CPU Type field in LX header

[David Parsons]

Hello all,

I upgraded a few DLLs used by Firefox & co to i686 standard recently and noticed
a significant performance improvement so I'm now want to update the rest to i686
also. I've been able to do some with the help of ANPM (it would be easier if
ANPM showed individual file dates & size) but I can not find a way to tell what
standard a particular file is at.

There is a field in the LX header which specifies the CPU Type but all files
show i386 even though I believe that many are at i686.
I've complied a test program here with 'gcc -march=i686 test.c' which compiles
and runs successfully but it also shows the CPU type as i386.
Could it be that the -march switch is silently ignored in our gcc builds?
For the record I used gcc v4.5.2.

I've searched on the internet and read though many pages of switches available
for gcc but not found anything other than march & mtune.

Does anyone know if there are any other switches I should use or have any advice?

Regards,
Dave P.

[Doug Bissett]

On Sat, 22 Oct 2016 16:49:08 UTC, David Parsons
<dwpa...@t-online.de> wrote:

> Hello all,
>
> I upgraded a few DLLs used by Firefox & co to i686 standard recently and noticed
> a significant performance improvement so I'm now want to update the rest to i686
> also. I've been able to do some with the help of ANPM (it would be easier if
> ANPM showed individual file dates & size) but I can not find a way to tell what
> standard a particular file is at.

Using the YUM command line should tell you what you have installed.

Or, add "/DUP" as a parameter to ANPM. Just be careful what you select
when you install things.

ANPM has an outstanding request to add a feature to be able to change
between versions, but it has not been done yet. Note that file date &
size means nothing, and individual files seem to have no information
about what version they are (no BLDLEVEL information). Some of them,
apparently, have a way to query their version, but it seems that it is
inconsistent, and you need to know exactly how to do it for different
files.

> There is a field in the LX header which specifies the CPU Type but all files
> show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which compiles
> and runs successfully but it also shows the CPU type as i386.
> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.
>
> I've searched on the internet and read though many pages of switches available
> for gcc but not found anything other than march & mtune.
>
> Does anyone know if there are any other switches I should use or have any advice?

Wait for the ANPM update, I guess, although YUM has an add on that
will do it when you use the command line (which is how ANPM will do
it). Sorry, I don't remember what it is called.

> Regards,
> Dave P.


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

[Dave Yeo]

David Parsons wrote:
> Hello all,
>
> I upgraded a few DLLs used by Firefox & co to i686 standard recently and
> noticed a significant performance improvement so I'm now want to update
> the rest to i686 also. I've been able to do some with the help of ANPM
> (it would be easier if ANPM showed individual file dates & size) but I
> can not find a way to tell what standard a particular file is at.
>
> There is a field in the LX header which specifies the CPU Type but all
> files show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which
> compiles and runs successfully but it also shows the CPU type as i386.
> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.

Our GCC's understand -march (at least as current when released) and
-mtune fine and for almost all CPU's i686 is a much better choice as it
includes a few needed instructions for things like atomic operations and
perhaps more importantly aligns the instructions such that modern CPU's
perform much better.
You can test by targeting a newer CPU then you're using (might need
floating point code) and getting a sigill (illegal instruction).
A while back I built a SM targeted at my desktop C2D and it wouldn't run
on P4's and built a TB targeted at my laptop's Pentium M which ran most
everywhere.
Targeting a CPU with SSE2+ instructions really helps floating point math
as it is done with the SSE+ instructions and registers instead of the
i387+ co-processor.
Our GCC does have a bug with SSE+ instructions, it doesn't align them
properly unless forced with -mstackrealign (there's also
-mpreferred-stack-boundary=4)

>
> I've searched on the internet and read though many pages of switches
> available for gcc but not found anything other than march & mtune.
>
> Does anyone know if there are any other switches I should use or have
> any advice?
>

It's the linkers job to set fields in the LX header, all GCC does is
produce the correct assembly code and obj files and ask the linker to
link them into an executable (or DLL).
Wlink could be patched (perhaps already is?) to use i686 in the CPU
field but I don't know if the kernel would be happy to load something
besides i386. I guess it would be easy enough to use a hex editor to
test and if it works, to file a feature request bug.
Ideally our uname should be updated to report -i686 as well so the
toolchain automatically targets it
Dave

[Dave Yeo]

David Parsons wrote:
> Hello all,
>
> I upgraded a few DLLs used by Firefox & co to i686 standard recently and
> noticed a significant performance improvement so I'm now want to update
> the rest to i686 also. I've been able to do some with the help of ANPM
> (it would be easier if ANPM showed individual file dates & size) but I
> can not find a way to tell what standard a particular file is at.
>
> There is a field in the LX header which specifies the CPU Type but all
> files show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which
> compiles and runs successfully but it also shows the CPU type as i386.
> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.

Our GCC's understand -march (at least as current when released) and
-mtune fine and for almost all CPU's i686 is a much better choice as it
includes a few needed instructions for things like atomic operations and
perhaps more importantly aligns the instructions such that modern CPU's
perform much better.
You can test by targeting a newer CPU then you're using (might need
floating point code) and getting a sigill (illegal instruction).
A while back I built a SM targeted at my desktop C2D and it wouldn't run
on P4's and built a TB targeted at my laptop's Pentium M which ran most
everywhere.
Targeting a CPU with SSE2+ instructions really helps floating point math
as it is done with the SSE+ instructions and registers instead of the
i387+ co-processor.
Our GCC does have a bug with SSE+ instructions, it doesn't align them
properly unless forced with -mstackrealign (there's also
-mpreferred-stack-boundary=4)

>

> I've searched on the internet and read though many pages of switches
> available for gcc but not found anything other than march & mtune.
>
> Does anyone know if there are any other switches I should use or have
> any advice?
>

[Marcel Mueller]

On 22.10.16 18.49, David Parsons wrote:
> There is a field in the LX header which specifies the CPU Type but all
> files show i386 even though I believe that many are at i686.
> I've complied a test program here with 'gcc -march=i686 test.c' which
> compiles and runs successfully but it also shows the CPU type as i386.

I would not bet that OS/2 will execute anything else.

> Could it be that the -march switch is silently ignored in our gcc builds?
> For the record I used gcc v4.5.2.

AFAIK march is working as expected.


Marcel

[Marcel Mueller]

On 22.10.16 19.48, Dave Yeo wrote:
>> There is a field in the LX header which specifies the CPU Type but all
>> files show i386 even though I believe that many are at i686.
>> I've complied a test program here with 'gcc -march=i686 test.c' which
>> compiles and runs successfully but it also shows the CPU type as i386.
>> Could it be that the -march switch is silently ignored in our gcc builds?
>> For the record I used gcc v4.5.2.
>
> Our GCC's understand -march (at least as current when released) and
> -mtune fine and for almost all CPU's i686 is a much better choice as it
> includes a few needed instructions for things like atomic operations and
> perhaps more importantly aligns the instructions such that modern CPU's
> perform much better.

Most atomic instructions are available since 486. Only 64 and 128 bit
atomics are introduced later.

But modern CPUs cannot be classified by a single scalar value anymore.
Some features also get removed with newer ones. Others depend on the
manufacturer or product line.

> You can test by targeting a newer CPU then you're using (might need
> floating point code) and getting a sigill (illegal instruction).
> A while back I built a SM targeted at my desktop C2D and it wouldn't run
> on P4's and built a TB targeted at my laptop's Pentium M which ran most
> everywhere.

Using march has its drawbacks. If you target to a specific CPU type you
cannot assume that it runs on everything newer.

> Targeting a CPU with SSE2+ instructions really helps floating point math
> as it is done with the SSE+ instructions and registers instead of the
> i387+ co-processor.

And it sadly fails on some non Intel CPUs.


Marcel

[A.D. Fundum]

> And it sadly fails on some non Intel CPUs.

Only optimize if you have to, without introducing avoidable implicit
requirements. Don't optimize "because it's faster/cool". Ignoring
Mozilla's latest SSE2 restrictions, a Pentium II is a good bottom line
for FF/SM/TB because of the installable memory, but not because of the
CPU.

I'ld recommend to use a compier's default, without having to document
the requirements. If each 1% may count (video, mdern browser, and so
on)(, then try to select a Pentium II. If you're requiring a CPU newer
than a Pentium 4, then you've lost most of the OS/2
community.Silently. In most of the world's languages there's no such
thing as OS/2/eCS for modern hardware.


--

[Paul Smedley]

Hi Dave,

On 23/10/16 04:18, Dave Yeo wrote:
> Our GCC does have a bug with SSE+ instructions, it doesn't align them
> properly unless forced with -mstackrealign (there's also
> -mpreferred-stack-boundary=4)

This might be fixed in GCC 6.x - do you have a simple testcase?

Cheers,

Paul

[Dave Yeo]

Marcel Mueller wrote:
> On 22.10.16 19.48, Dave Yeo wrote:
>>> There is a field in the LX header which specifies the CPU Type but all
>>> files show i386 even though I believe that many are at i686.
>>> I've complied a test program here with 'gcc -march=i686 test.c' which
>>> compiles and runs successfully but it also shows the CPU type as i386.
>>> Could it be that the -march switch is silently ignored in our gcc
>>> builds?
>>> For the record I used gcc v4.5.2.
>>
>> Our GCC's understand -march (at least as current when released) and
>> -mtune fine and for almost all CPU's i686 is a much better choice as it
>> includes a few needed instructions for things like atomic operations and
>> perhaps more importantly aligns the instructions such that modern CPU's
>> perform much better.
>
> Most atomic instructions are available since 486. Only 64 and 128 bit
> atomics are introduced later.

That's true, but if targeting i486, why not target i686? I started
targeting i686 during the Mozilla 10ESR cycle and have yet to have a
complaint about sigills or anything similar. Seems that most every OS/2
user has something that handles i686 instructions though there are
questions about things like cmov, which is fast on some processors and
really slow on others. Not sure if GCC uses cmov when targeting i686.

>
> But modern CPUs cannot be classified by a single scalar value anymore.
> Some features also get removed with newer ones. Others depend on the
> manufacturer or product line.

Interesting, do you know of any examples?

>
>
>> You can test by targeting a newer CPU then you're using (might need
>> floating point code) and getting a sigill (illegal instruction).
>> A while back I built a SM targeted at my desktop C2D and it wouldn't run
>> on P4's and built a TB targeted at my laptop's Pentium M which ran most
>> everywhere.
>
> Using march has its drawbacks. If you target to a specific CPU type you
> cannot assume that it runs on everything newer.
>
>> Targeting a CPU with SSE2+ instructions really helps floating point math
>> as it is done with the SSE+ instructions and registers instead of the
>> i387+ co-processor.
>
> And it sadly fails on some non Intel CPUs.

Do you mean ones like Athlon that never supported SSE? Anyways I'd
generally stick to something like i686 if distributing and perhaps also
add something that targeted newer CPU's such as the couple of test
builds of SM and TB I did.

Dave

[Dave Yeo]

I'd argue that many people have something newer then a P4 though I
wouldn't target anything newer except as an alternative.
IIRC, even a PII supports more instructions then an Athlon, though on
the other hand, an Athlon has 3DNOW! which is similar to SSE and an
example of something that has gone away.
The big advantage of targeting i686 is aligning the instructions on word
boundaries, which should benefit most all newer CPU's
Dave

[Dave Yeo]

You should be able to just do some floating point math and compile with
-msse2 -mfpmath=sse and see if it crashes with the xmms registers not
aligned. Might want to target a newer architecture as well.
Dave

[A.D. Fundum]

> That's true, but if targeting i486, why not target i686?

Why target i686? Typically you'll have to document it, because OS/2 is
i386+. Or rename a product to "... for eCS". eCS is i686+.

> I started targeting i686 during the Mozilla 10ESR cycle
> and have yet to have a complaint about sigills

Mozilla is the best example why a i686 can be a good target, because
browsing with a i486 would be "insane". But there's no reason why a
CONFIG.SYS sorter should target the i686 family.

> Seems that most every OS/2 user has something that handles
> i686 instructions

You'ld use older $5 hardware for specific apps which have stopped
working, for example due to required old native video drivers.

If using involves browsing of third-party websites, then a i686 is the
bottom line because of the installable memory. If a i686 would be the
default of GCC, then remaining users won't complain indeed, and owners
of old hardware will be familiar with such a PITA.

OTOH I'm not using the latest FF due to the assumed eCS 2.x
environment, so I've left your Mozilla for OS/2 community "silently".

In a nutshell, a 386 is the best default target. Same as the OS.
That's why. Otherwise it should be documented as a specific
requirement. If your users are probably using a modern browser,
including video, and your app requires power (video) or each 1% counts
(video), then a i686 can be a documented option. You won't even use a
i686 to watch a video. If you assume the use of anything newer than a
Pentium III, then people will leave your community silently. If the
developer assumes the use of at least two cores, then even more people
will leave the community silently. FF49+ requires a Pentium 4 or
newer. AFAIK the latest FF for OS/2 assumes eCS 2, which comes down to
reducing the community too.

In 99.99% of all cases, rounded up to 100%, I won't notice the use of
a i686 setting. I may not be aware of a marginal speed gain, and I'll
be using a i686+. Hence no complaints. But programmers should document
it, because the technical bottom line of the environment is OS/2's
386. Unless the use of a i686+s bleedin' obvious, like a browser which
requires a little bit more RAM than the 32'ish MB of a 486. The
required memory requires a i686 or newer. FF38 works with a i686 CPU
or with a Pentium 4.

Or stop writing software for OS/2 and finally start writing software
for eCS. eCS comes down to i686+, and users of OS/2 Warp 4 FP9 will
be aware of restrictions, including possibly required APIs. An
acceptable bottom line of OS/2 FP versions is the Y2K FP.

BTW, internet services which require a registration of users to report
bugs will also reduce the number of complaints.


--

[A.D. Fundum]

> many people have something newer then a P4 though

> wouldn't target anything newer except as an alternative.

The latest FF assumes an eCS 2.x environment, which you'll have to buy
for anything newer than a Pentium 4.

> The big advantage of targeting i686 is aligning the instructions
> on word boundaries, which should benefit most all newer CPU's

So start writing software for eCS. AFAICT this always implies the use
of a i686+. The remaining users of OS/2, including the well-known and
appriciated Korean FP15 example, will be aware of possible problems.

With a "SeaMonkey for eCS", the bottom line is a i686. But please use
386 as a target for a CONFIG.SYS sorter for OS/2. Typically I'll use
the default setting of VAC, a 386, despite of the fact that even I
don't have a 386. AFAIK the installer of eCS requires a i686, so eCS
is a clear generic threshold and it implies the use of a i686+ CPU.

If your software assumes an eCS 2 environment (YUK installer, and so
on), then "SeaMonkey for eCS 2" will be better and clear. Lenovo is
the threshold. All of my OS/2 or eCS hardware in use is still IBM, 486
upto and including a Pentium 4. I'm still waiting for a translated eCS
2+...

The bottom line of M$ Windows updates with FF49+ updates
(SSE2-related) is a Pentium 4. The main reasons why I won't complain
about a FF49 for eCS 2.x+ (i.e. a eCS 2.x environment) is because ...
I'm not using it.

Anyway, I'ld suggest to use a compiler's default target. If it has a
real use, then target a i686 (100% CPU load, video, significant speed
gains), then perhaps rename your product to "<name> for eCS". But
please don't target a i686 just because you've studied and understood
compiler switches without a significant gain.


--

[Lars Erdmann]

I am fairly sure that the linker is supposed to correctly set this field.
But I would not be surprised if any linker ever written for OS/2 just
ignores to properly set this field.

Additionally the LX spec only defines these values for CPU type:

01H - 80286 or upwardly compatible CPU is required to execute this
module.
02H - 80386 or upwardly compatible CPU is required to execute this
module.
03H - 80486 or upwardly compatible CPU is required to execute this
module.

That said, a 16-bit OS/2 linker will likely set this field to 01h
whereas a 32-bit OS/2 linker will set it to 02h just to indicate that a
32-bit CPU is needed as a 16-bit CPU is not enough for OS/2 >= version 2.0.

Anything higher than a 486 is therefore undefined in the standard.
I don't think you can rely on anything set in this field.


Lars


Am 22.10.16 um 18.49 schrieb David Parsons:

[David Parsons]

I have version 10 of that spec from 1996 and that is what it seems like to me.
I have read lots of switches for the various linkers we have and found nothing
to imply that any of them use the -march setting.

It looks as though I am out of luck unless anyone knows of another way to tell
how an exe or dll was compiled.

Dave P.

[David Parsons]

On 22-10-16 19:32, Doug Bissett wrote:
> On Sat, 22 Oct 2016 16:49:08 UTC, David Parsons
> <dwpa...@t-online.de> wrote:
>
>> Hello all,
>>
>> I upgraded a few DLLs used by Firefox & co to i686 standard recently and noticed
>> a significant performance improvement so I'm now want to update the rest to i686
>> also. I've been able to do some with the help of ANPM (it would be easier if
>> ANPM showed individual file dates & size) but I can not find a way to tell what
>> standard a particular file is at.
>
> Using the YUM command line should tell you what you have installed.
>
> Or, add "/DUP" as a parameter to ANPM. Just be careful what you select
> when you install things.
>
> ANPM has an outstanding request to add a feature to be able to change
> between versions, but it has not been done yet. Note that file date &
> size means nothing, and individual files seem to have no information
> about what version they are (no BLDLEVEL information). Some of them,
> apparently, have a way to query their version, but it seems that it is
> inconsistent, and you need to know exactly how to do it for different
> files.
>

Yes, bldlevel would be best if it was guaranteed to be updated whenever anything
changed, including the build flags, but that would mean a lot of extra work for BWW.
I appreciate that using the date & size information is not foolproof but it
would be correct in most cases and requires little extra work.

What does the /DUP switch do, is there a list of switches available anywhere?

Dave P.

[David Parsons]

On 22-10-16 19:48, Dave Yeo wrote:
>
> Our GCC's understand -march (at least as current when released) and -mtune fine
> and for almost all CPU's i686 is a much better choice as it includes a few
> needed instructions for things like atomic operations and perhaps more
> importantly aligns the instructions such that modern CPU's perform much better.
> You can test by targeting a newer CPU then you're using (might need floating
> point code) and getting a sigill (illegal instruction).
> A while back I built a SM targeted at my desktop C2D and it wouldn't run on P4's
> and built a TB targeted at my laptop's Pentium M which ran most everywhere.
> Targeting a CPU with SSE2+ instructions really helps floating point math as it
> is done with the SSE+ instructions and registers instead of the i387+ co-processor.
> Our GCC does have a bug with SSE+ instructions, it doesn't align them properly
> unless forced with -mstackrealign (there's also -mpreferred-stack-boundary=4)
>

> It's the linkers job to set fields in the LX header, all GCC does is produce the
> correct assembly code and obj files and ask the linker to link them into an
> executable (or DLL).
> Wlink could be patched (perhaps already is?) to use i686 in the CPU field but I
> don't know if the kernel would be happy to load something besides i386. I guess
> it would be easy enough to use a hex editor to test and if it works, to file a
> feature request bug.
> Ideally our uname should be updated to report -i686 as well so the toolchain
> automatically targets it
> Dave

Agreed, but it has to be told somehow. I had hoped the compiler would pass the
information on to the linker but if it does, it seems the linker ignores it.

Out of curiosity I patched the CPU Type field of my test program to i486, i586,
i686 and i786 and they all compiled and ran successfully even the non-existent i786.

Dave P.

[Marcel Mueller]

On 23.10.16 18.45, David Parsons wrote:
> Out of curiosity I patched the CPU Type field of my test program to
> i486, i586, i686 and i786 and they all compiled and ran successfully
> even the non-existent i786.

So OS/2 probably ignores the field.


Marcel

[Dave Yeo]

A.D. Fundum wrote:
> > many people have something newer then a P4 though
> > wouldn't target anything newer except as an alternative.
>
> The latest FF assumes an eCS 2.x environment, which you'll have to buy
> for anything newer than a Pentium 4.

The latest FF, which Bitwise compiled to target a i486 due to the need
for the GCC atomics, runs fine on my OS/2 ver 4+fp15 system though with
only one core working on my C2D.
At that my first C2D system was a P4 until I replaced the CPU. The
1.86Ghz C2D was almost twice as fast as the 2.8Ghz P4. I did end up
buying eCS2.1 so I could take advantage of both cores as Warp V4 has too
many none SMP safe libraries.

>
> > The big advantage of targeting i686 is aligning the instructions
> > on word boundaries, which should benefit most all newer CPU's
>
> So start writing software for eCS. AFAICT this always implies the use
> of a i686+. The remaining users of OS/2, including the well-known and
> appriciated Korean FP15 example, will be aware of possible problems.

I target my Warp V4+fp15+other free fixes such as the 32 bit stack.

>
> With a "SeaMonkey for eCS", the bottom line is a i686. But please use
> 386 as a target for a CONFIG.SYS sorter for OS/2. Typically I'll use
> the default setting of VAC, a 386, despite of the fact that even I
> don't have a 386. AFAIK the installer of eCS requires a i686, so eCS
> is a clear generic threshold and it implies the use of a i686+ CPU.

IIRC, even the later refresh of Warp V4 needs an i486 to install, or
perhaps that was Warp Server.

>
> If your software assumes an eCS 2 environment (YUK installer, and so
> on), then "SeaMonkey for eCS 2" will be better and clear. Lenovo is
> the threshold. All of my OS/2 or eCS hardware in use is still IBM, 486
> upto and including a Pentium 4. I'm still waiting for a translated eCS
> 2+...

Are you using the 486? I'd assume that it wouldn't support enough memory
to run Mozilla.

>
> The bottom line of M$ Windows updates with FF49+ updates
> (SSE2-related) is a Pentium 4. The main reasons why I won't complain
> about a FF49 for eCS 2.x+ (i.e. a eCS 2.x environment) is because ...
> I'm not using it.
>
> Anyway, I'ld suggest to use a compiler's default target. If it has a
> real use, then target a i686 (100% CPU load, video, significant speed
> gains), then perhaps rename your product to "<name> for eCS". But
> please don't target a i686 just because you've studied and understood
> compiler switches without a significant gain.
>

Generally when I port something, I do target the default i386 unless
there is a reason to target newer. Atomic operations is one reason I've
been forced to target newer. The atomic code is needed to make sure only
one thread accesses a data structure at a time. Especially important in
a SMP system and there are i686/PII SMP systems out there that can run
Warp Server 2.1SMP.
Dave

[Dave Yeo]

A.D. Fundum wrote:
> > That's true, but if targeting i486, why not target i686?
>
> Why target i686? Typically you'll have to document it, because OS/2 is
> i386+. Or rename a product to "... for eCS". eCS is i686+.

WarpV4.5, aka FP13+, needs at least a 486SX and some kernels were broken
and needed a 486.
Is anyone using Warp V4 FP12 or Warp V3? At least for general use.

>
> > I started targeting i686 during the Mozilla 10ESR cycle
> > and have yet to have a complaint about sigills
>
> Mozilla is the best example why a i686 can be a good target, because
> browsing with a i486 would be "insane". But there's no reason why a
> CONFIG.SYS sorter should target the i686 family.

You're right about the CONFIG.SYS sorter and If I was compiling one, I'd
use the defaults.
Note that according to the readme from the later kernels, an i686
(Pentium Pro) is required to access more then 64MBs of memory using the
int15 func e820 to avoid problems on older CPU's.

>
> > Seems that most every OS/2 user has something that handles
> > i686 instructions
>
> You'ld use older $5 hardware for specific apps which have stopped
> working, for example due to required old native video drivers.

How many are using such old hardware and need to run new binaries?
I'm also pretty sure that most developers would build a 386 version on
request. I know I would.

>
> If using involves browsing of third-party websites, then a i686 is the
> bottom line because of the installable memory. If a i686 would be the
> default of GCC, then remaining users won't complain indeed, and owners
> of old hardware will be familiar with such a PITA.
>
> OTOH I'm not using the latest FF due to the assumed eCS 2.x
> environment, so I've left your Mozilla for OS/2 community "silently".

FF runs fine on my Warp V4 (all free updates installed) system, though I
can only use one core.

>
> In a nutshell, a 386 is the best default target. Same as the OS.

Actually it seems a 486SX is the minimum for Warp V4+fp15

> That's why. Otherwise it should be documented as a specific
> requirement. If your users are probably using a modern browser,
> including video, and your app requires power (video) or each 1% counts
> (video), then a i686 can be a documented option. You won't even use a
> i686 to watch a video. If you assume the use of anything newer than a
> Pentium III, then people will leave your community silently. If the
> developer assumes the use of at least two cores, then even more people
> will leave the community silently. FF49+ requires a Pentium 4 or
> newer. AFAIK the latest FF for OS/2 assumes eCS 2, which comes down to
> reducing the community too.

FF for OS/2 assumes Warp V4 + all free fixes and various ported
libraries including some that require GCC atomics which use instructions
introduced with a 486. If you go to about:build on a Bitwise build of
FF, you'll see they targeted i486 with generic tuning. Some of the
libraries are only available for i686 but could be recompiled for i486.
While there is code that will take advantage of multiple cores, it is
not a requirement. Videos and such run fine on my Warp v4.5 system with
one core.

>
> In 99.99% of all cases, rounded up to 100%, I won't notice the use of
> a i686 setting. I may not be aware of a marginal speed gain, and I'll
> be using a i686+. Hence no complaints. But programmers should document
> it, because the technical bottom line of the environment is OS/2's
> 386. Unless the use of a i686+s bleedin' obvious, like a browser which
> requires a little bit more RAM than the 32'ish MB of a 486. The
> required memory requires a i686 or newer. FF38 works with a i686 CPU
> or with a Pentium 4.
>
> Or stop writing software for OS/2 and finally start writing software
> for eCS. eCS comes down to i686+, and users of OS/2 Warp 4 FP9 will
> be aware of restrictions, including possibly required APIs. An
> acceptable bottom line of OS/2 FP versions is the Y2K FP.
>
> BTW, internet services which require a registration of users to report
> bugs will also reduce the number of complaints.

Unluckily with a lot of bug reporting software, it's hard to avoid the
registration thing. Even mailing lists need an email address. Personally
I'll monitor the newsgroups as long as I can.
Dave

[Dave Yeo]

Using the recommended LDFLAGS=-Zomf, emxomfld would have to understand
and pass on the information to the linker and the linker would need to
understand it. Emxomfld and the OpenWatcom linker could probably be
fixed to make it work if someone is interested in doing the work. Steven
has commit access to OpenWatcom.

>
> Out of curiosity I patched the CPU Type field of my test program to
> i486, i586, i686 and i786 and they all compiled and ran successfully
> even the non-existent i786.
>

That's interesting.
Dave

[Dave Yeo]

There's also the question of whether OS/2 actually supports SSE.
A testcase that was suggested to me was running the Flac testsuite in
twice as many sessions as the number of enabled cores. While one session
passed the testcase, multiple sessions failed until only one was left
which passed.
This implies that the OS/2 kernel does not save the XMMS registers
during a context switch and SSE (and MMX?) code will fail if more then
one thread accesses the XMMS registers
Dave

[Peter Flass]

The OMF spec includes optional comments that often will include the
compiler and options used for the compile. I don't know enough about LX
format to say whether any of that carries over.

--
Pete

[A.D. Fundum]

> that would mean a lot of extra work for BWW.

If BWW is involved, they may as well rename their main product Firefox
for OS/2 to Firefox for/fuer eComStation 2.0+. This always implies the
use of a i686+ CPU.


--

[A.D. Fundum]

>> The latest FF assumes an eCS 2.x environment

> The latest FF, which Bitwise compiled to target a i486
> due to the need for the GCC atomics, runs fine on my
> OS/2 ver 4+fp15

In general it doesn't. FF + OS/2 = missing DLLs. You had to eCS 2'ify
your OS/2 system, which requires quite a few extraordinary efforts
from an user's point of view (the requirements of requirements of
requirements of requirements of required software). It will work, wehy
not, but I wouldn't sell it as OS/2 software. Your customers will
complain that they cannot find all DLLs, and the solution to obtain
those DLLs ... su^G^Gblows. Engineers (it works) vs humans. ;-)

> I did end up buying eCS2.1 so I could take advantage
> of both cores as Warp V4 has too many none SMP
> safe libraries.

I couldn't install eCS 1.2 using an IBM/Lenovo T60p after disabling
one of the cores. So far that's the only reason why I could consider
an upgrade to eCS 2 DE/EN. An outdated browser may be the next reason.

> I target my Warp V4+fp15+other free fixes such as the 32 bit stack.

Please keep in mind that you're one of the happy few, nowadays
restricted to the most active languages in this thread: DE/EN. FP15 is
not GA. There's no such thing as a GA Korean FP15 (FP5:
ftp://service.software.ibm.com/ps/products/os2/fixes/v4warp/korean/fx0
0505).

There's OS/2 (386), there's a Y2K FP (386, we've lost a few OS/2
languages back then), there are non-GA fixpaks to reduce the number of
OS/2 languages (386), there's eCS 1 (i686+, less languages), and
there's eCS 2 (i686, DE/EN only).

Hence the suggestion to rename readme.os2 and makefile.os2 to *.ecs,
to assume the use of a i686+. Users of FP15 will be aware of possible
problems. A language is a good reason to keep using such an old beast.

Off topic: I'll understand eCS 2 DE/EN, but often that comes down to
using ELF (English as a Lingua Franca). ELF, we're using it right
here, is one of the worst solutions. In our case you may have the
advantage of native language, but I may be restricted to the
vocabulary of a child, and my users may not speak English or German at
all.

> even the later refresh of Warp V4 needs an i486 to install

Retorical: GA, or only a version for the happy few?

Not retorical: it will be safe to use i486 as the bottom line, but you
should document it. I can recall one newsgroup report of 386 user,
but that was a museum piece instead of an used computer. Imn other
words, he owned a 386 but didn't use it for anything. I'm using a 486,
mainly for testing purposes. Nevertheless I'm still not using VAC's
switch /G4 to target 486, because the gain, if any, requires
documentation because it isn't a 386.

> Are you using the 486?

Yes, but of course not frequently. And I'll use Netscape instead of
FF/SM, if I would have to view a (local) HTML file. Software can stop
working, and I have even used my 486 to answer a Mozilla's font
question of Peter Weilbacher, IIRC. It also is one of my three
Warp-installs (2x 486, 1x 586), the rest is eCS 1.2.

> I'd assume that it wouldn't support enough memory
> to run Mozilla.

A pimped pentium II notebook hardly has enough memory to use the last
FF/SM for OS/2, and an animated GIF will kill the remaining
performance. In case of an "emergency" it can be used. Or, for
example, you may decide that you don't need a $1599 8THz CPU to
download a large file with a modem.

> Generally when I port something, I do target the default i386
> unless there is a reason to target newer.

I think video-related DLLs of FF/SM can target the i586 (supported by
IBM?) or i686+ (anything "newer than i486"?). The user of an
unofficial Korean FP15 could still develop it, and it requires hardly
more than renaming *.OS2 to *.eCS. And a fully working compiler
switch.

A Pentium 4 is hardly fast enough to watch modern HQ videos. A PIII
may still work. You don't grab a PII to watch a video.

Off topic:iIt would help if I was able to disable the second core and
use newer hardware than 10+ years old Pentium IIs-4s, but the eCS 1.2
installer seems to stop after displaying the blue eCS logo and after
disabling the second core.


--

[A.D. Fundum]

> Is anyone using Warp V4 FP12 or Warp V3?
> At least for general use.

Wrong question, FP12 is not GA, i.e. not "general". See my other post,
you're one of the happy few and we've lost most of the other people.
Silently. The last GA Korean FP is FP5. GA FP milestones are Warp 4
("FP0", all languages) and the Y2K fixpak (some languages).

As mentioned elsewhere, nobody will be actually using a 386. I can
reall one case, and "general use" wasn't true. He just owned an old
beast which still worked: 100% museum. Warp 4 may be in use by people
not speaking English that well, so they may never read our text here.

> Note that according to the readme from the later kernels,
> an i686 (Pentium Pro) is required to access more then
> 64MBs of memory using the int15 func e820 to avoid
> problems on older CPU's.

Probably confirmed: I wasn't able to install eCS using an ancient
ThinkPad 760EL with 80 MiB, so I've installed Warp 4 instead. I'm not
use if I skipped Pentium Pros.

> How many are using such old hardware and need to run new
> binaries?

Technology isn't democracy. A few users? "need" is a bit of a stretch.
Some CONFIG.SYS sorter can be a new binary. Last time I may have used
a new UNZIP.EXE to extract an IBM EWS drawing app, which wouldn't work
anymore with any newer OS version. Without having to contatc the autor
of UNZIP.EXE for OS/2 to verify if it's OS/2 software.

> most developers would build a 386 version on request.

I'm willing to advocate a 486 as the bottom line, but you'll have to
document it if you're writing software for OS/2. OS/2 = old = 386.

In general writing software for eCS addresses all of the above.

>> In a nutshell, a 386 is the best default target. Same as the OS.

> Actually it seems a 486SX is the minimum for Warp V4+fp15

Again, I'm assuming GA versions. And, sometimes, my point of view is
the point of view of an user. The requirements of requirements of
requirements of requirements of requirements of FF are Unix-solutions,
without keeping OS/2 in mind. Or it are eCS 2.x users, using DE or EN
as their language (and already having YUK/RUM). Over here I'm the
package manager, an announced translated version of eCS 2.x isn't
available yet, and "non-old" hardware isn't an option. Unfortunately,
Actually it's a problem that most of my hardware is 15'ish years old.

> I'll monitor the newsgroups as long as I can.

O, I know. Bless you. Over here most ISPs won't even offer Usenet
anymore. Even my email may stop working, according to a rather old
annoucement of my ISP (former ibm.net).


--

[A.D. Fundum]

> I'm also pretty sure that most developers would build
> a 386 version on request. I know I would.

FWIW, my informal proposal to start writing software for eCS (Pentium
Pro+) and eCS 2 (YUK/RUM) reverses this.

Write a CONFIG.SYS sorter for eCS. Users of OS/2, if any, will be
aware of that. If it doesn't work, then they could request an OS/2
version. By default it's software for eCS, so users of OS/2 have to be
"lucky" (availability of APIs/Warp v4.5/FPOs, and so on). The
developer has the freedom to assume the use of a i686+, without having
to document anything.

Technically "FF for OS/2" may still work, I won't even try to argue
with the educated expert, but "FF for eCS 2.1('s environment)" does
not rule out that OS2 and eCS 1.x are still supported too. It may be a
PITA, but it'll work.


--

[Doug Bissett]

On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons

<dwpa...@t-online.de> wrote:

> On 22-10-16 19:32, Doug Bissett wrote:
> > On Sat, 22 Oct 2016 16:49:08 UTC, David Parsons
> > <dwpa...@t-online.de> wrote:
> >
> >> Hello all,
> >>
> >> I upgraded a few DLLs used by Firefox & co to i686 standard recently and noticed
> >> a significant performance improvement so I'm now want to update the rest to i686
> >> also. I've been able to do some with the help of ANPM (it would be easier if
> >> ANPM showed individual file dates & size) but I can not find a way to tell what
> >> standard a particular file is at.
> >
> > Using the YUM command line should tell you what you have installed.
> >
> > Or, add "/DUP" as a parameter to ANPM. Just be careful what you select
> > when you install things.
> >
> > ANPM has an outstanding request to add a feature to be able to change
> > between versions, but it has not been done yet. Note that file date &
> > size means nothing, and individual files seem to have no information
> > about what version they are (no BLDLEVEL information). Some of them,
> > apparently, have a way to query their version, but it seems that it is
> > inconsistent, and you need to know exactly how to do it for different
> > files.
> >
>
> Yes, bldlevel would be best if it was guaranteed to be updated whenever anything
> changed, including the build flags, but that would mean a lot of extra work for BWW.
> I appreciate that using the date & size information is not foolproof but it
> would be correct in most cases and requires little extra work.

I wouldn't bet on it...

> What does the /DUP switch do, is there a list of switches available anywhere?
>
> Dave P.

"/DUP" is undocumented, and is really meant for development, but it
does show the version that is installed.Try it, and it will make
sense. I don't know of any others.

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

[Peter Flass]

A.D. Fundum <what...@neverm.ind> wrote:
> >> The latest FF assumes an eCS 2.x environment
>
> > The latest FF, which Bitwise compiled to target a i486
> > due to the need for the GCC atomics, runs fine on my
> > OS/2 ver 4+fp15
>
> In general it doesn't. FF + OS/2 = missing DLLs. You had to eCS 2'ify
> your OS/2 system, which requires quite a few extraordinary efforts
> from an user's point of view (the requirements of requirements of
> requirements of requirements of required software). It will work, wehy
> not, but I wouldn't sell it as OS/2 software. Your customers will
> complain that they cannot find all DLLs, and the solution to obtain
> those DLLs ... su^G^Gblows. Engineers (it works) vs humans. ;-)

Make a statically linked version?

--
Pete

[David Parsons]

Ok, It helps a bit but I presume the platform column shows which packages it has
available or has installed itself and not the file version on disk which was
installed from a zip file before ANPM became available.

Still I think it will be helpful, thanks.

Dave P.

[Steven Levine]

On Sat, 22 Oct 2016 17:48:37 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi Dave,

> > There is a field in the LX header which specifies the CPU Type but all
> > files show i386 even though I believe that many are at i686.

As Dave noted this is probably gcc. The relevant wlink code is

case CMT_WAT_PROC_MODEL:
case CMT_MS_PROC_MODEL:
proc = GET_U8_UN( ObjBuff ) - '0';
if( proc > FmtData.cpu_type )
FmtData.cpu_type = proc;
break;

and

if( FmtData.cpu_type <= 3 ) {
exe_head.cpu_type = OSF_CPU_386;
} else {
exe_head.cpu_type = OSF_CPU_486;
}

which says that the CPU type comes from the OMF record and wlink maps
the CPU type to either 386 or 486.

> > I've complied a test program here with 'gcc -march=i686 test.c' which
> > compiles and runs successfully but it also shows the CPU type as i386.

What linker did you use and did you check the COMMENT records
generated by gcc?

> > Could it be that the -march switch is silently ignored in our gcc builds?
> > For the record I used gcc v4.5.2.

That's pretty antique.

> It's the linkers job to set fields in the LX header, all GCC does is
> produce the correct assembly code and obj files and ask the linker to
> link them into an executable (or DLL).

That's sorta true. As noted above, gcc is responsible for indicating
the CPU type required by each object model.

> Wlink could be patched (perhaps already is?) to use i686 in the CPU
> field but I don't know if the kernel would be happy to load something
> besides i386.

AFAIK, it would not care. I've not seen any code that cares about the
CPU type field in the LX header.

Steven


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

[Doug Bissett]

On Wed, 26 Oct 2016 15:37:35 UTC, David Parsons

<dwpa...@t-online.de> wrote:

> On 25-10-16 18:50, Doug Bissett wrote:
> > On Sun, 23 Oct 2016 16:35:43 UTC, David Parsons
> > <dwpa...@t-online.de> wrote:
> >
> >> What does the /DUP switch do, is there a list of switches available anywhere?
> >>
> >> Dave P.
> >
> > "/DUP" is undocumented, and is really meant for development, but it
> > does show the version that is installed.Try it, and it will make
> > sense. I don't know of any others.
> >
>
> Ok, It helps a bit but I presume the platform column shows which packages it has
> available or has installed itself and not the file version on disk which was
> installed from a zip file before ANPM became available.
>
> Still I think it will be helpful, thanks.
>
> Dave P.

You should never get to the files on the disk, from before you
installed RPM/YUM (PATH and LIBPATH need to have the YUM paths first,
although some insist that the dot entry needs to be first in LIBPATH),
however, it is still possible to use the wrong file, so you really
should eliminate ALL duplicates of files that are in the \usr
directory structure, everywhere else on your system (with logical
exceptions). Once you get that mess cleaned up, ANPM (actually YUM)
will control the versions for you, and all you need to do is keep them
up to date (although that has also been known to cause problems when
the packages are not built properly).

HTH...

[Steven Levine]

On Sun, 23 Oct 2016 18:09:43 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi Dave,

> There's also the question of whether OS/2 actually supports SSE.
> A testcase that was suggested to me was running the Flac testsuite in
> twice as many sessions as the number of enabled cores. While one session
> passed the testcase, multiple sessions failed until only one was left
> which passed.
> This implies that the OS/2 kernel does not save the XMMS registers
> during a context switch and SSE (and MMX?) code will fail if more then
> one thread accesses the XMMS registers

If I understand the Intel docs, it should. If the hardware indicates
that support exists, current kernels will use fxsave/fxrstr and will
set cr4.OSFXSR which means the XMM and MXCSR registers will be saved
and restored by fxsave/fxrstr. Of course, this does not mean that the
code is defect free.

BTW, what do you mean by XMMS registers? This is a term used by the
Intel docs.

[A.D. Fundum]

>> FF + OS/2 = missing DLLs. You had to eCS 2'ify your OS/2
>> system, which requires quite a few extraordinary efforts from
>> an user's point of view (the requirements of requirements of
>> requirements of requirements of required software).

> Make a statically linked version?

That was discussed in comp.os.os2.apps, and I'm not expecting that
Dave will release a fully statically linked SM version of BWW's FF for
an eCS 2.x environment. IIRC he has already reduced the number of
required DLLs in the past, but as such FF is BWW's impressive project.

Releasing the DLLs as "RPM" ZIP files could work too, to offer people
an alternative way to manage their own packages, but apparently
"unification" was more important than users.

FWIW, BWW has complained ("press release") that people have to contact
them. I'm not using eCS 2.x DE/EN nor an eCS 2.x environment, I'm not
using the FF for OS/2 in question (because of their excessive
requirements), and I tend to not create accounts to report or discuss
RFCs, policies and bugs.


--

[Paul Smedley]

Hi Dave,

OK, will try come up with a testcase, then re-test with GCC 6.2

Cheers,

Paul

[Paul Smedley]

Hi Dave,

http://smedley.id.au/tmp/sse2.cpp runs fine with -msse2 when built with
g++ from 4.4.6, 4.9.2 and 6.2.0

Only 6.2.0 has the stack align changes :/

I might try compiling qtgui4.dll with gcc 6.2.0 without the changes from
https://trac.netlabs.org/qt4/ticket/187 - that at least is a known
failure case...

Cheers,

Paul

[Dave Yeo]

I'd guess the stack has to become mis-aligned first for the bug to show
up. The known failure I know of is Mozilla.
IIRC, a Mingw guy introduced the same fix (-mstackrealign) into FLAC and
I requested adding __OS2__ to the fix, though I never saw the failure
while running the test suite. So it implies that Mingw has the same problem
Dave

[Dave Yeo]

Steven Levine wrote:
> On Sun, 23 Oct 2016 18:09:43 UTC, Dave Yeo <dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>> There's also the question of whether OS/2 actually supports SSE.
>> A testcase that was suggested to me was running the Flac testsuite in
>> twice as many sessions as the number of enabled cores. While one session
>> passed the testcase, multiple sessions failed until only one was left
>> which passed.
>> This implies that the OS/2 kernel does not save the XMMS registers
>> during a context switch and SSE (and MMX?) code will fail if more then
>> one thread accesses the XMMS registers
>
> If I understand the Intel docs, it should. If the hardware indicates
> that support exists, current kernels will use fxsave/fxrstr and will
> set cr4.OSFXSR which means the XMM and MXCSR registers will be saved
> and restored by fxsave/fxrstr. Of course, this does not mean that the
> code is defect free.

That's what I thought (assuming you mean when doing a context switch),
but the FLAC failure implies otherwise, at least in an SMP environment.

>
> BTW, what do you mean by XMMS registers? This is a term used by the
> Intel docs.

Typo, meant XMM
Dave

[Dave Yeo]

It has become hard. Some libraries (fontconfig and pango) seem to be
designed to be shared, some don't work statically linked (mmap, where I
got socket errors when statically linked) and some are only getting
fixed in the YUM/RPM environment (NSPRPUB and the NSS DLLs). As well
some of the shared libraries have the same dependencies as Mozilla,
namely cairo and its requirement of pixman. Seems easier and safer to
use the same DLL rather then statically linking 2 different versions.
Get fixes and speedups with the newer version as well.
Then a bunch of the libraries need rebuilding and the license says I
need to distribute the source and I have a shortage of bandwidth.
Ideally I'd have to fork the Bitwise port of Firefox as well as a bunch
of the dependencies.
Dave

[Dave Yeo]

A.D. Fundum wrote:
> >> FF + OS/2 = missing DLLs. You had to eCS 2'ify your OS/2
> >> system, which requires quite a few extraordinary efforts from
> >> an user's point of view (the requirements of requirements of
> >> requirements of requirements of required software).
>
> > Make a statically linked version?
>
> That was discussed in comp.os.os2.apps, and I'm not expecting that
> Dave will release a fully statically linked SM version of BWW's FF for
> an eCS 2.x environment. IIRC he has already reduced the number of
> required DLLs in the past, but as such FF is BWW's impressive project.
>
> Releasing the DLLs as "RPM" ZIP files could work too, to offer people
> an alternative way to manage their own packages, but apparently
> "unification" was more important than users.

There are zips of most of the packages available and unrpm is also
available to extract the files. They do use @UNIXROOT, which makes sense
as most of the ports don't understand drive letters.

>
> FWIW, BWW has complained ("press release") that people have to contact
> them. I'm not using eCS 2.x DE/EN nor an eCS 2.x environment, I'm not
> using the FF for OS/2 in question (because of their excessive
> requirements), and I tend to not create accounts to report or discuss
> RFCs, policies and bugs.

Yes, while they advertise Mozilla, they're only interested in Firefox.
It's a shame as once Firefox is compiling, it is not much more work to
support SM and TB.
Of course they're no longer targeting eCS as Arca Noae is paying them to
target their coming release. At least Arca Noae is willing to support
OS/2, eg with a subscription, you can download binaries like ACPI that
are quite happy to be installed on Warp V4. Only really needed with
newer machines, mine is right on the cusp and works about the same with
it or without it, so I have it remmed out currently until my next upgrade.
Dave

[Dave Yeo]

A.D. Fundum wrote:
> > I'll monitor the newsgroups as long as I can.
>
> O, I know. Bless you. Over here most ISPs won't even offer Usenet
> anymore. Even my email may stop working, according to a rather old
> annoucement of my ISP (former ibm.net).

My ISP dropped newsgroups a long time ago. I ended up spending $10 for a
couple of GBs with no time limit. It'll last my lifetime with my use.
Now my ISP has announced that they're dropping dial-up on Nov 16.
Dial-up is the only option where I live, don't even have cell coverage
(sometimes a little bit in one spot upstairs) and the mountains hide the
satellites.
I'll be left with cell coverage and wifi in town and cellular internet
is $1 for 10MBs with 15 cents a MB if I go over, Or $70 for a GB. Canada
is probably the worst country in the world for internet and cell.
I guess I'll be using my T42 a lot more.
Dave

[David Parsons]

Hi Steven,

Those 2 snippets confirm my assumption, thanks.

As for GCC, the latest I've found on Paul's site is 4.9.2, not so much newer and
anyway I don't use C very often & when I do I normally use Watcom.

As for the linker, it is an old version of wl.exe which seems to be a patched
version of wlink v1.6.
I don't have the source for it and I don't know now where I got it from so I
don't know what is patched. When you invoke it, it says something about
experimental HLL.
I noticed that ANPM offers a version of wl, I'll give that a try and see if it
is any better.

Dave P.

[David Parsons]

When I finally got fed up trying to keep adding extra dependencies for Firefox &
Thunderbird by extracting the files from the zip & rpm files on Netlabs and
decided to use ANPM, I already had a very mature /usr tree for other programs
which I wanted to keep & I did not want yet another linux directory structure.

I eliminated any duplicates & moved a few stray linux orientated files into
/usr/... before running ANPM for the first time.

ANPM added the directories at the beginning of PATH & LIBPATH leaving the
existing entries where they were duplicating the directories in PATH & LIBPATH
which I later removed.

I had expected ANPM would overwrite any files already on the disk with its
version but it seems that it did not overwrite all unfortunately.

So now to the present problem. The Firefox 38.*.* series are appallingly slow at
scrolling and after updating a few files for another reason I noticed that the
scrolling was noticeably better with these updates which were i686 files so I
wanted to see if there were any other i386 files which I could update & perhaps
gain a bit better performance.

This led to the problem of how to identify i386 versions on the disk.
This should have been easy, just look at the CPU_Type field in the LX header.
As we now know, that field is not set as expected by wl.exe without Steven's patch.
I don't know which linker was used to produce the netlabs files but presumably
it doesn't set it either.



HTH...

Dave P.

[Dave Yeo]

David Parsons wrote:
> I don't know which linker was used to produce the netlabs files but
> presumably it doesn't set it either.

Generally wl.exe (wlink with support for our debugging support).
You could open an issue at the Netlabs RPM site to add Steven's patch
Dave

[Doug Bissett]

On Sat, 29 Oct 2016 13:41:33 UTC, David Parsons

That will, for sure, cause problems.

> I eliminated any duplicates & moved a few stray linux orientated files into
> /usr/... before running ANPM for the first time.

ANPM uses YUM to determine what is, or is not, installed, not what
files happen to be in the paths.

> ANPM added the directories at the beginning of PATH & LIBPATH leaving the
> existing entries where they were duplicating the directories in PATH & LIBPATH
> which I later removed.

That is simply messy, it won't cause a problem.

> I had expected ANPM would overwrite any files already on the disk with its
> version but it seems that it did not overwrite all unfortunately.

ANPM simply runs YUM to do the work. YUM expects to know exactly what
files are in the directory structure. It knows nothing about any stray
files that you may have added (or removed).

> So now to the present problem. The Firefox 38.*.* series are appallingly slow at
> scrolling and after updating a few files for another reason I noticed that the
> scrolling was noticeably better with these updates which were i686 files so I
> wanted to see if there were any other i386 files which I could update & perhaps
> gain a bit better performance.

I would suggest that you rename your old /usr directory structure, and
install ALL of the packages that ALL of the programs, that you use,
using ANPM into a new /usr directory structure. Then, eliminate the
old one. When you do that, ANPM will insist on initializing the
directory structure with a new downloaded bootstrap file, which is a
basic RPM/YUM install, with no extras. That will initialize your
RPM/YUM stuff to what YUM knows about, so you can successfully add
what you need.

> This led to the problem of how to identify i386 versions on the disk.
> This should have been easy, just look at the CPU_Type field in the LX header.
> As we now know, that field is not set as expected by wl.exe without Steven's patch.
> I don't know which linker was used to produce the netlabs files but presumably
> it doesn't set it either.

You cannot solve your problems by knowing what is on the disk. You can
only solve them by getting YUM to know what it thinks it installed.
That means letting YUM do it. ANPM simply runs YUM for you.

>
>
> HTH...
>
> Dave P.

[Paul Smedley]

Hi Dave,

On 29/10/16 23:07, David Parsons wrote:
> As for GCC, the latest I've found on Paul's site is 4.9.2, not so much
> newer and anyway I don't use C very often & when I do I normally use
> Watcom.

6.2.0 is available - I posted a link at os2world. It's probably tested
well enough that I should add it to my site as well now....

Cheers,

Paul

[David Parsons]

Thanks Paul, I'll give it a try.

Dave P.

[A.D. Fundum]

> unrpm is also available to extract the files.

Retorical: most files, not all files? I'll look at it again after a
new major upgrade, albeit most of my hardware probably won't support
FF49+ anyway (SSE2-related, FF49 for Windows requires a Pentium 4+).

> They do use @UNIXROOT

To be fair, the main problem of a real Unix directory structure is
that I don't have it (free boot disk space may become a problem too).
There's no "Unixification Package for OS/2 and eCS 1.x". OTOH, if I
would install eCS 2, and eCS 2 would introduce a real Unix directory
structure (i.e. not an avoidable directory called "@UNIXROOT"), then I
may smile and enjoy my new OS while it's being installed by the
installer of the OS. IOW: I'll use Unix if I like an Unix directory
structure, but I wouldn't uninstall it. In the end it's an acceptable
PITA, if an installer for OS/2/eCS 1.x installs the basics.

> Arca Noae is willing to support OS/2, eg with a subscription

Well, as long as it's clear. I'd prefer to use eCS 1.2 (USB support,
new APIs since my W4 FP9) and rather old "new" hardware (T60p, too
many cores, apparently even after disabling all but one core). At the
moment that's my best theoretical combination, but now I cannot even
install eCS 1.2. What I want/need is quite clear, from an user's point
of view. eCS 2.x works, but all I've seen is the demo CD.


--

[A.D. Fundum]

> mountains hide the satellites.

I've pressed <F5> a few times during one of your Hobbes uploads...

> Canada is probably the worst country in the world
> for internet and cell.

I'll reconsider a commercial CD/DVD/USB large file download/upload
service, and sneak you in as a mandatory XTS (virtual test currency)
test account for the Canadian franchisee.


--

[Dave Yeo]

A.D. Fundum wrote:
> > unrpm is also available to extract the files.
>
> Retorical: most files, not all files? I'll look at it again after a
> new major upgrade, albeit most of my hardware probably won't support
> FF49+ anyway (SSE2-related, FF49 for Windows requires a Pentium 4+).

Looks like FF52ESR will also be the last to support Win XP (and Vista)
though they are talking about extending the ESR support past the usual 1
year if the number of user is high enough.

>
> > They do use @UNIXROOT
>
> To be fair, the main problem of a real Unix directory structure is
> that I don't have it (free boot disk space may become a problem too).
> There's no "Unixification Package for OS/2 and eCS 1.x". OTOH, if I
> would install eCS 2, and eCS 2 would introduce a real Unix directory
> structure (i.e. not an avoidable directory called "@UNIXROOT"), then I
> may smile and enjoy my new OS while it's being installed by the
> installer of the OS. IOW: I'll use Unix if I like an Unix directory
> structure, but I wouldn't uninstall it. In the end it's an acceptable
> PITA, if an installer for OS/2/eCS 1.x installs the basics.

Run ANPM (freely available from the Arca Noae site) and it'll install
the basic @UNIXROOT stuff on its first run. Runs on at least Warp V4
fp15 and perhaps earlier (untested).

>
> > Arca Noae is willing to support OS/2, eg with a subscription
>
> Well, as long as it's clear. I'd prefer to use eCS 1.2 (USB support,
> new APIs since my W4 FP9) and rather old "new" hardware (T60p, too
> many cores, apparently even after disabling all but one core). At the
> moment that's my best theoretical combination, but now I cannot even
> install eCS 1.2. What I want/need is quite clear, from an user's point
> of view. eCS 2.x works, but all I've seen is the demo CD.

The subscription would also support eCS 1.2 though you'd have to add
ACPI to the boot disks I guess.
Lars has uploaded his recent USB support to Hobbes, worth trying.
Dave

[A.D. Fundum]

> Run ANPM (freely available from the Arca Noae site)
> and it'll install the basic @UNIXROOT stuff on its first
> run.

Thanks, worth a try to upgrade this "OS component".

> The subscription would also support eCS 1.2

A good T23 died this morning, so I've posted an article in c.o.o.e
with questions to install eCS 1.2 (in theory Warp 4 is possible too).
Certainly not my last PIII, but the number of perfectly working faster
(>= 1 GHz) PIIIs now is 0. It looks like I have to update a few files.
I'm not sure if ACPI is involved, it's one of the oldest IBM/Lenovo
T60s (i.e. not a 100% Lenovo).


--

[David Parsons]

On 30-10-16 00:22, Doug Bissett wrote:
> You cannot solve your problems by knowing what is on the disk. You can
> only solve them by getting YUM to know what it thinks it installed.
> That means letting YUM do it. ANPM simply runs YUM for you.

Of course I can. I only have to identify which files to update and then install
the packages which contain them using ANPM/YUM. From then on ANPM will manage
those packages.

Dave P.

[Doug Bissett]

On Tue, 1 Nov 2016 16:47:48 UTC, David Parsons <dwpa...@t-online.de>
wrote:

You will have a LOT of work to do, to even begin to understand what
might need to be installed by ANPM (RPM/YUM). Don't forget that there
is a lot more to it than just DLLs.

Just use ANPM to install ALL of the packages that your software needs,
and you will accomplish the same thing, without doing a lot of
unnecessary work (most packages are pretty small). However, that may
leave old stuff behind, that will eventually cause problems. Best to
just move what you have out of the way, and start new with ANPM
(RPM/YUM). Then you won't be guessing, and the problem will be solved.

The best advice that I can give, about using RPM/YUM when you haven't
used RPM/YUM before, is to start new, using ANPM. DO NOT even think
about trying to second guess that stuff, you will only spend untold
hours digging yourself a hole that will be more difficult to get out
of. Spending an hour to start over, is much smarter than spending days
trying to figure out what you think you might want to do, and messing
it up so bad that you will still need to spend that hour fixing the
problem (time depends on your download speed, I use standard DSL).

You could have done it twice, in the time you spent posting about it.

You must remember that RPM/YUM is a terrible way to do things (even
the *NIX world has mostly abandoned it), but if you want to use modern
*NIX ports, you need to use it. If you don't use it properly, you can
tie it in knots, and it won't be pretty.

You have been warned...

[Steven Levine]

On Sat, 29 Oct 2016 18:43:47 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi Dave,

Warpstock kept me away from the newsgroups...

> Generally wl.exe (wlink with support for our debugging support).
> You could open an issue at the Netlabs RPM site to add Steven's patch

What patch? Do you mean the wlink with HLL debug support? I've not
checked, but I would be surprised if it's not already available from
the Netlabs rpm since it's used to build Firefox.

[Steven Levine]

On Sat, 29 Oct 2016 03:56:40 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi Dave,

> > and restored by fxsave/fxrstr. Of course, this does not mean that the
> > code is defect free.
>
> That's what I thought (assuming you mean when doing a context switch),
> but the FLAC failure implies otherwise, at least in an SMP environment.

True. It would take some debugging to identify what the cause of the
failure really is.

Steve

[Steven Levine]

On Sat, 29 Oct 2016 12:37:38 UTC, David Parsons
<dwpa...@t-online.de> wrote:

Hi David,

> As for the linker, it is an old version of wl.exe which seems to be a patched
> version of wlink v1.6.

That would be Knut's original version of wlink with HLL debug support.
It's probably fine for anyone not building Firefox. The memory
management in Knut's patch was not quite up to building something as
big as Firefox with debug info.

You can find copies of recent builds of some OpenWatcom components at:

http://www.warpcave.com/OpenWatcom

Now that openwatcom.org is back online, there will probably be a
OpenWatcom release for OS/2 release in the relatively near future.
Gregg and I are trying to decide what to include in the release, what
to name the release and where to distribute it.

> I don't have the source for it and I don't know now where I got it from so I
> don't know what is patched.

There never was a repository for this. Knut distributed the diffs and
these formed the basis of my modifications to the then current
sources. My modifications have been committed to the OpenWatcom
Perforce repository.

> When you invoke it, it says something about
> experimental HLL.

You mean like:

[d:\tmp]wlink
** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited
Availability
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
Press CTRL/Z and then RETURN to finish

[Dave Yeo]

Steven Levine wrote:
> On Sat, 29 Oct 2016 18:43:47 UTC, Dave Yeo <dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
> Warpstock kept me away from the newsgroups...
>
>> Generally wl.exe (wlink with support for our debugging support).
>> You could open an issue at the Netlabs RPM site to add Steven's patch
>
> What patch? Do you mean the wlink with HLL debug support? I've not
> checked, but I would be surprised if it's not already available from
> the Netlabs rpm since it's used to build Firefox.
>

Maybe I miss understood. Didn't you say that you'd patched wlink to
report the CPU architecture? If so, that was the patch I meant. If not,
sorry for the noise.
Dave

[Steven Levine]

On Thu, 10 Nov 2016 16:52:30 UTC, Dave Yeo <dave....@gmail.com>
wrote:

Hi Dave,

> Maybe I miss understood. Didn't you say that you'd patched wlink to
> report the CPU architecture? If so, that was the patch I meant. If not,
> sorry for the noise.

Perhaps I did not state things clearly. What I posted was the
existing code that sets the CPU type field. This could be modified to
report other CPU types, but I have no plans to do this since it the
field is effectively ignored by OS/2.

[Dave Yeo]

Steven Levine wrote:
> On Thu, 10 Nov 2016 16:52:30 UTC, Dave Yeo <dave....@gmail.com>
> wrote:
>
> Hi Dave,
>
>> Maybe I miss understood. Didn't you say that you'd patched wlink to
>> report the CPU architecture? If so, that was the patch I meant. If not,
>> sorry for the noise.
>
> Perhaps I did not state things clearly. What I posted was the
> existing code that sets the CPU type field. This could be modified to
> report other CPU types, but I have no plans to do this since it the
> field is effectively ignored by OS/2.
>

OK, thanks for the clarification.
Dave

[David Parsons]

On 10-11-16 02:54, Steven Levine wrote:
> On Sat, 29 Oct 2016 12:37:38 UTC, David Parsons
> <dwpa...@t-online.de> wrote:
>
>> When you invoke it, it says something about
>> experimental HLL.
>
> You mean like:
>
> [d:\tmp]wlink
> ** EXPERIMENTAL (HLL) ** Open Watcom Linker Version 2.0beta1 Limited
> Availability
> Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
> Source code is available under the Sybase Open Watcom Public License.
> See http://www.openwatcom.org/ for details.
> Press CTRL/Z and then RETURN to finish
>
> Steven
>

Yes, except the one I have claims to be Version 1.6beta1.

I noticed that there is a version 2.0beta1 release 6 available via ANPM.

Thanks for the info & help.

Dave P.