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 GhHostSystem.hpp and there were two instances of the source, GhHostSystemMac.cpp for macOS and GhHostSystemWin.cpp for Windows. 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.

WIth that assumption in mind, the bring-up process for a new host OS proceeds in several stages. The event system and dispatch come first, followed by the media stuff. I separated the host header files into two parts, one for basics (GhHostBasics.hpp) and one for media (GhHostMedia.hpp). 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 (GhHostArchives.hpp). 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.

The stability achieved by isolating most of Guildhall from the host OS worked well for quite a number of years, but it broke down when the host OS (macOS) began restricting full access to the screen except during certain specific update cycles. It took some time, and a lot of code, but by caching graphics calls until those host update events got posted I was able to retain Guildhall's separate event dispatch thread and restore full operation on the latest host systems.

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 a unix derivative OS, will undoubtedly shuffle this picture. But I expect the basic separations to remain the same.