>Subject: Re: Determining whether Mac platform is Intel or PPC? >From: M Pulis <[EMAIL PROTECTED]> >This thread gets more interesting every day. :-) > >I am sure you have thought of this along the way, so now I am >curious. This could be a "dumb" question, perhaps off topic, so here >goes: If the RB app is only an installer, why not use Apple's >Installer? Or, a simple Cocoa application? What made RB the tool of >choice for this task?
We made the decision back to "roll our own" when OS 9 was introduced. It was triggered by Ray Sauer dropping support for DragInstall. I'm glad we did, as making the transition from OS 9 to OS X has been smooth and incremental. I may be wrong--I haven't looked closely at Apple's OS 9 and OS X installer technologies--but I believe that if we had adopted Apple's OS 8 installer technology we would have had to start completely from scratch with OS X. At the time, we looked at Stuffit InstallerMaker and Vise. Anything we did meant starting from scratch. The commercial products seemed to be full of features we didn't need, while failing to address some significant issues that were important to us. I was also influenced by the pain of a colleague who was trying to transition from InstallShield Express to InstallShield: it didn't seem as if using commercial installers would necessarily give you a smooth ride. The problem I was dealing with was, very roughly, this. Every time the OEM sends us a new product, we need to make "the same changes" to it. Actually, we need to make those "same changes" up to much as forty times per new release. During the period when we were shipping both OS 9 and OS X we supporting about ten product families times two OSes, and we supply a "private-label" version to another company which sells our products with their own logo and different product names. So the basic problem I was trying to solve was automating the process of applying forty different _small_ sets of modifications to what the OEM sends us. It's possible that if I had a good understanding of OS X packages that there's something relevant to that problem, but as I say this all started years before OS X. I could probably do all this with installer scripting languages, but as long as I'm going to be writing significant amounts of code I'd prefer to be writing it in something like REALbasic, which is much more capable and complete than most installer scripting languages. Writing the installer ourselves gives us a chance to tailor the UI more than with commercial installers. And it provides opportunities for doing things like extracting information that's in the (NeXTies, look away) resource fork of our driver. For example, the installer can automatically show the user the list of device models a driver supports just by parsing out information that's in the driver. If we add devices to a driver, we don't need to remember to update anything in help files or the UI: the installer is automatically up-to-date. There are downsides. As we've gotten into OS X and handling permissions and calling the authentication stuff, I've spent more quality time with #declare than I would have liked to. And I've had more glitches with RB version transitions than I would have liked, but there's never any _urgency_ to using the latest version of RB. On balance it's been a win. _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
