Firefox 24 DLLs

[t***@antispam.ham]

I've encountered enough web sites that need more than Firefox 10 can
provide, so I've decided to give Firefox 24 a try.

I've always enjoyed the freedom to put files where I want them, so I
don't use RPM/YUM, yet the installation instructions for Firefox 24
only point to .rpm versions of the required DLLs. I've looked in the
netlabs release/00/zip directory for zipped versions of these files,
but I don't see libstdc++ among them, which appears to be a showstopper.

Is there some place where I can find all the DLLs required by Firefox 24
in a form that doesn't force me to install RPM/YUM?

[Marcel Mueller]

Post by t***@antispam.ham
Is there some place where I can find all the DLLs required by Firefox 24
in a form that doesn't force me to install RPM/YUM?

pstat says:

D:\OS2APP\FIREFOX\FIREFOX.EXE 004F 1A D:\OS2\DLL\LIBC065.DLL*
D:\OS2\DLL\PMWIN.DLL*
D:\OS2\DLL\DOSCALL1.DLL*
D:\OS2\DLL\STDCPP6.DLL*
D:\OS2\DLL\GCC473.DLL*

PMWIN and DOSCALL1 are from OS/2. The others the required C/C++ runtime
libraries.

There are WarpIn packages available.
- kLIBC contains LIBC06x
- GCC4 contains STDCPP6 and GCC473 among others. (This is not the
compiler, just the runtime libraries.)


Marcel

[Steven Levine]

On Sun, 28 Jun 2015 09:57:58 UTC, Marcel Mueller
<***@spamgourmet.org> wrote:

HI Marcel,

Post by Marcel Mueller
D:\OS2APP\FIREFOX\FIREFOX.EXE 004F 1A D:\OS2\DLL\LIBC065.DLL*
D:\OS2\DLL\PMWIN.DLL*
D:\OS2\DLL\DOSCALL1.DLL*
D:\OS2\DLL\STDCPP6.DLL*
D:\OS2\DLL\GCC473.DLL*

Interesting. You learn something new everyday. I never realized that
pstat appears to be incapable of listing all the DLLs used by an app.

If you need the extra DLLs, grab

firefox-24.8.1.en-us.os2.beta_4_extra_dlls

from Hobbes as documented at the various OS/2 for Mozilla support
sites.

Steven

[Dave Yeo]

Post by Steven Levine
On Sun, 28 Jun 2015 09:57:58 UTC, Marcel Mueller
HI Marcel,

Post by Marcel Mueller
D:\OS2APP\FIREFOX\FIREFOX.EXE 004F 1A D:\OS2\DLL\LIBC065.DLL*
D:\OS2\DLL\PMWIN.DLL*
D:\OS2\DLL\DOSCALL1.DLL*
D:\OS2\DLL\STDCPP6.DLL*
D:\OS2\DLL\GCC473.DLL*

Interesting. You learn something new everyday. I never realized that
pstat appears to be incapable of listing all the DLLs used by an app.
If you need the extra DLLs, grab
firefox-24.8.1.en-us.os2.beta_4_extra_dlls
from Hobbes as documented at the various OS/2 for Mozilla support
sites.

These should also cover FF31 except the addition of libkai-1.1.4.zip
(currently in Hobbes incoming) or the RPM that I'm sure is in the
pipeline. (Still possible that changes will happen)
Dave

[t***@antispam.ham]

Post by Dave Yeo
These should also cover FF31 except the addition of libkai-1.1.4.zip
(currently in Hobbes incoming) or the RPM that I'm sure is in the
pipeline. (Still possible that changes will happen)

I didn't see any reference to FF31 on github. I assume that it's in
development. Any target date for availability?

I'm also curious as to whether 24.8.1 will be finalized (currently
beta 4) before 31 is released. Sort of a moving target. Looks like
one version is never finalized before efforts move on to a later
version. I have a tendency to stick with what works for a very long
time until incompatibilities force an upgrade.

[Dave Yeo]

Post by t***@antispam.ham

Post by Dave Yeo
These should also cover FF31 except the addition of libkai-1.1.4.zip
(currently in Hobbes incoming) or the RPM that I'm sure is in the
pipeline. (Still possible that changes will happen)

I didn't see any reference to FF31 on github. I assume that it's in
development. Any target date for availability?

Hopefully in the next week or two. It runs but has issues

Post by t***@antispam.ham
I'm also curious as to whether 24.8.1 will be finalized (currently
beta 4) before 31 is released. Sort of a moving target. Looks like
one version is never finalized before efforts move on to a later
version. I have a tendency to stick with what works for a very long
time until incompatibilities force an upgrade.

Development has moved to 31 (and really should move to 38 but that will
probably be next year based on past performance).
Unluckily the web keeps moving on, security holes are found in older
versions and there are more and more changes between versions. I think
FF will be at version 40 next release.
Dave

[t***@antispam.ham]

Post by Steven Levine
If you need the extra DLLs, grab
firefox-24.8.1.en-us.os2.beta_4_extra_dlls
from Hobbes as documented at the various OS/2 for Mozilla support
sites.

Well, it's not mentioned in the README.OS2 file included in the
downloaded beta 4 zip file. Nor it is mentioned on the github page
for the 24.8.1 beta 4. The latter does have a "Last Minute Update"
that says there are three more DLLs required that aren't mentioned
in the README.OS2 file (!), but the provided links are all to RPM
versions.

But thanks for the pointer to hobbes. Should have thought to look
there in the first place. I have a tendency to rely on Google
searches nowadays, but the references provided to DLLs with the same
name all seemed to be in connection with Windows. I assume that a
Windows version of a DLL isn't going to work on an OS/2 system.

I do have a question about the LIBC***.DLL files. My system
already has LIBC063.DLL and LIBC065.DLL files. The ones in the
extra_dlls file from Hobbes are much smaller in size. It's been
years since I recall seeing some discussion about that, but am I
correct that the new LIBC065.DLL file simply contains a "pointer"
to the LIBC066.DLL file? So any existing application that tries
to load LIBC065.DLL will be able to load the necessary code from
LIBC066.DLL? Ditto for the LIBC063.DLL? Without that knowledge,
one might worry about a new LIBC065.DLL that is much smaller
breaking existing code. In a file listing of LIBC065.DLL, I do see

LIST 2048 25% 06/29/;5 01:54  c:\LIBC065.DLL
007FF0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
008000 38 6B 4C 49 42 43 20 76 65 72 73 69 6F 6E 20 30 8kLIBC version 0
008010 2E 36 2E 36 20 28 42 69 72 64 20 42 75 69 6C 64 .6.6 (Bird Build
008020 20 32 30 31 34 2D 31 30 2D 32 36 20 31 38 3A 35 2014-10-26 18:5
008030 33 20 28 63 73 64 36 29 29 00 00 0F 5F 5F 5F 64 3 (csd6)) ___d

so there is some sort of reference to 066 in the 065 file. Just
noticed that LIST seems to have trouble with displaying the year.

[Dave Yeo]

Post by t***@antispam.ham
I do have a question about the LIBC***.DLL files. My system
already has LIBC063.DLL and LIBC065.DLL files. The ones in the
extra_dlls file from Hobbes are much smaller in size. It's been
years since I recall seeing some discussion about that, but am I
correct that the new LIBC065.DLL file simply contains a "pointer"
to the LIBC066.DLL file? So any existing application that tries
to load LIBC065.DLL will be able to load the necessary code from
LIBC066.DLL? Ditto for the LIBC063.DLL? Without that knowledge,
one might worry about a new LIBC065.DLL that is much smaller
breaking existing code.

Yes, the older (libc061-libc065) DLLs are just forwarders to libc066 so
older programs can benefit from bug fixes. Make sure that you only have
the one set installed.
Dave

[t***@antispam.ham]

ALong those same lines, I just noticed a potentially more serious
conflict. My system already has:

13-05-01 23.31 81.654 0 a--- fntcfg2.dll

whereas the new version from Hobbes is:

15-06-29 1.54 43.188 0 a--- FNTCFG2.DLL

That is, the new FNTCFG2 is a lot smaller than the old FNTCFG2.
But no "pointer" file to a superset file like LIB066. Is
replacing the old with the new going to break other code?
What would happen in Firefox 24 if I kept the old FNTCFG2,
which seems to have more stuff in it?

[Dave Yeo]

Post by t***@antispam.ham
ALong those same lines, I just noticed a potentially more serious
13-05-01 23.31 81.654 0 a--- fntcfg2.dll
15-06-29 1.54 43.188 0 a--- FNTCFG2.DLL
That is, the new FNTCFG2 is a lot smaller than the old FNTCFG2.
But no "pointer" file to a superset file like LIB066. Is
replacing the old with the new going to break other code?
What would happen in Firefox 24 if I kept the old FNTCFG2,
which seems to have more stuff in it?

It's the same code, different version of GCC used to compile and perhaps
ran through lxlite. Should be fine. Whenever the API is updated, the
name should change.
Note that freetype has changed as you can see by the different DLL name.
Dave

[Marcel Mueller]

Post by t***@antispam.ham
ALong those same lines, I just noticed a potentially more serious
13-05-01 23.31 81.654 0 a--- fntcfg2.dll
15-06-29 1.54 43.188 0 a--- FNTCFG2.DLL
That is, the new FNTCFG2 is a lot smaller than the old FNTCFG2.
But no "pointer" file to a superset file like LIB066.

Usually different LX image compression modes.


Marcel

[t***@antispam.ham]

Well, it turns out that the hobbes extra_dlls files does NOT
represent one-stop shopping for all the extra DLLs required
by Firefox 24.8.1 beta 4. After copying those files somewhere
in my LIBPATH, Firefox complained about needing GCC1. So I
found that at netlabs.org and added it. Then Firefox
complained about needing GCC473, and that was in the same
archive as GCC1, so I added it. Now Firefox starts to load,
but then pops up a window saying it also needs XUL.DLL. A
search of hobbes didn't turn that one up. The github page
for 24.8.1 beta 4 mentions that XUL.DLL is finally loadable
into high memory using "this tool" which is a link to a
dropbox account, which returns 404 Not Found. Nor do I see
it in the netlabs zip archive. So once again I'm stuck.

Where is XUL.DLL?

[t***@antispam.ham]

Ack! Okay, so XUL.DLL is included in the 24.8.1 beta 4 zip archive!
(Wish everything you need was included in the archive, but I gather
that there are licensing issues that prevent that.)

But the error message is that it couldn't load XUL.DLL, not that it
couldn't find it. I guess it involves the "this tool" broken link
that enables it to go into high memory. At least I know where XUL.DLL
can be found, but I'm still stuck. It won't load, and Firefox won't
work.

[Steven Levine]

On Mon, 29 Jun 2015 02:55:09 UTC, ***@antispam.ham wrote:

Hi,

Post by t***@antispam.ham
Ack! Okay, so XUL.DLL is included in the 24.8.1 beta 4 zip archive!
(Wish everything you need was included in the archive, but I gather
that there are licensing issues that prevent that.)

Not really. It's more about avoiding corrupting working system that
may have already installed updated versions of the dependent DLLs.

For example, while I know abou the extra DLLs zip file, I don't
actually need it because the DLLs it includes are already installed
for other apps that I use.

Post by t***@antispam.ham
But the error message is that it couldn't load XUL.DLL, not that it
couldn't find it.

You are still missing a DLL XUL.DLL requires. PMDLL.EXE or CHKDLL32
should tell you which DLL you need. Run it for FIREFOX.EXE and
XUL.DLL.

Post by t***@antispam.ham
I guess it involves the "this tool" broken link

Unlikely. It's also unlikely you will be able to use HIGHMEM.EXE when
you do download it. You tend to avoid keeping your systems current,
so it's unlikely you have the prerequisite kernel installed.

Steven

[t***@antispam.ham]

Post by Steven Levine
Unlikely. It's also unlikely you will be able to use HIGHMEM.EXE when
you do download it. You tend to avoid keeping your systems current,
so it's unlikely you have the prerequisite kernel installed.

When it comes to OS/2, the whole concept of a "current" system seems
a little strange, considering how long ago support ended for the
operating system. My desktop runs Warp 4.52 with the last fixpack
issued by IBM, so it is as "current" as real OS/2 is going to get as
far as the operating system is concerned. Sure, there are lots of
applications out there that require add-ons, and I won't have those
if I don't use those applications, but if you want to consider
applications in the context of "currentness", then nobody has a
"current" system because they don't have applications that I do have.
One such application is a WAV file editor, which makes use of high
memory; I recently edited a recording that allocated over 1.3 GB of
memory. Whether that is the same high memory capability kernel that
allows Firefox to load XUL.DLL into high memory, I don't know.

I also have a laptop running eCS 2.0, and I've tested the eCS 2.2 beta
on an even newer laptop that normally runs Windows 7. I even reported
the issues that I noticed during that test, but that was years ago, and
I have little confidence that eCS 2.2 will ever see the light of day.

But yes, I am reluctant to upgrade simply for the sake of trying to be
"current", because I've run into too many cases of "upgrades" breaking
existing applications. I even have an older 64-bit laptop still running
32-bit Windows XP, simply because when support ended, I ran a tool that
Microsoft provided to test my existing applications for compatibility
with Windows 7. There were a whole bunch that were listed as "not
compatible". As a result, that particular system isn't "current", nor
do I intend to make it "current". And I wish Microsoft would stop
nagging about the lack of support for XP. If there are still security
holes, it's their own fault; they had over a decade to find and fix all
the security holes in XP. Which makes you question their ability to
make more recent versions of Windows any more secure.

So, my strategy has been to stay with what works. When it no longer
works, then I'll do what is necessary to try and make it work. Such
is the case with Firefox. I use web sites that are now incompatible
with Firefox 10, so I'm giving Firefox 24 a try. It would be nice if
updates to Firefox for OS/2 were as easy as they are for Windows.

[Dave Yeo]

Post by t***@antispam.ham

Post by Steven Levine
Unlikely. It's also unlikely you will be able to use HIGHMEM.EXE when
you do download it. You tend to avoid keeping your systems current,
so it's unlikely you have the prerequisite kernel installed.

When it comes to OS/2, the whole concept of a "current" system seems
a little strange, considering how long ago support ended for the
operating system. My desktop runs Warp 4.52 with the last fixpack
issued by IBM, so it is as "current" as real OS/2 is going to get as
far as the operating system is concerned. Sure, there are lots of
applications out there that require add-ons, and I won't have those
if I don't use those applications, but if you want to consider
applications in the context of "currentness", then nobody has a
"current" system because they don't have applications that I do have.
One such application is a WAV file editor, which makes use of high
memory; I recently edited a recording that allocated over 1.3 GB of
memory. Whether that is the same high memory capability kernel that
allows Firefox to load XUL.DLL into high memory, I don't know.

It's partially the same high memory capability. FF will allocate high
memory and HIGHMEM.EXE will mark the DLLs so they actually load in high
memory leaving much more low shared memory free.

Post by t***@antispam.ham
I also have a laptop running eCS 2.0, and I've tested the eCS 2.2 beta
on an even newer laptop that normally runs Windows 7.

The kernel that comes with the eCS beta is the one that works best when
loading DLLs high.
...

Post by t***@antispam.ham
So, my strategy has been to stay with what works. When it no longer
works, then I'll do what is necessary to try and make it work. Such
is the case with Firefox. I use web sites that are now incompatible
with Firefox 10, so I'm giving Firefox 24 a try. It would be nice if
updates to Firefox for OS/2 were as easy as they are for Windows.

Well if you follow the developers lead, 31ESR will be just a matter of
yum install firefox. Of course then you have to install the RPM/YUM
environment
Dave

[Dave Yeo]

Post by t***@antispam.ham
Well, it turns out that the hobbes extra_dlls files does NOT
represent one-stop shopping for all the extra DLLs required
by Firefox 24.8.1 beta 4. After copying those files somewhere
in my LIBPATH, Firefox complained about needing GCC1. So I
found that at netlabs.org and added it. Then Firefox
complained about needing GCC473, and that was in the same
archive as GCC1, so I added it. Now Firefox starts to load,
but then pops up a window saying it also needs XUL.DLL. A
search of hobbes didn't turn that one up. The github page
for 24.8.1 beta 4 mentions that XUL.DLL is finally loadable
into high memory using "this tool" which is a link to a
dropbox account, which returns 404 Not Found. Nor do I see
it in the netlabs zip archive. So once again I'm stuck.
Where is XUL.DLL?

In your Firefox directory. This actually means that there is another DLL
problem, possibly a gcc*dll hiding in \ecs\dll or \os2\dll.
The GCC dlls have changed and now most are forwarders to GCC1.
Look for duplicates and don't forget if another program comes with a
different version of one of these DLLs and if it is loaded before
Firefox, the system will attempt to use it for Firefox as well.
Personally I prefer to statically link but I'm not in charge and the
developers swear having separate DLLs is better.
Dave

[ivan]

Post by Dave Yeo

Post by t***@antispam.ham
Well, it turns out that the hobbes extra_dlls files does NOT
represent one-stop shopping for all the extra DLLs required
by Firefox 24.8.1 beta 4. After copying those files somewhere
in my LIBPATH, Firefox complained about needing GCC1. So I
found that at netlabs.org and added it. Then Firefox
complained about needing GCC473, and that was in the same
archive as GCC1, so I added it. Now Firefox starts to load,
but then pops up a window saying it also needs XUL.DLL. A
search of hobbes didn't turn that one up. The github page
for 24.8.1 beta 4 mentions that XUL.DLL is finally loadable
into high memory using "this tool" which is a link to a
dropbox account, which returns 404 Not Found. Nor do I see
it in the netlabs zip archive. So once again I'm stuck.
Where is XUL.DLL?

In your Firefox directory. This actually means that there is another DLL
problem, possibly a gcc*dll hiding in \ecs\dll or \os2\dll.
The GCC dlls have changed and now most are forwarders to GCC1.
Look for duplicates and don't forget if another program comes with a
different version of one of these DLLs and if it is loaded before
Firefox, the system will attempt to use it for Firefox as well.
Personally I prefer to statically link but I'm not in charge and the
developers swear having separate DLLs is better.
Dave

"Personally I prefer to statically link "
Hence the reason I prefer your builds - very little messing about,
unzip (or 7z) and run.

I hope you will make available your build of firefox when you finish
it.

ivan
--

[t***@antispam.ham]

In case someone is keeping tracking of which DLLs are missing from
the extra_dlls file on hobbes, they are GCC1, GCC473, and lastly Z,
the one that prevented XUL from loading. I wondered about a name
collision between that one and the Z MP3 player, but the MP3 player
uses the name Z!.DLL.

[Dave Yeo]

Post by t***@antispam.ham
In case someone is keeping tracking of which DLLs are missing from
the extra_dlls file on hobbes, they are GCC1, GCC473, and lastly Z,
the one that prevented XUL from loading. I wondered about a name
collision between that one and the Z MP3 player, but the MP3 player
uses the name Z!.DLL.

Z.DLL shouldn't be a dependency as far as I know. While Freetype will
use it (and bzip2) if you don't stop it, the RPM version doesn't. Of
course most people do probably have a version of zlib (z.dll) installed
and then a collision can come from EMX compiled ones.
Do you remember which, if any other DLL depended on zlib?
Dave

[t***@antispam.ham]

Post by Dave Yeo
Z.DLL shouldn't be a dependency as far as I know. While Freetype will
use it (and bzip2) if you don't stop it, the RPM version doesn't.

How can you stop something from using a DLL?

Post by Dave Yeo
Of
course most people do probably have a version of zlib (z.dll) installed
and then a collision can come from EMX compiled ones.
Do you remember which, if any other DLL depended on zlib?

Looking at the tree display of PMDLL, it shows Z being called from
FREETYP6. It also shows a second instance of Z being called from
PNG1616, which in turn was called from FREETYP6. The latter also
shows Z calling LIBC065 and GCC473.

So Z appears only in the FREETYP6 branches, but it both gets called
and calls other DLLs.

[Dave Yeo]

Post by t***@antispam.ham

Post by Dave Yeo
Z.DLL shouldn't be a dependency as far as I know. While Freetype will
use it (and bzip2) if you don't stop it, the RPM version doesn't.

How can you stop something from using a DLL?

Don't link against the DLL (actually the import lib, alternative is to
link against a static lib) when building, usually done by feeding the
right options to configure.

Post by t***@antispam.ham

Post by Dave Yeo
Of
course most people do probably have a version of zlib (z.dll) installed
and then a collision can come from EMX compiled ones.
Do you remember which, if any other DLL depended on zlib?

Looking at the tree display of PMDLL, it shows Z being called from
FREETYP6. It also shows a second instance of Z being called from
PNG1616, which in turn was called from FREETYP6. The latter also
shows Z calling LIBC065 and GCC473.

OK, I forgot about freetype linking against png which does really have a
dependency against zlib. Another weird decision as the freetype test
program doesn't actually work on OS/2 last I checked.
I think they're just blindly following the RPM specs from Redhat or such
and we're not *nix.
I'm curious about the 31.6 RPM they've built and how it installs.

Post by t***@antispam.ham
So Z appears only in the FREETYP6 branches, but it both gets called
and calls other DLLs.

And most people probably already have zlib installed as it is a very
common library.
I'll note that on Windows, which is closer to us then *nix, those GCC
DLLs are statically linked. Libc isn't statically linked due to
licencing reasons
Dave

[t***@antispam.ham]

Post by Dave Yeo

Post by t***@antispam.ham
How can you stop something from using a DLL?

Don't link against the DLL (actually the import lib, alternative is to
link against a static lib) when building, usually done by feeding the
right options to configure.

Oh; I see what you mean now. I was thinking along the lines of how
could you stop a program from using the code in a DLL. Without the
code, it would break some capability of the program. You're talking
about the method of loading the code, dynamically via a DLL or statically
by having all the code built-in to the executable.

I write a lot of number crunching programs using gfortran on Windows,
and although the versions I use usually rely on dynamic linking to
gfortran libraries, if I need to distribute a program to somebody else,
I'll link it statically. I've encountered too many problems with those
other users not being able to run copies of my executable because they
either don't have the needed libraries, or they're in the wrong place,
or they're the wrong version.

[t***@antispam.ham]

One of the reasons I wanted to try Firefox 24 is because the
Major League Baseball scoreboard at espn.com didn't like
Firefox 10. Sadly, it also doesn't like Firefox 24. Screen
elements aren't being positioned as they are in Firefox 38
on Windows, and CPU activity stayed pegged at 100 percent
for long enough that I killed Firefox from the Window List.
Buttons with arrows didn't display correctly. And the tab
showed the green circle going constantly.

[Dave Yeo]

Post by t***@antispam.ham
One of the reasons I wanted to try Firefox 24 is because the
Major League Baseball scoreboard at espn.com didn't like
Firefox 10. Sadly, it also doesn't like Firefox 24. Screen
elements aren't being positioned as they are in Firefox 38
on Windows, and CPU activity stayed pegged at 100 percent
for long enough that I killed Firefox from the Window List.
Buttons with arrows didn't display correctly. And the tab
showed the green circle going constantly.

Well now that you have almost all the requirements for 31.8.0, you can
test that soon.
Dave

[Dave Yeo]

Post by t***@antispam.ham

Post by Dave Yeo

Post by t***@antispam.ham
How can you stop something from using a DLL?

Don't link against the DLL (actually the import lib, alternative is to
link against a static lib) when building, usually done by feeding the
right options to configure.

Oh; I see what you mean now. I was thinking along the lines of how
could you stop a program from using the code in a DLL. Without the
code, it would break some capability of the program. You're talking
about the method of loading the code, dynamically via a DLL or statically
by having all the code built-in to the executable.

In this case I mean dropping support for features along with the
dependency. eg not supporting compressed fonts so no need of zlib, bzip2
and LHA. I've never seen a compressed font and no-one has complained
Dave

[t***@antispam.ham]

While we're on the subject of Firefox 24.8.1, I just fired up
Theseus to take a look at how much memory is being used by
Firefox and where it is allocated. But what caught my eye is
the General Information about Firefox page. There are a
surprisingly large number of open files associated with Firefox.
In particular, it seems to have opened every single font that I
have in my PSFONTS directory. It even opened fonts that it found
in the JAVA131\JRE\LIB\FONTS directory as well as in the
OS2\MDOS\WINOS2\SYSTEM directory. Anybody know why? How might it
be affecting the performance of Firefox?

[Dave Yeo]

Post by t***@antispam.ham
While we're on the subject of Firefox 24.8.1, I just fired up
Theseus to take a look at how much memory is being used by
Firefox and where it is allocated. But what caught my eye is
the General Information about Firefox page. There are a
surprisingly large number of open files associated with Firefox.
In particular, it seems to have opened every single font that I
have in my PSFONTS directory. It even opened fonts that it found
in the JAVA131\JRE\LIB\FONTS directory as well as in the
OS2\MDOS\WINOS2\SYSTEM directory. Anybody know why? How might it
be affecting the performance of Firefox?

Fontconfig (actually an OS/2 implementation) reads the INI file to find
all the fonts that are installed on your system. I don't think that it
affects the performance. You could test by removing everything except
Helvetica, Times new Roman, Times New Roman WT J, Courier, Symbol Set
and DejaVu Sans.
Note that the fonts are stashed in %HOME%\FCCACHE.INI or
%TEMP%\FCCACHE.INI or as a last resort, the program directory
Dave

[t***@antispam.ham]

Post by Dave Yeo
Fontconfig (actually an OS/2 implementation) reads the INI file to find
all the fonts that are installed on your system. I don't think that it
affects the performance.

I would think that it would slow down the startup at the very least.
Once the INI file has been read and all the font files opened, I can
imagine that it doesn't affect performance. But open files are the
most susceptible to corruption if the system crashes, so my usual
coding practice is to open a file, read what I nead, then close it.
That way I also don't have to worry about sharing an open file with
other applications.

Post by Dave Yeo
You could test by removing everything except
Helvetica, Times new Roman, Times New Roman WT J, Courier, Symbol Set
and DejaVu Sans.

Not going to do that; it would break a lot of DeScribe word processing
files that use the installed fonts. Speaking of DeScribe, I'll note
that the font toolbar button will usually show a sample of each font,
so it obviously read what it needed from the font files, but Theseus
shows not a single open font file associated with DeScribe. In fact,
of the eight handles associated with DeScribe, only two are disk files,
one being the document currently loaded into DeScribe, and the other
being a temporary file. Surprisingly lean; only 4 MB of shared and
2 MB of private memory. Firefox is using 526 MB of shared memory!
Lucky my desktop has 2 GB of physical memory.

[Steve Wendt]

Post by t***@antispam.ham
In case someone is keeping tracking of which DLLs are missing from
the extra_dlls file on hobbes, they are GCC1, GCC473, and lastly Z,

I'm quite late to the conversation, but for what it's worth, you should
find everything required on the Warpzilla Tips page:
http://os2news.warpstock.org/Warpzilla.html

[Shmuel (Seymour J.) Metz]

In <55ab250c$0$44462$c3e8da3$***@news.astraweb.com>, on
07/18/2015
Says that Moz for OS/2 is dead.

[Dave Yeo]

Post by Shmuel (Seymour J.) Metz
07/18/2015
Says that Moz for OS/2 is dead.

Forked would be a better description. I'm posting this on SeaMonkey 2.28
and have Firefox 31.8.0.
Dave

[Dave Yeo]

Post by Steve Wendt

Post by t***@antispam.ham
In case someone is keeping tracking of which DLLs are missing from
the extra_dlls file on hobbes, they are GCC1, GCC473, and lastly Z,

I'm quite late to the conversation, but for what it's worth, you should
http://os2news.warpstock.org/Warpzilla.html

Libkai needs to be added to the list of DLLs
Dave

[Steve Wendt]

Post by Dave Yeo
Libkai needs to be added to the list of DLLs

Yes, I'll add that; thanks for the reminder.

[Dave Yeo]

"Personally I prefer to statically link"
Hence the reason I prefer your builds - very little messing about,
unzip (or 7z) and run.
I hope you will make available your build of firefox when you finish
it.

I hadn't really been planning on doing a Firefox release and currently
I'm building with all the dependencies that the Bitwise build has as
currently building only works with the RPM/YUM environment and the GCC
flags to force static linking are somewhat broken so I have to rebuild
some libraries without dependencies and move the import libs out of the way.
I'll consider making a build but I also have a severe bandwidth problem.
Took 11 hours to upload TB 31.6.0, the library doesn't like my T42
(wireless doesn't get an address, even when booted to XP), probably due
to its old inefficient wireless (they also block uploading zips) and the
battery isn't very good for other places without a plugin.
We'll also have to see how Bitwise packages Firefox and whether they
accept my very minor patch to allow SeaMonkey to compile against their tree.
Dave

[ivan]

Post by Dave Yeo

"Personally I prefer to statically link"
Hence the reason I prefer your builds - very little messing about,
unzip (or 7z) and run.
I hope you will make available your build of firefox when you finish
it.

I hadn't really been planning on doing a Firefox release and currently
I'm building with all the dependencies that the Bitwise build has as
currently building only works with the RPM/YUM environment and the GCC
flags to force static linking are somewhat broken so I have to rebuild
some libraries without dependencies and move the import libs out of the way.
I'll consider making a build but I also have a severe bandwidth problem.
Took 11 hours to upload TB 31.6.0, the library doesn't like my T42
(wireless doesn't get an address, even when booted to XP), probably due
to its old inefficient wireless (they also block uploading zips) and the
battery isn't very good for other places without a plugin.
We'll also have to see how Bitwise packages Firefox and whether they
accept my very minor patch to allow SeaMonkey to compile against their tree.
Dave

Thanks for the information Dave.

It would be nice if you could do one of your builds so they I don't
have to mess about unpacking RPMs and such like. Some of the people
that I manage IT for have OS/2 setups that preclude my installing
RPM/YUM on and I am afraid that I agree that it shouldn't be let near
an OS/2 system.

I was in your situation regarding net connection a couple of years ago
(dial-up was actually faster than ADSL) but then someone dug up some
cable when they were 'improving' the junction from the village to the
main road and now I have 2Mbs ADSL which isn't too bad considering I'm
more that 8 km from the exchange as the cable runs.

One thing that might allow you to upload from the library is a small
android tablet (I have one that I found at the dump and repaired) with
an SD card. Mine connects to any open WiFi and I have used it to
download from hobbes while at a friends house (I use an FTP client
app). The SD card plugged into an USB adapter appears as a MSD on
OS/2.

Anyway, enough waffling on my part and thank you for the work you do
that helps keep OS/2 up and running.

ivan
--

[Doug Bissett]

This post might be inappropriate. Click to display it.