Ms-dos 6 Source Code

[Mack Mosely]

Theabove problem was most likely caused by taking a source line using codepage 437 characters and badly converting them to UTF-8. That made the source line too long, past the circa 512 byte line length limit of MASM.

The timestamp destruction makes it harder to pin down what the source code actually is. The DOS 4.0 release was very confused because IBM first released PC DOS 4.0 in June 1988 (files dated 06/17/1988), but soon followed with a quiet update (files dated 08/03/1988) where the disks were labeled 4.01 but the software still reported itself as 4.00.

As a historic footnote, BAK stood for Binary Adaptation Kit. MS-DOS OEMs would receive the BAK to adapt to their hardware. However, most OEMs did not receive the full source code, only the code to components that likely needed modification, such as IO.SYS.

Historic source code should be released simply as an archive of files, ZIP or tar or 7z or whatever, with all timestamps preserved and every single byte kept the way it was. Git is simply not a suitable tool for this.

Besides the printer spooler, you did not need stacks until you loaded a network layer, in which case, they added the config.sys stacks command in PC-DOS 3.1, Remember that 4.0 is derived from DOS 2.0.

As for the small stack it may be of note that the stack may underflow, and this may or may not cause problems. Due to the near jump and lack of alignment directives, the msload stack is actually on an odd address. On a 386 pushing to offset 0FFFFh in Real 86 Mode (where limit is 0FFFFh) would fault I believe. Not sure about the 286.

And which tool would that be? Surely not ZIP, which not only does not support time zones, but lets you re-make new copies of the ZIP file with different timestamps, or even different contents, with little chance of being detected.

UTC considerations were rather irrelevant with DOS 1 or 2 or even any later DOS. Before the RTC, the time and date was whatever entered. No guarantee that would be even close to accurate. RTCs frequently drifted considerably from exact time. The filestamp will always be incorrect. It took the introduction of networking to force time to be somewhat consistent across systems.

The changes to clock availability was one of the hidden alterations to computer usage. Line clocks were an expensive add-on in the early 70s but practically free by the time of the IBM PC which is why the PC includes one. RTCs went from several hundred dollars to only about $20 in just a few years.

In March 2014, Microsoft released the source code to MS-DOS 1.25 and 2.0 via the Computer History Museum. The announcement also contains a brief history of how MS-DOS came to be for those new to the subject, and ends with many links to related articles and resources for those interested in learning more.

Ten years ago, Microsoft released the source for MS-DOS 1.25 and 2.0 to the Computer History Museum, and then later republished them for reference purposes. This code holds an important place in history and is a fascinating read of an operating system that was written entirely in 8086 assembly code nearly 45 years ago.

Thank you to Ray Ozzie, Starfrost, Jeff Sponaugle, Larry Osterman, Mark Zbikowski, our friends at the IBM OSPO, as well as the makers of such digital archeology software including, but not limited to Greaseweazle, Fluxengine, Aaru Data Preservation Suite, and the HxC Floppy Emulator. Above all, thank you to the original authors of this code, some of whom still work at Microsoft and IBM today!

The release includes the MS-DOS 4.00 source code, binaries, PDFs of the original documentation, and disk images. Microsoft has also pledged to continue exploring its archives and may update the release if additional relevant materials are discovered.

The story behind MS-DOS 4.00 is a complex and fascinating one. In the 1980s, Microsoft partnered with IBM for portions of the DOS code but also created a separate branch called Multitasking DOS, which never saw widespread release.

For those interested in exploring this historic software, Microsoft has confirmed successful runs on an original IBM PC XT, a newer Pentium system, and within the open source PCem and 86box emulators.

Looking to revamp your digital transformation strategy? Learn more about Digital Transformation Week taking place in Amsterdam, California, and London. The comprehensive event is co-located with AI & Big Data Expo, Cyber Security & Cloud Expo, and other leading events.

Developer Tech offers the latest app developer news and strategy. We cover topics, including coding, monetisation, billing, marketing and design, within the app development industry. We aim to help developers by providing top-class practical content across many issues.

As you know Doom source code as released in 1997 was not for original DOS version, but rather was Linux version cleaned up by Bernd Kreimeier. During clean up, code specific for DOS version was stripped out. Another big change was reorganizing header files, specifically doomdef.h, p_local.h and r_local.h were split to smaller header files. This is where Heretic sources comes in handy. Raven released their code as is, without any sort of clean up. Specifically it has majority of Doom's DOS specific code and header files organization is very close to Doom's original form.

The goal of this project is to combine both these sources and get codebase that is close to the Doom's original codebase as possible. Actually I had this idea for a pretty long time and had previous attempts in the form of PCDoom and PCDoom-v2. This time I decided to start mostly from Heretic sources, gradually reverting Raven's code changes by comparing it to Linux Doom sources. I targeted id Anthology Final Doom EXE as it was closest to linuxdoom sources. Eventually I got compiling EXE, but as expected it had lots of differences to original EXE files. Then I gradually fixed all the differences and got EXE that identical to original EXE by behaviours. Once I covered both revisions of Final Doom, NY00123 volunteered and also covered a lot more Doom revisions down to prototype v1.666. This also includes Chex Quest.

Meanwhile I decided to try to do the same for Strife executable using restored Doom code. As Strife source code was never released, I had to rely on reverse engineering of original EXE file. After finishing initial reversing resulted EXE had some differences to original EXE. Eventually after lots of trial and error and not without some help from NY00123 we eventually got EXE that identical to original EXE (up to usual garbage data between string literals and differences due to __LINE__ macro).

TL;DR These repositories recreate different revisions of Doom and Strife codebase. Compiled EXE files are identical to original EXE in term of behaviours. In total both repositories cover 15 different revisions of Doom, Strife and Chex Quest.

The goal of this project is to combine both these sources and get codebase that is close to the Doom's original codebase as possible. Actually I had this idea for a pretty long time and had previous attempts in the form of PCDoom and PCDoom-v2.

This time I decided to start mostly from Heretic sources, gradually reverting Raven's code changes by comparing it to Linux Doom sources. I targeted id Anthology Final Doom EXE as it was closest to linuxdoom sources. Eventually I got compiling EXE, but as expected it had lots of differences to original EXE files. Then I gradually fixed all the differences and got EXE that identical to original EXE by behaviours. Once I covered both revisions of Final Doom, NY00123 volunteered and also covered a lot more Doom revisions down to prototype v1.666. This also includes Chex Quest.

Very impressive showing considering not just one, but several versions were recreated. And based on Anthology gurantees the latest version, so its a good one to have as a reference point.

I feel efforts like this are incredibly understated, but they are among the most important contribtions to Doom.

Paging @Quasar here considering a similar reverse engineering effort was undertaken for Strife VE. Perhaps he or someone else on the team may find this useful, or perhaps they have additional pointers?

Also, what's the plan with these executables? You say that they together from a complete GPLv2 codebase. Could those be used in situations that now still rely on propetairy Doom2.exe, such as FreeDoom?

If that's the case, how can we differentiate between Doom2.exe and its GPL-equivalent? DoomNew has a differing name and so does PCDoom, but how would those revisions be called to differentiate them from the original executables?

This is very impressive indeed, I'm assuming this needs a rather recent version of DJGPP to compile? Since I tried on my DOS development box which has a DJGPP from 1998 and that died at your makefiles.

3a8082e126