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".