Eudora 4.3.1 Replaces Version 4.3 — After an initial abortive release of Eudora 4.3, Qualcomm quickly uploaded version 4.3.1, which fixes a bug caused by a single line of code being inadvertently removed in the final compile. The bug? In Sponsored mode, Eudora 4.3 wouldn’t fetch ads. Unfortunately, Eudora 4.3 will get cranky and start nagging after not receiving ads for several days and will automatically switch down to Light mode after a few weeks. So if you downloaded 4.3 and are using it in Sponsored mode, you’ll want to get 4.3.1 instead. Again, if you’re a current Eudora Pro 4.x user, wait for the updater that will bring you up to Eudora 4.3 and register you in Paid mode, due later this week – the full Eudora 4.3.1 won’t accept Eudora 4.x registration numbers. The updater, initially slated for last week, is now scheduled to become available later this week.

<http://www.eudora.com/download/>

<http://www.eudora.com/email/upgrade/>

Also note that we biffed the system requirements for Eudora slightly in last week’s article in TidBITS-517. Eudora 4.3.1 requires a PowerPC-based Mac with Mac OS 7.6 or above with QuickTime 3.0.2 or later (which you can download from the custom installation screen in Eudora’s installer). Eudora 4.3.1 is a 5.6 MB download. [ACE]

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

GraphicConverter 3.8 Adds AppleScript, Bug Fixes — Lemke Software has updated GraphicConverter to version 3.8, adding AppleScript support to the PowerPC version and numerous tweaks to its multipurpose tool for working with image files. (GraphicConverter ranked high in a recent TidBITS poll of image editing applications; see "Poll Results: They Come in Colors" in TidBITS-516.) GraphicConverter’s basic AppleScript support enables users to apply multiple modifications to files, such as resizing and changing the bit depth, thereby speeding up the production process. GraphicConverter 3.8 is a 1.9 MB download; registration for the shareware utility is $30 in Europe, $35 in the rest of the world. [JLC]

<http://www.graphicconverter.net/>

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

Farallon Announces 11 Mbps SkyLINE Card — Farallon Communications has announced a version of the company’s SkyLINE 802.11 wireless networking card that runs at 11 Mbps instead of the previous speed of 2 Mbps. Due to ship in April, the AirPort-compatible PC Card provides wireless Ethernet access to recent PowerBooks (the 2400, 3400, and G3 Series, with planned support for the 190, 1400, and 5300) and portable PCs with Type II PC Card slots running Windows 95, 98, or NT (with support for Windows 2000 planned). Farallon has yet to announce a price for the 11 Mbps SkyLINE card, but will offer an upgrade for users of the 2 Mbps card at a reduced price. [ACE]

<http://www.farallon.com/news/00_02_16.html>

Microsoft Releases Windows 2000 — Microsoft last week officially released Windows 2000, the successor to the company’s enterprise oriented server operating system Windows NT. Although Windows 2000 has consumer-friendly features like USB support and compatibility with more games, it isn’t an update to Windows 98, and it’s almost certainly not everything that Microsoft’s PR would have you believe (walks, chews gum, does Windows). In fact, despite stories like the now-famous "63,000 bugs" article from Sm@rt Reseller’s Mary Jo Foley, anecdotal comments we’ve heard from friends who ran Windows NT 4.0 indicate Windows 2000 is a credible upgrade. From the Macintosh standpoint, Windows 2000 is interesting primarily for the services it provides to Macintosh clients, and reports we’ve seen indicate those are improved from Windows NT 4.0 – but if you think Microsoft is reaching out to the Macintosh community, check out Macworld writer Philip Michaels’ amusing report on what it was like to be a Mac guy at the San Francisco unveiling of Windows 2000 last week. [ACE]

<http://www.microsoft.com/MAC/msmacproducts/ ntsmac.asp>

<http://macweek.zdnet.com/2000/02/13/ crossplatform.html>

<http://www.zdnet.com/pcweek/stories/news/ 0,4153,2436920,00.html>

<http://www.zdnet.com/filters/special2000/news/>

<http://macworld.zdnet.com/2000/02/18/ windows2000.html>

Poll Results: Ad-ing It Up — Last week’s release of Eudora 4.3 prompted us to ask what TidBITS readers thought about the option of applications displaying advertisements in exchange for enabling commercially available features. We received more than 850 responses which were decidedly split: 47 percent of respondents indicated they liked the idea at least a little, while 53 percent indicated they disliked or strongly disliked the idea. Discussion on TidBITS Talk also varied, although we understand this topic is difficult to nail down to specifics, since Eudora 4.3 is at the moment the only widely used application following this model – and it has been available for only a week. [GD]

<https://tidbits.com/getbits.acgi?tlkthrd=944>

Poll Preview: Color Me Pretty — Apple last week expanded the color palette of its iBook line to include a graphite-themed consumer laptop (see below), re-opening the topic of Apple’s often-brash color selections for its computing products. So, the poll question appearing this week on our home page is: What colors would you like to see Apple use in future Macs? We’ve chosen a few commonly requested themes, but feel free to contribute other ideas to TidBITS Talk! [GD]

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

During his keynote at Macworld Expo Tokyo, Apple CEO Steve Jobs rolled out enhanced versions of Apple’s laptop and professional desktop products. The latest PowerBook G3 (known as the "PowerBook (FireWire)" in Apple’s increasingly inane nomenclature) uses a case similar to the previous PowerBook G3 (Bronze Keyboard) and features speeds up to 500 MHz, up to ten hours of battery life with the dual-battery feature, room for an internal AirPort card, and two new FireWire ports supporting digital video, all for prices between $2,500 and $4,000. Other changes in the PowerBook (FireWire) include different RAM upgrade modules from previous PowerBook G3s, no SCSI port, a new iBook-style power adapter, and a DVD-ROM drive that isn’t compatible with the media bay in the PowerBook G3 (Bronze Keyboard), although batteries and other media bay devices are currently compatible.

<http://www.apple.com/powerbook/>

<http://til.info.apple.com/techinfo.nsf/artnum/ n58581>

<http://til.info.apple.com/techinfo.nsf/artnum/ n58588>

<http://til.info.apple.com/techinfo.nsf/artnum/ n58582>

<http://til.info.apple.com/techinfo.nsf/artnum/ n58586>

The $1,600 iBook product line now sports 64 MB of memory and a 6 GB hard drive in each model, while a new $1,800 graphite-colored iBook Special Edition offers a faster 366 MHz G3 processor. Meanwhile, Apple announced a speed bump for its Power Macintosh G4 line, with the three configurations shipping at 400, 450, and 500 MHz at the same price levels as the previous models, starting at $1,600. These enhancements bring Apple’s G4 systems back to the processor speeds originally announced in August of 1999.

<http://www.apple.com/ibook/>

<http://www.apple.com/powermac/>

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

Also at Macworld Tokyo, Apple announced an agreement with Dai Nippon Screen Manufacturing Co., Ltd., of Japan, to include that company’s high quality Japanese fonts with Mac OS X. The fonts will support the largest character set ever available on personal computers. Mac OS X should be released as a software product in mid-2000, and be pre-loaded on all Macintosh computers in 2001.

<http://www.apple.com/macosx/>

After the January 1999 release of Connectix’s Virtual Game Station, an emulator that enables a PowerPC G3 or better-based Macintosh to play many games designed for Sony’s PlayStation (see "Meet Me at the Virtual Game Station" in TidBITS-471 for a full review), Sony promptly sued to force Connectix to stop selling the product. Connectix won the first round of the lawsuit when the San Francisco District Court rejected Sony’s request for a temporary restraining order on shipments of Virtual Game Station while Sony was applying for a more-restrictive preliminary injunction. Sony prevailed with the preliminary injunction in May of 1999, and Virtual Game Station has been absent from shelves since, undoubtedly causing Connectix great consternation at Macworld Expos. Connectix has also been unable to work on a Windows version of the product, causing the company to lose ground to Bleem, another PlayStation emulator that runs only on Windows.

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

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

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

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

The U.S. Ninth Circuit Court of Appeals recently disagreed with the San Francisco District Court’s ruling in favor of a preliminary injunction though, concluding "Connectix’s reverse engineering of the Sony BIOS extracted from a Sony PlayStation console purchased by Connectix engineers is protected as a fair use. Other intermediate copies of the Sony BIOS made by Connectix, if they infringed Sony’s copyright, do not justify injunctive relief. For these reasons, the district court’s injunction is dissolved and the case is remanded to the district court. We also reverse the district court’s finding that Connectix’s Virtual Game Station has tarnished the Sony PlayStation mark." You can read the entire ruling under case number 99-15892 at the Ninth Circuit Opinions site.

<http://www.ce9.uscourts.gov/web/newopinions.nsf>

The upshot of this is that Virtual Game Station is once again for sale (as from TidBITS sponsor Outpost.com for $20), and you can expect to see a Windows version of Virtual Game Station in the future. However, just because the preliminary injunction has been lifted doesn’t mean that the suit is over; a trial still lies ahead, although the appellate court’s findings may make it difficult for Sony to continue arguing that Virtual Game Station either infringed copyright or tarnished Sony’s trademark.

Sony’s lawyers haven’t given up, filing yet another lawsuit against Connectix, this time claiming patent infringement. This suit stems from the fact that the preliminary injunction in the previous lawsuit was based on copyright law, so Sony is trying again under reportedly weaker patent law. Either way, it seems that Sony’s goal may be merely to tie things up in court long enough to move to a new generation of gaming machines and make Connectix’s PlayStation emulator irrelevant.

For many years, FileMaker Pro has been one of my standard tools for storing and retrieving structured information: with FileMaker, it’s easy to build yourself an address book or a guide to your music collection, and its thorough scriptability makes it splendid for exchanging data with other applications. Version 3.0, dating from 1995, introduced relational database capabilities; but subsequent versions offered so little (and cost so much) that I never upgraded further. Then recently version 5, instead of improving core features, introduced some vastly higher pricing, and I wondered whether I hadn’t backed the wrong horse.

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

Around this time I learned, with surprise, that Odesta’s Helix was still alive. I had used Helix briefly in 1991, but then lost track of it. Helix (soon re-dubbed Double Helix) had been one of the earliest Mac products, dating back to 1984. It was ahead of its time, but was sent down an unproductive development path – basically, much time and effort went into creating a VAX-based server for Helix, whereupon personal computers suddenly got faster and cheaper than a VAX would ever be (can you say Mac IIfx?) – and the company split up in 1992. The product was renamed again, as Helix Express, and more or less languished. Now it has been taken over by The Chip Merchant, which is run by a Helix enthusiast, and is being subjected to the nightmarish process of modernizing ancient legacy code, fixing memory leaks, and squashing bugs. Meanwhile, amazingly, the basic Helix product, now renamed Helix RADE (Rapid Application Development Environment), is free.

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

<http://www.helixtech.com/history.html>

In the Nucleus — Helix RADE (I’ll just call it Helix) is an environment for designing databases and then working with the data (inputting, viewing, querying and sorting, exporting, printing). The design process is unusually visual and object-based, revolving around icons and windows, in ways somewhat reminiscent of Prograph (see "Get Your Hands on Prograph" in TidBITS-312). The terminology is also rather quirky, so bear with me.

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

A database file created by Helix, containing the database structure and the data, is called a "collection." Only one collection can be open at a time. It is represented initially as an empty window, into which you drag icons to represent relations; each relation is a table of data, where all the records (the rows) will consist of the same fields (the columns) – what FileMaker would call a database. Thus, a one-relation collection is a flat-file database; a two-or-more-relation collection can be a relational database, as I’ll explain later.

Double-click a relation icon, and another empty window opens, into which you drag more icons. These are of many different types:

• A field is a category of data that each record is to have, such as "last name" or "age".

• An index is an instruction that a sorted order be maintained for one or more fields.

• An abacus is a calculation, such as "first name followed by space followed by last name".

• A template is like a FileMaker layout, where you arrange fields on the page.

• A view is like FileMaker’s browse mode; it portrays some particular template, but is where you actually enter and view live data.

• A query is a form, attached to a view, which you can open to change what subset of the data is shown in that view.

• A post is an action to be performed automatically when you do something in a view, such as entering data; chiefly, it’s a way of maintaining automatic integrity of data across relations. I’ll talk more about this later.

  
  

Each icon, once dragged into a relation window, just sits there until you do something with it. First, you name it, just like naming a file in the Finder. Then you double-click it to open its window and edit it. In a field’s window, you specify its data type and validation rules. In an index’s window, you specify what field(s) to sort. In an abacus’s window, you describe the desired calculation: this too is completely icon-based, as you drag icons representing operations and fields into the window and arrange them in a dataflow diagram. For example, to say "first name followed by space followed by last name", you drag in a "followed by" icon, then drag the "first name" field into its first part and set a space character as its second part; then you drag in a second "followed by" icon, feed the output arrow from the first one into the second’s first part, and drag the "last name" field into its second part.

A template window starts out as a blank sheet of paper with some rectangle drawing tools. What you draw is crucial, because a view, you recall, is the only place where you enter or examine any actual data, and every view is a representation of some one template; so if you ever want to be able to set directly the value of a record’s "last name" field, that field must appear in a template!

Templates come in two forms. A template showing fields for one record at a time is an entry template; in a view that uses an entry template, you navigate records via Next/Previous Record menu items. A template showing fields for all records at once is a list template, and is established by drawing a repeat rectangle around the data to be listed. For example, if you draw a repeat rectangle around the "last name" field in a template, then a view that uses this template will list the last name values for all the records at once. (By "all", I mean "all that this view shows"; you can limit or order the set of data shown, with a query or index attached to a view.)

A list template can appear within another template. For any view that uses the outer template, you specify a field in each template’s relation; the inner template will then list only those records of its relation where the data of those two fields match. This is how you make your database relational. The display of the inner template material is extremely flexible, so that Helix’s implementation of relationality is extremely powerful: for example, you can specify the sort order of the inner list; you can specify a query further limiting the inner list’s records; and you can nest list templates, for additional layers of relationality.

Helix runs in two modes, developer mode and user mode. Developer mode is what I’ve been talking about all this time. In user mode, you see only certain views and menu items, and have only certain types of access to those views, as predetermined in developer mode. Surprisingly, this can be useful even if you are your only user; when you are done designing, it’s nice to switch to user mode, eliminating extraneous windows, and just enter and retrieve your data.

Acid Test — To test Helix for this review, I reproduced, as a Helix collection, the structure, data, and functionality of a system of related FileMaker databases that we used when I was editing a Mac programming magazine. This system had proven almost too much for FileMaker to handle, and I wanted to see if Helix could do better. I will now provide some gory details, so skip the next couple of paragraphs if you have a weak stomach.

The system tracked articles submitted and published, plus payments to authors. An article could comprise more than one "fragment" (for example, in our Readers Tips column, each tip was a fragment); so there were no authors of articles, only authors of fragments. And a fragment could have more than one author. So far, that’s three databases: articles, fragments, authors. For every article, we needed a list of author-fragment-payment triplets. But how, in FileMaker, could a portal in the articles database show authors? Authors had no direct relationship to articles, and portals could not contain portals, or be limited through a query.

Our solution was an extra database, an intermediate "link" pairing fragments with authors (and payments). The articles database could have a portal on this fragment-author database; but how would it know which fragment-author pairs to list? Clearly, the article database’s key must match an article key in the fragment-author database. But where would that key’s value come from? There were no articles in the fragment-author database; articles were paired with fragments in the fragments database! So we forced each record in the fragment-author database to learn what article it was a part of, through a lookup on the fragments database.

This was just one of many complex portal/lookup tricks we used to hook up the information. The problem here was not the extra fragment-author database (that’s standard procedure with many-to-many relationships), but the dreadful fragility of the data’s integrity. Lookups in FileMaker were not live, so we had to keep running a script in the articles database that made the link database refresh its lookups. When creating a new article, tasks had to be performed in the right order, to ensure that the fragment-author database was updated correctly behind the scenes; despite precautions, it could easily acquire invalid records, and had to be double-checked often by hand.

The Helix version turned out to be far simpler and far more robust, and took me just two days to create after reading the documentation; it would have been much quicker for an expert. To list fragment-author pairs within a view of an article still requires the fragment-author relation, but in a much more straightforward way: an articles template holds a fragments list template, keying on the article, which in turn holds a fragment-author template, keying on the fragment. Integrity is maintained behind the scenes through a post: when you enter an author for a fragment in the fragments relation, Helix automatically creates a new record pairing them in the fragment-author relation – but only if they are not already paired.

The Helix version is also far more comprehensible to a developer. FileMaker hides crucial information in various modal dialogs: the Define Fields dialog and its Options sub-dialog, the Field Format dialog, the Portal Setup dialog, ScriptMaker and its Script Definition sub-dialog. In Helix, on the other hand, everything is a top-level entity, an icon in a window, and no icon window is modal, so you can open and study many at once – indeed, in an icon window you can double-click another icon’s name to open that icon’s window! You can view a relation window as a list (like Finder Name view), showing useful information about each icon. Each icon also has a Get Info window, where you can enter a comment and see the names of all icons that use this one. Finally, Helix prevents or warns you if you perform any invalidating action, such as trying to delete an icon used by another.

Helix derives great fluidity and power from the object-based independence of its entities. Consider calculations. In FileMaker, a calculation is basically a kind of field. In Helix, an abacus is just an abacus, and so you can use it however you like: it can provide data or validation for a field, a sort order for an index, a limiting query for a view or for a field entry pop-up menu. On the other hand, things that don’t need to be entities, are not. In FileMaker, relationality between databases is one more setting to be reached through a series of dialogs; but Helix knows that this is just a way of looking at data, so it’s merely an aspect of a particular view. The general feeling in FileMaker is that you start with a database and drill into it from various places to access its parts; in Helix, you start with the parts, and tie them together to form a database.

Under the Electron Microscope — Helix is not for the faint of heart. The manual (fortunately due to be rewritten) is a massive series of PDFs, more a specification than an explanation: it has some typos, and the pictures are mostly indecipherable, a serious flaw for a visual language. It fails utterly to teach you the Helix way of thinking, the peculiar culture and tricks handed down by past masters. The learning curve is hyperbolically steep; either you’ll suddenly have an "Aha" moment and pop past it, like bursting through a wall, or you’ll fall off the mountain.

Helix still has some bugs – I crashed several times – and many faults. Revision continues, so some of these may soon vanish; but at present, the new user is likely to find Helix quirky and fossilized. Over the years, Helix has grown like Frankenstein’s Monster; new bits were sewn on without touching old bits, many of which date back all the way to 1984 – and they feel like it, especially the interface, which incorporates no modern elements such as balloon help or tabbed panels.

Navigation is a big problem. There is no Window menu (a dreadful omission), no hierarchical outline view of your collection, and no way to navigate upwards (from an Index window to its containing Relation window, for example). So you spend most of your time lost; even if you can see an icon’s name and open its window, you may not know what relation it is part of, so you have to drill down into every relation looking for it.

Certain crucial windows are incomprehensible unless you’re very experienced or looking at the manual, and often present their information in a clumsy piecemeal fashion. The View Setup window, where you create the relationality between an outer and an inner template, is atrocious: the space is too narrow for the names you’re trying to read, and if you add another inner template the dialog forgets all its previous settings.

You cannot edit data in a list view – though you can double-click a listed record (or multiple selected records) to open it in an entry view where you can edit. Inner lists don’t scroll, or support multiple selection. On the other hand, list views support user-selectable sort orders, while entry views don’t – a curious asymmetry.

Here’s a final miscellany. You can only have eight colors. A multiple-choice field can’t be represented as radio buttons. There aren’t enough menu shortcuts, because the Command key is the only modifier. There is no way to learn which record of the current found set you’re looking at. An abacus has no find-and-replace functionality, so sometimes you have to export your data, munge it, and re-import it.

Replication & Evolution — Helix is internally scriptable, via menu items or buttons in views; but the only scriptable actions, besides opening views, are those normally available as menu items. That’s very weak compared with FileMaker, but posts often make a script unnecessary, and buttons can implement a form of branching and looping, which scripts themselves lack.

Helix can’t run AppleScript scripts, so any inter-application communication must originate externally. It responds, not to AppleScript, but to some rather oddly structured Apple events; you’ll need a program like Frontier to send them. The repertoire is very limited – fetch a record, load a record, delete a record – but you could probably manage by arranging your database cleverly beforehand, perhaps with an occasional boost from QuicKeys or OneClick. So if the question is, "Can Helix act as a CGI application behind my Web server?" the answer is: Maybe, but not alone, and not easily.

I have not seen the commercial Helix products; there are two. Helix Converter ($500) turns your database into a stand-alone application (in permanent user mode). Helix Client/Server lets multiple users access a database via AppleTalk. It might be preferable for serious CGI work, and without it you can’t run two copies of Helix on the same local network. It starts at $300 for two clients and goes up from there.

My exploration of Helix has certainly made me an addict, if not a convert. Once bug-squashing ends, the next big step will be a feature release. It isn’t clear what this might include – a truly modern Helix might benefit from an overhauled interface, fuller scriptability, and TCP/IP and ODBC awareness – or what the future pricing model will be. But the present pricing model is unbeatable: a powerfully relational database program at no cost. You have nothing to lose but your dependence on FileMaker.

Helix requires a PowerPC-based Macintosh running System 7.5.5 or later.

<http://www.helixtech.com/download.html>

[Note: This article owes much to the generous personal attention and informative guidance of Matt Strange of Helix Technical Support.]