BKeeney Briefs

Normally I run REALbasic on Mac OS X and remote debug in Windows.  This works 99.9% of the time but late last week I ran into a situation where I wanted the IDE on the Windows side as well.  So I installed RB and downloaded the plugins that I needed.  Then I started to use RB.

Using RB for Windows was…different.  I’m not sure that I can quantify it other than that it seemed less polished.  It just doesn’t feel like a normal Windows app and it certainly was not as smooth as the Mac OS X version.

The reason I was in Windows to begin with was of tracking down a printing bug that was affecting my product.  Turned out it was the Application.UseGDIPlus property that had been set to true.  The end result was that my reports were ‘blown up’ about 10 times bigger than they should have been.  This has been documented and is <feedback://showreport?report_id=10399>.  Turning off the property fixed the problem.  Some fix, eh?

I don’t think that Windows gets as much attention as the Mac OS X.  Why do I believe this?  The ARBP surveys consistently show Mac users being about 80% of the membership.  Likewise, traffic to this website is roughly 80% Macintosh.  What this means is that beta testers are predominantly Mac based.  I believe that most of the developers at RS are Mac users as well.

Currently, RS is in the transition to get Cocoa out.  It won’t be happening for 2010 R1…so it’s obviously a much tougher nut to crack than they originally thought.  Honestly, I’m not surprised.  Going from Carbon to Cocoa is like creating an entire new platform.  Eighteen months to two years isn’t out of the question for such a big undertaking.

I’m hoping that when Cocoa is out and working great (you think it won’t have some bugs in the first release?) that RS pays a lot of attention to Windows.  They’ve said in the past (sorry no reference for this) that a vast majority of new licenses are Windows users.  But yet, based on observation, the professionals and beta testers are mainly Mac users.  Does that not say something?  Would better Windows support translate into more Professional and Studio licenses?  I don’t know, but I suspect so.

Perhaps it’s time to kill support for Windows 2000.  I’d even suggest killing off XP but I know a lot of places in the world are still actively using it so that’s probably a non-starter.  I believe Cocoa support will effectively kill support for anything less than Mac OS X 10.4 so why not for Windows too?

I suggest that everyone that has a Studio license do a bulk of their work in Windows for a couple of weeks.  More Windows-specific bug reports will (hopefully) get some of the more obvious (and painful) bugs fixed.

What are your feelings about this?  Am I right, wrong, or somewhere in-between?

I’m not entirely sure what Apple changed in Snow Leopard but  we quickly discovered that disk images created in Snow Leopard don’t work the same in Leopard and earlier systems.  When we create our disk images we have something that looks like this:

Looks fine in Snow Leopard.  Acts fine in Snow Leopard.  But when you take it into Leopard you get a disk image that looks something like this (no background image):

Long time Mac users understand what to do but new Mac users were a little mystified at what to do.  Unfortunately we didn’t find this out until after a couple of releases, but we did find a solution.

We use a postbuild script to automatically create our disk image.  The bit of code is:

hdiutil convert -quiet  -format UDBZ -o “${IMAGE_NAME}.dmg” -imagekey zlib-level=9 “./${IMAGE_NAME}.sparseimage” \
|| error_exit “$LINENO: Could not compress the DMG”

This leaves a sparseimage file laying around and normally we get rid of it.  While running this in Leopard we didn’t and copied it.  This sparseimage has the proper graphics and works in Snow Leopard so we now use it as our template when doing builds in Snow Leopard.

We changed the script to delete the OLD file on the sparseimage using:

rm -rf “/Volumes/${MOUNTED_DISK_NAME}/Task Timer 4.app/Contents” \
|| error_exit “$LINENO: Could not delete old build”

Then we copy our newly created RB app into the sparse image.

rsync -a “${MAC_OUTPUT}/Task Timer 4.app/” “/Volumes/${MOUNTED_DISK_NAME}/Task Timer 4.app/” \
|| error_exit “$LINENO: Could not copy into volume”

So, it’s kind of pain to do, and it’s not very efficient but it works.  We are still using RB 2009 R3 because build automation that was released in R4 doesn’t work for us.

Update:  If you want to see the entire script, there is an article in the Articles section on the ARBP members only site, which is available to any paid membership.