Re: [lmi] Alien msvc rtl dll messing with the fpu?

[Greg Chicares]

On 2006-2-7 1:47 UTC, Greg Chicares wrote:
> On 2006-1-13 22:50 UTC, Greg Chicares wrote:
> 
> [...] I've just committed another change that strives to pre-load all
> system dlls that the application uses, directly or indirectly. Compare
> the list of dlls added to 'main_wx.cpp' against the result of
>   /MinGW-20050120/bin/objdump -p ./lmi_wx_shared.exe |grep 'DLL Name'
> applied recursively--i.e., here, that command yields
>         DLL Name: KERNEL32.dll
>         DLL Name: msvcrt.dll
>         DLL Name: msvcrt.dll
>         DLL Name: USER32.dll
>         DLL Name: wxmsw254d_gcc_custom.dll
>         DLL Name: wx_new.dll
>         DLL Name: liblmi.dll
> but applying it to 'wxmsw254d_gcc_custom.dll' yields other dlls.

That didn't prevent the problem, but we found a brute-force method
that did: at startup, call LoadLibrary() on every dll in the
"\WINDOWS" and "\WINDOWS\SYSTEM[32]" directories. Perhaps the dll
list I had hardcoded was specific to msw-xp, whereas msw-2000,
which is used in our office, requires a different list.

This workaround isn't ready to release to end users yet. Obviously,
it can load a very great number of dlls. Some system files with a
'.DLL' extension aren't valid dll images, and the operating system
pops up a warning when we call LoadLibrary() on them. Closing the
application in the normal way seems to leave it running; that may
be because at this stage of the investigation we aren't calling
FreeLibrary() on dlls loaded with LoadLibrary(), or maybe it's
because some of those system dlls are just, well, rude.

Wendy's going to carry the investigation forward, by trying to
determine which dlls are responsible for the problem. Perhaps they
fit a pattern, like 'COMC*.DLL MSVC*.DLL', that will work even on
operating-system versions we don't have. It would probably be best
to track dll dependencies dynamically (recursively applying a
dependency-sniffer) at run time, but I hesitate to put a lot of
effort into that right now.