Acknowledgements: 3 Great Tools

Here are some invaluable tools we used for DemolishPairs.com.

With the release of Demolish! Pairs and a number of other projects in the works, it has been a busy time here at Digital Gamecraft.  We finally got around to finishing the DemolishPairs.com web site (for now :)).  Now, I want to acknowledge three of the tools that proved particularly important to that task.

The first tool, and one of the most important in my arsenal, is Beyond Compare by Scooter Software.  I have mentioned before (and will probably continue to do so) that this is a product that I use almost daily and it is extraordinarily useful.  It performs both excellent file comparisons/”diffs”, showing (in this case) what changes we have made in HTML or code, and fantastic synchronization of files, so we can tell at a glance which files are updated and then copy changes to the servers (usually after verifying the diffs).  After using this tool, Dreamweaver is lacking and Expression Web is downright painful, so we exit either tool to publish with Beyond Compare instead.

The next tool is 3D Box Shot Pro, by Jellypie Software, which does a lot more than merely box shots.  For our iOS app, it generated wonderful 3D images of the screenshots on iPad and iPhone devices, which you can (finally) see on the Demolish! Pairs web page; they really make the page look much better.  I especially want to thank Andrew Gibson for actually generating these images (and more) and opening my eyes to the benefits of this software.  Here is more information and a short video showing how to make a 3D iPhone (or iPad) model with 3D Box Shot Pro.

The final tool is CSE HTML Validator by AI Internet Solutions.  This software validates your web site by checking your HTML (and CSS, etc.) files for issues that either will or could cause problems, and helps to make your site better all-around.  (It is like PC-lint for web sites: essential.)  Having used all of the validations in Expression Web successfully, I foolishly assumed that everything was fine with the site, but Dexter Bell (developer of FileBoss) pointed out that I had made a fundamental error with my HTML/CSS.  The tools from Adobe and Microsoft let it slide, but HTML Validator flagged it right away.  You can get an idea how thorough the product is with an online validation (but if you check mine, you may see that the iTunes link Apple provided me is invalid 🙁 ).

If you are developing a web site, I strongly encourage you to check out all three of these tools to help make your job easier, better looking, and more robust.

Carbon nibs update

A spurious warning appears to be spurious.

In my last post, Carbon nibs under Lion, I gave a solution to the problem of Carbon nib (interface) files not being supported in Xcode 4, while Xcode 3 would not run under Mac OS X 10.7 (Lion).  That solution was to run Interface Build 3.2.6 and convert the nibs to a newer format.

Toward the end of the post I mentioned that many windows in the converted nib files produced a warning: “This window’s content rectangle does not lie entirely on the screen with the menu bar and may not be completely visible for all screen resolutions and configurations.”  In testing, these files did not exhibit any errant behavior, but shipping a product, even a beta, with build warnings is against our development guidelines.

Since that post (and in preparation for a proper build, without warnings), I did a little research and experimentation and discovered that the problem appears to be a minor issue with the conversion, where the resulting data is aberrant enough to generate a warning, but is handled correctly in the resulting application.  Although I did not dig deeply enough to identify the exact source of the problem, it is related to window positioning (as one may have guessed).

The solution, oddly, is simply to open the offending nib file, select the (or each) window, click on the Size (ruler) tab in the Inspector, and then drag the window position image, even slightly.  As far as I can discern, any movement (within the simulated window) fixes the problem; at least, it fixed it for all of my affected windows.  Clearly, the size of the windows was not the issue, since that was not changed, and the position should never have been a problem, either, for windows with the ‘Center’ attribute enabled (as most of mine were).  I also note that the windows I created from scratch since moving to this Lion/IB 3.2.6 setup were unaffected.

One other idiosyncrasy to note is that the build process also produces the following message: “View is clipping its content.”  It is not a warning, just a message, and I assumed that it was related to the above warning until the warnings were fixed.  It is a straightforward message, albeit with no reference to the specific view involved, so I looked into find the problem there as well.

As it turns out, there is a very useful tool with IB 3.2.6 to assist with this.  Select ‘Layout->Show Clipping Indicators’ to enable a feature that displays a small “+” at the bottom of any view that is clipping its content.  I never noticed this setting before, and it can be very handy.  Alas, it also reveals (in our case) that the messages are just pointless chatter, since they are being given for list views with extra columns that are intended to scroll horizontally.  Fortunately, they do not produce a warning message, so the messages are easily ignored; in fact, they only appear on the full build log, so I may have never noticed them had I not been debugging a nearby warning.

[The most meaningful comment that I received for the last post was (seriously), “I’ve a cockroach on my pillow.  Wanna see it?”  The days of technical development posts may be numbered.]

Carbon nibs under Lion (Mac OS X 10.7)

Apple’s overly aggressive deprecation sucks.

If you are still maintaining a Carbon application for Mac OS X, you may have stumbled upon a serious issue with handling of nib (interface) files in Xcode 4 under Lion, and if you have not yet, you probably will soon.  Hopefully, this post will help you resolve problems or avoid some of the pitfalls.

The Problems

Apple marches forward and aggressively deprecates development technology.  In this particular case, they release Xcode 4 and only allow submissions to the Mac App Store from the latest version, forcing developers to upgrade.  We are maintaining and enhancing a product that was developed using Carbon, based on Apple’s (then) recommendation for cross-platform products, and was about 90% complete when they announced its deprecation in favor of Cocoa.

Additionally, we upgraded to Lion (to properly provide customer support), unaware that the latest version of Xcode 3, version 3.2.6, would not install or run on Lion.  Instead, we could only download and install Xcode 4.1, which does not provide support for Carbon nib files.  With Snow Leopard, we could download both versions normally, but from Lion, the Xcode 3 download link is removed and Xcode 4 is only available via the Mac App Store.  More accurately, the installer is available via the Mac App Store; you still need to find it in Launchpad and run it before Xcode is ready.

There are two particular problems that occur with Carbon nibs in Xcode 4.1:

First, there is no editing capability for modifying them, so when you highlight a Carbon nib, the editing window only displays an Interface Builder icon, but (importantly and annoyingly) there is no message that editing is not supported.  Unless you already know that is the case, you will waste some amount of time attempting to figure out how to activate the “integrated” Interface Builder.

Second, the build tools provided cannot process the older nib files, so you will get a message similar to the following: ‘error: ibtool could not strip “Main.nib” because it is not a valid Interface Builder document.

Of course, there are a few obvious options here.  If you stop upgrading your development system, you can still build on Xcode 3.2.6 under Snow Leopard, except that you cannot submit to the Mac App Store.  You may be able to have both versions in parallel, but that is not an option on Lion at all, and the nib build issue still exists in Xcode 4 (although the solution to that is provided below).  Finally, you can give in to Apple’s strongarm tactics and rewrite your application to use Cocoa, but that is not always feasible, economically or otherwise.  (In our case, we are trying to maintain our products and support our customers while we rewrite it with Cocoa.)

Or, I suppose, you could flip Apple the bird and abandon their Mac platform; that has crossed my mind more than once, but it is not really an option for us.  Instead, I found a way to resolve the two main problems above, without too much effort.  (That is, it will be fairly easy for you readers; it took me significant time to figure this all out.)

The Solution

To resolve the inability to edit Carbon nib files within Xcode 4, take advantage of the fact that Interface Builder was an external tool with Xcode 3, and that it does run in Lion.  Simply copy Interface Builder 3.2.6 from a (Snow Leopard) partition on which it is installed to the Lion partition.  It should be located (by default) in the ‘/Developer/Applications’ folder, and note that it must be copied to the same directory on the Lion partition after Xcode 4.1 is installed.  (It will not run properly from a different folder, and the Xcode installer apparently removes it [so make a backup copy].)  Since Xcode will no longer launch (the external) Interface Builder automatically, you will probably want to make an alias for it in a convenient location.

Then, to resolve the build problems with the older nib files, you must use the separate Interface Builder tool to covert your nib files to a newer (XIB) format.  This is accomplished by opening each nib file in IB, selecting ‘File->Save As…’ from the menu, changing the ‘File Type’ to “Interface Build Carbon Document (XIB 3.x)”, and saving.  You will then need to open your project in Xcode, add all of the new .xib files to it, and delete the older .nib files.  Clicking on one of the .xib files in Xcode will show/edit it as an XML file (instead of just an icon) but, of course, you will probably only want to edit it in your newly installed IB3.

There may (read: probably will) be other issues, both with Xcode 4 itself and with the newer SDKs.  For example, we use one (and only 1) function defined in ‘QuickdrawAPI.h’, which has been removed from the OS X 10.7 SDK, so we had to back down to the 10.6 SDK (plus each SDK has different versions of the zlib library available).  Also, several of our windows from (converted) nib files produce a new warning: “This window’s content rectangle does not lie entirely on the screen with the menu bar and may not be completely visible for all screen resolutions and configurations.”  (We dynamically adjust most of our windows anyway, so it appears to make no difference, but we have yet to eliminate these warnings.)

Nevertheless, making the above changes will allow an older Carbon-based application to be built on Lion using Xcode 4.1, leaving you free to discover more fun and excitement.

[If you find this information useful, please leave a meaningful comment.]

Disk Images Revisited

There are some issues under Snow Leopard.

In a blog post last year, I gave detailed instructions on Making Mac Disk Images Pretty.  Unfortunately, I have discovered that the most recent version of Mac OS X has some issues of which developers should be aware when using that technique (not that there is any obvious alternative).

I recently upgraded my development system to Mac OS X 10.6 (Snow Leopard).  Apple is fairly aggressive with requirements for its development tools,  and I need to upgrade in order to use the latest iPhone SDK.  Of course, I already had a Snow Leopard partition that I had used for testing, so I knew that our software would work, and I never experienced any previous problems.

When the time came to build an update for one of our products (FreeCell Plus 4.00/4.01), I had a few minor niggles with Xcode 3.2.1 (the latest version), described later, but I got the product built and packaged properly.  Then it was time for testing on our other supported versions of Mac OS X, Tiger (10.4) and Leopard (10.5), and I was surprised to learn that, although the software itself ran flawlessly, the disk images showed no background image when mounted, and the folder size was wrong.  The icons were in the correct locations, relative to the top left corner of the window, so the formatting was not entirely ignored, just effectively ignored.

After some research into the problem, I found the answer in this DropDMG forum thread, where it is stated that Apple has confirmed this as a bug in Snow Leopard.  I moved DropDMG over to my Leopard partition, rebooted to that version of Mac OS X (10.5), and build my packages there.  That solved the problem, and the background images showed in all supported versions of OS X.

Conclusion: In order to have background images appear in disk images on older versions of Mac OS X, you must build the disk image under Leopard or earlier, not Snow Leopard.

Caveats: Sometimes, when opening a prepared disk image under Snow Leopard, there is a blank space on the bottom (probably not coincidentally exactly the same size as the folder toolbar), which does not appear on other versions of Mac OS X.  Also under 10.6, the folder toolbar includes a slider control for quickly changing icon sizes (a.k.a., fouling up your layout).  I have not been able to determine the cause of the former issue (yet) nor the reason for the latter.  (How often does one actually change icon sizes that this is even remotely necessary?)

There were some build issues with Xcode 3.2.1 under Snow Leopard.

As I mentioned, I experienced a couple minor build issues after the upgrade to Xcode 3.2.1, both of which were addressed, albeit with differing degrees of success.

First, the default compiler in the latest version of Xcode is GNU 4.2, which is incompatible with the 10.4 (universal) SDK, and the very first build let me know that.  Faced with a choice, downgrading the compiler to GNU 4.0 versus upgrading to the 10.6 SDK, I chose the latter, which I saw as the path of least resistance (see “Apple is fairly aggressive with requirements for its development tools” above).  Unfortunately, at least for our project, the 10.6 SDK does not function as advertised and, despite properly setting the target OS to 10.4 (and obviously not using any 10.5 or 10.6 features), a product built with the 10.6 SDK will not run under Tiger (period), although it does work under Leopard.  I switched (back) to GNU 4.0 and the 10.4 SDK and all was well.

Second, the latest version of Xcode upgrades its tools (obviously), and one seemingly innocuous change to the linker was to eliminate the need for the “-mlong-branch” compile option for certain object files (generally kernel files, which means primarily for Apple and not so much for the rest of us).  Unfortunately, a warning message was added to that effect, yet Apple did not update its PPC object files accordingly.  As a result, every time one links a universal binary (supporting PPC), the linker throws this warning: “Object file compiled with -mlong-branch which is no longer needed.”  The only permanent solution is to recompile certain (protected) development files oneself, or wait until Apple fixes the problem.

The latter issue is extremely annoying to me, because now I am in the position of either ignoring linker warnings, which I never advise, or spending hours (or days) figuring out how to rebuild a portion of the development tools.  Can you say, “not my job“?  Personally, from my experience of Apple over the last few years, my bet is that this problem will soon be addressed by a campaign to suggest that developers should not continue to be stuck in the past supporting PPC systems.

Does anybody want a piece of that action?

Windows 7 Escapes

Microsoft releases its latest operating system.

Last week, Microsoft published Windows 7, the successor to Vista, to some fanfare.  The reviews have been fairly positive, perhaps because Vista softened the audience, but it seems that the sales tag line should be “Windows 7: what Vista should have been.

We tested the new operating system, in a couple of virtual machines, by running Sun VirtualBox virtualization software.  My first impression was that this was a great productVirtualBox, I mean.  Although I have not yet delved into the advanced features, it did exactly what we needed with a minimum of fuss and bother.  We were able to test both Windows 7 x86 (32-bit) and Windows 7 x64 (64-bit) on the same 32-bit Vista host system without serious problems.  In fact, the only problem we experienced was an inability to find a 64-bit sound driver through Windows Update (so our x64 VM did not have sound).

Back to the operating system, we found it to be perfectly adequate.  It performed as expected and was easy to use (for somebody already used to Vista, anyway).  There is nothing particularly revolutionary, but (as with the update from Windows 98 to Windows 98se) everything seems to be more polished, with a few minor features added.  The big change, really, is that the 64-bit version is becoming mainstream (whereas the 64-bit support for the previous versions was not quite ready for prime time).  It is for this reason that I am likely to upgrade my development system to Windows 7 x64 in the near future.

Some of the changes include the ability to “pin” an icon to the task bar (replacing the Quick Launch toolbar), and a new management feature for task bar (a.k.a., tray) icons, allowing the user to control when these icons are displayed or hidden.  In order to encourage users to make use of this feature, Microsoft kindly made their own icons here very ugly, so the first customization item is to get rid of them.  (This will also facilitate ignoring the loads of useless preinstalled junk that comes on some new computers.)

As far as developers are concerned, nothing much has changed.  As long as your software is Vista-compliant, it will probably run unmodified under Windows 7. All of our recent product releases worked just fine; the only items noted were the (now) missing Quick Launch toolbar and the task bar icon disappearing (i.e., being hidden) after its first appearance.  The only significant caveat, though, is that 16-bit applications (those built for Windows 3.1) will not run (directly) in Windows 7 x64.

Of course, I do have a couple of recommendations for Microsoft to consider in the future.  First, they should probably do a better job of considering the symbolism they (perhaps, inadvertently) put forward.  The default wallpaper for the beta and release candidate versions of Windows 7 was a male Siamese Fighting Fish, also known as a betta.  (“Get it?”)  The latter name may be punny, but the fact that these fish (at least at the pet store) have to have separate enclosures because they are nasty and do not play nicely with the other fish suggests that Win7 is intended to be likewise.

Also, perhaps underlining the above weakness in Microsoft’s overhyped marketing capabilities, I will point out that they had great successes with Windows 3.0 and Windows 3.1 (standard version numbering), as well as Windows 95, Windows 98, and Windows 2000 (release year numbering), moderate successes with Windows 286/386 (hardware support), Windows NT, and Windows XP (opaque version lettering), but commercial failures with Windows Me, Windows Vista, and even Windows (1.0, initial release) itself.  I suggest that Microsoft stop trying to “evoke” some greater vision and stick to practical version identification.

Finally, I note that the “Starting Windows” screen of Windows 7 is the best feature of the product, nearly perfect for its purpose.  It is too bad that the same design was not carried through to the system icons, which really are a step backwards in aesthetic terms.