DOS ain't dead

As I specified in https://github.com/stsp/dosemu2/issues/680 I went and tried building the MS-DOS 2.00 source's DEBUG. (MS-DOS 2.00 was recently released under the MIT license, see https://blogs.msdn.microsoft.com/commandline/2018/09/28/re-open-sourcing-ms-dos-1-25-and-2-0/ )

Without LOADFIX, the included MASM 1.10 (albeit technically "free software" now, this is given as a binary only) errors out with "Out Of Memory" on some files. Eric suggested it may be due to using memory in the first 64 KiB of the LMA. With FreeCOM's LOADFIX either MASM and/or my batch file crash or hang, though. As an alternative, I loaded up my lDebug, entered TSR mode ("tsr"), and insured with "dm" that the memory behind the debugger is above 64 KiB. Then I run with "g", which causes the debugged process to terminate and returns to the shell, now with lDebug resident.

After that a few more problems occurred, but I solved all of them and made scripts (one for building in DOS, which I run in dosemu2, and the other for packing the archive in bash on Linux) to build and package DEBUG version 2.30.

I uploaded my repository (based on Microsoft's) to https://bitbucket.org/ecm/msdos2 and also put an archive with the binary (and object and listing files) to https://bitbucket.org/ecm/msdos2/downloads/ (Make sure to use debug.com though; debug.exe is only included here as an intermediate object file and doesn't work correctly when run directly.)

---
l

> I went and tried building the MS-DOS 2.00 source's DEBUG.

Okay.

> MASM 1.10 (albeit technically "free software" now, this is given as a binary only)

Did you try with later MASMs or MASM compatibles (e.g. JWasm)?

BTW, I had thought I heard that the first MASM was written in (MS?) Pascal by Marc McDonald.

Just to quote here:

> Tim Patterson, the original creator of DOS and the famous DEBUG.COM,
> wrote an 8086 assembler (ASM) to assemble 86-DOS, the predecessor to
> MS-DOS. Here is what he said:
>
>> MASM was written in Pascal by Marc McDonald (Microsoft employee #1,
>> after Bill & Paul). Microsoft had been doing all their development on
>> DEC computers, and the macro capability put in MASM was modeled after
>> DEC assemblers. Because MASM was such a large macro assembler, one of
>> the guys referred to it as "McDonald's big mac".
>>
>> MASM does not have lineage back to M80. It was written specifically
>> for the 8086 and attempted some level of compatibility with Intel's
>> 8086 assembler. I remember it was different from what I was used to.
>> When MS bought DOS from SCP I was at MS. After finishing up DOS 1.0, I
>> translated DOS from SCP's assembler to MASM, and I needed Marc to
>> explain some of the syntax to me.

...

> After that a few more problems occurred, but I solved all of them and made
> scripts (one for building in DOS, which I run in dosemu2, and the other for
> packing the archive in bash on Linux) to build and package DEBUG version
> 2.30.

Did you only try building atop DOSEMU2? What DOS did you use, FreeDOS? Maybe these old tools have some unknown dependency on running atop actual MS-DOS 2.00 itself. (Dunno, try PCEM?) See here about running QuickPascal atop DR-DOS. And there was some weird bit about A20, EXEPACK, Pascal runtime, I dunno, see here.

Another article says this:

> Given that the compiler was designed to run on the original IBM PC
> and only required 128K memory, why is it failing on a system with
> a lot more? The real reason is of course not that there isn’t enough
> memory, the problem is that there’s too much. Let’s see how that works
> (or rather doesn’t work) exactly.
>
> IBM Pascal 1.0 suffers from a problem that is common to a number of
> products built with the Pascal compiler, specifically programs using
> the Pascal run-time startup code. That notably includes early versions
> of MASM as well as the Pascal compiler itself.

So that's fun.

> I uploaded my repository (based on Microsoft's) to
> https://bitbucket.org/ecm/msdos2 and also put an archive with the binary
> (and object and listing files) to
> https://bitbucket.org/ecm/msdos2/downloads/ (Make sure to use debug.com
> though; debug.exe is only included here as an intermediate object file and
> doesn't work correctly when run directly.)

Please don't take this the wrong way, I know it's not your fault. It's just a minor nitpick.

But it seems very sloppy and almost inappropriate to put "binary only" files on Github (and/or BitBucket). I know that's somewhat unavoidable, but it blurs the lines. "bin/" shouldn't have .TXT, .DOC, .PAS, or .OBJ files! "source/" shouldn't have .TXT (maybe), linker scripts, .EXE, .HLP, or .OVL files!

EDIT: Typos, added one more quoted paragraph.

> > MASM 1.10 (albeit technically "free software" now, this is given as a
> binary only)
>
> Did you try with later MASMs or MASM compatibles (e.g. JWasm)?

No and yes. JWASM seems to be too new, there are macros in the source that are keywords to JWASM (I think "invoke" was one of those).

> > After that a few more problems occurred, but I solved all of them and
> made
> > scripts (one for building in DOS, which I run in dosemu2, and the other
> for
> > packing the archive in bash on Linux) to build and package DEBUG version
> > 2.30.
>
> Did you only try building atop DOSEMU2? What DOS did you use, FreeDOS?

Yes, and I used FreeDOS SVN / build 2042, "compiled Sep 22 2017", along with FreeCOM "0.84-pre2 XMS_Swap" (this I think is the one included in the FreeDOS tarball for dosemu).

> Maybe these old tools have some unknown dependency on running atop actual
> MS-DOS 2.00 itself. (Dunno, try PCEM?) See
> here
> about running QuickPascal atop DR-DOS. And there was some weird bit about
> A20, EXEPACK, Pascal runtime, I dunno, see
> here.
>
> Another
> article says
> this:
>
> > Given that the compiler was designed to run on the original IBM PC
> > and only required 128K memory, why is it failing on a system with
> > a lot more? The real reason is of course not that there isn’t enough
> > memory, the problem is that there’s too much. Let’s see how that works
> > (or rather doesn’t work) exactly.
> >
> > IBM Pascal 1.0 suffers from a problem that is common to a number of
> > products built with the Pascal compiler, specifically programs using
> > the Pascal run-time startup code. That notably includes early versions
> > of MASM as well as the Pascal compiler itself.
>
> So that's fun.

Yeah, that seems like it might be the problem I'm running into. Oddly enough, when loading lDebug to stay resident, there are 569 KiB left for an application, which seems like it may still trigger the bugs described there. (Though it's less than 512 KiB + 64 KiB ( = 576 KiB).)


-tsr
Patched PSP at 11B6, now resident.
-dm
PSP: 11B6
02B4 4D 0008 000D    208 B SD
02C2 4D 02DA 0016    352 B LDEBUG
02D9 4D 02DA 0EDB   59 KiB LDEBUG
11B5 5A 11B6 8E49  569 KiB DEBUGGEE
9FFF 4D 0008 2300  140 KiB SC
C300 4D 0008 011B    4 KiB SD
C41C 4D 0000 0006     96 B
C423 4D C424 00BC    2 KiB COMMAND
C4E0 4D 0000 1B1E  108 KiB
DFFF 4D 0008 1000   64 KiB SC
F000 4D 0000 032D   12 KiB
F32E 4D 0000 0090    2 KiB
F3BF 5A C424 0040   1024 B COMMAND
-g
C:>ver /r
 
FreeCom version 0.84-pre2 XMS_Swap [Aug 28 2006 00:29:00]
DOS version 7.10
FreeDOS kernel - SVN (build 2042 OEM:0xfd) [compiled Sep 22 2017]
C:>


> > I uploaded my repository (based on Microsoft's) to
> > https://bitbucket.org/ecm/msdos2 and also put an archive with the binary
> > (and object and listing files) to
> > https://bitbucket.org/ecm/msdos2/downloads/ (Make sure to use debug.com
> > though; debug.exe is only included here as an intermediate object file
> and
> > doesn't work correctly when run directly.)
>
> Please don't take this the wrong way, I know it's not your fault. It's just
> a minor nitpick.
>
> But it seems very sloppy and almost inappropriate to put "binary only"
> files on Github (and/or BitBucket). I know that's somewhat unavoidable, but
> it blurs the lines. "bin/" shouldn't have .TXT, .DOC, .PAS, or .OBJ files!
> "source/" shouldn't have .TXT (maybe), linker scripts, .EXE, .HLP, or .OVL
> files!
>
> EDIT: Typos, added one more quoted paragraph.

The binaries in my bitbucket repo proper are only those already included in the repo by Microsoft. I uploaded the archive with my DEBUG build to the /downloads/ page, which as far as I understand it is exactly for this type of release. (Note that github doesn't have such a page.)

In the archive, there is no "source/" directory, it's all flat in the archive's root. So the only sin I committed according to your nitpick is that I put executable links and scripts into the source directory in the repo. If it bothers you too much, you're free to fork from the repo

---
l

> > Did you try with later MASMs or MASM compatibles (e.g. JWasm)?
>
> No and yes. JWASM seems to be too new, there are macros in the source that
> are keywords to JWASM (I think "invoke" was one of those).

Try "option nokeyword:<invoke>" (at top of file or via include -Fi). That seems to work correctly.

> > > Given that the compiler was designed to run on the original IBM PC
> > > and only required 128K memory, why is it failing on a system with
> > > a lot more? The real reason is of course not that there isn’t enough
> > > memory, the problem is that there’s too much. Let’s see how that works
> > > (or rather doesn’t work) exactly.
> > >
> > > IBM Pascal 1.0 suffers from a problem that is common to a number of
> > > products built with the Pascal compiler, specifically programs using
> > > the Pascal run-time startup code. That notably includes early versions
> > > of MASM as well as the Pascal compiler itself.
>
> Yeah, that seems like it might be the problem I'm running into.

Good to know.

> The binaries in my bitbucket repo proper are only those already included in
> the repo by Microsoft.

I know, but it's still less than ideal. I don't use Github, so I'm a bit surprised they don't forbid binary blobs. Maybe I'm naive, I thought some (most?) people wanted reproducible builds and full sources for as much as possible. (Yeah, I know this is old and formerly proprietary. Maybe they honestly expect us DOS nerds to clean it up!)

> In the archive, there is no "source/" directory, it's all flat in the
> archive's root. So the only sin I committed according to your nitpick is
> that I put executable links and scripts into the source directory in the
> repo. If it bothers you too much, you're free to fork from the repo

It's not that I care. People are sloppy all the time about things like that. Please don't take this the wrong way, I know it's not crucial. (There are lots of little "problems" like that that need fixing in other projects.)

Generally speaking, for FOSS enthusiasts who always have to care about licensing (whether they like it or not), it's a bit uncomfortable to see binary blobs or non-reproducible files from mysterious origins. Also, using non-free tools (that aren't portable, old and limited, buggy) makes things harder. It's just lots of little problems that need to be avoided, if you care about organization and rebuilding or redistributing.

> As I specified in https://github.com/stsp/dosemu2/issues/680 I went and
> tried building the MS-DOS 2.00 source's DEBUG. (MS-DOS 2.00 was recently
> released under the MIT license, see
> https://blogs.msdn.microsoft.com/commandline/2018/09/28/re-open-sourcing-ms-dos-1-25-and-2-0/
> )
>
> Without LOADFIX, the included MASM 1.10 (albeit technically "free software"
> now, this is given as a binary only) errors out with "Out Of Memory" on
> some files. Eric suggested it may be due to using memory in the first 64
> KiB of the LMA. With FreeCOM's LOADFIX either MASM and/or my batch file
> crash or hang, though. As an alternative, I loaded up my lDebug, entered
> TSR mode ("tsr"), and insured with "dm" that the memory behind the debugger
> is above 64 KiB. Then I run with "g", which causes the debugged process to
> terminate and returns to the shell, now with lDebug resident.
>
> After that a few more problems occurred, but I solved all of them and made
> scripts (one for building in DOS, which I run in dosemu2, and the other for
> packing the archive in bash on Linux) to build and package DEBUG version
> 2.30.
>
> I uploaded my repository (based on Microsoft's) to
> https://bitbucket.org/ecm/msdos2 and also put an archive with the binary
> (and object and listing files) to
> https://bitbucket.org/ecm/msdos2/downloads/ (Make sure to use debug.com
> though; debug.exe is only included here as an intermediate object file and
> doesn't work correctly when run directly.)


I've been using MS-DOS player to stage stuff.. and building debug seemed straight forward..

call m DEBASM
call m DEBCOM1
call m DEBCOM2
call m DEBCONST
call m DEBDATA
call m DEBEQU
call m DEBMES
call m DEBUASM
call m DEBUG
..binlink @deblink
..binexe2bin debug.exe debug.com


C:projdos2v2.0source>type m.cmd
..binmasm %1 %1.obj %1.lst %1.crf


and it appears to run 'okay'

-u\proj\dos2\v2.0\source>..\bin\msdos debug command.com
0B61:0100 E9CD0B JMP 0CD0
0B61:0103 0000 ADD [BX+SI],AL
0B61:0105 0000 ADD [BX+SI],AL
0B61:0107 0000 ADD [BX+SI],AL
0B61:0109 0000 ADD [BX+SI],AL
0B61:010B 0000 ADD [BX+SI],AL
0B61:010D 0000 ADD [BX+SI],AL
0B61:010F 0000 ADD [BX+SI],AL
0B61:0111 0000 ADD [BX+SI],AL
0B61:0113 0000 ADD [BX+SI],AL
0B61:0115 0000 ADD [BX+SI],AL
0B61:0117 0000 ADD [BX+SI],AL
0B61:0119 0000 ADD [BX+SI],AL
0B61:011B 0000 ADD [BX+SI],AL
0B61:011D 0000 ADD [BX+SI],AL
0B61:011F 0000 ADD [BX+SI],AL
-g


TeleVideo Personal Computer DOS Vers. 2.11
(C) Copyright TeleVideo Systems, Inc. 1983
(C) Copyright Microsoft Corp. 1981, 1982, 1983

C:\PROJ\DOS2\V2.0\SOURCE>exit

Program terminated normally
-q


So yeah.... I'm using Microsoft MASM v3, and the included Microsoft Link 2. MS-DOS Player has flags like -e to reduce the environmnet, -m to restrict free memory enable or disable EMS/XMS and my favorite is to 'bind' an exe to run on Win32/Win64.

> I've been using MS-DOS player to stage stuff.. and building debug seemed
> straight forward..
>
> call m DEBASM
> call m DEBCOM1
> call m DEBCOM2
> call m DEBCONST
> call m DEBDATA
> call m DEBEQU

DEBEQU.ASM is actually an include file used by some of the other files. You needn't assemble it on its own, nor link it. But it doesn't do any harm to do that anyway.

> call m DEBMES
> call m DEBUASM
> call m DEBUG
> ..binlink @deblink
> ..binexe2bin debug.exe debug.com

http://www.bttr-software.de/forum/forum_entry.php?id=15115 Your backslashes are missing.

> C:projdos2v2.0source>type m.cmd
> ..binmasm %1 %1.obj %1.lst %1.crf
>
>
> and it appears to run 'okay'
>
> -uprojdos2v2.0source>..binmsdos debug command.com
> 0B61:0100 E9CD0B JMP 0CD0
> 0B61:0103 0000 ADD [BX+SI],AL
> 0B61:0105 0000 ADD [BX+SI],AL
> 0B61:0107 0000 ADD [BX+SI],AL
> 0B61:0109 0000 ADD [BX+SI],AL
> 0B61:010B 0000 ADD [BX+SI],AL
> 0B61:010D 0000 ADD [BX+SI],AL
> 0B61:010F 0000 ADD [BX+SI],AL
> 0B61:0111 0000 ADD [BX+SI],AL
> 0B61:0113 0000 ADD [BX+SI],AL
> 0B61:0115 0000 ADD [BX+SI],AL
> 0B61:0117 0000 ADD [BX+SI],AL
> 0B61:0119 0000 ADD [BX+SI],AL
> 0B61:011B 0000 ADD [BX+SI],AL
> 0B61:011D 0000 ADD [BX+SI],AL
> 0B61:011F 0000 ADD [BX+SI],AL
> -g
>
>
> TeleVideo Personal Computer DOS Vers. 2.11
> (C) Copyright TeleVideo Systems, Inc. 1983
> (C) Copyright Microsoft Corp. 1981, 1982, 1983
>
> C:PROJDOS2V2.0SOURCE>exit
>
> Program terminated normally
> -q
>
>
> So yeah.... I'm using Microsoft MASM v3, and the included Microsoft Link 2.
> MS-DOS Player has flags like -e to reduce the environmnet, -m to restrict
> free memory enable or disable EMS/XMS and my favorite is to 'bind' an exe
> to run on Win32/Win64.

https://emulationrealm.net/downloads/file/3251-ms-dos-player Link for the record, I didn't find any more definitive source. Seems to be under GPL v2-only.

---
l

> https://emulationrealm.net/downloads/file/3251-ms-dos-player Link for the
> record, I didn't find any more definitive source. Seems to be under GPL
> v2-only.

That's some link farm thing as search engines don't like non english sources...

http://takeda-toshiya.my.coocan.jp/msdos/index.html

Thats the actual home link.

And yes, it's GPL, after the MAME release of the 80386 core. It's capable of even running stuff like DJGPP / Go32 stuff. It's really great.

We already had a thread here for MS-DOS Player, did you not remember? Ah, well.

> And yes, it's GPL, after the MAME release of the 80386 core. It's capable
> of even running stuff like DJGPP / Go32 stuff. It's really great.

Yes, it's usefull, I tried it in Win10-x64 and it can run DJGPP programs. Would it be possible to write some TSR (I have no idea if there exist something like 32/64-bit native TSR for commandline) or extension for cmd.exe that ms-dos player will be launched automatically if a dos program would be run from cmd instead throwing an error message? I guess that such exception could be caught and instead running "x.exe" will be executed "msdos.exe x.exe". So then it would behave like old good NTVDM...

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