About a year ago I wrote about the success a full blown SDK for Apple's iPhone's and iPod's would have. And then came the iPhone and there was no SDK and no way to write applications for it. That all changed a month ago when Apple announced that they would release an SDK in February. Now everyone is happy and excited.

But why did Apple wait? Here is the reason. Microsoft will be announcing and showing a demo of Office for the iPhone at the February event.

We all are expecting John Carmack of id Software to come on stage, and probably someone from Adobe touting Flash or such. But we were not counting on the big announcement from Microsoft.

One of the iPhone's must glaring omissions is support for Office and Exchange servers. Office 2008 for the Mac has been delayed much longer than any product should be, and Microsoft has a very competent team of Macintosh engineers who right solid code. They could have gotten this done much faster, but they needed to make sure the base code for Office 2008 is running on the iPhone.

Mac zealots you can flame me for saying Microsoft has competent engineers, but they do. I have met a few people working there, and they have all been quality engineers.

If Apple released the SDK for the iPhone without a big development partner, there would only be a lot of small developers making shareware apps for it. In general these apps could cause more problems than the value they would add to the platform. These apps will add value for the end user, but not value for Apple, Inc. Office will add real value for Apple by validating the platform, and other companies will then follow Microsoft's lead.

For those who say no way, Microsoft will never do this because they are trying to sell Windows Mobile and this will further hurt their sales of Windows Mobile as one of the biggest competitive advantages it has is Office and Exchange support. That is a wrong assumption. Microsoft will get a higher per copy royalty when selling Office for the iPhone than they will for Windows Mobile with Office when bundling with a hardware manufacture.

Microsoft is all about making money. Even when that means working with Apple, and it does not hurt that Office on the iPhone helps improve the hipness of their image as well.

As usually happens shortly before Macworld, the rumor mills are full of fun Apple lore, but what's the real story? We have new products coming from Apple along the lines of iTV, iPhone, and new iPods, but what is really new about these devices? What features are they going to offer? How are they going to run? Two interesting rumors about these devices are Mac OS X Embedded and Apple selling mobile phone service as an MVNO (Mobile virtual network operator). We are going to talk about these two rumors, and I'm going to suggest that Mac OS X Embedded is not going to happen but something even more exciting will. And Apple will become an MVNO so they can offer a simple and inexpensive a la carte service for the iPhone.

Apple is not going to make an embedded version of Mac OS X because embedded hardware today is not ready for a full blown OS. There are many pieces that would need to be pulled out of the OS to get this to work well and Apple is not ready to do this. Even if they did, the OS would still run slow and have poor battery life. These are two things Apple does not want to see happen. I understand that this can be done; we have embedded Linux phones. I'm not saying that they couldn't do it, just that they won't.
The hardware needed to make these devices work with a true Mac OS X would raise Apple's cost of the device, and the cost is very critical for these new consumer devices.

What is going to run this cool new phone, or iTV for that matter? It will be the iPod's OS. The iPod has a stable OS. It has nice performance, and low energy requirements. Like the iPod, iTV and iPhone will integrate with iTunes.

But what does all this embedded talk mean? It means that Apple is finally ready to open up the iPod OS and let the world write software for all of their amazing devices. Don't believe me? Keep reading.

The iPod already has a large selection of third party games. This means Apple already has a pretty complete API that has already been tested and used by third parties. It has a port of the Quartz drawing API, meaning the device will be able to display images and offer basic PDF support. There are embedded OpenGL drivers to speed up the 2D drawing. CoreFoundation (CF) is a basic framework of Mac OS X that lets us do many basic programming tasks. This is very portable code and runs on the iPod. Apple and Nokia's work on an embedded WebKit (Safari and Widget core) means Apple already has a Javascript and HTML engine that will be easy to port to the iPod. All of these pieces will make it easier for current software developers to port code to these devices as well.

Without a huge amount of work, Apple can now open their iPod API for developers to write C applications, Widgets, and modern HTML. They most likely ported Objective-C, parts of Core Video or small parts of QuickTime for video access, and a basic BSD based IP layer for communications with the new devices.

This open API explains why Apple is going to offer their own mobile phone service as an MVNO. Apple wants to change the way the world works with mobile devices. The current carriers (Cingular, Sprint, Verizon, etc.) do not offer a model that makes it easy or convenient to get great new software onto phones. They unnaturally restrict services on phones, all to charge you higher monthly fees.

Apple loves the a la carte business, and has done a wonderful marketing campaign to convince customers that the a la carte business is perfect for them. Apple knows how successful an a la carte phone business would be.

Want to make calls on your phone? No problem, get an free account and it will cost you five cents a minute to use the phone. Want to send a text message? Five cents, please. Want to play a game on your phone? No problem again, buy the game from iTunes and synch it or buy it on the phone and just play it. This won't expire after a month as it does on the crazy phone carriers. What are they thinking, that you should pay five dollars per month to play a game? And of course, music and video will just work perfectly and beautifully. You will be able to buy from iTunes or buy from the phone. Since Apple controls the network, they will be able to put the transfer cost into the purchase price. If you are on another carrier, you will have to pay them for the download.

Now we will have phones and devices that we can write software for, sell software to, and use without ugly commitments or contracts. In a years time, there will be a world of applications for these next-generation phones, iPods, and iTVs.

You'll be able to buy a phone without any contract, and use it to play games and music with no monthly fee. The a la cart business model will be so popular for parents, teenagers, and college students that the market will swarm to the phone.

What does this mean for all of our tribalmedia customers? It means we will start porting iShell to this great new platform. Yet again, iShell will open up a new world of possibilities for designers around the world.

Matt Veenstra
president
tribalmedia

What a double-sided sword this wonderful piece of software can be at times. For the last release of iShell, we needed to migrate pieces of our source code from QuickTime (QT) 5 code base to the more modern QuickTime 7 code base. This is logical and makes sense. And now, the rest of the story.

One thing to remember about iShell and tribalmedia's approach to software is we always write software with a cross-platform mind and a focus on compact -- as little code as needed -- software. With this in mind we quickly eliminated Cocoa/Objective-C as it is not a good solution in a cross-platform world. We could argue the merits of C++, but for us C is the way to go, and we use C in many abstracted and wonderful ways.

What prompted this article was using the latest QT API's to open a QT movie (should be really easy) and to create 64bit (larger than 2GB) media files with the QT API on both Mac and Windows platforms. Along the way there is some useful information and some good old ranting.

Opening a Movie

Just for a quick reference here are the options for opening a movie. *1

OpenMovieFile and NewMovieFromFile - Apple says, "Don't use this crazy FSSpec business." Even though it works everywhere etc. I totally understand the reasons why, but an easy cross-platform replacement would have been so welcomed. I guess they could have done something crazy and adopted FSRefs.

OpenMovieStorage - Not sure why this is not recommended. DataReferenceRecords are the recommended approach for many other APIs. Most of us really just want to add our a drawing world (Quartz, QuickDraw, OpenGL, HBITMAP, HDC, etc.) And if it is a just a single track sound file we would really like QT to not require a drawing world. I would think this could be done with a simple flag and parameter...but maybe not.

NewMovieFromHandle - OK. How often do we have an entire movie in file? Oh...but wait this is actually just the movie resource it is looking for in the handle. And this gets us to a problem we will look at when writing movie data.

NewMovie - So temptingly simple, but not what you want. Sorry.

NewMovieFromScrap - Not even sure what "Scrap" is. Easy enough to eliminate.

NewMovieFromStorageOffset - OK. Then name here helps me see when this could be useful. Useful when you want to create your own movie file etc. iShell needs things like this. But you are actually supposed to use the next function for must cases.

NewMovieFromDataFork - Or its 64bit sister NewMovieFromDataFork64. This does not imply offset. And damned it requires a fileRefNum again and this is only available on Windows with FSSpecs. So that takes us back to NewMovieFromStorageOffset, but at least I have an intimate knowledge of DataRef's thanks to part 2 of this story.

NewMovieFromDataRef - This is not really ever recommend as you cannot set the drawing world...and it crashes if one does not have an antiquated GWorld in place for the life of the movie. No CGContext or OpenGL world for this almost easy to use function.

NewMovieFromProperties - WE HIT THE JACKPOT!!! (Had to scream sorry. This is just not intuitive when all someone wants to do is open a movie file! Open is such a good word.) NewMovieFromProperties is the way Apple recommends us to do this now. And you have to really understand many nuances to get it to work. Yes it is more powerful, and useful for many of the things iShell needs to do. But for newbies this looks like the start of maze they will never make it out of.

Now for some useful examples of this and why it works.

/* ___________________________ The Old Way _______________________ */
// NOTE: keyIfError() is simply a error checking macro we use.
// Requires FSSpecs and active GWorld
keyIfError(OpenMovieFile(&aFSSpec, &aRefNum, fsRdPerm));
keyIfError(NewMovieFromFile(&aMovie, aRefNum, NULL, NULL, newMovieActive | newMovieAsyncOK, NULL));
CloseMovieFile(aRefNum);
aRefNum = 0;

/* ___________________________ The New Way _______________________ */
// First define these...
DataReferenceRecord aQTDataRef = {0};
Boolean isActive = true;
QTVisualContextRef aVisualContext = NULL;
QTNewMoviePropertyElement aMovieProperties[] = {
{kQTPropertyClass_DataLocation, kQTDataLocationPropertyID_DataReference, sizeof(aQTDataRef), &aQTDataRef, 0},
{kQTPropertyClass_NewMovieProperty, kQTNewMoviePropertyID_Active, sizeof(isActive), &isActive, 0},
{kQTPropertyClass_Context, kQTContextPropertyID_VisualContext, sizeof(aVisualContext), &aVisualContext, 0},
};

/* Just to note, it is not clear what the visual context is, but I assume we need this now so as not to crash. */

// Now Create the Data ref.
keyIfError(FSPathMakeRef(aPath, &aFSRef, NULL));
keyIfError(QTNewDataReferenceFromFSRef(&aFSRef, 0, &aQTDataRef.dataRef, &aQTDataRef.dataRefType));

// Wait. That does not work on Windows. So try this...
keyToSystemPascalString(aCPath, aPascalPath, sizeof(aPascalPath));
keyIfError(FSMakeFSSpec(0, 0, aPath, &aFSSpec));
keyIfError(QTNewDataReferenceFromFSSpec(&aFSSpec, 0, &aQTDataRef.dataRef, &aQTDataRef.dataRefType));

/* And since Windows programmers are so used to a Pascal path this makes sense. And again we are using those FSSpecs we are never to touch again so try again. */

// The real trick is this...

aCFStringPath = CFStringCreateWithCString(NULL, aCPath, kCFStringEncodingUTF8);
keyIfError(QTNewDataReferenceFromFullPathCFString(aCFStringPath, kQTNativeDefaultPathStyle, 0, &aQTDataRef.dataRef, &aQTDataRef.dataRefType));
CFRelease(aCFStringPath);
aCFStringPath = NULL;

/* Now raise your hand if you have ever seen any Apple sample code use Core Foundation classes on Windows. I could not find it. Hopefully this exists and I am just blind. Low and behold, this and the CFURL equivalents work, and give you an easy way to handle paths and start creating movies. */

// Now call...and don't forget we have a DataRef which we are not sure what it is in one of those properties.
keyIfError(NewMovieFromProperties(3, aMovieProperties, 0, NULL, &aMovie));

/* And now you have to call SetMovieGWorld() or the other equivalents which I am not sure what they are as I have not migrated my drawing to the only cross platform option of OpenGL. And GWorlds work in crazy hacked ways from HBITMAP's and CGContext's */

// Finally dispose of the DataRef...but wait there is not an compliment to QTNewDataReferenceFrom() functions. So you have to use the most intuitive. DisposeHandle to the pointer of one of the structs values

DisposeHandle(aQTDataRef.dataRef);
aQTDataRef.dataRef = NULL;

Now we know how to open a movie the QT 7 way. And I believe it is not so clear.

Writing Data

I will only touch briefly on writing data the QT 7 way vs. the old way. Basically the old way involved FSSpecs and used the straight classic Mac file system calls. FSOpen, FSWrite, etc, and you could write data buffers, movie data, and movie resources. *2 It was never as easy as on Windows file APIs, but it worked. The new way now says to use DataRef's and DataHandlers. Seems easy enough, but there are some really tricky bits. There is one sample I found (qtfiletransfer.win http://developer.apple.com/samplecode/qtfiletransfer.win/qtfiletransfer.win.zip ) and it did not solve my problem of 64bit files, but at least was a basis to start from.

To get started we need to create the DataRef. We now know to use CFString's or CFURL's so this is much easier. But the problem here is we cannot create a new file with the Core Foundation API, but QuickTime saved us here and will create the file for us if it does not exist.

The next trick is how to take that DataRef and make a DataHandler out of it so we can use the nifty new DataHWrite64, DataHGetFileSize64, etc. You’d think there would be an easy way or sample to do this. And the link above did provide one sample. It is shown below.

aHandler = OpenComponent(GetDataHandler(aQTDataRef.dataRef, aQTDataRef.dataRefType, kDataHCanRead));
anErr = GetMoviesError();

I would have never guessed this without the sample from above. I probably searched for two hours to come across this. And now in the process of writing this article I think I have discovered you could use OpenMovieStorage to get the same thing. I think this is much cleaner if it works.

Now the last trick is to figure out how to read data. When writing data we have DataHWrite64. This works great and as expected. You would think DataHRead64 would exist, but to my greatest amazement, this does not exist. The closest compliment is DataHReadAsync and according to the latest docs is unsupported. But it does work if you play around. And it will work synchronously if you leave out the callback proc. But what are you really suppose to use? After much searching I found out it was DataHScheduleData64. I am sure this just calls DataHReadAsync somewhere underneath. My question here is who would have ever thought to call the compliment of "Write" "ScheduleData"? I don't think I will ever understand that.


Conclusion

Here are my two recommendations for Apple. Please just create a nice OpenMovie function. I don't think this name has ever been used in the QT API, so it probably would be available. The second recommendation is give us simpler file API. The core code here works great. Just abstract it for us.

Hopefully this long read will save you a bit of time as you write your own QT code.

Next time maybe we will write about the Macintosh file APIs so all those Windows only programmers out can feel how lucky they are to have the Windows file API’s.

---

A quick company pitch...if you ever need help in writing that great media software the engineering team at tribalmedia is available and ready to help you create the next great piece of software.

*1 - When writing software with QuickTime and the Mac in general, reading the header files is one of the best resources you can find.

*2 - When we look at a movie data and information you must always remember that when the documentation says a "movie resource" they are referring to the movie header or description information stored in classic QT Atoms. And "movie data" is a reference to the actually streams of information. The QT storage system is amazingly powerful and flexible but the terminology can be a bit confusing for newbies. And this is just a very simplistic rough explanation.

iShell Future

On our subscriber email list we were sent the following questions.

"Subject: is iShell alive?... and many more questions...

Message: - is it alive?

- what's the roadmap from now onwards?

- is it wise for me to invest money training our staff in the use of
iShell?

- are there any plans to expand the user-base?

- what will be the renewal price?"

We felt it was best to put the answer to this in a more public place.


First, let me say that we love iShell and have great ideas to make it even more amazing than it is today.

Right now iShell 4.0r10 is the current stable version. We have the next version, iShell 4.5, nearly ready and expect to have a new release by the end of the month. iShell 4.5 will bring native support for Mac OS X on Intel as well as many nice improvements and features. This is where we stand today. Let’s get back to the questions and clarify our current situation.

Is iShell alive? Absolutely. Starting a new company and working out all the details to get the ownership assets for the software have taken time. Now that we are done with the business foundation, we’re excited to start focusing more energy on software.

The roadmap onward is simply to make the software better and more useful. There are a million things we can do, but we are limited in our resources. In general we are going to focus on getting out releases with new features in a more timely fashion, but bug fixes will always be a priority. Crappy software with many features that do not work is not something we ever want to create or be associated with. As for the next major release, it will focus on making iShell more internet savvy.

We have some great ideas for future versions of iShell but we must move forward in a way that makes sense for us as a company. All I can say is my feature list is much longer than you can imagine, but at the same time we must prioritize and do what we can.

We are a small company with great support and software. No bug report or feature request is ever ignored or sent an autoreply. We take users’ input very seriously when discussing future plans for iShell.

We cannot decide for you if it is wise to invest in training for your staff. But if you have a profitable project lined up and iShell fits your needs, then by all means train your staff. We will be here to help if you need anything.

Do we plan to expand the user base? Yes, of course. iShell’s move to tribalmedia has already brought in a great new crop of developers. We love iShell and want to keep writing great software and working with amazing people. If we don't work on making more money and having more users, then this cannot happen and we have to go work on something else that we probably won't love as much.We have no plans right now to change the pricing structure. We always talk about pricing and costs. If we make a change in the future, you should expect it to be quite a radical change. And one I think everyone will like.

At tribalmedia we live and breathe software, iShell, the internet, web 2.0, and multimedia in a way that makes us be proud to be a part of the Bay Area and its amazing technology base. We never think in the past. We always think in the present and future.

As of August 1, 2006, tribalmedia is the new owner of iShell, the fastest, most versatile, easiest-to-use multimedia tool of its kind.

Our story began in the mid 1990s, when developers all over the world were discovering a new way to think about media. iShell, the latter-day version of the Apple Media Tool, was the hot new authoring program, just as versatile as similar programs on the market, but easier to use. Tribeworks was quickly developing a strong community of multimedia developers all over the world.

One of those developers was a graduate student in Oklahoma named Matt Veenstra. After becoming an active member of the iShell user community, Veenstra was hired as director of customer services for Tribeworks, and was promoted to head engineer shortly thereafter.

Veenstra’s new company, tribalmedia, has now acquired iShell from Tribeworks, in a mutually friendly agreement. The same engineering and sales teams that have supported iShell for the past five years will continue to work together to serve the needs of iShell’s ever-growing userbase.

The great software and services that our customers have come to expect aren’t changing, but the move is great news for everyone. tribalmedia is a new company with a strong focus on the needs of the iShell developer community. Unlike Tribeworks, which occasionally spread its engineers and resources too thin, we promise to give iShell and its users our undivided attention. There are many new ideas for iShell in the pipeline, and customers can expect to see some exciting changes over the next few years.

iShell is a multimedia authoring tool built on QuickTime’s capacity as a media player. iShell is the easiest way to create secure, interactive, cross-platform CD-ROMs and DVD-ROMs. iShell can also be used to create other types of multimedia applications such as kiosks, digital signage, and standalone Internet applications. iShell is sometimes compared to Macromedia Director, but iShell's intuitive framework makes it a clear choice for high-power users and newbies alike.

Anyone who registers at the tribalmedia website can obtain a fully functional evaluation copy of iShell. There are no time limits on iShell trials.

tribalmedia’s engineering team is also available for custom multimedia work, including CD-ROMs, digital signage, and specialized plugins for iShell. Please contact us for more information.

For more information, see the annoucement to iShell users. Any questions about tribalmedia and iShell can be directed to .