Safe from the Losing Fight

Sorry about the title, I couldn’t resist. All the unnecessary sensationalism makes me feel like a real journalist! Will your porting kit kill you?? Find out at 11 (10 Central)!

Well, theoretically it could. You could be in the middle of a Doom-a-thon when a bug in the porting kit locks up your client, and your ex-best-friend frags you.

Tragic. Just tragic.

Anyway, this new fangled product from TransGaming, Cider, has me interested. From the article over at The Mac Observer it sounds like it uses an “emulation” approach to porting to the Mac.

Its interesting to me because, in my experience, attempting to “emulate” one platform API with another is pretty much the worst way to port anything. The API’s of Mac and Windows aren’t a one to one match, and some comparable technologies have vastly different architectures. That means trying to emulate a Windows API on the Mac might prove to be very difficult (i.e. the Windows model might assume polling, while the Mac model might assume callbacks). It also means trying to emulate certain API’s on another platform might be slow or inefficient. And that’s bad in a game, or so I am told.

Although I have to admit, by limiting the porting kit to games they dodge some of the bullets fired by using the “emulation” approach. Namely, all the UI differences on Mac vs Windows. Games usually have a totally custom UI that is unique to the game, not to the platform. So the porting kit doesn’t have to worry about Windows icons not looking right on the Mac, or controls that exist on one platform, but not the other, or menu items being in the wrong place. Its all custom, so it doesn’t matter.

By limiting the kit to games, it also means they can concentrate on certain API’s. From the Cider FAQ:

TransGaming’s Cider implements common multimedia Windows APIs such as Direct3D, DirectInput, DirectSound and many others by mapping them to Mac equivalents.

Games will probably focus on DirectX and graphics API’s, and probably not so much on, say, CD burning API’s. Which means Cider’s decision to focus on multimedia API’s was a wise one, in a bang for the buck sense.

Of course, if not all the API’s are implemented, what are your options if your product uses one that’s not supported? Well, you could change your Windows’ code to use a different, supported API. But that’s no fun, and may not even be feasible. You could also just switch directly to using Mac API’s and #ifdef your code based on platform. But that means you don’t get one codebase, which is one of the things TransGaming touts. It doesn’t sound like you’ll actually get the source to Cider, so implementing the Windows API on the Mac might not be an option. From the Cider FAQ:

Cider works by directly loading a Windows program into memory on an Intel-Mac and linking it to an optimized version of the Win32 APIs.

It certainly sounds like they’re handing you a DLL you link in, and you pray that they implemented all the right API’s, and in the right way. If you were depending on an obscure side effect (in a Win32 API? Never!), and they didn’t implement it, you’re kind of screwed. Or if, heaven forbid, there was a bug in their implementation. Of course, TransGaming might fix it for you, for the right price.

If they’re handing you a black box DLL, I wonder how big it will be. In my experience, “emulation” porting layers tend to be pretty thick as far as code goes, so it could be a large DLL. If you have the source code you could hand optimize out the functions you don’t need, or even let the linker do that for you. I doubt TransGaming would like to be giving .NET a run for its money in terms of download size.

The other interesting thing about Cider is that it seems to be derived indirectly from WINE. From the Mac Observer article:

Cider shares the same core technology as Cedega, which has its roots in WINE but branched from that technology in 2002.

This is interesting because WINE is covered under the LGPL. I know LGPL isn’t as strict as the regular GPL, but doesn’t it still mean someone should be opening up their source? I also wonder about the legal implications of the ported game. Perhaps I should leave that question to the GPL experts and to the law talking guys.

Although Cider might surprise me, it doesn’t sound like its all its cracked up to be. Emulating an API is a poor way to port an application to a platform, even for a game. I truly wonder if they can pull off the performance they say they can. I also wonder how many games will be ported as easily as they imply:

TransGaming works with the game developers and publishers to optimize the game for Intel Mac but this process takes hours to a mere few days.

That prediction only seems plausible if the game is using the API’s that Cider supports. If not, then things will take a lot longer. They also seem to be forgetting about testing. The Cider porting kit isn’t Windows, even if its trying real hard to be. The game code might be the same, but the OS/porting kit code isn’t. You’ll have to spend time testing on the Mac as well.

Of course, this doesn’t keep their Founder/CTO, Mr. State, from being cocky. From the Mac Observer article:

Mr. State said: “We imagine that they[the traditional porting companies] are re-evaluating their business models. Our technology does revolutionize how games are brought to the Mac, which we believe will result in a paradigm shift in the Mac game publishing landscape.”

I don’t know Mr. State. I’ve used and maintained “emulation” porting kits before, and even with the source they’re very hard to make work, and make work well. I don’t think anyone is re-evaluating their business model until Cider is proven.

Spotlight has to be one of the most unused technologies on my computer. Its not that I don’t need it — I need to search for things all the time. Its not that the idea behind Spotlight isn’t sound, it is. It makes a lot of sense to index files and make them available for a quick search.

The problem is it doesn’t work.

First, its slower than Christmas in Tehran on my machine. I’m not talking about the “indexing” time that I see a lot of people complaining about. I actually rarely see it indexing. However, on the off chance I try to do a search, it brings my machine to its knees, and its a Dual 2 Ghz G5 with a gig of RAM. The Finder locks up until the search is done and sometimes the disk activity it generates is so intense my whole machine locks up temporarily. I would assume its just this machine, but it happens on my PowerBook and my iMac/Intel as well.

I don’t get it. It always works for Steve.

And Lord help you if you use that stupid widget in the top right of your screen. Good grief. You’d better hope that the ten results it happens to show there are what you’re looking for (and they’re not), otherwise you have to open a real Spotlight window to get all the results. That means Spotlight has to run the entire query all over again, disk thrashing and all. Its the model of efficiency, that Spotlight.

The other thing that’s wrong with search in general is it just tells you that your search term is somewhere in a given file. There ought to be a way to then double click on the search result and have the application open up to where the search result is. But perhaps that’s just a distant dream.

Of course, the only reason I even tried Spotlight is because Xcode search sucks so badly. It only wants to search the current project, and even then only the files in the actual project (not included files). Sure, Apple has added all kinds of options to the Find dialog, and maybe one day they’ll add one that makes it useful. Until then, searching an arbitrary folder is one of the most painful experiences within Xcode (and there are a lot). Here’s what you have to do in Xcode:

1. Command-Shift-F to open the Find in Files dialog.
2. Press the “Options” button to get the Find Options dialog. (Why are these in a separate dialog?!?)
3. So you don’t overwrite one of Apple’s precious predefined sets, press the “Add” button.
4. Type in a name for your set and hit enter.
5. Press the + button at the bottom and add the folder you want to search. (Also remove any left over folders from previous sets you don’t want.)
6. Check the “Search in files and folders” box. (Why do I have check this? I just added a folder, isn’t it obvious what I want to do??)
7. Uncheck “Search in open documents” and “Search in open projects.”
8. Close the Find Options dialog and/or go back the Find dialog.
9. Select your new Find set from the set popup.
10. Type in the search term(s) you want to find, and press return.

Yes, in those short ten steps, you too can search for something in an arbitrary folder!

The problem is these stupid find sets that I have to create are there to increase flexibility. Undoubtedly, the engineer who created that whole mess thought “Think of the power and flexibility I’m giving the user! They can search for anything in any way they want! Having them save find sets means all the find options are nicely encapsulated!” But the problem is I don’t want flexibility, I want speed. And I don’t mean raw search speed, I mean speed of entering in my search criteria and having Xcode find it. When I’m looking for something, I’m in a hurry. I don’t have time to create one of your stupid Find sets, as architecturally nice as they might be. I’m sorry, ten steps to do anything is too many.

At the very least Apple should merge all the options into the Find dialog. And don’t force me to create a stupid find set. They could also add a default set that searches $SRC_ROOT.

The truth is I still keep CodeWarrior around, just so I can use its Find in Files dialog. It has a nice popup of all the previously searched in folders, or text field I can type the path into, or a browse button which I can use to go select the folder I want, all from the Find dialog. Apple, if you want to know how to make a decent search, look no further than CodeWarrior.

I hate searching on my Mac. Granted, I don’t have a dog asking me retarded questions, but its always a painful ordeal. It doesn’t have to be. The technology is there, but they need to run it through some usability specialists or at least a couple of real users.

For those who don’t know, I’m a partner at Order N Development. We do a lot of contract work, and among those contracts is doing the Mac porting of SereneScreen’s Marine Aquarium.

Recently I came across the blog of one Phill Ryu, who attempted to rank the ten best screensavers for Mac OS X. I say “attempt”, because obviously he failed. Despite all the hard work I put into it (well, technically it was Jim who did the “work”), Marine Aquarium was only ranked number two.

Clearly this contest was rigged from the start. The upstart “Fenêtres Volantes” took first place with its cheap French name and obvious payoff. I’m no expert, but there’s no telling how much money was made by the author off this so-called “freeware”, whatever that means.

This called for an investigation. I dug into the past of this Phill Ryu, if that’s his real name, and discovered he has a blog and likes to rank screensavers. It was obviously a cover for something far more sinister. What, I don’t know, because I lost interest after seeing all that shiny plastic over at MacThemes. I’m not sure who runs that site, but maybe they should be the ones ranking screensavers. They sure do know what looks like plastic.

I also take offense to the characterization of Marine Aquarium in the review. Its hardly “an oldie” as Phill suggests. I mean, you don’t hear geriatric radio stations playing The Marine Aquarium, do you? I thought not. Its usually something by The Beatles or Elvis. Phill also suggests that you cannot “touch” Marine Aquarium. Hooey. I caress my monitor all the time when its running. The fish like that. It reminds them of the time they were in the dentist’s office.

Finally, Phill implies that $20 is a steep price to pay for a screensaver. Oh, like all the other guys give it away for free? psh. Listen, Phill, web site hosting isn’t free, and I have to have some place to mock your hard work. So there.

(BTW, if you do decide to buy Marine Aquarium, please do it from our website. I get more money that way.)