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?


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 31.05.16 um 12.37 schrieb 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?

--

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 31 May 2016 12:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de>
wrote:

Am 31.05.16 um 12.37 schrieb 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?

--

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

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
--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lars Erdmann wrote:

Am 31.05.16 um 12.37 schrieb 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?


--

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.

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 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.

(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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 31 May 2016 14:54:07 UTC, "ivan" <ivanjt@free.fr> wrote:

On Tue, 31 May 2016 12:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de>
wrote:

Am 31.05.16 um 12.37 schrieb 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?

--

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

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).

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.

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.

--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Doug Bissett wrote:

On Tue, 31 May 2016 14:54:07 UTC, "ivan" <ivanjt@free.fr> wrote:

On Tue, 31 May 2016 12:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de>
wrote:

Am 31.05.16 um 12.37 schrieb 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?


--

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

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).

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.

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.

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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


Am 31.05.16 um 16.54 schrieb ivan:

On Tue, 31 May 2016 12:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de>
wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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... :-)

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lars Erdmann wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 1 Jun 2016 05:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de>
wrote:

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

Am 31.05.16 um 16.54 schrieb ivan:

On Tue, 31 May 2016 12:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

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
--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ivan wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 31 May 2016 16:10:35 UTC, "Doug Bissett"
<dougb007!SPAM@telus.net> wrote:

On Tue, 31 May 2016 14:54:07 UTC, "ivan" <ivanjt@free.fr> wrote:

On Tue, 31 May 2016 12:51:44 UTC, Lars Erdmann <lars.erdmann@arcor.de> wrote:

Am 31.05.16 um 12.37 schrieb 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?

--

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

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).

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.

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
--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ivan wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 1 Jun 2016 17:19:20 UTC, "ivan" <ivanjt@free.fr> wrote:

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.

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.
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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...


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

If you want to:
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?

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A.D. Fundum wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A.D. Fundum wrote:

> If you want to:
> 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.

> 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.

> 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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

A.D. Fundum wrote:

> If you want to:
> 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

> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi

A.D. Fundum wrote:

> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.*


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 3 Jun 2016 18:42:47 UTC, "A.D. Fundum" <what.ever@neverm.ind>
wrote:

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.

--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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


Am 03.06.16 um 20.42 schrieb A.D. Fundum:

> 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.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 1 Jun 2016 17:54:44 -0700, Dave Yeo <dave.r.yeo@gmail.com> wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lars Erdmann wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Dave

Dave Yeo wrote:

Lars Erdmann wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

...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


Am 05.06.16 um 02.45 schrieb Pete:

Hi Dave

Dave Yeo wrote:

Lars Erdmann wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Dave,

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 ...
--

Gruesse,

Thorolf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lars Erdmann schrieb:

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!
--

Gruesse,

Thorolf

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pete wrote:

Hi Dave

Dave Yeo wrote:

Lars Erdmann wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T. wrote:

Hi Dave,

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Lars

Lars Erdmann wrote:

...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

Am 05.06.16 um 02.45 schrieb Pete:

Hi Dave

Dave Yeo wrote:

Lars Erdmann wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 5 Jun 2016 14:24:37 +0200, T. <nospam@godawa.invalid> wrote:

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)... :-)


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.


--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

A.D. Fundum wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05/31/16 10:16 pm, Dave Yeo wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/01/16 12:39 am, A.D. Fundum wrote:

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?

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/06/16 11:48 pm, Dave Yeo wrote:

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

Wholeheartedly agreed. :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/02/16 09:05 pm, Dave Yeo wrote:

> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/11/16 03:06 pm, Steve Wendt wrote:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Steve Wendt wrote:

On 06/01/16 12:39 am, A.D. Fundum wrote:

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?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Steve Wendt wrote:

On 06/02/16 09:05 pm, Dave Yeo wrote:

> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 12 Jun 2016 05:07:25 UTC, Dave Yeo <dave.r.yeo@gmail.com>
wrote:

Steve Wendt wrote:

On 06/02/16 09:05 pm, Dave Yeo wrote:

> 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
--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)