Structure and Interpretation of Computer Programmers

…goes to printing on OS X Server. You’ll notice that you can add or remove printers via Server Admin: however, if you do add one via that route then the system will try and get the printer to emit its PPD at it. If the printer doesn’t do this, then it’s a "Generic Postscript Printer" and there’s no way to change that.

Unless, of course, you log in at the console (Xserves make that so easy and snappy to achieve) and use the same Printer Setup Utility you’d otherwise have used on the client OS. You can then go back into Server Admin to set up whether a queue is quotad, set up sharing and so on.

Great, so far we’ve used two apps to configure our printer. Let’s just add a third (although this does make sense), because you now have to go into workgroup manager to set up the per-user quotas for the print queues. Fine, and while we’re here we’ll use managed config to define which printers appear in which print panels. Only, we can’t. Shared printers can’t be added to the MCX print menus…even if they appear in my print menu.

This is so confusing it’s almost fun…

I was once told by a local Human-Computer Interface luminary (who claims to have in-depth knowledge of the way NeXTStep’s UI works) that it’s not possible in any existing GUI to have lines connecting separate windows.
Allow me to introduce a decade-old piece of scotch mist.

….will no longer boot OPENSTEP successfully, as far as I can tell.  At least, OS4.2 hangs out, in trying to load the VBE driver.  Reverting to Beta 4 works though.

If anyone has different experiences with Beta 5, could they comment here?

So, Sun have a new CEO in the shape of President and erstwhile COO Jonathan Schwartz.  Schwartz joined Sun back when they acquired Lighthouse Design, a NeXTSTEP applications developer with an office suite for the platform.  Having slightly more bravado than sense, I sent this:

Hi Jonathan, I hope you do not mind receiving unsolicited personal mail.

Congratulations on your appointment as CEO of Sun.  Perhaps now would be a good time, in the spirit of openness and interoperability that Sun is famous for, and in extension of the success of the OpenSolaris project, to revisit that Lighthouse Design code in the basement with a view to releasing it under an acceptable open source licence?  Would you be able to also open up the source for Sun’s OpenStep implementation, as a reference for Cocoa and GNUstep developers to see how it’s done?  So doing would give Sun lots of ‘good faith’ points among Cocoa developers on the Mac platform, and further Sun’s position at the front of the 21st Century’s open source-centric software market.

By the way, Cocoa really is a great application development platform (as I’m sure you know with your OpenStep experience), and the combination of Apple’s UNIX workstations with Sun’s Solaris UNIX servers, both sporting a coherent and consistent Cocoa-based application stack and development environment would truly be a wonder to behold ;-).

Regards,

Graham.

I expect precisely nothing to occur…

So, I’m far from the first to discuss the voodoo surrounding repair permissions, but I’ve never seen quite such a flagrant violation of penal code 1984 (It is a felony to pass off your own sloppy programming as a user configuration issue)…

Yesterday I bought some software from the Apple store (the developers and software shall remain nameless, but suffice it to say that it was an expansion pack for a game).  Came home in order to install it, that didn’t quite work…I’d installed a (n official) patch for the original game, making its version newer than the version in the expansion pack.  OK, blow it away, and reinstall.

The installer is a PEF-based Stuffit thing (I didn’t realise people still used either PEF or Stuffit), so doesn’t know anything about the Authorisation Services API.  OK, switch to an admin user, run the installer.  Switch back to regular user, and run the game.

Erm, no in-game text.  On any of the UI elements.  That’s a bit strange.  Let’s check the FAQ on their website; apparently there’s a particular file in the game which contains all of the text, if that’s corrupted then no text.

It’s not corrupted, it’s just unreadable by anyone except the user I installed it as. Quick su-chmod-exit, try again. OK, in-game text. Asks for the licence key. Enter it, gets accepted….asks for the licence key. Enter it, check it, gets accepted….asks for the licence key. Couple more times, checking really carefully now that I’ve entered the correct key (no acc1d3nt4l el1t3ne5s). Definitely doesn’t work.

Back to the website FAQ: I find the file where the licence key gets stored. In the app directory. Guess who it’s not writable by? That’s right, anyone…turns out that savegames get stored there too. So the application dir has to be writable by anyone who might want to play the game. Erm, that kindof sucks.

So I wrote to the company, explaining what I’d found, and got this response:

The fact that the game couldn’t write to the nwncdkey.ini file probably means that OS X is having some sort of file permissions issue on your Mac. You might want to boot to your OS X CD, run the disk utility, and run “Repair Disk” and “Repair Disk Permissions” on your hard drive.

Repeat after me: WTF? Their software is installed by a Stuffit installer, not by Installer.app – this means there’s no BOM, so there are no known permissions pertaining to that directory as far as the OS is concerned. If they got the permissions wrong on the way in (not unlikely, a number of my user accounts on various systems have custom umasks, and I bet Stuffit doesn’t check that) then Disk Utility isn’t going to do anything to fix their mistake. For completeness I ran a verify perms check, and indeed nothing came back (well yes something did, in a different area of the filesystem: I had myself chmodded an area of /Developer but last time I checked, Carbon games don’t make heavy use of the developer documentation). But the Cult Of Mac is strong, and its idols shall not be slighted, so running repair permissions is obviously the fix in this situation. Perhaps I should zap the PRAM, start with extensions off, rebuild the Desktop and sacrifice me a goat while I’m at it.

I’m going to write "a polite response" to this particular company’s support desk, explaining how repair perms works, why perms errors (in the BOM-perms-don’t-match-filesystem-perms sense) were not – could not have been – the cause of my issue and requesting that they switch to an installer platform which, well, understands the Mac OS X filesystem. And that they start writing user-specific data like savegames and so on into ~/Library/Application Support/.

[Title link goes to my Oxford homepage, where you can grab a PDF of my slides and notes]

So yesterday was the UKUUG/Apple tech briefing on the Intel transition. Talking to Eric (Albert, Apple Core OS group) and listening to his talk was very interesting, and gave me new and unexpected insights into the whole business of the transition.

Essentially, the fact that [[NeXT|OPEN]Step|Rhapsody] was already ported to Intel platform hardly helped at all. Or maybe that should be "what Apple did to support the Intel port hardly helped at all", though whether they were right or wrong to use it as they did is not the subject of this post. The reasons are manifold, but largely come down to the fact that technology’s moved on.

Porting a UNIX – especially Mach, which has been seen on so many architectures already – to a new platform these days is a trivial exercise, with a small team of engineers who know the platform well you could probably get up to single-user mode in a couple of days, and have a multi-user networked platform up and running in a matter of weeks. Apple pretty much went back to the starting blocks on the OS X Intel port, because so much of the existing Intel port was obsolete. Even Darwin/x86 (as was) didn’t help here, because although Darwin/x86 and "the Darwin in Intel OS X" target the same architecture, they’re different operating systems on different platforms. None of the existing IOKit drivers are for hardware that’s contained in an Intel Mac (in fact, OpenStep/Rhapsody didn’t use IOKit at all, let alone the fact that no-one wrote an AirPort Extreme driver for them). The processors which OpenStep and Tiger target are completely different – for instance, Tiger doesn’t hit the floating point unit at all but instead uses the vector engine’s floating point support; this effectively means compiling for a different CPU. Even the bootloader has to be different, to speak with EFI instead of the legacy BIOS.

But that’s only part of the problem, it would seem that the higher-level APIs have nothing to gain from older Intel ports either. OK, so OpenStep was designed portable (and largely OS-independent too, but that’s another matter) from the ground up, but Cocoa just ain’t OpenStep. Or rather, Cocoa ain’t just OpenStep. As well as supporting new classes, and the bindings/CoreData stuff, implementations of the OpenStep APIs have been rewritten over the years such that the fact that Yellow Box runs on Intel doesn’t mean that Cocoa will. A specific example, and one I particularly liked, which Eric used was that of NSString/CFString, which now (sometimes) uses UTF-16 as its internal data representation. As does whatever type passes for a text representation in the Carbon world. This is nice, except that when Apple first implemented the UTF-16 support, it seems that some of the people forgot to check for endianness, and some other of the people deliberately ignored endianness (i.e. most UTF-16 is bigendian anyway, and we’re running bigendian cough, let’s assume it’s all bigendian). Bring that representation over to the Cocoa/Intel API, and interesting and humourous results can occur. So you end up having to reimplement NSString anyway. It actually turns out that Carbon (at least, the Carbon API itself; apps are a different matter) can be easier to deal with than Cocoa, because there you just assume that any data you have control over has historically always been bigendian, and you treat it appropriately.

Anyway, it turned out that the amount of time spent on porting Cocoa and porting Carbon, including all the respective applications, was more-or-less the same. Which I find surprising.

I see someone else is also using OpenStep/Parallels/Mac/i386; let’s hope we don’t start outstripping OS X usage :-)

N.B. slides from today’s Intel talk coming soon…ish…

In describing the Apple/UKUUG tech briefing on the Intel transition, MacWorld describe the secondary speaker as “Oxford University Unix expert Graham Lee”. Let’s hope no-one finds out until I’ve managed to start the motor….

“To configure your network card, please download our drivers from this website”

That’s a bit like the experience at the moment, getting the NE2K driver for NeXTSTEP onto a Parallels-running installation.  Never fear, for I have created NE2k driver floppy which can be used in Parallels.

Edit 2006-04-13 12:03 GMT – changed the download URL, once I remembered how small my bandwidth at SDF is.

Just turn off VT-x extensions for the host CPU in the VM’s configuration (you’ll find this switch in Options -> VM Flags -> Emulation Flags).  Now the system boots fully, in any of the VESA modes that I’ve tried :-)