Parallels 2.1 beta 5

....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?

Too much confidence is good for you

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...

The repair permissions fiasco

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/.

Apple Technical Briefing: Scientific computing and the Intel transition

[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.

Comrades in OpenStep

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...

Wolf! Wolf!

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....

The age-old problem

"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.

Parallels and OpenStep: success!

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 :-)

More progress on Parallels

Thanks to Christian Brunschen and the other kind folks at UK-nextstep-users, I've got quite a bit further with my OPENSTEP installation. Christian pointed me to a NE-2000 driver which works without issue on the Parallels-installed OPENSTEP system.

Applying Apple's patches was a little more involved - my first approach was to download them on a Mac, create an ISO image (Apple's tools can do this:

hdiutil makehybrid -iso -o OS42patches.iso OS4patches

rather nicely) then put the ISO in the virtual CD-ROM drive. While the tarballs unpacked correctly, the package they contained was corrupt. So I downloaded the patch (OS42MachUserPatch4 being the latest one, containing the SVGA driver and the y2k fixes) to a Solaris box, then used FTP to get it over to the OS4.2 PC (now that we've got network). This was more successful, and the patch could be installed.

So, now we're fully patched, pull out the "Default VGA" driver and put in the VBE (VESA local bus) one, using Configure.app. Let's choose a low resolution for the first boot, just in case; reading Apple's notes, we should be able to check which modes are available and change at boot time anyway. So I've gone for 640x480x8 (i.e. 256 colours) for the first boot... and it hangs here.



This is actually after I typed "VBE Check"=Yes at the boot prompt, and it didn't show a list of modes...so something's not quite right with the VESA driver. I'll leave it overnight in case it decides suddenly to boot, but I think that reverting to Default VGA is, for the moment, the order of the day.

Edit 2006-04-10 17:36 GMT - some history revision, correcting a spelling mistake and therefore pretending I've never heard of visual basic for apps :-)

About NSMailDelivery and Message.framework

I've been asked a few times about the NSMailDelivery class by a few people, probably either through a mailing list post I made, or iSendMail. Well, let's look through iSendMail to see what happens.

Firstly, the iSendMail target includes Message.framework, which is where NSMailDelivery is defined. Now, some clips from the iSendMail.m file:

if([NSMailDelivery hasDeliveryClassBeenConfigured]==NO)
{
//can't send mail...
NSLog(@"Cannot send mail!\n");
[pool release];
exit(EXIT_FAILURE);
}

Before I even try to send mails out, I check whether NSMailDelivery is going to work. The clincher is straightforward: if Mail.app can send an email, NSMailDelivery can send an email. There's no way to configure e.g. a SMTP server programatically (unless you want to delve into Mail.app's configuration, that is); if you want to do this, consider using PantoMIME which is a more complete message framework. NSMailDelivery is just a convenience class for accessing Mail.app's message sending capabilities, nothing more. Launch Mail, open a new message, put a To address in and hit Cmd-Shift-D. If it goes, then you can use NSMailDelivery.

NSMutableDictionary *headers=[NSMutableDictionary dictionary];

while((argch=getopt(argc,argv,"f:t:s:"))!=-1)
{
switch(argch)
{
case 'f':
[headers setObject:[NSString stringWithCString:optarg] forKey:@"From"];
break;
case 't':
[headers setObject:[NSString stringWithCString:optarg] forKey:@"To"];
break;
case 's':
[headers setObject:[NSString stringWithCString:optarg] forKey:@"Subject"];
break;
case '?':
default:
usage();
}
}

Headers are defined in a dictionary. Obviously a To header is a requirement, you could probably get away without a Subject. If I wanted to use Mail's default email address I wouldn't supply a From header (but I'd use a different delivery method, see below); and if I wanted custom X-Mailer: or whatever, I'd do it here too. Any header which appears here will make it into the resultant mail, and any header not listed here will not be inserted for you.

NSAttributedString *attrMsg;
NSMutableString *msg=[[NSMutableString alloc] init];

//...

attrMsg=[[NSAttributedString alloc] initWithString:msg];

The message must be an attributed string, whether or not you actually use any attributes. But unless you choose a send a MIME message, any attribute you do use will be lost, read on...

mailSent=[NSMailDelivery deliverMessage:attrMsg headers:headers format:NSASCIIMailFormat protocol:nil];

if(mailSent==YES)
{
NSLog(@"Mail sent successfully.\n");
}
else
{
NSLog(@"Mail delivery failed!\n");
}

a few things to note about the delivery line. Firstly, observe that all of these methods we're using are class methods, not instance methods; I never instantiate anything from Message.framework. If I hadn't set a From address I could have used +deliverMessage:subject:to: but then could only send an ASCII message (which is all iSendMail does, anyway) and would have had to accept whatever From address was default in Mail.app. If your message atributed string contains formatting information (or MIME attachments :-)) then use NSMIMEMailFormat. protocol may as well always be nil, as your choices are that (which uses the preferred transport protocol, which is SMTP at the moment on Mac OS X) or NSSMTPDeliveryProtocol, which is also SMTP.

So, here's the full system:



Networking is the biggest current issue, and replacing the default VGA display with something better would be useful, too. But it works :-)

Oh, and images of the driver disks are available from Apple.

We're in! The WindowServer has no graphics glitches that I can see, and it's time to configure the devices.

Graphics: default VGA. Play it safe :-). We may be able to do something more fancy, but I'd rather check with Parallels before b0rking my install.

Network: ah. The emulated card is a Realtek 8029(AS), and OpenStep doesn't claim to have support for that. Apparently it's compatible with the NE-2000, but OpenStep doesn't have a driver for that either :-(. I need to ask someone with more Intel-version-of-NeXT noodle than I about that...

Sound: we ignored this for the moment.

SCSI: Nope.

So now we're at the 'installing additional packages' stage, I won't post a screenshot until we're into the OS.

And now, the reboot:



it's been sat there for a while now... :-/

And now the console is up: a few graphics gremlins but the ATAPI CD-ROM driver is doing its business.

Wooo! New blog. For the first few posts, this is going to be about my attempts to get OpenStep 4.2 running under parallels VM for Mac. So far, I've set up the VM and am wading through the release notes and installation guide. I've found that it should be installed without the (virtual) network cable connected, so that's what we do.

Worryingly, the install notes say that we require a SCSI CD-ROM, but Parallels only provides an IDE one. I don't know how that will pan out, I definitely remember one version of NeXTSTEP coming with an IDE CD-ROM driver. Let's see.

OK, so I've got the OpenStep boot floppy up and running (via some failures of NeXTSTEP to provide the necessary device file to dd, and with tremendous thanks to Simon Cozens for lending use of his /dev/fd0), the compatibility BIOS isn't an issue and the installer dutifully loads:



Now to find the drivers disk...