Regarding the release of the MS-DOS 4.00 source code, Michal Necasek makes an excellent point about how just dumping the code in git is a terrible and destructive way to release older source code.
It’s terrific that the source code for DOS 4.00/4.01 was released! But don’t expect to build the source code mutilated by git without problems.
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.
↫ Michal Necasek at OS/2 Museum
The problems caused by dumping the code in git are quite real. Timestamps are not preserved, and the conversion to UTF-8 is deeply destructive, turning some parts of the code to literal gibberish. It’s a bit of a mess, and the people responsible for these release should be more careful and considerate.
This entire thing sound very ungrateful.
First of all, after checking the source files, and comparing it to some other similar efforts, they seem to be extremely clean, and self explanatory. The build files are there, and many people report success. (I no longer have access to these tools).
And line endings? Really?
https://docs.github.com/en/get-started/getting-started-with-git/configuring-git-to-handle-line-endings
UTF-8 as well…
When files are stored as text in GIT, it is very easy to get the format you want out. If your UNIX system defaults to LF, don’t blame git for it. You can always switch to CRLF, and of course to US-ASCII.
> This entire thing sound very ungrateful.
I agree. Imagine you have to run a company and you take some extra effort and responsibility and do someone a favor only to get slapped into your face like that. I would think twice before I ever bothered again.
Agree about the tone. Michal can be very direct.
As far as I can tell, what happened is somebody made a serious attempt to make this code approachable and easy to work with. They had an environment working in their working copy, committed, and pushed. Unfortunately if the working copy is ASCII and git defaults to interpreting it as UTF8, it will start interpreting extended chars as leading chars in multibyte sequences, and here the result is manged. Importantly, it is mangled at the time of commit, so it cannot be automatically recovered later. The end result is code that doesn’t compile.
It’s hard to be upset at the person preparing the code, who clearly made every attempt to make this process simple. Aside from these characters, this repo is shockingly straightforward to build – far easier than any of the other “historic” releases we’ve had before.
Personally I’m a little more disappointed that this appears to an early copy of a buggy release. It does not incorporate later bugfixes. There’s a monster update rollup (PD0255.EXE) that applies to kernels compiled from this code and ends up rewriting half of it. Without some of these fixes, it should be considered as code to demonstrate why DOS 4’s reputation was do bad.
The article is quite right, it is easier and better just to release a ZIP/RAR/etc. of the files, there less chance of things being mangled. Clearly Microsoft only did this method of release because they own the site involved, not because it would be the most beneficial for the users.
I agree with @sukru
I have gone through this: https://docs.github.com/en/get-started/getting-started-with-git/configuring-gitmulesoft course-to-handle-line-endings
Hope this will help you.