Share this article

Latest news

With KB5043178 to Release Preview Channel, Microsoft advises Windows 11 users to plug in when the battery is low

Copilot in Outlook will generate personalized themes for you to customize the app

Microsoft will raise the price of its 365 Suite to include AI capabilities

Death Stranding Director’s Cut is now Xbox X|S at a huge discount

Outlook will let users create custom account icons so they can tell their accounts apart easier

Microsoft’s MS-DOS 4 open-source release stirred nostalgia but now is on fire due to flaws

As of now, you should wait for Microsoft to fix the issues

4 min. read

Published onApril 29, 2024

published onApril 29, 2024

Share this article

Read our disclosure page to find out how can you help Windows Report sustain the editorial teamRead more

Recently, Microsoftannounced the release of the source code for its iconic 1986 MS-DOS 4operating system and made it publicly available on GitHub for all to edit, study, or distribute.

Microsoft’s intended motive was tostir nostalgia and celebrate retro computing. However, little did they know it quickly turned into a controversy when developers and enthusiasts discovered critical flaws in the release.

A popular developer, Michal Necasek, who is known for OS/2 Museum, listed the issues he found in the release in a blog post,How Not To Release Historic Source Code.

He praised the decision to release the code but was not happy with its execution. He mainly lambasted the use of Git, a version control system, as it failed to preserve the timestamps and converted files to UTF-8 format.

In his blog post, he mentioned:

This source code will be an excellent reference of modern-ish DOS until Microsoft officially releases the long ago leaked MS-DOS 6.0 source code. The source code includes all required build tools, which makes building it (compared to many other source releases) extremely easy.

But pleasepleasedon’t mutilate historic source code by shoving it into (stupid) git.

First of all, git does not preserve timestamps, which causes irreversible damage. Knowing when a source file was last modified is valuable information.

Second of all, the people releasing the source code clearly thought, hey, it’s source code, let’s shove it into git, what could possibly go wrong.

The repercussions of these harmless actions were serious. Let us tell you how. In the MS-DOS era, the text files were usually encoded in ASCII or a similar coding scheme. However, Microsoft converted the source files to UTF-8, which encodes diverse Unicode characters, which is not compatible with MS-DOS environment.

And, as UTF-8 was not available in the times of MASM 5.10 and Microsoft C 5.1, old tools can’t deal with it; hence making them unreadable.

The byte length of MS-DOS 4’s MASM compiler was 512 bytes and by converting the files to UTF-8, they brought some files above that limit.

Some of the core system files managed to survive the conversion without any harm, however the conversion multilated others, resulting into inconsistencies between the original disk image files and released source code.

Necasek also mentioned that the source code released is not the MS-DOS 4.00 but a less-known version, 4.01, which wasn’t available directly, but was shipped to PC OEMs. The 4.01 version included important bug fixes.

Here is the proof, in the  SETENV.BAT file, there is a line mentioning just that:

In the end of the blog post, Necasek also suggested that the source code should be made available as an rchive of files, ZIP or similar format, with all the timestamps preserved and each byte kept the way it was. Also, he mentioned that Git is not the right tool for this.

Once the article went live, one of the MS-DOS 4 release co-developer Connor Hyde, also known as Starfrost commented that due to legal constraints inclusion of timestamps can’t happen.

He said:

The reason I cannot do timestamps is because data protection law mandates anonymisation of source files, at least that is the policy.

Note that this is far better than the CHM “preservation”.

To which Michal Necasek responded:

Do you know how the files survived? On floppies or on some hard disk backup? If on disks, then releasing the disk images would be terrific. But really anything that builds without having to be edited would be good.

There’s probably some way to fix the files in git as well? As I said they’re not plain ASCII (most are, but not all of them) and they must not be converted to UTF-8.

He further added,

Let’s hear it for idiotic corporate policies! Obviously not your fault.

But I have to point out that in the Multitasking DOS release, there are source files on a floppy image, with original timestamps…

Yes, the CHM release of DOS source code was… not ideal.

Then, there was a brief debate in the comments section, between Necasek and Starfrost about the source code and the way it was release, which concluded when they agreed on talking over email in private.

As of now, the developer community is waiting for resolution so that they can enjoy using the legendary operating system in its former glory.

Have you checked the source code  MS-DOS 4.00 or 4.01 until now? If so, share your experience with our readers in the comments section below.

More about the topics:microsoft

Srishti Sisodia

Windows Software Expert

Srishti Sisodia is an electronics engineer and writer with a passion for technology. She has extensive experience exploring the latest technological advancements and sharing her insights through informative blogs.

Her diverse interests bring a unique perspective to her work, and she approaches everything with commitment, enthusiasm, and a willingness to learn. That’s why she’s part of Windows Report’s Reviewers team, always willing to share the real-life experience with any software or hardware product. She’s also specialized in Azure, cloud computing, and AI.

User forum

0 messages

Sort by:LatestOldestMost Votes

Comment*

Name*

Email*

Commenting as.Not you?

Save information for future comments

Comment

Δ

Srishti Sisodia

Windows Software Expert

She is an electronics engineer and writer with a passion for technology. Srishti is specialized in Azure, cloud computing, and AI.