In this case they may never have had the source, the copyright is for Design Science, Inc which makes MathType a popular equation editor for Word. Depending on how this was licensed this may have even technically been illegal (due to copyright issues); although I suspect MS has a license that allows this.

I've never heard him claim that MS actually lost the source code to Word, only that they couldn't find the cause of a decades-old bug (related to selection and text-justification as I recall), even though it had thousands of bug reports, and that they spent years looking for it before giving up.

The point was that the code is too big and complicated, even for some of the best engineers in the world.

Microsoft has lost tons of code over the years. Even with the source, refactoring office which has people using file formats that are binary dumps of memory, is not trivial.

This was actually the Onus for the switch to the XML formats IIRC. Basically after the DOJ settlement they had the uneasy realization that the requirement to document the .doc format was going to be a nightmare because nobody had a complete spec of it. To make it worse the code wasn't very portable and customers were asking for x64 support pretty hard at the time.

Re: 64 bit is that about Excel? I found the idea of a Word document needing >4GB RAM somewhat absurd

Note that due to the way the 32-bit address space was laid out, a process could really use only about 2GB of RAM — the extra 2GB was reserved for the system based on old 386-era CPU limitations. Since that space had various things allocated in it, a normal program generally wouldn't get more than 1.7GB in a single allocation — e.g. according to https://support.microsoft.com/en-us/help/313275/-not-enough-... Excel 2003 had a heap limit of about 1GB.

The other thing to keep in mind is that Office documents are, in addition to being somewhat bloated internally, far more than just text. Think about all of the people writing things like documentation with hundreds of screenshots (all uncompressed BMPs), audio or video, etc. — and the people with those are far more likely to be at the kind of large corporations which expect value from their support contracts. There were multiple ways to deal with that problem but in general the easiest was switching to a 64-bit address space.

Recently they had to enable /LARGEADDRESSAWARE in 32-bit Outlook.

If you want to use a 64-bit COM/OLE object, such as from a VBA script, then it's extremely difficult unless the host is 64 bit.

I can imagine users just pasting images without a 2nd thought about their sizes.

I routinely update single page Powerpoints with more than 4 MB, due to the background image or logos.

Maybe they just don't know how to run the same version of the compiler any more, Visual C++ 4.2 or whatever they had... I remember it stopped working with some newer version of Windows.

There'd be nothing extraordinary about that, either. I've never worked for a company that could build something today that they released twenty years ago.

25 years old and I got it to compile and run when I re-found it last year!

https://github.com/linker3000/Historic-code-PC-Pascal-and-AS...

This do make a lot of sense. I don't think there is exe calls directly linked from other apps. If that were the case they would just update the address in the calling app. Much easier. Anyway, very nice piece of work. :)