Right. I'm aware of that and obviously am aware of the code ownership restraints. You are to be commended for finding workarounds.
I only mentioned/linked to detlef because at that time we seem to have encountered similar issues to what you are discussing...lack of sources, working with a binary only, issues with prefs, etc. I just happen to see a lot of parallels in the struggle.
I thought perhaps if all of detlef's postings from that era were examined, you might find something helpful, or perhaps an issue not considered yet.
#6
Personally, I feel uncomfortable to "mine" the work of other developers for clues instead of asking them directly, if they are still around and are inclined to go over their past work, offering insights. Ten, twenty or more years down the line it does become difficult to remember the rationale for design and implementation decisions made, though.
Old code tends to make you make the worst assumptions about the motivations and especially the ability of the original developer and designer (exceptions exist, though: I still find Exec to be exceptionally slick code, for example, and just to mention it, the Amiga platform-specific code of the Amiga Unix kernel). You're almost always biased, and it takes an effort to dial back how harshly you are bound to judge what you will see. Well, you are looking for bugs after all, and compatibility/portability issues, too. But you cannot conveniently infer the reason behind the design and implementation. What works for me is to remind myself constantly that the guys who wrote this weren't "stupid", it's just that I don't know enough about the code yet: I'm the one who's stupid right now.
The code does not always provide answers, and given its age, the only way forward often is to go back to the specifications for which it was built, e.g. the ROM kernel reference manuals, schematics, etc., and do your homework
If you are lucky, you can talk to other developers who have been around a long time and who can provide context. We have been very lucky in this respect (and here's hoping dearly that our luck will not run out any time soon).
That said, nothing beats reading the code and testing how it works and interacts. This is what takes so much time, especially in such a small team. The printer.device is one such case. We lacked the source code to the device as used in the OS 3.5/3.9 updates, so for the OS4 work I "ported" the V39 code to build cleanly and portably under SAS/C, then moved it to the PPC platform. Detlef Würkner's work would subsequently build upon it.
The cleanest way to start over for the 3.1.4 update seemed to be to take the SAS/C port I had prepared and take it from there. Sure enough, this was 10-15 year old code which had not been reviewed since. There was trouble in every corner. Thomas reviewed the printer.device, tested, updated and rewrote it, filling in the gaps in the implementation to allow for OS 3.5/3.9 driver and prefs compatibility. Then it turned out that the HP printer drivers which were added in the OS 3.5/3.9 update were just as lacking as the printer.device and had to be reviewed, tested and updated. This was pretty scary
I'm still floored by what Thomas accomplished. At the back of my mind I still do wonder if printer.device deserved that much love, though. It's an interface for transforming bitmap imagery and for producing text output on mechanical devices which, unless you exclude the generic PostScript and HP-PCL printer drivers, are now so old that they are no longer being manufactured. Still, this is probably part of the package if you are going to update an operating system and its components which was last updated at this scale some 24 years ago. Funny thing: the reconstruction of Babbage's Analytical Engine includes a print output device (as part of the original design), so who am I to argue
