Firefox 3.5 start crashes DosLoadModule/DosUnloadModule

[Marcel Müller]

I have another ugly drawback of FF 3.5:

Once FF 3.5 has been started on the system DosLoadModule always returns
error 295 (initialization routine returned non-zero) when a DLL which
depends on MDM.DLL (MMOS2) is to be loaded. This causes /all/ versions
of PM123 to fail while loading the output plug-in (tested with 1.21 to
1.40). Once this happend in an application /all/ calls to
DosUnloadModule return the same error, even for DLL modules that have
been loaded successfully.

If I start PM123 first, everything is fine as long as I do not end it.

Any idea what FF 3.5 could mess up in the system?
It is a really annoying feature.

Marcel

[Dave Yeo]

IIRC it is a kernel bug, it does work with using DosLoadModule to load
MDM.dll or MDM. I think that this is now fixed in the latest dailies.
Really you should be posting this in
news://news.mozilla.org/mozilla.dev.ports.os2 so someone more
knowledgeable or better memory can answer
Dave

[Marcel Müller]

Dave Yeo wrote:
> IIRC it is a kernel bug, it does work with using DosLoadModule to load
> MDM.dll or MDM.

Uh, I feared something like that.

> I think that this is now fixed in the latest dailies.

In fact you are right. The 3.5.3 pre version does not show this behavior
anymore.

Marcel

[tho...@antispam.ham]

Marcel writes:

I wonder if that could be related to the problem I've experienced with
Firefox 3?

I have an Analog Devices 1885 audio chipset built-in on an Intel
motherboard. There are certain applications that simply kill my
audio capabilities. RSJ's trackcpy is one of them, but oddly
enough, the PM version of trackcpy, CDView, doesn't have that
effect. All RSJ could tell me about the problem is that they
couldn't reproduce it, which suggests to me that it may be specific
to the Analog Devices 1885 driver.

Anyway, several days ago I experienced an audio failure that appeared
to involve Firefox, so I performed a test that included rebooting,
running my audio editing software to verify that audio was working,
and firing up Firefox 3. Tried to launch my audio editing software,
but something was blocking it. The command prompt didn't return, but
neither would my editor continue. Similarly, z! wouldn't paint its
window, instead just sitting there as if blocked. Then I exited
Firefox 3 and retried both my editor and z!. My editor exited
immediately, returning to a command prompt, ditto for z! Sure
looked to me like Firefox 3 was having the same effect on my system
that RSJ's trackcpy did.

Audio applications that are already running at the time of a
failure continue to produce audio, but as soon as I exit the
application, restarting it results in immediate failure. All of
this sounds eerily similar to what you're describing (involves
MMOS2, involves a recent version of Firefox, doesn't affect
applications already running as long as you do not end them).

So I did a little web surfing and discovered that there is a version
3.1.4 of the audio driver for my chipset, whereas I was at version
3.1.3. Hopeful of an improvement, I downloaded it an installed it.
At first it seemed to be a cure, but I have since experienced other
failures, which suggests to me that it might depend on which web
page Firefox went to after it was launched. For now, I'm back to
Firefox 2, because the only way I know of to restore my audio is to
reboot. If it's really a kernel bug, then I suppose nobody can offer
a solution other than rebooting.