Nope. The formats were completely undocumented. Nothing outside of Microsoft could properly import the formats. Sure things tried, but they inevitably always failed in rather dramatic ways.

Joel on Software had article about the file formats several years ago. Apparently big chunks of the files are basically just memdumps. http://www.joelonsoftware.com/items/2008/02/19.html

I know a guy who worked at Microsoft and left to create a .doc reader for some other software. He said the .doc format wasn't even documented inside Microsoft and pretty much no-one could tell you how to parse it, apart from trial-and-error.

The prevailing idea seemed to be that if you wanted conversion of Word documents, let's say to screenshots, to match properly in all cases, the only way was a dedicated (or virtual) machine running Windows+Word and some VBS to automate the conversion.

I don't know if this is still the best way. LibreOffice has came a long way for sure, but still doesn't reproduce Word's layout perfectly (which is still the expectation).

Some differences in rendering or printing would be acceptable - what is not acceptable, however, is unintended corruption of existing documents.

E.g. if I open a word document in libreoffice (to do e.g. review and commenting), save it without any changes to the layout, then I'd expect the original author to have the same document layout as before... and that is not so. The same applies to LibreOffice Calc - opening and saving the document produces changes.

Can't you just have a unit test that verifies that reading and immediately writing a document should keep it completely unchanged, except possibly for metadata?

Im guessing the unit test would fail. So what good would it do to add a failing unit test?

I do not envy those who have spent years of their life trying to reverse engineer .doc and .xls formats... those are pretty nasty.