> When building openSSL on Windows with: > > * CONFIG=VC-WIN64A or CONFIG=VC-WIN32 > * no-shared no-threads -DWINVER==0x0501 -D_CRT_NON_CONFORMING_SWPRINTFS > * With Visual Studio 2005 > > I get dependencies to user32.dll, when using libeay32.lib, e.g: > > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__delet...@4 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__deleteobj...@4 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__getbitmapb...@12 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__bit...@36 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__getobje...@12 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__selectobj...@8 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__createcompatiblebit...@12 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__getdevicec...@8 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__createcompatibl...@4 > 2>libeay32.lib(rand_win.obj) : error LNK2001: unresolved external symbol > __imp__create...@16 > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol > __imp__getuserobjectinformati...@20 > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol > __imp__getprocesswindowstat...@0 > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol > __imp__getdesktopwin...@0 > 2>libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol > __imp__messageb...@16 > > These dependencies are unwanted for our application, since using > user32.dll will result in Windows desktop exhaustion if too many users > are logged in to a Windows system (via a service) and use our application. > I would like to have an option to prevent any interaction to UI > (user32.dll) related code. Can you please add such option? > > As far as I could see, the code in rand_win.c/cryptlib.c are related to: > - OPENSSL_isservice(), which uses GetDesktopWindow(), > GetProcessWindowStation(), GetUserObjectInformationW() > - and a number of functions in rand_win.c e.g. readscreen() > - readscreen() seems to be used only in RAND_SCREEN() and has some > comments that the function exists only for backward compatibility. If > this compatibility can be turned off, much of the dependencies to > user32.dll are removed then. > > I don't know how to fix this. But I would like to share some thoughts: > > * Windows 2008/Vista does not allow to call MessageBox() if the > calling process is a service (and running in session 0). So > MessageBox() is only useful if a normal user, connected to an > interactive Windows Desktop, will call openssl executables.
This is misconception. It's not like 2008/Vista does not allow to call MessageBox in service, it's just that you don't see nor can you interact with it. Secondly [and more importantly!] openssl won't call MessageBox if it finds itself running in Windows service context. Instead it will log the message to event log. > * I saw a lot of NT4 code. What NT4 code? You must be referring to _WIN32_WINNT macro sometimes set to 0x400. It does not denote NT4-specific code, it denotes that NT4 is required *minimum*. Meaning that it targets *all* Windows versions *past* 4: 2000, XP, 2003, Vista, 2008, 7, etc. > * Background information on desktop exhaustion: > > http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx > > <http://blogs.msdn.com/ntdebugging/archive/2007/01/04/desktop-heap-overview.aspx> > and > http://blogs.technet.com/markrussinovich/archive/2010/02/24/3315174.aspx > > <http://blogs.technet.com/markrussinovich/archive/2010/02/24/3315174.aspx> As already implied, when executed in Windows service context, openssl is programmed to abstain from making user32 and gdi32 calls and won't interact with UI. But user32.dll is mapped and this does mean that some session memory is consumed, *but* *not* beyond absolute minimum implied by mere initialization of user32.dll. The only situation I can think of when resource exhaustion could be a problem is when a separate *process* is created for every user/connection. Is it your case? If not, then it shouldn't even be a concern. If yes, i.e. a separate *process* is created for every user/connection, then I'd suggest to modify OPENSSL_isservice() to immediately return 1(**) and /delayload:gdi32.dll /delayload:user32.dll and keep it is as private customization. A. (*) For reference, most of Microsoft services have user32.dll mapped into their address spaces, meaning that they also consume at least some bare minimum. (**) Alternative to returning 1 could be enumerating handles, identifying windowstation one, pulling and finally checking its name in same manner it's currently done in OPENSSL_isservice, but with native NT API. Naturally also with /delayload. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
