FF38 req. DLLs

[A.D. Fundum]

So far (the undocumented?) EXPAT7.DLL, GTHR2.DLL and INTL8.DLL are
also required...


--

[A.D. Fundum]

> So far (the undocumented?) EXPAT7.DLL, GTHR2.DLL and INTL8.DLL
> are also required...

And, finally, STDCPP.DLL.


--

[A.D. Fundum]

> And, finally, STDCPP.DLL.

Is there a ZIP version of the bleedin' RPM-only packages in the
README.OS2 file?

Now it looks like FF38 cannot load a STDCPP.DLL of 26-7-2013 and/or a
STDCPP6.DLL of 2-2-2015, albeit there's no error message to support
such a claim. Or is there yet another undocumented, missing and/or
updated DLL?


--

[Dave Yeo]

There's Fontconfig, Pango, Cairo, Pixman, maybe glib and perhaps more.
I have to build to double check as my current build has some of the
above statically linked.
SM2.35a1 and Fontconfig available on my Bitbucket 31ESR page
Dave

[A.D. Fundum]

> maybe glib

The documentation isn't complete. For example:

>> INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'

The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
isn't.

FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.

> SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
> page

Thanks, SM is more important than FF and I do prefer static linking,
for one to avoid this "complicated" mess.

At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
cannot load STDCPP6.DLL.

The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.

Yesterday it looked like it worked with PM DLL, after copying
STDCPP.DLL to "." too, but it never really worked. It may have been
some PM DLL bug.

FWIW, I've only installed know, documented packages. For example, I
haven't verified if I should update GCC473,DLL, and so on. I'm almost
installing it as if I'm a new user, without an install whcih is
guaranteed to be fully up-to-date. All installed DLLs are verified,
only SM could cause a conflict but I haven't used that, nor games with
an own Z.DLL version.


--

[Dave Yeo]

A.D. Fundum wrote:
> > maybe glib
>
> The documentation isn't complete. For example:
>
> >> INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
>
> The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
> isn't.

gthreads are part of glib2 and really should be in the same zip.

>
> FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
> Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.

The new freetype dll should work with the last few releases and co-exist
with the mzfntcfgft DLLs

>
> > SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
> > page
>
> Thanks, SM is more important than FF and I do prefer static linking,
> for one to avoid this "complicated" mess.

https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35a1.en.os2.zip

>
> At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
> to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
> cannot load STDCPP6.DLL.

Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.

>
> The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
> PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
> CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.

Most of those are mozilla DLLs and Mozilla can find them by itself.
pthr01, mmap, pixman10, cairo2, pango100 and kai0 should be on the libpath.

>
> Yesterday it looked like it worked with PM DLL, after copying
> STDCPP.DLL to "." too, but it never really worked. It may have been
> some PM DLL bug.
>
> FWIW, I've only installed know, documented packages. For example, I
> haven't verified if I should update GCC473,DLL, and so on.

You need gcc1.dll along with its various forwarders such as gcc473.dll,
not the original gcc473.dll. Turns out all the GCC dlls are
interchangeable and should have been GCC1.DLL to start with.

> I'm almost
> installing it as if I'm a new user, without an install whcih is
> guaranteed to be fully up-to-date. All installed DLLs are verified,
> only SM could cause a conflict but I haven't used that, nor games with
> an own Z.DLL version.
>

BTW, plugin-container.exe doesn't correctly work yet (it's used to run
Flash in its own process space). What you should point PMDLL at is
XUL.DLL which will show you all the needed DLLs and with SeaMonkey
running the only ones in red are the Mozilla ones.
Dave

[Dave Yeo]

A.D. Fundum wrote:
> > maybe glib
>
> The documentation isn't complete. For example:
>
> >> INSTALL ... 'glib2.dll', 'gobj2.dll', 'gmod2.dll'
>
> The glib ZIP package is mentioned in README.OS2, but its GTHR2.DLL
> isn't.

gthreads are part of glib2 and really should be in the same zip.

>

> FWIW, I've moved (work in progress) new DLLs to the LIBPATH, except
> Z.DLL and a new FREETYP6.DLL which doesn't work with the installed SM.

The new freetype dll should work with the last few releases and co-exist
with the mzfntcfgft DLLs

>

> > SM2.35a1 and Fontconfig available on my Bitbucket 31ESR
> > page
>
> Thanks, SM is more important than FF and I do prefer static linking,
> for one to avoid this "complicated" mess.

https://bitbucket.org/dryeo/dry-comm-esr31/downloads/seamonkey-2.35a1.en.os2.zip

>
> At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
> to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
> cannot load STDCPP6.DLL.

Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
with the GCC* DLLs. New one will work for where the old one was needed.

>

> The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL, NSS3.DLL,
> PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL, MOZSQLT3.DLL,
> CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and SMIME3.DLL.

Most of those are mozilla DLLs and Mozilla can find them by itself.
pthr01, mmap, pixman10, cairo2, pango100 and kai0 should be on the libpath.

>

> Yesterday it looked like it worked with PM DLL, after copying
> STDCPP.DLL to "." too, but it never really worked. It may have been
> some PM DLL bug.
>
> FWIW, I've only installed know, documented packages. For example, I
> haven't verified if I should update GCC473,DLL, and so on.

You need gcc1.dll along with its various forwarders such as gcc473.dll,
not the original gcc473.dll. Turns out all the GCC dlls are
interchangeable and should have been GCC1.DLL to start with.

> I'm almost
> installing it as if I'm a new user, without an install whcih is
> guaranteed to be fully up-to-date. All installed DLLs are verified,
> only SM could cause a conflict but I haven't used that, nor games with
> an own Z.DLL version.
>

[ivan]

On Wed, 24 Feb 2016 02:53:17 UTC, Dave Yeo <dave....@gmail.com>
wrote:

The more I see of this the more I think that either firefox should be
compiled with static linking or there should be a zip made available
with the correct DLLs for that version (a RPM could also be made
available with the DLLs for those that use it).

The way this is going we are going to end up with some programs
requiring one version of the DLL and other programs requiring another
version of the same DLL.

I have already seen this with TAME no longer working on some updated
boxes but still working on unupdated ones.

ivan
--

[Dave Parsons]

Hi Dave,

On 24-02-16 04:01, Dave Yeo wrote:
>> At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
>> to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
>> cannot load STDCPP6.DLL.
>
> Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
> with the GCC* DLLs. New one will work for where the old one was needed.

> You need gcc1.dll along with its various forwarders such as gcc473.dll, not the original gcc473.dll. Turns out all the GCC dlls are interchangeable and should have been GCC1.DLL to start with.
>

The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
dated 2 Feb 2015.
Do you mean newer than these?

I am also trying to get FF 38.2.1 to work but at the moment it starts
to load & after about 5 seconds or so it beeps and quits.
There was nothing on the screen but it produced a TRP file and output
via stdout/stderr these few lines:-

> Fontconfig error: Cannot load default config file
> DIVE is disabled - Panorama's shadow-buffer is enabled
> Fontconfig error: Cannot load default config file
> Fontconfig error: Cannot load default config file
> Fontconfig error: Cannot load default config file
> Fontconfig warning: ignoring en_GB_EURO: not a valid region tag
> Fontconfig error: Cannot load default config file
> Fontconfig error: Cannot load default config file
> Fontconfig error: Cannot load default config file
> Fontconfig error: Cannot load default config file
> Creating 031E_01.TRP
>
> Killed by SIGSEGV

Any idea which file it is referring to?

The TRP file says it is trying to read from 00000018 & shows this:-

Call Stack
______________________________________________________________________

EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 0E04991E XUL 0001:00D0991E nsExpirationTracker.h#34 __ZN17gfxPangoFontGroup17GetFirstValidFontEj + 21E 0001:00D09700
(D:\Coding\mozilla\master\gfx\thebes\gfxPangoFonts.cpp)

Lost Stack chain - invalid EBP 40000000

I've been round all the DLLs mentioned in the readme and a few which
aren't and they all seem to be up-to-date. Presumably there is one
that isn't, but which?

Cheers,
Dave P.

[Dave Yeo]

Dave Parsons wrote:
> Hi Dave,
>
> On 24-02-16 04:01, Dave Yeo wrote:
>>> At the moment FF just produces beeps. With an adjust PM DLL STARTUPDIR
>>> to use the right "." directory, PM DLL claims PLUGIN-CONTAINER.EXE
>>> cannot load STDCPP6.DLL.
>>
>> Have you got the most recent STDCPP6.DLL, IIRC it has been updated along
>> with the GCC* DLLs. New one will work for where the old one was needed.
>
>
>> You need gcc1.dll along with its various forwarders such as
>> gcc473.dll, not the original gcc473.dll. Turns out all the GCC dlls
>> are interchangeable and should have been GCC1.DLL to start with.
>>
>
> The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
> dated 2 Feb 2015.
> Do you mean newer than these?

Mine are all from 2 Feb 2015.

>
> I am also trying to get FF 38.2.1 to work but at the moment it starts
> to load & after about 5 seconds or so it beeps and quits.
> There was nothing on the screen but it produced a TRP file and output
> via stdout/stderr these few lines:-
>
>> Fontconfig error: Cannot load default config file
>> DIVE is disabled - Panorama's shadow-buffer is enabled
>> Fontconfig error: Cannot load default config file
>> Fontconfig error: Cannot load default config file
>> Fontconfig error: Cannot load default config file
>> Fontconfig warning: ignoring en_GB_EURO: not a valid region tag

What is your codepage and LANG settings?

>> Fontconfig error: Cannot load default config file
>> Fontconfig error: Cannot load default config file
>> Fontconfig error: Cannot load default config file
>> Fontconfig error: Cannot load default config file
>> Creating 031E_01.TRP
>>
>> Killed by SIGSEGV
>
> Any idea which file it is referring to?
>
> The TRP file says it is trying to read from 00000018 & shows this:-
>
> Call Stack
> ______________________________________________________________________
>
> EBP Address Module Obj:Offset Nearest Public Symbol
> -------- --------- -------- ------------- -----------------------
> Trap -> 0E04991E XUL 0001:00D0991E nsExpirationTracker.h#34
> __ZN17gfxPangoFontGroup17GetFirstValidFontEj + 21E 0001:00D09700
> (D:\Coding\mozilla\master\gfx\thebes\gfxPangoFonts.cpp)
>
> Lost Stack chain - invalid EBP 40000000
>
> I've been round all the DLLs mentioned in the readme and a few which
> aren't and they all seem to be up-to-date. Presumably there is one
> that isn't, but which?
>

How did you install Fontconfig? By default it needs to be installed in
@UNIXROOT/usr, @UNIXROOT/etc and @UNIXROOT/var.
It should also work with everything installed in %HOME%, need to test
though.
What happens if you run fc-list.exe (the fc-* executables should be on
the PATH).Running fc-cache.exe --verbose is another test you can do.
Should show where it is looking for its configuration.
Dave

[Andreas Kohl]

Dave Parsons schrieb:

> The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
> dated 2 Feb 2015.
> Do you mean newer than these?

There's nothing newer.

> I am also trying to get FF 38.2.1 to work but at the moment it starts
> to load & after about 5 seconds or so it beeps and quits.
> There was nothing on the screen but it produced a TRP file and output
> via stdout/stderr these few lines:-
>
>> Fontconfig error: Cannot load default config file
>

> Any idea which file it is referring to?

Path for fontconfig seems to hard coded to a location under /usr/share/...

> I've been round all the DLLs mentioned in the readme and a few which
> aren't and they all seem to be up-to-date. Presumably there is one
> that isn't, but which?

You also need dll files that are not mentioned in README.OS2. At least
EXPAT7.DLL, INTL8.DLL (from gettext).

--
Andreas

[David Parsons]

On 02/25/16 17:53, Andreas Kohl wrote:
>
> You also need dll files that are not mentioned in README.OS2. At least
> EXPAT7.DLL, INTL8.DLL (from gettext).

Yes, thanks Andreas I saw those in an earlier post here. I only need
to add INTL8.

Dave P.

[ivan]

On Thu, 25 Feb 2016 16:53:18 UTC, Andreas Kohl <ak...@arcor.de> wrote:

> Dave Parsons schrieb:
> > The latest versions of stdcpp6, gcc1 & gcc473 that I can find are all
> > dated 2 Feb 2015.
> > Do you mean newer than these?
> There's nothing newer.
>
> > I am also trying to get FF 38.2.1 to work but at the moment it starts
> > to load & after about 5 seconds or so it beeps and quits.
> > There was nothing on the screen but it produced a TRP file and output
> > via stdout/stderr these few lines:-
> >
> >> Fontconfig error: Cannot load default config file
> >
> > Any idea which file it is referring to?
>
> Path for fontconfig seems to hard coded to a location under /usr/share/...

That makes it very dificult for those of us that don't have a
?:\usr\share directory on our systems, or %unixroot% for that matter.

Now the question arrises, what is fontconfig used for and why would I
tell our clients that we need to put (install) it on their computers?

Does anything else use it other than firefox?

>
> > I've been round all the DLLs mentioned in the readme and a few which
> > aren't and they all seem to be up-to-date. Presumably there is one
> > that isn't, but which?
>
> You also need dll files that are not mentioned in README.OS2. At least
> EXPAT7.DLL, INTL8.DLL (from gettext).
>
> --
> Andreas
>

ivan
--

[Dave Yeo]

ivan wrote:
>>>> > >>Fontconfig error: Cannot load default config file
>>> > >
>>> > >Any idea which file it is referring to?
>> >
>> >Path for fontconfig seems to hard coded to a location under/usr/share/...
> That makes it very dificult for those of us that don't have a
> ?:\usr\share directory on our systems, or %unixroot% for that matter.

It's possible for it to use %HOME%, at that it used to be used that way.
Here fc-cache seems to have this search order,
R:\tmp>fc-cache -v
N:/OS2/OS2.INI: skipping, existing cache is valid: 140 fonts, 0 dirs
/@unixroot/usr/local/share/fonts: skipping, no such directory
/@unixroot/usr/share/fonts: skipping, no such directory
F:/home/dave/.local/share/fonts: skipping, no such directory
F:/home/dave/.fonts: skipping, no such directory
/@unixroot/var/cache/fontconfig: cleaning cache directory
F:/home/dave/.cache/fontconfig: not cleaning non-existent cache directory
F:/home/dave/.fontconfig: not cleaning non-existent cache directory
K:\usr\bin\fc-cache.exe: succeeded

I need to experiment.

>
> Now the question arrises, what is fontconfig used for and why would I
> tell our clients that we need to put (install) it on their computers?

It's used to catalog the fonts on the system and find the best match.
It' actually a pretty powerful utility.

>
> Does anything else use it other than firefox?

Many *nix ports use it. Firefox has been using it since 3.6 IIRC, first
fontconfig 2.3.2, then Peter and Doodle wrote the OS/2 specific
mzfntcfg, which was sorta a stripped down Fontconfig to get away from
the configuration stuff. Now Firefox's font handling stuff has changed
enough that mzfntcfg doesn't handle it and we've gone back to the real
Fontconfig.
Dave

[Dave Yeo]

ivan wrote:
>>> > >I am also trying to get FF 38.2.1 to work but at the moment it starts
>>> > >to load & after about 5 seconds or so it beeps and quits.
>>> > >There was nothing on the screen but it produced a TRP file and output
>>> > >via stdout/stderr these few lines:-
>>> > >
>>>> > >>Fontconfig error: Cannot load default config file
>>> > >
>>> > >Any idea which file it is referring to?
>> >
>> >Path for fontconfig seems to hard coded to a location under/usr/share/...
> That makes it very dificult for those of us that don't have a
> ?:\usr\share directory on our systems, or %unixroot% for that matter.

You can use %FONTCONFIG_FILE% to point to fonts.conf and fonts.conf can
point somewhere other then @UNIXROOT/usr.
Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed in the
INI files.
Dave

[Dave Parsons]

On 25-02-16 17:26, Dave Yeo wrote:

> Dave Parsons wrote:
>> I've been round all the DLLs mentioned in the readme and a few which
>> aren't and they all seem to be up-to-date. Presumably there is one
>> that isn't, but which?
>>
>
> How did you install Fontconfig? By default it needs to be installed in
> @UNIXROOT/usr, @UNIXROOT/etc and @UNIXROOT/var.
> It should also work with everything installed in %HOME%, need to test though.
> What happens if you run fc-list.exe (the fc-* executables should be on the
> PATH).Running fc-cache.exe --verbose is another test you can do. Should show
> where it is looking for its configuration.
> Dave

Thanks Dave. I didn't use UNIXROOT previously and I only copied across the
dlls from \usr\lib.

Setting UNIXROOT and copying everything across got rid of the error messages
and fixed the crash.

Initial assessment, everything seems to work, fonts look a little better but
r followed by n still looks like m if displayed in bold.

However it hangs briefly when scrolling up & down with the mouse wheel on some
pages. It is particularly bad on http://www.bbc.com/news loading all the little
images. 31.8.0 does not have this problem.

Dave P.

[ivan]

On Fri, 26 Feb 2016 04:50:11 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Thanks for that Dave. I will set up our test WSeB machine this
evening and see what happens.

ivan
--

[Dave Yeo]

Dave Parsons wrote:
> On 25-02-16 17:26, Dave Yeo wrote:
>> Dave Parsons wrote:
>>> I've been round all the DLLs mentioned in the readme and a few which
>>> aren't and they all seem to be up-to-date. Presumably there is one
>>> that isn't, but which?
>>>
>>
>> How did you install Fontconfig? By default it needs to be installed in
>> @UNIXROOT/usr, @UNIXROOT/etc and @UNIXROOT/var.
>> It should also work with everything installed in %HOME%, need to test
>> though.
>> What happens if you run fc-list.exe (the fc-* executables should be on
>> the
>> PATH).Running fc-cache.exe --verbose is another test you can do.
>> Should show
>> where it is looking for its configuration.
>> Dave
>
> Thanks Dave. I didn't use UNIXROOT previously and I only copied across the
> dlls from \usr\lib.
>
> Setting UNIXROOT and copying everything across got rid of the error
> messages
> and fixed the crash.

As mentioned in a sibling post, it is possible to point at fonts.conf
with an environmental variable, patch fonts.conf and not use @UNIXROOT

>
> Initial assessment, everything seems to work, fonts look a little better
> but
> r followed by n still looks like m if displayed in bold.

Fontconfig is also very configurable.
http://www.freedesktop.org/software/fontconfig/fontconfig-user.html

>
> However it hangs briefly when scrolling up & down with the mouse wheel
> on some
> pages. It is particularly bad on http://www.bbc.com/news loading all the
> little
> images. 31.8.0 does not have this problem.

Haven't really noticed this, perhaps partially due to using no-script. I
do see some heavy CPU usage displaying some scripts.
This is a bit of a weird version and hopefully the next upload will be
better.
Dave

[Dave Yeo]

You will also need some of the utility programs such as fc-cache.exe on
the PATH, fc-list.exe is also handy to see which fonts Fontconfig found.
I also used *nix path separator, / to point at fonts.conf.
There's also %FONTCONFIG_PATH% which is supposed to point to the default
configuration directory, untested here.
http://www.freedesktop.org/software/fontconfig/fontconfig-user.html
Let us know how you make out
Dave

[A.D. Fundum]

> You can use %FONTCONFIG_FILE% to point to fonts.conf

By default there's no file called fonts.conf.

> and fonts.conf can point somewhere other then @UNIXROOT/usr.
> Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
> in the INI files.

So, should a file fonts.conf be created and should it typically
contain the text "<dir>OS2FONTDIR</dir>"?


With SM the crash seems to be related to fonts (GetFirstValidFont)
indeed, FWIW.

Filename: XUL.DLL 02/18/2016 22:46:13 38,343,417
Address: 005B:0EF8BD73 (0001:0106BD73)
Cause: Attempted to read from 00000018
(not a valid address)

Trap -> 0EF8BD73 XUL 0001:0106BD73 between
gfxPangoFontGroup::GetFirstValidFont + 213 and
gfxDownloadedFcFontEntry::InitPattern - 11D (both in
gfxPangoFonts.cpp)

0013BB08 1080887D XUL 0001:028E887D between
NS_NewListBoxBodyFrame + 17D and nsListBoxBodyFrame::operator new - 13
(both in Unified_cpp_layout_xul1.cpp)


--

[A.D. Fundum]

>> The glib ZIP package is mentioned in README.OS2,
>> but its GTHR2.DLL isn't.

> gthreads are part of glib2 and really should be in the same zip.

Yes, but initially I only installed DLLs mentioned in README.OS2

> The new freetype dll should work with the last few releases
> and co-exist with the mzfntcfgft DLLs

Allright.

>> The PLUGIN-CONTAINER.EXE also cannot load MOZALLOC.DLL,
>> NSS3.DLL, PTHR01.DLL, SSL3.DLL, MMAP.DLL, PIXMAN10.DLL,
>> MOZSQLT3.DLL, CAIRO2.DLL, PANGO100.DLL, KAI0.DLL, and
>> SMIME3.DLL.

> Most of those are mozilla DLLs and Mozilla can find them by itself.

Now PM DLL claims that FF can load all DLLs. Maybe it was a PM DLL
bug.

> What you should point PMDLL at is XUL.DLL which will show
> you all the needed DLLs and with SeaMonkey running the
> only ones in red are the Mozilla ones.

I've pointed PM DLL at all DLLs and EXEs. PLUGIN-CONTAINER.EXE was (?)
the only one with red names. Out-of-the-box FF nor SM works. So far I
haven't seen red entries with SM, but that may be related to your
appriciated efforts w.r.t. static linking.

PM DLL tips & tricks, possibly outdated: the "." is in my LIBATH. With
PM DLL v2.11, a PM DLL program object assumes that "." is the PM DLL
directory instead of the directory of an examined DLL/EXE. I do change
the "working directory" (STARTUPDIR) to the directory of FF/SM first ,
so "." represents the relevant directory and PM DLL won't show red
entries. Of course PM DLL's interpretation of "." is technically
right, but there's no reason to presume that PM DLL's directory is a
better and more relevant choice than the directory of an examined
DLL/EXE. I haven't checked v2.12 yet, but otherwise a drag & drop
wrapper could be written to use the directory of the dropped DLL/EXE
instead of PM DLL's (should be quite easy with e.g. VX-REXX if VX-REXX
can execute PM DLL, FWW).


--

[Dave Yeo]

A.D. Fundum wrote:
> > You can use %FONTCONFIG_FILE% to point to fonts.conf
>
> By default there's no file called fonts.conf.

I uploaded the full FONTCONFIG package to my bitbucket page,
https://bitbucket.org/dryeo/dry-comm-esr31/downloads/fontconfig-2.11.94-1.oc00.i686.zip

>
> > and fonts.conf can point somewhere other then @UNIXROOT/usr.
> > Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
> > in the INI files.
>
> So, should a file fonts.conf be created and should it typically
> contain the text "<dir>OS2FONTDIR</dir>"?

The default one should the one installed with fontconfig

>
>
> With SM the crash seems to be related to fonts (GetFirstValidFont)
> indeed, FWIW.
>
> Filename: XUL.DLL 02/18/2016 22:46:13 38,343,417
> Address: 005B:0EF8BD73 (0001:0106BD73)
> Cause: Attempted to read from 00000018
> (not a valid address)
>
> Trap -> 0EF8BD73 XUL 0001:0106BD73 between
> gfxPangoFontGroup::GetFirstValidFont + 213 and
> gfxDownloadedFcFontEntry::InitPattern - 11D (both in
> gfxPangoFonts.cpp)
>
> 0013BB08 1080887D XUL 0001:028E887D between
> NS_NewListBoxBodyFrame + 17D and nsListBoxBodyFrame::operator new - 13
> (both in Unified_cpp_layout_xul1.cpp)

Yes, that is the broken fontconfig crash.
Fontconfig also comes with some utility programs that should probably be
installed on the PATH. fc-list.exe will show all fonts that fontconfig
is aware of.
Dave

[Dave Yeo]

A.D. Fundum wrote:
> I've pointed PM DLL at all DLLs and EXEs. PLUGIN-CONTAINER.EXE was (?)
> the only one with red names. Out-of-the-box FF nor SM works. So far I
> haven't seen red entries with SM, but that may be related to your
> appriciated efforts w.r.t. static linking.

It was actually more of an accident. Given more bandwidth, I would
produce 2 binaries with one being mostly statically linked

>
> PM DLL tips & tricks, possibly outdated: the "." is in my LIBATH. With
> PM DLL v2.11, a PM DLL program object assumes that "." is the PM DLL
> directory instead of the directory of an examined DLL/EXE. I do change
> the "working directory" (STARTUPDIR) to the directory of FF/SM first ,
> so "." represents the relevant directory and PM DLL won't show red
> entries. Of course PM DLL's interpretation of "." is technically
> right, but there's no reason to presume that PM DLL's directory is a
> better and more relevant choice than the directory of an examined
> DLL/EXE. I haven't checked v2.12 yet, but otherwise a drag & drop
> wrapper could be written to use the directory of the dropped DLL/EXE
> instead of PM DLL's (should be quite easy with e.g. VX-REXX if VX-REXX
> can execute PM DLL, FWW).

I'm pretty sure that Mozilla doesn't use the "." or Libpath at all
besides finding system DLLs (including the RPM ones). Note that
SeaMonkey still has one DLL (suite.dll) under components and if the
lightning extension is installed (automatic now), there is a DLL under
the extensions directory.
Fontconfig also has code to find where the DLL is installed and find its
configuration that way but our port is not linked against DLL_INIT (or
is that DLL_TERM?) so doesn't work on OS/2.
Dave

[A.D. Fundum]

> I uploaded the full FONTCONFIG package to my bitbucket
> page

Brilliant! Now FF worked at least once, after adding the missing
readme.os2 DLLs (original posting) to a LIBPATH directory and after
typing the magic words SET FONTCONFIG_FILE=N:/OUNIX/fonts.conf
(unmodified copy from your package).

Next I'll give SM a try, after a reboot, but with a working FF the
hard labour should be over (yes, famous last words) by now.

The missing fonts.conf file was probably the generic reason why FF
originally didn't work, with several right or wrong reports w.r.t.
unloadable DLLs.

Thanks, Dave.


--

[A.D. Fundum]

> I'm pretty sure that Mozilla doesn't use the "." or Libpath at all

Restricted to the ".", the real "." can be anything indeed. In this
case a better description perhaps is that the "." represents a sane
working directory of an app, but that third-party software which
checks DLLs may ignore the likely use of that directory.

If e.g. PM DLL claims that SEAMONKEY.EXE cannot load SM's XUL.DLL,
then PM DLL is right nor wrong. Typically SEAMONKEY.EXE will be able
to load XUL.DLL in the same SM directory, so PM DLL could show a
conditional warning instead of an error because it assumes that the
(variable) "." is the current directory of SM.

I still may try to write a drop target which assumes that a "."
represents the directory of the dropped DLL/EXE, regardless of the
LIBPATH, so PM DLL can report that A:\TEST.EXE can load A:\TEST.DLL by
using its directory A:\ instead of PM DLL's C:\UTILS\PMDLL. So I'll CD
to A:\, and then execute "C:\UTILS\PMDLL\PMDLL.EXE A:\TEST.EXE".

> our port is not linked against DLL_INIT (or is that DLL_TERM?)

Yes, if the "or" is not an XOR. It's all of the above: DLL_InitTerm


--

[A.D. Fundum]

> Given more bandwidth, I would produce 2 binaries with one
> being mostly statically linked

FWIW, with my setup the damage is already done by FF. FF (mainly
evaluation) >= SM (mainly production), so an awful lot of DLLs already
made it to my LIBPATH now.

So next time it may be harder to report undocumented, required DLLs,
because there's more "polution" in my LIBPATH than before this
dynamically linked version of FF.

FWIW/2, an older version of QupZilla stopped working. IIRC due to an
updated GCC* DLL. Upgrading QupZilla to v1.8.0 solved that minor issue
(newer versions of QupZilla required yet another unclear package). So
far that was the only derived issue (without using some test policy).


--

[Dave Yeo]

A.D. Fundum wrote:
> The missing fonts.conf file was probably the generic reason why FF
> originally didn't work, with several right or wrong reports w.r.t.
> unloadable DLLs.

By itself, the missing fonts.conf causes a crash with a certain trp file
rather then unloadable DLLs so there must have been something else missing
Dave

[A.D. Fundum]

>> with several right or wrong reports w.r.t. unloadable DLLs.

> By itself, the missing fonts.conf causes a crash with a certain trp
> file rather then unloadable DLLs so there must have been
> something else missing

I didn't notice it immediately, but PM DLL itself created a TRP file
too, between install attempts. At that stage FF/SM produced the
"expected" missing-fonts.conf beeps.

An old SM-specific problem is solved too, by upgrading. Checking for
new mail (handshake) was extremely slow when the previous version was
used, with a honest Windows'ish 100% CPU load during several seconds.
So far I also haven't seen rare, possibly related, mail server error
messages while sending mails anymore.


--

[A.D. Fundum]

> Note that <dir>OS2FONTDIR</dir> actually loads the fonts listed
> in the INI files.

FONTCONFIG-related RFC: with OS2FONTDIR in use, it creates a directory
called @UNIXROOT in de root directory of the SM/FONTCONFIG/fonts.conf
drive. Would it be posible to use %TMP%, %TEMP% or the directory of
fonts.conf (e.g. C:\TOOLS\FONTSCONFIG\...) to create some cache file?

Maybe %UNIXROOT% could be used, but I'm not using %UNIXROOT% and I
don't want other apps to assume that I'm using such a file structure.
Now only FONTCONFIG is. I don't know how this cache file is (re?)used,
so I don't know if %TMP% or %TEMP% is a good choice.


--

[Dave Yeo]

Look in fonts.conf for the section "Font cache directory list" and add
where you want the cache. The usual for user set cache is in %HOME% but
should work anywhere.
fc-cache.exe can be used to rebuild the cache, use --help to see various
settings.
The other fc-*.exe can be useful as well and should probably be on the PATH
Dave

[ivan]

On Mon, 29 Feb 2016 15:18:25 UTC, "A.D. Fundum" <what...@neverm.ind>
wrote:

We got round the problem of updating DLLs by having a dedicated DLL
directory in which to put them. We have a backup of that directory
from when we knew all the programs we use work, thus if when the DLLs
are 'updated' and something we use stops working we blowaway the dir
and restore from backup. So far that has not failed but I expect
there will come a time when we will have to use drastic measures to
keep everything working.


--

[Andreas Kohl]

Am 01.03.16 um 16.44 schrieb Dave Yeo:

> Look in fonts.conf for the section "Font cache directory list" and add
> where you want the cache. The usual for user set cache is in %HOME% but
> should work anywhere.

At least almost. Without a setting for UNIXROOT it could be become more
complicated.

> fc-cache.exe can be used to rebuild the cache, use --help to see various
> settings.
> The other fc-*.exe can be useful as well and should probably be on the PATH

From my observation also fc-list.exe causes the cache to be rebuilt. So
you don't have to restart for instance seamonkey or firefox to use a
newly installed font. I don't keep them on the PATH but thats only a
matter of taste. They only need to find the dll files in LIBPATH.

--
Andreas

[Dave Yeo]

Andreas Kohl wrote:
>> fc-cache.exe can be used to rebuild the cache, use --help to see various
>> settings.
>> The other fc-*.exe can be useful as well and should probably be on the
>> PATH
>
> From my observation also fc-list.exe causes the cache to be rebuilt. So
> you don't have to restart for instance seamonkey or firefox to use a
> newly installed font. I don't keep them on the PATH but thats only a
> matter of taste. They only need to find the dll files in LIBPATH.

fc-list does not trigger a cache rebuild here. So far I've only seen
cache rebuilds when changing systems, eg rebooting to Warp or eCS.
I haven't added any fonts yet.
Dave

[A.D. Fundum]

> a drag & drop wrapper could be written to use the directory
> of the dropped DLL/EXE instead of PM DLL's

Done, FWIW: /pub/incoming/whatisthedot.zip @ Hobbes (8 KiB).

With e.g. SM's XUL.DLL it will often reduce the number of PM DLL's red
errors by using the directory of XUL.DLL as PM DLL's working
directory. It's quite common that a DLL can be found in the same
non-LIBPATH directory.

Animals were harmed during the production, but I have nothing to do
with that.


--