Mac Daddy World

We just finished some marathon coding and are happy to announce iPhoneDrive. In a nutshell, it lets you use your iPhone for file storage by providing an easy file browser interface. Version 1.0 is very functional considering that it was written in about one week. The demo version works just like the paid version but only for a 7 day period.

It supports drag and drop to and from the iPhone. It also supports transfer of entire folders. This makes it easy to move large directories back and forth between your Mac and your iPhone. Since the iPhone uses USB 2.0, the transfer speed is very fast. Now you can put those spare gigabytes to good use. Backup your important files! Your hard disk could fail at any moment! Do it now!

Here’s a screenshot:

Reinventing the Wheel

You can see we used an NSBrowser for the file browser. If you’ve ever tried to use one of these you’d know that they’re not very useful out of the box. Drag and drop has to be implemented manually, and the updating of cell data is very flaky, requiring many work-arounds. Also, they don’t do many of the things that you’d come to expect from the Finder’s column view mode.

All said and done, the interface came out pretty good. I just wish Apple would update NSBrowser to support more of the things found in the Finder column view. Obviously the Finder isn’t implemented using NSBrowser (it’s not even Cocoa for that matter), but it would be nice to have things like elipsification, marquee selecting, and drag and drop in there without having to reinvent the wheel.

We welcome any feedback about iPhoneDrive. Leave a comment here or use the feedback form on the main Ecamm website.

Safari 3 on Windows is old news by now, but I still have this nagging feeling.

Apple has had iTunes on Windows for years, but iTunes is a Carbon app, and doesn’t contain any Cocoa, AppKit, or Objective-C. (A quick analysis with otool will show this.)
I’m not saying that getting iTunes ported to the PC was easy, but it’s not exciting because we don’t write Carbon apps anymore.

Now enter Safari for Windows… Safari is written from the ground up in Cocoa. A quick analysis of Safari will show you that it contains over 200 Obj-C classes and about 4000 Obj-C methods. Its controllers (logic) and views (the UI) are built entirely in Objective-C using AppKit.

Why is this an important fact?

I’m a huge fan of Cocoa and coding using AppKit: I find it makes coding fast and efficient. The only downside? Without a huge nasty porting effort, your code is permanently stuck on the Mac. All of your NSMutableDictionary, all of your NSWorkspace, all of your NSLock, all of your NS-anything. Today, it’s just not leaving your Mac. It’s stuck.

I’d really like to port CardRaider to Windows, but it makes such heavy use of Objective-C and AppKit, that it just seems like a nasty task.

Now enter Safari on Windows. Cursory examinations of the Safari 3 Windows binaries shows no evidence of an Objective-C runtime or any AppKit.dll. So let’s assume for a moment that they didn’t just port the Cocoa and AppKit libraries…
So did Apple really rewrite all 200 Obj-C classes in Safari in C++ or C# and change them to not use Cocoa? Are they somehow going to maintain two codebases, one written entirely in Obj-C based on AppKit, and one in another language and based some other library? Maybe they did… they seem to have done that with WebKit and WebCore….

Or, more likely, do they have some kind of secret button (some kind of tool, script, or compiler modification) that takes Safari’s 200 .m files and makes Windows code.

I’m not trying to trivialize their porting effort, because I’m sure it wasn’t an easy task. I’m just looking at the implications of maintaining two mostly identical versions of Safari 3, one written in Objective-C using Cocoa, and the other not allowed to use those things.

Did they really port this manually? I don’t think so.
otool -ov /Applications/Safari.app/Contents/MacOS/Safari | grep -c Module
202
otool -ov /Applications/Safari.app/Contents/MacOS/Safari | grep -c method_name
4097
otool -tV /Applications/Safari.app/Contents/MacOS/Safari | grep -c _objc_msgSend
20319

I hope for their sakes that it’s somehow automated, and if it is…

Apple: Share the technology!
Give developers the secret button to easily make their Cocoa apps into Windows apps!

Can you think of anything that could do more to encourage Mac development than allowing that code to also be useful for Windows?

But maybe they really did port it line by line, class by class.
If you look at the Windows branch of WebKit/WebCore, all the .m files have become .cpp files and the AppKit calls have become CoreFoundation calls. And it shows no sign of having been automated.
And a lot of the code has clearly been manually ported to Windows code. For example looking at a randomly selected class/routine:

The once graceful:
-[WebIconDatabase iconForURL:withSize:cache:]

has become:
HRESULT WebIconDatabase::iconForURL(BSTR url, LPSIZE size, BOOL cache, OLE_HANDLE* bitmap)


with the underlying NSWorkspace, NSImage, NSMutableDictionary, etc. calls now turned into dirty Windows CreateDIBSection code.