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

I have revisited this, and have been able to get the multitasking version to work.

And I now have an http://pdos.org/dos4mt.zip with a readme2.txt explaining how the VHD was created.

And now I would like to try running an NE executable.

I took makefile.wcd and changed "Form dos" to "Form windows"
to get an NE executable created.

But DOS4MT still runs the DOS stub.

Sniffing about here:

http://www.retroarchive.org/swag/WIN-OS2/0025.PAS.html

I tried various zaps:

zap pdptest.exe 0xa6 0x03

zap pdptest.exe 0x70 0x4d
zap pdptest.exe 0x71 0x5a

So I have something like this:

D:\devel\pdos\pdpclib>hexdump pdptest.exe 0 500
000000 4D5A8000 01000000 04000000 FFFF0000 MZ..............
000010 B8000000 00000000 40000000 00000000 ........@.......
000020 00000000 00000000 00000000 00000000 ................
000030 00000000 00000000 00000000 70000000 ............p...
000040 0E1FBA0E 00B409CD 21B8014C CD215468 ........!..L.!Th
000050 69732069 73206120 57696E64 6F777320 is is a Windows
000060 65786563 75746162 6C650D0A 24000000 executable..$...
000070 4D5A0501 5C000200 00000000 02020200 MZ..\...........
000080 00000020 00000100 00000200 02000000 ... ............
000090 0F004000 50005000 5B005B00 CE000000 ..@.P.P.[.[.....
0000A0 00000100 00000300 00000000 00000003 ................
0000B0 6F002877 400D2877 103CF609 410D0071 o.(w@.(w.<..A..q
0000C0 07706470 74657374 00000000 00000B70 .pdptest.......p
0000D0 64707465 73742E65 78650000 00009090 dptest.exe......
0000E0 9090068B C4B104D3 E88CD303 C383C002 ................
0000F0 8CDB2BC3 8BD8B44A CD21BAFF FF8EDA8C ..+....J.!......


And other variations:

D:\>fc /b pdptest.exe pdptest2.exe
Comparing files pdptest.exe and PDPTEST2.EXE
000000A6: 03 02

D:\>fc /b pdptest.exe pdptest3.exe
Comparing files pdptest.exe and PDPTEST3.EXE
00000070: 4E 4D
00000071: 45 5A


But this DOS4MT isn't accepting any of them, and just runs the stub.

Anyone know what's happening? ie how do I create an NE executable that is acceptable to DOS4MT?

I have a theory that this is a very old version of DOS4MT, and NE support was added later, and that version is not available so that's why it isn't working.

Thanks. Paul.

Note that I also see this:

https://hg.pushbx.org/ecm/msdos4/

A lot of activity. Is there a group or groups already working on enhancing MSDOS 4.0?

Maybe they can add NE support in a compatible way.

The above seems to have switched from masm to nasm though. I would prefer to stay compatible with Microsoft tools.

> Note that I also see this:
>
> https://hg.pushbx.org/ecm/msdos4/
>
> A lot of activity. Is there a group or groups already working on enhancing
> MSDOS 4.0?

I'm the only one it appears. (pushbx.org is my website.)

> Maybe they can add NE support in a compatible way.

You need to differentiate this MS-DOS v4.00/v4.01 from the "European"/Ozzie/Multitasking MS-DOS v4. We do not have the sources for Multitasking MS-DOS. This repo (lMS-DOS, ie the lDOS fork of MS-DOS) is based on the regular (non-multitasking) MS-DOS v4.01, for which we do have most of the sources. (Most because tools like the message preparation program are missing sources.)

> The above seems to have switched from masm to nasm though. I would prefer
> to stay compatible with Microsoft tools.

Yes, I'm porting things to NASM and WarpLink step by step. The kernel and sharer are already ported, two files of the format program are likewise. (The kernel includes both the msbio and the msdos modules, albeit they're now linked together and the separation between them has been eroded. They're bundled with lDOS's iniload, lkernpl, optionally inicomp for compression, and lDOS instsect.)

NASM is free software with sources, unlike the MASM that ships with the 2024 April MS-DOS v4 release. So therefore I think NASM is better. Likewise for WarpLink and x2b2 (exe2bin replacement).

---
l

> > Maybe they can add NE support in a compatible way.
>
> You need to differentiate this MS-DOS v4.00/v4.01 from the
> "European"/Ozzie/Multitasking MS-DOS v4. We do not have the sources for
> Multitasking MS-DOS.

Which is why I said "add" support - because NE support
is not already in this version.

> > The above seems to have switched from masm to nasm though. I would
> prefer
> > to stay compatible with Microsoft tools.
>
> Yes, I'm porting things to NASM and WarpLink step by step.

> NASM is free software with sources,

So is jwasm. And as86. If you're porting the code anyway,
why not to something that will still work on masm?

> unlike the MASM that ships with the
> 2024 April MS-DOS v4 release. So therefore I think NASM is better.

I personally don't want to involved in a non-standard
language.

But if I'm just a user then I don't really care. I just
need NE support to work.

> > > Maybe they can add NE support in a compatible way.
> >
> > You need to differentiate this MS-DOS v4.00/v4.01 from the
> > "European"/Ozzie/Multitasking MS-DOS v4. We do not have the sources for
> > Multitasking MS-DOS.
>
> Which is why I said "add" support - because NE support
> is not already in this version.

I don't see what the point is. You could as well add "NE support" to the FreeDOS kernel.

> > > The above seems to have switched from masm to nasm though. I would
> > prefer
> > > to stay compatible with Microsoft tools.
> >
> > Yes, I'm porting things to NASM and WarpLink step by step.
>
> > NASM is free software with sources,
>
> So is jwasm.

JWasm is encumbered by the Sybase license. It's OSI "open source" but not FSF "free software". The OpenWatcom relicensing effort isn't fulfilled yet, and even if it were JWasm contributors would also need to agree: https://github.com/Baron-von-Riedesel/JWasm/issues/20

> And as86. If you're porting the code anyway,
> why not to something that will still work on masm?

as86 appears to be incompatible to MASM. For instance, immediate operands need a # prefix.

> > unlike the MASM that ships with the
> > 2024 April MS-DOS v4 release. So therefore I think NASM is better.
>
> I personally don't want to involved in a non-standard
> language.

I don't see how NASM is "non-standard", unless you want to define a "standard" as just whatever dialect has the single largest existing code base or whatever tool has been the single most popular choice at one point in time.

> But if I'm just a user then I don't really care. I just
> need NE support to work.

I don't see a need for it, nor do I know how exactly this support should work. So I won't add it.

---
l

> > Which is why I said "add" support - because NE support
> > is not already in this version.
>
> I don't see what the point is. You could as well add "NE support" to the
> FreeDOS kernel.

FreeDOS is more restrictive than MIT license.

> > > > The above seems to have switched from masm to nasm though. I would
> > > prefer
> > > > to stay compatible with Microsoft tools.
> > >
> > > Yes, I'm porting things to NASM and WarpLink step by step.
> >
> > > NASM is free software with sources,
> >
> > So is jwasm.
>
> JWasm is encumbered by the Sybase license. It's OSI "open source" but not
> FSF "free software".

I don't subscribe to the FSF definition of "free".

So basically this is a license dispute.

> The OpenWatcom relicensing effort isn't fulfilled yet,
> and even if it were JWasm contributors would also need to agree:
> https://github.com/Baron-von-Riedesel/JWasm/issues/20

Which is why all of these things suck and I don't
want to get involved.

> > And as86. If you're porting the code anyway,
> > why not to something that will still work on masm?
>
> as86 appears to be incompatible to
> MASM. For instance, immediate operands need a # prefix.

Name clash.

as86 as shipped on the PDOS/386 disk.

https://github.com/robertapengelly/as86

It's a subset of masm and completely public domain.

This is what I see as the future - enhancing this
public domain assembler so that it gets closer to
be able to do things like assemble MSDOS 4.0 source code.

> > > unlike the MASM that ships with the
> > > 2024 April MS-DOS v4 release. So therefore I think NASM is better.
> >
> > I personally don't want to involved in a non-standard
> > language.
>
> I don't see how NASM is "non-standard", unless you want to define a
> "standard" as just whatever dialect has the single largest existing code
> base or whatever tool has been the single most popular choice at one point
> in time.

Yes, Microsoft has always set the standard in this
area. Actually, I consider whatever works on masm,
wasm, jwasm and as86 to be "standard".

> > But if I'm just a user then I don't really care. I just
> > need NE support to work.
>
> I don't see a need for it,

It provides a way for AHINCR and AHSHIFT to be specified.
MZ can't do that unless you provide an extension one way
or another. And if you're going to do that anyway, may
as well do NE. Or at least, perhaps it should be an option.

> nor do I know how exactly this support should work.

Exactly what I want to know too. That's why I'm asking
about the MT version. Even binary should be sufficient
to find out what NE does.

> Name clash.
>
> as86 as shipped on the PDOS/386 disk.
>
> https://github.com/robertapengelly/as86

I see a Makefile.wcd there, is it using OpenWatcom's wmake?
It does (allegedly) produce a large model DOS .EXE.

Wmake does support "*wcl" for longer cmdlines (indirectly via env vars). It also has "rm" built-in and some other nifty features.

(Speaking of "standard", why force Gmake on BSD? They have their own make.)

> It's a subset of masm and completely public domain.
>
> This is what I see as the future - enhancing this
> public domain assembler so that it gets closer to
> be able to do things like assemble MSDOS 4.0 source code.

I see your point, but MASM has a lot of heavy features. I don't think even TASM fully supported them all.

In particular, one thing that MASM and TASM supported was memory references without square brackets, e.g. "MOV MyWordVar,13" instead of "MOV [MyWordVar],13". This is somewhat ambiguous (albeit more concise) and not supported by almost anyone else (over a dozen different assemblers), so not just NASM.

Macros, structs, preprocessor, outputs, and other weird features. For just a "simple" assembler program, MASM is overkill.

Yes, it was popular, but no, it's not standard (or even commonly supported).

> > > > unlike the MASM that ships with the
> > > > 2024 April MS-DOS v4 release. So therefore I think NASM is better.

They ship MASM v5, right?

> > > I personally don't want to involved in a non-standard
> > > language.
> >
> > I don't see how NASM is "non-standard", unless you want to define a
> > "standard" as just whatever dialect has the single largest existing code
> > base or whatever tool has been the single most popular choice at one
> > point in time.

NASM was originally strictly two-pass, so some things they did without. (There are even one-pass assemblers with even more restrictions.)

> Yes, Microsoft has always set the standard in this area.

MS does not always support standards. Their BASICs were never "standard". However, I think C# did get a few standards, and some things (e.g. PowerShell, which even runs on Linux) are written in it.

I would not hold their work up as a good example of standard anything (nor Linux although some few people may try). Some people are more interested in feature creep and competitive advantages rather than portability to unsupported, no longer sold OSes or cpus. (Modern software seems to primarily care about x64 and AArch64.)

> Actually, I consider whatever works on masm, wasm, jwasm and as86
> to be "standard".

Just from (admittedly limited) personal experience, very few IA-16 assemblers agree on anything. It's not like C or Pascal (with actual standards) although even there, differences exist. (MASM was originally written in Pascal but switched to their C compiler for mixed memory model speedups. Of course, MASM also stopped being DOS-hosted in 1995, stopped being sold as a separate product later, and removed all 16-bit instruction support in 2010, IIRC. OS/2 support is also long gone.)

Standards exist, even unofficial ones, but you more or less have to cope with your own workarounds. (It's feasible to write a Sed script to quickly adapt syntax between assemblers for specific bits of code.)

"Standard"? You don't strictly need it. You can roll your own syntax. Admittedly weird (and annoying when everybody is incompatible) but totally valid if you can prove it's better somehow (ahem, TASM's Ideal mode).

> > Name clash.
> >
> > as86 as shipped on the PDOS/386 disk.
> >
> > https://github.com/robertapengelly/as86
>
> I see a Makefile.wcd there, is it using OpenWatcom's wmake?

I use pdmake, but I just tried wmake, and it worked too:

wmake -h -e -a -ms -f makefile.wcd

(although I didn't rebuild pdpclib so I got a link error)

> It does (allegedly) produce a large model DOS .EXE.
>
> Wmake does support "*wcl" for longer cmdlines (indirectly via env vars). It
> also has "rm" built-in and some other nifty features.
>
> (Speaking of "standard", why force Gmake on BSD? They have their own
> make.)

So once again, I consider nmake to be standard, and
you should use a subset of that.

> > It's a subset of masm and completely public domain.
> >
> > This is what I see as the future - enhancing this
> > public domain assembler so that it gets closer to
> > be able to do things like assemble MSDOS 4.0 source code.
>
> I see your point, but MASM has a lot of heavy features. I don't think even
> TASM fully supported them all.

Sure. So use a subset of masm, so that you can use
a competitor to Microsoft.

While the professionals can still use the commercially
supported assembler.

> In particular, one thing that MASM and TASM supported was memory references
> without square brackets, e.g. "MOV MyWordVar,13" instead of "MOV
> [MyWordVar],13". This is somewhat ambiguous (albeit more concise) and not
> supported by almost anyone else (over a dozen different assemblers), so not
> just NASM.

So don't write code like that.

> Macros, structs, preprocessor, outputs, and other weird features. For just
> a "simple" assembler program, MASM is overkill.

So don't use those features.

In a professional setting, they may use those features
(that's likely why the features exist in the first place).
And then professionals will be stuck with Microsoft.
They probably don't mind being stuck with Microsoft,
and don't even consider it to be "stuck".

They likely consider it to be "stuck" if they use syntax
supported only by nasm, so any issue they get they have
to pay full unlimited western contract rates to someone
on the internet to fix it. Instead of simply switching to
a commercially-supported competitor.

> Yes, it was popular, but no, it's not standard (or even commonly
> supported).

A subset is commonly supported.

> > > > > unlike the MASM that ships with the
> > > > > 2024 April MS-DOS v4 release. So therefore I think NASM is better.
>
> They ship MASM v5, right?

They ship 5.1, yes.

D:\devel\DOS4\TOOLS>masm
Microsoft (R) Macro Assembler Version 5.10
Copyright (C) Microsoft Corp 1981, 1988. All rights reserved.


> > Yes, Microsoft has always set the standard in this area.
>
> MS does not always support standards. Their BASICs were never "standard".
> However, I think C# did get a few standards, and some things (e.g.
> PowerShell, which even runs on Linux) are written in it.

I didn't say MS set the standard for BASIC. There is an
ISO committee for that, I believe.

Are you saying that MS BASIC doesn't even supported the
first version of the ISO standard?

> I would not hold their work up as a good example of standard anything (nor

I am not aware of any part of the ISO/IEC 9899:1990
standard that Microsoft violates in any of their
compilers since Microsoft C 6.0. Perhaps you could
show me an example?

> Linux although some few people may try). Some people are more interested in
> feature creep and competitive advantages rather than portability to
> unsupported, no longer sold OSes or cpus. (Modern software seems to
> primarily care about x64 and AArch64.)

Sure - different people have different goals. If
someone wants to jump on the FSF bandwagon then
that limits their choices to certain software.

They live in the free world - go for it!

I'm just saying I personally don't want to get
involved because I have a different goal.

In the osdev community there are heaps of people
writing OSes - and they all write the exact same
Unix clone. And they all abandon it after a short
time. So we have 50 million mini Unix clones available.

Noone at all sat down for 30+ years to write something
that was a mini Microsoft clone.

Well. Just one person. With a different goal to
everyone else.

> > Actually, I consider whatever works on masm, wasm, jwasm and as86
> > to be "standard".

I should have included "tasm", which is still
available commercially and supported.

> Just from (admittedly limited) personal experience, very few IA-16
> assemblers agree on anything.

They all have incompatible extensions in the hope that
you will become beholden to their product.

I don't want to become beholden to any of them, so I
use a subset that works on all.

> It's not like C or Pascal (with actual
> standards) although even there, differences exist. (MASM was originally
> written in Pascal but switched to their C compiler for mixed memory model
> speedups. Of course, MASM also stopped being DOS-hosted in 1995, stopped
> being sold as a separate product later, and removed all 16-bit instruction
> support in 2010, IIRC. OS/2 support is also long gone.)

Visual Studio 2022 with x64 to x86 command line:

C:\devel\pdos\pdpclib>ml -DPOLLUTE -c -nologo -DMSC -D__SZ4__ -Dmemodel=huge -omf dosstart.asm
Assembling: dosstart.asm

C:\devel\pdos\pdpclib>dir dosstart.*
Volume in drive C has no label.
Volume Serial Number is 2E16-A311

Directory of C:\devel\pdos\pdpclib

2025-04-29 07:52 PM 6,955 dosstart.asm
2025-04-30 05:30 AM 464 dosstart.obj


I didn't test it beyond that. I use an older version.

> Standards exist, even unofficial ones, but you more or less have to cope
> with your own workarounds.

I'm already doing that. And I've been doing that
since around 1989-ish - using tasm and trying to
write my assembler code so that it works on masm
as well. Although I rarely wrote in assembler. I
instead wrote in C90 and used Turbo C 2.0.

> (It's feasible to write a Sed script to quickly
> adapt syntax between assemblers for specific bits of code.)

So - convert all the code to standard masm/tasm/as86
syntax before shipping if it's so easy, so that people
don't need to learn a non-standard language.

> "Standard"? You don't strictly need it.

Correct. You only really need food, shelter and clothing.

> You can roll your own syntax.

I can remember a line from during the Iraq war.

A US spokesman was showing Al Jazeera TV to a group
of Iraqis and pointing out all the lies.

And an Iraqi asked a question - "Are you saying we
shouldn't watch Al Jazeera?".

His reply was "It's my job to tell you what you should
or shouldn't watch. It's a free country. Watch whatever
you want."

> Admittedly weird (and annoying when everybody is incompatible) but totally
> valid if you can prove it's better somehow (ahem, TASM's Ideal mode).

Absolutely. Depending on your goals, you may well be
happy to use TASM's ideal mode and tie yourself down
to one commercially supported assembler.

Or use nasm and tie yourself down to one assembler that
is supported by yourself or whoever you can afford to
pay to wade through thousands of lines of copyrighted
(by someone else) code to fix their code.

Some people still watch Al Jazeera too. Admittedly I'm
one of those though. I don't think they lie on the
English version and give me more coverage of what I'm
interested in (Syria). (or was interested in, anyway -
right at the moment I am interested in NE executables
and am doing a hexdump of an OS/2 1.0 executable so
that I can answer Robert's questions so that he can
add support to slink - which again I consider to be
the future of 16-bit - I'm using it for a reason - but
yes, different people have different goals).

> Are you saying that MS BASIC doesn't even supported the
> first version of the ISO standard?

I don't think they ever did (or intended to), no.

> > I would not hold their work up as a good example of standard anything
>
> I am not aware of any part of the ISO/IEC 9899:1990
> standard that Microsoft violates in any of their
> compilers since Microsoft C 6.0. Perhaps you could
> show me an example?

C is different for them (but not by much). For a long time they ignored C99 in lieu of C++.

> > > Actually, I consider whatever works on masm, wasm, jwasm and as86
> > > to be "standard".
>
> I should have included "tasm", which is still
> available commercially and supported.

It's not supported in the sense of modern features (64-bit) or being actively maintained. I think Wikipedia implies it hasn't been updated since 2002. At least my copy of TASM32 5.3 is dated 2000 (but I got it in 2007). They may bundle it with their C++ Builder, not sure, but it's not "supported", AFAIK.

JWasm is quite a bit better than Wasm.

> > Are you saying that MS BASIC doesn't even supported the
> > first version of the ISO standard?
>
> I don't think they ever did (or intended to), no.

Well that would be a reason to not use BASIC then -
people are unwilling or unable to support the
standard.

> > > I would not hold their work up as a good example of standard anything
> >
> > I am not aware of any part of the ISO/IEC 9899:1990
> > standard that Microsoft violates in any of their
> > compilers since Microsoft C 6.0. Perhaps you could
> > show me an example?
>
> C is different for them (but not by much). For a long time they ignored C99
> in lieu of C++.

I said C90, not C99. PDPCLIB doesn't support any of
C99 at all.

Another reason to not use C99 at all.

C90 is the lingua franca of the world of computers.

You can write an entire OS in nothing other than C90.
Portable anywhere.

(assumes the existence of a suitable BIOS though, or
a layer above that to turn unsuitable BIOSes into
suitable BIOSes, hence why I use the term "pseudobios")

> > > > Actually, I consider whatever works on masm, wasm, jwasm and as86
> > > > to be "standard".
> >
> > I should have included "tasm", which is still
> > available commercially and supported.
>
> It's not supported in the sense of modern features (64-bit) or being

The discussion at hand is about MSDOS 4.0 source code.
64-bit is not a consideration.

> actively maintained.

Perhaps no-one has reported any bugs in it, because
it is working fine? You're not asking for change for
the sake of change, are you?

> I think Wikipedia implies it hasn't been updated since
> 2002.

All bugs that affected anyone ironed out by 2002,
rock solid stable for 23 years - not one bug that
anyone can point to. Sounds like a winner to me.

> At least my copy of TASM32 5.3 is dated 2000 (but I got it in 2007).
> They may bundle it with their C++ Builder, not sure, but it's not
> "supported", AFAIK.

Depends on your definition of "support" I guess. If
you don't have any bugs to report, and the vendor
thus doesn't fix any reported bugs, that may meet
your definition of "unsupported".

And perhaps that is the exact rub. Modern software
is so full of bugs and people put out new beta
releases that replace one set of bugs that may not
affect you with a new set of bugs that may, and
there is a constant scramble to get the latest bug
fixes for your Android phone or whatever because
everything is permanently broken.

No-one is bothering to sit down and get something
stable. Except the owners of tasm, apparently.

I like this guy's take on the situation:

https://www.quora.com/Why-did-you-leave-a-job-as-a-software-engineer/answer/Jeff-Sturm-2

> JWasm is quite a bit better than Wasm.

Sure. Which is why if you're going to port the MSDOS 4.0
source code - ie remove Microsoft features that don't
exist elsewhere - jwasm could have been the new target.
Or the (apparent) gold standard bug-free tasm. Or a
subset of all 3.

BFN. Paul.

> > It's a subset of masm and completely public domain.
> >
> > This is what I see as the future - enhancing this
> > public domain assembler so that it gets closer to
> > be able to do things like assemble MSDOS 4.0 source code.
>
> I see your point, but MASM has a lot of heavy features. I don't think even
> TASM fully supported them all.
>
> In particular, one thing that MASM and TASM supported was memory references
> without square brackets, e.g. "MOV MyWordVar,13" instead of "MOV
> [MyWordVar],13". This is somewhat ambiguous (albeit more concise) and not
> supported by almost anyone else (over a dozen different assemblers), so not
> just NASM.

It's fairly complicated to determine whether a source operand is a memory access or an immediate due to this. In my conversion script I check for bare register names, plain numbers, "equates" (with expansions that are plain numbers), cl, string literals, or whether the operand contains the offset keyword.

Here's a changeset that describes the scriptlet to use to run fixmem.pl, and the diff of running it on one of lMS-DOS's format source text files.

This still doesn't cover every change needed. In this case, I ran a perl scriptlet to replace the double-dollar label prefixes that are probably written by the SALUT preprocessor. (NASM doesn't like double dollar prefixes.) One of the port labels had to be moved, the result still didn't assemble with NASM due to using a segment override on the source operand of a memory-destination mov. Then it assembled.

Next I ran another perl scriptlet to replace some equates by %ixdefine directives, which was needed because psdata.mac expects these to be defines. The local copy of parse.nas had to drop an earlier identicalise nop that had been added while identicalising msbio.

After that I ran yet another perl scriptlet to replace all uses of segment overrides on operands with offset, which on recent NASM versions is allowed but makes it assemble this operand as a memory operand (if possible). MASM v5.10 appears to just ignore the segment override.

After this I verified that the file is identicalised using my ident86 tool. More on running that on the blog.

> Macros, structs, preprocessor, outputs, and other weird features. For just
> a "simple" assembler program, MASM is overkill.

NASM's preprocessor is fairly complicated as well.

> Yes, it was popular, but no, it's not standard (or even commonly
> supported).

NASM's development has been slow in the last years but I would still prefer that to using a closed source (if "free" under MIT license) MASM version.

> > > > > unlike the MASM that ships with the
> > > > > 2024 April MS-DOS v4 release. So therefore I think NASM is better.
>
> They ship MASM v5, right?

Yes, v5.10 to be precise. The MS-DOS v2 source tree ships v1.10 as well, which I used to use to build MSDebug, my MS-DOS Debug fork/recreation.

> > > > I personally don't want to involved in a non-standard
> > > > language.
> > >
> > > I don't see how NASM is "non-standard", unless you want to define a
> > > "standard" as just whatever dialect has the single largest existing
> code
> > > base or whatever tool has been the single most popular choice at one
> > > point in time.
>
> NASM was originally strictly two-pass, so some things they did without.
> (There are even one-pass assemblers with even more restrictions.)

NASM has been multi-pass for a long time now.

> Standards exist, even unofficial ones, but you more or less have to cope
> with your own workarounds. (It's feasible to write a Sed script to quickly
> adapt syntax between assemblers for specific bits of code.)

You can look at the full sources of fixmem.pl to see how much I already added to handle the MASM to NASM conversion.

> "Standard"? You don't strictly need it. You can roll your own syntax.
> Admittedly weird (and annoying when everybody is incompatible) but totally
> valid if you can prove it's better somehow (ahem, TASM's Ideal mode).

I don't recall much that uses Ideal mode. Maybe doslfn?

---
l

> > NASM was originally strictly two-pass, so some things they did without.
> > (There are even one-pass assemblers with even more restrictions.)
>
> NASM has been multi-pass for a long time now.

IIRC, Masm has become a one-pass assembler with version 6+ ( they mentioned that to explain why directives IF1 and IF2 have been removed ).

JWasm is "multi-pass", meaning that it continues to reassemble the source until there's no change in the segment lengths anymore - that's actually a pretty dump strategy...

So one may come to the conclusion that the number of passes is perhaps not really a sign of quality.

---
MS-DOS forever!

> So one may come to the conclusion that the number of passes is perhaps not
> really a sign of quality.

I think it should be pretty obvious that number of passes has _almost nothing_ to do with quality (however one would define "quality"). When assembling/compiling, the file(s) are read from top to bottom and sometimes something at the top of the file will refer to something later in the file, or even in a different file, and the assembler/compiler will not know what to do with it. The most obvious thing it may not know is the size (Byte, Word, DWord, QWord, Array, Structure, etc.) but there could be other things it may need to "guess" on the first pass. If it guesses wrong, things can get ugly (or at least non-optimal). The usual way around these things is to make "unnecessary" declarations (usually about size) for anything that is a forward reference, which makes the code more cumbersome to write since it includes a bunch of unneeded/duplicate syntax. In addition to sizes of data items, there are also issues related to sizes of JMPs (both conditional and non-conditional) and whether they are short or near (far jumps usually must be declared explicitly no matter what, at least in ASM).

However, the one good thing about making specific declarations is that it can provide a form of error checking -- if all the declarations for the same item don't match there may (or may not) be something wrong in the code. But, you can also sometimes use declarations to "override" the actual setting of something (like using a Word declaration to just refer to the lower half of a DWord item), so having them not match isn't necessarily an "error".

Anyway, the point is this all really has nothing to do with "quality" -- it has to do with how the assembler/compiler expects the code to be written and what "hoops" it wants the programmer to jump through to meet the expectations of the person/team that wrote the assembler/compiler.

I really don't see how a single-pass assembler/compiler could work as well as a multi-pass, at least when it comes to producing the most efficient (smallest size) output without requiring the code writer to jump through a bunch of "unnecessary" hoops.

> > > NASM was originally strictly two-pass, so some things they did
> without.
> > > (There are even one-pass assemblers with even more restrictions.)
> >
> > NASM has been multi-pass for a long time now.
>
> IIRC, Masm has become a one-pass assembler with version 6+ ( they mentioned
> that to explain why directives IF1 and IF2 have been removed ).

It also became a lot more powerful. When was the last 16-bit version? I'd have to check. Presumably around v5.

> JWasm is "multi-pass", meaning that it continues to reassemble the source
> until there's no change in the segment lengths anymore - that's actually a
> pretty dump strategy...
>
> So one may come to the conclusion that the number of passes is perhaps not
> really a sign of quality.

When massaging PSR Invaders (my favorite testing ground), it's nominally "MASM" syntax already (he used TASM 4.0). But old MASM 1.10 can't handle it unless fixed. Besides the nonsensical "40:' segment overrides that TASM ignores, JWasm can assemble it verbatim. But most other assemblers need brackets around memory references. My point is that adding brackets still requires 5 passes, but further adding explicit size overrides then only needs 2 passes. (OpenWatcom's WASM demands explicit size overrides.)

TASM was originally 1-pass only anyways, only adding /m# later. Usually one-pass is much faster (e.g. A86). MASM was considered quite slow in the old days.

> I think it should be pretty obvious that number of passes has _almost
> nothing_ to do with quality (however one would define "quality").

A86 is one-pass and much faster than MASM or TASM. Isn't A386 your favorite assembler?

> When assembling/compiling, the file(s) are read from top to bottom and sometimes
> something at the top of the file will refer to something later in the file,
> or even in a different file, and the assembler/compiler will not know what
> to do with it. The most obvious thing it may not know is the size (Byte,
> Word, DWord, QWord, Array, Structure, etc.) but there could be other things
> it may need to "guess" on the first pass. If it guesses wrong, things can
> get ugly (or at least non-optimal). The usual way around these things is
> to make "unnecessary" declarations (usually about size) for anything that
> is a forward reference, which makes the code more cumbersome to write since
> it includes a bunch of unneeded/duplicate syntax.

I believe the traditional way around that problem is to "JMP Start" and then define your data so that the assembler knows where it is.

> In addition to sizes of data items, there are also issues related to sizes
> of JMPs (both conditional and non-conditional) and whether they are short
> or near

People always got choked up about short conditional jumps, but it's not THAT bad. Besides, MASM "ljmp", TASM "jumps", and even NASM "-O3" with "cpu 8086" can do a workaround for such out-of-range jumps. (The main worry is not to have a 386+ near jump in 8086 code. Some assemblers do not warn about that.)

In reality, saving a few bytes for jumps hardly makes a difference, so it's not worth worrying about (although only a few assemblers lack that optimization). A86 actually can only handle backwards conditional jumps automatically. Again, it's in the interest of speed (which was more obvious in pre-Pentium days).

> I really don't see how a single-pass assembler/compiler could work as well
> as a multi-pass, at least when it comes to producing the most efficient
> (smallest size) output without requiring the code writer to jump through a
> bunch of "unnecessary" hoops.

I had several strategies, just out of curiosity and completeness, to 100% match optimized outputs:

1). Use Sed or AWK to automate fixing from the listing .LST file to optimize. This still takes a few extra "passes", but it works. (I was sneaky and able to bundle the .sed or .awk inside the .BAT itself. It's not as complex as it sounds.) For example, A86 4.05 (forward short jumps) and NASM 0.97 (short jumps, explicit byte operands).

2). Some assemblers allow symbolic equates, so you can (in one "pass") read the entire .ASM and find all data declarations and put then in an .INC include file, e.g. "s_myWordVar equ word" so that "s_myWordVar[myWordVar]" works. For example, OpenWatcom WASM or A86 or NASM.

3). If that doesn't work, you can always do a second "pass", with Sed or whatever else, to explicitly change all instances of "s_myWordVar" to "word".