Volume Number: 15 (1999)
Issue Number: 1
Column Tag: From The Factory Floor
by Darryl Lovato, Brian Pfister, Peter Thomas, and Dave Mark, ©1998 by Metrowerks, Inc., all rights reserved.
This month, the Factory Floor visits with the folks at Aladdin. My personal connection to Aladdin began when they first introduced Magic Menu, the iconic menu that was added to the Finder's menu bar and allowed you to perform a variety of compression operations on the current Finder selection. At the time, I was blown away by this trick and trying to figure out how they did that opened up a bunch of new Mac programming doors for me.
Darryl Lovato is Aladdin VP, Chief Technology Officer, and Board member. Lovato, 32, is a 15 year veteran in the high tech software business and an Aladdin co-founder. Prior to co-founding Aladdin, Lovato worked as a Software Engineer for Dayna Communications on "Mac Charlie", a PC-Mac Emulator, and FT100, a DOS drive for the Macintosh, while attending the University of Utah in the Computer Science Department. During this time Darryl also worked as a consultant, a contract programmer, and a contributing editor of MacTech magazine.
Darryl also worked at TML Systems, developing the TML Pascal Compiler, as well as at Apple Computer, where he worked on the Apple IIGS Finder, Control Panels, Advanced Disk Utilities products and later worked on the Macintosh IIsi and Macintosh IIse computers. Lovato also served as the Apple II laison to the Apple human interface group.
Brian Pfister is the StuffIt Deluxe Lead Engineer. Pfister, 32, an avid soccer player and computer engineer, attended the University of Santa Clara, majoring in Computer Science. Afterwards, Pfister moved to South West Florida to start his company, Softlink, where he developed OpenDoc parts.
Pfister's expertise led him to Aladdin Systems to continue his engineering focus. Over the past year, Pfister has enjoyed working on the Macintosh-standard compression software, StuffIt Deluxe, which many engineering aspects in version 5.0 are accredited to.
Peter Thomas, 29, has worn many hats for the three and a half years he's been with Aladdin. He began his career in technical support, but has also held positions in tradeshow technical management, product demonstrations, and is currently, a product manager for Aladdin FlashBack, Private File and Aladdin Desktop Magician.
Dave: How can developers add StuffIt technology to their own apps?
Darryl: Aladdin provides a StuffIt Engine SDK (software developer kit), that is downloadable from the Aladdin website http://www.aladdinsys.com/developers/. The original purpose of the engine was to put all the code that does compression and decompression in one place, so it wouldn't be duplicated in all of Aladdin's products. A "side-effect" of this made it possible for other developers to call the engine to compress or decompress files. Many developers have already included this functionality in their products including America Online and QUALCOMM.
Using the StuffIt Engine is actually pretty easy. You simply open the engine, pass the files or folders to compress or decompress to the engine, and it does the rest. I've included some sample code that shows how simple it really is. The StuffIt Engine SDK also provides low-level calls that allow you to do things like walk the contents of an archive, etc.
/* SimpleTest.c puts up a dialog box to allow you to select a file. It
then determines the file type and takes appropriate action of stuffing
(if the selected file is not a .sit file) or unstuffing (if the selected
file is a .sit archive). Modifying constants in the code allows you to
change the stuffing parameters and see their effects. SimpleTest.c
demonstrates how to use the high level SDK calls. */
#ifndef __MWERKS__
#include <Desk.h>
#include <Dialogs.h>
#include <DiskInit.h>
#include <Errors.h>
#include <Events.h>
#include <Files.h>
#include <Fonts.h>
#include <Memory.h>
#include <Menus.h>
#include <OSEvents.h>
#include <StandardFile.h>
#include <TextEdit.h>
#include <Types.h>
#include <Windows.h>
#endif
#include "StuffItEngineLib.h"
main()
{ OSErr err;
StandardFileReply theReply;
FSSpec theFSSpec, destSpec, expandedSpec;
long magicCookie;
Boolean makeSEA = true;
// changes these for different actions...
Boolean encodeBinHex = true;
InitGraf((Ptr)&qd.thePort);
InitFonts();
InitWindows();
InitMenus();
TEInit();
InitDialogs(0L);
InitCursor();
StandardGetFile(NULL, -1, NULL, &theReply);
if (theReply.sfGood) {
theFSSpec = theReply.sfFile;
err = OpenSITEngine(kUseExternalEngine,&magicCookie);
// first we open the engine up
if (!err && magicCookie) {
// if we found it - let's use it!
// make sure we have the correct version of the Engine
if (GetSITEngineVersion(magicCookie) >=
kFirstSupportedEngine) {
short ftype = DetermineFileType(&theFSSpec);
if (ftype == ftype_StuffIt) { // then unstuff it
UnStuffFSSpec(magicCookie, &theFSSpec, NULL, NULL,
kDontPromptForDestination, kDontDeleteOriginal,
createFolder_Smart, kSaveComments, kDontStopOnAbort,
USIT_conflict_autoRename, textConvert_Smart);
} else { // stuff that sucker!
FSSpec arcSpec;
FSSpecArrayHandle specListH = NewFSSpecList();
if (ftype) { // this is something we can expand
ExpandFSSpec(magicCookie, ftype, &theFSSpec, NULL, NULL,
createFolder_Smart, kDontDeleteOriginal,
textConvert_Smart);
} else { // stuff it!
AddToFSSpecList(&theFSSpec, specListH);
GetNewArchiveFSSpec(specListH, makeSEA, &arcSpec);
StuffFSSList(magicCookie, specListH, &arcSpec, NULL,
kCompressOriginal, kDontDeleteOriginal,
kDontEncryptOriginal, kResolveAliases,
kRecompressCompresed, SIT_conflict_autoRename);
if (makeSEA)
ConvertSIT2SEA(magicCookie, &arcSpec);
if (encodeBinHex) {
HQXEncodeFSSpec(magicCookie, &arcSpec, NULL,
kDontDeleteOriginal, kDontAddLineFeeds,
kDefaultHQXCreator);
}
}
DisposeFSSpecList(specListH);
}
}
CloseSITEngine(magicCookie); // and finally close it
}
}
}
Dave: By the time folks read this, StuffIt 5.0 will have hit the streets. What new technologies are in this release?
Darryl: The biggest change in StuffIt 5.0 is that for the last three years we have been re-writing the STUFFIT archive file format from the ground up. The old format was about six years old, and didn't support a lot of new technology that has been created since then. The new format has the following new features:
Dave: Can you fill us in on the magic behind your True Finder Integration technology?
Brian: True Finder Integration (TFI) is a series of components that allow you to manipulate StuffIt archives from within the Finder. The TFI Control Panel is the heart of these components. TFI has a plugin architectural.
_mpeg.extension", "mpg,mpeg");
user_pref("mime.audiCurrently we have 3 plugins (MagicMenu"!, ArchiveViaRename"!, and StuffIt Browser"!).
We load the plugins in a 2 step process. TFI does its preflight at INIT time. That includes installing the appropriate Gestalt Vectors that the individual plugins will use to communicate with TFI. TFI then finds all the plugins and reads their individual internal preferences. One of these preferences tells TFI when the plug-in should be called for its pre-flighting. This can be either immediately, when Finder launches, or at both times. If there is a plug-in that requires a preflight at Finder launch, TFI will patch InitDialogs. From within this patch TFI will call the plugin to initialize itself.
Each plugin follows a similar loading procedure. They first install a Gestalt vector so that the TFI control panel can configure them as needed. They then load the necessary code resources and reserve the needed memory. Lastly they patch the calls that they need. AVR is the simplest, patching only _Rename. The Browser is the most complicated. It patches more than 40 OS traps & ToolBox traps. MagicMenu is pretty modest, patching only the four MenuBar related system calls: _DrawMenuBar,_MenuKey,_MenuDispatch and _MenuSelect. We use a head patch with DrawMenuBar. We head and tail patch the other three.
Like TFI, MagicMenu has a plugin technology. Its main purpose is to determine what is selected in the Finder and pass that information to the appropriate MagicMenu extension (MME). It is the specific MME that makes the appropriate calls to the StuffIt Engine. MagicMenu and its plugins communicate through a dispatch routine.
Dave: What are your plans for Carbon/Mac OS X?
Brian: It is still too early to commit to Carbon/Mac OS X 100%. We are keeping a very close eye on it for future revisions of our products. We expect a future version of Deluxe to be very close to 100% carbon compliant but since Carbon/MacOS X development will be progressing in time frame parallel to our engineering and development we can not expect Deluxe to be completely compliant.
The True Finder integration technologies are a completely different challenge, since they are so closely tied to the current OS architecture. We have conceded that they will require a complete rewrite to work under MacOS X. Given that fact, we intend to look closely at MacOS X and see how we can best fit the functionality of TFI into the MacOS X. This will be better understood as MacOS X evolves over the next year.
Dave: What can you tell me about your latest release of InstallerMaker, V5.3?
Brian: InstallerMaker has gone through dramatic changes in the last year. We began at MacWorld Expo '98, by introducing support for retrieving files from the Internet. We also gave installers a face-lift, to provide a more modern look and feel. In our 5.0 release, following Apple's Worldwide Developer's Conference, we radically altered the internal structure and handling of archives and installers. For the first time, developers could set all conditions, package assignments, and actions individually to items nested inside folders. We also added long overdue support for hierarchical packages. InstallerMaker 5.3 solidifies and strengthens our earlier work through code optimizations and completion of full scripting support.
InstallerMaker's Network or Internet support includes both FTP and HTTP file transfers. Developers create "Network Install" tasks for the files to be retrieved. These tasks consist primarily of the name of the host to retrieve the file from and the path leading to the file. Developers may optionally choose to configure their installers to automatically decode BinHex and MacBinary files and decompress StuffIt .sit files and .zip files. It's very easy to use, flexible, and has powerful installer technology.
The 5.0 release focused on the functionality most requested by our customers. InstallerMaker has always required conditions, package assignments, and actions to be set only at the root level of archives, which meant items in folders would always receive the same settings as their root parents. This made it difficult to create a single installed folder with items installed based on many different criteria. Developers had to use folder factoring, a process by which multiple folders of the same name in an archive are merged together during installation, to build these installers. Version 5.0 blew away that barrier, so now every archive item may be individually assigned different conditions, packages, and actions.
Hierarchical packages were also a big part of the 5.0 release. We worked hard to make it easy to configure for developers and easy to use for their customers. We wanted to preserve the original functionality, for developers not wishing to use the new support, while extending the feature set out for those who did. We also shied away from changing the design toward things we didn't like about other installers we have seen, which we considered less intuitive and thus less user friendly to use. Specifically, we wanted to keep the descriptions of packages displaying in the main installer window automatically when a user clicked on a package name. We also added a selection button with a question mark on it next to each package in a package list. We wanted to get users connected with information as efficiently as possible.
InstallerMaker 5.3 is a developer's dream release, especially if an automated build system is the goal. This release fills out all the nooks and crannies of automatic generation of installers through AppleScript. InstallerMaker 5.3, with the new native AppleScript support in MacOS 8.5, is a powerful combination for supporting an automated build system. We also provide a FileMaker Pro database example, used in conjunction with AppleScripts, demonstrating a complete automated build system. Aladdin uses a derivative of that example for our own automated build system for our products. The database allows product managers to file installer requests that are easily turned into automatically generated installers for Aladdin products. It's a really fluid process and quite elegant in how it handles our installer needs.
Dave: I've heard about a product called FlashBack. What can you tell me about it?
Peter: Aladdin FlashBack provides unlimited Undo's for any application with instant access to all previous versions of a document. With Aladdin FlashBack, you can create, compose, edit and save documents in any application without the fear of ever losing their work. It recovers previously saved versions of any FlashBack-protected document, even if the original file is lost, damaged, overwritten or erased. It tracks and records only the changes made to a document each time it is saved, eliminating the need for "Save As...."
To "FlashBack" a document, the user simply drags and drops the file into the Aladdin FlashBack window. Every time the file is saved, FlashBack uses a "differencing engine" to compare the current file to the previously saved version and captures and records the changes. Only the changes between these two files are recorded and saved by the FlashBack application (under the same title with a time and date stamp), so disk space is reduced compared to the conventional "Save As...."
The FlashBack application window lists all the tracked files and their versions. To retrieve a previous version, the user simply double-clicks on the selected version, or drags it to the desktop. FlashBack launches the file's application (if it is not already running) and combines the current document with the difference files to generate the version the user selected. The file is recreated exactly as it was at the time and date indicated.
FlashBack maximizes efficiency by letting the user set the frequency with which it records changes. The user can configure FlashBack to track changes whenever a document is saved, or whenever it is closed. With programs that have an auto-save function, FlashBack can be set to save changes every few minutes, instead of every instant, since many auto-save programs save so frequently. Settings can be made on a default basis, or tailored to a file or application.
