On Windows, suppress missing DLL dependency dialogs from PR_LoadLibrary

RESOLVED DUPLICATE of bug 278328

Status

NSPR
NSPR
RESOLVED DUPLICATE of bug 278328
14 years ago
14 years ago

People

(Reporter: Benjamin Smedberg, Assigned: Wan-Teh Chang)

Tracking

other
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
Created attachment 173707 [details] [diff] [review]
Wrap LoadLibrary() in SetErrorMode()
Attachment #173707 - Flags: review?(wtchang)

Comment 2

14 years ago
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

14 years ago
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.
(Reporter)

Comment 4

14 years ago
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

14 years ago
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.
(Assignee)

Comment 6

14 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → DUPLICATE
(Assignee)

Updated

14 years ago
Target Milestone: --- → 4.6
(Assignee)

Updated

14 years ago
Attachment #173707 - Flags: review?(wtchang) → review-
You need to log in before you can comment on or make changes to this bug.