281471 - On Windows, suppress missing DLL dependency dialogs from PR_LoadLibrary

Status: RESOLVED DUPLICATE of bug 278328

(NSPR :: NSPR, defect)

Description

[Benjamin Smedberg]

On linux, if a sharedlib dependency is missing, PR_LoadLibrary simply fails. On
Windows, the OS displays a dialog box by default. Since PR_LoadLibrary is
frequently used to do runtime detection of libraries, this dialog is bad UI. We
can wrap the PR_LoadLibrary impl on windows with SetErrorMode() to avoid this
dialog.

Comment 1

[Benjamin Smedberg]

Attachment: Wrap LoadLibrary() in SetErrorMode()

Comment 2

[Darin Fisher]

From MSDN:

"Each process has an associated error mode that indicates to the system how the
application is going to respond to serious errors. A child process inherits the
error mode of its parent process.

Because the error mode is set for the entire process, you must ensure that
multi-threaded applications do not set different error-mode flags. Doing so can
lead to inconsistent error handling."

Do we care?

Comment 3

[Doug Turner (:dougt)]

I doubt that we want to make this change in NSPR; If we were going to do this,
XPCOM would be the better place was we are the ones more likely to load a
library that has missing depend libraries.  Wan-Teh, would a better place for
this patch be in XPCOM?

These dialogs aide discovery of what installation problem there might be.  Is
there an alternative way this information can be generated by the user and be
given to someone in tech support/customer service?  

Also, this dialog may be the least of the user's worries, right?  If the
component failed to load, chrome or other core functionality may be hosed, right?

Probably in a seperate bug, we should discuss making xpcom smarter the way it
loads (or fails to load) components.  If we drop this dialog, it make make sense
for xpcom to raise a dialog with simple information about the failure.

Comment 4

[Benjamin Smedberg]

Nono! The point is that missing dependencies are a normal+expected occurence,
and should not be reported to the user (think gdi+). We already removed the
"could not load component" warning from the console output, because on linux we
use this to do runtime detection of gssapi and such.

Comment 5

[James Ross]

So instead of flattening the entire thing, why not have a
LoadButWeDontCareIfThisFails call instead? Then we still know about required
stuff missing without any unneeded stuff when 'testing' if something is there.

Comment 6

[Wan-Teh Chang]

This bug is a duplicate.

Error mode is a process-wide property.  A library
like NSPR should refrain from setting a process
property.  An application is in the best place to
do that.  I agree that we should disable the error
dialog, but it should be the applications (Mozilla,
Firefox, Thunderbird, etc.) that should do that.
Even XPCOM may not be the right place to do that.

The fact that the attached patch is not thread-safe
is irrelevant.


*** This bug has been marked as a duplicate of 278328 ***