Host Abstraction Layer (HAL)

When I originally worked on Seahaven Towers 2.0 and Haniport Levee I had one file that encapsulated those application's interaction with the host OS. The header file was HostSystem.h and there were two instances of the source, HostSystemMac.c for macOS and HostSystemWin.c for Windows (yes, I use the ".c" extension for C++ sources—so did Taligent, so blame them). This worked well for a while, but as each host OS started changing rapidly I realized I couldn't keep up. For whatever reason (and I can think of a few nefarious ones) each new OS release seemed intent on breaking lots of stuff, especially UI stuff. In a substantial number of cases those changes weren't better, just different, meaning developer sources had to be updated, and applications released again, and again. Is there a business model out there that profits from frequent updates? I know, silly question.

About then I got to thinking about menus. Which was easier, building menus up from a rapidly changing host OS, or building them down towards the core OS and graphics systems which seemed to change less frequently? Actually, building down looked easier, and certainly it looked like a lot more fun. And given that decision, could I do the same with other UI elements, for example windows, controls, and dialogs? Well, I certainly could if I had the entire desktop to work with. Lots of games already did this, the process of taking over the screen and implementing a serviceable user experience of their own design. What I then realized is that platforms such as macOS and Windows weren't going to change that lower level much if it meant disruption to those games. Here Ms or Mr Gamer, pick one, this nifty OS upgrade you aren't interested in or that game you love. Yep, another silly question.

It proved to be an accurate assessment for quite a number of years, only recently (Summer 2021) starting to break down. So I took over the screen, commandeered the event system, figured out a scheme for event dispatching, and pretty soon had functional applets using Guildhall menus, windows, controls, and desktop elements.

The bring-up process for this change happened in several stages. The event system and dispatch came first, followed by the media stuff. I separated the host header files into two parts, one for basics (HostBasics.h) and one for media (HostMedia.h). Then came another interesting decision point. Seahaven 2.0 (and Haniport) offered a means of saving games called an Archive window. It was basically just a flat array of saved games with names, although it offered the illusion of having folders. But what if it was more than that? What if it really was more like a dmg or zip file, with a hierarchical directory embedded in a host file? The idea was intriguing, so I spent more and more time on it, again because it was fun. Eventually I got to a relatively stable hierarchical file system with support for several forks, including a version fork, a resource fork, and an ephemeral information fork, the latter two having arbitrarily extensible attributes. Of course each file also had a data fork. And at that point I broke out another host source file to support this new runtime (Host Archives). Finally, as I was tuning Guildhall for an Alpha release for customers of Seahaven and Haniport, I added in a few more pieces to accommodate running a finished desktop product.

This is the layering I ended up with (macOS host version).

No scheme survives contact with a new OS, so getting Guildhall to again run on Windows, or for the first time on FreeBSD, will undoubtedly shuffle this picture. But I expect the basic separations to remain the same.