TidBITS Issue #71

08 Jul 1991 | Print

MailBITS/08-Jul-91

For those of you struggling with MaxAppleZoom's recent demise, yet more hope exists. Bob Boonstra came up with a patch that he's found to work with both version 1.3 and 1.3.1 of MaxAppleZoomShow full article

Hide full article

For those of you struggling with MaxAppleZoom's recent demise, yet more hope exists. Bob Boonstra came up with a patch that he's found to work with both version 1.3 and 1.3.1 of MaxAppleZoom. It requires a disk editor and a little technical knowledge, but is cleaner than the other solutions. He writes,

After further investigation, the following appears to be a more complete fix for the bug (time bomb) in MaxAppleZoom. The patch does not require an INIT and does not require changing the date. At least, it works for me, on version 1.3 and 1.31, with dates out as far as I checked (1999).
 For MAZ 1.3:
  INIT 1 offset 572:     change 02EA 3000 002C 65AE 43FA 0352
                             to 02EA 3000 002C 4E71 43FA 0352
  INIT 1 offset 5CE:     change 02EA 3000 002C 65AE 43FA 02DA
                             to 02EA 3000 002C 4E71 43FA 02DA
  cdev -4064 offset C48: change 02EA 3000 002C 65AE 1428 0004
                             to 02EA 3000 002C 4E71 1428 0004
  cdev -4064 offset CD0: change 02EA 3000 002C 65B0 5213
                             to 02EA 3000 002C 4E71 5213
 
 For MAZ 1.31:
  INIT 1 offset 570:     change 02EA 3000 002C 65AE 43FA 0340
                             to 02EA 3000 002C 4E71 43FA 0340
  INIT 1 offset 5CC:     change 02EA 3000 002C 65AE 43FA 02C8
                             to 02EA 3000 002C 4E71 43FA 02C8
  cdev -4064 offset C46: change 02EA 3000 002C 65AE 1428 0004
                             to 02EA 3000 002C 4E71 1428 0004
  cdev -4064 offset CCE: change 02EA 3000 002C 65B0 5213
                             to 02EA 3000 002C 4E71 5213
The patch substitutes a NOP for a conditional branch that follows each of three CMP2 range checks. The value being checked, and the range checked against, are computed by code so obscure (clever?) that I don't know exactly what is being bypassed, or why it was there, but it works for me. In each case, the patches to the INIT prevents MAZ from not loading, while the patch to the cdev prevents the Control Panel device from being disabled. Thanks to Nobu Toge for pointing out the problem with the cdev, and to Scott E. Lasley for sending me version 1.31.

TidBITS is available in many places online, but until recently has not appeared on Delphi. Luckily for all of us, Mike Martin has graciously volunteered to upload each week's issue to Delphi for me (there' s a limit to how much I can do online personally). So for those of you on Delphi who haven't seen TidBITS before, welcome, and I hope you enjoy it. I'm sure Mike will forward limited mail back to me via America Online, so if you have comments or suggestions, please feel free to send them along (just don't swamp him with mail - I'm sure he's got better things to do than play mailman). Thanks for all your help, Mike! Now are we missing any other online services? How about BIX, the BYTE Information Exchange? Does anyone out there use BIX?

Although TidBITS is available in many electronic hideaways, it is no longer available in ForumLink on America Online, simply because ForumLink is no longer there. It was dissolved recently, and although I don't know exactly why yet, I suspect it simply wasn't getting enough traffic. Unlike most everything on the Internet, AOL has to turn a profit, and if an area is unpopular, then it's not helping make money. We're trying to find a new place for TidBITS on America Online, but in the meantime, you can find new issues in the HyperCard library there. If you want to help our search for a new spot on AOL, send mail to me at Adam Engst and to Tim Barwick (AFP TimB). He's the person who decided to drop ForumLink. Ideally we could get a specific TidBITS section where everything would be available and where each issue would appear quickly.

Shawn Barnhart writes, "In TidBITS-069/01-Jul-91 you go on at length about using Macs for video conferencing, lamenting the current state of A/V compression and decompression. There has been considerable discussion in rec.video.satellite over the past six months or so of a new satellite TV service called SkyPix that is supposed to provide 50 or so channels off of one satellite transponder via some pretty tricky video compression. Supposedly it's high-quality digital video, but evidently fast motion scenes give the compression hardware a bit of headache, resulting in jittery video. But it would seem like the ideal technology for video conferencing, where as you said in TidBITS, most of what you see is a talking head. With this kind of technology you could use just one satellite transponder and get 25 or so simultaneous video conferences."

John Norstad writes, "Disinfectant 2.5.1 is a new release of our free Macintosh anti-viral utility. Version 2.5.1 corrects an error in the version 2.5 INIT which caused some programs (e.g., CompuServe Navigator) to crash on Macs using the Motorola 68000 processor (the 512KE, Plus, SE, Classic, and Portable.) Version 2.5.1 also corrects an error in the 2.5 program which could, at least in theory, cause crashes or hangs during program startup or when you try to do a scan. We apologize to everybody for the inconvenience caused by these errors in the 2.5 release. The errors are serious, and we strongly urge all Disinfectant users to obtain the new version 2.5.1."

Information from:
Bob Boonstra -- jrb@mbunix.mitre.org
Mike Martin -- CWSoldier at AOL
Shawn Barnhart -- sbarnhar@mailbox.mail.umn.edu
John Norstad -- j-norstad@nwu.edu

08 Jul 1991 | Print

SevenBITS/08-Jul-91

by Adam C. Engst

A few weeks ago I talked briefly about Chris Derossi's Hierarchical Apple Menu (HAM) and some of its competitors-to-be. In the meantime I've heard some more informationShow full article

Hide full article

A few weeks ago I talked briefly about Chris Derossi's Hierarchical Apple Menu (HAM) and some of its competitors-to-be. In the meantime I've heard some more information. Apparently, there's some possibility that HAM will be built into a future version of System 7, which accounts for the fact that Chris hasn't released it yet. No word what the interface folks at Apple will decide, but I'd like to see it sometime soon. On a related note, apparently a pre-release version of Connectix's SuperMenu was leaked to the public. Magic Apple, as it's called, has quickly made the rounds of the Internet, appearing in Europe as well as the US. According to author Fred Hollander, Magic Apple has some bugs and isn't the sort of thing you want to run regularly. SuperMenu will be commercial software, included with the System 7-savvy HandOff II 2.2, so if you have a copy of Magic Apple, please delete it and wait for the stable release of SuperMenu. Fred also promises that there will be many more features in SuperMenu and HandOff II, so there will be incentive to buy the final version. Current plans call for all registered users of HandOff II to receive a free upgrade, so if you already have HandOff II, you're all set.

If you like to have all sorts of information at hand and you have the disk space to support your habit, you might check out a FileMaker II database created by Kathryn Turpin on America Online. Kathryn collected and edited all messages (other than the obvious drivel) pertaining to System 7 that she could find on AOL from 10-May-91 to 13-Jun-91. Kathryn edited down the 7 MB of raw material to 1049 records comprising about 2.6 MB. It is stored in a self-extracting Compact Pro archive and takes about 125 minutes to download, I presume at 2400 bips. Kathryn said that she will probably continue her work collecting information on System 7 and in August will upload an update to the database covering messages after 13-Jun-91. It will include updated compatibility information and possibly even extracts from magazine articles. So if you have FileMaker II or Pro and want to collect information on System 7, here's a good way to get started.

Connectix -- 800/950-5880

Information from:
Fred Hollander -- F.Hollander@applelink.apple.com.
Michael Costello -- costello@stx.uucp
Kathryn Turpin -- KathrynT at AOL

08 Jul 1991 | Print

Dirtier ROMs

by Adam C. Engst

For some time after I coordinated the NewROMs petition there was no response at all. Henry Norr of MacWEEK said that he thought the issue was dead until Apple issued a statement, and the only other mention that our letter received came from Bob Cringely of InfoWorldShow full article

Hide full article

For some time after I coordinated the NewROMs petition there was no response at all. Henry Norr of MacWEEK said that he thought the issue was dead until Apple issued a statement, and the only other mention that our letter received came from Bob Cringely of InfoWorld. In the last few days I've heard some more interesting news, though it doesn't necessarily mean anything in terms of getting new ROMs.

A few days ago I got a call from David Burmaster, a consultant based in Cambridge, MA. He was irate about the problem of the dirty ROMs and had gone so far as to send a letter to John Sculley threatening a lawsuit. What interested me about his situation was that Apple responded by saying that he could jolly well go out, buy MODE32 from Connectix, and shut up. OK, so I doubt that Apple actually worded it like that, but David was upset enough that it might have been. We can see that Apple now officially recommends MODE32. David checked with his lawyer to see what kind of chances he had at winning a suit against Apple for misrepresenting the abilities of the Mac II, IIx, IIcx, and SE/30. His lawyer said that although he thought he could prove the misrepresentation in court, it would take 18 to 24 months to get a court date and a minimum of $5000 in legal fees to file. That's the first educated legal opinion I've heard on the issue, and it's interesting that it does put Apple in the wrong. David decided not to sue since it made no financial sense and since Apple Legal is not a group you want to tangle with unnecessarily.

A day or so later, I received another call (I normally get a lot of email, but not too many telephone calls, so all this surprised me), this time from Roy MacDonald of Connectix. He'd heard from a MODE32 beta tester that I would be a good person to put on the press list, so he called and asked me if I'd like a copy of MODE32 to work with. Mark H. Anbinder has already done a mini-review of MODE32, but I'm never one to turn down software to test. I haven't been using it for all that long, but it seems to work just fine. I can't ask for virtual memory over 16 MB since I don't have that much disk space available, but I do plan to clear up some more space eventually. I'll keep people posted on my experiences with MODE32. Thanks, Connectix!

A number of people have wondered why Apple couldn't just build the 32-bit cleanliness into System 7, as they did with A/UX. I've heard that the 32-bit cleanliness worked a bit like virtual memory under System 6. Someone at Apple said to the engineers, "How about putting virtual memory in System 6?" and the engineers said, "Can't be done." In January of 1989, Connectix introduced Virtual 1.0. So when work started on System 7 and virtual memory was included, someone said, "How about 32-bit cleanliness, so users can use lots of memory and virtual memory on those older machines?" Once again the reply came back, "Can't be done in System 7. A/UX is a different OS." Once again, several months later, the wizards at Connectix came out with MODE32. Hmm, starting to see a pattern here? Actually I doubt Apple will let such an obvious gap happen again, if only to save face. Next time somebody asks one of those questions, the answer will be, "Is tomorrow soon enough?"

Lots of rumors have floated by about how Apple has some 32-bit clean ROMs based on the IIfx ROMs or the IIsi ROMs, or something like that. I've now heard that those rumors were true, though the details are still to be completely discovered. Apparently, some people poking around at Apple found a couple of boxes labeled "Mr. Clean" and inside the boxes were a bunch of 32-bit clean ROMs. These ROMs were never a product, are not a product, and may never be a product, but when they were made, Apple distributed them to developers who used machines with dirty ROMs and who needed to test their code on the 32-bit clean ROMs. Essentially then, it sounds like these clean ROMs got caught in some sort of marketing/administrative snafu and ended up in a closet instead of on a production line and in all of our hot little hands. Humph!

Information from:
Roy MacDonald -- connectix@applelink.apple.com
Pythaeus
David Burmaster

08 Jul 1991 | Print

Mac to Unix Backup

by Adam C. Engst

In this day of limited resources, I especially enjoy hacking together strange combinations of equipment to cover for an expensive solution. Back when I worked for Cornell as a student supervisor, we had a real problem with backupsShow full article

Hide full article

In this day of limited resources, I especially enjoy hacking together strange combinations of equipment to cover for an expensive solution. Back when I worked for Cornell as a student supervisor, we had a real problem with backups. Most of our Macs were public and didn't have hard drives, but a couple of servers had hard drives, and the operators' Macs were similarly equipped. We seemingly had a negative hardware budget but floppy-based backups were simply too much work.

Cornell has a fiber backbone (which is actually more complimentary than it initially sounds :-)) so all of these Macs could easily connect to the various mainframes. What I wanted to do, but never managed to get the time nor the approval for, was to set up some kind of automatic backup scheme whereby the Mac would upload all its files to an account on one of the mainframes, and once up on the mainframe, all the files would be included in the automatic tape backups. I'd decided on using one of Cornell's Vaxen because binary files uploaded to the IBM mainframe came back down intact but missing the type and creator, not something you'd want to recreate by hand. But, like many of my brainstorms (OK, so maybe that's pushing it, but it was more than braindrizzle), the scheme fell by the wayside, never to be implemented. The mainframe folks probably would have hated me for it anyway.

Obviously someone at the University of Utah had the same idea, but being slightly brighter than I, decided to implement it with Unix machines and custom software. Succinctly named Dump (in the spirit of Unix, they probably wanted to call it du, but that's taken already), the program is a small MultiFinder program that talks to the Unix client programs (also supplied in source code) that actually perform the backups and restores. The Mac program synchronizes the Mac's clock to the Unix machines clock, and you can do full and incremental backups to whatever tape drive or other backup media you have for the Unix machine. The Macintosh program uses TCP, so you do need MacTCP from Apple (available from APDA) for this to work. If you've got the necessary network anyway but not MacTCP, you should probably get it because it provides useful services and works with programs such as NCSA Telnet, HyperFTP, and various NNTP servers.

Since many implementations of Unix require a recompile for a program to work, the Unix client programs come only in source code. This also allows sites with complex backup needs to modify the code for their own purposes. Although the code is specifically designed for Unix, and the scripts that manage the backups are Unix shell scripts, you could theoretically write your own client programs on a non-Unix host that supports TCP/IP.

Considering what this product will do for you, the price is quite reasonable at $200 for an educational site and $250 for all other sites. An educational site is a single campus, and all other sites are considered to be a single location or mailing address. As I said before, you do need MacTCP, along with a Mac running MultiFinder under System 6.0 or newer (I don't know what the compatibility status of MacTCP is with System 7 currently, but I know there are some problems and an upgrade is planned). You also get User, Installation, and Protocol Documentation, which is good, since I have the feeling that this set of programs requires a good bit of customization, for which documentation is essential.

For general information and a copy of the license agreement contact:

Loretta Cruse
University of Utah
Center for Software Science
3190 Merrill Engineering Building
Salt Lake City, UT 84112
801/581-5017
FAX: 801/581-5843
cruse@cs.utah.edu

For technical information, contact:

Brian Sturgill
801/581-5591
brian@cs.utah.edu

APDA -- 800/282-2732 US -- 800/637-0029 CAN
408/562-3910 others
APDA@applelink.apple.com

Information from:
Brian Sturgill -- brian%harpo@hellgate.utah.edu

TidBITS Watchlist

Spin Through Toolbar View Options

Recent TidBITS Talk Discussions

Other articles in the series The 24-bit ROM Blues

TidBITS#71/08-Jul-91

MailBITS/08-Jul-91

SevenBITS/08-Jul-91

Dirtier ROMs

Mac to Unix Backup