commercial competitor to windows

[Paul Edwards]

It's been a long convoluted path, but I think
I have now got to a position that I am possibly
going to settle on.

It's one of these "forest for the trees" things.

There is not a lot of code involved to "glue"
a (limited target) Win32 executable so that it
can run on OS/2, which is still commercially
supported in the form of ArcaOS.

This (ArcaOS) is the first realistic competitor
I see to Windows. I don't buy into the freeware
nonsense.

Anyway, search for win32os2 at http://pdos.org
if interested. It's still proof of concept. But
the underlying ArcaOS is far from proof of
concept, which is what counts (in my opinion).

And the other monopoly I wanted challenged is
IBM's z/OS. And for that I'm happy to remain
on Windows with Hercules or more likely the
commercial FSI.

This is more problematic though. The only thing
I have available is z/PDOS. The PDOS-generic
concept which I Frankensteined for expediency
to support Win32 API on OS/2 and Win64 API on
UEFI (with minimal code) possibly doesn't apply
to z/OS (ie separate CRT via a well-defined
DLL interface). I know there is LE but I'm not
sure I can intercept at that level. Hell - even
msvcrt.dll is undocumented.

I'll need to ask about LE elsewhere to decide
what to do there. Or maybe have my own DLL. I
was thinking of getting away from the msvcrt
name too. I don't like standard windows ANSI
support. That is solved on ArcaOS because I
have to do the ANSI keyboard myself.

BTW, the convoluted path included buying
Microsoft C 6.0 (brand new) and running it
under Windows 2000 to produce 16-bit OS/2
executables. Trying to get 16-bit to work
to my satisfaction triggered the required
abstraction. This was non-obvious to me.

BFN. Paul.

[Paul Edwards]

On 22/12/23 19:57, Paul Edwards wrote:

> It's one of these "forest for the trees" things.

And another one.

> Anyway, search for win32os2 at http://pdos.org

Search for win32lin (for Linux). As a poor
(depending on measure) alternative to Wine.
I think it would work with standard 32-bit
gcc (with dynamic libc) and be even smaller.
Ironically 64-bit won't work as easily because
the technique relies on consistent calling
convention (cdecl). 64-bit diverges Linux
vs Windows.

I don't know how to solve the double escape
problem with the included me.exe (microemacs).

I don't want to rely on a timeout after an
ESC comes in. I want two ESC generated as
ANSI X3.64 allows.

BFN. Paul.

[Paul Edwards]

On 22/12/23 19:57, Paul Edwards wrote:

> It's one of these "forest for the trees" things.

Actually, I don't think it is a case of this at all.

> There is not a lot of code involved to "glue"
> a (limited target) Win32 executable so that it
> can run on OS/2, which is still commercially
> supported in the form of ArcaOS.

Actually, I believe it is working (e.g. on Linux
as the latest target) because I have managed to
combine two C libraries into one.

It is not obvious that it is possible to do that.

In addition, with msvcrt.dll in particular, for
fprintf(stdout ...) to work, it required mapping
of some standard names.

This was done by Alica years ago for producing our
equivalent DLL, and this code needed to be activated
in the Linux etc environment.

So yeah - it's a limited amount of code, but anyone
would be forgiven for thinking it was nominally
impossible to combine two different C libraries
into a single executable. I have a "runnum" variable
that knows it needs to switch parameter format for
numbers above 1 too.

So yeah - the incremental approach to getting this
working (including going via 16-bit systems, and
trying to get the abstraction right) - was part of
the process, not unnecessarily convoluted.

In hindsight there isn't a lot of code involved
and it's seemingly obvious.

But quite frankly, as per this correction - I'm only
vaguely aware of how it works at all. And at no point
during the construction was I 100% sure the various
steps would work. I had no idea whether there was
a show-stopper I hadn't thought of.

With the 16-bit in the path, one of the potential
show-stoppers was the ds pointing to the DGROUP,
but lo and behold, Microsoft C 6.0 and Watcom
both had an option for ds to not be assumed to
be pointing to DGROUP, requiring the ds to be
reloaded.

Someone once told me (I don't know if it is true),
that something like pennicilin was actually invented
in Africa. They had stumbled across a sequence of
steps - some of them unnecessary - to produce the
required antidote (by luck). So it's probably
something closer to that. There were a huge number
of "I wonder if this works?" along the way. Maybe
a lot of those questions had answers already known
to others, but the only answers I ever got from
others around at the time were "no, the format is
incompatible so it won't work" or something along
those lines. Never once did someone say "of course
it will work - how the hell do you think xyz works?".

So I never had any confidence that any of the
numerous steps would work.

Thus I don't think it is fair to say that I
couldn't see the forest for the trees. It's more
that I managed to grow one tree on top of another
tree and the entire forest didn't collapse as it
was always in danger of doing.

A bit like S/380. It's nominally impossible to
run a 31-bit program on a 24-bit OS. You could
say "oh - dos extenders do that", but it's not
the same, and before it was proven to work, there
wasn't one person saying "of course it will work -
it's just a simple dos extender", but there was
a gaggle of people saying it wasn't possible.

Basically it is nominally impossible to put 31
liters of water into a 24 liter container. But
is it? If the rules used the chemical equation
H2O, so that freezing wasn't prohibited, you
can indeed delicately balance 31 liters of ice
in a 24 liter container.

Or in my case - 2**31 liters in 2**24 liters -
much more useful.

BFN. Paul.