TidBITS Issue #260

23 Jan 1995 | Print

Congratulations

Congratulations are in order for Australian developer Peter N. Lewis (not the Peter Lewis who writes for the New York Times). At Macworld Expo in San Francisco this year, MacUser Magazine awarded him the Derek Van Alstyne Rising Star AwardShow full article

23 Jan 1995 | Print

Take a Deep Breath: Word 6.0a

by Geoff Duncan

Take a Deep Breath: Word 6.0a -- Last Friday, Microsoft announced plans to release a free maintenance update for the Macintosh version of Microsoft Word 6.0Show full article

23 Jan 1995 | Print

MacUser and MacWEEK

by Adam C. Engst

MacUser and MacWEEK have made their appearance on the World-Wide Web. The MacUser home page contains selected articles from the most recent issue, article archives, and links to Apple and other Macintosh sites and resourcesShow full article

23 Jan 1995 | Print

Connection Machine WAIS Server Down

by Adam C. Engst

Connection Machine WAIS Server Down -- Unfortunately, due to financial troubles, Thinking Machines has taken down the vastly useful Connection Machine WAIS server, effective 27-Dec-94Show full article

Hide full article

Connection Machine WAIS Server Down -- Unfortunately, due to financial troubles, Thinking Machines has taken down the vastly useful Connection Machine WAIS server, effective 27-Dec-94. The data is all pretty much safe, so it's likely to appear again at some other site in the future. In the meantime, the sources for TidBITS, <comp.sys.mac.programmer>, Info-Mac Digest, the CIA World Factbook, and others are not available. I'm talking with various people about ways of making the Connection Machine sources available once again, but until then, all I can say is to be patient. The list of sources lost includes: [ACE]

 CM-fortran-manual.src
 CM-paris-manual.src
 CM-star-lisp-docs.src
 CM-tech-summary.src
 CMFS-documentation.src
 Connection-Machine.src
 RSInetwork.src
 bible.src
 comp.sys.mac.programmer.src
 fatfree-cookbook.src
 info-mac.src
 info-nets.src
 macintosh-news.src
 macintosh-tidbits.src
 risks-digest.src
 scsi-2.src
 silent-tristero.src
 sun-spots.src
 usenet-cookbook.src
 world-factbook.src

23 Jan 1995 | Print

Macintosh Client/Server Database Development Summary

by Liam Breck

Liam Breck writes: The Macintosh Client/Server Database Development Summary is an overview I've written for developers and managers involved in the evaluation, design, and construction of multi-user database systemsShow full article

23 Jan 1995 | Print

GIF Gaffe

by Geoff Duncan

GIF Gaffe -- Our article on the recent Unisys/CompuServe GIF fiasco (see TidBITS-259) contained a few misstatements. First, Unisys's patent on the LZW compression method was effective in 1985, not 1993 as stated in the articleShow full article

23 Jan 1995 | Print

Comdex/PacRim

by Adam C. Engst

Last week, Geoff and I went on a road trip last week to Vancouver for the Comdex/PacRim conference. Frankly, the trip was more an excuse to go to Vancouver (a three hour drive) with our friend Cary Lu and a friend of his, David CoderShow full article

Hide full article

Last week, Geoff and I went on a road trip last week to Vancouver for the Comdex/PacRim conference. Frankly, the trip was more an excuse to go to Vancouver (a three hour drive) with our friend Cary Lu and a friend of his, David Coder. Nevertheless, the show proved interesting in a few ways that I thought I'd share. The PC industry is tremendously fragmented. As much as I may complain that the Macintosh industry has become rife with niche markets and products only a professional could love, the PC market is an order of magnitude more complex. That's appropriate, I suppose.

Probably the most interesting work being done in the PC hardware world is with laptops, with everyone and their corporate brother showing PC laptops with interesting and unique features. Despite the number of different PC laptops we looked at, none (in our eyes) beat the PowerBooks. Pointing devices in PC laptops still universally stink, and even an Epson laptop that used a trackpad was brought down by abysmal buttons and the fact that it wouldn't work with just your fingertip: you had to lay your entire first finger joint on the pad for it to recognize your presence. I'm not too fond of the little joystick device IBM uses for its ThinkPads (and I far prefer Apple's palmrest design for the keyboard), but otherwise, the ThinkPads were extremely nicely designed.

Every show has an undercurrent, and to give you an idea of the flavor of this one, the whispers we overheard dealt not with a cool new product or service, but with the fact that Robin Williams (the actor - you know, Mork), was present on the floor, just walking around like a normal person. Geoff was taken with a Dixieland trio playing at the Digital booth (we considered asking them for an evaluation copy of a DEC Alpha). After seeing PCMCIA cards for every function you could imagine, I decided the ultimate absurd peripheral would be a PCMCIA-based UPS (Uninterruptible Power Supply), perhaps autographed by both Robin Williams the actor and Robin Williams the author.

Comdex/PacRim was definitely a Windows show. We were accosted by a nice woman at the Claris booth who wanted to give us entries for winning a copy of FileMaker Pro if we watched the demo, at which point we asked, "Mac or Windows version?" She was taken aback and said, "This is a Windows show," a bit huffily, to which we replied, "Yeah, so?" Despite the Windows emphasis, Apple's booth was heavily trafficked, and judging by the informal surveys of the audience during demos, plenty of Mac users were present. Apple had a specific station dedicated to Macintosh Internet usage, and the Apple Canada guy there definitely knew his stuff.

Internet wannabes were out in full force, as they were at Macworld, and we decided that if a product has anything to do with networking, the word "Internet" will appear in its description. Similarly, if a piece of software isn't entirely text-based, "multimedia" appears as if by magic in the description, and any game or program using animated graphics is now described as using "virtual reality." Now, I suppose, we only have to wait until some product's description wins the gold ring by incorporating all three buzzwords. Right now, the closest product I can think of in those terms is Outland's Internet-based game network, which has plenty of non-text games for the "multimedia" tag, but doesn't quite yet have the level of animated graphics necessary to claim "virtual reality." Besides, the Outland folks are good Internet citizens and wouldn't stoop to such tactics.

http://www.outland.com/

23 Jan 1995 | Print

Image is Everything: ShrinkWrap 1.2

by Geoff Duncan

Anyone who's dealt with floppy disk images knows what a pain they can be. The idea behind a disk image is simple enough: instead of distributing or storing a floppy disk as a physical object, you store it as a file on a larger diskShow full article

Hide full article

Anyone who's dealt with floppy disk images knows what a pain they can be. The idea behind a disk image is simple enough: instead of distributing or storing a floppy disk as a physical object, you store it as a file on a larger disk. Admittedly, back in the days of the 128K Macintosh (which came with a single 400K floppy disk drive), this wasn't much of an issue. But as hard drives became commonplace and capacities increased, the idea of storing floppy disks as images became more practical and more necessary. Floppy disks are still one of the principle ways in which software and documents are distributed - after all, nearly every Macintosh has a floppy drive, but the same can't be said of CD-ROM drives, networks, or modems. As a result, people frequently use disk images to back up application disks, to store or send exact copies of floppies online, or (with compression) to pack a few 800K disk images onto a single high-density floppy.

DiskCopy, MountImage, and MungeImage -- For years, images of floppy disks have been hard to deal with and difficult to manage. In the beginning, there was DiskCopy, a utility from Apple that let you read and write floppy images. Using DiskCopy, you could store a floppy on your hard disk as a file, then read that file back out to a floppy disk any time you wanted. (DART is another Apple utility that performs similar functions.) Although DiskCopy is a reliable, bare-bones way to handle floppy images, it leaves a lot to be desired. For instance, to look at or use the contents of an image file, you had to find a floppy disk, copy the image file to it, and then pop the floppy disk back into your drive in order to see the files on it - a major nuisance. But DiskCopy is useful, and Apple continues to distribute system software and software updates in DiskCopy format.

ftp://ftp.apple.com/dts/utils/diskcopy-4-2.hqx
ftp://mrcnext.cso.uiuc.edu/pub/info-mac/disk/ dart-153.hqx

Later, Apple introduced MountImage, a control panel that lets you mount a DiskCopy image on your desktop as if it were a real disk. This was a nice step forward: finally the floppy disk itself had been eliminated from the equation, and you could peruse and change the contents of a floppy disk image without having to mess around with a physical floppy disk. Unfortunately, MountImage suffers from a major bug that Apple has been open about: if your original disk image file was fragmented (stored in more than one piece) on your hard disk, MountImage can lose or destroy data in that image and/or other files.

Roger Bates (author of DiskDup+) has offered a safe alternative to MountImage for years, but unfortunately it's not widely available or distributable (it's only available if you pay your shareware fee). Eventually, in mid 1994, the inimitable Peter Lewis and Quinn staged a rescue when they introduced MungeImage, a freeware replacement for MountImage. Peter and Quinn implemented MungeImage as a drag-and-drop application that didn't have extensions conflicts or suffer from MountImage's file fragmentation problem, but MungeImage has virtually no interface and only deals with DiskCopy (and later DART) images. Because other applications do their own flavors of disk images (DiskDup+, DropDisk, Norton's Floppier, and MacTools' FastCopy to name a few), MountImage doesn't provide a one-stop disk image utility solution.

ftp://mrcnext.cso.uiuc.edu/pub/info-mac/disk/ disk-dup-plus-25.hqx
ftp://mrcnext.cso.uiuc.edu/pub/info-mac/disk/ munge-image-120.hqx

Enter ShrinkWrap -- Now, you have to understand: Chad Magendanz lives for disk images. He has waking dreams of row upon row of 230 MB magneto-optical cartridges lining his home office, all of them filled with backup images of all-too-vulnerable floppy disks. Although pleased as punch about his MO drive, he found the disk image situation in 1994 to be intolerable. Simply speaking, it was a ton of trouble to deal with images, even with MungeImage. Not being afraid of drivers or assembly language, Chad decided to do something about the sorry state of affairs. So ShrinkWrap was born.

Chad based early versions of ShrinkWrap on Peter and Quinn's MungeImage driver and the germ of MungeImage's drag and drop application interface. However, ShrinkWrap also took a hint from Aladdin's StuffIt Expander and DropStuff utilities, adding power and flexibility to its drag and drop capabilities. To mount disk image files, just drag them to the ShrinkWrap icon: like magic, floppies appear on your desktop. To make image files from disks, drag those disks to ShrinkWrap's icon. Voila, image files materialize. ShrinkWrap is also very careful with data; it generates and confirms checksums of disk images for all formats it supports.

But there were still problems. The MungeImage driver used by ShrinkWrap mounted disk images in RAM. This meant that if you wanted to mount a dozen disk images simultaneously (say, to install a major application), you had to have enough free RAM to hold a dozen disk images. This was a big problem for owners of low-end (and even mid-range) machines.

ShrinkWrap 1.2 addresses these issues and more:

Version 1.2 uses a new driver that uses both available RAM and disk space to mount images. So if you have the memory to mount dozens of floppies, great, ShrinkWrap will use it. But if you don't, ShrinkWrap lets you use available hard disk space to mount images. Although using the hard disk to mount images isn't as fast as using RAM, it's considerably better than not being able to mount them at all.

ShrinkWrap now reads and writes a number of disk image formats, including DiskDup+, DiskMaker, DropDisk (DOS Card drive containers), Norton Floppier, and MacTools FastCopy (uncompressed), in addition to DiskCopy and DART.

ShrinkWrap integrates with StuffIt Expander and the StuffIt Engine, which is distributed with Aladdin's shareware DropStuff utility. This means ShrinkWrap can automatically decompress and decode any format supported by these utilities, including BinHex, StuffIt, Compact Pro, and gzip. So, you can use ShrinkWrap 1.2 to download those compressed disk images Apple uses to distribute system patches and updates, and to store disk images in a compressed format. Also, the StuffIt Engine makes images compress and decompress quickly, plus the images generally end up smaller than those in other compressed image formats.

ftp://ftp.tidbits.com/pub/tidbits/tisk/util/ stuffit-expander-352.hqx
ftp://ftp.tidbits.com/pub/tidbits/tisk/util/ drop-stuff-with-ee-352.hqx

ShrinkWrap has a new batch floppy mode that allows you to create disk images or duplicate a disk image without doing anything but feeding disks to your Mac - no mouse or keyboard action required. This is handy for making multiple copies of a single disk, or for archiving the mass of floppies that came with that latest bloated commercial application. Although dealing with floppy disks is never speedy, ShrinkWrap creates images and copies disks faster than any other utility, including DiskCopy.

Plus, did you ever have a need for an instant RAM disk? Just drag a folder over to the ShrinkWrap icon. If it's smaller than the default media type set in ShrinkWrap's preferences, ShrinkWrap creates and mounts a disk image of that folder. This is handy for files you need to have ultra-fast access to, and you don't have to restart your Mac to get that RAM disk. Done? Just drag it to the Trash.

Okay - so not everyone deals with disk images every day. In fact, many Macintosh users may never deal with disk images at all. But if you've ever wondered what to do with system updates issued by Apple or if there are reliable ways to back up your original floppy disks from commercial applications or other sources, ShrinkWrap makes the world much simpler. If that doesn't convince you, the ability to create instant RAM disks should appeal to anyone doing graphics work or requiring rapid file access. To be fair, ShrinkWrap has a few bugs (including a crashing problem with MODE32), but for the most part these problems are innocuous - they don't interfere with the majority of ShrinkWrap's uses. Finally, ShrinkWrap is freeware. Just download and enjoy.

ftp://mrcnext.cso.uiuc.edu/pub/info-mac/disk/ shrink-wrap-12.hqx

23 Jan 1995 | Print

URLs 'R Us

by Adam C. Engst

We've been using URLs in TidBITS for over a year now, and I don't think an issue goes by without us pointing at some resource or another with a URL. I wrote a little about URLs back when we first started, but with our readership growing so quickly I think it's worthwhile to talk about URLs some moreShow full article

Hide full article

We've been using URLs in TidBITS for over a year now, and I don't think an issue goes by without us pointing at some resource or another with a URL. I wrote a little about URLs back when we first started, but with our readership growing so quickly I think it's worthwhile to talk about URLs some more. I've taken most of this article from information I originally wrote for my Internet Starter Kit for Macintosh, Second Edition.

URL generally stands for Uniform Resource Locator, although some people switch "uniform" for "universal." Despite what I've heard from one source, I have never heard anyone pronounce URL as "earl;" instead, everyone I've talked to spells out the letters.

URLs constitute the most common and efficient method of telling people where to find objects available via FTP, the World-Wide Web, and other Internet services. I say "objects" because you can specify URLs not only for files and Web pages, but also for stranger things, such as email addresses, Telnet sessions, and Usenet news postings. For example, this issue's ShrinkWrap article ended with an FTP URL you can use to download ShrinkWrap.

A URL uniquely specifies the location of an object on the Internet, using the three main bits of information that must be used in order to access any given object. First is the type of server making the object available, be it an FTP, Gopher, or World-Wide Web server. Second comes the machine on which the resource lives. Third and finally, there's the full pathname to the object. This description is a slight oversimplification, but the point I want to make is that URLs are an attempt to provide a consistent way to reference objects on the Internet.

Client/Server -- If you see a URL that starts with "ftp" you know the file specified in the rest of the URL is available via an FTP server, which means you could use an FTP client, such as Anarchie or Fetch, to retrieve it. If the URL starts with "gopher", a Gopher client like TurboGopher could access the file on the Gopher server in question. If the URL starts with "http", it's on a Web server, so you might use a Web browser like MacWeb or Netscape. Other server types used in URLs include "news", "mailto", "telnet", and "wais", although they're less common than FTP and Web URLs.

You can use a Web browser to access most of the URL types above, although Web browsers are not necessarily ideal for anything but information on the World-Wide Web itself. Web browsers work pretty well for accessing files on Gopher servers, and via gateways to WAIS databases, but FTP via a Web browser is clumsy (and may fail entirely with certain types of files, such as self-extracting archives).

Machine -- After the URL type comes a colon (:) and two slashes (//). These characters separate the server type from the second part of common URLs. This second part is the name of the Internet machine that contains the object you're seeking. In some rare circumstances, you may need to use a username and password in the URL as well. A URL with a username and password might look like this: ftp://username:password@domain.name/pub/

Path -- The last part of the URL gives the path to the directory of the object you're looking for, and it may also give the name of a specific file. This is separated from the machine name by a slash (/). When used with WAIS or various other protocols that don't simply point at files, the path may specify other types of information. You don't have to specify the path with some URLs, such as FTP or Gopher URLs, if you're only connecting to the top level of the site.

If an FTP or Gopher URL ends with a slash, that means it points at a directory and not a file. If it doesn't end with a slash, it may or may not point at a directory. If it's not obvious from the last part of the path, there's no good way of telling until you go there. Since most Web servers enable the creation of some sort of default.html or index.html file to be served in the absence of a specific file in the URL, it's a bit less important for Web users to realize whether or not they're specifying a file or a directory.

Using URLs -- All of these details aside, how do you use URLs? Your mileage may vary, but I use them in three basic ways. First, if I see them in email or in a Usenet posting, I often copy and paste them into Anarchie (if they're FTP URLs) or Netscape or MacWeb (if they are other types). I do this because copying the URL into the appropriate client is the easiest way to retrieve a file or connect to a site with a MacTCP-based Internet connection. In NewsWatcher 2.0b24 (and InterNews for FTP), you can simplify the process by command-clicking URLs to have them resolved by the appropriate FTP (Anarchie or Fetch), Gopher (TurboGopher 2.0b7), or Web (MacWeb 1.00A3 or Netscape 1.0N) client program. MacWeb 1.00A3 can also use other programs to resolve URLs more appropriately, and finally, the next version of Eudora (perhaps only the commercial version) will sport this feature as well.

Sometimes I manually decode the URL to figure out which program to use and where to go. This method takes more work, but sometimes pays off in the end. You can put a screw in the wall with a hammer, but it's not the best tool for the job.

Third and finally (and this is where you come in), when I want to point someone at a specific Internet resource or file, I provide a URL. URLs are unambiguous, and although a bit ugly in running text, easier to use than attempting to spell out what they mean.

Consider the example below:

ftp://ftp.tidbits.com/pub/tidbits/issues/1995/ TidBITS#260_23-Jan-95.etx

To verbally explain the information in that URL, I would have to say something like: "Using an FTP client program, connect to the anonymous FTP site <ftp.tidbits.com>. Change directories into the /pub/tidbits/issues/1995/ directory, and once you're there, retrieve the file TidBITS#260_23-Jan-95.etx."

Note that our long-time naming scheme with TidBITS isn't all that Web friendly, since the # character has a specific meaning in Web URLs. Stripping off the filename and hitting the directory manually would always work, though, as would simply pasting that URL into Anarchie or Fetch.

The URL enables me to avoid the convoluted (and boring) language above; frankly, URLs are in such common use on the Internet you might as well get used to seeing them now. And for those of you who recommend files to get via FTP or sites to browse with a Web browser, please use URLs since they make life easier for everyone.

If you try to retrieve a file or connect to a Web site and are unsuccessful, chances are either you've typed the URL slightly wrong, the server is down temporarily, or the file no longer exists. If an FTP URL doesn't work, try removing the file name from the last part of the URL and look in the directory that the original file lived in for an updated file.

If, after all this, you'd like to learn more about the technical details behind the URL specifications, check out:

http://info.cern.ch/hypertext/WWW/Addressing/ URL/Overview.html

I find that URLs don't always work well for files stored on Gopher servers, since Gopher allows spaces and other characters that URLs don't accept. Thus, spaces are encoded in Gopher URLs with %20 to indicate that there's a space there. Similarly, WAIS sources usually are easier to refer to by name - using a WAIS client such as MacWAIS makes it easy to use sources without worrying about all the additional information in a URL.

TidBITS Watchlist

Expose Shortcut for View All Windows

TidBITS#260/23-Jan-95

Congratulations

Take a Deep Breath: Word 6.0a

MacUser and MacWEEK

Connection Machine WAIS Server Down

Macintosh Client/Server Database Development Summary

GIF Gaffe

Comdex/PacRim

Image is Everything: ShrinkWrap 1.2

URLs 'R Us