Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue
Congrats to Peter Lewis for his MacUser award, corrections on last week's GIF article, and an announcement from Microsoft about a faster Word 6.0a start off this issue. Geoff and Adam report on a road trip to Vancouver for Comdex/PacRim, a heavy-duty Windows show. Geoff also has an in-depth review of Chad Magendanz's ShrinkWrap 1.2, an indispensable disk image utility. Finally, Adam explains URLs, those ever-so-useful identifiers of Internet objects.
Copyright 1995 TidBITS Electronic Publishing. All rights reserved.
Information: <firstname.lastname@example.org> Comments: <email@example.com>
This issue of TidBITS sponsored in part by:
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 Award. This comes on the heels of his Cool Tools award from Apple for Internet tool development earlier this year, and it's great to see a shareware developer receiving the recognition he deserves. [ACE]
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.0. The update will allegedly address key performance problems (such as launch time, spell checking, and type-ahead) and restore some features in Word 5.1 that are either absent or difficult to find in Word 6.0.
The update is to be made available by 30-Mar-95, although no methods of distribution have been specified. When thinking about that date, bear in mind that one of the Microsoft business practices being investigated by the U.S. Department of Justice is premature announcement of software products, followed by significant slips. [GD]
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 resources. You'll find MacWEEK news, archives and subscription information on the MacWEEK page. [ACE]
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
Liam Breck <firstname.lastname@example.org> 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 systems. It covers over 30 software tools for Macintosh and cross-platform development in three categories:
The eight-page (20K ASCII text) document provides an explanation of each category and a brief description of each product. Its sources are vendors' product literature, industry periodicals, and discussions with users and vendors' tech support staff. It is purely informational and contains no propaganda. The current revision is 1.2, released 12-Dec-94.
To receive a complimentary copy via email, send email to: <email@example.com>. Please give your name, organization, and position in the body of the request message; no other text is necessary. The summary is automatically emailed to the address which sent the request. To specify a different address, put it in the subject line of the message.
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 article. Second, the TIFF file format is not itself licensed from Unisys, but the LZW method used in the TIFF format is licensed from Unisys.
Notwithstanding, the LZW compression format was first published in June of 1984, calling into question Unisys's subsequent application for a patent on the method. Also, while CompuServe can be accused of many things, making a secret of LZW's use in the GIF format is not one of them. It remains astounding that Unisys overlooked the (increasingly widespread) GIF file format for seven years.
CompuServe announced last week plans to serve as the coordinator of a new "free and open" GIF24 standard. GIF24 will support 24-bit, lossless compression and will presumably be free of proprietary technology. [GD]
by Adam C. Engst <firstname.lastname@example.org>
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.
by Geoff Duncan <email@example.com>
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.
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.
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:
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.
by Adam C. Engst <firstname.lastname@example.org>
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:email@example.com/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:
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:
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.
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