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

[Greg Chicares]

On 2006-2-8 12:23 UTC, Greg Chicares wrote:
> On 2006-2-7 1:47 UTC, Greg Chicares wrote:
[...]
> 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.
[...]
> Wendy's going to carry the investigation forward, by trying to
> determine which dlls are responsible for the problem.

She reports that
  ::LoadLibrary(DOCPROP2.DLL);
fixes the immediate, reproducible problem on msw-2000. Without
that, merely starting the application, doing File | Open, and
changing the directory in the "common file dialog" changes the
floating-point control word--which a wxTimer handler checks
every tenth of a second.

Using msw-xp, I find that loading that dll does not change the
control word.

With the latest cvs HEAD, a list of dlls to preload can be
specified in an '.xml' file. Therefore, without any further
code changes,...

> This workaround isn't ready to release to end users yet. Obviously,
> it can load a very great number of dlls.

...the application can be configured to work around problems
with a specific operating-system version, or even with a
particular user's machine.

> 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.

If a specified dll isn't valid, an lmi diagnostic suggests
removing it from the list. If it was loaded successfully but
had no effect on the control word, then another diagnostic
similar suggests removing it from the list.

> 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.

Now, FreeLibrary() is called, at exit, on the list of dlls
that were preloaded successfully--in reverse order of loading.

Because 'DOCPROP2.DLL' was the culprit for the reproducible
msw-2000 problem, I considered calling a function like the
following, just before preloading any dll explicitly:

void InitializeAllKnownCommonControls()
{
    INITCOMMONCONTROLSEX iccx;
    iccx.dwSize = sizeof(INITCOMMONCONTROLSEX);
    iccx.dwICC =
          ICC_ANIMATE_CLASS
        | ICC_BAR_CLASSES
        | ICC_COOL_CLASSES
        | ICC_DATE_CLASSES
        | ICC_HOTKEY_CLASS
        | ICC_INTERNET_CLASSES
        | ICC_LINK_CLASS
        | ICC_LISTVIEW_CLASSES
        | ICC_NATIVEFNTCTL_CLASS
        | ICC_PAGESCROLLER_CLASS
        | ICC_PROGRESS_CLASS
        | ICC_STANDARD_CLASSES
        | ICC_TAB_CLASSES
        | ICC_TREEVIEW_CLASSES
        | ICC_UPDOWN_CLASS
        | ICC_USEREX_CLASSES
        | ICC_WIN95_CLASSES
        ;
    InitCommonControlsEx(&iccx);
}

I chose not to do that because it is documented not to work
on msw-98 without a particular version of the 'explorer'
browser installed--and several of those macros were added
at various later times. There's nothing in lmi itself that
doesn't work with stock msw-95, and I don't want to break
that invariant without a compelling reason.