TidBITS Issue #109

02 Mar 1992 | Print

|

Administrivia

We would like to apologize to all of you who received multiple TidBITS files via the SFU mailing list. We can point the finger of blame, but not at an identified individualShow full article

02 Mar 1992 | Print

|

David Roth writes, "I've been trying to use Professional Composer on a Mac Plus running System 6.0.5 to generate PostScript files to be printed on other systems with PostScript printersShow full article

02 Mar 1992 | Print

|

More On Viruses

by Adam C. Engst

Murph Sewall wrote to tell us that he talked to both Lloyd Chambers, author of AutoDoubler, and Greg Friedman, Technical Director of Aladdin Systems. Murph was concerned that if an infected application was compressed by either AutoDoubler or Aladdin's forthcoming SpaceSaver, that perhaps virus checking programs like Disinfectant would not detect the virusShow full article

Hide full article

Murph Sewall wrote to tell us that he talked to both Lloyd Chambers, author of AutoDoubler, and Greg Friedman, Technical Director of Aladdin Systems. Murph was concerned that if an infected application was compressed by either AutoDoubler or Aladdin's forthcoming SpaceSaver, that perhaps virus checking programs like Disinfectant would not detect the virus. Both Lloyd and Greg said that as long as the virus checking program accessed the infected files through the Resource Manager, they should successfully detect viruses. So the use of transparent compression utilities such as AutoDoubler, SpaceSaver, and (presumably) More Disk Space from Alysis should not impede the functioning of a virus checking utility. This is not to guarantee that all virus checkers will detect all infections in any sort of transparently compressed file, but I know that AutoDoubler and Disinfectant work fine together, and I imagine that other combinations do as well.

Porting Viruses -- Murph continues, "Here's a humorous rumor. A member of our local user group called yesterday to ask if it was true that the Michelangelo virus would affect Macs as well as PCs. As a friend of mine (who works for Apple) says, authors of viruses rarely publicize what platforms are supported. Porting that sort of code from one operating system to another is a thankfully daunting proposition. Still, I may do a full backup on March 5th." [Adam: This rumor about a Mac version of Michelangelo being a Mac virus seems to be going around. As far as I know, this is merely a humorous and incorrect rumor.] [Tonya: It gets less humorous when you spend a lot of your day explaining how it's only a rumor. ;-)]

Information from:
Murph Sewall -- SEWALL@UCONNVM.UCONN.EDU

Virus Checking Code -- Last week I suggested that perhaps Claris could put their integrity checking code into the public domain so that other programmers could use it. Several people quickly pointed out the problem with this idea - publicizing the code would make it easy for virus authors to circumvent it. In addition, the more different techniques that people use to prevent viruses from infecting their programs, the harder it will be for a virus to pass unnoticed.

Marshall Clow adds:

There are lots of easy things that an app can do to make life difficult for viruses:

Mark your resources "protected", especially "CODE 0" and "CODE 1". This makes it more difficult to change them.

Mark your resource map "read-only". This makes it more difficult to add or enlarge resources.

Check the number and sizes of your CODE resources occasionally. Note that infection need not occur at program startup!

Use your imagination! Be creative! Be a winner like Claris! P.S. I have no affiliation with Claris.

Information from:
Keith Instone -- instone@euclid.bgsu.edu
Edward Reid -- ed@titipu.meta.com
Marshall Clow -- marshall@sdd.hp.com
Murph Sewall -- SEWALL@UCONNVM.UCONN.EDU

02 Mar 1992 | Print

|

Virus Fighters

by John Norstad

I've been getting a number of thank you notes via private email and on the newsgroups lately. Thank you very much. I appreciate your appreciation. However, I must let everyone know that I'm more than a bit embarrassedShow full article

Hide full article

I've been getting a number of thank you notes via private email and on the newsgroups lately.

Thank you very much. I appreciate your appreciation.

However, I must let everyone know that I'm more than a bit embarrassed. As the author of Disinfectant, I am in a way just the most visible tip of a very large iceberg. The rest of the iceberg deserves just as much credit and thanks as do I. The only problem is, you don't know who these people are!

I can't list the names of these people, or even the name of our Internet-based organization. This is not the same group as the Disinfectant Working Group I mention in my online manual, although there is quite a bit of overlap between the two groups.

Let me just tell you very briefly what has happened since last Wednesday morning (19-Feb) concerning this new MBDF virus.

The virus was reported to me, and a copy was sent to me, last Wednesday morning by a Professor of Mathematics in Wales. I immediately forwarded his note and the virus to the group.

By Wednesday evening, several members of the group had completely disassembled, analyzed, and tested the virus. I did NOT do any of this work!

On Thursday morning, the same professor in Wales sent me a note saying that he thought he had gotten the virus from sumex-aim. I checked, and sure enough, the games he mentioned were infected at sumex.

I again immediately notified our group, which includes the managers of sumex. The sumex managers started working furiously checking files, shutting down the archive temporarily and tracing back the source of the infection. They quickly discovered a trail leading to Cornell University.

I began working on Disinfectant 2.6. Others in the group worked on their anti-viral programs, helped prepare public announcements, and continued to do technical research on the virus. Others in the group notified the authorities at Cornell and began cooperating on that front.

To make a long story short, the net result is that:

Within three days of the discovery of the virus, all of the major freeware, shareware, and commercial Mac anti-viral tools were updated to deal with the new virus.
Two Cornell sophomores have been arrested, arraigned, and are now in jail, less than six days after discovery of the virus. [Adam: They are now free on bail, and the FBI has decided not to investigate or press federal charges.]

This brief historical summary of the events of the past six days is a wonderful example of the power of the Internet, and is a wonderful example of the tremendous spirit of cooperation fostered by the Internet.

At least a dozen people were directly involved in this process. I was just one of them. I was not even the "leader," just a participant.

So again, it's embarrassing. The credit should go to the group, not just to me.

02 Mar 1992 | Print

|

QuickMail & AppleShare 3.0

by Adam C. Engst

Oh dear, this will be unpopular. It seems that Apple's recently released AppleShare Server 3.0 software is incompatible with versions of CE Software's QuickMail mail server software from 2.2.x up through the current 2.5 and the forthcoming 2.5.1Show full article

Hide full article

Oh dear, this will be unpopular. It seems that Apple's recently released AppleShare Server 3.0 software is incompatible with versions of CE Software's QuickMail mail server software from 2.2.x up through the current 2.5 and the forthcoming 2.5.1. You cannot run both AppleShare 3.0 and QuickMail on the same Macintosh, something which many people have done with previous versions of AppleShare.

This is related to, but separate from, another incompatibility. QuickMail server software also conflicts with System 7's Personal FileSharing, though this conflict is less likely to cause as much frustration as the conflict with AppleShare Server 3.0. Luckily the conflicts are only between servers on the same machine, so an AppleShare client machine will work happily with a QuickMail server, and a QuickMail client will coexist with an AppleShare client. It's a silly thought, but I wonder if an AppleShare server will get along with a QuickMail client? :-)

If you want to run both AppleShare Server 3.0 and QuickMail server, CE recommends that you do it on two separate Macs. I'm sure that this won't be entirely feasible for many smaller organizations, but I know that a user can coexist with QuickMail server on a personal machine since I've done it on a small scale (though before I was using System 7 and Personal FileSharing). That would be a stopgap measure until CE and Apple fix the incompatibility.

CE is working hard to fix this problem, but unfortunately, it's not a trivial fix. Apple and CE are evaluating changes to their server software so that the two can coexist better in the future. You can be sure that both companies are interested in better compatibility, since QuickMail is the most popular Macintosh email software, and I'm willing to bet that the combination of AppleShare 3.0 and System 7's FileSharing holds the lion's share of Macintosh networking software in use.

Information from:
Christian F. Gurney, Manager of Technical Support, CE Software
Mark H. Anbinder -- mha@baka.ithaca.ny.us

02 Mar 1992 | Print

|

Patents & Copyrights

by Clifford T. Matthews

Abacus R&D, Inc. (Disclaimer: I am biased since my company developed and markets "ROMlib" and "Executor," two products that predate Quorum's similar Latitude and EqualShow full article

Hide full article

Abacus R&D, Inc.

(Disclaimer: I am biased since my company developed and markets "ROMlib" and "Executor," two products that predate Quorum's similar Latitude and Equal. None of our or Quorum's products require the user to copy the Apple ROMs or System File. Please note that currently our products are only supported on NeXT computers, but this will change within six months.)

Adam C. Engst writes in TidBITS-108:

Finally, since Quorum based the display parts of Latitude on Adobe's Display PostScript, there is no conflict with Apple's patented QuickDraw software (which is why most other emulators have required that you find some Mac ROMs to pop in).

US Patent #4,622,545 covers Apple's region code. If you take the claims in that patent (there are 35) at face value, then anyone that attempts to be compatible with the Mac will either have to get permission to use the patented technology or be in violation of the patent. It is an absurd patent that for all practical purposes locks up the data structure itself. So, even though Quorum doesn't use regions for most of its work, since it has the ability to read regions when processing PICTs it is in violation (assuming there's no secret agreement between Apple and Quorum). Apple has done similar things with their HFS structure in England. They have a patent there, which if taken at face value, prohibits anyone from reading or writing HFS compatible disks. [Adam: Note that several companies including Hydra (Mac emulator on a PC) and Gadgets By Small (Mac emulator on an Atari ST) already market products that do this.]

I believe there are two real reasons that other emulators require Mac ROMs.

It is much easier to use someone else's code than to rewrite the code yourself. Whether or not you choose a different "look and feel," as Quorum does, or you intentionally do exactly what the application code is asking for, as we do, rewriting the ROMs is a major achievement. It is especially difficult since the Mac OS is a hodgepodge of code that has several side-effects that an emulator must duplicate if it expects to run real world applications.
The second reason has to do with "look and feel" copyright (not patent) issues. The basic claim is that by using legitimate ROMs, the right to the look and feel is transferred with the ROMs. Apple hasn't challenged the rights of people who have acquired Mac ROMs to use them in other devices (although there was a challenge related to who can sell Mac ROMs). The implications here are significant. Apple is in effect admitting that they don't totally own the rights to the "look and feel" or else they would be able to shut down these other companies. In fact, if Apple had made an explicit claim for the "look and feel" in the early days of development, warning developers that "... the look and feel of your product ... is commingled with the look and feel of our product ... and hence can't be used on any platform other than what we specify ..." then, perhaps, they would have the right not only to attack clone makers but also companies that hack up Macs and put them in boxes that Apple doesn't like. Of course if Apple had done that in the early days, these policies would have scared numerous developers away, perhaps causing the Mac to fail.

Copyright and patent issues are very difficult indeed. There have been exceedingly few cases that have actually gone to trial and none of them addressed the specific issue of whether or not the look and feel of an application belongs to the application writer or the operating system vendor. I bring this up to point out that Quorum may not be in the clear as much as the original article implies and to reassure people who are interested in our technology that we are equally aware of the legal implications of what we're doing and that we too believe we're totally in the clear. Quorum has chosen to alter the "look and feel" of applications built with Latitude or run under Equal; we have chosen not to. Films that were shot in black and white can now be "colorized," and some people prefer colorized films. However others prefer to be true to the original creation of the producers, directors and cinematographers. When it comes to computer software there are more concerns than those aesthetic; there are manuals to rewrite and people to retrain. The nineties are going to be interesting.

02 Mar 1992 | Print

|

Messaging Acronyms

by Adam C. Engst

I have some new acronyms for you - VIM and OCE. Only time will tell if these particular acronyms will be with us in the future, but VIM and OCE are certainly worth some thoughtShow full article

Hide full article

I have some new acronyms for you - VIM and OCE. Only time will tell if these particular acronyms will be with us in the future, but VIM and OCE are certainly worth some thought. VIM, or Vendor Independent Messaging, is a new standard programming interface proposed by Apple, Lotus, and Novell, and supported by Borland and IBM. The idea behind VIM, as far as I can tell, is that anyone will be able to write an application requiring cross platform messaging services using VIM, and application will then be able to talk to all other VIM-aware applications (you've heard of System 7-savvy - perhaps this should be VIM-vigorous?).

VIM is by no means a new idea, and in fact Apple and Lotus tried the same thing earlier under a different acronym, OMI, or Open Messaging Interface. Rule #1 of marketing initially unpopular products: change the name. If it's an acronym, probably nobody will even notice the difference. IBM didn't change the name of OS/2 and may have to drop a couple extra million dollars into marketing it as a result.

Back to the discussion at hand. OMI suffered from the fact that no one much liked it, especially Novell, which carries a lot of weight in the LAN community. Everyone likes the idea of VIM because it's becoming even more obvious that hardware and software from different vendors needs to communicate better. Of course, you'll notice that the companies in question are all members of the Anti-Microsoft Fan Club for various reasons, which may account for why Lotus and Borland are consenting to be seen together in the same press release. I suspect that OMI was a little too early to gather the support it needed. Now that everyone is a bit more worried about Microsoft's intentions for the industry, not to mention the way those intentions are being carried out, even Lotus and Borland might feel a bit more kindly toward each other.

VIM may end up helping with cross-platform messaging, but Apple has its own in-platform messaging scheme now too, called OCE, or Open Collaboration Environment. OCE will add a pleasant front end to what is currently a bit of a user interface nightmare - connecting to network services and working with them. Even basic email programs are often a pain to use and aren't as integrated with the rest of the operating system as many users would like. OCE should help a lot in that respect, providing a Mailbox icon and a World icon right on the Mac desktop and plenty of behind the scenes technology as well.

Integrated email -- The Mailbox icon will open to a window displaying incoming mail, whereas outgoing mail will be handled partly through drag & drop on the Mailbox icon (presumably for pre-addressed files) and partly through integration with applications. Some people on ZMAC were discussing the possibility of using this sort of capability to mail a file to a coworker and then have changes to that file automatically updated in the remote copy through the Edition Manager, a capability that could be very popular in a publishing workgroup, for instance.

I'm especially interested in the concatenation of all my mail services into a single mail environment. Quite frankly, I'm tired of checking email on five different services, each with a completely different interface. I'm still envious of CE's Don Brown though, since he has more email addresses on his business card than I had thought possible. He who dies with the most addresses wins, but no one will care once OCE is out and used. Incidently, one of the electronic islands, America Online, is busy at work on a bridge to the Internet. Look for it sometime this spring or summer.

Network services on the desktop -- The World icon will help bring everything together by providing a single location for all network services and devices, so you don't have to search about in the Chooser. Aside from servers, databases, and network devices such as printers and fax modems, users and groups will be represented in the World window, so sending a file or email to someone remotely could be as easy as dropping it on their icon. I'm sure there will be other methods of sending information as well, since drag & drop, as nice as it can be, is not the ultimate mail interface.

Data Wrappers -- Of course, once Apple brings all this wonderful network stuff out of the closet (does that mean all of us who live on the nets have to come out too?), great confusion will reign due to the massive amount of information suddenly available. Luckily for us, Apple has considered this problem and has come up with the idea of the data wrapper, a layer of indentifying information wrapped around a data file. You'll be able to add keywords, events (some interesting functions could come from this), and even your own customized fields to the data wrappers, which will then allow you to filter your files based on the wrapper criteria. I hope Apple will also provide some tools for automatically creating data wrappers and filtering the data in them, since I've found such keywording too much trouble in the past. How many people really enter summary information for every one of their Word 5 files?

Data Worries -- Some third parties like CE Software are concerned that OCE will remove much of the need for their products. After all, if email is integrated into the Finder and major applications, why bother to use QuickMail? I imagine that Apple's tools will fall short of the sophistication needed by power users and large organizations. Apple often targets its software at a common denominator of user, thus increasing the available market and leaving room for third parties to provide enhancements at the same time. I see no reason that OCE will be different, and even if programs like QuickMail do become redundant, I'm sure that CE will capitalize on its knowledge of email applications and uses to retain a leadership role in the email market. If nothing else, someone is going to have to write gateways for OCE, and nothing has more gateways than QuickMail.

It is nice to see Apple working on this kind of stuff for the Mac since operating systems of the future will have to be aware of more than just the machine they live on, and I think Apple realizes that network awareness is only half the battle. The other half is making those services easily accessible and useful, something which Apple is generally, though not universally, good at. I'm all in favor of making email easier, so I'm looking forward to whatever Apple does come up with.

Information from:
Mark H. Anbinder -- mha@baka.ithaca.ny.us
Apple propaganda

Related articles:
MacWEEK -- 10-Feb-92, Vol. 6, #6, pg. 1
Communications Week -- 10-Feb-92, #389, pg. 1

Syslogd Overwhelming Your Computer?

Recent TidBITS Talk Discussions

TidBITS#109/02-Mar-92

Administrivia

Printing Notes

More On Viruses

Virus Fighters

QuickMail & AppleShare 3.0

Patents & Copyrights

Messaging Acronyms