USB Adapter Connects Palm Devices — Palm organizer owners frustrated by the lack of a direct USB solution for connecting their HotSync cradle to iMacs or blue and white Power Macintosh G3 machines can now purchase Keyspan’s $40 USB PDA Adapter. Currently, owners of USB-enabled Macs need the combination of a USB-to-serial adapter and Palm Computing’s MacPac adapter to synchronize their Palm handheld devices with data on their Mac. The USB PDA Adapter provides a direct link from the Mac’s USB port to the DB-9 serial connector found on the Palm HotSync cradle and stand-alone HotSync cable. (For more about Palm handhelds, see our "Reading the Palm" series of TidBITS articles.) According to Keyspan, the device also works with serial-equipped Wacom digitizing tablets. [JLC]

<http://www.keyspan.com/products/usb/pdaadapter/>

<http://www.palm.com/macintosh/>

<https://tidbits.com/getbits.acgi?tbser=1030>

Mailsmith 1.1.3 Update from Bare Bones — Bare Bones Software has released version 1.1.3 of Mailsmith, their sophisticated POP and SMTP email program. Version 1.1.3 includes a new POP Monitor window that enables users to download or delete messages selectively from a remote POP server, enhanced manipulation of quoted text in messages, improvements to Mailsmith’s mail storage database, and an assortment of interface enhancements and feature additions (a full list of changes is available). The Mailsmith 1.1.3 updater is a 3 MB download, free to current Mailsmith owners. Mailsmith costs $79 directly from Bare Bones, although BBEdit and BBEdit Lite users as well as owners of Qualcomm’s Eudora or Claris Emailer can take advantage of a $59 discounted price. You can download a free Mailsmith demo (3.6 MB) from the Bare Bones Web site. [GD]

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

A recent expedition through my Preferences folder uncovered the fossils of utilities and other programs I’ve installed and removed during the past several months. These abandoned preferences files shared names with applications that seemed worth trying but didn’t end up on the list of tools I use regularly. At the same time, my system spelunking highlighted a few programs I tend to forget about – not because they’ve been relegated to some deeply nested folder, but because their features have become second nature. One of these gems is St. Clair Software’s Default Folder.

<http://www.stclairsoft.com/DefaultFolder/>

Default Folder enhances traditional Open and Save dialog boxes, as well as newer Navigation Services dialogs, by enabling you to access frequently used folders without having to wend your way through the Finder’s file hierarchy one directory at a time. This capability not only makes file manipulation smoother but also saves time in the long run.

Default Folder creates a row of four buttons in Open and Save dialog boxes that appears when your cursor passes over the name of the current hard disk in the upper-right corner. Pressing the buttons brings up pop-up menus that let you select recently used folders, access folders you’ve marked as Favorites, switch between mounted hard disk volumes, and use Default Folder’s file utility features. In Navigation Services windows, three of these buttons are already present: Favorites, Shortcuts (which is similar to the Disks button in standard Open and Save dialogs), and Recent. Default Folder adds its Utility button to the left of these.

Default Folder also creates Favorites and Recent folders in the Apple menu and includes a Control Strip module, enabling you to open deeply nested folders with a single action in the Finder.

It’s Your Own Default — The heart of Default Folder is the capability to make Open and Save dialogs jump to a preferred folder when you use an application. For example, if you store all of your FileMaker Pro databases in one central folder, you can set that as your default location. Default folders can be assigned for each application you use, or you can specify one folder that all applications will use. This reduces the possibility of inadvertently saving a file where you won’t be able to locate it easily later. From now on, that folder will be selected when you open or save a file for the first time after launching the application. You can also press Command-U or select the first item from the Favorites menu to jump to that folder at any time. Default Folder remembers the location of the last file you opened or saved, so jumping quickly to your chosen directory can often save you the hassle of navigating back to your default.

Direct Your Directories — I tend to work on four or five projects concurrently, so much of my time is concentrated within a handful of folders. I could open them all in the Finder for easy access, or set them as pop-up windows at the bottom of the screen, but I don’t like to clutter my desktop with items I’m not actively using, and I already have five pop-up windows.

Instead, I access my regular folders from any Open or Save dialog box by selecting them from Default Folder’s Favorites menu. This is by far the feature I use most, because Default Folder assigns a numbered keyboard shortcut (such as Command-2) to your Favorite folders. Although you can’t change the shortcut key (which is based on the position your folder appears in the Favorites list) you can dictate the list’s order in Default Folder’s control panel. Now, whenever I need to access TidBITS-related files, I type Command-1 in any Open or Save dialog box. It’s also handy to use this feature as a point of reference: if I need to get to a folder that’s at the same level as TidBITS (another project, for instance) but I’m in the middle of another directory or volume, I can type Command-1, then navigate up one level in the hierarchy to access my folder. With only a minute or two of setup time, I’ve changed a multiple step action into a series of two or three keystrokes. Since I’m also a big fan of being able to do as much as possible from the keyboard, Default Folder also cuts down on the number of times I reach for the mouse.

Another feature I find invaluable, to my surprise, is the capability to click on any open window on the desktop while in an Open or Save dialog to move directly to that folder. True, I try not to leave too many windows open on the Desktop, but often it’s helpful to display a few directory windows that I’m using, then switch quickly between them with the click of a mouse. I’ve found this to be particularly helpful with my pop-up windows in the Finder, allowing me to view each folder easily by clicking on its tab at the bottom of the screen. This works with open windows that are hidden behind applications, as well.

The latest version of Default Folder added a nice twist to this feature: if you click and hold the mouse cursor outside of your Open or Save dialog, you’re presented with a contextual pop-up menu that lists all open folders on the Desktop.

Folder Sets — If you find yourself moving between multiple folders repeatedly, Default Folder can create folder sets that help to focus your efforts. I tend to stick with just one set because I don’t use a large number of folders in my work; however, I could easily split my tasks between writing-related and design-related tasks. For example, when I’m focusing on one task, I don’t necessarily want to clutter my Default Folder menus with items associated with something else. In this case I would set up two sets in the Default Folder control panel, and include folders specific to each task in the sets. When you have two or more sets in use, you can switch between them using the Utility menu, or by pressing a key combination (Command-Option-2, for example). Sets can also be exported or imported.

More Features Beneath the Surface — Although Default Folder devotes itself to switching between folders, several other useful features are also available. From any Open or Save dialog, you can create new folders, rename files or folders, or move items to the Trash without exiting to the Finder. It’s also possible to get information about a file, such as its size, creation and modification dates, and its type and creator codes (which can be edited in Default Folder’s advanced mode).

You can speed up the display of folder lists by choosing to show only generic icons. Other settings control the size of the Recent menu, add the capability to display files of any type by Option-clicking the list, and control whether recent files are listed chronologically or alphabetically. Default Folder also works in conjunction with utilities such as Apollo, DragStrip, DragThing, Dialog View, and KeyQuencer to increase their directory navigation abilities.

<http://www.dcs.qmw.ac.uk/~jeremyr/apollo.html>

<http://www.poppybank.com/DragStrip/>

<http://www.dragthing.com/>

<http://members.aol.com/jwwalker/pages/dv.html>

<http://www.binarysoft.com/kqmac/kqmac.html>

Default Folder has become one with my Mac, as far as I’m concerned. Using a computer that doesn’t have Default Folder’s features feels awkward and limiting now, forcing me to map directory structures in my mind as I work, rather than allowing me to concentrate on the task at hand. Although other utilities (like Action Files; see "Get a Piece of the ACTION Files" in TidBITS-434) offer similar features, Default Folder is a leaner program that doesn’t try to accomplish every conceivable file-related task. For the shareware price of $25, this 930K download will pay for itself within hours of using it.

<https://tidbits.com/getbits.acgi?tbart=04931>

This is a bit embarrassing, but I’ve saved nearly every TidBITS-related email message I’ve received since joining the TidBITS staff in late 1994. Sure, I delete unsubscribe requests, vacation notices, junk mail, and the like, but I’ve kept almost everything else, particularly messages from readers and internal email amongst the staff.

According to that email archive, I’ve been avoiding writing about the year 2000 and the Macintosh since we first talked about such an article in February of 1995. Why? In part, I don’t find Y2K issues – known variously as "the Year 2000 Problem" or "the Millennium Bug" – particularly interesting. Although their ramifications are wide-ranging, Y2K issues are straightforward as computing problems go, and Macintosh hardware and system software have never had trouble dealing with the year 2000. Writing about Y2K and the Macintosh seemed about as relevant as writing about the dangers of highway driving and cars. The topic might be pertinent to many TidBITS readers, but it’s not why people read TidBITS.

Things have changed since 1995. Y2K topics have moved from a fringe technology issue to a mainstream cultural thread covered continuously by newspapers, television programs, and Web sites. Opinions and analyses diverge widely. Some experts predict doom and global chaos, and some people are literally heading for the hills. Others experts claim Y2K issues will be minor or nearly non-existent (especially in the United States) and some people think the entire Y2K brouhaha is a conspiracy to sucker users and companies into paying for expensive upgrades and consulting. Further, a great deal of Y2K discussion emphasizes that no one really knows how profound – or how trivial – the problems may be. Mass media messages about Y2K issues are decidedly mixed, creating a sense of trepidation among many people which seems to be increasing as the end of the century draws closer.

Apple hasn’t ignored society’s growing millennial anxiety. In fact, Apple has been trumpeting the Macintosh’s "Y2K compliance" with irreverent quotes, Web sites, and even a television commercial broadcast during the 1999 Super Bowl.

<http://www.apple.com/hotnews/features/hal.html>

Although Apple’s smugness may not be endearing, for the most part it’s justified. The Macintosh truly has been ready for the end of the century since it first rolled off production lines in 1984, something mouse-thumping Macintosh advocates espouse as an indication of the Mac’s superiority. However, the integrity of the Macintosh’s hardware and software design doesn’t necessarily mean Macintosh users can blindly assume their computers will be unaffected by Y2K issues.

Defining Y2K — Fundamentally, Y2K problems concern a system’s inability to process century information in dates correctly. This definition is different from the widely held belief that Y2K problems involve a computer interpreting a two-digit year as if it were in the 1900s – how a system handles the omission of century information is a subset of the larger issue. Although opinions vary, in my mind a program is "Y2K compliant" so long as it correctly handles dates with century information. In other words, if I enter "01-Jan-00" into an application and it interprets the year as 1900, I might be unhappy or seriously inconvenienced, but in fact, a two-digit year can easily be interpreted as any year divisible by 100, including 1200, 1600, or 2300. I wouldn’t consider this behavior a "Y2K problem" unless the program rejected or otherwise misinterpreted "01-Jan-2000." The former case stems from a conflict between the program’s assumptions and my expectations, while the latter stems from a genuine problem with the program’s treatment of dates.

Humans often interpret century information by context. If you have an airline ticket dated 05-Apr-99, common sense tells you the ticket doesn’t refer to 1899, since the Wright brothers didn’t make their famous flight at Kitty Hawk until 1903. The context isn’t as clear if you have a train ticket with the same date, although, if nothing else, changes in pricing, typographic style, and ticket materials would probably clue you in.

Computers don’t pick up on contextual clues: they simply do whatever programmers tell them to do. In many cases, programers effectively tell computers "all dates are in the 20th century," or "if you see a date without century information, always assume it’s in the 20th century" which is a problem if the program doesn’t store any century information. The implications are widespread – some systems may crash or do the wrong thing based on unanticipated results from date-based math, some may refuse to start up, some may corrupt data, and others may assess a century’s worth of interest penalties. Further, since microcontrollers using date information are present in everything from mainframes to coffee makers, determining what systems have century-related date problems (and what the impact of those problems might be) is an enormously complicated task.

Why did programmers make these seemingly brain-dead errors? In some cases, they weren’t errors. Sometimes programmers omitted redundant century information to save memory and storage space: after all, in 1970 a megabyte of memory could cost more than $3 million and may have been larger than a breadbox. In other cases, programmers had little thought for the future because it was inconceivable to them that their software would be in use fifteen, twenty, or thirty years in the future. And sometimes programmers, being human, simply screwed up.

Y2K & Your Mac — Macintosh hardware and system software from Apple is Y2K compliant – there’s no fundamental "Y2K time bomb" ticking away inside your Macintosh. You can check out Apple’s Y2K readiness disclosure, as well as a list of products Apple has tested for Y2K problems.

<http://www.apple.com/about/year2000/>

Although it’s slightly obscured by a self-satisfied attitude, Apple’s statement basically says that Macs won’t have problems changing over to the year 2000, but that they don’t make any promises regarding third-party products, including macros and custom programming. Obviously, Apple can’t guarantee other company’s products, but so long as those products use the date routines built into the Macintosh system software – and the vast majority of Mac programs do – they’ll be fine. Software on the original Macintoshes can handle dates from January 1, 1904 to February 6, 2040; most Macintosh software released in the last decade uses a more expansive date system that can handle dates from about 30,081 B.C.E. (Before Common Era) to 29,940 C.E. (Common Era), along with non-Gregorian calendar systems.

The two most common cases where a Macintosh application would not use the date routines provided by the Mac OS are when it needs to use dates in a wider range, or when it needs to use date data or procedures originally developed for another operating system. Examples could include programs that model processes that take place over very long periods of time (like geology or stellar evolution), or Macintosh ports of programs for genealogy, statistics, or specialized vertical markets that must read and write date information used by other platforms – these programs may inherit Y2K issues that don’t originate on the Macintosh.

Your expectation of Y2K compliance might be another matter. Once the calendar ticks over to the year 2000, you may find some Macintosh programs interpret two-digit years as if they were in the 1900s. Again, unless the program rejects or misinterprets a four-digit year, I wouldn’t consider the program broken, although the behavior may be annoying – like an unwanted toolbar or a frequently used command without a keystroke equivalent. Some programs have "date windows" which define how they interpret two-digit years. For instance, in order to be compatible with System 6, Apple’s Date & Time control panel still limits user input to years between 1920 and 2019. Current versions of Microsoft Excel handle four-digit years but assume any two-digit year less than or equal to 29 is in the 2000s, while two-digit years 30 and over are in the 1900s. Similarly, current versions of FileMaker Pro handle four-digit years, but use a convoluted window for two digit years, revolving around the first and last decades of the current and preceding century. (Although there are still cases where FileMaker interprets two-digit years provided by formulas or scripting as being the 1900s.)

I haven’t been able to find a comprehensive clearinghouse for Macintosh Y2K issues, but Rich Barron is maintaining a list at his Macnologist site; it’s a little apocryphal in places, but serves as a reasonable starting point. The best place to look for information about a specific application is with the program’s developer (assuming they’re still in business).

<http://www.macnologist.com/y2k/>

But Macs Are Immune! The greatest potential for Y2K issues on the Macintosh stems from custom utilities and applications, rather than from the Mac OS or major commercial products. Developers usually know about the Mac OS’s internal date capabilities; however, consultants, hobbyists, interns, and everyday Macintosh users may not know about them, or have the tools to access them reliably. Further, because these people aren’t necessarily experienced developers, they’re more likely to make math errors or incorrect assumptions about dates. Even if the Mac OS and the tools used are Y2K compliant, it’s entirely possible to create macros and custom solutions that exhibit classic Y2K problems.

For example, a few months ago a local non-profit organization asked me to identify and fix a "printing problem" with their donations system developed by a former volunteer a few years before in FileMaker Pro. The system is designed to project revenue forward into the next year based on pledges from their supporters, many of whom commit to regular, periodic contributions. The system wasn’t printing projected donations beyond 1999. "This isn’t a millennium bug, is it?" they asked. "It’s only January 1999! Aren’t Macs supposed to be immune?"

A few minutes in their databases revealed a typical Y2K problem. The system created donation numbers based on a donor’s identification number and level of support, prefixed with (you guessed it) the month and year of the anticipated donation. A typical donation ID might be 9904-4-1234, where "9904" indicated the year and month of the expected donation. These prefixes were used for sorting – it turned out the system was creating the appropriate projections, but they were sorting incorrectly and the database operator didn’t know how to find them. Further questioning revealed the number format they’d chosen was deliberate: it was designed to be easy to read over the telephone and to match donation numbers used in a paper-based accounting system dating back to the 1950s. Fixing the problem was simple, but the organization took weeks to decide on the changes that would work best for them, since the numbers are used widely throughout their operations.

This example happened in a FileMaker Pro database, but similar problems can (and do) exist in custom software built using a variety of tools, including but not limited to HyperCard, SuperCard, AppleScript, FaceSpan, utility programs like OneClick, and internal programming languages like Microsoft’s Visual Basic for Applications – all of which are themselves Y2K compliant! Similarly, it’s easy for users to make date errors in spreadsheet formulas in Excel or ClarisWorks, JavaScript scripts embedded in Web pages, or any number of other places.

Leap of Faith — For folks who want to look beyond January 1, 2000, the year 2000 is a leap year, and therefore date-dependent systems need to account for February 29, 2000. Again, the Macintosh handles this date correctly, but a few computers stumble over it – in fact, Connectix had to update Virtual PC to 2.1.1 (now at 2.1.2) because its emulated clock chip failed to recognize this leap day.

<http://www.connectix.com/html/vpc_updates.html>

The Gregorian calendar calls for a leap year whenever a year is divisible by 4, but not in years divisible by 100 unless they in turn are divisible by 400. Ironically, the year 2000 being a leap year sometimes isn’t a problem for home-grown utilities, which (if they account for leap years at all) usually assume any year evenly divisible by four is a leap year. Thus, they would incorrectly consider 1900 and 2100 as leap years, but would behave correctly with the year 2000.

<http://es.rice.edu/ES/humsoc/Galileo/Things/ gregorian_calendar.html>

If you’re curious, the Mac OS does not account for leap seconds (nor do other mainstream devices or operating systems). Leap seconds are a periodic adjustment made to atomic clocks to keep them in sync with the rotation of the Earth, which slows by about two milliseconds a day.

<http://maia.usno.navy.mil/eo/leapsec.html>

Best Advice — The Macintosh is remarkably well prepared for the year 2000. For the most part, normal Macintosh users don’t have a thing to worry about.

If you use specialized commercial software – particularly if it’s ported from another platform – you should contact the program’s vendor to see if they’re aware of any Y2K issues. If you rely on home-grown macros or custom software, you should check to see if it’s ready for the year 2000 or test it yourself, even if it’s developed using tools that are Y2K compliant. A basic three-in-one test for Y2K problems would be:

• Make a complete backup of your Macintosh. Consider disabling any automatic backup or scheduling utilities so they aren’t confused by the following steps.

• Set your Macintosh’s clock to 11:59 PM on February 28th, 2000.

• Wait a minute, then check your computer’s clock to verify it handled the leap year correctly.

• Use your custom tools as you would normally, taking care to exercise each feature in some depth. It’s hard to offer specific advice, but you may need to create and delete records, input new data, sort, or perform comparisons. Obviously, focus on functions that are in some way date-dependent.

  
  

Y10K — Before anyone asks, yes, many Macintosh programs need to be revised to accommodate five-digit years, although the Mac OS can handle them just fine. We promise that TidBITS-384730 will cover the topic in detail.