From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.comm
Subject: Re: MacIntercomm (finally a real comm program)
Date: 9 Oct 92 17:38:26 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <1992Oct8.233419.14095@muddcs.claremont.edu>, jam@jupiter.claremont.edu (Jay Margolis) writes:
> In article <cshotton-081092155153@oac2.hsc.uth.tmc.edu>  
> cshotton@oac.hsc.uth.tmc.edu (Chuck Shotton) writes:
>> I'm with Tim on this. Good APPLICATION level software should never touch
>> the hardware directly.
> 
> Where are you getting this impression that MacIntercomm is doing anything  
> "directly to the hardware"?  They are simply using interrupts to continue  
> running.  That has nothing to do with the hardware and is a well defined  
> and documented method of doing things that has been around since the  
> Macintosh 128K.  

Agreed. I believe it is possible to implement this stuff to the published
programming documents. Difficult, but possible.

> There are no Apple warnings against it, and besides the  
> fact that no one else has ever done it because of all the hurdles  
> involved, there is nothing wrong with it.  MacIntercomm is MUCH more able  
> to be compatible with future hardware and system software, not less.  

I disagree with this assertion.

The safest configuration is like an armadillo -- one that is all rolled
up intil a tight, generic application ball with nothing hanging out. Most of
the existing cooperative communications applications fit this model. They
will continue to work with little regard for what Apple does to the system.
Indeed, they work with just about all existing INITs.

MacIntercamm, however, has KNOWN, DOCUMENTED incompatabilities with existing
INITs. That does not imply to me to be MORE compatable. 

Further, a number of posters have indicated that MacIntercomm crashed their
machine, or that they were unable to get it to run properly after several
tries. That does not imply to me to be MORE compatable.

Jay, again, it is OK to be excited about a product, but let's not overstate
this. MacIntercomm is taking risks to provide this preemptive tasking
feature. It is coupling in tight with the system. Add a few INITs, and it
breaks. Chances are, when Apple does change the system software, things will
break.

Here's a question -- does MacIntercomm work on the Radius Rocket? No?
Well that's OK, Smartcom II doesn't either. (But that's the fault of the
RocketWare, not Smartcom II) But other comm software does.

> They depend on neither the hardware nor the system software, but rather the  
> code that is part of the program.  A cursory examination will reveal that  
> many top applications such as Microsoft Word are also written to bypass  
> parts of the Mac toolbox because they are inadequate.

Comparison with any Microsoft product is a non-sequitur. Why don't you try
a comparison with other Comm software. Like Smartcom II, Or Microphone II,
or White Knight, VersaTerm Pro, Zterm, etc.

> MacIntercomm communicates with serial ports just like anything else, and  
> also supports the comm toolbox.  How much more compatible can you get?  

It could work with more INITs. It could work for people that had it crash
on them.

> On top of its invisible file transfer feature, there is a comm program that  
> blows all the others away (except it wont have a scripting language until  
> they ship 1.1).  If the multitasking bothers you, turn it off.  That's  
> what the checkbox is for.  You can then run any init you want to and still  
> use the best comm program.

Oh NO! You can't do that. If you turn off the multitasking, then any background
transfer will crash or abort if you try to do anything. At least, that's what
you said before about background transfers with OTHER comm software.

Face it, Jay, if this multitasking stuff were so robust, so compatable,
why would there be a setting to turn it off? QED

-- 
Bill Coleman, AA4LR                ! CIS: 76067,2327    AppleLink: D1958
Principal Software Engineer        ! Packet Radio: AA4LR @ W4QO
Hayes Microcomputer Products, Inc. ! UUCP: uunet!hayes!bcoleman
POB 105203 Atlanta, GA 30348 USA   ! Internet: bcoleman%hayes@uunet.uu.net
Disclaimer: "My employer doesn't pay me to have opinions."
Quote: "The same light shines on vineyards that makes deserts." -Steve Hackett.

Newsgroups: comp.sys.mac.comm