win32 development

[[e-mail]]

When PD-Windows starts working properly,
you will be able to develop Win32 executables
using PD-Windows, and making use of PDPCLIB.

But actually the tools should also work under
HX under Freedos.

And the GCC 3.2.3 that I am using could be
replaced by Smaller C.

Does this buy anything compared to DJGPP
which is most common?

I'm thinking I can replace Windows with Freedos,
while waiting for PD-Windows to come online
(and be robust).

BFN. Paul.

[Rod Pemberton]

On Mon, 12 Apr 2021 15:41:57 -0700 (PDT)

Post by ***@gmail.com
When PD-Windows starts working properly,
you will be able to develop Win32 executables
using PD-Windows, and making use of PDPCLIB.

We have Wine for Linux, DOSBox-X for DOS, Japheth's HX for DOS, and
MAME for Linux/Windows/MacOs (with IBM Pentium AT clone emulation) etc,
all of which should run Win32 executables.

https://www.winehq.org/
https://dosbox-x.com/
https://www.mamedev.org/
https://www.japheth.de/HX.html

Post by ***@gmail.com
But actually the tools should also work under
HX under Freedos.

...

Post by ***@gmail.com
And the GCC 3.2.3 that I am using could be
replaced by Smaller C.

...

Post by ***@gmail.com
Does this buy anything compared to DJGPP
which is most common?

OpenWatcom buys some speed at the expense of being a more pedantic and
limited implementation of C, e.g., no LFN support for v1.3, maybe they
added it by v1.9. DJGPP's primary DPMI host, CWSDPMI, is extremely
slow compared to other DPMI hosts, but is very reliable. DJGPP (GCC
compiler but with non-GCC, DOS C libraries) produces slower code than
OpenWatcom. My OS runs much, much, much, much slower when compiled via
DJGPP than with OpenWatcom, even with the best optimizations. My OS
doesn't use a DPMI host, so this is an x86 code optimization issue.
Disassembly of the compiled C code shows that one issue for DJGPP code
is that it doesn't generate 8-bit x86 instructions, e.g., chars, i.e.,
generating slower, larger 32-bit sequences.

Otherwise, I haven't used Alexei's recently developed Smaller C, but
had been experimenting with Ron Cain's Small C for bootstrapping.
Actually, I experimented with more than a few obscure, no longer
available, small C compilers some years ago. They're all a pain to use
because they're so limited. I patched up one with code from various
versions, and I fixed numerous bugs in another, and another was so old
that the C code wouldn't even compile due to syntax errors, e.g., too
K&R.

Post by ***@gmail.com
I'm thinking I can replace Windows with Freedos,
while waiting for PD-Windows to come online
(and be robust).

I'm not really sure how compatible Freedos is with MS-DOS. It had some
issues a few years back, but maybe they've been fixed? DR-DOS was the
DOS that was known to be the most compatible. The reason I mention that
is DJGPP v2.03 works really well with MS-DOS. However, more recent
versions of DJGPP are attempting to make DJGPP work better in Windows
consoles, since the main developers don't use real DOS anymore. The
last time I checked, they broke some stuff for true DOS, which they
weren't about to fix. DJGPP is basically end-of-life for real DOS.

[[e-mail]]

Post by Rod Pemberton

Post by ***@gmail.com
When PD-Windows starts working properly,
you will be able to develop Win32 executables
using PD-Windows, and making use of PDPCLIB.

We have Wine for Linux, DOSBox-X for DOS, Japheth's HX for DOS, and
MAME for Linux/Windows/MacOs (with IBM Pentium AT clone emulation) etc,
all of which should run Win32 executables.

Ok, thanks.

I have a new suggestion.

Assume PDOS/86 becomes built with 8086 instructions
using a veryhuge memory model (all pointers huge, as in
Smaller C).

Rather than running HX, what I could instead do is
incorporate the equivalent of a cut down HX into
PDOS/86. It would detect a "PE" signature and only
at that point switch to protected mode (which is
the point at which an 80386 is required).

I'm really only interested in supporting Windows
executables that only use a subset of kernel32,
so I'm not sure what the return to real mode
would look like, in order to convert a ReadFile()
request from the Windows executable into
multiple read() from normal PDOS/86 and buffer
transfers.

It seems logical to me that PDOS/86 and PDOS/386
should both support Win32 executables, using a
largely similar codebase.

In order to load gccwin.exe into memory, it would
have to be memory above 1 MiB, so the executable
loader may need to be split. And I'll have both 8086
code operating in real mode, and 80386 code
operating in protected mode, so I may need to have
a separate executable instead of the single pdos.exe.

I've never considered this possibility before. I didn't
have any interest in being in the "DOS extender"
business, but this is not a DOS extender, this is part
of PDOS/86.

I am not interested in DPMI/himem.sys or whatever.

BFN. Paul.

[Rod Pemberton]

On Thu, 15 Apr 2021 12:30:39 -0700 (PDT)

Post by ***@gmail.com
I'm really only interested in supporting Windows
executables that only use a subset of kernel32,
so I'm not sure what the return to real mode
would look like, in order to convert a ReadFile()
request from the Windows executable into
multiple read() from normal PDOS/86 and buffer
transfers.

I'm not familiar with this, i.e., Win32. I'd probably suggest studying
Japheth's works such as HX or HXRT etc.

Apparently, most versions of Windows use NTVDM to implement the Windows
console for executing DOS apps:

https://en.wikipedia.org/wiki/Virtual_DOS_machine#NTVDM

[[e-mail]]

Post by Rod Pemberton
Apparently, most versions of Windows use NTVDM to implement the Windows
https://en.wikipedia.org/wiki/Virtual_DOS_machine#NTVDM

Thanks. This was interesting:

"using the invalid opcode 0xC4 0xC4 to bop down into the 32-bit NTVDM to handle the requests"

I'm not sure that is applicable to either PDOS/86 running
Win32 applications or PDOS/386 running DOS programs
though.

BFN. Paul.

[[e-mail]]

Post by Rod Pemberton

Post by ***@gmail.com
When PD-Windows starts working properly,
you will be able to develop Win32 executables
using PD-Windows, and making use of PDPCLIB.

We have Wine for Linux, DOSBox-X for DOS, Japheth's HX for DOS, and
MAME for Linux/Windows/MacOs (with IBM Pentium AT clone emulation) etc,
all of which should run Win32 executables.

It occurred to me that the most convenient thing for
me to do would be to have MacOs running Windows
executables, and standardize on that.

I checked your list and you show "MAME". But when
I went to the Wikipedia page:

https://en.wikipedia.org/wiki/MAME

it said it emulated arcade games, not Windows.

I see you mentioned emulating a Pentium - is this software
emulation?

I am expecting PE/COFF executables that call
kernel32.dll to work, preferably at native speed.

Without having to provide my own kernel32.dll.

I only need console mode to work, and within that,
just file access etc.

If this doesn't already exist, maybe I can provide it.
I can provide msvcrt.dll already if they don't have
one of them. HX didn't have that.

BFN. Paul.

[Joe Monk]

"It occurred to me that the most convenient thing for
me to do would be to have MacOs running Windows
executables, and standardize on that."

You have two options.... vmware fusion or parallels.

I personally hate parallels, but it works. Vmware fusion works much better, you can run windows executables right from the mac desktop.

https://www.parallels.com
https://www.vmware.com/products/fusion.html

Joe

[[e-mail]]

Post by Joe Monk

Post by Joe Monk
"It occurred to me that the most convenient thing for
me to do would be to have MacOs running Windows
executables, and standardize on that."
You have two options.... vmware fusion or parallels.

I personally hate parallels, but it works. Vmware fusion works much better, you can run windows executables right from the mac desktop.
https://www.parallels.com
https://www.vmware.com/products/fusion.html

Ok, thanks. Both of those are commercial software.

According to this:

en.wikipedia.org/wiki/Wine_(software)

Wine is primarily developed for Linux and macOS,[18] and there are, as of July 2020, well-maintained packages available for both platforms.


It's unclear to me whether this will do what I want.

Regardless, I have a proposal which fits in with what
I've alluded to previously.

From the MacOS terminal prompt, go:

bios pdos.exe disk.img

and disk.img is a hard disk image (identical to what
Bochs uses) and pdos.exe is probably a normal
PE/COFF Windows executable (but it doesn't rely
on kernel32.dll because this *is* the kernel), and
makes callbacks to bios (a normal MacOS executable)
to retrieve "sectors" from disk.img.

The above configuration isn't just for MacOS. I can
even use it to run PD-Windows under Windows.

Executables will run at native processor speed. They
will be loaded by pdos.exe, and disk.img is a normal
FAT-16 hard disk.

Most of the code (such as fat.c) already exists, but I
do have some work to do to rearrange it to make all
calls via the bios callback instead of a int386() call.

For the Mac (but not Windows) I also have some work
to do to port PDPCLIB to the Mac. I don't know at the
moment how MacOS executables get services from
the OS. I know Linux uses INT 80H. I also don't know
what executable formats MacOS supports, maybe it
is just Mach-O. There is a mach-o target in
binutils 2.14a, I just have to try to build it.

Or maybe the Mac has some sort of restriction like
smartphones that prevent "unauthorized" arbitrary
executables from being run. Let's see what happens!

BFN. Paul.

[[e-mail]]

Post by ***@gmail.com
For the Mac (but not Windows) I also have some work
to do to port PDPCLIB to the Mac. I don't know at the
moment how MacOS executables get services from
the OS. I know Linux uses INT 80H. I also don't know
what executable formats MacOS supports, maybe it
is just Mach-O. There is a mach-o target in
binutils 2.14a, I just have to try to build it.

Ok, change of plans.

After quite a bit of hunting, it seems:

https://docstore.mik.ua/orelly/unix3/mac/ch05_02.htm

that there is a -lSystem which links in /usr/lib/libSystem.dylib
which gives access to libc, which would seem to be the
MacOS answer to msvcrt.dll.

So there is no need for PDPCLIB on the Mac unless I was
trying to replace the Mac, which I have no interest in doing.

Nor is there a lot of point bringing GCC 3.2.3 and binutils 2.14a
to the Mac, because these things predate intel Mac, so
probably aren't ready for that.

So I will just install gcc (or is there a better option?) and
build Bochs on the Mac, and delay the "bios" rearrangement
for now.

This will have a good short-term advantage in that I get
a COM1 etc.

But "bios" running Win executables at native speed seems
a much better option in the medium term. It's unclear to
me what the non-commercial competitors to that are.

BFN. Paul.

[Rod Pemberton]

On Mon, 10 May 2021 08:05:13 -0700 (PDT)

Post by ***@gmail.com
I checked your list and you show "MAME". But when
https://en.wikipedia.org/wiki/MAME
it said it emulated arcade games, not Windows.

It merged with their MESS project which emulates computers.