DrawFile module archaeology

I was recently working on RO4’s ill-named ImageFileConvert system and accidentally fell into the DrawFile module, where I noticed more than the usual amount of oddness. I shall share the odd.

DrawFile contains an implementation of a renderer for Draw files (it doesn’t match !Draw, but that’s a different story). It tries to be somewhat extensible, but is not very well designed.

It was introduced into the ROM in 3.60, so I haven’t looked at any earlier softload versions. It processes the various objects familiar to !Draw, and defers others to a Service Call (&45540). Nothing changed until 3.80 where two things happened simultaneously:

• It gained a service call handler for &45540, so that if it receives a request to render one of the standard objects, it calls the appropriate code.
• It gained a “fast service table”, which was introduced ready for RO4 in order to mitigate the massive misuse of the service call mechanism.

This does not seem particularly odd, but for two observations:

1. For reasons that are very difficult to justify, the main render loop does NOT pass on unknown object numbers between 0 and 255¹, so new system objects cannot be rendered by a compatibility module and, crucially, its own service handler for standard objects could never be called.
2. The ‘fast service table’ doesn’t include &45540 anyway… so its service handler really really can never be called on any OS newer than 3.80.

I mention this because I think both of these decisions are wrong, and they’re still there in RO5 (which is a lightly warmed-over version of 3.80 after all ;-)

I’m also firmly of the opinion that Service Calls are the work of the devil and almost every service call ought to have been a vector call instead. I will die on that particular hill.

¹ Nor anything with b31 set, and I’m sure that’s not deliberate. But as object numbers have been 16b since 1999 YMMV

That’s what happens when people modify stuff without being in possession of the pink dinosaur.

Sounds to me like “a good idea” was created, and then it was half implemented. But, fundamentally, broken because of the reasons outlined.

Have you filed a bug report?

Isn’t a Service Call intended to be a “notification that can be claimed if necessary” as opposed to “a way of inserting yourself into OS behaviour” (vector)?

That being said, extending a renderer sounds more like it ought to be a vector for extension rather than hijacking a notification to get the job done?

I’ve no idea what the bug is.

1. A doesn’t call B
2. B cannot call C
3. C exists
4. All of the above
5. Blueberries

Let’s start with the obvious -

• The fast dispatch mechanism is missing the new service call
• Unknown objects with IDs under 256 aren’t handled
• The standard object handler is broken?

And, of course:

• Blueberries

I thought DrawFile issued the service call &45540 to enable externsion modules to handle formats it does not understand. If so, why does DrawFile itself need to have a handler for that service call &45540?

If so, why does DrawFile itself need to have a handler

Presumably because something else might use the exact same mechanism, especially if it knows something that DrawFile doesn’t know, such as what a multipage DrawFile looks like. Or perhaps the intention is that something can handle object type X by substituting it with simple object Y which DrawFile can then render.

It is at this point you hit yourself in the head with the Vectors chapter of the PRMs.

The reason I describe DrawFile as not well designed is that internally it uses an object registration system… so you’d think it might allow other things to register their object support functions with it just as it does itself but NO. Service calls, whose prioritisation is obscure.