MS-DOS v1.25 and v2.0 Source Code now on github

This repo contains the original source-code and compiled binaries for MS-DOS 1.25 and MS-DOS 2.0.

These are the same files originally shared at the Computer History Museum on March 25th 2014 and are being (re)published in this repo to make them easier to find, reference-to in external writing and works, and to allow exploration and experimentation for those interested in early PC Operating Systems.


All files within this repo are released under the MIT (OSI) License as per the LICENSE file stored in the root of this repo.

At first I just thought it was simply just another mirror of the original source that had been released that had some incredible restrictions.

Original license:
To access this material, you must agree to the terms of the license displayed here, which permits only non-commercial use and does not give you the right to license it to third parties by posting copies elsewhere on the web.

However the restrictions have been lifted, and MS-DOS 1.25 & 2.0 are now available under a MIT license.

So this is actually very awesome!

You can download it here:

33 thoughts on “MS-DOS v1.25 and v2.0 Source Code now on github

    • It seems like 1.25 doesn’t have a lot that FreeDOS doesn’t already have. 2.0 is missing several key parts to make it bootable and even fdisk is missing.

      It seems like the most valuable thing from this would be the insight of how to craft usable programs in a now unimaginably tiny (we’re talking 64kb) 8088 space.

      • 2.0, or more correctly 2.11, isn’t really missing that much to be bootable. MSDOS.SYS and COMMAND.COM are complete here.

        The reason those things are missing is because they’re not actually part of MS-DOS. These things – IO.SYS, portions of FORMAT.COM, FDISK and the like – these were provided by the licensees. For example, in PC DOS 2.1, these are supplied by IBM; in Tandy MS-DOS 2.11, they’re supplied by Tandy, and in Compaq MS-DOS 2.12, they’re supplied by Compaq.

        • Can you build MSDOS.sys? I got to build by either using the older version 2.0 fragments & from bitsavers Seattle Computer Products, although it’s lacking the international stuff, so I just stubbed them out…

          trying to build the files for doslink response file just gives me so many missing bits. STRIN.ASM is clearly damaged, missing it’s header & footer…

          • I *thought* I’d built msdos.sys, at least – it’s possible I’m misremembering.

            I definitely did build, using MASM 3.0 and the TLINK from Turbo C++ 1.01. I have a zip of that somewhere, and I have a code tree where I was trying to gradually upgrade it to the functionality of version 3.3.

          • I’ve been using the IBM version of MASM 2, as the included Microsoft MASM 1.1 seems to have all kinds of memory issues running in a high memory system.

            now that it’s MIT we don’t have to hide anymore….

            if you got it to build that’d be great! Maybe the hint is the TLINK, Ive been using the MS Link 2.0 thing and although it’s enough to build things like debug,edlin & it certainly has issues building dos.

          • Well, I cleaned up my build folder for the straight 2.11 COMMAND.COM, and just slapped it in my webspace. (Mainly by taking the ASM files and slapping the license statement on the top, then deleting masm and tlink.)


            I do remember fighting with some parts of the DOS sources. Maybe with some kind of unified effort a complete buildable system can be developed, and then a decision made how to deal with the IBM parts?

            I wonder if we can convince them to open up GW-BASIC… xD Maybe that’ll be a little too much to ask.


            this has what should be an io.sys like thing. I can’t do anything with the IMD files, and I don’ tknow if SIMH can even run this…. but it’d be a starting point. SYSIMES.OBJ & SYSINIT.OBJ are supplied to MS as objects.. which would be in the MIT archive. Just as FORMAT.OBJ & FORMES.OBJ are supplied as part of

            I’ll have to take yet another stab at this with a different linker to see how it behaves.

            My total mess is here.

          • A file I downloaded somewhere with a folder called “Microsoft MS-DOS 2.00 [SCP OEM] (8 inch) [SCP Tarbell S-100]” has the 1.IMD named “dos20_1_ms-422.imd”, and has the files from the various disks extracted into folders. Nothing useful on that volume, just binaries, but there is source on the second disk. Think it’s just for the Seattle IO.SYS, though.

          • MS-DOS version 2.0 Series #86, Tarbell

            Yeah that’s what is in that Directory.

            Is there a scp Tarbell emulator? I forget what the 8086 coprocessor card is called, SIMH can run it along with 86-DOS.

          • Get on the FreeDOS list if you care about combining effort. (Or BTTR Software or similar forum.)

            A decent (small) COMMAND.COM would be cool for various reasons, but there’s already been a fair bit of effort recently (by Bart) to clean up FreeCOM. Try his latest pre-release (pre6) if you haven’t already, he needs more testers. (Hey, I can’t do everything!)

            GW-BASIC? I’d rather have QBASIC, but either would be cool. (Heck, even MASM v1 in Pascal.)

            Honestly, we’re already spoiled with FreeDOS (et al), so I don’t know why we pine for old MS stuff. I really don’t anticipate that they’ll unearth much else. It’s almost strange how motivated people are with MS (but unmotivated with FD). Nostalgia, I guess.

          • I’ve been on the FreeDOS list for years. 😉

            As I said there, the fact that I’ve been pretty deep in the MS-DOS codebase is why I stopped developing, although I’ve mainly provided advice.

            To be fair, what I really would like to see opened up is QuickBasic Extended 7.1. 😉

          • The memory issues are because the Pascal compiler’s RTL had bugs. (Apparently MASM v1 was written in it.) Maybe try JWasm (MASM clone) instead?


            BTW, there are a million different 16-bit linkers, so you don’t have to stick exclusively to MS LINK or TLINK. I’d suggest JWlink or ValX or Alink or WarpLink (or …).

          • It’s why I like MS-DOS Player, as I can reduce available memory, environment and set the version as needed.

            I’m tying to stick with the vintage tools as I’m in no mood to try to go into whatever the syntax drift will be with other assemblers. Even MASM 5.1 has issues as many ‘new’ reserved words are in use in the code, and again I didn’t want to fight something like that, but rather try to get it to work as is before making radical changes.

            It’s part of the hell I went through with porting Quake II to MS-DOS, it’s far more efficient to start with a possible ‘known good’ then to go off and change so many things at the start that you’ll be in so much trouble trying to figure out what broke where and why.

          • I found out what amount of MS-DOS 2.11 I’d actually built while trying to find another copy of the sources. Unfortunately, MSDOS.SYS wasn’t part of it (guess I had given up due to the link issues).

            I had built chkdsk, command, debug, diskcopy, edlin, exe2bin, fc, find, format, more, print, recover, sort and sys. I think that’s a pretty big chunk.

          • Yes I have a chunk of MS-DOS.sys built, but it is missing parts. Just as one of the ASM files is incomplete, and all the high level text Io is missing. I think the link script is for 2.00 which is why the macros are in place for a 2.00 build, lacking internationalisation support.

            It’ll take a bit of filling in the missing bits to get it complete.

            On the other side of the chain, I’m wondering why any DPMI stuff couldn’t run with DOS 2…

          • At least it’s possible to test msdos.sys with the bootstrap and from PC DOS 2.10 (something I’ve done for years).

            DOS 3.0 was the first to fill in the data used to construct argv[0] in C applications, meaning that applications which need this information cannot run under 2.x. (I have just confirmed this; I thought it was 3.1.)

  1. Could the use of backslash for path separators be IBMs fault?:

    5. Documentation. Features of 2.0 are documented on this disk.

    The user manual contains some significant errors. Most of these are
    due to last minute changes to achieve a greater degree of compatibility
    with IBM’s implementation of MS-DOS (PC DOS). This includes the use
    of “\” instead of “/” as the path separator, and “/” instead of “-”
    as the switch character.

    • That’s an OAK, or known as the OEM adaption kit. I’m pretty sure those included the known working versions of MASM + Linker etc in there. However I don’t know if that OAK has been ported to anything so you may have to write the platform code.

    • As has been mentioned, that’s just the OEM Adaptation Kit. (Actually, isn’t MS-DOS 2.11’s release also just the OAK?)

      The only source there is io.sys, format, sys, and a couple other commands. Not even the BDOS (msdos.sys) or COMMAND.COM have full source in that tree.

    • Rolled it with MASM 5.10A, LINK 5.31.009 from Visual Basic for MS-DOS, and a self-rolled EXE2BIN from the DOS 2 tree. Spits a few warnings, but it rolls, and works with the PC DOS 2.0 bootloader and DOS BIOS.

      I wonder what differences in COMMAND.COM 2.11 vs. the prior 2.02 prevent it from being used with a 2.00 kernel.

      • I have built it on freedos using the masm and link in masm 5.1 and the exe2bin that comes with freedos 1.2.

        I was able to replace the on a pc-dos 2.10 disk with the msdos.sys file I compiled, boot it successfully and run several of the programs on the disk except for basic and basica. Pretty soon it stopped recognizing the floppy it booted from, though.

        This is on 86box.

        • John Elliott uploaded a second folder yesterday containing the 2.11 kernel. I rolled it with both 5.1A and 4.0, using the actual EXE2BIN from the source distribution, and either the LINK from the DOS 3.3 OAK or the one from Visual Basic for MS-DOS. I’ve also rolled COMMAND.COM. Plug in the PC DOS 2.1 IBMBIO.COM and bootloader – and yes, it works. I’ve never stresstested the thing but it absolutely works.

Leave a Reply