What is the accepted wisdom with fixing errors in vintage computer headers etc

[Elektraglide]

As I dig deeper into Tek4404, I discover missing declarations, or even headers with syntax errors that do not compile.
I've been fixing them as I go - because I need them - but while it means my disk image is more functional, it is not as-is (and broken).

Any thoughts?

Some are pretty hilarious. The headers for floating point functions have misnamed declarations (mixing up double and float ops) and then the actual printed manuals also have the same errors! You literally could not use these headers as the assembler throws an error - I guess we had less QA in them days!

 

[djg]

I would go with an archive of the as released code and a runable image, a release of fixed OS of Tek released software that follows your development,and a release with all your improvements like your GCC port assuming the effort isn't too great. The fixed tek release could also be replaced by documentation of the fixes.

 

[Bruce Tomlin]

If you put them in a git repo, you could add a separate check-in that corrects the errors. Then you have the original, tagged as such, plus an easy-to-diff record of the changes. Of course this is a bit harder to do with printed manuals!

 

[Elektraglide]

If you put them in a git repo, you could add a separate check-in that corrects the errors. Then you have the original, tagged as such, plus an easy-to-diff record of the changes. Of course this is a bit harder to do with printed manuals!

Yes, I did think of that and it would be neat to have before/after etc, but MFMemu images are 100MB and git has never been best buddies with large binary files.

 

[Bruce Tomlin]

Oof, I didn't realize these were files inside of disk images. The only way that works is to make some kind of packaging utility that builds a fresh image from individual files.

 

[Elektraglide]

Oof, I didn't realize these were files inside of disk images. The only way that works is to make some kind of packaging utility that builds a fresh image from individual files.

Actually, mfm-emu files are fat 'n' sparse for performance. Just looked and they compress to sub 10MB. So probably do-able to commit them.

There are 4 buckets of changes:
1. Fixing just plain wrong headers etc
2. Patching executables (for which I have no source) which are broken. (eg I've patched "ls" to play nice with pseudo terminals)
3. Adding new headers/helper libs for undocumented (but working) functionality I've discovered with Ghidra.
4. Writing all new software. My replacement linker for Uniflex appears to be 2x the speed of the native one.

All the new software is in github already (https://github.com/Elektraglide/tek4404)