Beta One doesn't load

[David McKenna]

Uninstalled old preview, then installed Beta with no issues. Install said all prerequisites were installed. Started SeaMonkey?, but Flash does not appear in 'About Plugins' and in fact no Flash content works (says no plugin installed).

I had tried an early test version for debug purposes (long deleted) and that required an environment variable 'SET ODINDLLPATH =...' I tried that and now Flash works.

Is this correct?

[dmik]

The new version of Flash should not require any environment/registry settings at all. The reasons it doesn't show up in about:plugins may include the inability to load a proper version of Odin (0.8.3, in particular its kernel32.dll) from [BEGIN]LIBPATH or the win32 plugin DLL (npswf32.dll) that must be located in the same directory where npflos2.dll resides.

Please check these two conditions. If you find nothing, I will give you the debug wrapper with logging.

[gerrit]

Hello,

Installed the new Flash 11 beta, after uninstalling of the old preview. Install ran flawlessly. The right plugin directory was found. All prerequisited DLL's and the right ODIN version (0.83) were present. I use Rich Walsh RUN utility to start firefox as firefox!E.exe with the environment variables mentioned in the firefox!.env file, e.g.:
SET MOZILLA_HOME=L:\FIREFOX_PROFILE
SET MOZ_PLUGIN_PATH=L:\FIREFOX_PROFILE\PLUGINS

Starting Firefox that way ended up on flash sites with the message "missing plugin". "About:plugins" said: No enabled plugins were found.
Apparently Firefox could not find the contents of the plugin directory despite of the fact that firefox should be aware where to find it (according to the environment variable settings).

Moving the PLUGINS directory to the DEFAULT path, e.g. L:\FIREFOX_PROFILE\MOZILLA resulted in a working flash????????

My question is: What's going on here. Above could not be reproduced on a machine with a fresh eCS 2.1 install. In both cases the same Firefox 8.01 build was used.

Cheers!
Best Regards
Gerrit Schoenmaker
Mensys BV

[diver]

the fact is we don't know atm. all we know ffox works w/o problems when running w/o the run.exe utility. please stay tuned.

[David McKenna]

Yes, those two conditions are correct (Odin is in c:\usr\lib and it is the first path in LIBPATH). Gerrit's post made me think... I normally start SeaMonkey? using Run!. When I do that, Flash does not work (without the environment variable set). If I start SeaMonkey? directly, then Flash works fine. Maybe LIBPATHSTRICT is getting in the way?

[gerrit]

Hi,

Just to mention that I've tested the new flash build for firefox also without using RUN!. The environment variables were SET in the config.sys and firefox was started as FIREFOX.EXE.
Got the same result: about:plugins said "No enabled plugins were found". The only way to get the new flash running, was moving the PLUGIN dir to the default location where firefox does expect it to find, e.g. L:\FIREFOX_PROFILE\MOZILLA\PLUGINS.

BTW: ODIN 0.83 was installed by copying the new DLL's from the ZIP file to the system32 directory of a former ODIN WPI install. ODIN resides in C:\ODIN and the config.sys contains a C:\ODIN\SYSTEM32 statement in PATH and LIBPATH.

[Michaelhz]

Hi,

after playing around, i found out that using run!.exe is not the problem. firefox!.exe works, firefox!L.exe not. So the item is related to libpathstrict.

hopefully this helps.

Michael

[lewisr]

Yep, LIBPATHSTRICT bit me, too.

I couldn't figure out why the plugin was loading under PmW-Fx 2, but not FF10 or SM2.7. Turns out, my script to start PmW-Fx was the only one of the three *without* LIBPATHSTRICT set.

[dmik]

Yes, after many hours of debugging together with Silvan I found two separate issues:

1. If you have BEGINLIBPATH pointing to a directory that doesn't contain Odin32 DLLs and also set LIBPATHSTRICT=T, then the wrapper will not be able to load KERNEL32.DLL. Since this is what Firefox!L.exe does, no surprise that it doesn't work if you use it.

2. If you have another application using Odin DLLs running and try to start firefox for which you suppliy another set of Odin DLLs (either through BEGINLIBPATH/LIBPATHSTRICT=T or through NPFLOS2_ODINDLLPATH) but this set doesn't contain WGSS50.DLL, then loading KERNEL32.DLL will also fail. And also, the application using another set will be completely screwed up because WGSS50.DLL will be unexpectedly initialized twice in its process.

The reason why the old Flash plugin didn't show the behavior described in #1 is because it always used the full path when loading KERNEL32.DLL, regardless of BEGINLIBPATH. So, in order to temporarily overcome problem 1, you should use a special environment variable NPFLOS2_ODINDLLPATH that points to a directory containing Odin32 DLLs. This will mimic the old behavior and make starting through run! work again.

Problem #2 doesn't have a workaround.

I will check if these problems can be properly fixed.

Thanks to everybody for reporting.

[dmik]

Note that these problems only happen on some machines. On other machines everything works (including mine, of course). This seems to be related to the order of DLLs in the internal OS/2 loader list.

[David McKenna]

OK, #1 works for me. I don't think I will ever run into #2 (only one Odin here - unless Innotek runtime counts as one too).

[Michaelhz]

#1 works for me also. Thanks. Michael

[dmik]

I've made some tests and found the following:

1. If LIBPATHSTRICT=T is set AND an attempt to load a DLL with DosLoadModule?() using the NAME.EXT specification (i.e. "KERNEL32.DLL") is made, then OS/2 ignores the contents of both LIBPATH and ENDLIBPATH variables. This means that it will be unable to find a DLL (and return error 2) unless its path is explicitly specified in BEGINLIBPATH.

2. If LIBPATHSTRICT=T is NOT set, then the above problem doesn't show up: the DLL can be successfully found and loaded. OTOH, if you load a DLL using only its basename (e.g. "KERNEL32"), then LIBPATH and ENDLIBPATH are respected and the DLL can be loaded even in LIBPATHSTRICT=T mode.

3. Just as a side observation. It is known that in normal mode, if a process attempts to load a DLL when there is already a DLL with the same name in memory loaded by some other process, this already loaded DLL will be used regardless of whether there is another DLL around in in its BEGINLIBPATH/LIBPATH/ENDLIBPATH. Setting LIBPATHSTRICT=T for a process changes this behavior in the following ways:
   • The DLL which is found in BEGINLIBPATH/LIBPATH/ENDLIBPATH of this process (in the given order), will be loaded regardless of whether there is a DLL with the same name already in memory. If no DLL is found in in these LIBPATHs, then the one already loaded is used.
   • However, if a process tries to load a DLL which is absent in its BEGINLIBPATH/LIBPATH/ENDLIBPATH and there is a DLL with the same name loaded by a LIBPATHSTRICT=T process, this DLL will NOT be picked up (regardless of this process' LIBPATHSTRICT setting). This last rule is not obvious but it looks logical (DLLs loaded by LIBPATHSTRICT=T processes are hidden from normal processes unless they load them by full path or specify their exact locations in their own BEGINLIBPATH/ENDLIBPATH).

The first two items look like a mere bug in the OS/2 loader to me.

[dmik]

Problem 1 is fixed now (r59).

[dmik]

Problem 2 isn't going to be fixed now as it's not really a case for normal users (and it probably doesn't have a fix at all). I created a separate ​Odin ticket for it.

This means that this defect is fixed. A new version will be released soon.

[dryeo]

If LIBPATHSTRICT=T is set AND an attempt to load a DLL with DosLoadModule??() using the NAME.EXT specification (i.e. "KERNEL32.DLL") is made, then OS/2 ignores the contents of both LIBPATH and ENDLIBPATH variables. This means that it will be unable to find a DLL (and return error 2) unless its path is explicitly specified in BEGINLIBPATH.

IIRC even using a name like KERNEL32.DLl will work around this bug and this how Flash 7 had to be patched to work correctly with sound.
We also recommended people to load their main browser without LIBPATHSTRICT and only use LIBPATHSTRICT with secondary programs such as Thunderbird. This worked fine due to another bug in the kernel loader.

[dryeo]

Here's the thread about this bug with Rich's diagnoses, ​https://groups.google.com/group/mozilla.dev.ports.os2/browse_thread/thread/b7bd9b3cbfca9795/43ea7737ddbc10c6?hl=en&ie=UTF-8&q=libpathstrict+sound+flash+7#43ea7737ddbc10c6

[abwillis]

Same issue as was fixed in Odin sometime back in:
​http://svn.netlabs.org/odin32/ticket/32