Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue

TidBITS Logo

TidBITS#450/12-Oct-98

Our examination of how moderately normal people can use MacsBug continues this week and includes valuable information on how to create logs for developers when you're beta testing a program. Also in this issue, Adam looks at the apparent demise of Claris Emailer, and we note important software releases including QuarkXPress 4.04, Eudora Pro 4.0.2, AutoShare 3.0, and FileMaker Pro 4.0v2, and the "almost here" StuffIt Deluxe 5.0.

Topics:

Copyright 1998 TidBITS Electronic Publishing. All rights reserved.
Information: <info@tidbits.com> Comments: <editors@tidbits.com>


This issue of TidBITS sponsored in part by:


MailBITS/12-Oct-98

QuarkXPress 4.04 Update Addresses Numerous Bugs -- Quark has released an update to QuarkXPress 4.0 that fixes several bugs related to saving and printing, Find/Change operations, Bezier lines with arrowheads, and other miscellaneous problems. Additionally, Quark has modified the scripting syntax in the AppleScript dictionary to include new 4.0 features and work better with existing scripts. Owners of version 4.03 can download a 3 MB updater; owners of earlier versions of QuarkXPress 4.0 should download the 8.2 MB "universal updater." [JLC]

<http://www.quark.com/quarkxpress/qxpfix_1.html>

Eudora Pro 4.0.2 Now Available -- Although Eudora Pro 4.1 remains in public beta, Qualcomm has finally released Eudora Pro 4.0.2, which fixes a number of minor bugs and nagging annoyances. If you're having troubles with Eudora Pro 4.0.1, it's worth downloading the free 5 MB updater; otherwise I'd recommend waiting for version 4.1. [ACE]

<http://eudora.qualcomm.com/betas/epro41.html>
<http://eudora.qualcomm.com/pro_email/updaters.html>

AutoShare 3.0 Released -- Mikael Hansen has released version 3.0 of AutoShare, his freeware mailing list manager and auto-responder that works with Eudora Internet Mail Server and Stalker Internet Mail Server. Major new features include support for internal and external subscriber databases, support for MIME digests, additional remote email administration commands, and support for more bounce formats. The most interesting feature is the support for subscriber databases, which enable you to add your own fields. AutoShare communicates with external databases via scripting, which provides good flexibility but can suffer from poor performance. AutoShare 3.0 is a 1.9 MB download. [ACE]

<http://www.dnai.com/~meh/autoshare/>

StuffIt Deluxe 5.0 Announced -- Aladdin Systems has announced StuffIt Deluxe 5.0, a major release of their popular compression program. StuffIt Deluxe 5.0's main new feature is a new compression format that's 20 percent smaller and provides compatibility with Windows. Also included in StuffIt Deluxe 5.0 are support for MacBinary III, compatibility with Mac OS 8.5, additional "Archive Via Rename" functionality for .hqx and .bin, fast conversion of self-extracting archives to StuffIt archives, and new support for Outlook Express and Mailsmith in the "Stuff and Mail" feature. Aladdin expects to ship StuffIt Deluxe 5.0 by the end of October for an estimated street price of $79.95; user group pricing will be $49.95. Existing StuffIt Deluxe and DropStuff owners - plus owners of AutoDoubler, DiskDoubler and the Eudora Productivity Toolkit - can upgrade to StuffIt Deluxe 5.0 for $29.95 through 31-Mar-99 with proof of purchase (such as your Aladdin registration number, or by faxing a photocopy of a receipt, manual, or disk to Customer Service at 831/761-6206). StuffIt Deluxe requires a 68020 Mac or later with 8 MB of RAM and System 7.5.3 or later. [ACE]

<http://www.aladdinsys.com/company/news/releases/stuffit/100798-predlx50.html>

FileMaker Pro 4.0v2 Updater Available -- FileMaker, Inc. has released a free FileMaker Pro 4.0v2 updater, which brings the changes and bug fixes found in FileMaker Pro 4.1 to FileMaker Pro 4.0 users without 4.1's new ODBC features (see "FileMaker Pro 4.1 Does ODBC for a Price" in TidBITS-447). Enhancements include the capability to import Excel 98 files, support for the Euro currency symbol, improvements to JPEG display within FileMaker, and several bug fixes related to importing, exporting, deleting, and sorting records in specific situations. The Mac OS updater is 1.8 MB; updaters are also available for various versions of Microsoft Windows. [GD]

<http://www.filemaker.com/support/>
<http://db.tidbits.com/getbits.acgi?tbart=05091>
<ftp://ftp.filemaker.com/pub/USA-Macintosh/Updaters/FileMakerPro40v2Update.bin>


Emailer and the Death of Software

by Adam C. Engst <ace@tidbits.com>

Was anyone surprised when Emailer languished after being brought back into Apple in the Claris-to-FileMaker, Inc. transformation? Perhaps Emailer users were, since there's little that inspires blind loyalty like a good program you use all day, every day. Emailer was and is a good email program, and frankly, it deserves better than to fade away into the bit bucket. Unfortunately, despite several petition drives, that's what I see happening, unless... well, let's not get ahead of ourselves.

<http://www.macsoldiers.com/save-emailer/>
<http://www.pasoftware.com/save_emailer.shtml>

Think for a moment about Apple's position as the Macintosh company. Apple must always tread a fine line between adding capabilities to the Macintosh and maintaining good relations with Macintosh developers. Apple could crush almost any Macintosh product by building similar functionality into the Mac OS. It's happened in the past, and it will happen in the future: AppleScript undermined UserLand Frontier as a commercial scripting tool; PlainTalk has impeded development of sophisticated speech recognition software; and countless shareware products have been mothballed over the years as items like hierarchical Apple menus and desktop pictures were integrated into the operating system. Apple must do these things carefully and without malice, or the company risks alienating the very developers who power the Macintosh.

Revisions Necessary -- So Apple now holds a powerful but aging email client. Although Emailer has numerous great features on top of a solid base, its primary competition - Eudora Pro and Outlook Express - have leapfrogged Emailer's feature set. They added support for multiple accounts, HTML-styled mail, LDAP directory services, IMAP for retrieving mail, inline spell checking, and much more. If that weren't enough, new email programs like Mailsmith from Bare Bones Software and PowerMail from CTM Development have further divided the market. Today, Emailer's main unique feature is its ability to pick up mail from CompuServe and AOL.

<http://web.barebones.com/products/msmith/msmith.html>
<http://www.ctmdev.com/>

Revising Emailer to compete wouldn't be a trivial task, since adding support for HTML-styled mail requires adding an HTML parser and modifying the display engine. IMAP support could require significant modifications to the code that retrieves mail, and IMAP requires a rethinking of how mailboxes work due to its method of storing mail on the server. Apple either has or could hire the talent necessary to update Emailer, but that costs money, and Apple is still concentrating on keeping the company in the black. Projects that might not earn a profit aren't likely to live long in today's Apple Computer.

Apple's Options -- For the moment, however, let's assume that Apple would be willing to put the effort and money into bringing Emailer up to speed. What then?

Another option arises if Apple decides not to update Emailer. Giving the current version of Emailer away for free wouldn't cost anything except some good will with developers. But it also hurts the entire email community by slowing the acceptance of new capabilities that require interoperability. For instance, a set of standard headers have been approved for use by mailing lists to make it easier for email programs to identify mailing list postings and automate tasks like subscribing, unsubscribing, posting, getting help, and so on. Without support for those new headers in email programs (which wouldn't happen in a moribund Emailer), mailing list administrators would have less incentive to implement the new headers, reducing their utility to the rest of us.

<http://info.internet.isi.edu/in-notes/rfc/files/rfc2369.txt>
<http://search.ietf.org/internet-drafts/draft-chandhok-listid-01.txt>

Adopting Emailer -- Faced with little chance for profit from Emailer and a strong possibility for alienating a number of Macintosh developers, Apple could consider selling Emailer to another company. That's how 3Com picked up Claris Organizer for use with the PalmPilot; in fact, we've heard that Apple has shopped Emailer around.

<http://db.tidbits.com/getbits.acgi?tbart=04874>

The problem is that any company that buys Emailer from Apple must still make the business case for spending more money updating and marketing Emailer. The decision would easier with less competition, but competing against a set of powerful programs that range from free to inexpensive isn't a recipe for business success. The main argument in its favor is that a small company like Fog City Software (the company that originally developed Emailer, though Emailer's lead developer now works on Outlook Express) wouldn't need to sell as many copies as a giant like Apple to turn a profit. Even still, marketing software isn't cheap, and that's especially true of inexpensive software, where you need high sales volume to break even on a marketing campaign.

So, although it could still happen, I can't see any well-known Macintosh company buying and resuscitating Emailer. The best commercial option would be some well-funded unknown that wanted to use it as their introduction to the Macintosh market. They'd certainly get significant word of mouth from the current Emailer users, and that kind of notoriety is tremendously valuable.

If I'm right and Emailer stands little chance of surviving in any of these different ways, perhaps there's an alternative? Tune in next week for thoughts on how we can save both Emailer and a variety of other worthwhile programs that have met untimely ends.


MacsBug for the Merely Geeky, Part Two

by Geoff Duncan <geoff@tidbits.com>

The first part of this article in TidBITS-449 looked at MacsBug, Apple's free low-level debugger, explained how to install and invoke it, and how to use MacsBug to recover from application crashes. It also discussed looking up system error numbers with MacsBug, plus converting between decimal and hexadecimal and doing basic math.

<http://db.tidbits.com/getbits.acgi?tbart=05118>

This time, we'll take a look at some MacsBug commands that reveal detailed information about your system and its applications. We'll also explain a bit about how your Macintosh and applications use memory, as well as how to make problem logs using MacsBug. MacsBug still isn't a friendly piece of software I'd recommend to all Macintosh users, but if you've come this far, going a little further won't hurt.

By Your Command -- Let's take a look at some common (yet useful) MacsBug commands. These and other commands are case insensitive; it doesn't matter if you capitalize them the way I've written them here. MacsBug also has a Help command that displays often-cryptic descriptions of these and other commands. Although you'll see many of MacsBug's capabilities have to do with obscure functions like traps, breakpoints, and disassembly, there are some useful gems to be found. Type Help Misc for a small sampling.

Thanks Heaps -- Each application running on your Mac stores windows, dialogs, documents, and other data in an area of RAM called its application heap. The size of a heap varies with the amount of memory allocated to an application. The system also has a heap, and it's the only one the Mac OS can resize on the fly. To change the size of an application heap, you must quit the program, change its memory settings in its Get Info window, then re-launch the program. This is one of the reasons proponents of other operating systems say the Mac OS has a weak memory model.

Heaps are divided into blocks, which can either be free (unused), relocatable (in use, but movable), or locked (in use and unmovable). Blocks in use can also be marked as purgeable, meaning that the application would prefer the data stay in RAM, but it can be released (purged) if the program needs more free memory. Each block of memory begins with a header containing some information about the memory block.

An application heap is a little like a disk in that it can become fragmented. As a program uses and releases memory (say, opening and closing documents), both free and occupied blocks of memory can become scattered throughout the heap. If the blocks are relocatable, the application re-organizes them to create larger areas of free space - just like optimizing a hard drive. If the blocks are locked, however, they can't be moved and the application may not be able to handle requests for large blocks of memory (say, to open a big document), even though there might be enough total free memory for the request.

Given this, you might wonder why programs ever use locked blocks. The reasons vary, but a good example is playing a movie. If the memory block containing a movie could be moved at any instant, the application would constantly have to check whether the memory had moved, which would destroy performance. By being able to guarantee the block won't move, the program can concentrate on playing the movie, then (in theory) give back the memory when its done. Some applications use more locked memory than others, but all applications use some.

Heaps can also become corrupted, usually when a program puts more data into a block than it was intended to hold. When this happens, it usually overwrites the header of the next block, and the Mac's Memory Manager loses track of that next block. The consequences can range from unnoticeable to disastrous, depending on the nature of that next block of memory.

If you'd like a program that graphically displays areas of an application's heap (and can peer into heap blocks), check out Joshua Golub's ZoneRanger, a 517K download from Metrowerks's Web site. It's a little unstable under recent versions of the Mac OS, but it's useful and educational.

<http://www.metrowerks.com/tools/software/zoneranger.html>

MacsBug can tell you heaps about your heaps.

Logging Problems -- Because MacsBug is so good at uncovering information about your current application and the state of your Macintosh, it's useful for folks who are testing or evaluating software, as well as for software programmers. The only difficulty is determining what information is relevant when you're reporting a bug.

Fortunately, the folks who make MacsBug have made this easy for you. The StdLog command, as the name implies, creates a text file with a standardized log of information developers commonly need when they're investigating a bug. These logs are pretty big (usually about 20K), and contain the results of several MacsBug commands, including many discussed here. When you use the StdLog command, the log appears as a text file named StdLog on the desktop. If you use the StdLog command again, the information will be appended to any existing file named StdLog, rather than overwriting it.

Unless you're already in contact with the program's developer, I don't recommend sending a standard log via email as a bug report. Instead, describe the bug succinctly, and indicate you've made a MacsBug log of the problem, which you can send they like. Hang on to the file. Some developers will disagree with me, but, having handled my share of bug reports received via email, large reports with attachments are more awkward than concise notes. Frankly, if a program is in public testing, there should be few new bugs turning up. It's not particularly useful for a developer to receive dozens of log files about a problem that's already known and possibly already fixed.

Another Break Point -- In the next part of this article, we'll take a quick look at using MacsBug to restart machines automatically in the event of a crash. If you'd like more information about MacsBug, check out Apple's MacsBug Reference and Debugging Guide, available in Acrobat PDF format. Although it hasn't been updated since MacsBug 6.2 in 1991, this guide still offers detailed information on the inner workings of Macintosh memory management, plus traps, disassembly, and much more.

<http://developer.apple.com/dev/tools/debuggers/MacsBug/Documentation/MacsBugRef_6.2.pdf>

In addition, the weekly journal MWJ published a lengthy two-part article earlier this year called MacsBug for Non-Programmers, which discusses several MacsBug features not covered here, including analyzing heaps and both displaying and searching memory. Both parts are reprinted on Ted Landau's MacFixIt site. If you can't get enough insightful Macintosh news, sign up for a free, no-obligation, three-week trial subscription to MWJ in time for their Mac OS 8.5 coverage, or download some free sample issues.

<http://www.macfixit.com/reports/MacsBug.shtml>
<http://www.gcsf.com/pages/mwj/>


Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017.

Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue