FF38.8.0 DLLs

[A.D. Fundum]

Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
original archive:

https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip

Probably an error. If not, then where can those DLL files be found
nowadays?


--

[Lars Erdmann]

Post by A.D. Fundum
Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip
Probably an error. If not, then where can those DLL files be found
nowadays?
--

No it's not an error. Almost all DLLs with the exception of the very few
DLLs in Firefoxes directory will now be installable via YUM/RPM. You
just need to use it.
As you have already seen all DLLs where this was possible have been
removed from the Firefox install package.
The reason that MOZALLOC.DLL / MOZSQLT3.DLL / XUL.DLL is still in there
is because these are not yet "unified" between Firefox and Thunderbird
(and Seamonkey).
Once that is done they will also go away and be installable via YUM/RPM.


If you want to:
http://rpm.netlabs.org/release/00/i386/

contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.

(there is also a zip subdirectory with zips but I think they are no
longer updated).

1) you will have to run a DLL listing tool like chk4dlls against
firefox.exe, mozalloc.dll, mozsqlt3.dll and xul.dll (with RECURSIVE
dependency listing) in order to see all DLLs which are directly or
indirectly loaded from firefox.exe. You will then need to reduce these
lists to the DLLs that are not standard DLLs as part of the OS.

2) You will have to search in those rpms in order to gather all the DLLs
found in 1).

Finally, the above still does not give a 100% guarantee that you have
all DLLs that you need. For example, the exceptq.dll (which is used to
report exception info on a trap) is loaded during RUNTIME, that is it
will not show up in the dependency tree.
And the DLLs loaded during runtime can themselves have dependencies to
additional DLLs ...

(For exceptq this is not an issue as it is not mandatory for the correct
operation of firefox and therefore firefox will still run if it does not
exist.)


Have fun. Wish you all the best. You are on your own.


Lars

[ivan]

Post by Lars Erdmann

Post by A.D. Fundum
Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip
Probably an error. If not, then where can those DLL files be found
nowadays?
--

No it's not an error. Almost all DLLs with the exception of the very few
DLLs in Firefoxes directory will now be installable via YUM/RPM. You
just need to use it.
As you have already seen all DLLs where this was possible have been
removed from the Firefox install package.
The reason that MOZALLOC.DLL / MOZSQLT3.DLL / XUL.DLL is still in there
is because these are not yet "unified" between Firefox and Thunderbird
(and Seamonkey).
Once that is done they will also go away and be installable via YUM/RPM.
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.
(there is also a zip subdirectory with zips but I think they are no
longer updated).
1) you will have to run a DLL listing tool like chk4dlls against
firefox.exe, mozalloc.dll, mozsqlt3.dll and xul.dll (with RECURSIVE
dependency listing) in order to see all DLLs which are directly or
indirectly loaded from firefox.exe. You will then need to reduce these
lists to the DLLs that are not standard DLLs as part of the OS.
2) You will have to search in those rpms in order to gather all the DLLs
found in 1).
Finally, the above still does not give a 100% guarantee that you have
all DLLs that you need. For example, the exceptq.dll (which is used to
report exception info on a trap) is loaded during RUNTIME, that is it
will not show up in the dependency tree.
And the DLLs loaded during runtime can themselves have dependencies to
additional DLLs ...
(For exceptq this is not an issue as it is not mandatory for the correct
operation of firefox and therefore firefox will still run if it does not
exist.)
Have fun. Wish you all the best. You are on your own.
Lars

Actually he is not on his own. There are a number of us that are
maintaining certified systems where we CAN NOT install RPM/YUM and
maintain the certification (we can just get by with the esr versions
of firefox because firefox was included in the original
certification).

I assume the developers have to have working versions of the DLLs to
test and since they produce the necessary exceptq zip it should not be
ant greater effort to produce a DLL zip (in fact I think it would be
easier than producing all the individual RPMs).


ivan
--

[Doug Bissett]

Post by ivan

Post by Lars Erdmann

Post by A.D. Fundum
Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip
Probably an error. If not, then where can those DLL files be found
nowadays?
--

No it's not an error. Almost all DLLs with the exception of the very few
DLLs in Firefoxes directory will now be installable via YUM/RPM. You
just need to use it.
As you have already seen all DLLs where this was possible have been
removed from the Firefox install package.
The reason that MOZALLOC.DLL / MOZSQLT3.DLL / XUL.DLL is still in there
is because these are not yet "unified" between Firefox and Thunderbird
(and Seamonkey).
Once that is done they will also go away and be installable via YUM/RPM.
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.
(there is also a zip subdirectory with zips but I think they are no
longer updated).
1) you will have to run a DLL listing tool like chk4dlls against
firefox.exe, mozalloc.dll, mozsqlt3.dll and xul.dll (with RECURSIVE
dependency listing) in order to see all DLLs which are directly or
indirectly loaded from firefox.exe. You will then need to reduce these
lists to the DLLs that are not standard DLLs as part of the OS.
2) You will have to search in those rpms in order to gather all the DLLs
found in 1).
Finally, the above still does not give a 100% guarantee that you have
all DLLs that you need. For example, the exceptq.dll (which is used to
report exception info on a trap) is loaded during RUNTIME, that is it
will not show up in the dependency tree.
And the DLLs loaded during runtime can themselves have dependencies to
additional DLLs ...
(For exceptq this is not an issue as it is not mandatory for the correct
operation of firefox and therefore firefox will still run if it does not
exist.)
Have fun. Wish you all the best. You are on your own.
Lars

Actually he is not on his own. There are a number of us that are
maintaining certified systems where we CAN NOT install RPM/YUM and
maintain the certification (we can just get by with the esr versions
of firefox because firefox was included in the original
certification).

I'm afraid, that those who wish/need to do it without RPM/YUM, are on
their own. Even the developers have decided that it is way too much
work to do it that way. Don't get me wrong, I don't like RPM/YUM, at
all. There has got to be a better way, but RPM/YUM (especially with
the Arca Noae Package Manager to run it), is, by far, the best
available method.

I see two options:

1) install a system with the Arca Noae Package Manager (RPM/YUM), and
keep it up to date. Then, extract whatever you need from that, ZIP it
up, and distribute it as required. Note that RPM/YUM distributes
things other than DLLs, so you may want to investigate that too.

2) Get Arca Noae Package Manager (RPM/YUM) added to the certification.
You will probably need that in the future, even if you can still work
around it now ("work" being the operative word).

There is actually a third option: Stop updating (which is probably not
a smart idea).

Post by ivan
I assume the developers have to have working versions of the DLLs to
test and since they produce the necessary exceptq zip it should not be
ant greater effort to produce a DLL zip (in fact I think it would be
easier than producing all the individual RPMs).

Exceptq is from a different source, and it is already an RPM package.
The user part of Exceptq is available at HOBBES as a WarpIn package,
if you prefer, but that will probably never be updated since it is now
managed by RPM/YUM.

Post by ivan
ivan

FWIW, I do understand the problems of certified software.
Unfortunately, that stuff is usually controlled by consultants. and
managers, who are terrified that something will go wrong, and don't
understand the consequences of not changing, so they don't want
anything to change without going through a really stupid set of tests,
that usually don't prove anything. The real danger lies in not keeping
things up to date, no matter how it is done.

Currently, I suggest working with option 1, if you insist on not using
RPM/YUM on each system. At least you should have everything that you
need, and it will all be in one place.

[Dave Yeo]

Post by Doug Bissett

Post by ivan

Post by Lars Erdmann

Post by A.D. Fundum
Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip
Probably an error. If not, then where can those DLL files be found
nowadays?
--

No it's not an error. Almost all DLLs with the exception of the very few
DLLs in Firefoxes directory will now be installable via YUM/RPM. You
just need to use it.
As you have already seen all DLLs where this was possible have been
removed from the Firefox install package.
The reason that MOZALLOC.DLL / MOZSQLT3.DLL / XUL.DLL is still in there
is because these are not yet "unified" between Firefox and Thunderbird
(and Seamonkey).
Once that is done they will also go away and be installable via YUM/RPM.
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.
(there is also a zip subdirectory with zips but I think they are no
longer updated).
1) you will have to run a DLL listing tool like chk4dlls against
firefox.exe, mozalloc.dll, mozsqlt3.dll and xul.dll (with RECURSIVE
dependency listing) in order to see all DLLs which are directly or
indirectly loaded from firefox.exe. You will then need to reduce these
lists to the DLLs that are not standard DLLs as part of the OS.
2) You will have to search in those rpms in order to gather all the DLLs
found in 1).
Finally, the above still does not give a 100% guarantee that you have
all DLLs that you need. For example, the exceptq.dll (which is used to
report exception info on a trap) is loaded during RUNTIME, that is it
will not show up in the dependency tree.
And the DLLs loaded during runtime can themselves have dependencies to
additional DLLs ...
(For exceptq this is not an issue as it is not mandatory for the correct
operation of firefox and therefore firefox will still run if it does not
exist.)
Have fun. Wish you all the best. You are on your own.
Lars

Actually he is not on his own. There are a number of us that are
maintaining certified systems where we CAN NOT install RPM/YUM and
maintain the certification (we can just get by with the esr versions
of firefox because firefox was included in the original
certification).

I'm afraid, that those who wish/need to do it without RPM/YUM, are on
their own. Even the developers have decided that it is way too much
work to do it that way. Don't get me wrong, I don't like RPM/YUM, at
all. There has got to be a better way, but RPM/YUM (especially with
the Arca Noae Package Manager to run it), is, by far, the best
available method.
1) install a system with the Arca Noae Package Manager (RPM/YUM), and
keep it up to date. Then, extract whatever you need from that, ZIP it
up, and distribute it as required. Note that RPM/YUM distributes
things other than DLLs, so you may want to investigate that too.
2) Get Arca Noae Package Manager (RPM/YUM) added to the certification.
You will probably need that in the future, even if you can still work
around it now ("work" being the operative word).
There is actually a third option: Stop updating (which is probably not
a smart idea).

The other option is to build a statically linked Firefox. I'll note that
the 38.8.0 I have here still has the nspr and nss dlls.
With a little work the dependencies can be reduced to maybe a half dozen
DLLs and with more work maybe 3 or 4. The source is all available.

Post by Doug Bissett

Post by ivan
I assume the developers have to have working versions of the DLLs to
test and since they produce the necessary exceptq zip it should not be
ant greater effort to produce a DLL zip (in fact I think it would be
easier than producing all the individual RPMs).

Steve has been doing a pretty good job of packaging the DLLs and
hopefully will produce another package, but it is getting harder.

Post by Doug Bissett
Exceptq is from a different source, and it is already an RPM package.
The user part of Exceptq is available at HOBBES as a WarpIn package,
if you prefer, but that will probably never be updated since it is now
managed by RPM/YUM.

Post by ivan
ivan

FWIW, I do understand the problems of certified software.
Unfortunately, that stuff is usually controlled by consultants. and
managers, who are terrified that something will go wrong, and don't
understand the consequences of not changing, so they don't want
anything to change without going through a really stupid set of tests,
that usually don't prove anything. The real danger lies in not keeping
things up to date, no matter how it is done.
Currently, I suggest working with option 1, if you insist on not using
RPM/YUM on each system. At least you should have everything that you
need, and it will all be in one place.

Dave

[A.D. Fundum]

Post by Dave Yeo

Post by Doug Bissett
I see two options

Software (FF), which requires software (e.g. FF DLLs ?!), which
requires software (whatever unwanted package manager, typically I'm
the package manager over here), which require software (requirements
of an unneeded package manager) is more than a little bit over the
top. It almost sounds like Micro$oft to me... :-)

Post by Dave Yeo
The other option is to build a statically linked Firefox.

Basicly what is being denied here, in general, is that this implies
that it isn't Firefox for OS/2 anymore. Apparently it's Firefox for
eCS 2, with matching requirements/assumptions. The use of eCS 2 is
assumed, AFAICT. If it would have been called Firefox for eCS 2, then
I would not have downloaded it. I'm not one of the happy few with eCS
2, and I tend to avoid software which requires software which requires
software which requires software. I'm afraid it's a reasonable claim
that it's Firefox for eCS 2+, albeit the README still is README.OS2.
This isn't OS/2 software. You can make it work with OS/2 indeed, but
only with extraordinary efforts. I'd prefer a statically linked FF
indeed (ignoring 1200/75'ish modem speeds, and so on).

BTW, one of the problems of pretending that OS/2 is eCS 2 by updating
or installing random components (requirements of requirements of ...)
is that eventually upgrading to eCS 2 will introduce new problems,
like the WPIRTL.DLL-one. It's a general disadvantage of adding non-OS
software to an OS.


--

[A.D. Fundum]

I'll try to use the SM DLLs, albeit FF could be >= SM.

Post by Doug Bissett
Get Arca Noae Package Manager (RPM/YUM) added to the
certification.

And, I guess, fully ignored internet connections for the stand-alone
machines?

This is an option, produced by owners of eCS 2 with an internet
connection for their beloved hobby. IRL this is yet another reason to
prefer ZIP packages (but onbly if such a ZIP package is an unavoidable
requirement). There are several reasons why one doesn't want to use
whatever you happen to be using. Or simply cannot use whatever the
happy few are using.

FWIW, what's the general added value, or what is the most significant
advantage of introducing such a new NSPR-requirement by excluding
required DLLs? Technical reasons? Faster exectution speed? Disk space?

FWIW/eCS2, a late introduction of statically linked distrubutions will
mean that most of the requirements will be both installed and possibly
outdated.


--

[Steve Wendt]

Post by A.D. Fundum
And, I guess, fully ignored internet connections for the stand-alone
machines?

I understand your point in general, but the applicability in this
scenario is quite limited; is Firefox all that useful without an
internet connection?

Post by A.D. Fundum
advantage of introducing such a new NSPR-requirement by excluding
required DLLs?

If I understand correctly, the forthcoming port of VirtualBox will
require the nspr package as well.

[Dave Yeo]

Post by Steve Wendt

Post by A.D. Fundum
And, I guess, fully ignored internet connections for the stand-alone
machines?

I understand your point in general, but the applicability in this
scenario is quite limited; is Firefox all that useful without an
internet connection?

Post by A.D. Fundum
advantage of introducing such a new NSPR-requirement by excluding
required DLLs?

If I understand correctly, the forthcoming port of VirtualBox will
require the nspr package as well.

As well as the NSS package I believe.
Dave

[Steve Wendt]

Post by Dave Yeo
The other option is to build a statically linked Firefox.

Just like Mozilla produces for other operating systems. :-)

Some Linux distros roll their own using system libraries, but in that
scenario, the whole thing is available through their standard packaging
systems. Unless you can "yum install seamonkey", static linking makes
for a much more sane deliverable.

Post by Dave Yeo
Steve has been doing a pretty good job of packaging the DLLs and
hopefully will produce another package, but it is getting harder.

I've had low motivation, since I much prefer SeaMonkey over Firefox. I
may or may not get to it soon.

[Steve Wendt]

Post by Steve Wendt

Post by Dave Yeo
Steve has been doing a pretty good job of packaging the DLLs and
hopefully will produce another package, but it is getting harder.

I've had low motivation, since I much prefer SeaMonkey over Firefox.

Interested parties can give it a shot:
http://os2news.warpstock.org/Warpzilla.html

[ivan]

On Tue, 31 May 2016 16:10:35 UTC, "Doug Bissett"

Post by Doug Bissett

Post by ivan

Post by Lars Erdmann

Post by A.D. Fundum
Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip
Probably an error. If not, then where can those DLL files be found
nowadays?
--

No it's not an error. Almost all DLLs with the exception of the very few
DLLs in Firefoxes directory will now be installable via YUM/RPM. You
just need to use it.
As you have already seen all DLLs where this was possible have been
removed from the Firefox install package.
The reason that MOZALLOC.DLL / MOZSQLT3.DLL / XUL.DLL is still in there
is because these are not yet "unified" between Firefox and Thunderbird
(and Seamonkey).
Once that is done they will also go away and be installable via YUM/RPM.
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.
(there is also a zip subdirectory with zips but I think they are no
longer updated).
1) you will have to run a DLL listing tool like chk4dlls against
firefox.exe, mozalloc.dll, mozsqlt3.dll and xul.dll (with RECURSIVE
dependency listing) in order to see all DLLs which are directly or
indirectly loaded from firefox.exe. You will then need to reduce these
lists to the DLLs that are not standard DLLs as part of the OS.
2) You will have to search in those rpms in order to gather all the DLLs
found in 1).
Finally, the above still does not give a 100% guarantee that you have
all DLLs that you need. For example, the exceptq.dll (which is used to
report exception info on a trap) is loaded during RUNTIME, that is it
will not show up in the dependency tree.
And the DLLs loaded during runtime can themselves have dependencies to
additional DLLs ...
(For exceptq this is not an issue as it is not mandatory for the correct
operation of firefox and therefore firefox will still run if it does not
exist.)
Have fun. Wish you all the best. You are on your own.
Lars

Actually he is not on his own. There are a number of us that are
maintaining certified systems where we CAN NOT install RPM/YUM and
maintain the certification (we can just get by with the esr versions
of firefox because firefox was included in the original
certification).

I'm afraid, that those who wish/need to do it without RPM/YUM, are on
their own. Even the developers have decided that it is way too much
work to do it that way. Don't get me wrong, I don't like RPM/YUM, at
all. There has got to be a better way, but RPM/YUM (especially with
the Arca Noae Package Manager to run it), is, by far, the best
available method.
1) install a system with the Arca Noae Package Manager (RPM/YUM), and
keep it up to date. Then, extract whatever you need from that, ZIP it
up, and distribute it as required. Note that RPM/YUM distributes
things other than DLLs, so you may want to investigate that too.
2) Get Arca Noae Package Manager (RPM/YUM) added to the certification.
You will probably need that in the future, even if you can still work
around it now ("work" being the operative word).
There is actually a third option: Stop updating (which is probably not
a smart idea).

Post by ivan
I assume the developers have to have working versions of the DLLs to
test and since they produce the necessary exceptq zip it should not be
ant greater effort to produce a DLL zip (in fact I think it would be
easier than producing all the individual RPMs).

Exceptq is from a different source, and it is already an RPM package.
The user part of Exceptq is available at HOBBES as a WarpIn package,
if you prefer, but that will probably never be updated since it is now
managed by RPM/YUM.

Post by ivan
ivan

FWIW, I do understand the problems of certified software.
Unfortunately, that stuff is usually controlled by consultants. and
managers, who are terrified that something will go wrong, and don't
understand the consequences of not changing, so they don't want
anything to change without going through a really stupid set of tests,
that usually don't prove anything. The real danger lies in not keeping
things up to date, no matter how it is done.
Currently, I suggest working with option 1, if you insist on not using
RPM/YUM on each system. At least you should have everything that you
need, and it will all be in one place.

Thanks for that Doug.

Your option 1 is more or less what we have done and now have it setup
on our test box.

The thing I don't understand is why the change from doing it the OS/2
way to trying to emulate the Linux way with the least favoured Linux
package manager out there.

Maybe I'm just getting too old but we didn't have this sort of thing
back in the days of OS/2 2.1.


ivan
--

[Dave Yeo]

Post by ivan
The thing I don't understand is why the change from doing it the OS/2
way to trying to emulate the Linux way with the least favoured Linux
package manager out there.

A package manager is a good idea as Warpin was pretty crappy at things
like downloading dependencies. I can only assume that they picked RPM as
that is what they know. I do have to agree with it being a crappy choice
though.

Post by ivan
Maybe I'm just getting too old but we didn't have this sort of thing
back in the days of OS/2 2.1.

We didn't do it in the most of the days of eCS even.
Dave

[Paul Ratcliffe]

Post by Dave Yeo
A package manager is a good idea as Warpin was pretty crappy at things
like downloading dependencies.

It isn't "pretty crappy" at such things. It doesn't do them at all. It
was never designed to do so.

[A.D. Fundum]

Post by Dave Yeo
A package manager is a good idea as Warpin was pretty
crappy at things like downloading dependencies.

Ignoring that I tend to be the package manager over here, package
managers and installers ought to be different products, just like an
OS shouldn't be a collection of archivers. AFAIK FF for Windows
doesn't update system components too.

Post by Dave Yeo
I do have to agree with it being a crappy choice though.

The crappy choice is just one of the crappy choices, introduced by FF
for eCS 2.x. It's not just the package manager as such. The
documention seems to be fully aimed at users of eCS 2.x, it looks like
RPM will be used instead of RPM and ZIP, it Unixifies OS/2 extremely,
the number of requirements of crappy requirements is excessive, and so
on.

Regarding FF, WarpIN, and a theoretical perfect WPI file, the earlier
campaign to WPI'ify archives was crappy too. With some back-up
strategies you have to back-up both the huge FF archive itself and its
installed huge FF files, mainly because authors haven't included a
WPINSTAL.CMD file (and WarpIN won't generate it). IRL I often convert
such a WPI file to own WPINSTAL.CMDs, avoiding having to back-up over
100 MiB and avoiding possible other issues. Nevertheless FF.WPI could
have been Windowified (and OS/2'ified) by adding all required unique
files to it, albeit its composer doesn't have to solve my fatal
problems with crappy choices.


--

[Dave Yeo]

Post by A.D. Fundum
AFAIK FF for Windows
doesn't update system components too.

That's partially due to MS updating system components. Mozilla has been
debating dropping support for XP and only supports the latest service pack.
I guess if you update to ArcaOS 5, then all the system components will
be there to run the newest Firefox and I assume that Arca Noae are
paying for the Firefox updates. At least it is possible to update older
versions of OS/2 (back to v4+fp15, maybe even v3+fp42) unlike if running
older other OSes.
We're lucky to have a close to up to date browser at this point and
Bitwise has done an excellent job of bug fixing even if we don't like
some of their other decisions.
Dave

[Steve Wendt]

Post by Dave Yeo
Bitwise has done an excellent job of bug fixing even if we don't like
some of their other decisions.

Wholeheartedly agreed. :)

[Doug Bissett]

Post by ivan
Your option 1 is more or less what we have done and now have it setup
on our test box.
The thing I don't understand is why the change from doing it the OS/2
way to trying to emulate the Linux way with the least favoured Linux
package manager out there.

You need to ask those who are doing it. Personally, I don't like
RPM/YUM, and especially I don't like the directory structure, but
since that is the path that was chosen, it leaves us with three
options: 1) Go with it. 2) Do it manually. 3) Quit updating. #3 is
really not an option when it comes to a browser. There are too many
ways to cause problems, if they are not kept up to date. Since FF (and
TB or SM) is pretty well required, we need to keep it as up to date as
possible. #2 is proving to be a LOT of work, although keeping one
system up to date using ANPM (RPM/YUM) makes that somewhat easier. #1
is really the only logical option for most people. Those, like
yourself who have contract obligations, are in a bit of trouble
because of it.

Post by ivan
Maybe I'm just getting too old but we didn't have this sort of thing
back in the days of OS/2 2.1.

In those days, IBM was doing the job properly. We no longer have that
luxury, and those who do it get to call the shots (as IBM did, in the
old days). If the rest of us want to keep using OS/2, we need to do it
their way, quit updating (which has it's own advantages, and
disadvantages), or do it in some other way. Since it takes somebody
who knows what they are doing (and usually a LOT of money), most users
can't do it themselves.

At least the platform is still viable, even if it is on life support.

[A.D. Fundum]

Post by ivan
Maybe I'm just getting too old but we didn't have
this sort of thing back in the days of OS/2 2.1.

In the industry it's quite hard to imagine two steps forwards without the
mandatory step(s) back.

The other day I think I saw an OS/2 2.1 screen/logo while watching a final
part of 007's movie Goldeneye. I guess that's what they bought when they
had to destroy a bunch of old computers...


--

[Lars Erdmann]

Ok, I see the point.

"they have working versions of the DLLs": I guess the problem is to
track the dependencies. I am no expert but I guess that if you port some
library that there is dependency info coming with the complete package
so that it is suitable to be installed via RPM but not any other way.
They just don't have the time to continously "write down and update" the
dependency tree so that they would know what overall set of DLLs is needed.

Would it be possible for you to have ANPM or YUM/RPM added to your
certification (as Doug suggested) and set up a regular update via
YUM/RPM on all the affected machines ?
For ANPM I don't think it can be executed in a command line mode.
However, if you have that need I think it would be worth asking ArcaNoae
to add this to ANPM. Since ArcaNoae also provides the OS to companies,
they potentially have a vital interest in solving this problem.


Lars

Post by ivan

Post by Lars Erdmann
Have fun. Wish you all the best. You are on your own.
Lars

Actually he is not on his own. There are a number of us that are
maintaining certified systems where we CAN NOT install RPM/YUM and
maintain the certification (we can just get by with the esr versions
of firefox because firefox was included in the original
certification).
I assume the developers have to have working versions of the DLLs to
test and since they produce the necessary exceptq zip it should not be
ant greater effort to produce a DLL zip (in fact I think it would be
easier than producing all the individual RPMs).
ivan

[Dave Yeo]

Post by Lars Erdmann
For ANPM I don't think it can be executed in a command line mode.
However, if you have that need I think it would be worth asking ArcaNoae
to add this to ANPM. Since ArcaNoae also provides the OS to companies,
they potentially have a vital interest in solving this problem.

ANPM is just a front end to YUM, so for command line just directly use YUM
Dave

[ivan]

Post by Lars Erdmann
Ok, I see the point.
"they have working versions of the DLLs": I guess the problem is to
track the dependencies. I am no expert but I guess that if you port some
library that there is dependency info coming with the complete package
so that it is suitable to be installed via RPM but not any other way.
They just don't have the time to continously "write down and update" the
dependency tree so that they would know what overall set of DLLs is needed.
Would it be possible for you to have ANPM or YUM/RPM added to your
certification (as Doug suggested) and set up a regular update via
YUM/RPM on all the affected machines ?
For ANPM I don't think it can be executed in a command line mode.
However, if you have that need I think it would be worth asking ArcaNoae
to add this to ANPM. Since ArcaNoae also provides the OS to companies,
they potentially have a vital interest in solving this problem.
Lars

Post by ivan

Post by Lars Erdmann
Have fun. Wish you all the best. You are on your own.
Lars

Actually he is not on his own. There are a number of us that are
maintaining certified systems where we CAN NOT install RPM/YUM and
maintain the certification (we can just get by with the esr versions
of firefox because firefox was included in the original
certification).
I assume the developers have to have working versions of the DLLs to
test and since they produce the necessary exceptq zip it should not be
ant greater effort to produce a DLL zip (in fact I think it would be
easier than producing all the individual RPMs).
ivan

It might be possible to get RPM/YUM certified IF we can make a case
for doing so but the problem is that the client is very unlikely to
want to pay for it and I'm damned if we are going to.

Out of curiosity I had a look at the same version of firefox on a
friends win7 box and guess what, it has all the DLLs in the firefox
directory - strange that the OS/2 version is the only one out of step.

Anyway, we have unpacked the RPMs and now have a set of DLLs moved
over to the test version of firefox on the test box. Now we find out
if it works consistently and runs the clients interface and addons.
If all goes well we might be able to release it to the client next
week.


ivan
--

[Dave Yeo]

Post by ivan
Out of curiosity I had a look at the same version of firefox on a
friends win7 box and guess what, it has all the DLLs in the firefox
directory - strange that the OS/2 version is the only one out of step.

The developers seem like children playing with a new toy when it comes
to the DLL thing. We always had the goal of Mozilla and most programs
being self contained or close to it. Sometimes there has to be a DLL for
licensing reasons, eg libc falls under this along with the FFmpeg DLLs
that are dynamically loaded and sometimes a library is expected to be
actively updated, which was the reason I moved mozfntcfgft to DLLs.
Otherwise I don't understand the reasoning, we generally have lots of
memory installed.
Dave

[A.D. Fundum]

we generally have lots of memory installed.

In all other cases the user won't even expect anymore that a modern full
browser like FF/SM will be fast.

I'm not claiming that developers may savely assume the availability of at
least a few GBs. My worst case is probably 288 MB, so I'm confirming that
in this case the general rule also is the only rule. With 288 MB it works,
but that's about it. The next working step in Hardware Land will be a
Pentium 4, which generally should support "lots of memory" anyway.

In a way memory-related "optimizations" seem to be aimed at a Pentium III
with less than "lots of memory", but more than 288 MB. At the moment FF/SM
doesn't work with Pentium IIIs, so IRL it doesn't make sense indeed.


--

[Dave Yeo]

Post by A.D. Fundum
I'm not claiming that developers may savely assume the availability of at
least a few GBs. My worst case is probably 288 MB, so I'm confirming that
in this case the general rule also is the only rule. With 288 MB it works,
but that's about it. The next working step in Hardware Land will be a
Pentium 4, which generally should support "lots of memory" anyway.

Yes, 288MBs is pushing it but it should work as long as you don't go to
really JavaScript heavy pages or load too many tabs. You still have to
worry about shared memory as well and even with only 288MBs, might
benefit from loading the DLLs high.

Post by A.D. Fundum
In a way memory-related "optimizations" seem to be aimed at a Pentium III
with less than "lots of memory", but more than 288 MB. At the moment FF/SM
doesn't work with Pentium IIIs, so IRL it doesn't make sense indeed.

They should work with Pentium IIIs and even a Pentium Pro.
Dave

[A.D. Fundum]

Post by Dave Yeo

At the moment FF/SM doesn't work with Pentium IIIs

They should work with Pentium IIIs and even a Pentium Pro.

Actually it (possibly including add-ons, i.e. the whole suite) will
work, but not without the 100% CPU load w.r.t. FF/SM only, which
(according to you, and unchallenged) could be related to Java
optimizations for Pentium III CPUs. Doing anything may or will take
several minutes. Technically it works, but socially it doesn't.

So saving a few MiBs of RAM quickly may be worth the efforts. But if
it's going to be a project, then it's pretty useless unless this
project includes Java updates too.

A user of a Pentium II with 288 MiB of RAM will hardly notice the
difference, and users of Pentium IVs or better should be able to
install your "lots of RAM" indeed.

Theoretically Pentium IIIs should benefit the most from a smaller RAM
footprint, but such a smaller footprint won't solve the far more
significant problem of the 100% Pentium III CPU load w.r.t. FF/SM
(anything but FF/SM remains responsive).

So far I haven't renewed any PIII install, so I still haven't recorded
what the specific trigger of this 100% CPU load may be. It may be one
of the recommended performance-enhancing add-ons, like noscript. If
so, then an attempt to avoid a 100% CPU load (by scripts) causes
another type of a 100% CPU load (by Java optimizations)... :-)


--

[Dave Yeo]

Post by Lars Erdmann

Post by A.D. Fundum
Several DLL files, e.g. FF's own NSPR4.DLL, are missing from the
https://github.com/bitwiseworks/mozilla-os2/releases/download/FIREFOX_
38_8_0esr_RELEASE_OS2_Beta_7/firefox-38.8.0.en-US.os2.zip
Probably an error. If not, then where can those DLL files be found
nowadays?
--

No it's not an error. Almost all DLLs with the exception of the very few
DLLs in Firefoxes directory will now be installable via YUM/RPM. You
just need to use it.
As you have already seen all DLLs where this was possible have been
removed from the Firefox install package.
The reason that MOZALLOC.DLL / MOZSQLT3.DLL / XUL.DLL is still in there
is because these are not yet "unified" between Firefox and Thunderbird
(and Seamonkey).
Once that is done they will also go away and be installable via YUM/RPM.

Actually I'd expect that eventually they'll use a sqlt3.dll and get rid
of mozsqlite3.dll. Ideally mozalloc.dll ahould be replaced by a
jemalloc.dll but I don't think it'll work on OS/2 as it expects to
allocate memory at specified addresses. Shame as I believe it supports
garbage collection.
The Thunderbird xul.dll seems to work for FF, SM as well as TB here, as
long as all apps are built from the same tree.

Post by Lars Erdmann
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.
(there is also a zip subdirectory with zips but I think they are no
longer updated).
1) you will have to run a DLL listing tool like chk4dlls against
firefox.exe, mozalloc.dll, mozsqlt3.dll and xul.dll (with RECURSIVE
dependency listing) in order to see all DLLs which are directly or
indirectly loaded from firefox.exe. You will then need to reduce these
lists to the DLLs that are not standard DLLs as part of the OS.
2) You will have to search in those rpms in order to gather all the DLLs
found in 1).
Finally, the above still does not give a 100% guarantee that you have
all DLLs that you need. For example, the exceptq.dll (which is used to
report exception info on a trap) is loaded during RUNTIME, that is it
will not show up in the dependency tree.
And the DLLs loaded during runtime can themselves have dependencies to
additional DLLs ...

For H264/AAC video playback there is a requirement that FFmpeg/Libav
DLLs be found on the LIBPATH, they'll depend on at least the dlls from
zlib and bzip2.

Post by Lars Erdmann
(For exceptq this is not an issue as it is not mandatory for the correct
operation of firefox and therefore firefox will still run if it does not
exist.)
Have fun. Wish you all the best. You are on your own.
Lars

Dave

[A.D. Fundum]

Post by Lars Erdmann
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe
and cpio.exe.

Thank you, that was pretty clear 2.0!

According to the text and names of files FF for OS/2 is a product for OS/2,
but OS/2 nor eCS 1.x ships with e.g. RPM2CPIO.EXE.

So, FTR: where can one find those EXEs? IRL the documentation assumes the
use of RPM, i.e. eCS 2.x. What are recommended (eCS 2.x-) directories to
install those OS components?

Post by Lars Erdmann
And the DLLs loaded during runtime can themselves have dependencies
to additional DLLs ...

I still don't get it why "unification" of some compenents of a single brand
of products was judged to be far more important than the introduction of
excessive, rather extreme (e.g. compared with FF for Windows) and avoidable
requirements. An engineer's choice?

FWIW, in my case FF hardly justifies any extraordinary efforts. I'm using
SM is production. The latest version of SM still included all expected
DLLs, without surprises. So it's quite unlikely that I'll install RPM just
because FF requires it, unless the (AFAICT) OS-component RPM is available
as an drop-in update for eCS 1.x too (so including the use of the same
directories, and so on). Otherwise I'd really, really like to avoid using
software, which requires software, which requires software, which requires
software, which requires software. As such I'm not using nor liking Unix.


--

[Dave Yeo]

Post by A.D. Fundum

Post by Lars Erdmann
http://rpm.netlabs.org/release/00/i386/

That should be http://rpm.netlabs.org/release/00/i686 as some of the
programs, including Mozilla require instructions that weren't included
in the i386 and i386 has been depreciated.

Post by A.D. Fundum

Post by Lars Erdmann
contains all rpms which are extractable via rpm2cpio.exe
and cpio.exe.

Thank you, that was pretty clear 2.0!
According to the text and names of files FF for OS/2 is a product for OS/2,
but OS/2 nor eCS 1.x ships with e.g. RPM2CPIO.EXE.
So, FTR: where can one find those EXEs? IRL the documentation assumes the
use of RPM, i.e. eCS 2.x. What are recommended (eCS 2.x-) directories to
install those OS components?

I believe everything is included in
http://homepage1.nifty.com/jsawa/attglobal/rpm/unrpm.zip.

Post by A.D. Fundum

Post by Lars Erdmann
And the DLLs loaded during runtime can themselves have dependencies
to additional DLLs ...

I still don't get it why "unification" of some compenents of a single brand
of products was judged to be far more important than the introduction of
excessive, rather extreme (e.g. compared with FF for Windows) and avoidable
requirements. An engineer's choice?

Mostly. Often developers seem to think they know better what the users
prefer then the users do. Best example is Firefox, where they keep
making hated decisions and are now only 12% of the browser market.
NSPR and NSS are also part of the new VirtualBox port so in a way it
makes sense sharing them. As well if development stops on our Firefox
port, updating NSS will still be possible and as it takes care of
encryption, it is important for it to be maintained and up to date.

Post by A.D. Fundum
FWIW, in my case FF hardly justifies any extraordinary efforts. I'm using
SM is production. The latest version of SM still included all expected
DLLs, without surprises. So it's quite unlikely that I'll install RPM just
because FF requires it, unless the (AFAICT) OS-component RPM is available
as an drop-in update for eCS 1.x too (so including the use of the same
directories, and so on). Otherwise I'd really, really like to avoid using
software, which requires software, which requires software, which requires
software, which requires software. As such I'm not using nor liking Unix.

Of course RPM is available as a drop-in update for eCS1.x and Warp
v4+fp13 (perhaps earlier as well, no one is testing or even seriously
using anything less then Warp V4+fp15+all the other free updates).
Simplest is to decide where you want your @UNIXROOT tree and download
the Arca Noae Package Manager and run it. It'll install the base RPM
system and let you install the other packages.
I'm using YUM/RPM on Warp v4 and eCS2.1, shared between them. Ideally is
to dedicate a partition to it
Dave

[Steve Wendt]

Post by Dave Yeo

Post by Lars Erdmann
contains all rpms which are extractable via rpm2cpio.exe
and cpio.exe.

I believe everything is included in
http://homepage1.nifty.com/jsawa/attglobal/rpm/unrpm.zip.

7zip works also.

[Dave Yeo]

Post by Steve Wendt

Post by Dave Yeo

Post by Lars Erdmann
contains all rpms which are extractable via rpm2cpio.exe
and cpio.exe.

I believe everything is included in
http://homepage1.nifty.com/jsawa/attglobal/rpm/unrpm.zip.

7zip works also.

Wonder if the Windows 7zip still works with Odin? It did have a nice
interface.
Dave

[ivan]

Post by Dave Yeo

Post by Steve Wendt

Post by Dave Yeo

Post by Lars Erdmann
contains all rpms which are extractable via rpm2cpio.exe and cpio.exe.

I believe everything is included in
http://homepage1.nifty.com/jsawa/attglobal/rpm/unrpm.zip.

7zip works also.

Wonder if the Windows 7zip still works with Odin? It did have a nice
interface.
Dave

The version I am using does (7z v9.2) and it opens and extracts all
the RPMs without problems.

ivan
--

[Pete]

Hi

Post by A.D. Fundum

Post by Lars Erdmann
http://rpm.netlabs.org/release/00/i386/
contains all rpms which are extractable via rpm2cpio.exe
and cpio.exe.

Thank you, that was pretty clear 2.0!
According to the text and names of files FF for OS/2 is a product for OS/2,
but OS/2 nor eCS 1.x ships with e.g. RPM2CPIO.EXE.
So, FTR: where can one find those EXEs? IRL the documentation assumes the
use of RPM, i.e. eCS 2.x. What are recommended (eCS 2.x-) directories to
install those OS components?

If you just want to unpack files from an rpm package you can use the
Archive Viewer available here http://www.altsan.org/programming/os2/#arcview

Post by A.D. Fundum

Post by Lars Erdmann
And the DLLs loaded during runtime can themselves have dependencies
to additional DLLs ...

I still don't get it why "unification" of some compenents of a single brand
of products was judged to be far more important than the introduction of
excessive, rather extreme (e.g. compared with FF for Windows) and avoidable
requirements. An engineer's choice?
FWIW, in my case FF hardly justifies any extraordinary efforts. I'm using
SM is production. The latest version of SM still included all expected
DLLs, without surprises. So it's quite unlikely that I'll install RPM just
because FF requires it, unless the (AFAICT) OS-component RPM is available
as an drop-in update for eCS 1.x too (so including the use of the same
directories, and so on). Otherwise I'd really, really like to avoid using
software, which requires software, which requires software, which requires
software, which requires software. As such I'm not using nor liking Unix.

Looks like we will have to go the yum/rpm route in the future if we want
to keep using an OS/2 based system.

As my various previous experiences of yum/rpm in the linux world were
less than satisfactory and my first experience of yum/rpm in an OS/2
environment was the failure of the package supplied with eCS2.2 I must
admit to being less than enthralled at the prospect of installing
yum/rpm in the future.

Maybe it is time to look into other OS's and see what takes my interest
- if I have to run a linux package manager it may as well be in a linux
environment.


Regards

Pete

[A.D. Fundum]

Post by Lars Erdmann
You are on your own.

Actually _you_ are, FWIW.

AFAICT eCS 2.x licenses are only available in English and German, and
it looks like the group of the happy few is dominated by countries
where German or English is the main official language. The rest of the
world seems to be less pleased by this Anglo-Saxon "solution", at
least so far. They've now produced FF for eCS 2.x, probably "Made in
Germany".

FWIW/2, downloading the rather useless WPI archive of FF has no use if
you're looking for all files and/or bloody tools which are supposed to
be required to install FF. The archive doesn't include the excluded
DLL files.


--

[Doug Bissett]

Post by A.D. Fundum
FWIW/2, downloading the rather useless WPI archive of FF has no use if
you're looking for all files and/or bloody tools which are supposed to
be required to install FF. The archive doesn't include the excluded
DLL files.

Hmmm. The Firefox WarpIn installer includes everything that is
supplied by those who do the port. Nothing has been excluded. They
have decided that it is wise to install the DLLs using Arca noae
Package Manager (RPM/YUM). While RPM/YUM is a pile of crap (but it is
far better than trying to sort it out by yourself), ANPM does make it
usable, and when FF becomes available as a RPM package, it will be the
only way to install FF (and, eventually, SM and TB). I strongly
suggest that you get, and install, Arca Noae Package Manager
(RPM/YUM), and start using that for what it is designed to do. Trying
to take any other path forward, will prove to be an exercise in
frustration (which you are already experiencing). The future is here,
get on board before you sink.

[Lars Erdmann]

looks like you are having fun already :-)

No, nothing is dominated by anybody. I have a mix of german and english
as eComStation 2.2 beta was only in English. On the other hand, you do
can select between different keyboard layouts and every keyboard layout
offered by Warp4 is also offered.
There is no FF "Made in Germany". FF is language neutral, there are XPIs
to customize the language.
There are lots of applications that have requirements and rely on other
SW. In fact, all of them rely on the DLLs that OS/2 ships (if these are
broken then you will need to update them, too).

In my opinion Warp4 is just too outdated. How would you run Warp4 on an
ACPI system and fully exploit its capabilities if it is a multi-core
machine (which is standard nowadays) ?


Lars

Post by A.D. Fundum

Post by Lars Erdmann
You are on your own.

Actually _you_ are, FWIW.
AFAICT eCS 2.x licenses are only available in English and German, and
it looks like the group of the happy few is dominated by countries
where German or English is the main official language. The rest of the
world seems to be less pleased by this Anglo-Saxon "solution", at
least so far. They've now produced FF for eCS 2.x, probably "Made in
Germany".
FWIW/2, downloading the rather useless WPI archive of FF has no use if
you're looking for all files and/or bloody tools which are supposed to
be required to install FF. The archive doesn't include the excluded
DLL files.
--

[Dave Yeo]

Post by Lars Erdmann
In my opinion Warp4 is just too outdated. How would you run Warp4 on an
ACPI system and fully exploit its capabilities if it is a multi-core
machine (which is standard nowadays) ?

Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.
Dave

[Pete]

Hi Dave

Post by Dave Yeo

Post by Lars Erdmann
In my opinion Warp4 is just too outdated. How would you run Warp4 on an
ACPI system and fully exploit its capabilities if it is a multi-core
machine (which is standard nowadays) ?

Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.
Dave

I seem to recall something like that from my early attempts to get an
AMD 64x2 cpu working with os2apic.psd.

If I remember correctly the answer was to use the OS/4 kernel and loader
package, some info about the package here
http://www.os2world.com/wiki/index.php/Phoenix_OS/4


Regards

Pete

[Lars Erdmann]

...which exactly seconds what I have stated: there is no way to get
Warp4 to run with multiple cores without investing additional effort
(and SW). And using only 1 out of 8 cores is not a solution for me.

OS2APIC.PSD is a mess and has never worked for more than a handful of
machines. It's also outdated by now as much of the functionality has now
been taken over by ACPI and therefore the old Intel MP configuration
table (according to the original Intel Multiprozessor spec version 1.4)
in BIOS that OS2APIC.PSD makes use of is often outdated or buggy (ACPI
comes with a new set of tables that mostly replaces that stuff).


Lars

Post by Pete
Hi Dave

Post by Dave Yeo

Post by Lars Erdmann
In my opinion Warp4 is just too outdated. How would you run Warp4 on an
ACPI system and fully exploit its capabilities if it is a multi-core
machine (which is standard nowadays) ?

Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.
Dave

I seem to recall something like that from my early attempts to get an
AMD 64x2 cpu working with os2apic.psd.
If I remember correctly the answer was to use the OS/4 kernel and loader
package, some info about the package here
http://www.os2world.com/wiki/index.php/Phoenix_OS/4
Regards
Pete

[T.]

Post by Lars Erdmann
OS2APIC.PSD is a mess and has never worked for more than a handful of
machines.

it was designed to run only on selected boards/cpus, preferable IBM
Servers and some others from the "big players".

On my IBM Netfinity it always was working very well!

[Pete]

Hi Lars

Post by Lars Erdmann
...which exactly seconds what I have stated: there is no way to get
Warp4 to run with multiple cores without investing additional effort
(and SW). And using only 1 out of 8 cores is not a solution for me.
OS2APIC.PSD is a mess and has never worked for more than a handful of
machines. It's also outdated by now as much of the functionality has now
been taken over by ACPI and therefore the old Intel MP configuration
table (according to the original Intel Multiprozessor spec version 1.4)
in BIOS that OS2APIC.PSD makes use of is often outdated or buggy (ACPI
comes with a new set of tables that mostly replaces that stuff).
Lars

Probably the reason for the existence of acpi4.sys in the OS/4 package.

Regards

Pete

Post by Lars Erdmann

Post by Pete
Hi Dave

Post by Dave Yeo

Post by Lars Erdmann
In my opinion Warp4 is just too outdated. How would you run Warp4 on an
ACPI system and fully exploit its capabilities if it is a multi-core
machine (which is standard nowadays) ?

Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.
Dave

I seem to recall something like that from my early attempts to get an
AMD 64x2 cpu working with os2apic.psd.
If I remember correctly the answer was to use the OS/4 kernel and loader
package, some info about the package here
http://www.os2world.com/wiki/index.php/Phoenix_OS/4
Regards
Pete

[Dave Yeo]

Post by Pete
Hi Dave

Post by Dave Yeo

Post by Lars Erdmann
In my opinion Warp4 is just too outdated. How would you run Warp4 on an
ACPI system and fully exploit its capabilities if it is a multi-core
machine (which is standard nowadays) ?

Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.
Dave

I seem to recall something like that from my early attempts to get an
AMD 64x2 cpu working with os2apic.psd.
If I remember correctly the answer was to use the OS/4 kernel and loader
package, some info about the package here
http://www.os2world.com/wiki/index.php/Phoenix_OS/4

Last time I tried that it crashed slightly quicker and without a way to
get a serial log output...
Current computer does have a serial port but it's the only one in the
house so still hard to get a log.
Dave

[T.]

Hi Dave,

Post by Dave Yeo
Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.

so seems not to work correctly.

And if you are (only) using Warp4 you don't have a license to use the
SMP stuff, no TCPIP32, no JFS and much more.

So nowadays, an MCP2r (aka Warp 4.52) or eCS 1.2R should be the minimum
on everything that does not support the legacy IBM APM anymore!


If you have older hardware with just one core, like a Pentium M (e.g.
ThinkPad T40-/X30-Series) plus a working SciTech SDD/Snap, Warp 4 will
run quite well without all the ACPI and Panorama trash!

Anyway, MCP2r would run even better ...

[Dave Yeo]

Post by T.
Hi Dave,

Post by Dave Yeo
Arca Noae's ACPI package is quite happy to run on Warp v4+fp15+SMP
kernel etc though enabling more then one core results in traps here.

so seems not to work correctly.
And if you are (only) using Warp4 you don't have a license to use the
SMP stuff, no TCPIP32, no JFS and much more.

I also have a license for eCS 2.1, aka Warp 4.52.
There is a free TCPIP32 available for Warp V3 & V4

Dave

[Paul Ratcliffe]

Post by T.
And if you are (only) using Warp4 you don't have a license to use the
SMP stuff, no TCPIP32, no JFS and much more.

JFS came with Warp 4.

[A.D. Fundum]

Post by T.
If you have older hardware with just one core, like a Pentium M
(e.g. ThinkPad T40-/X30-Series)

Software which fully presumes the use of eCS 2.x is a problem, but
w.r.t sustainability having to depend on "older" hardware is a problem
too. Even Pentium IV-hardware is quite old now. Too old for Windows
retry #10, for example. In general, ye olde problem is that eCS 2.x
isn't as GA as possible (yet). Unless English and German are suddenly
representing G.

eCS 2.x: only sold with DE/EN licenses.
eCS 1.x: requires "older" hardware.

Ich verstehe "elektronischKommunikationBahnhof Zwei punkt x" im
Deutsch (and, FWIW, Erdmann's earlier essay-length instructions in
English) , for one by recognizing icons, but that doesn't mean that I
want e.g. eCS 2.x DE. It's not a serious option for new nor old
hardware. My preferred language is one of the (informally) announced
ones. I am/was hoping that the last version of eCS 2.x will/would be
as GA as possible/announced.

No matter what, even if FF for eCS 2.x would be twice as fast as FF/2,
then I'd easily rate FF for eCS 2.x as the worst OS/2 and eCS software
ever published. The number of foolish, extreme decisions of developers
using eCS 2.x does exceed one, and it's hard to imagine that "unified"
FF DLLs are that important.


--

[A.D. Fundum]

If not, then where can those DLL files be found nowadays?

Any "solution" assumes that there's, for example, a defined UNIXROOT,
i.e. post-eCS 1.x installs, so I stopped reading and caring too. I'm
not using Unix, and I'm not going to install reiuqrements of
requirements of requirements of requirements of requirements of
requirements of rather useless requirements.

For now I'll stop updating and, eventually, using FF. Well, unless
there happens to be an acceptable solution (possibly including, but
not limited to eCS 3) for a single release.

Excuse me for starting this thread. I did miss the documented "YUM
nspr"-part, was too suprised and don't create accounts to report
assumed bugs.

I really hope that the remaining users of updates of FF are happy with
whatever the added value of not including required DLLs may be. A new
NLV version of eCS may force me to move towards this happy world too,
but right now eCS 2.x isn't an option.


--

[Pete]

Hi

Post by A.D. Fundum

If not, then where can those DLL files be found nowadays?

Any "solution" assumes that there's, for example, a defined UNIXROOT,
i.e. post-eCS 1.x installs, so I stopped reading and caring too. I'm
not using Unix, and I'm not going to install reiuqrements of
requirements of requirements of requirements of requirements of
requirements of rather useless requirements.
For now I'll stop updating and, eventually, using FF. Well, unless
there happens to be an acceptable solution (possibly including, but
not limited to eCS 3) for a single release.
Excuse me for starting this thread. I did miss the documented "YUM
nspr"-part, was too suprised and don't create accounts to report
assumed bugs.
I really hope that the remaining users of updates of FF are happy with
whatever the added value of not including required DLLs may be. A new
NLV version of eCS may force me to move towards this happy world too,
but right now eCS 2.x isn't an option.

I don't think there will be another eCS release. Not sure what languages
the Arca Noae ArcaOS5 (aka Blue Lion) release will support
https://www.arcanoae.com/blue-lion/ but you can always use the "contact
us" to ask.


Regards

Pete

[A.D. Fundum]

where can those DLL files be found nowadays?

Only this time copying the following files from the latest SM for OS/2
to FF for eCS 2.x seems to work:

nspr4.*
nss3.*
nssutil3.*
plc4.*
plds4.*
smime3.*
ssl3.*


--

[A.D. Fundum]

Post by A.D. Fundum
copying the following files from the latest SM for OS/2

FTR: untested, it just starts and some sites may work . It will fail
with secure sites. So at the moment 38.2.1 may be the last version of
FF which had OS/2 or eCS 1.x in mind, and doesn't fully presume the
use of eCS 2.x.


--