Just one idea, which popped up today. What about of using UuidCreate() function, see: http://msdn.microsoft.com/en-us/library/aa379205(VS.85).aspx
In our case, our software runs as a service, in its own desktop/winstation. That desktop does not have a bitmap at all, or if it has one, it is always identical. You may like to use UuidCreate() to generate a unique/random number, not dependent on user32.dll/gdi32.dll. Regards, Kees -----Original Message----- From: Kees Dekker Sent: Monday, 12 April, 2010 12:27 To: 'r...@openssl.org' Cc: openssl-dev@openssl.org Subject: RE: [openssl.org #2194] Unwanted dependencies to user32.dll > -----Original Message----- > From: Andy Polyakov via RT [mailto:r...@openssl.org] > Sent: Monday, April 12, 2010 12:08 > To: Kees Dekker > Cc: openssl-dev@openssl.org > Subject: Re: [openssl.org #2194] Unwanted dependencies to user32.dll > > >>>>> May be there is another method to check wether a windows > >>>>> process is a service, without using user32.dll. > >>>> As mentioned one can do it with Native NT API, but it's quite > >>>> special and belongs rather in [your] application than in > >>>> openssl. > >>> Yes and no. As soon as there is any openSSL code, using APIs from > >>> user32.dll, my application still have a dependency to > >>> user32.dll. > >> Once again, if you /delayload user32 and never make the call, > >> you're safe. OpenSSL never calls RAND_screen, your application can, > >> make sure it doesn't. OPENSSL_isservice doesn't make user32.dll > >> calls if you redirect stderr. If called as service start your > >> application with redirected stderr. > > > > The function app_RAND_load_file() calls RAND_screen. And > > app_RAND_load_file() is called from many places. > > app_RAND_load_file is in openssl.exe application. Do you invoke > openssl.exe from your application??? I was under impression > that *your* > application is *linked* with OpenSSL *library*... So that when I > referred to "OpenSSL" I referred to the *library*, not openssl.exe. Or > you might compile one of apps/*.c modules with your application. In > which case http://cvs.openssl.org/chngview?cn=19557 would still do the > trick... You are right. > > > I cannot oversee > > whether OpenSSL (library) really Never calls this function. Most > > probably, the library will not. > > When I said "it doesn't call it" there was no "probably." This implies > that you a) take my word for it; b) verify the statement and tell that > it's wrong in case it is. In latter case, if the statement will be > proven wrong, it will be considered as bug and will be fixed. > But there > is nothing one can do about "I cannot oversee." I only use the static lib. > > >> Rules of conversation imply that you either try to refute the > >> statement or confirm it. As opposite to ignoring it and tell what > >> would you *like* to do over and over:-):-):-) > > > > Ok you can close this request. It was not intended by me to move the > > 'difficult part' to openSSL. > > > > I only suggested - if the code was not used by OpenSSL at all, like > > you said - just to put it within #ifdef > NEED_OLD_FUNCTIONALITY or so. > > ??? RAND_screen would be the *only* candidate for > NEED_OLD_FUNCTIONALITY, but it's not the only place where user32 calls > are made... Only one or two others left, or am I wrong? > > > The problem with delayed loading of user32.dll is that developers of > > our code **can** use user32.dll functionality, while I prefer to > > forbid it, i.e. explicitly disable linking to user32.dll. > > What are the means of forbidding? Not having user32.lib on > link command > line you tell developers to use? How do you link with openssl library? > Statically or dynamically? If statically, then add stub module of own > design with handful of empty functions called by OpenSSL library and > exclude gdi32/user32 from link command line. Or consider switching to > dynamic link, i.e. with OpenSSL *dlls*, because if linked dynamically, > then you don't need user32.lib on *your* link command line at all. > Statically. Dynamic linking has its own merits. I will try what I can do in this region. However, it is ok to close this request. > > I would > > like not to use user32.dll at all in our code. > > Then don't. Just demand discipline from your developers. Tell them why > it's important, they'll understand. > > >> From development/compile/link perspective there is no difference in > >> using user32.lib/dll with regular flags, or with delayed load > >> flags. > > By using delayed loading, the risc is high that user32.dll is used > > (either by accident, or by intention of one of our developers). > > What is real risk/concern here? That product is shipped to > end-user, who > discovers that amount of users can start application in question in > service context is lower than expected. Just add the check for > user32.dll being mapped at run-time to your test cycle and handle the > problem prior release... A. > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
