One curious support issue that’s landed in my lap a few times is installation failure when importing old 3D Realms shareware titles: like Duke Nukem, Cosmo’s Cosmic Adventure, Secret Agent and the like.
The problem is that the zips available from the 3D Realms download page (which have found their way onto other download sites too) have corrupt file permissions. After extracting the zip using OS X’s built-in zip support, one or more of the game files may be marked as write-only. This prevents Boxer from accessing the contents of those files, making the game’s installer spit out spurious errors and fail abysmally.
The permissions on the affected files can be corrected from Finder’s Get Info panel:
Once you’ve ensured that all the files are readable, Boxer should import the game successfully.
An easier fix though is to use The Unarchiver to extract the zips instead. <plug>This is a terrific (and free) drop-in replacement for OS X’s built-in zip support, seamlessly extending it to support RAR, 7zip, and other archive formats popular on abandonware sites. It works exactly like the built-in support, extracting in the background instead of making you plod through a worthless fucking UI.</plug> More to the point, The Unarchiver ignores file permissions when extracting, avoiding the write-only problem in the first place.
I’m not getting any kickbacks or sexual favours for this endorsement; The Unarchiver is just a great piece of software which I’ve been using for 5 years, and can recommend unreservedly to any Mac user.
After several months of big noisy feature work I needed to blow off a little steam: so over the past few weekends I’ve been pottering away on a feature I knew would be of use to approximately 6 people. Can you guess what feature that could be? That’s right!
Boxer 1.4 emulates a 24-pin dot matrix parallel printer, compatible with the IBM PPDS and Epson ESC/P2 printer languages popular in the DOS heyday. This means any DOS app can print text; any DOS app with drivers for IBM ProPrinter or Epson LX/LQ-series printers (including Word, Works, WordPerfect and others) can print graphics too. Authentically shitty graphics, as you can see — just like the old days.
This emulation is built on the third-party printer emulation patch that’s been floating around for DOSBox: rewritten in Objective-C with Cocoa's native PDF support, and sprinkled with some UI magic to help the medicine go down. Boxer uses the standard OS X print panel, so you can print to a PDF file or straight to a real printer. Because Boxer generates actual PDF data, the PDFs you save are fully vectorised and have selectable text.
One of the challenges of printer emulation is that the print workflow in DOS programs is quite different to how we roll these days. Printing in OS X is done in discrete print jobs representing a set of pages or an entire document. But DOS programs squirt text and graphics to the printer line-by-line: they have no notion of a print job, and there’s no formal indication of when they’re actually done printing. This means a human (you) has to decide when the printing is done — and that means you need to be able to see what the printer is doing.
So once the DOS program starts printing, Boxer brings up a live animated print preview showing you what’s coming out of the emulated printer. After the emulated printer has been idle for more than a couple of seconds, Boxer lets you print or discard the pages so far – or you can keep printing more pages to add to the print job. Once you’re ready, hit Print and Boxer will wrap it up as a print job and hand you over to the OS X print panel.
I’ll be honest: the print preview was the reason I implemented this whole feature, because it was a fun design challenge and a way to make printer emulation about me instead. I call this Design By Narcissism.
So when I said back in July that I was taking a break because of real-life commitments, that was a teeny tiny fib. In fact I was beavering away undercover with the fine people at GOG.com to help them launch their DOS games catalogue on Mac.
On October 18th the fruits of our labours were finally revealed, and I can finally gush about what I’ve been working on all this time: Boxer standalone. This is a streamlined and state-of-the-art Boxer built for one purpose: releasing DOS games as individual apps. It's also a peek into Boxer’s future.
When we were figuring out how to deploy GOG.com's DOS games on the Mac, it became abundantly clear that Boxer in its current form wasn't gonna cut it. It sticks you with a folder full of sample games to help you figure out the emulator. Its gameboxes are document files that can’t be played without downloading a separate application. Its emulation is studded with peripheral features to help you install new games and configure them and add new drives to them and all that jazz. The entire app is designed around turning your box of old CDs into a games collection.
But GOG.com are selling games, not raw materials for someone else’s curated emulation experience. Their games already come ready to play, so they don't need any of the features to help you get there. Each game needs nothing but to look and feel like a native Mac game.
So I began macheteing off all the bits of Boxer that weren’t part of that experience. Sample games and game importing were the first to go; the preferences window, inspector panel and drag-drop drive addition all hit the cutting-room floor. The UI was tailored to clean away everything that smelled like emulator infrastructure instead of a native game.
Putting together a game app isn’t as easy as making a gamebox – there’s resources to bundle, app IDs to choose, help links to define, behaviour to tweak, branding to slap on – so I also developed a bundler utility that takes a gamebox and wraps it into an app according to your specifications. It’s not as slick as Boxer’s game importer and it’s not intended for end-users: you’ll need to build it and Boxer standalone from source yourself.
With Boxer’s dead weight liposuctioned away and gamebox-to-app conversion a reality, new challenges came to light. Ones that required exciting and shiny new features.
Boxer’s program panel was designed for one task: choosing the right executable once and never touching it again.
But many of GOG.com’s games don’t have just one true executable: there may be a main game and expansion packs, there may be separate singleplayer and multiplayer options, there may be setup utilities and campaign editors. Boxer’s program panel was woefully inadequate for switching back and forth between different launch options.
Even worse, the program panel insisted on appearing alongside the wretched old DOS prompt, and it wouldn’t even appear at all in fullscreen mode. In a standalone game app, that makes for a terrible user experience.
So I threw it away and started again.
The first time you launch one of these games, you’ll be greeted with a tidy list of predefined launch options. Click an option to launch that program; quit back to DOS, and the app will return to the launch options. (You can also get back to the launch options at any time from the File menu.)
If you quit the app while a program is still running, the app will remember which launch option you’d chosen and start up with that next time. This way, it’s easy to switch back and forth between launch options, without needing to choose one every time you start up.
The launch options panel only appears in GOG games that actually have multiple options. For games with only a single launch option, the game will start up straight away and exiting to DOS will quit the app instead of returning to the launch options.
As you’d expect, inside each game app are all the files for that game. And as you also know, DOS games like to dump their savegames in the same place as all their other program files.
These two facts are on a head-on collision course. OS X apps aren’t expected to be self-modifying: and if you’re not running as an administrator, then apps in the Applications folder are not even allowed to write to themselves. This would prevent you from saving your game and in many cases would prevent the game from running at all.
The solution is one I’ve discussed in the past: write shadowing. Attempts to write to game files are instead written to a ‘shadow’ location inside the current user’s Application Support folder. The app reads changes from there first, before reading the original game files from inside the app. This way noone’s trying to modify the app itself and everyone’s happy.
This has several knock-on benefits:
Dropping OSX 10.5 support let me pull the trigger on a feature I’ve had in my sights for a long time: pixel shaders for rendering styles. Shaders are programmable effects that run on the GPU, and they allow for faster and considerably fancier scaling effects.
The game apps ship with three shader-powered rendering styles: the original untouched output, a 5xBR smoothing shader by Hyllian and crazy46guy, and a simply awesome curved CRT shader by cgwg, Themaister and DOLLS. I cherry-picked these from the thriving BSNES shader community; the coders deserve much love for creating such great-looking shaders.
For older Macs that can’t run pixel shaders at an acceptable speed, Boxer standalone falls back on the old software rendering styles you get in Boxer 1.3.
Naturally, the game apps also natively support those newfangled retina displays.
The game apps are slick as hell, but that comes in exchange for flexibility and features. Hence some caveats:
Each game app has a gamebox inside, so if you prefer you can just run the gamebox in Boxer 1.3.2 instead. However, Boxer 1.3.2 does not utilise the new launch option structure, nor does it support write shadowing: your game state will not be consistent between Boxer and the game app, and any changes you make in Boxer will be saved permanently into the app.
Soon! But there’s still a bunch of work to do before these features are ready to appear in Boxer 1.4:
For now, buy the hell out of GOG.com’s DOS game collection and get the goodies right away. If you don’t mind wet paint and you’re familiar with XCode, you could build Boxer 1.4pre from source and take advantage of all the new features; or even build Boxer standalone and its bundler utility and start churning out your own game apps (some assembly required!)
It's been a huge pleasure to collaborate with the cool guys at GOG.com and big ups to them for choosing Boxer. By doing so, they’ve ensured that their Mac gamers get the best DOS gaming experience across any platform.
My July has gotten a lot more crowded than I expected, and it’s become clear that Boxer 1.4 will not be ready in time for the impending release of OS X 10.8 Mountain Lion. So, I released Boxer 1.3.2 as a stopgap: this has a few minor bugfixes and is Developer-ID signed to be trusted by Mountain Lion's new Gatekeeper system.
I'll be very busy over the next couple of months with Real Life commitments, so Boxer’s development will be quiet for a wee while and Boxer 1.4 may not arrive until later this year. Fear not though, exciting things are on the way!
Boxer 1.3.1 is out now at a browser near you! Release notes are here: I’m afraid this update comprises boring old bugfixes and minor tweaks, with no new features to delight and astound.
1.3.1 is mainly intended as an end-of-life update for users still stuck on Leopard; bye guys! Boxer 1.4 will be along later this month, with a brand-new shader-based renderer and retina display support, ready for OS X 10.8 – and you’ll need Snow Leopard or newer to run it. (Yes, for really reals this time.)
It's been a long time since I last talked about putting Boxer in the Mac App Store. The landscape has changed significantly since then, and Apple’s current policies mean that Boxer’s probably not coming to the App Store – not until the development climate changes, for the worse or for the better.
The main thing is that as of the start of June, all apps submitted to the App Store must now run in a restrictive sandbox environment that curtails the kinds of things an app can do and removes access to certain OS features altogether.
If you follow other Mac developers, you’ve likely read a lot of rants about the ramifications of the sandbox and the kind of things it prevents apps from doing. Here are all the ways (that I know of) that the App Store would affect Boxer:
App Store apps can only access files that are within the app’s own sandboxed filesystem (which is hidden from the user) or to which the user has implicitly granted them access: this by either opening files directly with the application, or by choosing them from a file-picker, or by drag-dropping them into the application.
This restriction would mean:
MOUNT and IMGMOUNT from functioning;App Store apps can no longer open other apps directly, or talk to them via Applescript. This restriction would mean:
App Store apps cannot intercept and handle system-level key events. This restriction would mean:
App Store apps are not permitted to create or download other apps. This restriction would thwart my future plans to make gameboxes into first-class applications of their own.
This proviso is clearly intended to keep out alternative app stores like Steam and Bodega.
App Store apps are not permitted to download or support additional executable code, i.e. plugins. I have no plans to offer traditional plugins for Boxer, but it's debatable as to what actually constitutes a plugin: e.g. whether MT-32 ROMs or additional OpenGL shaders would be counted as plugins by Apple’s fickle review staff.
A case can be made that the Mac App Store terms of use are incompatible with the Grand Ole GPL, which opens Boxer up to being pulled from the App Store on spurious legal grounds. This threat has already been realised on the iOS App Store, where some GPL-licensed apps have been unceremoniously pulled after DMCA complaints from parties with axes to grind.
Compared to some apps, Boxer gets off lightly, and none of these restrictions on their own are dealbreakers for running DOS games: but they would put a dent in Boxer’s ease-of-use, and curtail future development angles, without offering me anything in return besides the increased exposure. Given that I don’t make any money off Boxer, the exposure would bring me no benefit (beyond basking in the glory of more happy users) and it would come with a much bigger support burden attached. Apple's mercurial policy changes would also leave Boxer at the risk of losing further features just to stay in the store once it’s there, or of being pulled from the store altogether at the whims of other people.
It’s very late in the lifespan of an operating system to attempt to lock it down like this, and I’ve heard it likened to putting the genie back into the bottle. Some apps are simply unable to function within the sandbox, and so there has been a miniature exodus of app developers from the App Store since the new rules went into effect. Some high-quality apps, ironically including apps that Apple themselves have promoted, are now laying fallow in the App Store without the opportunity to submit new updates, and many other popular apps will now never be able to join the App Store. It’s possible that Apple will expand the sandbox API at a later point to let some of them back in, but I don’t have my hopes up.
Fortunately Apple seem to be in no hurry to remove your Mac’s ability to run well-behaved software from outside the App Store; they’ve made moves in OS X 10.8 to codify a distinction between unapproved apps that are made by any old rabble, and apps by trusted developers that just could not be distributed in the App Store for whatever reason. This indicates they recognise the ecosystem outside their App Store is still vital to the platform; let’s hope they keep thinking that way.
So there we go! For now Boxer will stay out of the App Store: until Apple expands the range of things possible in the App Store sandbox, or until Boxer evolves to a point where those restrictions are no longer relevant, or until Apple force my hand by preventing 3rd-party apps from running on OS X at all.
Design by 40watt.