Building installs

I thought I'd share some of what I've learned in building installs for Windows, Mac, Windows Mobile and iPhone.

Windows: Inno Setup

This is free from http://www.jrsoftware.org/isinfo.php

Inno Setup is a marvellous tool, making it really easy to auto-build "standard looking" setup .exe files using scripts. I use cygwin bash shell to grab my latest files, build the setup .exe files and zip them up - dead easy. Spread the word!


Mac: PackageBuilder - free from Apple

Some apps are simple enough just to distribute as zipped-up Disk Images, from which the user can drag the embedded .app file to their Applications folder. However, applications that are more complex (such as Noatikl, which includes various components including Audio Unit and VSTi variants) are tougher to build installs for.

PackageBuilder is built-in to XCode, and builds good looking "Mac Standard" installs, but it is a pain to drive it automatically. I use one bash shell script to copy all the bits I need under a build folder, then I run the PackageBuilder manually using pre-prepared configuration file (can't figure-out how to run it from the command line!) (making sure I save the .pkg files into the right folder... that'll catch you out if you're not careful!) and then a second script to build the pkg file into a .dmg file, then zip it up.

Both these tools allow you to embed licenses that the user has to agree to in order to complete the install, which was important to us; in both cases, those text files can come from .rtf files so they're nicely formated!

PackageBuilder with XCode 3

If you're using XCode 3.0, and have tried to build an installer package and encountered all sorts of annoying problems that prevent it from working; don't despair.

Instead, do what I did, and copy/use intead the PackageBuilder.app from from an XCode 2.x distribution; this works, and means you can totally avoid the buggy version in XCode 3.0 ... :)

This fixes the problem where when your application gets installed, it appears in /Library/Applications rather than ~/Applications ... this is such a huge bug, I'm amazed it actually got into XCode 3 ... oh well!

Here is an outline bash script that you could use. Note the use of sudo to get around some file permission problems; basically, if the files that you work with don't have the appropriate permissions, they won't get installed properly on the target Mac.

sudo /Developer/Tools/packagemaker \
-build \
-v \
-p myprod/install/macosx/myprod_mac.pkg \
-proj imyprod/liptikl/install/macosx/myprod_mac.pmproj \
-f ./myprod_install_root \
-r ./myprod_install_root \
-i myprod/install/macosx/Info.plist \
-d myprod/install/macosx/Description.plist

The .pmproj file is prepared by you, prior to repeated running of this script, by the PackageMaker GUI tool that is in /Developer/Applications/Utilities ...

Oh, and under myprod_install_root, you first have to create separate Applications, Library etc. folders containing copies of my App, Libraries etc. that you want installed, in a folder structure mirroring how they should get installed on the target Mac.

Windows Mobile

The solution here is to build cabinet files using cabwiz (which comes with of Visual Studio). You'll need to construct all sorts of custom code in a custom setup.dll file, that does stuff such as displaying license text that the user must agree to at install time. You should also write a relatively simple launcher .exe for Windows Desktop, that allows the user to install the file directly from their Windows desktop, through the services of ActiveSync (this is a lot easier for your users, than expecting them to copy a .cab file across to their Mobile device's StartUp menu...!)

iPhone

For distribution to your ad-hoc testers, remember that you need to update the version number in version.plist every time you supply an updated build; otherwise, it'll fail to install/update on the target iPhone/iPod! Remember also that if you zip-up a .app file, it won't install properly after being unzipped on the target computer. Instead, first put the .app file in a disk image, and then compress the disk image to a zip file that you can then mail to your ad-hoc testers.



Windows Mobile, iPhone, Android, Palm - a look around

It is an interesing time of flux in the mobile software development market. The new version of iPhone OS released, a new version of Windows Mobile in the offing, Android phones have trickled onto the market and the Palm Pre arriving.

Intermorphic are in a pretty good position during this time of change.

The approach we've taken is to try and embrace all the key platforms - provided they support C++, Posix threads and STL. This lowest common denominator allows us develop complex software quite cost effectively. Of course, this required us to engineer our products from the beginnning to be able to reuse 95+% of our UI code, and 99+% of all other code, across all platforms we support; which is a challenge but one that was well worth the effort. That allows us to create standalone Mixtikl variants for Windows Mobile, iPhone, and Mac/Windows desktops. And even plug-in VSTi/AU variants for Mac/Win desktops!

This baseline requirement on C++ means that for now, Android and Palm webOS aren't viable target platforms for Mixtikl. The reason? Android only supports Java applications, and Palm Pre supports only JavaScript/CSS applications. However, the C++ approach does mean that a Symbian Series 60 variant of Mixtikl is possible in the future, if the Symbian SDKs ever become cost-effective to use (I remember various past problems when I last looked at Symbian, including their use of non-standard C++, no thread support, no support for STL...). The Antix platform also looks very promising, I hope it gets mass distribution so we can run on it!

It is interesting to consider how the Android and Palm platforms might succeed in terms of a 3rd party software market. From my perspective as a creator of applications for mobile, I can't see how it could be cost effective for me to invest several months (or years!) in creating a complex app for either Android or Palm, where I could spend just a little more time creating a complex app that would run on all of Windows Mobile, iPhone/iPod, Windows desktop, Mac desktop, and future platforms as yet unknown. The economies of scale seem pretty clear to me. :) I can see small games and utilities being created for the two platforms, but would be surprised to see large-scale commercial apps coming about for either of them.

Pete

Mixtikl 1.5 gets closer...

Another 2 weeks on, and another 2 (or 3!) weeks of coding to go.

I've put a lot of effort over the past couple of weeks into further polishing Mixtikl on iPod/iPhone, and have also spent time improving the behaviour of Mixtikl on Windows Mobile (which has not been forgotten amongst all the iPhone work!).

There is still quite a bit of work to do on tweaking the skins for all the different Mixtikl platforms, and we've yet to finalise the Tiklpaks for release; we'll just have to see how we get on and release when we're ready!

Porting Mixtikl to iPhone

I spent most of Christmas finishing-off the bulk of the remaining port of Mixtikl to iPhone, with a view to possibly releasing it if we can resolve various issues related to Apple's SDK terms.

I had planned to work on the Symbian port, but delayed that after reminding myself again of the horrors of porting any code to Symbian. :) That will wait for a few more weeks...!

Anyways, it is interesting to reflect on the iPhone porting process.

All in all, I reckon it took me around 3 to 4 weeks to port Mixtikl; which was mainly about creating an iPhone abstraction layer, with Cocoa variants for some of the code.

Not too hard, but there is some crazy stuff out there:
- you have to abandon all use of fopen() etc., and use Cocoa NSFileManager instead. If you try fopen() in the emulator, it'll try to open files in the host Mac's file system; which isn't what you want. :) opendir() etc. all have to be replaced, too.
- Mixtikl is highly threaded. I simply couldn't get the NSTimer class working properly in such a threaded system, and resorted to using Thread-based timers instead (that wasted a few days, drove me potty!).
- despite what Objective-C/Cocoa heads tell you, I found autorelease pools difficult to get my head round, easy to leak by mistake, and inefficient on occasion. IMO, if you have to learn magic rules for when you can and should release objects returned to you within the system, then the system ain't as smart as it should be. No such problems in Java. No such problems in C++! You need to remember that not all of us spend all of our time writing Objective-C, and it isn't easy to dip-into without making mistakes in this area.
If you call [object release] when you shouldn't, the system fails at some unrelated time in the future; if you fail to call [object release] when you should, the system will leak and it ain't easy to track down! Horrible.
- On a related note, avoid using NSData to hold file read/write data; use the file descriptor and low-level file-descriptor function such as read()/write() instead. Why? Well, if you're reading loads of file data, the NSData objects (which are purged by an auto-release pool) aren't actually purged until some arbitrary point later over which you have no control. This can lead to your system running out of memory as lots of auto-release objects are accumulated but not yet purged (!); leading to memory allocations failing bizarrely even when you're convinced your software should still have access to lots of memory (the memory clearly isn't available until the system purges the autorelease pool.... at some point when it feels like it!). You can avoid this simply by using file descriptors instead (from [myfile fileDescriptor]). Oh, and another reason is that file descriptor based access is a whole lot faster, as there is no unnecessary buffer allocation/releasing going on.
- you'll be amazed at how horrible image drawing is, if you're using Core Graphics like we are. Having to use transformation matrices to account for the inverted Y coordinate was not fun at all, to say the least! :(

On a separate note, the state of play wrt demo code for Apple/iPhone/Microsoft etc. remains pretty poor. When I worked at Tao Group, I put lots of effort into creating many clear, fully-working and complete demo programs that illustrated many different specific specific uses of our Audio APIs, along the lines of "what code do I need to achieve this specific effect", including playing files, playing streams, adding effects plug-ins etc. I can but presume that the reason that most companies don't do this, is that those responsible for writing the APIs aren't actually genuinely passionate about helping the people who want to use their APIs. This always leads to me wasting lots of time fiddling with poorly written demos, trying to figure-out how to actually use the various APIs...

Porting Mixtikl to Mobile - Windows Mobile, Symbian, iPhone, Antix Game Player

While evolving miniMIXA into Mixtikl at my company Intermorphic, I've encountered quite a few issues porting Mixtikl to the various mobile platforms, and I thought it'd be useful to be able to share some of this with those of you interested in writing trans-platform applications. I hope you find this of use! If you have any comments, please let me know!

A bit of background

Before I start, the first thing to note is that for implementing any trans-platform application of this complexity (750K++ lines of code!), you'll need to start with a common UTF8 library. I wrote that when I first started Liptikl, so didn't have to worry about that this time round!

I started by implementing Mixtikl to sit on top of the trans-platform graphics layer that I'd already written. The first implementations of this layer were for Juce, Direct X, Windows Mobile GDI, and SDL. Symbian will come soon; iPhone is ongoing, and hopefully Android at some point. The Juce version of the graphics layer for Mixtikl were really easy - Juce is a really great platform for desktop apps. Hence, Mixtikl for Windows and Mac desktops were relatively straight-forward (considering the complexity of Mixtikl!) And, of course, it made the plug-in variants of Mixtikl relatively easy to sort-out.

What do I like about writing for Windows Mobile?

- Great tools: Visual Studio is simply superb.
- Fabulous documentation - mostly. I love MSDN, but the API documentation is light on in-situ example code, and I have had to spend a lot of time surfing for solutions to problems. I still rely on my old Windows API Bible (by Jamle L Conger) - certainly the best API guide I have ever seen, packed with examples of every API call; no longer in print, but amazingly still relevant to graphics coding for Windows Mobile!
- Windows Mobile supports full-duplex audio, which is more than can be said for Symbian...!
- Windows Mobile devices are very consistent
- Windows Mobile devices have good user input: joy pads for control, and keypad/touchable screens where appropriate.
- Windows Mobile allows users to copy data freely to-and-from their desktop computer (via Internet Explorer), which is more than can be said for iPhone...!
- End-of line Windows Mobile 2005 devices are really, really good value.

What don't I like about writing for Windows Mobile?

- Graphics APIs: it took a while to get our Windows Mobile graphics layer sorted-out.

I wasn't able to use Direct X out-of-hand for a couple of reasons. The biggest consideration is that we think that it is useful from a usability perspective for an application like Mixtikl to be able to use the mobile device's soft menus, and to display the status bar. However, Direct X apps on Windows Mobile only run full screen, which made it a non-starter. On another point, there is no PNG import support, the blit routines are not flexible, and I'd have had to do a lot of blitting through my own generic blit functions anyways.

So, we used the standard win32 GDI API for Windows Mobile. The biggest problems I faced here were twofold: I had to implement my own png importer (it is a huge oversight for this not to be built-in to Windows Mobile 2005!), and I didn't realise that when constructing an in-memory bitmap on Windows, I had to WORD-align all lines in the bitmap. That latter problem actually had me stumped for a few days! Also, you need to know to create your bitmaps where possible as 565 BGR bitmaps, as this is the most memory format for Windows Mobile; transparent bitmaps must be stored as 32-bit ABGR bitmaps.

- Problems with the Visual Studio 2005 C++ compiler

Even though the port to Windows Mobile wasn't so hard, I faced some serious problems with Visual Studio 2005. The first problem is that the emulator is so *slow*; I ended-up having to get a top-of-the range Mac Book Pro to get the emulator running fast enough for real-time debugging of my audio engine under the emulator. And far more seriously, there is at least one horrible bug in the compiler ... you can read more about the bug here:
http://vividos.wordpress.com/2007/12/06/the-infamous-arm-by-value-compiler-bug/
http://vividos.wordpress.com/2007/12/09/in-depth-analysis-of-the-arm-by-value-compiler-bug/
The bug is fixed in Visual Studio 2008...

- Visual Studio 2008 Pro is required for Windows Mobile 6 development

Due to the compiler problem in Visual Studio 2005, we upgraded to Visual Studio 2008 Pro; it fixed our compiler problems, and you need at least the Pro version of Visual Studio 2008 to develop for Windows Mobile 6. It is a shame that Microsoft didn't include the Windows Mobile support in the Standard Edition; only the Pro edition (or even more expensive versions) contain Windows Mobile support; I'm sure this puts-off a great number of hobby developers from developing for the platform.

I've taken a close look some of the ARM code generated by the Visual C++ 9 compiler, and it looks really good; the code it makes for maths routines is as good as (or better!) than I can write by hand, so I'm happy to say that I'm keeping clear of assembler on this platform!

- The lack of build-in profiler; you don't get a profiler without paying for an even more expensive version of Visual Studio. This seems a shame for hobby developers.

What do I like about writing for Symbian?

- Symbian allows users to copy data to-and-from their desktop computer (via Internet Explorer), which is more than can be said for iPhone...!
- Symbian devices have good user input: joy pads for control, and keypad/touchable screens where appropriate.
- Based on the Gnu tool chain, so the compiler is good!

What don't I like about writing for Symbian?

- the lack of full-duplex audio support. This is a crazy omission in the Symbian APIs. If anybody out there is listening, you should commission Intermorphic to provide you with a decent audio library. :)
- the need for multiple SDKs. Series 60, UIQ, and variant sub-variants of each... that is a lot of stuff to keep track of.
- if you put your software code a little too deep in your file/folder structure, the Symbian build system falls over!
- documentation nowhere near as good as what is available on MSDN or Apple's site.
- the user interfaces. Why is so much screen real-estate wasted on the title-bar and soft menus, for example?
- the really weird idiosyncracies in their use of C++...
- Symbian doesn't allow full browsing of the local file system from the device; if you want to see what is on a storage card, you have to pop-out the card and look at it with Windows Explorer using a card-reader!

What do I like about writing for iPhone?

- XCode is free for all Mac users!
- It uses a good development environment. XCode is quite nice, though the debugger drives me potty compared to Visual Studio when browsing variables in the application code.
- XCode has a really, really good build-in code profiler. Well done Apple!
- No need to write graphics importers; image loading is pretty easy.
- Based on the Gnu tool chain, so the compiler is good!

What don't I like about writing for iPhone?

- The real killer, show-stopper, "I don't believe it" problem is that the user can't copy data to-and-from the desktop and any data area that can be seen by an iPhone application. This is a *massive* problem with writing software for iPhone. Why even bother attempting to write creativity software for iPhone, if you can't transfer data between your desktop computer and your mobile? Why didn't Apple provide for a common area to which all apps can read/write, and where Windows Explorer and Finder can also read/write. That seems a complete no-brainer to me.
- You're not allowed to use interpreted languages or scripting engines in your applications (other than those in Apple's own APIs - which aren't adequate). Which is not good news for games that rely on scripting engines to get their behaviours, or the user Lua scripts in Noatikl pieces, to give just two simple examples! I am really puzzled by why there would be such a restriction...
- No support for storage cards. No doubt to force all content to come via the Apple Store...
- No clipboard support. Presumably this is part of a cunning plan by Apple to prevent applications sharing data with each other. :-)
- Objective C. It is a great language that seems very well suited to development in a wide range of contexts. It is a whole lot cleaner than C++ (IMO!). It is great that you can mix objective C and C++ in your code (if you first remember to rename your files to have .mm extensions, rather than the default of .m!). However, it just wouldn't be cost-effective to write a new application purely in Objective C; so you have to write most of your code in C++, and implement a very thin adaptor code layer to the iPhone APIs. Fair enough!
- the touchable user interface can't be operated with a pointer stick; that makes high-precision user interfaces a no-no

And to close with a slightly off-target point: why doesn't my Mac Book Pro have a built-in 2-button mouse? Drives me potty.


What next?

The Antix Game Player looks interesting! Android is also on the near horizon; but, and here is a show-stopper: it looks like it only allows apps for it to be written in Java ... which seems crazy!

Hoping this is of interest!

Pete