Can't run Dooble when Apache is running

[David McKenna]

 I just noticed a strange problem... when I try to run Dooble on my Apache server system, it fails with this POPUPLOG:

12-25-2023  13:44:30  SYS2070  PID 0070  TID 0001  Slot 009d
C:\USR\BIN\DOOBLE.EXE
FREETYP6->BZ2._BZ2_bzDecompressEnd
127

 If I stop the server, then Dooble works. I am running latest Apache 2.4.57, and php 8.1.17. I am guessing it is somehow related to the fact there is a php module named bz2.dll, and its directory is added by the beginlibpath statement in the startup Apache command, but it should be just for the Apache process (I thought), right?. Any ideas what could be done?

Regards,

[Steven Levine]

In <93d03bac-0219-4afd...@googlegroups.com>, on 12/25/23
at 11:00 AM, David McKenna <davidmc...@gmail.com> said:

Hi David,

>12-25-2023 13:44:30 SYS2070 PID 0070 TID 0001 Slot 009d
>C:\USR\BIN\DOOBLE.EXE
>FREETYP6->BZ2._BZ2_bzDecompressEnd
>127

Error 127 is our typical entry point not found failure. As you suspect,
we have mismatched DLLs.

>I am guessing it is somehow related to the fact
>there is a php module named bz2.dll, and its directory is added by the
>beginlibpath statement in the startup Apache command, but it should be
>just for the Apache process (I thought), right?

Not exactly. If a DLL with the same module name is already loaded in
memory, OS/2 will use it, unless LIBPATHSTRICT is enabled and the DLL if
found in a BEGINLIBPATH directory and a few other condiions are satisfied.
I've appended a copy of my libpath errata notes with more of the gory
details.

>Any ideas what could be done?

A local fix would be the DLLRename the PHP bz2.dll to bz3.dll and modify
php.ini to reference it. This assumes you really the the bz2 extension
loaded.

Probably the best long term solution is a new php 8 build that builds the
php bz2.dll as php_bz2.dll.

Back in php5 days, all the module names had a php_ prefix. This changed
in php7, probably because the name conflicts were not an issue on other
platforms.

Steven

--
----------------------------------------------------------------------
"Steven Levine" <ste...@earthlink.net> Warp/DIY/BlueLion etc.
www.scoug.com www.arcanoae.com www.warpcave.com
----------------------------------------------------------------------

libpath and libpathstrict errata

2007-10-06 SHL Baseline
2012-07-20 SHL Add more
2014-09-24 SHL More LIBPATHSTRICT
2014-10-06 SHL Add LIBPATH errata
2018-07-16 SHL Expand empty directory errata
2019-04-04 SHL Add RLW DosLoadModule FQ name notes
2023-02-08 SHL Doc empty directory fix

== TBD ==

http://www.edm2.com/os2api/Dos/DosLoadModule.html

=========================================
== DosQueryExtLIBPATH/DosSetExtLIBPATH ==
=========================================

APIRET APIENTRY DosQueryExtLIBPATH(PSZ pszExtLIBPATH, ULONG flags);
APIRET APIENTRY DosSetExtLIBPATH(PSZ pszExtLIBPATH, ULONG flags);

/* definitions for DosQueryExtLIBPATH and DosSetExtLIBPATH flags parameter */
#define BEGIN_LIBPATH 1
#define END_LIBPATH 2
#define LIBPATHSTRICT 3

Use "T" or "F" or "" for LIBPATHSTRICT argument

LIBPATHSTRICT does not nul terminate return value

See bsedos.h:2555

===============================
Rich Walsh says - LIBPATHSTRICT
===============================

Hard-coded uppercase .DLL causes DLL load to fail with LIBPATHSTRICT=T under
certain conditions (Rich Walsh).

1- LIBPATHSTRICT has NO effect unless BEGINLIBPATH has also been set.

2- Only dlls found along the BEGINLIBPATH are given special treatment;
dlls found along LIBPATH and ENDLIBPATH are handled normally.

3- Regardless of whether LIBPATHSTRICT is in effect, the system *always*
searches the entire extended libpath (i.e. BEGIN/LIBPATH/END) if needed.

4- If LIBPATHSTRICT is in effect _and_ BEGINLIBPATH is set, the system
will fail to load a dll if it is not in a BEGINLIBPATH directory *and*
its extension is all uppercase. For example, if gbm.dll is in \os2\dll,
the gbm plugin will have no problem loading "GBM", "GBM.dLL", "GBM.Dll",
etc, but will always fail loading "GBM.DLL" .

Item 4 is the basis for my Flash fix (my thanks to Peter for noting that
MDM.DLL was failing to load). flashwin tries to load "MDM.DLL" but fails
when LIBPATHSTRICT is in effect because \mmos2\dll is part of the standard
libpath and the file extension is all uppercase. There are 3 solutions:
copy mdm.dll to a BEGINLIBPATH directory, add \mmos2\dll to BEGINLIBPATH,
or lowercase the extension. My patch does the latter: it changes the
string "MDM.DLL" to "MDM.dLL" and gets around this peculiar bug.

BTW... Peter, I don't think there would be any problem with turning off
LIBPATHSTRICT in the mozapps. AFAIK, it's only needed while the system
is loading the dlls that reside in the exe's directory (i.e. the ones
the linker knows about). All of the other dlls (i.e. those in components
and plugins) are loaded by fully-qualified name, so the LIBPATH isn't
used. Of course, you'll want to test this...

===================================
== LIBPATH and empty directories ==
===================================

- Reported by JvW 2014-10-05

LIBPATH .;emptydir;dir2;..dirN

where emptydir is empty will cause boot hang or trap

Internal proecessing Errror ##1800:05b5 - 0003:05b5
65535, 9051
JFSBOOT: Error reading in FS
0a8606a9
14.106_SMP

- non existing directory in LIBPATH => no problem
- empty directory at the END of the LIBPATH => ring-0 trap (IPE)

See ReadSectors in miniJFS.asm
ReadSectors:
...
Message generated by
call FSH_DOVOLIO
or ax,ax
jz short @@Rdrt
mov si,offset ErrorReadFS
call IntError

- Resolved by Arca Noae jfs 1.9.8

=======================================
Rich Walsh says - DosLoadModue FQ names
=======================================

https://groups.google.com/forum/#!topic/comp.os.os2.programmer.misc/Cu-WS91aqvk
https://www.os2world.com/forum/index.php/topic,2037.0.html

You've encountered a problem in the v4.5 kernel that I identified
years ago. Scott Garfinkel agreed it was a bug but wouldn't fix it.

In effect, the loader maintains 2 lists of dlls: those loaded by
f/q name and those loaded by modulename using the extended libpath.
When you load a dll by modname, the loader ignores its list of dlls
already loaded by f/q path and instead searches the libpath. The
net effect is sort of a "libpathHALFstrict" condition.

There is a workaround/hack that I've had to use in several projects.
If a dll that was initially loaded by f/q name is later loaded by
modname, its entry get moved from the f/q list to the modname list.
Thereafter, it can be reloaded any number of times by either method.

In my case, the dll had already been loaded by f/q name, so I got it's
path, added it to BEGINLIBPATH, then reloaded it by modname. Since my
code was operating in a process it didn't create, it had to clean up
after itself by restoring the original BEGINLIBPATH. If you control
the process, then you can just set it, do the initial load of A.DLL
by modname, and leave things as-is.

FYI... while LIBPATHSTRICT is in effect, all newly-loaded dlls go
on the f/q name list. Because of the "libpathHALFstrict" condition
that normally prevails, none of these dlls will be found if reloaded
by modname. This is what permits you to run multiple, incompatible
versions of the Mozilla apps without having to set LIBPATHSTRICT for
all of them. Any *one* can omit it and each will still use its own
dlls.

[David McKenna]

Thanks for the detailed explanation Steven - you truly are a fount of OS/2 knowledge! I did as you suggested and changed the module DLL name to php_bz2.dll and updated php.ini to show the same. No problem with Apache (and Wordpress, and phpMyAdmin, and FileGator) but Dooble (and it turns out Firefox and SeaMonkey) still doesn't start when Apache is running (it is LIBPATHSTRICT=T BTW), but now without a POPUPLOG, instead just an exceptq log. Seems to point at fnfcfg1.dll, but not clear why. I'll attach a log. Maybe renaming the DLL isn't enough?

Regards,

[Steven Levine]

In <6f689b29-a591-448e...@googlegroups.com>, on 12/26/2023

at 02:38 PM, David McKenna <davidmc...@gmail.com> said:

Hi David,

>I did as you suggested and changed the module DLL name
>to php_bz2.dll

You cannot just rename the DLL. As I mentioned, you need to use dllrname
from the toolkit. You new name needs to be the same length as the old
name. Try

dllrname bz2.dll BZ2=BZ3

bz2.dll will be edited and renamed to bz3.dll.

The better long term solution is for Paul to build a php_bz2.dll. I
recommend you submit a ticket. It would be good if the new build included
debug symbols. It would make debugging other issues easier.


Steven

--
--------------------------------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
DIY/Warp/BlueLion etc. www.scoug.com www.arcanoae.com www.warpcave.com
--------------------------------------------------------------------------------------------

[David McKenna]

Steven,

 Ah... OK, now I understand - sorry for my confusion. I'll raise a ticket on his mantis site...

Regards,