HDTenEightyP/NetNews huggingface dataset:
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Why Macs are better (and the others aren't)
Date: 30 Sep 92 11:50:58 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <qdkzdx#@rpi.edu>, johnsd2@lib106.its.rpi.edu (Daniel Norman Johnson) writes:

[ Much of the cut and paste debate deleted ]
> Someone (Wolfgang?) writes:
> |> Excels "nonstandard" implementation of the clipboard you complain about
> |> is probable caused by the fact that it delays the actuall cutting
> |> (i.e. removing) of the source cells until you actually paste the cells
> |> to another part of the sheet. This is indeed a bit different from how
> |> it works for example in edit fields. 

And that is exactly the problem.

> |> Its all done in one,
> |> single, atomic operation: the source cells become empty, and at the
> |> same time their contents appear at the destination.
> 
> This is SPECIFICALLY what Cut+Paste was origionally devised
> to avoid. After you "cut", the worksheet is in a special mode.
> If you aren't in that mode, you can't paste. If the mode
> was completely invisible (ie it was strictly an implementation
> thing) this would be fine. But the user CAN see it in Excel;
> if you try to do anything after a cut or copy, the cut-selection
> gets foozled, and you cant paste.

Also, if you do a normal cut, you can paste the same information in
multiple places, since the inforamtion is cut to the clipboard. Repeating
Paste copies the same contents over and over.

Excel's design seems to miss this. Of course, Excel was about the first
spreadsheet for the Mac (and it was implemented first on the Mac, and only
came to the PC much later). It is typical of MS design technique to 
do something simple (like cut and paste) in a non-standard fashion.

Wingz (the spreadsheet I use), doesn't have this problem. It implements 
cut and paste just like other programs do.

-- 
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.advocacy
From: peter@NeoSoft.com (Peter da Silva)
Subject: Re: Whither Apple? (Wither Apple?) 
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Sat, 03 Oct 1992 04:18:47 GMT

I would like to suggest that the main advantage to the Mac is not the O/S,
the GUI, or any of that stuff. It's the applications. The Mac has more high
quality applications than any other PC. Why? Because Apple very early on
insisted that Mac applications be high quality, and support developers who
wrote good software. And dumped on developers writing inconsistent and
weird applications that didn't fit into the system. And provided a good
set of (for the time) top notch applications with the machine as both a
selling point and example.

It's certainly not the OS, and while the GUI is good it's by no means the best.
The graphics library is well suited to the interface, but that's not unique:
NeWS and NextStep are better.

That's why I expect NeXT to carve out enough of a market share for long term
survival. They're doing the same thing (no surprise). Oh, sure, Mach is a
memory hog, but it's not growing that fast... and the Mac system software is.
Hardware is getting cheaper. When the first under $2000 Next comes out I'll
probably buy one, to go along with my Amigas and Mac and UNIX box.
-- 
Peter da Silva.  <peter@sugar.neosoft.com>.
 `-_-'   "Heeft u vandaag al uw wolf geknuffeld?"
  'U`  
Newsgroups: comp.sys.mac.advocacy
From: tzs@stein.u.washington.edu (Tim Smith)
Subject: Re: Mac's Doomsday
Organization: University of Washington, Seattle
Date: Sun, 4 Oct 1992 04:40:59 GMT

Nazedgi@yalevm.ycc.yale.edu (Ivan@yalevm) writes:
>
>
>Being a former PC user and now a Mac convert I've come to the following
>conclusion:  The majority of Mac users just don't get it.  If Apple really
>wants to lure a significant amount of PC users it will have to do something
>more than proclaim the superiority of the Mac hardware and software. 
>They'll have to enter a cut-throat competition:  Dell is doing it, Compaq
>is doing it,  Big Blue is doing it.  And I'm not talking about

Since Apple has a bigger market share than the companies you name, why
do you use them as examples of what Apple has to do to get significant
market share?

--Tim Smith
From: ibhan@husc8.harvard.edu (Ishir Bhan)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Why Macs are better (and the others aren't)
Date: 5 Oct 92 15:49:20 GMT
Article-I.D.: husc8.ibhan.718300160

peter@NeoSoft.com (Peter da Silva) writes:

>In article <hdpz1g+@rpi.edu> johnsd2@rpi.edu writes:
>> Well, I at least find pop up menus a pain because the targets are
>> really small, vertically. They are wide enough, but one line
>> of text is a pain to hit accurately. It slows me down.

>I don't understand this. All menus require you to hit a vertical target
>of that size, once you've pulled it up.
>-- 
>Peter da Silva.  <peter@sugar.neosoft.com>.
> `-_-'   "Heeft u vandaag al uw wolf geknuffeld?"
>  'U`  
>Kunt u mij de weg wijzen naar het dichtsbijzijnde intelligente zoogdier?

Once you've pulled it up, yes, but to hit the menu in the first place is
easier with a top of the screen menu bar.  Just give your mouse a hard
shove and then you just need to worry about the horizontal location.

-- 
------------------------------------------------------------------------------
|                     Ishir Bhan (ibhan@husc.harvard.edu)                    | 
|  "Oh, I should be...a polar bear...but it's impossible." - The Cure        | 
------------------------------------------------------------------------------
From: wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!)
Subject: Re: When is a CLI faster than a GUI?
Date: Wed, 30 Sep 1992 23:50:29 GMT
Organization: MSD software vault #9 @THD

In article <3tjzqnk@rpi.edu> johnsd2@rpi.edu writes:
>Oh good. :)
>
>|> Command history                        (mouse macros don't count)
>
>A workaround to a problem GUIs dont (well, shouldn't) have,
>namely long obnoxious commands. GUIs have _short_, obnoxious
>commands. :) All the difference in the world.
Aha! Found a week spot there apparently. Histories are maybe my favorite
reason to use a CLI. If you run several different programs sequentially,
and repeatedly (as I always seem to do) it's a great timesaver,

>|> Command name completion (not filename) (possible, but not implemented)
Actually coming to think of it, since a GUI doesn't have a concept of
a PATH, where the commands reside, the only option you have is fill up
the main screen with icons as 'immediately available' commands. Obviously
this is rather limiting, and as soon as you move a window over it you
are losing time, uncovering parts of yor desktop.

Nat!

-- 
 -----   Email: wallmann@backus.pu.informatik.th-darmstadt.de  -----
                "Bang that bit that doesn't bang"                 
 Album of the month: "Psalm 69" Ministry

Newsgroups: comp.sys.mac.advocacy
From: jmo50888@uxa.cso.uiuc.edu (Josephine M. Otter)
Subject: Re: Macintosh emulation on Amiga
Organization: University of Illinois at Urbana
Date: Sat, 26 Sep 1992 18:47:18 GMT

UC525655@mizzou1.missouri.edu (Mark Eaton) writes:
>So lets get this straight... an Amiga, running in black and white,
>is 10% faster than a mac IIci running in color? <snort>
> 

No.  An Amiga >EMULATING< a mac IIci in black and white is 10% faster than a
mac IIci running in color.
From: ifbb657@ccwf.cc.utexas.edu (Douglas Floyd)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Trepidations of a potential mac-user
Summary: OS/2 needs recent BIOS
Date: 29 Sep 92 15:08:45 GMT
Distribution: usa
Organization: The University of Texas at Austin, Austin TX

In article <1992Sep25.031158.4324@cc.umontreal.ca> tsirbasc@ERE.UMontreal.CA (Tsirbas Christos) writes:
>Concerning OS/2, somebody wrote:
>>Where is the misinformation? What is misleading? Nan, not everyone is running
>>OS/2. If it is as great as you make it out to be, one must certainly ask
>>the question -- why?
>
>Why? Well, for starters, try the fact that it takes up 22 diskettes. Second, tryto understand that a lot of people have been unable to install OS/2 on their 386clones.  The reason for this is unknown to me, but I have several friends who have
>never been able to install OS/2 for one reason or another
>
>Chris in Montreal

The BIOS in the 386 must be produced later than October '91 for
OS/2 to work.

-- 
------------------------------------------------------------
******* ifbb657@ccwf.cc.utexas.edu (Douglas R. Floyd) ******
------------------------------------------------------------
|            (Insert standard disclaimer here)             |
|  I would rather have a frontal lobotomy than Windows NT! |
------------------------------------------------------------
Newsgroups: comp.sys.mac.advocacy
From: marquis@netcom.com (Roger Marquis)
Subject: Re: IBM SUCKS! .NOT.
Date: Mon, 28 Sep 92 19:43:15 GMT
Organization: Netcom 

In article <6056.2ac6d891@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>>>In article <1657@anagld.analytics.com>, sammy@anagld.analytics.com (Sam Blackburn) writes:
>>>> Macs aren't suited for a lot of applications that PCs do today.  
>>>
>>>Name *ONE*.
>> 
>> Anything that requires system programming (batch files).  
>
>I have get to see a "system programming" application. This is a bad answer.
>That's unfortunate. You're other answers were quite good.

OK, tell me how to do the following on a Mac then.

->We'll, I just finsihed a 150 line batch file that collects timesheet
->data from 5 remote offices of a large law firm and uploads them to
->their HP3000 for processing on a nightly basis.  I would have rather
->have used a UNIX shell script to do this but the ability is there in DOS.
->I don't see an equivalent ability in the MacOS.  Perhaps when Frontier
->is bundeled with the OS ... we'll see.>


 DOS batch commands were clearly useful here to 1) compare
files for validity, 2) verify the existence of a file, call another
batch file to modify the timesheet data (which could not have been
done without a command line), 3) set and check that the specified
drives were mapped, 5) write the output to a log file for verification
verification, 6) maintain the previous 2 days log files for reference,
etc.  I'm sure there's more but this is a clear case of an everyday
business problem that was easily handled by a PC.  It's questionable
whether the same thing could be done on a Mac with or without Frontier.



Roger (marquis@netcom.com)
Newsgroups: comp.sys.mac.advocacy
From: faheyr@silver.ucs.indiana.edu (Bob Fahey)
Subject: Re: Macintosh emulation on Amiga
Organization: Indiana University
Date: Tue, 29 Sep 1992 02:22:45 GMT


>In article <Bv786v.9q5@news.cso.uiuc.edu> jmo50888@uxa.cso.uiuc.edu 
>(Josephine M. Otter) writes:
>> No.  An Amiga >EMULATING< a mac IIci in black and white is 10% faster 
>than a
>> mac IIci running in color.


Hmm... I think there are a few misquoted numbers floating around here...
I don't know about the newer Amax versions (namely Amax II+, which I thought
was the same speed as previous versions), but I used to run Amax II a while
back on a <read> stock Amiga 500. This was on a 7.14Mhz 68000, no frills,
etc. What some mac speed programs reported to me was that I was running
the emulation 10% faster than a <<stock Mac Plus>>. I don't know what system
you tested Amax on, but I am sure that on a 25Mhz '030 Amiga, you would be
comparable to the speed of a Mac II running 25Mhz. (whichever Mac II series
that might be)

But to say that Amax on a stock Amiga runs 10% faster than a IIci is next
to impossible. Doesn't the IIci run a 68030? What system did you supposedly
get a 10% speed increase over a IIci? A 16Mhz A3000? It most DEFINATELY
was not a standard "out-the-door" unaccelerated Amiga.

Over on comp.sys.amiga.*, a lot of talk has been going on about software
and hardware emulations over the past 6 months or so. Yes, you can emulate
just about anything you want, given that you can fool your emulated system
into thinking that your host system is compatible. But, my question is:
Why? Why spend $500 to get 90% compatiblility with a system if you can just
spend $700 for a nice used system that you are trying to emulate? Believe
me, not all of the people who are running emulators are penny-pinchers.
Emulating another computer is more of a status symbol than a necessity.
The only time I could see it being cost-effective is when we can get a
NeXT emulator running on a Mac, Amiga, or whatever, for a few hundred
dollars. 

Don't get me wrong, however. I have my share of emulators, but I use them
only when I don't have access to the real thing.  I think that is the whole
point of emulating.  How many Mac owners do intensive work on SoftPC?
I'm sure there are some, but do you emulate because you want to, or because
you HAVE to for lack of the real thing?

Whew! I think I'll step off the soap box, & let others take it from here.
just my $.02.... ;-)

-Bob
-----------------------------------
faheyr@silver.ucs.indiana.edu
faheyr@zuni.ucs.indiana.edu -- NeXT Mail

Newsgroups: comp.sys.mac.advocacy
From: "Marc VanHeyningen" <mvanheyn@apricot.ucs.indiana.edu>
Subject: Re: When is a CLI faster than a GUI?
X-Quoted: 58%
Reply-To: mvanheyn@whale.cs.indiana.edu
Organization: Computer Science Dept, Indiana University
Date: Tue, 29 Sep 1992 12:37:56 -0500

Thus said ewright@convex.com (Edward V. Wright):
>In <1992Sep29.004928.26815@news.cs.indiana.edu> "Marc VanHeyningen" <mvanheyn@mango.ucs.indiana.edu> writes:
>
>>>>A non-ASCII .txt file?  Whoever created that should be shot!  
>>>
>>>Well, we could start with IBM, then.  Have you ever heard of EBSDIC?
[ ... ]
>>It it related to the issue of .txt files in UN*X in any way? 
>Yes.  EBCDIC text files can be transferred to a UNIX machine.
>In which case, the UNIX machine's file system would then contain
>text files that are not ASCII.  This is called "networking."

Yup.  They also could, I suppose, be transferred to a Mac.  I assume
that your magical Mac would (unlike Big Bad UNIX which might require a
program to convert them) handle them perfectly with a simple double
click?

>No, just another example of a snot-nosd student trying to take
>a cheap shot and making a fool of himself instead. 

It's refreshing to see such well-reasoned argumentation.  This one ranks
up there with "Your shell script does exactly what you meant it to do,
but not precisely what you said it did when describing it in an
imprecise language like English.  Therefore, CLIs are evil."

>>\begin{not-to-be-taken-seriously}
>>Suppose you are addressing a subordinate in how to do something you want
>>done.  You are in a hurry, and want to express the idea quickly.  Which
>>of the following two subordinates is more valuable to you in this
>>situation:
>
>>- The one who takes a pithy textual description of the task and performs
>>  it immediately.  "Get coffee from 332-G."
>>- The one who requests you express the task to be done by playing
>>  charades, making particular movements to represent "go to room",
>>  selecting the room 332-G from a lengthy list, making gestures indicating
>>  that "coffee" is the thing you want him to get (or perhaps pointing to
>>  a little picture of coffee on a poster of lots of different items.)
>
>No, subordinate number three, who is bright enough to draw a map
>so that you can actually find Room 332-G.

I already know where Room 332-G is.  I'm trying to tell him to go
there and get coffee.  Preferably in two seconds or less, and without
disturbing the phone call I'm in the middle of or the six other tasks
floating around in my head.
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted

What you have, however, is not a shell script.  It's a csh abomination instead.
		- Tom Christiansen  
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: What's Easier To Use (read "better")
Date: 6 Oct 92 17:50:43 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <92276.175023ASI509@DJUKFA11.BITNET>, ASI509@DJUKFA11.BITNET writes:
> In article <2578@cronos.metaphor.com>, emg@Metaphor.COM (Mike Greenawalt) says:
> 
> I don`t know about the Macs of 1984. But I don`t call the jumping of the mouse
> cursor while accessing floppies smooth. 

Agreed. It does get sorta spastic.

> Neither the unability to do some work while downloading some stuff over the 
> serial port at 9600baud. 

Gee. My Mac doesn't have this problem. I regularly download while doing other
things. I've even done MPW COMPILES while downloading.

> Or the half day it takes to print some pages on a Laserwriter LS.

I have no experience with the LaserWriter LS, but you can turn background
printing on. This helps a lot.

> But this is on a 1991 IIsi, so perhaps it was better in the ole days.

Funny. I use a IIsi as well. I don't seem to have the same trouble you do.

> There are not that much system software components that have not been 
> converted to the GUI in OS/2. One of them is Backup/Restore which is 
> lacking at all on the Mac.

DiskFit and Retrospect are both excellent choices. Why do you say they are 
lacking? There's also other products such as Redux and FastBack.

-- 
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.advocacy
From: nagle@netcom.com (John Nagle)
Subject: Re: More info on system 7.1 and $$$
Date: Sat, 26 Sep 92 17:55:13 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

greg@applelink.apple.com (Greg Marriott) writes:

>In article <hp48sx.717272666@wuarchive.wustl.edu>, hp48sx@wupost.wustl.edu (HP48SX Archive Maintainer) writes:
>> [System 7.1] is a bug-fix...

>Nope.  System 7.1 is NOT a bug-fix release.  System 7.1's focus is world-ready
>software.  

       Hm.  System 7.0 was supposed to be "world-ready software".  Remember?
See IM VI, chapter 14.  And remember how much trouble Apple got into by
claiming the Mac II was "32-bit ready"?

					John Nagle
From: bcoleman@hayes.com (Bill Coleman)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: When is a CLI faster than a GUI?
Date: 2 Oct 92 15:12:55 EDT
Organization: Hayes Microcomputer Products, Norcross, GA

In article <TOMSTER.92Oct1155116@bigwpi.WPI.EDU>, tomster@bigwpi.WPI.EDU (Thomas Richard Dibble) writes:
> In article <6072.2ac8373c@hayes.com> bcoleman@hayes.com (Bill Coleman) writes:
>    In article <1992Sep28.202604.20391@news.th-darmstadt.de>, wallmann@backus.pu.informatik.th-darmstadt.de (Natuerlich!) writes:
>    > Command history                        (mouse macros don't count)
> 
>    Wrong! AppleEvents (when recorded) make up a detailed command history.
>                        ^^^^^^^^^^^^^
> That was the point.  I just did some horrendous task and now want to repeat
> it.  I did not know I would want to repeat it when I started the task.  I
> know that now.  Therefore, I did not start up my macro recorder.  Now.  How
> do I repeat that sequence of events with only a few mouse and/or keyboard
> clicks on a Mac.  On my pc, i press up-arrow, <enter>.

That's because you have recording turned on all the time.

There's no reason you couldn't do the same thing with AppleEvents. You could
tell the applications you are recording, and stick the last 100 or so
events into a circular buffer and get the same type of functionality.

-- 
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.advocacy
From: ckd@eff.org (Christopher Davis)
Subject: Re: Why Macs are better (and the others aren't) (long)
Organization: Electronic Frontier Foundation Tech Central
	<TOMSTER.92Sep30202903@banzai.WPI.EDU>
Date: Sun, 4 Oct 1992 05:38:47 GMT

Thomas> == Thomas Richard Dibble <tomster@banzai.WPI.EDU> 

 Thomas> The hardware *can* do this.  As long as you don't go through
 Thomas> DOS to read the disk, any format you want to use can be used.
 Thomas> As far as the availability of the guts of the Macintosh format,
 Thomas> I can not say one way or the other.  I would say that this is
 Thomas> the most likely hold-up to software which reads Mac disks.

Nope, the hardware can't read Mac 800K disks (though it can read 1.44M
disks just fine).  The 800K format uses different "zones" of the disk at
different rotational speeds to pack on more bits on the outer tracks;
that's where the extra 80K comes in.  The Mac drives can be
speed-controlled in software, but most if not all PC drives can't.
--
Christopher K. Davis      |       NET.INSIGHTS INTO ARTISTIC CRITICISM:
<ckd@eff.org>   EFF #14   | ``[Y]ou don't cure bad art by locking it all up
System Administrator, EFF | in one museum, you cure it by throwing tomatoes
+1 617 864 0665  [CKD1]   | at bad artists.'' --Barry Shein <bzs@world.std.com>
Newsgroups: comp.sys.mac.advocacy
From: tlt38517@uxa.cso.uiuc.edu (Terry Thiel)
Subject: Re: IBM SUCKS! .NOT.
Organization: University of Illinois at Urbana
Date: Sat, 26 Sep 1992 23:51:47 GMT

>It depends on what you mean by applications.  It would be difficult to
>argue that anything, on any platform, is easier to write a simple
>application under than Visual Basic.
Look at Prograph on the Macintosh and NeXTstep on the NeXT machine and you'll
eat your words.  They also do far more than Visual Basic.  
-Terry
Newsgroups: comp.sys.mac.advocacy
Subject: testing please ignore
From: system@fallout.lonestar.org
Date: 29 Sep 92 23:44:59 CST
Organization: DECUS DFWLUG BBS *Dallas*TX*

Testing please ignore
From: peter@NeoSoft.com (Peter da Silva)
Subject: Re: Why Macs are better (and the others aren't)
Organization: NeoSoft Communications Services -- (713) 684-5900
Date: Sat, 03 Oct 1992 03:58:44 GMT

In article <1acv6sINNa3n@travis.csd.harris.com> jimb@rcx1.csd.harris.com (Jim Burmeister) writes:
> A single menu bar at the top of the screen has one big advantage: it provides
> a target of "infinite vertical height" for the mouse pointer.

Why should you have to move the mouse pointer at all? The menu *should* pop up
right underneath the pointer when you hit the "menu" button.

Neither Windows or the Mac get this all right, but on large screens I find the
Windows method less irritating.

> Besides, you can only interact with one application at a time,

I can? I drag-and-drop stuff between applications all the time, and switch
active applications as often as I shift active windows. Everything becomes a
single meta-application called "what I'm working on right now".

I don't think of "OK, now what am I running?" most of the time.
-- 
Peter da Silva.  <peter@sugar.neosoft.com>.
 `-_-'   "Heeft u vandaag al uw wolf geknuffeld?"
  'U`  
Newsgroups: comp.sys.mac.advocacy