DOS ain't dead

My vision of what MSDOS should have become in the late 1980s is here:

http://pdos.org

Specifically in addition to IO.SYS, MSDOS.SYS and COMMAND.COM should have been added KERNEL32.DLL and MSVCRT.DLL.

That should have been the only visible change.

With the benefit of hindsight.

And a shitload of work.

Note that I am training (and paying) some people to take it from here, but it's a very slow process.

BFN. Paul.

> My vision of what MSDOS should have become in the late 1980s is here:
>
> http://pdos.org

what does it better than MSDOS?

what sort of programs does it run?

does it run Norton Commander?

Does it support MS Lanmanager?

can it read DVD/CD?

as you mention MSVCRT.DLL: does it load PE executables?

> > My vision of what MSDOS should have become in the late 1980s is here:
> >
> > http://pdos.org
>
> what does it better than MSDOS?

It is 32-bit instead of 16-bit if you wish
to have that.

> what sort of programs does it run?
>
> does it run Norton Commander?
>
> Does it support MS Lanmanager?

It doesn't support anything unless you
recompile as 32-bit.

But (some) INT 21H functions are available
(in clean 32-bit mode, flat address space,
supervisor mode, no memory protection).

One executable format used is a.out (which
EMX 0.9d used, not sure about other DOS
extenders). But segment registers are
never used.

> can it read DVD/CD?

No. Only hard disks and floppy disks.

> as you mention MSVCRT.DLL: does it load PE executables?

Correct. That is the other executable format
supported. So if you write to the lowest
common denominator, you can have a Win32
executable that runs on PDOS/386 and also
Freedos+HX and also every version of Windows
since Win95 (not sure if it works on Win32s
systems prior to Win95) and also Linux/Wine
(or anything else with Wine).

Note that there is also a new GCC executable
for this environment just released an hour ago.

BFN. Paul.

> > what sort of programs does it run?
> >
> > does it run Norton Commander?
> >
> > Does it support MS Lanmanager?
>
> It doesn't support anything unless you
> recompile as 32-bit.
what exactly do you mean by 'recompile to 32-bit'?

recompile to a.out would imply a UNIX/Linux toolchain.

does it run DOS 32-bit binaries?

if not, you have an operating system with exactly zero programs to run.

good luck with that.

> > > what sort of programs does it run?
> > >
> > > does it run Norton Commander?
> > >
> > > Does it support MS Lanmanager?
> >
> > It doesn't support anything unless you
> > recompile as 32-bit.

> what exactly do you mean by 'recompile to 32-bit'?

Use a suitable 32-bit compiler and 32-bit linker to
produce a 32-bit executable.

> recompile to a.out would imply a UNIX/Linux toolchain.

That implication is incorrect.

> does it run DOS 32-bit binaries?

It *defines* 32-bit DOS binaries.

> if not, you have an operating system with exactly zero programs to run.

That is not correct. It runs 32-bit MSDOS
binaries and 32-bit Windows binaries.

Including a 32-bit MSDOS toolchain and a
32-bit Win32 toolchain.

> good luck with that.

I'm perfectly happy with it.

I've spent 27 years working on it.

BFN. Paul.

> > does it run DOS 32-bit binaries?
>
> It *defines* 32-bit DOS binaries.

that's rather vague - actually, I don't understand what that is supposed to mean.

> That is not correct. It runs 32-bit MSDOS
> binaries and 32-bit Windows binaries.

So it offers some form of Win32 emulation and 32-bit Int 21h emulation, but no v86 monitor?
Will DOS-extended programs in PE format (HX, Pharlap TNT, 32RTM, WDOSX) run without recompile? JWasm, for example?

Please provide links to "substantial" documentation!

---
MS-DOS forever!

> > > does it run DOS 32-bit binaries?
> >
> > It *defines* 32-bit DOS binaries.
>
> that's rather vague - actually, I don't understand what that is supposed to
> mean.

Basically by coincidence, it is quite similar
to DOS/4GW I think. Although I've never used
it, it seems to support some INT 21H calls.

However, it also exposes the 32-bit executables
to segments. I don't.

> > That is not correct. It runs 32-bit MSDOS
> > binaries and 32-bit Windows binaries.
>
> So it offers some form of Win32 emulation and 32-bit Int 21h emulation, but
> no v86 monitor?

Correct.

> Will DOS-extended programs in PE format (HX,Pharlap TNT, 32RTM, WDOSX) run
> without recompile? JWasm, for example?

Certain HX programs, yes. I'm not actually sure
about those other formats you mentioned. It may
be possible to support the 32-bit component of
them. So long as they don't use segments. I don't
want to support segments.

I have focused on providing a C90-compliant
environment, so mostly it depends on whether
the HX programs you are interested in use
the subset of the Win32 API that I implemented
in order to provide C90 when writing PDPCLIB.

> Please provide links to "substantial" documentation!

This is what I have:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/readme.txt

But if I haven't documented something, I'm happy
to answer any questions.

Also, I was somewhat wrong about one thing.
Someone else added "paging" to PDOS, to
support multitasking. But I would rather have
a simple V=R address space. I tried #defining
out the paging code, via NOVM, and it semi-works
but eventually hangs. My intention is to debug
that and switch it off. People will need to
recompile to switch it on again.

BFN. Paul.

Hi Japheth.

Sorry, I didn't notice I was responding
to someone different.

> JWasm, for example?

I forgot to answer this specific question.
jwasm uses some non-C90 functions:

C:\devel\jwasm>pdmake -f makefile.w32
rm -f *.o jwasm.exe
gccwin -S -O2 -fno-common -I. -I../pdos/pdpclib -Ih -D__WIN32__ -o main.s main.c
main.c:34:19: fcntl.h: No such file or directory
main.c:39:18: io.h: No such file or directory

I don't know what those result in if compiled
with a different C compiler that supports
them, but they probably result in something
that I haven't implemented.

However, it is my hope that HX can be ported
to this new (PDOS/386) environment, as well
as run on PDOS/86. I'm not familiar with the
internals of HX, but I would have thought that
most of the code is already 32-bit, and either
takes control of the hardware itself (which is
fine - I don't manipulate the hardware, I make
BIOS calls), or does INT 21H calls, and the
only difference here is that HX doesn't need
to (and can't) drop down to RM16 to do those
calls, it needs to stay in 32-bit mode and do
the INT 21H.

HX probably makes some INT 21H calls that I
haven't implemented, but maybe those can be
added when I find out what the scope of the
problem is. Especially for the task of
executing jwasm.

Note that I have made binutils 2.14a C90-compliant
so I provide an "aswin" which is a 32-bit
assembler that runs under both HX and PDOS/386.
I also provide "as386" which is a 32-bit
assembler that only runs under PDOS/386, but
is probably very similar to DOS/4GW.

BFN. Paul.

One other piece of information that isn't
documented anywhere. I have a "wrapper" on
all the INT 21H functions I use, e.g. I
call PosOpenFile() instead of INT 21H AH=3DH.

This compiles appropriately for 16-bit real
mode so that it works on Freedos, MSDOS
and PDOS/86.

It compiles appropriately for 32-bit MSDOS
that works on PDOS/386 only.

What I plan to add is for it to do a 32-bit
compile to call kernel32 calls so that the
resultant executable works on all Windows
environments (PDOS/386, HX, Windows 95-10).

That way applications can ditch the awful
SECURITY_ATTRIBUTES, LONG etc introduced
by Microsoft and return to a much saner
MSDOS-inspired API.

So there will be 3 competing APIs.

POSIX
Windows
MSDOS-inspired-Pos*

The last one on that list will do 16-bit MSDOS.
Windows won't. Not sure if anyone has implemented
Posix on the 8086.

BFN. Paul.

I realized that I could test jwasm.

Here is what happened:

A:\]dir
IO.SYS 17882 2021-06-07 19:03:42
COMMAND.COM 71120 2021-06-07 19:05:50
KERNEL32.DLL 35328 2021-06-07 20:08:20 kernel32.dll
MSVCRT.DLL 38400 2021-06-07 20:10:30 msvcrt.dll
TERMINAL.EXE 15883 2021-06-14 15:00:04
HDTOFIL.EXE 4096 2021-06-13 15:13:58
ZFILL.EXE 3584 2021-06-25 22:31:56
HEXDUMP.EXE 3584 2021-06-13 15:11:38
PDPTEST.EXE 4608 2021-06-13 15:10:46
PORTINIT.EXE 15041 2021-06-13 15:01:54
PORTREAD.EXE 15741 2021-06-13 15:03:18
PORTWRIT.EXE 15567 2021-06-13 15:03:50
ZAP.EXE 3072 2021-06-13 15:13:18
README.TXT 133 2021-06-10 02:45:30 readme.txt
MSDOS.SYS 101024 2021-06-07 19:05:20 msdos.sys
JWASM.EXE 302592 2021-05-31 20:33:22 jwasm.exe

A:\]jwasm
warning - failed to open jwasm.com
warning - this executable uses a non-standard DLL KERNEL32.DLL
Function CreateEventA not found in DLL
Failed to load DLL KERNEL32.DLL

A:\]


Don't worry about the warnings, that's just
something I like to know.

But yes, CreateEventA is something I need to
add to my kernel32.c in order to get jwasm
to work.

This is Windows crap that I really have no
interest in. MSDOS doesn't do that.

I have no idea why an assembler would have
a requirement to create events, whatever
that even means. It's supposed to be reading
in a text file and outputting a single binary
file. Nothing more. You don't need more than
C90 to do that.

If I can create a dummy CreateEventA that
just returns "success" and does nothing,
that's fine.

It depends what Watcom's C library is trying
to achieve.

PDPCLIB doesn't do things like that. I use
PDPCLIB.

BFN. Paul.

> > > My vision of what MSDOS should have become in the late 1980s is here:
> > >
> > > http://pdos.org
> >
> > what does it better than MSDOS?
>
> It is 32-bit instead of 16-bit if you wish
> to have that.

nobody cares about the bitness of the OS. people care if the performance of the OS is faster/slower, but not if it has more bits.

anyDOS can execute 32-bit DOOM.EXE.
PDOS can't - at any speed.

where is PDOS advantage?

in fact, if you can't execute DOS executables why do you call your project 32-bit DOS?

last, not least: don't get me wrong. at least you have something to show which is 100% more the NightDOS

> > > > My vision of what MSDOS should have become in the late 1980s is
> here:
> > > >
> > > > http://pdos.org
> > >
> > > what does it better than MSDOS?
> >
> > It is 32-bit instead of 16-bit if you wish
> > to have that.
>
> nobody cares about the bitness of the OS.

I care. I want to be able to write 32-bit
applications and be able to debug them by
putting debug into the OS, not just the
application.

And if my computer hangs, I want to be able
to debug the OS.

And if I spend time debugging the OS, and
getting familiar with it, I want to be able
to create a commercial derivative of it
without restriction. And for that I need it
to be public domain.

And if I enable paging but keep V = R, to
enable memory protection, I want an MVS-style
dump produced. I already have proof of concept
for that with divide by zero.

If you don't have the same requirements,
that's fine. But don't say "nobody". I'm
not trying to win Miss America, I'm trying
to create a pristine programming environment.

> people care if the performance of
> the OS is faster/slower, but not if it has more bits.

Applications are normally bottlenecked in
the application, not in the OS.

> anyDOS can execute 32-bit DOOM.EXE.
> PDOS can't - at any speed.
>
> where is PDOS advantage?

I don't want to run DOOM.EXE. I want to
run GCCWIN.EXE and GCC386.EXE.

I'm a programmer, not a gamer.

Regardless, I don't know what the internals
of DOOM are, but if it just wants to take
control of the hardware, it can do that
under PDOS. It needs to be compiled to one
of the two supported formats though. If it
doesn't come with C source code you won't
be able to do that currently.

BFN. Paul.

(sorry for the extra reply, I either missed
this bit or you edited your message)

> in fact, if you can't execute DOS executables why do you call your project
> 32-bit DOS?

Because it executes 32-bit DOS executables,
rather than 16-bit DOS executables.

Regardless, I also produce a PDOS/86 that
executes some 16-bit DOS executables. My
hope is for it to also progress to the point
where it can run HX unchanged, to provide
yet another Win32 environment.

> last, not least: don't get me wrong. at least you have something to show
> which is 100% more the NightDOS

My project is public domain. I don't know why
they don't simply pick up my code and do
whatever they want with it. They can slap any
alternative license on it they want. It's
unrestricted public domain.

BFN. Paul.

> where is PDOS advantage?

One claim is that public domain is in some way superior to other open or closed source. I would hope that because PDOS/386 assumes int 21 to do everything in a flat 32-bit mode, it could be made to support DOS32A style API to become useful for protected mode DOS extended apps. It also supports a minimal subset of the Win32 API already, basically just enough to run a compiler: Handle files and console output. There also is a normal PDOS version which runs normal DOS apps in a limited way.

If you limit yourself to BIOS-ignorant apps, PDOS/386 could run DOS32A style apps on UEFI-only systems eventually, by having different versions of the kernel: BIOS-based, UEFI-based or hardware-based device I/O.

My general impression is that both PDOS variants put simplicity and elegance over compatibility and I agree with you that people will not recompile their apps just to run them on yet another newcomer OS. As you compare it to NightDOS, it seems that FD32 is showing some signs of life again. Note that you could technically call everything which talks to apps and BIOS for the purpose of facilitating file access could technically be called a DOS

---
FreeDOS / DOSEMU2 / ...

> But yes, CreateEventA is something I need to
> add to my kernel32.c in order to get jwasm
> to work.
>
> This is Windows crap that I really have no
> interest in. MSDOS doesn't do that.
>
> I have no idea why an assembler would have
> a requirement to create events, whatever
> that even means. It's supposed to be reading
> in a text file and outputting a single binary
> file. Nothing more. You don't need more than
> C90 to do that.

Actually, jwasm is written in C89/C90.

This createevent thing comes from the Open Watcom static C library (maybe something to support Ctrl-C/Ctrl-Break?).

There's also a jwasmd.exe (d for DOS), where the Win32 API used by OW is translated to 32-bit DOS protected-mode int 21h calls (by linking in the HX kernel32 code statically) - I'm afraid, however, that PDOS doesn't support all the int 21h ( and BIOS interrupts ) that this executable will call.

---
MS-DOS forever!

(replying in 2+ parts because I don't know why it
is rejecting my message)

> One claim is that public domain is in some way superior to other open or
> closed source.

Oh yeah - that's another thing I forgot to mention.
People slap copyrights on things precisely because
they know that some people will do things with the
software that they don't want them to do.

I cater for those people who want to do those things.

Almost no-one else does. If you try to find
some public domain OSes, you won't find much.

> I would hope that because PDOS/386 assumes int 21 to do
> everything in a flat 32-bit mode, it could be made to support DOS32A style
> API to become useful for protected mode DOS extended apps.

I looked at DOS32A a couple of weeks ago, saw
that it used segments, and lost interest.

> style apps on UEFI-only systems eventually, by having different versions of
> the kernel: BIOS-based, UEFI-based or hardware-based device I/O.

I have a tentative plan to create a BOOTX64.EFI
that reinstates the BIOS so that there is literally
no change to the PDOS/386 disk except one extra
file is added.

However, before p*lluting my pristine PDOS/386
disk with UEFI aaaa that I never asked for, I
am more interested in bbbbing the firmware
with SeaBIOS to do it there. In addition, I want
SeaBIOS to restore an INT 14H so that I get my
serial port back, even on a system that doesn't
have a serial port. Instead INT 14H can be
directed to bluetooth or wifi. In addition I
would like a BIOS option to make INT 14H read
block.

Wow. It was p*olluting it didn't like. It was
happy with crap and flashing.


> My general impression is that both PDOS variants put simplicity and
> elegance

Right. My plan is to switch from large memory
model to huge memory model so that I can remove
the kludge I put in for PDOS/86 memory management.

A couple of days ago I discovered that although
Watcom generates appropriate code in huge memory
mode, Turbo C doesn't.

Then I would make size_t 32-bit (long) in this
huge memory model.

Another plan (see the "bios" directory for proof
of concept) is to have a C90 BIOS abstraction.
So disks would be seen as just files. This
restricts disks to 2 GiB though. To lift that
restriction I want to make long (only) 64-bit.
Still with 80386 code.

> over compatibility and I agree with you that people will not
> recompile their apps just to run them on yet another newcomer OS. As you

Win32 applications don't need to be recompiled
if they have been written to the lowest
common denominator which is PDOS/386.

> > But yes, CreateEventA is something I need to
> > add to my kernel32.c in order to get jwasm
> > to work.
> >
> > This is Windows crap that I really have no
> > interest in. MSDOS doesn't do that.
> >
> > I have no idea why an assembler would have
> > a requirement to create events, whatever
> > that even means. It's supposed to be reading
> > in a text file and outputting a single binary
> > file. Nothing more. You don't need more than
> > C90 to do that.
>
> Actually, jwasm is written in C89/C90.

It is using non-C90 includes, so I can't
compile against PDPCLIB.

If it is written in C90, why does it need
those includes?

If you can eliminate those includes, I will
be able to produce my own jwasm executable
that works.

I'm using an old jwasm though. I think I tried
to upgrade, but jwasmr didn't work or something
like that, so I went back to the working version.

BFN. Paul.

> Wow. It was p*olluting it didn't like. It was
> happy with crap and flashing.

In fact the word it doesn't like is 'p*oll'.
We just filled the bad words list with words used by forum spammers.

---
Forum admin

> nobody cares about the bitness of the OS.

> where is PDOS advantage?

Here's what someone wrote in an email to me
in 2014. Note that I started in 1994, long
before this person emailed me, but I had
always hypothesized that people like him
existed.


Dear Paul Edwards,

I just found PDOS and read your manifesto. Right on!

My problems are that a) I don't trust any OS for cybersecurity reasons,
and need to read the code, and also b) I want to do some new things with
it and not have to give them away.

But as you astutely point out, if more such components were free of
restrictions, commercial code will be better and cheaper, precisely what
I hope to do.

It's too early to commit (10 minutes in) to contributing enhancements. I
might work up to it. But I could kick in a few bucks. If I can find an
address I'll just mail in a check for my donation.

Man, I really appreciate you're having this idea and getting this far
with it! It's saving my butt.

BTW, you know how Win32 programs normally
say "this program cannot be run in DOS mode"?

Here's what executables I produce say:

C:\winpath>hexdump md5.exe 0 200
000000 4D5A9000 03000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 80000000 ................
000040 0E1FB409 BA1000CD 21B001B4 4CCD2100 ........!...L.!.
000050 496E7374 616C6C20 4858206F 72207570 Install HX or up
000060 67726164 6520746F 2050444F 532F3338 grade to PDOS/38
000070 36206F72 2057696E 65206574 630D0A24 6 or Wine etc..$
000080 50450000 4C010400 8748D860 00000000 PE..L....H.`....
000090 00000000 E0000E02 0B010238 000E0000 ...........8....
0000A0 00060000 00000000 00100000 00100000 ................
0000B0 00000000 00004000 00100000 00020000 ......@.........
0000C0 04000000 01000000 ........

Another thing of interest, especially since there
are so many Germans here.

I don't wish to support UTF-8. I want to return
to having non-ASCII characters in the top 128
bytes.

People can code using wchar_t, but I have defined
that as one byte.

The Vietnamese need 6 control characters to be
released, so I have found 6 that don't interfere
with micro-emacs keystrokes that I use or
anything else. VISCII takes things I use.

The Chinese are the only people who have
exceeded 2 bytes, so they can have a wchar_t
of 4, which will incidentally cover anyone
who likes Unicode.

All they need to do is recompile. They do not
need to depend on Microsoft.

BFN. Paul.

I remember we had some PDOS thread here in the past...
http://www.bttr-software.de/forum/mix_entry.php?id=16623
I could give it a try again :)
BTW are you aware about RDOS?
http://www.rdos.net/eng/
It seems it went much further with HW support so maybe would be good to blend the best of both. I also like the idea to create something usable for UEFI-only systems, of course I would prefer to hack SeaBIOS in as CSM but if not possible would be better to have something than nothing.
Do you use your PDOS for some embedded application or just for self-education purpose?

---
DOS gives me freedom to unlimited HW access.

> This is what I have: https://sourceforge.net/p/pdos/gitcode/ci/master/tree/readme.txt

Ok, that's not much. However, since DPMI isn't even mentioned in your document, I guess that this API (int 31h) doesn't exist. That's a pity.

---
MS-DOS forever!

I welcome any development of a possible UEFI-replacement for DOS, and the elegance of your "32-bit MSDOS" seems like it one day will surmount the CSM / BIOS limitations which a 16-bit MSDOS imposes.

Memory and file systems supported? FAT32, EX-FAT, NTFS? Is it in fact file-system agnostic? Getting away from Microsoft standards is important, but so is backward compatibility with extant filesystems. Does it support unsigned long access to files natively, ie able to access files from 2 GiB to 4 GiB-1? How about access to PAE memory as has been done with Japheth's XMS 3.5 protocol, for example.

> BTW are you aware about RDOS?
> http://www.rdos.net/eng/

I went there:

RDOS source code is distributed as GPL

Not something I wish to get involved with.
May as well just run Linux+Wine.

Note that I actually contacted the author
of EMX asking him if he would be willing to
make his code public domain, and he said it
would be quicker for me to write my own than
convince him to make his public domain.

So 27 years or whatever later, here we are.

> Do you use your PDOS for some embedded application or just for
> self-education purpose?

Neither. I just wanted to create a public domain
"base" so that others didn't need to start from
scratch.

It's normal to do market research before producing
a product, rather than the other way around, but
as Rum says, "opinion is divided":

http://allblackadderscripts.blogspot.com/2012/12/blackadder-ii-episde-3-potato.html

BFN. Paul.

> > This is what I have:
> https://sourceforge.net/p/pdos/gitcode/ci/master/tree/readme.txt
>
> Ok, that's not much. However, since DPMI isn't even mentioned in your
> document, I guess that this API (int 31h) doesn't exist.

Correct. To date I haven't found a use for that.

> That's a pity.

Why is that? You're only executing that so that
you can get access to INT 21H, right?

You have direct access to that under PDOS/386.

I guess I could create an INT 31H that just
redirects you to INT 21H if that would help.

BFN. Paul.

> I welcome any development of a possible UEFI-replacement for DOS, and the
> elegance of your "32-bit MSDOS" seems like it one day will surmount the CSM
> / BIOS limitations which a 16-bit MSDOS imposes.

Surely if we're going to involve UEFI, the first
thing we should have is a UEFI that simply restores
the basic BIOS services?

That then makes all BIOS-dependent OSes work, not
just "32-bit MSDOS".

> Memory and file systems supported? FAT32, EX-FAT, NTFS? Is it in fact

What memory are you talking about? Currently I
just call the BIOS to get the extended memory
size, which gives me enough to run gccwin, but
it is my intention to get the proper memory
map so that I have access to nearly 4 GiB or
whatever. It just hasn't been a priority.

FAT-12, 16, 32 are supported. Note that FAT-32
and LFN was entirely written by an 18-year old
girl called Alica from Slovakia.

> file-system agnostic?

In what way? My main focus is on C90, so most
applications I care about do not know what
the file system is.

> Getting away from Microsoft standards is important,
> but so is backward compatibility with extant filesystems. Does it support
> unsigned long access to files natively, ie able to access files from 2 GiB
> to 4 GiB-1?

C90 is limited to seeking to a "long", so I don't
want to get involved in kludges to exceed that.

To exceed that my intention is to change gccwin
so that "long" (only) is 64-bit. Using 80386
instructions still.

> How about access to PAE memory as has been done with Japheth's
> XMS 3.5 protocol, for example.

I don't know what PAE is. Alica added paging,
but my only interest in paging is to switch
it off so that V=R and I return to a simple,
understandable system. Then when an exception
like divide by zero occurs, I will be able to
print an MVS-style dump that includes stack
traceback.

Note that over the weekend I discovered that
Windows has the ability to do the equivalent,
it's just not enabled by default.

It starts with this PowerShell script:

enabdump.ps1:
New-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting" -Name "LocalDumps"
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" -Name "DumpFolder" -Value
"%LOCALAPPDATA%\CrashDumps" -PropertyType "ExpandString"
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" -Name "DumpCount" -Value 10 -PropertyType DWord
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\Windows Error
Reporting\LocalDumps" -Name "DumpType" -Value 2 -PropertyType DWord

and then you match it with windbg, link maps
and assembler listings (with offsets) of your
C code.

Probably a majority of the time you will be able
to solve a production problem with a single
crash, instead of needing to be able to reproduce
the problem in dev.

Note that I have a plan to change gccwin to save
all registers on function entry, and save the EIP
and function name by doing a "call", so that the
entire stack traceback is predictable. That's how
to match MVS convention which I like.

BFN. Paul.

> I guess I could create an INT 31H that just
> redirects you to INT 21H if that would help.

I think that DPMI API INT31 is something different that cannot be simply redirected to INT21. But maybe HDPMI/CWSDPMI source could be ported some way to PDOS. But I'm not sure what apps will then use DPMI as PDOS native apps are 32b and don't need DPMI and standard 32b DPMI apps for DOS cannot run in PDOS. But maybe PDOS could load e.g. DJGPP 32b apps? I don't know if there's some hard obstacle why not as they are also 32b apps but requires DPMI API...

---
DOS gives me freedom to unlimited HW access.

> > I guess I could create an INT 31H that just
> > redirects you to INT 21H if that would help.
>
> I think that DPMI API INT31 is something different that cannot be simply
> redirected to INT21. But maybe HDPMI/CWSDPMI source could be ported some
> way to PDOS. But I'm not sure what apps will then use DPMI as PDOS native
> apps are 32b and don't need DPMI and standard 32b DPMI apps for DOS cannot
> run in PDOS. But maybe PDOS could load e.g. DJGPP 32b apps? I don't know if
> there's some hard obstacle why not as they are also 32b apps but requires
> DPMI API...

I guess the first thing that should be asked is
what 32-bit MSDOS should look like.

There are multiple 32-bit DOS-extenders. DOS32A
comes close to what I decided was "clean" myself.

However, they mixed segments up in it.

Win32 doesn't use segments anywhere within the
application, and I agree with Microsoft that
that is clean.

Win32 also provides a "get memory" function,
unlike POSIX, and once again I agree with
Microsoft.

When I look at a Win32 executable that is
reliant on nothing more than msvcrt.dll, I
see a clean (and small) executable. I disagree
with Microsoft at this point because they didn't
make msvcrt.dll a formal interface. I have
instead standardized on that, and restricted
it to C90.

Another thing that I sort of diverge from
Microsoft is that I would have thought this
DLL, or rather, set of functions, should have
been provided as a parameter to the executable.
Like UEFI does. But I'm not 100% sure that
the UEFI/my way is superior to Microsoft's.
I'm not sure how to prove that one way or
the other.

When I look at DOS32A (or the DOS/4GW that
it followed), I think that their design is
inferior to the segment-less designs.

I don't know what all the other DOS extenders
did. If one of them had a clean segment-less
design, I might be willing to change PDOS to
use that, for compatibility.

But if it's a choice between cleanliness and
compatibility, I'll choose cleanliness.

And I note that I already have compatibility
with the ubiquitous Win32 executable format.
I don't think having an "INT 21H" in an
executable, even a 32-bit executable, is a
good thing to do. It prevents me from doing
the "C90 BIOS" thing which would allow me
to run PDOS as a user-mode application under
normal Windows.

So although I have an INT 21H OS, and it
works, I ask people to not directly execute
that. HX executing it would be fine though.
I'm interested in adjusting for HX. I'm just
not familiar with the internals of HX to
know what the scope of any adjustments
would be.

BFN. Paul.

Hello kerravon,

> I guess the first thing that should be asked is
> what 32-bit MSDOS should look like.
>
> There are multiple 32-bit DOS-extenders. DOS32A
> comes close to what I decided was "clean" myself.

Just implement DPMI. Come on, DPMI was hashed out by a committee comprising Microsoft, Borland, IBM, Intel, Rational Systems, etc., etc., etc. There is a formal standard for it. And there is a sizeable body of software that implement DPMI hosts and DPMI clients.

Basically you are now saying that we should throw away all this prior work because you, in your infinite wisdom, have cogitated up your own new "clean" vision of "what 32-bit MSDOS should look like".

Well, to that I say: good day, sir.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

Hello RayeR,

> I think that DPMI API INT31 is something different that cannot be simply
> redirected to INT21. But maybe HDPMI/CWSDPMI source could be ported some

That is correct (http://www.delorie.com/djgpp/doc/dpmi/). int 0x31 is only for DPMI-specific services --- the various BIOS and DOS services must still be invoked via int 0x10, int 0x21, int 0x33, etc. (sometimes by way of int 0x31).

> run in PDOS. But maybe PDOS could load e.g. DJGPP 32b apps? I don't know if
> there's some hard obstacle why not as they are also 32b apps but requires
> DPMI API...

I have look at the DJGPP C library source code --- and yes, the DJGPP libc runs directly on top of a DPMI host, without any DOS extender. This is unlike Watcom's 32-bit libc, which (if I am not wrong) will need a DOS extender to work properly.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> > > I guess I could create an INT 31H that just
> > > redirects you to INT 21H if that would help.

so you are completely clueless about the INT 31H interface.
and unfortunately completely unwilling to learn.

> There are multiple 32-bit DOS-extenders. DOS32A
> comes close to what I decided was "clean" myself.

there is no such thing as a DOS-extender standard.
however, virtually all DOS extenders gave you a runtime library which gave you

malloc(many MB);
write(handle, buffer, many MB);
32-bit pointers without segments


and so on, and translated this transparently to 16-bit MSDOS (or any other OS). the translation layer is absolutely undefined and is provided by some runtime library. but the boundaries are clear: DPMI and INT21H on one side, STDIO.H on the other.

so basically you offer/implement your own DOS extender, and require everyone to recompile. this is simply not going to happen.

> Win32 doesn't use segments anywhere within the
> application and I agree with Microsoft that
> that is clean.

DOS extender applications haven't used segments for what you intend to do for the last 30 years. 'hello world' applications don't need segment registers.
GCC has been ported to DOS, 30 years ago.

UNLESS it was *really* necessary because some functionality was required that wasn't covered by this DOS extender, so the application had to call BIOS functions directly.

think "load VGA character font".

> > > > I guess I could create an INT 31H that just
> > > > redirects you to INT 21H if that would help.
>
> so you are completely clueless about the INT 31H interface.
> and unfortunately completely unwilling to learn.

Well, I am happy to learn about it when I actually
need it, but to date I've never actually needed it.

The first things I would like to know are:

1. Why didn't PDOS/386 need it?
2. Would PDOS/386 be better if it had used it?

> > There are multiple 32-bit DOS-extenders. DOS32A
> > comes close to what I decided was "clean" myself.
>
> there is no such thing as a DOS-extender standard.

Maybe there should be? What should be the
design goals?

> however, virtually all DOS extenders gave you a runtime library which gave
> you
>
> malloc(many MB);
> write(handle, buffer, many MB);
> 32-bit pointers without segments

> and so on, and translated this transparently to 16-bit MSDOS (or any other
> OS).

If "any other OS" includes "a 32-bit OS, maybe
even Linux", that is interesting.

But why write() instead of fwrite()? It is the
latter that is part of C90.

> the translation layer is absolutely undefined and is provided by some
> runtime library. but the boundaries are clear: DPMI and INT21H on one side,
> STDIO.H on the other.

Ok, rightly or wrongly (how do you prove
which one?), I look at the executable itself,
not just the application source code.

I don't like the idea of the "ds" or "es"
being manipulated inside an executable.

Don't forget I have my own C library, PDPCLIB,
so I actually have to implement any solution,
so I know what goes into it. I don't mind if
there are kludges *outside* the executable,
but I want every byte *inside* the executable
to "look nice".

I'm not an expert at this, so maybe I'm wrong
when I make a clean/unclean judgement.

> so basically you offer/implement your own DOS extender, and require
> everyone to recompile. this is simply not going to happen.

It happens to anything I am interested in, such
as micro-emacs.

If I don't win some popularity contest, so be it.

And regardless, Win32 executables don't require
recompilation.

> > Win32 doesn't use segments anywhere within the
> > application and I agree with Microsoft that
> > that is clean.
>
> DOS extender applications haven't used segments for what you intend to do
> for the last 30 years. 'hello world' applications don't need segment
> registers.
> GCC has been ported to DOS, 30 years ago.

GCC was only made C90-compliant recently.

PDOS/386 currently only runs C90-compliant
programs. Well, at least if you don't want
a warning to be printed.

BFN. Paul.

> > I guess the first thing that should be asked is
> > what 32-bit MSDOS should look like.
> >
> > There are multiple 32-bit DOS-extenders. DOS32A
> > comes close to what I decided was "clean" myself.
>
> Just implement DPMI.

DOS32A executables are not particularly
dependent on DPMI. They use segment registers
a bit (no idea why DOS/4GW chose to do that),
but they don't directly call INT 31H. And why
should they?

> Come on, DPMI was hashed out by a committee
> comprising Microsoft, Borland, IBM, Intel, Rational Systems, etc., etc.,
> etc. There is a formal standard for it. And there is a sizeable body of
> software that implement DPMI hosts and DPMI clients.

> Basically you are now saying that we should throw away all this prior work
> because you, in your infinite wisdom, have cogitated up your own new
> "clean" vision of "what 32-bit MSDOS should look like".

Even Microsoft didn't follow what is apparently
their own standard. They created a new Win32
standard instead. Why did they do that if DPMI
was so great?

I'm not saying they are right or wrong, I'm just
asking what the underlying philosophy is. It would
be good if the proper API could be mathematically
proven (I'm not a mathematician, but that's what
gives me the most confidence), but in the absence
of that, I'd like to know what the mechanism is
for creating APIs.

I know that Linux executables have "INT 80H" in
them, while Win32 executables do not. Now that
I know I would like (as an option) to run
PDOS/386 under Windows 10, or Linux, I "know"
that I cannot have any "INT" instructions in
my application executables, because I do not
have control of the interrupt vectors when
PDOS/386 is running in user mode.

But I've never heard anyone make the argument
"Windows is technically better than Linux because
its executables aren't tied to interrupt vectors".

In the absence of mathematical proof either way
for the above hypothesis, what tools should be
used to answer it? The only tool I have at the
moment is my "bios" proof of concept that calls
"generic PDOS". I can look at it and say that
it won't work if anyone does an INT instruction.

BFN. Paul.

> In the absence of mathematical proof either way
> for the above hypothesis, what tools should be
> used to answer it? The only tool I have at the
> moment is my "bios" proof of concept that calls
> "generic PDOS". I can look at it and say that
> it won't work if anyone does an INT instruction.

I think the test is - any application executable
that demands that a segment register be set a
certain way, or an interrupt vector be set a
certain way, precludes the ability of the caller
to be unprivileged.

Instead, only instructions (such as mov ecx, edx)
should exist inside an executable, as these are
unprivileged instructions that have no dependencies
on particular memory locations or particular
privileged registers.

So that includes anyone who calls INT 21H directly
at all, nevermind INT 31H.

Note that if PDOS/386 or HX do these interrupts
internally, that is fine, as they are part of
the OS implementation (from my perspective,
anyway). The HX applications themselves do not
depend on INT 31H. That instruction is not
inside the Win32 executables themselves.

BFN. Paul.

> > I guess I could create an INT 31H that just
> > redirects you to INT 21H if that would help.
>
> I think that DPMI API INT31 is something different that cannot be simply
> redirected to INT21. But maybe HDPMI/CWSDPMI source could be ported some
> way to PDOS. But I'm not sure what apps will then use DPMI as PDOS native
> apps are 32b and don't need DPMI and standard 32b DPMI apps for DOS cannot
> run in PDOS. But maybe PDOS could load e.g. DJGPP 32b apps? I don't know if
> there's some hard obstacle why not as they are also 32b apps but requires
> DPMI API...

Just thinking about this some more.

If I'm going to get anything else to work, the
thing that interests me the most is HX.

I would be happy to implement some subset of
DPMI purely for use by HX. If someone else
uses it too, they're on their own.

But at what level does INT 31H make sense in
a PDOS/386 environment? There is no 16-bit
DOS waiting to be called, and if you attempt
to do that, you will fail.

So what sort of INT 31H call could HX do that
makes sense in a "pure" 32-bit environment?

I would be happy to translate an attempt to
call a non-existent 16-bit API back into a
32-bit API call. After all, the INT 21H
functions match already. If I have missed
any INT 21H functions, that's not a problem,
I'm happy to add anything important.

I'm happy to provide dummy functions in
INT 31H to satisfy HX too.

BFN. Paul.

> But at what level does INT 31H make sense in
> a PDOS/386 environment? There is no 16-bit
> DOS waiting to be called, and if you attempt
> to do that, you will fail.

I think this all is a misunderstanding.

You labeled this thread "32-bit MSDOS" and this made a few people ( including me ) think that you had to offer a somewhat "DOS compatible" OS. It's clear now that this is not the case - and hence there's absolutely no need to implement DPMI for your OS.

---
MS-DOS forever!

> > But at what level does INT 31H make sense in
> > a PDOS/386 environment? There is no 16-bit
> > DOS waiting to be called, and if you attempt
> > to do that, you will fail.
>
> I think this all is a misunderstanding.
>
> You labeled this thread "32-bit MSDOS" and this made a few people (
> including me ) think that you had to offer a somewhat "DOS compatible" OS.
> It's clear now that this is not the case

Well, it depends what you mean by "DOS
compatible". INT 21H exists. The INT 21H
looks very much like MSDOS and very much
like DOS32A, but not identical.

It's obviously designed to be called in PM32,
hence the "32-bit" in the title.

I'm not sure if it is a misunderstanding or
a semantic debate.

> - and hence there's absolutely no
> need to implement DPMI for your OS.

Ok. I have my own kernel32.dll and msvcrt.dll,
but I would like to support all the other
HX DLLs.

What are those other HX DLLs dependent on?

I can flesh out my own kernel32.dll as required.

Thanks. Paul.

> I think the test is - any application executable
> that demands that a segment register be set a
> certain way, or an interrupt vector be set a
> certain way, precludes the ability of the caller
> to be unprivileged.

Afaik Windows and Linux use %fs for TLS.

Hello kerravon,

> I think the test is - any application executable
> that demands that a segment register be set a
> certain way, or an interrupt vector be set a
> certain way, precludes the ability of the caller
> to be unprivileged.

I appreciate that PDOS is your personal project --- but what you said is simply not true.

I do not know where you get the idea that DPMI applications demand "that a segment register be set a certain way", or that they cannot run unprivileged.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> I think this all is a misunderstanding.
>
> You labeled this thread "32-bit MSDOS" and this made a few people (
> including me ) think that you had to offer a somewhat "DOS compatible" OS.
> It's clear now that this is not the case - and hence there's absolutely no
> need to implement DPMI for your OS.

Amen.

> > I think the test is - any application executable
> > that demands that a segment register be set a
> > certain way, or an interrupt vector be set a
> > certain way, precludes the ability of the caller
> > to be unprivileged.
>
> Afaik Windows and Linux use %fs for TLS.

I know every byte that goes into the Win32
executables that I produce (that run under
normal Windows, HX and PDOS/386). There is no
requirement for %fs to be set. I don't even
know what TLS is.

BFN. Paul.

> > Afaik Windows and Linux use %fs for TLS.
>
> I know every byte that goes into the Win32
> executables that I produce (that run under
> normal Windows, HX and PDOS/386).

> There is no
> requirement for %fs to be set. I don't even
> know what TLS is.

I'm sure you know your subset, but since TLS also plays a role in SEH, in practice it is quite important for non trivial windows binaries, e.g. ones that interface COM, or use native Windows C++ and thus system libraries for exceptions (rather than SJLJ emulation)

Of course since TLS is related to threading it might be less relevant on a single threaded OS like dos. But the subset of Windows binaries (even commandline) that will run decreases because of it.

Which is sad, since from what I have read, Win32 seems to be the only way of running existing binaries on your OS.

Apropos, nearly all dos extenders use DPMI services for their memory operations (e.g. allocate blocks >1MB), access to segments and hooking interrupts. Emulating those should make it easier to retarget existing compilers.

> > I think the test is - any application executable
> > that demands that a segment register be set a
> > certain way, or an interrupt vector be set a
> > certain way, precludes the ability of the caller
> > to be unprivileged.
>
> I appreciate that PDOS is your personal project --- but what you said is
> simply not true.
>
> I do not know where you get the idea that DPMI applications demand "that a
> segment register be set a certain way",

http://dos32a.narechk.net/manual/index.html

ES = 32-bit data selector with base=PSP and limit=256 bytes


That's what DOS32A executables require. The
caller needs the privilege requires to set the
ES register. In some environments I am interested
in, that is not possible.

Win32 executables do not have such a requirement.
I have no idea why DOS32A (and thus DOS/4GW) didn't
just pass that on the stack.

> or that they cannot run unprivileged.

It is the caller who needs to be privileged in
order to set segment registers and interrupt
vectors. In an environment I am interested in
(interested in running Win32 executables), I
will not be privileged.

I can't think of any reason to require a
privileged caller when the stack can be used.

Note that Win32 executables don't use the stack
for this purpose, they have DLL references
resolved at load time instead. I think (I'm not
sure) the stack would have been better, but the
important thing is that the loader doesn't need
to be privileged in either design.

BFN. Paul.

> > I do not know where you get the idea that DPMI applications demand "that
> a
> > segment register be set a certain way",
>
> http://dos32a.narechk.net/manual/index.html
>
> ES = 32-bit data selector with base=PSP and limit=256 bytes
>
>
> That's what DOS32A executables require. The
> caller needs the privilege requires to set the
> ES register. In some environments I am interested
> in, that is not possible.

And how is that related to DPMI ? E.g. DJGPP go32v2 programs afaik assume es to be simply equal to ds. (so that rep movsb can be used to copy)

We also map the first 1MB of memory to the FS selector for easy dos access, but that is also not related to DPMI, and since your OS would be an independent target/OS anyway, that is not relevant.


> > or that they cannot run unprivileged.
>
> It is the caller who needs to be privileged in
> order to set segment registers and interrupt
> vectors. In an environment I am interested in
> (interested in running Win32 executables), I
> will not be privileged.

You can work around entry requirements in the privileged program loader. Doesn't have to mean that the binary itself must run privileged.

> My vision of what MSDOS should have become in the late 1980s is here:
>
> http://pdos.org
>
> Specifically in addition to IO.SYS, MSDOS.SYS and COMMAND.COM should have
> been added KERNEL32.DLL and MSVCRT.DLL.

Reading the site and the thread, I only see one application, a BBS. (besides some ported toolchains)

What do you envision as the audience for your OS, and because it seems porting requires work, what are the major attractions above other systems that would make that effort worthwhile?

> > > Afaik Windows and Linux use %fs for TLS.
> >
> > I know every byte that goes into the Win32
> > executables that I produce (that run under
> > normal Windows, HX and PDOS/386).
>
> > There is no
> > requirement for %fs to be set. I don't even
> > know what TLS is.
>
> I'm sure you know your subset, but since TLS also plays a role in SEH, in
> practice it is quite important for non trivial windows binaries, e.g. ones
> that interface COM, or use native Windows C++ and thus system libraries for
> exceptions (rather than SJLJ emulation)

I don't know any of those terms, but GCCWIN is
a 3 MB executable and hardly "trivial". It's
400,000 lines of C code.

> Of course since TLS is related to threading it might be less relevant on a
> single threaded OS like dos. But the subset of Windows binaries (even
> commandline) that will run decreases because of it.

My focus is on getting C90-compliant programs
to work. The onus is on applications to be
written in such a way that in an environment
that doesn't support threading, the code base
produces a sensible executable.

> Which is sad, since from what I have read, Win32 seems to be the only way
> of running existing binaries on your OS.

It is the way that is officially supported.

It also runs (after defining!) 32-bit MSDOS
executables that look quite similar to
DOS32A, but don't make demands on segment
registers (but do make the same/similar
demand on INT 21H).

> Apropos, nearly all dos extenders use DPMI services for their memory
> operations (e.g. allocate blocks >1MB), access to segments and hooking
> interrupts. Emulating those should make it easier to retarget existing
> compilers.

It seems harmless enough to redirect an INT 31H
that requests >1MB memory to the appropriate
INT 21H function (which was necessarily an
extension in PDOS/386).

But access to what segments? I only have one
usable selector and the segment registers are
already set correctly. If any DPMI application
intends to inspect or modify those, it isn't
going to work. ie DOS32A won't work when it
starts looking at ES expecting a parameter
there.

There is an existing MSDOS call to hook interrupts
though. That is OK. I can redirect INT 31H to the
standard INT 21H call to hook interrupts.

So with 2 out of the 3 above things being doable,
does that enable anything existing to run?

Thanks. Paul.

> > My vision of what MSDOS should have become in the late 1980s is here:
> >
> > http://pdos.org
> >
> > Specifically in addition to IO.SYS, MSDOS.SYS and COMMAND.COM should
> have
> > been added KERNEL32.DLL and MSVCRT.DLL.
>
> Reading the site and the thread, I only see one application, a BBS.

The BBS is running on PDOS/3X0 (mainframe)
not PDOS/386. There is a terminal program
running on PDOS/386 though. It directly
does INT 14H BIOS calls at the moment, so
something that should be moved to the OS.

> (besides some ported toolchains)

That's a whole class of executables. They're
not "ported", they are native Win32 executables.

> What do you envision as the audience for your OS, and because it seems
> porting requires work, what are the major attractions above other systems
> that would make that effort worthwhile?

My main audience is companies who would like to
write a commercial Windows clone to compete with
Microsoft's monopoly. They have a (somewhat)
working system to use as a base instead of having
to start from scratch. Companies that won't touch
something unless it is public domain so that they
can close-source it and/or not be bound by any
other conditions that they consider to be
unacceptable.

The audience for PDOS/3X0 is for companies to
compete with IBM's monopoly on mainframes.

In the absence of companies willing to use PDOS
as a base, or even know that it exists, I just
plug away at it myself. 27 years and counting.
Hopefully my estate will be used to continue
plugging away after I'm dead.

BTW, Microsoft has just abandoned 32-bit CPUs
with Windows 11, which means the entire 8086
market (which PDOS/86 competes in) and the
entire 80386 market (which PDOS/386 competes
in), has been left without supported Microsoft
competition.

Someone once told me "you take the best, I'll
take the rest".

BFN. Paul.