Volume Number: 19 (2003)
Issue Number: 4
Column Tag: QuickTime Toolkit

The Sting

Developing QuickTime Applications with "Stinger"

by Tim Monroe

In the previous QuickTime Toolkit article ("The Vision" in MacTech, March 2003), we took a look at developing QuickTime applications using Microsoft's Visual Basic. I noted then that Visual Basic provides no built-in support for displaying or editing or creating QuickTime movies, but that we can work with QuickTime movies using any one of several third-party ActiveX components. Apparently that article struck a nerve somewhere within Microsoft, for several days after the magazine hit the stands, I received a package -- postmarked in Redmond, Washington but otherwise with no indication of the sender -- containing a single CD. The CD contains what appears to be a pre-release version of a multimedia application framework developed by Microsoft. The product is named "Stinger" and sports a logo of a bee (which is eerily reminiscent of the MSN butterfly).

So far, I've spent only a couple of days working with Stinger, but it's clearly a software development environment of some importance for QuickTime developers. It allows us to write applications that support the standard litany of Microsoft proprietary media and file formats (AVI, WMV7, ASF); Stinger also supports MPEG-4 audio and video formats. This already is pretty surprising, as it represents an abrupt shift on Microsoft's behalf toward open standards for multimedia content. What's even more surprising is that we can use Stinger to develop applications that can create, open, and display QuickTime movies. And the list of operating systems that can run Stinger-developed applications is truly amazing; Stinger can create multimedia applications that run on Windows, Mac OS, several flavors of Linux, Palm OS, and even MS-DOS itself! For instance, Figure 1 shows the QuickTime sample movie displayed by an application running under Red Hat Linux; note the distinctive Red Hat "Bluecurve" graphical interface.

In this article, we're going to take a preliminary and unfortunately brief look at Stinger. I should say in advance that the information here is derived mainly from my own tinkering around with it (there was no documentation on the CD), and some of it is pure conjecture. Also, the name "Stinger" is quite likely a code name -- though judging from the professional finish to the logo, the final product name will probably have some apiary connection ("Visual Beesic" perhaps?).

Perhaps the most amazing thing about Stinger is that it exists at all. I noted in the previous article that "Microsoft...does not have a history of promoting QuickTime as a multimedia creation or delivery technology". That was an understatement. In fact, Microsoft has a history of trying to derail the adoption of QuickTime, at least on Windows operating systems. Here is an excerpt from the court's decision in the recent Justice Department anti-trust case against Microsoft:

"S. 105. Beginning in the spring of 1997 and continuing into the summer of 1998, Microsoft tried to persuade Apple to stop producing a Windows 95 version of its multimedia playback software, which presented developers of multimedia content with alternatives to Microsoft's multimedia APIs. If Apple acceded to the proposal, Microsoft executives said, Microsoft would not enter the authoring business and would instead assist Apple in developing and selling tools for developers writing multimedia content....Apple would have been permitted, without hindrance, to market a media player that would run on top of DirectX. But...Apple's QuickTime shell would not have exposed platform-level APIs to developers. Microsoft executives acknowledged to Apple their doubts that a firm could make a successful business out of marketing such a shell." (From the Court's Findings of Fact, Civil Action No. 98-1232.)

At one meeting in April 1997, Apple engineer Peter Hoddie asked incredulously: "Are you asking us to kill playback? Are you asking us to knife the baby?" According to court testimony, a Microsoft official responded: "Yes, we want you to knife the baby." Ouch. (Insider trivia factoid: this exchange prompted a member of the QuickTime engineering team to print up tee-shirts bearing the slogan "Don't Knife the Baby.")

It gets worse. Some early versions of Microsoft's multimedia playback application, the Windows Media Player (also known affectionately and perhaps too accurately as WiMP), had a tendency to hijack the QuickTime movie MIME type (that is, "video/quicktime"). When a Windows user would navigate to a web site containing embedded QuickTime files (with the file extension .mov), the movie files would be opened by WiMP, not by the QuickTime plug-in. For most media types, and particularly for QuickTime VR movies, this would result in a less than optimal experience.

Further, Internet Explorer version 6.0 (which was first shipped with Windows XP) and version 5.5 with Service Pack 2 applied broke browser-based QuickTime movie playback altogether. That was because those versions of IE stopped supporting NetScape-style plug-ins and because the QuickTime plug-in was implemented as a NetScape-style plug-in. Indeed, it was precisely to address this issue that Apple developed (with Microsoft's assistance, it must be pointed out) the Apple QuickTime ActiveX control that we investigated in the previous article.

I could continue down this road ad nauseum, but the fact is that I come to praise Microsoft, not to bury it. After all, as I've suggested, Stinger represents a complete reversal of this "knife the baby" strategy. So, in quasi-Watergate style, let's follow the honey.

The CD I received contains two folders, one labeled "Runtime Installers" and the other labeled "DevStudio Installers". The first folder contains what appear to be runtime environment installers for the target platforms (more on this later). The second folder contains only a single executable file, StngrInstl.exe. After running the application, I launched Microsoft Visual C++ Developer Studio and was greeted with the "Tip of the Day" shown in Figure 2.

Dutifully, I selected the New menu item in the File menu. Sure enough, the list of available projects included "QuickTime Application" and "QuickTime Component", as shown in Figure 3. Clicking on "QuickTime Application" revealed that Stinger can generate QuickTime-savvy applications for seven different platforms: Windows, Mac OS 9, Mac OS X, Palm OS, Red Hat Linux, Mandrake Linux, and MS-DOS. I was, to put it mildly, intrigued.

I named the new project "StingerShell". Recall that our goal in this current series of articles is to replicate the functionality of our existing application QTShell. On Windows, QTShell provides support for opening multiple QuickTime movie files and displaying them in child windows inside an enclosing frame window. In other words, QTShell on Windows uses the Multiple Document Interface (MDI). It turns out that the default applications created by Stinger use the Single Document Interface (SDI): they open QuickTime movies in a window whose content area completely contains the movie and the movie controller bar. (The size of the movie within the content area can be adjusted, but for present purposes we don't need to do so.) So the only thing we need to do to bring the default Windows application into line with an SDI version of QTShell is add the Test menu -- where we add our application-specific items -- and add some code to handle those menu items.

The programming model supported by Stinger is unexciting: it's straight C code that calls Windows APIs for basic application services (event handling, message processing, and so forth) and QuickTime APIs for multimedia services. Listing 1 shows the code that is called when the user selects a movie in the file-opening dialog box.

OpenMovie
void OpenMovie (HWND hwnd, char *szFileName)
{
   short      nFileRefNum = 0;
   FSSpec      fss; 
   NativePathNameToFSSpec(szFileName, &fss, 0);
   SetGWorld((CGrafPtr)GetNativeWindowPort(hwnd), NULL); 
   OpenMovieFile(&fss, &nFileRefNum, fsRdPerm);
   NewMovieFromFile(&sMovie, nFileRefNum, NULL, NULL,
            newMovieActive, NULL); 
   CloseMovieFile(nFileRefNum);
}

The only interesting departure from the standard Windows programming model that we've worked with throughout this series of articles concerns the specification of the application's resources. The default project contains a file StingerShell.sc that defines the application's menus, icons, text strings, and dialog box layouts. This .sc file is analogous to the .rc files we've worked with previously, but supports additional resource compiler directives necessary to support deployment on different platforms. Listing 2 shows how we can add in the Test menu but -- for Palm applications only -- exclude the Help menu.

StingerShell.sc
IDR_MAINFRAME MENU PRELOAD DISCARDABLE 
BEGIN
   POPUP "&File"
   BEGIN
      MENUITEM "&New\tCtrl+N",            ID_FILE_NEW
      MENUITEM "&Open...\tCtrl+O",        ID_FILE_OPEN
      MENUITEM "&Close\tCtrl+W",          ID_FILE_CLOSE
      MENUITEM SEPARATOR
      MENUITEM "&Save\tCtrl+S",           ID_FILE_SAVE
      MENUITEM "Save &As...",             ID_FILE_SAVE_AS
      MENUITEM SEPARATOR
      MENUITEM "E&xit\tCtrl+Q",           ID_APP_EXIT
   END
   POPUP "&Edit"
   BEGIN
      MENUITEM "&Undo\tCtrl+Z",           ID_EDIT_UNDO
      MENUITEM SEPARATOR
      MENUITEM "Cu&t\tCtrl+X",            ID_EDIT_CUT
      MENUITEM "&Copy\tCtrl+C",           ID_EDIT_COPY
      MENUITEM "&Paste\tCtrl+V",          ID_EDIT_PASTE
      MENUITEM "C&lear",                  ID_EDIT_CLEAR
      MENUITEM SEPARATOR
   MENUITEM "Select &All\tCtrl+A",        ID_EDIT_SELECTALL
   END
   POPUP "&Test"
   BEGIN
      MENUITEM "&Hide Controller Bar\tCtrl+1",
                                          ID_TEST_HIDE_CTRL
      MENUITEM "&Hide Speaker Button\tCtrl+2",
                                          ID_TEST_HIDE_SPKR
   END
#if !TARGET_OS_PALM
   POPUP "&Help"
   BEGIN
      MENUITEM "&About StingerShell...",   ID_APP_ABOUT
   END
#endif
END

The code required to handle our application-specific menu items is, once again, completely unexciting. I'll leave it as an exercise for the interested reader to dredge up a past issue of MacTech to see how it works.

Now let's build the applications. Select "Build StingerShell" in the Build menu (or press the F7 key). Once the build process completes, the Debug folder will contain the usual collection of object files and other junk; it will also contain debug builds of StingerShell for the target platforms. If we launch the Windows application StingerShell.exe, we'll see the error window shown in Figure 4.

This is where the installers in the "Runtime Installers" folder come into play. Let's run the installer WinHiveInstl.exe. Once we've done this, we can try launching StingerShell.exe again. This time, everything proceeds as expected. The movie playback window is shown in Figure 5.

We can transfer the other compiled applications (and runtime installers) to their target operating systems. The file StingerShell.app is a Carbon application that can run on Mac OS 9 or Mac OS X. Figure 6 shows StingerShell running under Mac OS X.

The file StingerShell.rhl is the executable for Red Hat Linux (see Figure 1 again). The file StingerShell.ml is the executable for Mandrake Linux (Figure 7).

Apparently there is already a PalmOS application with the trademarked name StingerShell, so I've renamed the Palm application QTShell.prc. When we download the executable to a Palm device, we'll see it in the list of available programs, as shown in Figure 8.

Figure 9 shows QTShell running on the Palm device.

This is all very cool, but how does it work? Apple provides QuickTime runtime support only for Macintosh and Windows operating systems. How can we run QuickTime applications on Linux and Palm systems as well? This is where I'm reduced to pure speculation. As we've seen, our compiled applications would not run without the prior installation of the so-called ".HIVE" runtime environment. I'm guessing that this is some sort of multimedia extension to Microsoft's .NET environment. Apparently Microsoft has shoehorned the QuickTime libraries into the platform-specific .HIVE interpreters and also provided some sort of emulation layer for those platforms that do not natively support QuickTime. Or so I'm guessing. If I had more time and a good debugger, I could probably figure out more of what's happening under the hood.

No matter how it works, it's clear that indeed it does work. It's sad to realize that Microsoft has beaten Apple to the punch in supporting QuickTime movie playback on Palm devices and on Linux platforms. The performance is not good (I was able to achieve a playback rate of only about 0.5 frames per second on a Palm device, and only about 2.5 fps under the Linux systems), but the API coverage appears to be fairly complete. Sigh.

Special thanks are due to an unknown source within Microsoft for providing a pre-release copy of Stinger.

You may have noticed that QuickTime Toolkit articles sport titles borrowed from movies (appropriate for a series on QuickTime, eh?). Perhaps a better title for the present article would have been the 1969 Jack Lemmon and Catherine Deneuve comedy, "The April Fools".

Tim Monroe in a member of the QuickTime engineering team. You can contact him at monroe@apple.com. The views expressed here are not necessarily shared by his employer.