The promise of Cocotron is a big one. Wrote a Cocoa app? Just add a new Xcode target, hit compile and out shoots a Windows version. Your mountains of Objective-C code now cross compiles and is no longer stranded on the Mac. You put your feet up, having just shipped a Windows app without ever touching a PC. Your cat brings you a freshly brewed cup of coffee. Read on for our journey from app to exe.

The Goal

Back in August, we decided that we should have a Windows version of our FileMagnet Uploader, a Mac application which connects to the iPhone via Bonjour and moves files back and forth between the desktop and our FileMagnet iPhone app. If you’ve been in this situation before, you know how much fun a line-by-line Windows port can be. Not only do you have to spend weeks hunched over Visual Studio, re-writing your entire program in a different language, but when you’re done you now have two separate code bases to manage. When a friend recommended that we check out Cocotron as an alternative, we were quite skeptical but agreed to try it out.

The Proof

Skip forward two months. We are now shipping a Windows version of our FileMagnet Uploader, built completely with Xcode from the same source files as the Mac version. Visual Studio was never opened. But wait… 2 months?

The Details

Let’s back up a bit. What is Cocotron? I’ll quote from the website:

“The Cocotron is an open source project which aims to implement a cross-platform Objective-C API similar to that described by Apple Inc.’s Cocoa documentation. This includes the AppKit, Foundation, Objective-C runtime and support APIs such as CoreGraphics and CoreFoundation.”

In addition to this, you get a modified version of the gcc toolchain, allowing all this to be done from your Mac. The project has an MIT License.

It’s important to point out that Cocotron is targeting more than just Windows. All of the platform specific code is nicely abstracted using a bridge pattern. The Foundation project is implemented for linux too.

Cross Platform?

Let’s back up even more…

Get a couple of Mac software engineers together around a table of Chinese food and eventually they’ll start to debate the best way to do a cross-platform app. Usually, the nicest results come from using a combination of a cross-compiling core and platform specific UI code (a la Safari, Skype, PhotoShop, etc.) Anyone who’s tried to use most cross-compiling UI libraries knows that eventually what you end up with is an app that’s ugly and unruly on both platforms. At least with Cocotron, you end up with a beautiful Mac app, and hey, Windows apps are kind of ugly anyway so there’s no loss there.

Cocotron’s potential usefulness extends beyond user interface. It also includes a reimplementation of the Foundation framework. Foundation provides the powerful data structures, string handling, threading, I/O, etc., which is what makes Cocoa great for rapidly and robustly coding an app’s core logic. It would be a shame to have to use C++ for an app’s core instead of Foundation just because you need it to be cross platform. I can imagine a cross platform app which combines an Objective-C core (using Cocotron’s port of Foundation) with separate Mac and Windows native UI implementations.

Back to Cocotron

Simply follow the instructions to install Cocotron. Now, eagerly add the new Windows target to your Xcode project. Now, hit compile. Now, wait while the errors pile up like fan-boys at the Apple Store on a release day.

What’s wrong? Whoops! It turns out that your app isn’t only Cocoa after all. Okay, I’ll wait here while you go and #ifdef out all of that Mac specific code. That’s right… go find all the Carbon and other Mac-only routines (any Frameworks you’re using outside of Cocoa, such as AddressBook, CoreData, IOKit, CoreAudio, etc.) You’ll have to figure out how to port that stuff later.

Once your app is compiling, you’ll quickly realize that some methods appear at first glance to exist, but are actually just stubbed out for future implementation. Ever want to implement a Cocoa class method? Here’s your chance!

The Reality

The majority of Cocotron is spot-on brilliant, but here are some examples of the kind of things that we did to get FileMagnet up and running on Windows:

• Added unicode path support to the NSFileManager class.
• Added support for displaying truncated strings.
• Added support for drawing unicode strings. (Not very pretty support.)
• Fixed some issues with the NSSocket implementation.
• Worked around or fixed a number of UI bugs. (It was similar to trying to get a Cocoa UI to look right in both OS X 10.4 and 10.5.)
• Since Cocotron is not a complete implementation, we had to implement some methods ourselves, filling in the Windows implementation of the required Cocoa routines. A few examples:
– [NSPropertyList dataFromPropertyList:] (for binary property lists)
– [NSImage TIFFRepresentation]
– [NSFileManager subpathsAtPath:]
– [NSWorkspace iconForFile:]
– [NSMutableString replaceOccurrencesOfString:withString:option:]
• Additionally, Ken posted a few issues/requests to the Cocotron Google Group, and the team responded amazingly fast; they even implemented some functionality that we needed.

Now that the app has shipped, we’ll be merging our additions and fixes back into the Cocotron project as soon as possible.

The primary shortcoming of the Cocotron project may be the lack of a flagship product to drive the effort. It became apparent once we started the port, that the creators weren’t actively using it to create a shipping application. For comparison, take the Cappuccino project. They’re drinking their own Cocoa by using their new framework to make the awesome 280 Slides presentation tool. Cocotron desperately needs something in this vein to flush out bugs and unearth crucial but missing functionality.

I’m a PC

It’s true that we do build our app from Xcode, but we still needed to have Windows around for actually running, debugging and testing the app. However, in this day and age you don’t need to hop to a different machine. We simply used VMware Fusion.

One unexpected bonus was the ability to do source-level debugging of our Cocotron app. The website provides detailed step-by-step instructions for installing Insight-GDB. Once it’s all set up, just one click has you stepping through your Objective-C code on the Windows system. You can even step into the Cocotron framework’s source. (Don’t you wish you could do that with Cocoa?)

Also, I should point out that Windows users expect an installer, so you still do have to sit down on Windows and figure out how Windows installers and code signing work. Finally, don’t forget to struggle through Vista compatibility. Our app didn’t exactly work like a dream the first time we tried Vista. In fact, it didn’t even install.

Cocotron Evolution

Today we asked Cocotron co-creator Chris Lloyd about what the team has in store for us:

“Cocotron development going forward will continue to focus on the needs of developers who use the project. This will revolve around completion of the existing frameworks and the addition of more frameworks. Some of the larger pieces under active development are a complete high quality Quartz 2D (CoreGraphics) rasterizer, AppKit support on Linux via X11 and a Windows cross-debugger which works with Xcode. There has been interest and some work on CoreData so hopefully we can expand on that component too. The more people use it, report bugs and submit patches the better it will become.”

It’s amazing what this team has been able to accomplish, and it sounds like they’ll continue to crank out new goodness.

In Conclusion

Good stuff, but be prepared to roll up your sleeves and join in the fun! But as Geordi La Forge would say, you don’t have to take our word for it. Try it out yourself! Our next Cocotron adventure will be a breeze now that we’ve fought through the jungle and know just what to expect. Expect it to work, but don’t expect it to be super fun.

In the spirit of the contest, we procrastinated until late Thursday afternoon and hatched a plan in a Starbucks-fueled brainstorm. (The employees at Starbucks are thoroughly convinced that we have no job.)

We had some Core Location-related ideas, but they would have involved lots of running around Chicago with iPhones, and since Wolf had given explicit permission to deviate from the theme “if the hack was cool enough”, we decided not to go the Core Location route. Once we came up with the stupidest idea on the planet, we headed out to buy Radio Shack’s last four remaining infrared LEDs and some tiny calculator batteries.

Six hours later, we had our hack ready: Using the WiiRemote.framework and some Apple sample code, we created a Mac app which could track infrared light sources using a Bluetooth link to a Wii Remote to draw colorful lines on the Mac screen. We also added an HTTP server using Cultured Code’s Simple HTTP Server Cocoa project. We then created an iPhone application to send HTTP requests to the Mac via Wifi. These requests controlled what kind of “artwork” would be generated by the Mac application. (Line color, thickness, etc.) As a finishing touch, we taped the infrared LEDs and batteries to the front of the iPhone. This allowed for a “digital whiteboard” effect. By pressing button on the iPhone’s cool UI and waving it around in a drawing motion, we were able to paint designs in the Mac program.

Friday was something of a blur and no work happened on the hack. I think I signed up for Twitter at some point. Tweet.

Saturday afternoon, we decided that we needed a “clincher” feature. A new mode was added to the application (using a UITabBarController of course) which allowed for the positioning and stamping of image files. We also added iPhone X-axis accelerometer data to the mix to allow for rotating of the stamped images by simply twisting the iPhone.

The next 24 hours was spent trying to decide what images we would use. We finally decided on Ken and Glen heads, tinfoil hats, nose glasses and fake moustaches, inspired by Josh and Dave’s Mr. Shuffle app, and the “paranoia” theme.

After spending Sunday morning in Photoshop lassoing fake moustaches, the live demo was a complete disaster. We positioned the Wii remote too far away from the Mac for the Bluetooth link to function, and our iPhones randomly jumped from out of our ad-hoc network to the conference network midway through the demo. Much awkwardness was twittered.

In the end, we somehow managed to take first place. Thanks for your votes, and thanks to all of the companies who donated software and t-shirts!

Here’s the source (875k) for our hack including Mac and iPhone projects. You’ll need Xcode 3.1, iPhone SDK and the WiiRemote.framework if you would like to build it. You’ll also need infrared LEDs… and tape…

Known issues: HTTP did not prove to be the best way to send rapid-fire requests from the iPhone to the Mac. The iPhone’s HTTP request system seems to freeze up if we send requests too quickly. Also, the IP address of the Mac server is hardcoded into the iPhone app for extra credit laziness.

One more thing: This code was mashed together in a few hours, and just barely. It contains some nasty bits and should not be used as an example of proper or efficient Cocoa programming!

So will anyone actually try this themselves? Let us know if you do!

Actual Program Output

Use your iPhone’s camera as a wireless Mac webcam! Stream video over Wi-Fi to any Mac video application such as iChat, Photo Booth or Skype.

Some History:

After the C4 Iron Coder contest where we made the video conferencing iPhone app, we put down our iPhones and got back to writing Mac software for the rest of year. Nobody knew, and we still don’t know, what the future of these iPhone apps would and will hold.

Last week I had a strange urge to get back on the iPhone again and solve some problems that had left us stumped this summer. More specifically, I wanted to get streaming video from the camera. (If you remember our video demo at C4, the frame rate was quite low. This was because, under the strict time limit of the conferece, we weren’t able to grab from the camera any faster than a frame or two per second.)

Meet iPhoneCam:

Click to download a recording of an iChat video conference where I demo it to Glen.

I figured it out: Now we can stream at up to 30 fps. My proof-of-concept is an iPhone app which streams video over Wi-Fi to a video driver component on the Mac. This way, you can use the iPhone’s camera stream in any Mac video program like iChat, Photo Booth or Skype.

Using iChatUSBCam (so that iChat can see non-iSight video sources), I did a video conference with Glen to show him how it looks. He recorded it with Conference Recorder so that we could share it on the blog. You can download a demo video here.

But I haven’t gotten to the clever bit yet.

The Clever Bit:

The iPhone app and the Mac component find each other using Bonjour (zeroconf). There’s absolutely no configuration necessary. If there’s an iPhone-based camera available, the Mac finds it and uses it automatically. Glen had the idea to see if Bonjour could be used, and we noticed that IDMResearch had already provided a nice wrapper around CFNetService.

FAA: (Frequently Answered Answers)

A: No, it only streams video.

A: No, it’s only for Mac users.

A: iPhoneCam is not yet available to download. We’ll have something for folks to try soon. Stop by our booth at MacWorld Expo and maybe we can give you a live demo!

This Mac app will work on any iPhone or iTouch (no hacking required).

Instructions:

1. Have a Mac.
2. Download: Caption Crunch.
3. Run the app.
4. Connect your iPhone or iTouch.
5. Enter a message.
6. Click “Set Message”.
7. Your iPhone will say “Restore in Progress” and may or may not reboot. Wait for it.

If it doesn’t work, just try again. You can always go back to showing the time using the other button.

Download: v1.0: Caption Crunch (340K).

Update: In response to a user request, we’ve built an alternate version that changes the carrier string (e.g. AT&T) instead of the time. Here’s the link: CaptionCrunchCarrierString.zip (344K).

DISCLAIMER: This is just for fun and completely at your own risk. It’s unlikely to cause any problems, but if it does, we won’t be able to help.

Before I was even finished coding this feature, I already knew I couldn’t live without it. Glen used more explicit terms; something leading to him and the new feature having babies.

In short, you can see unread counts for any mailbox or folder up in the status area, and a simple click on the indicator pops open Mail.app and brings up the right mailbox. This was a requested feature from DockStar fans. (We get a lot of our best ideas from customers.) It’s not limited to unread counts either: You can set each indicator to count flagged messages, total message counts, and even monitor Smart Mailboxes.

This upgrade brings many new features for Leopard users. If you use To Do items in Mail.app or Calendar.app, you can use DockStar to monitor the number of incomplete To Dos. You can also count Notes or even keep track of unread RSS feed items.

The DockStar Dashboard Widget also got some improvements. You can now click on the widget to jump right into the relevant mailbox.

If you’re a serious emailer, and you’ve never tried DockStar, you should try the free trial, but be warned: Afterwards, you won’t be able to live without it.

Input Manager plugins are now commonly used as a quick and easy way to make plugins for any Cocoa app. At Ecamm, we use a single simple Input Manager, which loads any of our plugins that you have installed such as DockStar, iGlasses, or Call Recorder into their appropriate applications.

The Mark Twain Effect

We received a lot of emails in the months leading up to Leopard with people asking, “Hey, I heard Input Managers are not going to work in Leopard. What are you going to do?” I don’t know where they heard this, because at no point in the many Leopard pre-releases did Apple completely remove Input Manager support. In short, rumors of their death were greatly exaggerated.

We worked our butts off and on October 26th, when the final release of OS X 10.5 rolled off the factory floor, all of our Input Manager-based plugins were ready for Leopard and working quite well.

The Truth About Input Managers

So what’s the deal, what are we doing about it you might ask?

In response to security concerns about InputManagers, Apple decided to place a whole slew of new restrictions on whether or not to allow them to load into apps. These restrictions are very briefly summarized in the 10.5 AppKit Release Notes, and I’ll excerpt that here:

1. The valid installation is now restricted to the /Library/InputManagers folder only. Bundles in other locations are silently ignored.
2. All the files in the bundle and /Library/InputManagers folder itself must be owned by the root user and admin group. No files inside the bundle can have group or other write permissions.
3. Processes running with the root privilege (getuid() == 0 or geteuid() == 0) cannot load any bundle input manager.
4. Processes running with the wheel group privilege cannot load any bundle input manager.
5. The process must be in the active workspace session at the time of loading the bundles.
6. The process must not be tainted by changing user or group id (checked by issetugid()).
7. No 64-bit processes can load any bundle input managers.

So what does it all mean?

Let’s go over each restriction in detail:

1. The valid installation is now restricted to the /Library/InputManagers folder only. Bundles in other locations are silently ignored.

On 10.4 and earlier, Input Managers can be installed in the root Library (/Library/InputManagers) or your user Library (/Users/[your user]/Library/InputManagers). If there is an Input Manager with the same name in both places, it completely ignores the one in the root Library and uses the home Library instead.

On 10.5, only Input Managers in the root Library are allowed to load. However, if there’s an Input Manager with the same name in the home Library, it will ignore the one in the root Library and load neither.

Ecamm’s Input Manager has always lived in the root Library so this change did not affect us. Additionally, because people sometimes manually move stuff around, our installer has always zapped any Ecamm Input Manager it finds in the home Library.

This change requires all Input Managers be global (affecting all users). There’s no longer any way for developers to provide the option to install only for the current user. This will be a real pain for unprivileged users, as they will no longer be able to install Input Managers without an admin password. We did have a customer who is an instructor, and uses Call Recorder in a locked-down computer lab environment. We had helped him install Call Recorder in the user Library. This will no longer be possible, at least not possible using Input Managers.

2. All the files in the bundle and /Library/InputManagers folder itself must be owned by the root user and admin group. No files inside the bundle can have group or other write permissions.

In 10.5, every file in an Input Manager plugin’s directory is recursively checked to make sure they meet these ownership and permissions requirements. Additionally, the InputManagers directory itself must meet these same requirements.

In a pinch, the following commands can be used to fix ownership and permissions of the InputManagers folder:

sudo chown -R root:admin /Library/InputManagers
sudo chmod -R go-w /Library/InputManagers

As of their latest versions, the Ecamm installers automatically fix permissions and ownership.

This requirement was the main hurtle to getting Input Managers working on Leopard, but it makes sense to have these requirements if the goal is make this all safer.

3. Processes running with the root privilege (getuid() == 0 or geteuid() == 0) cannot load any bundle input manager.

This one is pretty self explanatory as they’ve given the code they’re using to make the check. If getuid() == 0 , it means you’re logged into your Mac as root. I’m not sure why someone would do this or if it’s even possible. geteuid() == 0 would indicate that the process is running effectively as root (e is for effective). A process is running effectively as root if you run it using sudo, if it is started programmatically using AuthorizationExecuteWithPrivileges, or if it’s running with the setuid bit.

This requirement seems like overkill. The Input Manager has to be owned by root per #2, so why can’t root run its own plugin? Oh well, no big deal. This keeps Input Managers out of sketchy places like loginwindow.

UPDATE: We’ve had a handful of users with all their apps running with geteuid()==0. We don’t yet know why it happens.

4. Processes running with the wheel group privilege cannot load any bundle input manager.

In 10.5, the process’s primary group cannot be wheel (wheel is the name of the root group, gid == 0). Both getgid() and getegid() are checked for 0.
Additionally, the process owner’s supplementary groups are checked for wheel.

This last bit is the one that caught us off guard. We eventually determined that a handful of users who reported problems getting our plugins to load were actually failing this requirement. Their main admin user was a member of the wheel group! This situation is most likely the result of migrating a user account forward from OS X 10.1 (Puma) or earlier, where all admin users were added to the wheel group by default.

If our installer finds that the current user has wheel in its supplemental group list, it simply removes it. Because of the way Cocoa is checking the supplemental groups, a full reboot is required before the change takes effect and Input Managers will load.

5. The process must be in the active workspace session at the time of loading the bundles.

Having an inactive workspace session means that your user is currently switched out via “Fast User Switching”. Fast User Switching allows user B to login without making user A, who was already logged in, have to quit all his programs. It’s then possible to quickly switch back and forth between the two users.

Since Input Managers load when an application starts, I’m not completely sure how an application can start while a user is switched out or what the implications of this are. Anyone have an idea?

6. The process must not be tainted by changing user or group id (checked by issetugid()).

issetugid() makes sure that neither setuid nor setgid have been called. In short, this function makes sure that the process is currently running with the same uid and gid that it was given at birth (execve).

7. No 64-bit processes can load any bundle input managers.

This is an interesting requirement. I can’t think of any good reason for this.

It turns out that checks 2 through 6 are not made when running in 64-bit. Instead, the validation routine simply returns NO.

If they were to allow 64-bit Input Managers, and we actually wanted to have them load into a 64-bit app, we’d simply have to rebuild them with 64-bit architectures.

If you thought things got confusing back when binaries were PowerPC, Intel, or both (Universal), then you’re in for a treat. There’s now up to 4 possible architectures that can be in one mach-o file: PowerPC, Intel, PowerPC 64-bit, and Intel 64-bit. The dynamic loader can’t mix and match architecture types inside one process. So if you want a plugin to load into a 64-bit application, the plugin will have to be built with 64-bit as one of its architectures. To get people around problems like this, Apple has provided a “Open as 32 Bit” checkbox next to the “Open using Rosetta” checkbox. If, for example, Photoshop is made 64-bit capable, then you’ll need to use this new checkbox if you want it to be able to load any of your “old” 32-bit-only plugins.

Another problem plugin developers are going to have on Leopard involves the new Garbage Collection (GC) in Objective-C 2. A process running with GC turned on cannot load non-GC plugins. It’s a little bit more complicated than this, but I won’t go into details.

A strange turn of events

As a result of check #3, Input Managers no longer load into certain processes where you’d probably agree you don’t want Input Managers.

For example, on 10.4 and earlier, Input Managers load into loginwindow. This is no longer the case on 10.5.

However, in a very interesting turn of events, Input Managers now load into the Finder. Go figure.

Update: Our demo won first place for Iron Coder Live this afternoon! Thanks for your votes everyone!

Update 2: We’ve added a link to source code at the bottom of the post. We also made a quick video demo in Starbucks today.

This was a great excuse to buy another iPhone, install the iPhone toolchain and waste some time! Before we knew it, the iCal told us it was Thursday and we were putting the finishing touches on iPhone video conferencing.

Camera? Oh really?

Obviously we had to do something with the iPhone’s camera. Doing crazy things with cameras is a full time job for us! Our contest entry captures video from the iPhone’s camera, compresses it, and sends it to a web server, where it’s relayed to another iPhone, and vice-versa, resulting in a nice two-way video conference. Need audio too? That’s not our department but simply make a phone call to the other person’s iPhone and put them on speaker phone. Then fire up our program and you’re in business. (Yes, the iPhone makes phone calls apparently.)

Wait for the Clever Bit

Now you’re probably thinking, how do you do a video conference when the iPhone’s camera is pointed in the wrong direction? The iPhone, like every other smartphone that I’ve seen, has a camera mounted on the back of the device, causing most people to dismiss the possibility of video conferencing right out of the gate.

Phuckleberry

For those of you familiar with the Ecamm product line, you may remember that we sell the Huckleberry mirror, a periscope for your MacBook or MacBook Pro. While the Huckleberry II for MacBook Pro doesn’t quite fit properly on an iPhone, that’s nothing some wire cutters and imagination couldn’t fix. Here are some pictures of our homemade iPhone-Huckleberry-stand running a two-way video conference over wifi. As you can see, the camera image is reflected off two acrylic mirrors and re-oriented in software.

(The orientation changes automatically of course.)

Darn

Ok, whoops, we meant to create something useless and fun. Surprisingly, this actually works very well, and might be considered downright useful in some scenarios. I hope that doesn’t disqualify us from the hack contest…

The iPhone Toolchain

The first step after jailbreaking our iPhones (which sounds dangerous but is actually pretty benign), was downloading and building the iPhone toolchain. The toolchain is clearly the result of hundreds of hours of work by a devoted group of iPhone dev devotees. What have they built? In a Nutshell, devs can now write native iPhone apps in the same integrated development environment we use to write Mac apps, in the same programming lanaguage, using almost the same set of APIs. It’s pretty overwhelming to think of the possibilites this opens up. It’s like a tiny little Mac/phone just like we were all promised! Thanks to the folks at iPhone Dev Wiki, and the binutils project, and these two pages for getting us up and running within hours.

Source Code

We’ve decided to post the source code for our contest entry here on the blog. Please keep in mind, this is most likely not going to be useful to you for anything other than illustrating the mechanisms that we used to accomplish our hack. The current app does not support more than two users, and will not just compile and magically work, as you will also need a server and a relay script to send the imagery between iPhones. (We used Perl for that.)

Download here: squidge_source.zip (84K)

Sample App

Next on our list, we’ll be creating an app that will actually let ambitious iPhone users try out the proof of concept. This primarily involves adding a user interface. Check back for this.

The fun new functionality is all there after updating to 7.2, but there are no new header files (no public API yet). Also, the functionality is now used by QuickTime Player Pro. However, you probably won’t notice much of a change except a little progress indicator in the Recording section of the prefs when it’s scanning for cameras, and hopefully a performance improvement.

Since it’s in the wild, I can now talk freely about this cool new feature of QuickTime. All of this I learned simply by hunting around and looking at sample traces of a running video stream in the new version of QuickTime Player.

QTKit Capture looks to be a total ground-up replacement of the Sequence Grabber. The Sequence Grabber is a very ancient part of QuickTime, designed long ago as the way to capture streaming audio/video. It doesn’t appear to be going away, but QTKit Capture doesn’t use it internally except for reverse compatibility* with old vdig drivers. Where the Sequence Grabber uses QuickDraw, QTKit Capture makes heavy use of Core Video and OpenGL. Also, the top layer is Objective-C so it can be integrated easily into a Cocoa app.

I’ve done some looking around and found some interesting things:

It makes use of some new private frameworks. New to the club are:
CoreMediaAuthoringPrivate.framework
CoreMediaIOServicesPrivate.framework
CoreMediaPrivate.framework

CoreMediaIOServicesPrivate’s framework Resources folder contains a number of plugin modules. There’s one for AVC (DV cams), IIDC (external iSight), and VDC (the built-in iSight). In a nutshell, CoreMedia appears to implement a Device Abstraction Layer (A way to allow access to all video devices without having to know the details of the device.)

Other notes:

• * QTKit Capture still works with existing QuickTime component vdig modules (macam still works). In this case, it is actually running the Sequence Grabber below CoreMedia. For the built-in iSight however, the Sequence Grabber is not being used. Hopefully, Apple will provide a new way to write plugins for third party devices so the SequenceGrabber doesn’t have to be used. However, they do support 3 major video camera standards (IIDC, AVC, and UVC), so device developers going forward would be wise to implement one of these standards, eliminating the need for writing their own driver.
• You can build and link against the new functionality if you have the proper header files.

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.

Today we cleaned it up and are posting it here so new-MacBook-Pro-having visitors can try it out see the new and improved image for themselves.

The app requests and displays a video stream from the camera at 1280×1024. If you’re on an older iSight it will still stretch the VGA image out to be this size but it won’t look very good. The app will report the frame actual size from the ImageDescription at the top.

There’s also a snapshot button so you can take your own picture and make your friends jealous of your fancy new laptop. Sorry: no Photo Booth effects yet!

If you get to try it, leave a comment and let me know how it works for you.
The Test App (68 k)

Tech Talk Follows:

The app does Hi-Lite™ a potential reason why Apple might not be yelling from the rooftops about the new camera: You can see right away how slow it is to stream the full sized video. Why? It’s more than four times more data than VGA. The Sequence Grabber was designed decades ago and wasn’t designed to handle more than NTSC/PAL sizes. Until the Sequence Grabber is revamped, it’s a little too slow to run such a large stream.

1,280 x 1,024 = 1,310,720 pixels
It’s 4:2:2 compressed YUV data, so that’s 2 bytes per pixel or 2,621,440, or 2.5 megabytes per raw frame.
So for full 30 fps video, this translates to about 75 megabytes per second or 600 Mbps.
Now keep in mind the camera controller allows for a compressed MJPEG mode which cuts the required USB bandwidth signifcantly. (You’d never fit that over USB 2.0 without compression.)

But even if it is being compressed on-camera, it’s then being decompressed in the driver and passed to QuickTime in YUV. That’s a lot of data to push through the poor Sequence Grabber pipes. Technically, you should be able to request MJPEG data from the sequence grabber, but the default seems to be YUV. I haven’t tried requesting other compression types as I don’t actually have one of these new machines in front of me.*

More details about the new camera:

The original iSight didn’t advertise itself as a UVC device (It was Vendor Specific).
The new one does advertise as UVC, so you can easily use USB Prober to decode the device descriptor:
According to the descriptor the camera supports the following frame formats:

MJPEG 640×480 @ up to 60fps
MJPEG 720×480 @ up to 60fps
MJPEG 800×600 @ up to 30fps
MJPEG 1024×576 @ up to 30fps
MJPEG 1024×768 @ up to 30fps
MJPEG 1280×960 @ up to 30fps
MJPEG 1280×1024 @ up to 30fps
Uncompressed 640×480 @ up to 30 fps
Uncompressed 352×288 @ up to 30 fps
Uncompressed 160×120 @ up to 30 fps
Uncompressed 704×576 @ up to 25 fps
Uncompressed 720×480 @ up to 25 fps

Maybe another SequenceGrabber savvy engineer out there with the new MBP could experiment and see what you get back from VDGetCompressionTypes. Can we request MJPEG data through the pipes?

*Another thanks to Dave for running some tests for me on his MBP. Dave is a web designer and has a website that I’ll plug.