On Wednesday, April 17th, 2024 at 6:57 AM, Michael Wojcik via openssl-users <openssl-users@openssl.org> wrote:
> > From: Turritopsis Dohrnii Teo En Ming teo.en.m...@protonmail.com > > Sent: Monday, 15 April, 2024 07:36 > > > > > > From: openssl-users openssl-users-boun...@openssl.org On Behalf Of > > > > Turritopsis Dohrnii Teo En Ming via openssl-users > > > > Sent: Saturday, 9 March, 2024 06:59 > > > > To: openssl-users@openssl.org > > > > > > > > On 7 March 2024 Thursday, when I was installing new self-signed SSL > > > > certificate for the door access system for a law firm in Singapore, I > > > > notice that > > > > Suprema BioStar 2 also has 32-bit OpenSSL binary. > > > > > > > > The path is: > > > > > > > > C:\Program Files\BioStar 2(x64)\ta\OpenSSL-Win32\bin > > > > > > > > I am wondering if I can install 64-bit OpenSSL binary from another > > > > packager. > > > > Will there be any conflict? > > > I am thinking of installing Third Party OpenSSL Related Binary > > Distributions like > > FireDaemon. > > > I can't comment on that; I don't know what it contains, or how its > installation process works. > > > I think there shouldn't be a conflict. > > > This is more a question about Windows and how it loads DLLs, than it is an > OpenSSL question. > > Assuming BioStar 2 loads the OpenSSL DLLs using the normal Windows mechanism, > from EXEs in the same directory as those DLLs, then it should continue to > load its own OpenSSL DLLs. Windows puts the EXE's directory at the start of > the DLL search path when doing a normal implicit load, assuming no SxS > nonsense interferes. Though that said, it's odd that BioStar 2 puts the > OpenSSL DLLs in a "bin" directory (apparently) of their own. I can't say what > BioStar 2 is up to here; I have no idea how the developers of that package > expect things to work. > > The other concern is whether any other programs which use OpenSSL will end up > loading it from the BioStar 2 OpenSSL-Win32\bin directory rather than the > FireDaemon installation directory, whatever that might be. Applications which > simply have an implicit dependency on the OpenSSL DLLs, or which do a > conventional LoadLibrary, will typically end up searching the directories in > their PATH environment value. So you would want to ensure that the FireDaemon > directory containing the OpenSSL DLLs is earlier in the PATH for at least > those applications, and probably for everything — assuming BioStar 2 does > something sensible like specify its library-loading source. > > In short, it's impossible for anyone to say whether there will be a problem > without recreating your environment. This is a universal difficulty with > loading shared modules. The best approach for professional software is to > avoid using modules which might conflict, by being explicit with their > linking or using alternative file and symbol names or whatever. But many ISVs > do not take that precaution. > > -- > Michael Wojcik Dear Michael, Noted with thanks. Mr. Turritopsis Dohrnii Teo En Ming Targeted Individual in Singapore
