That is pretty cool - I wonder if 'ol Bill wrote any code in those versions. If MS was anything like the place I work at currently, then 90% of it would be cut-and-pasted code from V1.0.

I also wonder why 6.2 wouldn't be open sourced yet - is someone still making a buck off something that old? Maybe so.

badmojo wrote:

That is pretty cool - I wonder if 'ol Bill wrote any code in those versions. If MS was anything like the place I work at currently, then 90% of it would be cut-and-pasted code from V1.0.

I also wonder why 6.2 wouldn't be open sourced yet - is someone still making a buck off something that old? Maybe so.

Might even be that they are not the sole rights holders for parts of the software. E.g. doublespace etc.

However, DOS 3.3 and onwards would be more interesting, since it is necessary for lots of old software.

Something to note is it's all written in assembly (ASM) low-level code. One wonders at what version of DOS they began to use higher-level compilers for things...

badmojo wrote:

That is pretty cool - I wonder if 'ol Bill wrote any code in those versions.

Well, DONKEY.BAS is in the archive, so there's that. 😜

From an email posted in the repo, it looks like Tim Paterson himself provided the source package for 1.25 in 2013. AFAIK the 1.x branch was still largely SCP/Paterson's product with some badge engineering. 2.0 should have more substantial changes from MS.

SW-SSG wrote:

Something to note is it's all written in assembly (ASM) low-level code. One wonders at what version of DOS they began to use higher-level compilers for things...

I wouldn't be surprised if at least the kernel / command.com were all assembly all the way up to 6.2. There were still real benefits to doing so until relatively recently.

Somebody on a Hackernews thread I was reading pointed out the FAT12 filesystem is like 53 lines of assembly. Talk about tight coding...

Wonder if any CPM code can still be found in there...
#can of worms opened...#

SW-SSG wrote:

Something to note is it's all written in assembly (ASM) low-level code. One wonders at what version of DOS they began to use higher-level compilers for things...

It would be something to note if it wasn't all written in assembly... considering that every bit of memory and performance was important on the range of systems that DOS ran on. People wouldn't have liked even 10K or so of additional C runtime code (or equivalent) eating into their precious conventional memory (nor the trade-offs of ensuring that it doesn't).

CarlHopkinsUK wrote:

Wonder if any CPM code can still be found in there...
#can of worms opened...#

I bet Tim Paterson sometimes feels like Buzz Aldrin felt before he punched out that little "moon hoax truther" shit in the now-famous video. #Can of whoopass opened#. 😁

VileRancour wrote:

SW-SSG wrote:

Something to note is it's all written in assembly (ASM) low-level code. One wonders at what version of DOS they began to use higher-level compilers for things...

It would be something to note if it wasn't all written in assembly... considering that every bit of memory and performance was important on the range of systems that DOS ran on. People wouldn't have liked even 10K or so of additional C runtime code (or equivalent) eating into their precious conventional memory (nor the trade-offs of ensuring that it doesn't).

The released sources of version 2.0 also include some Pascal code. Someone has opened an issue about .pas files being located in the bin folder instead of in the source folder: https://github.com/Microsoft/MS-DOS/issues/13

digger wrote:

The released sources of version 2.0 also include some Pascal code. Someone has opened an issue about .pas files being located in the bin folder instead of in the source folder: https://github.com/Microsoft/MS-DOS/issues/13

Yep, but those 2 files look like they're related to some helper utilities for developers (possibly part of the OEM toolkit?). IF any of that code was part of the OS, that'd be interesting. 😁

...Annnnnd, here's the Windows NT4 version of File Manager (not Explorer) open-sourced under the same MIT license. There's a "reference"/oldschool copy available but you can also grab the maintainer's updated Win10 & 64-bit compatible port. Yes, this is the official repo from Microsoft. Somebody was having fun. 😜

I am so tempted to try and port this to Mac OS/X, because Finder sucks balls.

VileRancour wrote:

It would be something to note if it wasn't all written in assembly... considering that every bit of memory and performance was important on the range of systems that DOS ran on. People wouldn't have liked even 10K or so of additional C runtime code (or equivalent) eating into their precious conventional memory (nor the trade-offs of ensuring that it doesn't).

It may be true for kernel, drivers and TSRs, but not for utilities. I mean, there is no point in writing FORMAT, FDISK, MODE and other utilities in assembler because they won't be eating up your memory all time (even with 256k you have enough memory). But I guess that the cumulative effect of those bigger files would mean that they couldn't fit in a floppy disk (shared libraries weren't commonplace until Windows)... and HDDs were rare at that time.

Zup wrote:

It may be true for kernel, drivers and TSRs, but not for utilities. I mean, there is no point in writing FORMAT, FDISK, MODE and other utilities in assembler because they won't be eating up your memory all time (even with 256k you have enough memory). But I guess that the cumulative effect of those bigger files would mean that they couldn't fit in a floppy disk (shared libraries weren't commonplace until Windows)... and HDDs were rare at that time.

The speed advantage of pure assembly code on systems from when these were written was huge. All these utilities had to run well on a 4.77MHz IBM PC and at least make it look competitive against systems that loaded their OS from ROM. Your average 486-based "retro gaming rig" is probably a thousand times faster than the hardware DOS 1.x/2.0 was intended to run on.

Not only that, assembling & debugging on these machines is multiple orders of magnitude faster than compiling, and forget about having an IDE to work with. You couldn't exactly fire up Turbo C for DOS to write DOS. (When did the first C compiler for DOS even appear?)

xjas wrote:

The speed advantage of pure assembly code on systems from when these were written was huge. All these utilities had to run well on a 4.77MHz IBM PC and at least make it look competitive against systems that loaded their OS from ROM. Your average 486-based "retro gaming rig" is probably a thousand times faster than the hardware DOS 1.x/2.0 was intended to run on.

Not only that, assembling & debugging on these machines is multiple orders of magnitude faster than compiling, and forget about having an IDE to work with. You couldn't exactly fire up Turbo C for DOS to write DOS. (When did the first C compiler for DOS even appear?)

There's also the fact that most of those utilities do need lots of low-level hardware access, which would make them actually simpler to write in assembly. There were quite a few C compilers very early on (in 1982-1983 you had at least C86, DeSmet C, and Lattice C which eventually became Microsoft C) but I don't know if any of them supported things like inline assembly - didn't that come with Turbo C?

Some of the later utilities with a more elaborate UI such as DOSSHELL, MSD, etc. may have been written in a higher-level language at least partially, I guess.

Not quite on-topic, but PC-MOS/386 was uploaded to GitHub, too.
Yes, I know. It's not MS-DOS, but a professional Operating System.
Still, I truely believe someone could still learn from it a few things. 😀

VileRancour wrote:

digger wrote:

The released sources of version 2.0 also include some Pascal code. Someone has opened an issue about .pas files being located in the bin folder instead of in the source folder: https://github.com/Microsoft/MS-DOS/issues/13

Yep, but those 2 files look like they're related to some helper utilities for developers (possibly part of the OEM toolkit?). IF any of that code was part of the OS, that'd be interesting. 😁

Turns out you were right. See this response by the maintainer: https://github.com/Microsoft/MS-DOS/issues/13 … mment-426100055

badmojo wrote on 2018-09-30, 09:24:

That is pretty cool - I wonder if 'ol Bill wrote any code in those versions. If MS was anything like the place I work at currently, then 90% of it would be cut-and-pasted code from V1.0.

I also wonder why 6.2 wouldn't be open sourced yet - is someone still making a buck off something that old? Maybe so.

I know this is a pretty old thread, but according to the program manager, this is due to third-party licensing restrictions: https://github.com/microsoft/MS-DOS/issues/42 … mment-542437019