Hi,
The difference is that, on WCE, for stunnel code, it is straigthforward to access the "unique profile" stunnel.conf, WITHOUT in fact dealing with envvars,
rather than 1/ decode %VARNAME% tokens in conf file and then ask env for replacement...
well...ok..we can create stubs as well for getenv etc... but is is much more complicated.
For W32 platforms, communicating with a server with env vars can open issues.
files not modified globally, only for current USER by USER values in runtime, only for specified parametersBUT working in "local user sandbox", folders etc...is more secure than modifying system files by everyone through envvars.
More generally, I agree that a per user conf can be useful ONLY IF each user is able, and "directed to" start HIS/HER STUNNEL by HAND, in a user space process.
But to achieve this....stunnel is ALREADY ready to go by using the command line like this "stunnel myownconfig.conf", of course having "my" own copy of stunnel executable.
So there is no real need to have an embeddef feature in stunnel for conf file customization per user.
And, once again, as conf file are just "text files", it is quite easy to create a bunch of such from a template, by text editiong tools : sed on win32 is really powerful, or win32 perl engine, or whatever scripting language you prefer