DOS ain't dead

Microsoft has just released the source code to some
version of MSDOS 4.0:

https://github.com/microsoft/MS-DOS

I haven't yet determined whether it is the "European"
version that supports NE executables. That's of
interest to me, as I am basically looking to convert
PDOS/86 to run NE executables in either RM16 or PM16
(and have massive amounts of memory in the latter).

And I would like to understand the "prior art".

BFN. Paul.

> Microsoft has just released the source code to some
> version of MSDOS 4.0:
>
> https://github.com/microsoft/MS-DOS
>
> I haven't yet determined whether it is the "European"
> version that supports NE executables. That's of
> interest to me, as I am basically looking to convert
> PDOS/86 to run NE executables in either RM16 or PM16
> (and have massive amounts of memory in the latter).
>
> And I would like to understand the "prior art".
>
> BFN. Paul.

You have both. The regular 4.0 as well as the Multitasking/European MT-DOS.

---
Visit my personal blog at https://www.javiergutierrezchamorro.com

> Microsoft has just released the source code to some
> version of MSDOS 4.0:
>
> https://github.com/microsoft/MS-DOS
>
> I haven't yet determined whether it is the "European"
> version that supports NE executables. That's of
> interest to me, as I am basically looking to convert
> PDOS/86 to run NE executables in either RM16 or PM16
> (and have massive amounts of memory in the latter).
>
> And I would like to understand the "prior art".
>
> BFN. Paul.

I’m mind blown they’ve released this.

> Microsoft has just released the source code to some
> version of MSDOS 4.0:
>
> https://github.com/microsoft/MS-DOS
>

and it comes with an early version of EMM386:
https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/MEMM/MEMM

> and it comes with an early version of EMM386:
> https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/MEMM/MEMM

Yeah!!!
And SmartDrv is included as well!!!
Even better, Tools MS C 5.1 and Masm 5.1 aren't missing, so there should be no problems to create the binaries!!!
And the best at last: the linker ( MS overlay linker v3.65 ) even suffers from the infamous "packed file is corrupt"-A20-Gate-EXEPACK-error!!!

The good old times...

* "...so there should be no problems to create the binaries": may be true - if you can overcome the fact that the source files are all LF only, while the good old MS-DOS tools from the 80ties stubbornly persist on CR/LF line endings.

---
MS-DOS forever!

* The history of Multitasking MS-DOS
* Multitasking MS-DOS 4 - BetaWiki

---
Forum admin

> if you can overcome the fact that the source files are all LF only, while
> the good old MS-DOS tools from the 80ties stubbornly persist on CR/LF line
> endings.

Maybe it happened due to some github online conversion? Versioning SW sometimes do this fun stuff, depend how configured. But no problem to batch-convert back to CR+LF...

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

> > if you can overcome the fact that the source files are all LF only,
> while
> > the good old MS-DOS tools from the 80ties stubbornly persist on CR/LF
> line
> > endings.
>
> Maybe it happened due to some github online conversion? Versioning SW
> sometimes do this fun stuff, depend how configured. But no problem to
> batch-convert back to CR+LF...

There were more problems than just that, but I have
overcome them (a lot of effort after I sent that
previous post - and I was unexpectedly out of
internet coverage) with my Windows 2000 system
and you can find:

http://pdos.org/dos4.zip

See \devel\dos4mods\readme.txt

There are still more issues found when I attempted to
redo the build on DOS 4.0 itself instead of Windows 2000.

The CRLF hit harder for some reason, so the files like
chdir.asm will choke with either a hang or spurious errors.

You need to add FILES= whatever to config.sys

Can't remember if I added the SHELL= - need to increase
the environment space.

I will fix those errors in due course and upload a new
version, but that's what I have at the moment.

I am at a bit of a quandry here.

I had to use edlin to make any changes. I finally got
"e" to exit with save as opposed to "q" to quit.

Using just this disk - ie just the raw DOS 4.0 files -
I could theoretically write a program to convert
LF to CRLF etc rather than just copying an unzip
program across. I already have a crlffix - I could
copy that across instead and likely compile it.

Not sure what a sensible goal here would be.

I am actually interested in having MSDOS 4.0 (modified)
competing against Freedos. MSDOS 4.0 has the more
liberal license. Basically no conditions (MIT).

BFN. Paul.

> > I haven't yet determined whether it is the "European"
> > version that supports NE executables. That's of

> You have both. The regular 4.0 as well as the Multitasking/European MT-DOS.

Can you point me to the source code for the latter?

The source code in 4.0 is not the multitasking version - I
can see in src/dos/exec.asm line 154:

CMP AL,3 ; only 0, 1 or 3 are allowed
JNA exec_check_2

that it is non-multitasking, which would explain why I
can't find any sign of "NE".

Thanks. Paul.

> > > I haven't yet determined whether it is the "European"
> > > version that supports NE executables. That's of
>
> > You have both. The regular 4.0 as well as the Multitasking/European
> MT-DOS.
>
> Can you point me to the source code for the latter?
>
> The source code in 4.0 is not the multitasking version - I
> can see in src/dos/exec.asm line 154:
>
> CMP AL,3 ; only 0, 1 or 3 are allowed
> JNA exec_check_2
>
> that it is non-multitasking, which would explain why I
> can't find any sign of "NE".
>
> Thanks. Paul.

v4.0-ozzie is the multitask one, but it doesn't come with everything.

> > Can you point me to the source code for the latter?
>
> v4.0-ozzie is the multitask one, but it doesn't come with everything.

Well I can't maintain it if I don't have the source code.

But I might be able to do sufficient analysis of it to
add the minimal NE functionality I would need, to the
standard 4.0 sources.

And technically I don't even need that - I could have
an entirely different scheme.

I mainly need a (potentially) slightly different scheme -
I need a way of getting the environment variables without
needing to inspect the stack on entry.

So even though there is no PSP, I need to be able to
retrieve a fake PSP - or some other method.

Or I can just code a new function code.

Also I noticed that this has things like DosWrite().
This is basically an early incarnation of OS/2 - and
one that looks better to me - ie it doesn't use the
ULONG etc.

And it has a DosFindFirst() as well, that uses the DTA
in a complex way which I wasn't able to decipher.

Also, the permissive license means that another thing
comes into view - HX. If MSDOS 4.0 is married up with
HX - perhaps even incorporating the hxldr32, we basically
get a Win32 system.

The license isn't visible on the source tree here:

https://github.com/Baron-von-Riedesel/HX/tree/master

This says very little:

https://github.com/Baron-von-Riedesel/HX/blob/master/HXsrc.txt

5. License

The HX DOS extender is freeware. Copyright 1996-2020 Japheth.

Japheth


If you sniff around further you find:

https://github.com/Baron-von-Riedesel/HX/blob/master/Src/HXLDR32/HXLDR32.TXT

It's unclear how widely that applies, but it says:

6. Copyright

HXLdr32 is part of HX DOS extender. This extender is freeware.
View HXRT.TXT for licence details.

Japheth


That file - HXRT.TXT - is not included in the above source tree,
but if you download HXRT221.zip you can see it, and it has more
verbiage:



8. License

The HX DOS extender runtime is freeware and may be used for any purpose.
Copyright Japheth 1996-2022. The HX runtime can be freely distributed
with any application.

Japheth


Which is basically unrestricted as I see it.

The MIT license for MSDOS 4.0 says:

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.


I don't see anything requiring source code to be published
in either of those things.

Which means the traditional closed source model for commercial
(viable) software could be used.

So some of us here could potentially start a company.

I'm more interested in getting it to the point where
that would be feasible, rather than getting involved
in administering a business.

One other thing that could be important is incorporating
DOSLFN - not sure what the license on that is, or whether -
if it is restrictive - there is some competitor.

BFN. Paul.

> Also I noticed that this has things like DosWrite().
> This is basically an early incarnation of OS/2 - and
> one that looks better to me - ie it doesn't use the
> ULONG etc.

Just to expand - Microsoft *did* create a C-callable
interface to MSDOS - ie DosWrite() etc. This is apart
from anything they included in their C compiler
(write() or whatever - not sure what they provided).

And if you accept the legitimacy of the DosWrite()
call interface (used - albeit barely - by Microsoft's
own utilities), like:

v4.0/src/CMD/RESTORE/RTFILE.C

/*************************************************************/
/* write to dest file */
/*************************************************************/
retcode =
DOSWRITE
(dest_file_handle,
(char far *)&buf_pointer[0],
(unsigned) numread,
(unsigned far *) &numwrite
);

Then the definition of "32-bit MSDOS" would be:

v4.0/src/H/DOSCALLS.H

extern unsigned far pascal DOSWRITE (
unsigned,
char far *,
unsigned,
unsigned far * );

but those 16-bit unsigned parameters now naturally
morph into 32-bit (exactly what should happen for
a transition to 32-bit), and the pointers remain
as 32-bit, but obviously the "far" keyword is no
longer applicable, and they are flat pointers.

Since a recompilation is being done regardless, the
"pascal" calling convention could be dropped in
favor of cdecl.

And given the naming convention, you end up with
something similar to OS/2.

OS/2 in actuality went with:

USHORT APIENTRY DosWrite(USHORT hfile, void *ptr,
USHORT towrite, USHORT *tempWritten);

for 16-bit

and:

ULONG APIENTRY DosWrite(ULONG hfile, void *ptr,
ULONG towrite, ULONG *tempWritten);


ie the source code is not compatible.

In actuality you can simply ignore the official OS/2
documentation and use the MSDOS 4.0 definitions and
source, and it will happen to work with both 16-bit
and 32-bit OS/2.

So I would suggest that this (MSDOS 4.0) should be
adopted as the official standard to use instead of
POSIX or Windows or OS/2 (I don't like any of them
except the OS/2 function names), and provide existing
use (MSDOS 4.0, OS/2 1.x, Windows up to 2000, OS/2 2.0+).

The existing header file - doscalls.h - could be used too.

And the nature of the beast means that a thin wrapper
could be written to translate that into Win32 equivalents
so that everything from Win 95 to Win 11 is also covered.

Any thoughts?

BFN. Paul.

> Using just this disk - ie just the raw DOS 4.0 files -
> I could theoretically write a program to convert
> LF to CRLF etc rather than just copying an unzip
> program across. I already have a crlffix - I could
> copy that across instead and likely compile it.
>
> Not sure what a sensible goal here would be.

It may not qualify as "sensible", but I am formulating
a goal now.

There was this Kon-Tiki Expedition on a balsa wood raft:

https://en.wikipedia.org/wiki/Kon-Tiki_expedition

https://www.google.com.ph/books/edition/Kon_Tiki/x...ric+raft%22&pg=PT35&printsec=frontcover

“Radio!” I said, horrified. “What the hell do we want with that? It’s
out of place on a prehistoric raft.”

“Not at all—it’s a safety precaution which won’t have any effect on
your theory so long as we don’t send out any SOS for help. And we shall
need the radio to send out weather observations and other reports. But
it’ll be no use for us to receive gale warnings because there are no reports
for that part of the ocean, and, even if there were, what good would they
be to us on a raft?”


So now, using just the DOS 4.0 distribution, and any public domain
source code I can obtain, how far can I get on an XT with 640k in
preparation for jumping to an AT or 386? And perhaps only using
things that I have documented on the disk.

So long as I don't exceed the memory available on the machine
in those days, it doesn't matter if I am instead running under
qemu.

In fact, PdAndro is coming into view (we should find out soon
if it is accepted on the Google Play Store), so I might be able
to write my own 8086 emulator and do it on a Smartphone.

I already have the beginnings of an 8086 emulator.

I've done a lot of cleanup and I am doing a new build at
the moment.

BFN. Paul.

> I've done a lot of cleanup and I am doing a new build at
> the moment.

That took a lot longer than I expected because I was
trying to get a complete build to go through without
intervention, given that the lack of CRs is causing
masm to randomly fail.

Note that it isn't necessary for it to happen in a
single run, but I thought it would be nice. But most
runs fail.

Anyway, at http://pdos.org if you search for 4.0 you
will find a new, cleaner distribution. Direct link
is still the same.

BFN. Paul.

> Anyway, at http://pdos.org if you search for 4.0 you
> will find a new, cleaner distribution.

And also a snapshot of the UC8086 distribution so that
a slew of source code is available should that be useful.

That includes micro-emacs, so I need to see if I can get
that operational, so that I can write tools to clean up
the source code of MSDOS 4.0 - using MSDOS 4.0 itself.

BFN. Paul.

> The CRLF hit harder for some reason, so the files like
> chdir.asm will choke with either a hang or spurious errors.
>
> Using just this disk - ie just the raw DOS 4.0 files -
> I could theoretically write a program to convert
> LF to CRLF etc rather than just copying an unzip
> program across. I already have a crlffix - I could
> copy that across instead and likely compile it.

Both of these [2021] goofy kludges are very simple hacks to workaround a flaw
in [then] current versions of A72 assembler (e.g. 1.03a) where it won't read
properly from *nix-only text files (LF-only ending).

N.B. public domain, free for any use.

crlffile.asm

org 100h ; public domain, nenies proprajho

DOS equ 21h
ARGC equ 80h
ARGV equ 82h
CR equ 13
LF equ 10
OPENFILEREAD equ 3D00h
CREATEFILE equ 3Ch
CLOSEFILE equ 3Eh

Komenco:
  mov si,ARGC
  cmp byte[si+1],CR
  jz Fino
  xor bh,bh
  mov bl,byte[si]
  mov byte[si+bx+1],bh
OpenFiles:
  mov ax,OPENFILEREAD
  mov dx,ARGV
  int DOS
  jc Fino
  mov [inhandle],ax
  mov ah,CREATEFILE
  xor cx,cx
  mov dx,outfile
  int DOS
  jc Fino
  mov [outhandle],ax
  call main
CloseFiles:
  mov ah,CLOSEFILE
  mov bx,[inhandle]
  int DOS
  mov ah,CLOSEFILE
  mov bx,[outhandle]
  int DOS
  dec byte[err]
Fino:
  mov ax,[err]
  int DOS

main:
  call readbyte
  test ax,ax
  jz main_ret
  cmp byte[buf],LF
  jnz main_write
  mov dl,byte[buf]
  push dx
  mov byte[buf],CR
  call writebyte
  pop dx
  mov byte[buf],dl
main_write:
  call writebyte
  jmp short main
main_ret:
  ret

readbyte:
  mov ah,3Fh
  mov bx,[inhandle]
  mov cx,1
  mov dx,buf
  int DOS
readbyte_ret:
  ret

writebyte:
  mov ah,40h
  mov bx,[outhandle]
  mov cx,1
  mov dx,buf
  int DOS
  ret

outfile db 'CRLF.OUT',0
err db 1,4Ch
inhandle dw 0
outhandle dw 0
buf db 0

; EOF


crlf.asm

org 100h ; public domain, nenies proprajho

DOS equ 21h
CR equ 13
LF equ 10
EXIT equ 4C00h
ISKEYPRESS equ 0Bh
READ equ 8
WRITE equ 2

Komenco:
  mov ah,ISKEYPRESS
  int DOS
  test al,al
  jz Fino
  mov ah,READ
  int DOS
  cmp al,LF
  jnz WriteIt
AddCR:
  push ax
  mov dl,CR
  mov ah,WRITE
  int DOS
  pop ax
WriteIt:
  mov dl,al
  mov ah,WRITE
  int DOS
  jmp short Komenco
Fino:
  mov ax,EXIT
  int DOS

; EOF


When I heard about this, my jaw hit the floor. It's actually ALMOST close enough to my targets to completely obviate it. (And almost all of it Just Worked®™© to roll it the first time. I had trouble with select, xmaem and xma2ems but I don't give a damn about those.) 2.11 was a long way to go but this is 4.0 - outside the kernel and shell there wasn't really that much evolution up until 6.2.

I've started to try to get it migrated off the Microsoft tools, but they did use a lot of MASM-specific stuff that WASM doesn't grok. My goal is to have an ironed-out source tree I can cross-build (no need for DOSBOX) or roll native.

> I've started to try to get it migrated off the Microsoft tools, but they
> did use a lot of MASM-specific stuff that WASM doesn't grok.

Whatever the purpose, JWASM will solve at least some of the problems.

> My goal is to
> have an ironed-out source tree I can cross-build (no need for DOSBOX) or
> roll native.

Try building it in a Windows XP (or any other 32bit Windows) "DosBox".
It's MUCH more productive and produces the exact same results.

> > I've started to try to get it migrated off the Microsoft tools, but they
> > did use a lot of MASM-specific stuff that WASM doesn't grok.
>
> Whatever the purpose, JWASM will solve at least some of the problems.
>
> > My goal is to
> > have an ironed-out source tree I can cross-build (no need for DOSBOX) or
> > roll native.
>
> Try building it in a Windows XP (or any other 32bit Windows) "DosBox".
> It's MUCH more productive and produces the exact same results.

Even under Linux, DOSBOX has no problem rolling it (I had most of the system rolled before a lot of people realized what it was). Just wanted to remove that element from the mix.

I am pleasantly surprised by the quality of the MS-DOS 4.0 code documentation. Way beyond how the EDR-DOS source is documented. I am wondering if this is a result of IBMs influence to the DOS development, or if this was MS standard even at this time.

> And SmartDrv is included as well!!!

This has been available forever in the Windows/286 OEM Binary Adaptation Kit, in almost exactly the same version.

> > And SmartDrv is included as well!!!
>
> This has been available forever in the Windows/286 OEM Binary Adaptation
> Kit, in almost exactly the same version.

Under MIT License?

---
Forum admin