It is rare that I say this but, thanks MS! Arguably just as, if not more, important is the BASIC that they wrote. That was what they actually wanted to do. DOS just got them the contract with IBM. For decades MS was really a developer tools company with a side biz of writing operating systems and other misc software. They also open sourced that BASIC code too [1].
What's interesting is that Microsoft BASIC itself was derived from BASIC-PLUS which itself was derived from Dartmouth BASIC (which evolved into a structured programming language called SBASIC (Structured BASIC). But the popularity of Microsoft BASIC, actually halted the standardisation of SBASIC as an ANSI standard.
The Altair BASIC interpreter was developed by Microsoft founders Paul Allen and Bill Gates using a self-written Intel 8080 emulator running on a PDP-10 minicomputer.[1] The MS dialect is patterned on Digital Equipment Corporation's BASIC-PLUS on the PDP-10, which Gates had used in high school.
Dartmouth BASIC is the original version of the BASIC programming language. It was designed by two professors at Dartmouth College, John G. Kemeny and Thomas E. Kurtz. With the underlying Dartmouth Time-Sharing System (DTSS), it offered an interactive programming environment to all undergraduates as well as the larger university community.
Dartmouth also introduced a dramatically updated version known as Structured BASIC (or SBASIC) in 1975, which added various structured programming concepts. SBASIC formed the basis of the American National Standards Institute (ANSI) "Standard BASIC" efforts in the early 1980s.
In contrast to the Dartmouth compilers, most other BASICs were written as interpreters. This decision allowed them to run in the limited main memory of early microcomputers. Microsoft's Altair BASIC is one example: it was designed to run in only 4 KB of memory (interestingly, it was delivered on paper tape).
Kemeny became involved in an effort to produce an ANSI standard BASIC in an attempt to bring together the many small variations of the language that had developed through the late 1960s and early 1970s. This effort initially focused on a system known as Minimal BASIC that was similar to earliest versions of Dartmouth BASIC, while later work was aimed at a Full BASIC that was essentially SBASIC with various extensions.
But by the late 1980s, tens of millions of home computers were running some variant of the MS BASIC interpreter. It had become the de facto standard for BASIC, which eventually led to the abandonment of the ANSI SBASIC efforts.
Kemeny and Kurtz, however, decided to continue their efforts to introduce the concepts from SBASIC and the ANSI Standard BASIC efforts. This became True BASIC.
There are versions of the True BASIC compiler for MS-DOS, Microsoft Windows, and Classic Mac OS. At one time, versions for TRS-80 Color Computer, Amiga and Atari ST computers were offered, as well as a UNIX command-line compiler.
After several years of inactivity, as of February 2026, the TrueBASIC website is officially closed.
I cannot describe to you how jealous I am of the fact that back then writing a few thousand lines of assembly was what it took to launch a successful software company.
>writing a few thousand lines of assembly was what it took to launch a successful software company.
Yes, but that assembly was not DOS, and it wasn’t easy.
Microsoft purchased the DOS code, they didn’t write it. Of course, they did develop and modify DOS. But that was a clever (and lucky) business deal, not a technological accomplishment.
The real beginning of Microsoft was earlier, with Allen, Gates and Davidoff writing the Altair BASIC interpreter. That was a serious achievement.
They had never seen the computer they were writing that assembly code for. They did not even own any computers. It took them 8 weeks on a university computer they were not supposed to be using for that
“Altair agreed to meet them to possibly buy a BASIC interpreter… Gates and Allen had neither a BASIC interpreter nor even an Altair system on which to develop and test one. However, Allen had written an Intel 8008 emulator that ran on a PDP-10 time-sharing computer. Allen adapted this emulator based on the Altair programmer guide, and they developed and tested the interpreter on Harvard's PDP-10.
The finished interpreter, including its own I/O system and line editor, fit in only four kilobytes of memory, leaving plenty of room for the interpreted program. In preparation for the demo, they stored the finished interpreter on a punched tape that the Altair could read, and Paul Allen flew to Albuquerque to meet with Altair…
While on final approach into the Albuquerque airport, Allen realized that they had forgotten to write a bootloader to read the tape into memory. Writing in 8080 machine language, Allen finished the program before the plane landed. Only when they loaded the program onto an Altair and saw a prompt asking for the system's memory size did Gates and Allen know that their interpreter worked on the Altair hardware.”
The "competition" never been just a different codebase, that's one of the smallest pieces you'd have to actually build if you want to build a product people actually want to buy and use. The magic is basically all around it, multiplied by the code, but you really must have every else down pretty tight before the codebase even start mattering. But once it does matter, it matters a lot, hence the difficult balancing.
And for such simple processors and systems no less! No descriptor tables to deal with, no memory management to configure. These days it takes a little processor inside the main processor, just to get things started. Those were golden times.
More than a few people would rather die in poverty than put in the effort today even if you offered to time-machine them back with their finished product.
Interesting story of how MS got into the operating system business. IBM wanted the CPM operating system, but Digital Research wouldn’t sign ibms NDA… really a pivot point in computing history.
Jack Sams (IBM) was looking for a package from Microsoft containing both the BASIC computer language and an Operating System. But IBM hadn't done their homework.
Steve Ballmer:
They thought we had an operating system. Because we had this Soft Card product that had CPM on it, they thought we could licence them CPM for this new personal computer they told us they wanted to do, and we said well, no, we're not in that business.
Jack Sams (IBM);
When we discovered we didn't have - he didn't have the rights to do that and that it was not...he said but I think it's ready, I think that Gary's got it ready to go. So I said well, there's no time like the present, call up Gary.
Steve Ballmer:
And so Bill right there with them in the room called Gary Kildall at Digital Research and said Gary, I'm sending some guys down…. Treat them right, they're important guys.
Whether Kildall actually blew IBM off at that meeting or not, what was definitely the case was that CP/M didn't have a 16-bit version ready to meet IBM's schedule, and that's what ultimately took them out of the running.
wow, they had to OCR it back in from paper printouts
> This source code is old enough that it hadn’t been stored digitally. “A dedicated team of historians and preservationists led by Yufeng Gao and Rich Cini,” calling itself the “DOS Disassembly Group,” painstakingly transcribed and scanned in code from paper printouts provided by Paterson. This process was made even more difficult because modern OCR software struggled with the quality of the decades-old printout.
> With less-than-satisfactory OCR output, I resorted to a process I used many years ago when converting scans made of old Commodore ROM dumps printed on a Commodore 1515 dot-matrix printer. The process relies on the ASCII OCR output having the same repetitive errors. "B" and "8", "S" and "5" are good examples, as are "l" and "1", and "O" and "0". There are many other similar single-character errors and, when working with x86 code, there are similar errors with instructions like "MOV". This process naturally works better if the output file is monolithic rather than single-page OCR conversions because you can do substitutions across the entire converted printout and not 75 separate files.
> The next formatting hassle was the spacing. This required repetitive substitutions of a descending numbers of spaces to tabs (i.e., replace 8 spaces with a tab, 7, 6, etc.). Then if you want to return it to fixed spaces (which is likely how the original printer printed it -- spaces and not vertical tabs), you can. For pure re-creation work, spaces produce absolute column formatting while tabs can move around depending on the program displaying the file.
> Once you run thought the 15 or so common global substitutions and tab conversion, it's a lot easier to work with the file to fix formatting and perform other cleanup. This is then followed by a line-by-line comparison against the original printouts. Overall I'd say the conversion output quality with this method is very good.
Boring reply perhaps, but I've had wild success with adding even a tiny LLM afterwards to do "fixups" over OCRd text, works great for the typical O/0 issues and similar, just pass it the scrambled OCRd text together with the text around it, and even dumb and tiny 7b models running on CPU do a pretty fine job.
I remember seeing stacks of cards being carried into/out of the university "computing center" in the mid 1980s, on more than a couple of occasions. Though in retrospect, these were probably just old programs that had been in various professors offices since the mid 70s, being taken to get read into some disk in the mainframe.
We still learned how to use them in the 80’s high school computer classes, mostly because we had a balance of CP/M plus card-reader/early DOS machines, eventually .. in the labs. Rich kid schools had Apples though, and some of them also had card readers for BASIC ..
Finally, a sensible use case for BASIC's "READ" and "DATA" commands. Learning BASIC as a kid on a micro, it always struck me as an odd way to get input into a program. Sure, with INPUT, you'd have to hand enter your input every time, but baking into the program meant that you'd have to edit your program any time you wanted to change anything.
But with a card reader, you could "cut the deck". Keep the program cards, and then just stack on whatever set of data cards you wanted.
From this vantage point, in the 21st century with our flying cars and what not, it seems really quirky that back then, even your data could be a tangible thing.
Indeed, we still pay homage to the era with terms such as the stack, pushing and popping, and all kinds of things .. i remember we had fun inserting random infinite loops in other students cards on occasion until we all realized we could just have marked “finished” stacks with an X across the spine, and also to ease sorting, and so on .. i would mark certain sub-routines with different color markers on the spine too, just to see a budget for how much computing time i expected to be billed for, and so on and on .. lots of valuable hands on came from the card-based computing, its a lost art ..
The idea that it never existed digitally is obviously untrue. Likely poor wording in the author's part. They probably meant something like, so old that a printout is all that survived (which sounds vaguely like not being digital to someone in an era so far removed from a time when programs were/could realistically be printed.)
> a time when programs were/could realistically be printed
Really depends on the program. Source code is often quite manageable. Even artifacts aren't always as large as you might expect. Busybox on my system weighs in at 1.9 MiB or alternatively 928 KiB with zstd maxed out.
But I don't really see a point to printing any of it. A situation that might require the printouts is likely to largely preclude the continued existence of modern electronics, the ability to replace batteries, or even a connection to a reliable electrical grid.
Yeah, that's why I tried to include both categories. Even for programs that are small enough to be printed, we just don't do it any more. I could have worded that part better myself.
Early versions of some things, MS Basic being one example I think, were baked into ROM. One of the best innovations that Paul Allen came up with was adding software hooks to the code so bugs that were found later could still be patched.
They had some old German guy with a big beard, and two interns, running some sort of big contraption that looked like a medieval torture instrument, and the interns would run and put letters in a row and then the old guy move a massive letter and in the end out came a bit of paper with source code on it.
One has to be pretty ignorant and dismissive to claim that this is not "a big win for paper".
First of all, that comment is weirdly out of place. The quality and longevity of paper is not the topic.
Secondly, there are fragments of paper with writing as old as 2,000 years.
Thirdly, paper you look at and see the writing. With digital documents, you need the technology to read the medium and then you need to know how the information was encoded onto the medium, before you even arrive at the same level with paper, where you can start to decide the actual writing.
Paper has brought us where we are today, and given us what we know about the past. Don't be so ignorant and dismissive.
At some point, we'll have a new field in history for digital archeology, and I'm really envious for those future historians setting out to sleuth around old datasets, trying to reconstruct the history of computing, understand long-forgotten file formats to preserve data, use statistical methods to analyse binary backups, trace for specific documentation versions to crack old encryption formats...
I wonder how long it'll be before they release the source for the earliest Windows versions. The fact that they still have the source for this very old DOS at least gives hope that they also do for old Windows.
The day they would make Windows 2000 codebase open source (or source available) would be the day I could die happy (although I'd probably be long dead anyways by the time there's a glimmerof chance of it happening). What a beautiful, smooth-running operating system it was.
They will never release the code for anything that new because at that point, there's tons of licensed third-party code and the codebase is so large that going through everything to verify ownership would not be feasible. The code to NT 4 and XP have been leaked though.
Except for "the hive". Remember the hive? Sort of an alternate registry, in addition to the actual registry. Granted, it was pretty invisible, until it got corrupted.
I had a win2k machine that was my daily (at home) that was fine until idk about 2006, at which point something happened (muons?) and it would go into some kind of panic state just after bringing up the desktop. Hive corruption. I tried on and off for a couple of years to repair it, no luck. It wasn't just about the files on the HD, it was easy enough to transplant the drive and read/write anything, it was that I really liked the way I had the environment configured. Sure, it was all kind of moot, but it became a kind of personal windmill to resurrect this old thing. In the end, I booted an XP CD in it, and selected 'upgrade', and voila, it was Duncan Idaho, back from the dead.
OP said source available was acceptable. not even asking for compiler access which is also widely available.
Windows has always been more than modular enough for any repurposing and there were licenses that were not tied to specific hardware so you could use them even today.
Which is to say no one is stopping you from building a COPILOT.VBX for VisualBasic 3.0.
While oldest source of it, note that the 86-DOS v0.1-C binaries are even earlier (and v0.34 has also been found) than this v1.00 source and can be downloaded and used in an emulator. :-)
It is wonderful how early years of modern computing was brilliant. We treated machines as they really are: machines. Performance, creativity, science..., all possible to make a 386 machine work. Nowadays is all about libraries, virtualization, [bad] code over [bad] code over [bad] code..., I dont like it.
While I did a few 10 line programs in BASIC in high school on punch cards, when things really started was a freshman class on semiconductors. The class started with diodes and quantum mechanics, then onto transistors, then flip flops, then registers, then ALUs. Then it was on to designing/building a digital clock (which never worked right), and later designing/building/programming single board computers (6802 chip).
It was fun knowing everything about a computer. That's long gone!
For a very long while now, we had programmers who never understood any low level concepts at all. They have started with js or python, and never looked 'down'. There are no limits to monstrosities they will consider normal.
Linus Torvalds, a few months ago, said something to this effect when discussing AI coding tools. That his (also, mine) generation was lucky to have started with low level stuff and managed to retain the understanding of the whole stack - and kids these days don't get that. Good luck acquiring this level of feel for computers, algorithms, data structures today, when a kid's first experience with coding will be a seemingly genius chatbot.
I remember in the naughts, coming across a dos machine that was quite out of time… even for the university basement it was living in next to a pile of lead brick. Its only job was to run an instrument via an home-built ISA card and write data out to 5.25” floppies.
It's a single user OS that runs everything in ring zero by design. I'm not sure, definitionally, that it can have security vulnerabilities. I... guess maybe code execution on exposure to an untrusted floppy disk filesystem?
Look closely, you'll notice there's no network interface. The only vulnerability in a system like that is physical access by malicious individuals.
About the worst mal-ware it can have is a boot sector that installs a "terminate, stay resident" (TSR) that copies itself onto any floppy that gets inserted.
Fascinating piece of computing history. Preserving early DOS source code gives a lot of context to the structural choices that stuck around in x86 architecture for decades.
I've used Claude to fix/reconstruct & build leaked Win2k3 on Linux with original toolchain via Wine. This approach included full gdi sources reconstruction. I just don't know what to do with this, it's kinda difficult to "wash" on this scale
> Anthropic offers a formal copyright indemnification policy for its enterprise customers using the Claude API. The policy protects businesses from copyright infringement claims arising from authorized use of Claude or its generated outputs
It is rare that I say this but, thanks MS! Arguably just as, if not more, important is the BASIC that they wrote. That was what they actually wanted to do. DOS just got them the contract with IBM. For decades MS was really a developer tools company with a side biz of writing operating systems and other misc software. They also open sourced that BASIC code too [1].
[1] https://opensource.microsoft.com/blog/2025/09/03/microsoft-o...
I dont think I've ever seen a commit that says "49 years ago". Damn.
1968 https://www.netlib.org/go/fft.f
https://github.com/dspinellis/unix-history-repo
I remember when I realized I had been using Microsoft all along through my Commodore 64.
What's interesting is that Microsoft BASIC itself was derived from BASIC-PLUS which itself was derived from Dartmouth BASIC (which evolved into a structured programming language called SBASIC (Structured BASIC). But the popularity of Microsoft BASIC, actually halted the standardisation of SBASIC as an ANSI standard.
https://en.wikipedia.org/wiki/Microsoft_BASIC
The Altair BASIC interpreter was developed by Microsoft founders Paul Allen and Bill Gates using a self-written Intel 8080 emulator running on a PDP-10 minicomputer.[1] The MS dialect is patterned on Digital Equipment Corporation's BASIC-PLUS on the PDP-10, which Gates had used in high school.
https://en.wikipedia.org/wiki/Dartmouth_BASIC
Dartmouth BASIC is the original version of the BASIC programming language. It was designed by two professors at Dartmouth College, John G. Kemeny and Thomas E. Kurtz. With the underlying Dartmouth Time-Sharing System (DTSS), it offered an interactive programming environment to all undergraduates as well as the larger university community.
Dartmouth also introduced a dramatically updated version known as Structured BASIC (or SBASIC) in 1975, which added various structured programming concepts. SBASIC formed the basis of the American National Standards Institute (ANSI) "Standard BASIC" efforts in the early 1980s.
In contrast to the Dartmouth compilers, most other BASICs were written as interpreters. This decision allowed them to run in the limited main memory of early microcomputers. Microsoft's Altair BASIC is one example: it was designed to run in only 4 KB of memory (interestingly, it was delivered on paper tape).
Kemeny became involved in an effort to produce an ANSI standard BASIC in an attempt to bring together the many small variations of the language that had developed through the late 1960s and early 1970s. This effort initially focused on a system known as Minimal BASIC that was similar to earliest versions of Dartmouth BASIC, while later work was aimed at a Full BASIC that was essentially SBASIC with various extensions.
But by the late 1980s, tens of millions of home computers were running some variant of the MS BASIC interpreter. It had become the de facto standard for BASIC, which eventually led to the abandonment of the ANSI SBASIC efforts.
Kemeny and Kurtz, however, decided to continue their efforts to introduce the concepts from SBASIC and the ANSI Standard BASIC efforts. This became True BASIC.
https://en.wikipedia.org/wiki/True_BASIC
There are versions of the True BASIC compiler for MS-DOS, Microsoft Windows, and Classic Mac OS. At one time, versions for TRS-80 Color Computer, Amiga and Atari ST computers were offered, as well as a UNIX command-line compiler.
After several years of inactivity, as of February 2026, the TrueBASIC website is officially closed.
Ah, the good ol’ “Embrace, Extend, … Extinguish”
I cannot describe to you how jealous I am of the fact that back then writing a few thousand lines of assembly was what it took to launch a successful software company.
>writing a few thousand lines of assembly was what it took to launch a successful software company.
Yes, but that assembly was not DOS, and it wasn’t easy.
Microsoft purchased the DOS code, they didn’t write it. Of course, they did develop and modify DOS. But that was a clever (and lucky) business deal, not a technological accomplishment.
The real beginning of Microsoft was earlier, with Allen, Gates and Davidoff writing the Altair BASIC interpreter. That was a serious achievement.
They had never seen the computer they were writing that assembly code for. They did not even own any computers. It took them 8 weeks on a university computer they were not supposed to be using for that
“Altair agreed to meet them to possibly buy a BASIC interpreter… Gates and Allen had neither a BASIC interpreter nor even an Altair system on which to develop and test one. However, Allen had written an Intel 8008 emulator that ran on a PDP-10 time-sharing computer. Allen adapted this emulator based on the Altair programmer guide, and they developed and tested the interpreter on Harvard's PDP-10.
The finished interpreter, including its own I/O system and line editor, fit in only four kilobytes of memory, leaving plenty of room for the interpreted program. In preparation for the demo, they stored the finished interpreter on a punched tape that the Altair could read, and Paul Allen flew to Albuquerque to meet with Altair…
While on final approach into the Albuquerque airport, Allen realized that they had forgotten to write a bootloader to read the tape into memory. Writing in 8080 machine language, Allen finished the program before the plane landed. Only when they loaded the program onto an Altair and saw a prompt asking for the system's memory size did Gates and Allen know that their interpreter worked on the Altair hardware.”
https://en.wikipedia.org/wiki/Altair_BASIC
To be fair, i think you needed a cutthroat businessman leading the company. Which i guess is more or less the same today
This too but early MS to their employs was closer to a hipster SV vibe coding in a coffee shop a decade ago.
Replace Assembly with TypeScript/Rust/Go/whatever and as long as the idea is good and useful, same thing applies today.
Except the competition was essentially non existent and no one would copy your product with llm in a day
What makes you think there was no competition?
The "competition" never been just a different codebase, that's one of the smallest pieces you'd have to actually build if you want to build a product people actually want to buy and use. The magic is basically all around it, multiplied by the code, but you really must have every else down pretty tight before the codebase even start mattering. But once it does matter, it matters a lot, hence the difficult balancing.
And for such simple processors and systems no less! No descriptor tables to deal with, no memory management to configure. These days it takes a little processor inside the main processor, just to get things started. Those were golden times.
More than a few people would rather die in poverty than put in the effort today even if you offered to time-machine them back with their finished product.
Interesting story of how MS got into the operating system business. IBM wanted the CPM operating system, but Digital Research wouldn’t sign ibms NDA… really a pivot point in computing history.
From “Triumph of the Nerds” tv transcript:
https://www.pbs.org/nerds/part2.html
Jack Sams (IBM) was looking for a package from Microsoft containing both the BASIC computer language and an Operating System. But IBM hadn't done their homework.
Steve Ballmer: They thought we had an operating system. Because we had this Soft Card product that had CPM on it, they thought we could licence them CPM for this new personal computer they told us they wanted to do, and we said well, no, we're not in that business.
Jack Sams (IBM); When we discovered we didn't have - he didn't have the rights to do that and that it was not...he said but I think it's ready, I think that Gary's got it ready to go. So I said well, there's no time like the present, call up Gary.
Steve Ballmer: And so Bill right there with them in the room called Gary Kildall at Digital Research and said Gary, I'm sending some guys down…. Treat them right, they're important guys.
Eh, basically all facts in this story are disputed by all sides. Aside from general gist that there was some meeting that didn't go well.
Whether Kildall actually blew IBM off at that meeting or not, what was definitely the case was that CP/M didn't have a 16-bit version ready to meet IBM's schedule, and that's what ultimately took them out of the running.
Discussion, on the source, at the time (79 points, 24 days ago, 19 comments) https://news.ycombinator.com/item?id=47957494
Or on the GitHub clone (162 points, 15 comments) https://news.ycombinator.com/item?id=47946813
wow, they had to OCR it back in from paper printouts
> This source code is old enough that it hadn’t been stored digitally. “A dedicated team of historians and preservationists led by Yufeng Gao and Rich Cini,” calling itself the “DOS Disassembly Group,” painstakingly transcribed and scanned in code from paper printouts provided by Paterson. This process was made even more difficult because modern OCR software struggled with the quality of the decades-old printout.
I'd like to hear more about what works in OCR of dot-matrix fonts.
I've been able to OCR letter-quality printer output to 97% (mostly Os and Xs problems).
But it seems that machine-learning text-recognition is also now biased to reject computer code because it doesn't look like human language.
There's a writeup here from one of the people on the team about the work it took to go from the listings to source code. http://cini.classiccmp.org/recoveryblog.htm
> With less-than-satisfactory OCR output, I resorted to a process I used many years ago when converting scans made of old Commodore ROM dumps printed on a Commodore 1515 dot-matrix printer. The process relies on the ASCII OCR output having the same repetitive errors. "B" and "8", "S" and "5" are good examples, as are "l" and "1", and "O" and "0". There are many other similar single-character errors and, when working with x86 code, there are similar errors with instructions like "MOV". This process naturally works better if the output file is monolithic rather than single-page OCR conversions because you can do substitutions across the entire converted printout and not 75 separate files.
> The next formatting hassle was the spacing. This required repetitive substitutions of a descending numbers of spaces to tabs (i.e., replace 8 spaces with a tab, 7, 6, etc.). Then if you want to return it to fixed spaces (which is likely how the original printer printed it -- spaces and not vertical tabs), you can. For pure re-creation work, spaces produce absolute column formatting while tabs can move around depending on the program displaying the file.
> Once you run thought the 15 or so common global substitutions and tab conversion, it's a lot easier to work with the file to fix formatting and perform other cleanup. This is then followed by a line-by-line comparison against the original printouts. Overall I'd say the conversion output quality with this method is very good.
Boring reply perhaps, but I've had wild success with adding even a tiny LLM afterwards to do "fixups" over OCRd text, works great for the typical O/0 issues and similar, just pass it the scrambled OCRd text together with the text around it, and even dumb and tiny 7b models running on CPU do a pretty fine job.
ABBYY has a specific module for dot matrix printouts so I’m surprised it was a struggle for them but every document is different
I've recovered some ancient software I wrote via scanning in listings I found among my dad's papers.
Yet another case where text printed on paper outlived any digital storage.
Seems like it was never digitally stored in the first place, and the printed text was barely readable due to age. Not really a big win for paper.
Well it had to have been on disk or tape at some point. It wasn't all typed in by hand every time they needed to build a new version.
unless they used punch cards
Punch cards are still a form of digital storage, mind.
Also a form of storing things on paper
I threw out all my punch cards. Wish I'd kept at least a listing!
> unless they used punch cards
For MS-DOS?
Not likely. Punch cards disappeared around the end of 1976.
I remember seeing stacks of cards being carried into/out of the university "computing center" in the mid 1980s, on more than a couple of occasions. Though in retrospect, these were probably just old programs that had been in various professors offices since the mid 70s, being taken to get read into some disk in the mainframe.
We still learned how to use them in the 80’s high school computer classes, mostly because we had a balance of CP/M plus card-reader/early DOS machines, eventually .. in the labs. Rich kid schools had Apples though, and some of them also had card readers for BASIC ..
"[..] card readers for BASIC"
Finally, a sensible use case for BASIC's "READ" and "DATA" commands. Learning BASIC as a kid on a micro, it always struck me as an odd way to get input into a program. Sure, with INPUT, you'd have to hand enter your input every time, but baking into the program meant that you'd have to edit your program any time you wanted to change anything.
But with a card reader, you could "cut the deck". Keep the program cards, and then just stack on whatever set of data cards you wanted.
From this vantage point, in the 21st century with our flying cars and what not, it seems really quirky that back then, even your data could be a tangible thing.
Indeed, we still pay homage to the era with terms such as the stack, pushing and popping, and all kinds of things .. i remember we had fun inserting random infinite loops in other students cards on occasion until we all realized we could just have marked “finished” stacks with an X across the spine, and also to ease sorting, and so on .. i would mark certain sub-routines with different color markers on the spine too, just to see a budget for how much computing time i expected to be billed for, and so on and on .. lots of valuable hands on came from the card-based computing, its a lost art ..
My college used them for PL/I and IBM Assembly language programming classes until 1982. Cards were used well into the mid-80s.
We still used them in the university as late as in 2010...
...as writing paper.
The idea that it never existed digitally is obviously untrue. Likely poor wording in the author's part. They probably meant something like, so old that a printout is all that survived (which sounds vaguely like not being digital to someone in an era so far removed from a time when programs were/could realistically be printed.)
Having printouts were necessary when:
1. you were using a DECwriter dot matrix printer as a terminal
2. using an ASR-33 teletype as a terminal
3. using punch cards or paper tape
4. using a glass tty that could only display 24 lines
5. when you did not have a remote terminal, and wanted to spread your code out on a table and debug it
Brings back memories of desk checking
> a time when programs were/could realistically be printed
Really depends on the program. Source code is often quite manageable. Even artifacts aren't always as large as you might expect. Busybox on my system weighs in at 1.9 MiB or alternatively 928 KiB with zstd maxed out.
But I don't really see a point to printing any of it. A situation that might require the printouts is likely to largely preclude the continued existence of modern electronics, the ability to replace batteries, or even a connection to a reliable electrical grid.
Yeah, that's why I tried to include both categories. Even for programs that are small enough to be printed, we just don't do it any more. I could have worded that part better myself.
Early versions of some things, MS Basic being one example I think, were baked into ROM. One of the best innovations that Paul Allen came up with was adding software hooks to the code so bugs that were found later could still be patched.
How did they print it then, I wonder?
They had some old German guy with a big beard, and two interns, running some sort of big contraption that looked like a medieval torture instrument, and the interns would run and put letters in a row and then the old guy move a massive letter and in the end out came a bit of paper with source code on it.
Where can I buy this printer?
Humbrechthof, Mainz, Germany ofc.
(https://en.wikipedia.org/wiki/Humbrechthof)
One has to be pretty ignorant and dismissive to claim that this is not "a big win for paper".
First of all, that comment is weirdly out of place. The quality and longevity of paper is not the topic.
Secondly, there are fragments of paper with writing as old as 2,000 years.
Thirdly, paper you look at and see the writing. With digital documents, you need the technology to read the medium and then you need to know how the information was encoded onto the medium, before you even arrive at the same level with paper, where you can start to decide the actual writing.
Paper has brought us where we are today, and given us what we know about the past. Don't be so ignorant and dismissive.
> struggled with the quality of the decades-old printout.
barely
It sounds like this printout has deteriorated badly and was barely readable.
If it was your standard issue cheap dot-matrix printout, it may not been particularly legible even back then.
Even if the printer itself was fine it doesn't imply the ribbon was wet enough.
At some point, we'll have a new field in history for digital archeology, and I'm really envious for those future historians setting out to sleuth around old datasets, trying to reconstruct the history of computing, understand long-forgotten file formats to preserve data, use statistical methods to analyse binary backups, trace for specific documentation versions to crack old encryption formats...
I wonder how long it'll be before they release the source for the earliest Windows versions. The fact that they still have the source for this very old DOS at least gives hope that they also do for old Windows.
The day they would make Windows 2000 codebase open source (or source available) would be the day I could die happy (although I'd probably be long dead anyways by the time there's a glimmerof chance of it happening). What a beautiful, smooth-running operating system it was.
They will never release the code for anything that new because at that point, there's tons of licensed third-party code and the codebase is so large that going through everything to verify ownership would not be feasible. The code to NT 4 and XP have been leaked though.
Agreed. It's still my favorite Windows version.
Except for "the hive". Remember the hive? Sort of an alternate registry, in addition to the actual registry. Granted, it was pretty invisible, until it got corrupted.
I had a win2k machine that was my daily (at home) that was fine until idk about 2006, at which point something happened (muons?) and it would go into some kind of panic state just after bringing up the desktop. Hive corruption. I tried on and off for a couple of years to repair it, no luck. It wasn't just about the files on the HD, it was easy enough to transplant the drive and read/write anything, it was that I really liked the way I had the environment configured. Sure, it was all kind of moot, but it became a kind of personal windmill to resurrect this old thing. In the end, I booted an XP CD in it, and selected 'upgrade', and voila, it was Duncan Idaho, back from the dead.
Anyway.. loved win2k, but not a fan of the hive.
The registry is a collection of individual database files known as hives.
I think you are mistaking the registry for the registry.
https://devblogs.microsoft.com/oldnewthing/20030808-00/?p=42...
Wasn't there a 2000 source leak a while ago? I remember some exploits coming out after the leak.
Yes but it could not be legally used by anything.
OP said source available was acceptable. not even asking for compiler access which is also widely available.
Windows has always been more than modular enough for any repurposing and there were licenses that were not tied to specific hardware so you could use them even today.
Which is to say no one is stopping you from building a COPILOT.VBX for VisualBasic 3.0.
There is a mostly complete leak of it...
It shouldn't be hard to disassemble it.
I imagine its not far off. I get the impression they are almost done with windows as a platform.
I am sure that there is a lot good material to take inspiration and learning even from the early Windows 3.11.
Do a deep dive into how OS/360 formalized to having DOS.
/s ?
Pretty sure it's a bot or simple karma farming operation.
They waited a couple decades too long for this to be of interest.
Recent and related:
Microsoft open sources DOS 1.00 on 45th anniversary - https://news.ycombinator.com/item?id=47957494 - April 2026 (19 comments)
While oldest source of it, note that the 86-DOS v0.1-C binaries are even earlier (and v0.34 has also been found) than this v1.00 source and can be downloaded and used in an emulator. :-)
https://arstechnica.com/gadgets/2024/01/the-oldest-known-ver...
It is wonderful how early years of modern computing was brilliant. We treated machines as they really are: machines. Performance, creativity, science..., all possible to make a 386 machine work. Nowadays is all about libraries, virtualization, [bad] code over [bad] code over [bad] code..., I dont like it.
I sometimes think that my mental model of a computer is still an Apple ][+ with 48K of RAM leads to my writing better code.
While I did a few 10 line programs in BASIC in high school on punch cards, when things really started was a freshman class on semiconductors. The class started with diodes and quantum mechanics, then onto transistors, then flip flops, then registers, then ALUs. Then it was on to designing/building a digital clock (which never worked right), and later designing/building/programming single board computers (6802 chip).
It was fun knowing everything about a computer. That's long gone!
And mine is a Commodore Vic-20 circa 1981, with 3583 bytes of free RAM. Programmed in 6502 assembler. Can't get much closer to the CPU than that.
For a very long while now, we had programmers who never understood any low level concepts at all. They have started with js or python, and never looked 'down'. There are no limits to monstrosities they will consider normal.
Linus Torvalds, a few months ago, said something to this effect when discussing AI coding tools. That his (also, mine) generation was lucky to have started with low level stuff and managed to retain the understanding of the whole stack - and kids these days don't get that. Good luck acquiring this level of feel for computers, algorithms, data structures today, when a kid's first experience with coding will be a seemingly genius chatbot.
>and managed to retain the understanding of the whole stack
No one understands the whole stack. There is too much specialized information.
Even assembly is a high-level language relative to what’s actually going on inside a modern CPU.
DOS and brilliant in the same sentence...
Time to find vulnerabilities!
I remember in the naughts, coming across a dos machine that was quite out of time… even for the university basement it was living in next to a pile of lead brick. Its only job was to run an instrument via an home-built ISA card and write data out to 5.25” floppies.
What uses would this code have in 2026?
It's a single user OS that runs everything in ring zero by design. I'm not sure, definitionally, that it can have security vulnerabilities. I... guess maybe code execution on exposure to an untrusted floppy disk filesystem?
Look closely, you'll notice there's no network interface. The only vulnerability in a system like that is physical access by malicious individuals.
About the worst mal-ware it can have is a boot sector that installs a "terminate, stay resident" (TSR) that copies itself onto any floppy that gets inserted.
To see what decisions they made. Like any historical document. Aim to understand the people of the time.
I’m sure this is better software than Windows Millenium Edition
Fascinating piece of computing history. Preserving early DOS source code gives a lot of context to the structural choices that stuck around in x86 architecture for decades.
readable plain text plus boring metadata still ages better than most clever archival systems
In this case a paper printout.
More code that copilot can be trained on.
How about Microsoft fixes npm, github, and vscode
Back when it was all written by hand and optimized well.
Too little, too late.
in the words of mr. mitch-hedburg “here, you throw this away“
He could have sold those printouts instead of giving them away.
I'm wondering whether ReactOS can exploit Claude et. al. to their fullest and "recreate" Windows 2000/95. I may donate some tokens for that cause.
I've used Claude to fix/reconstruct & build leaked Win2k3 on Linux with original toolchain via Wine. This approach included full gdi sources reconstruction. I just don't know what to do with this, it's kinda difficult to "wash" on this scale
That sounds like a terrifying legal minefield that they would not want to tread
Is it not safe to assume Window source code is not present in the LLM training data?
No: https://archive.org/download/windows-source-code
Slap a fair use on it and call it a day.
> Anthropic offers a formal copyright indemnification policy for its enterprise customers using the Claude API. The policy protects businesses from copyright infringement claims arising from authorized use of Claude or its generated outputs
So just claim it is Claude
What's that phrase, "derivative work" or something?
But surely anything the LLM outputs is clear of licensing requirements /s
Or would Microsoft like to argue otherwise in court?