From: johnsd2@lib106.its.rpi.edu (Daniel Norman Johnson)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Why Macs are better (and the others aren't)
Date: 29 Sep 92 20:54:08 GMT
Article-I.D.: rpi.qdkzdx#
Reply-To: johnsd2@rpi.edu
Organization: Rensselaer Polytechnic Institute, Troy, NY.

In article <strobl.717780436@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
|> In <+!kz16n@rpi.edu> johnsd2@jec306.its.rpi.edu (Daniel Norman Johnson) writes:
[deletia- Cut&Paste]

|> >Nonetheless, it should (as I understand it) behave like you were
|> >copying something to a clipboard, and pasting it out again. That
|> >you can paste the same data in different formats matters not at all
|> >to this. Frequently, as you mention, the format is determined by the
|> >application being pasted to. The difference between the Macnitosh
|> >"copy all formats to the clipboard, paste whichever is appropraite"
|> >and teh Windows "don't copy anything to the clipboard until it is needed
|> >or the clipboard-owning app exits" is internal. (and has nothing to do
|> >with the Excel cut+paste problem I was complaining about)
|> 
|> I disagree. Excel is both a good and a bad example. It is a good example
|> because it illustrates something which can only be done using the
|> Windows model of the clipboard. It is a bad example, because it doesn't
|> get it right.
|> 
|> 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. But it has one  advantage:
|> there is no inconsistent, intermediate state of the sheet during
|> the time the cutout is parked in the clipboard.

There is nothing inconsistent about this state. Its a perfectly
good state. :) Nothing strange about it at all. If you do
a cut, it is part of what you want (ie, the selected stuff
goes away)

|> 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.

|> This is how it
|> works if you cut & paste within a single sheet. Windows implementation
|> of the clipboard would make it possible to extend this very behaviour
|> to the interapplication case. Unfortunately, they didn't do that,
|> perhaps in order to get an uniform behaviour on both platforms.

Well, they didn't get uniform behavior. And as far as I know,
Excel spreadsheet data is the only thing trhat gets treated
this wya- if you are cut&pasting text in an edit text box or
word processor, Cut&Paste works like on the mac. Is this incorrect?
 
|> Another point is, that "copy all formats, paste whichever is appropriate"
|> is only feasible if the number of different formats is quite small, and
|> if the amount of data in each format is so small that it doesn't matter
|> much, and - more important - if the actual rendering of all these
|> different formats doesn't cost much time. In practice, this means that
|> in the case of the simple clipboard model, you have to choose between
|> disadvantages - ask the user which format he wants to cut, don't 
|> use more than a few formats, or let the user buy a new computer be-
|> cause the cut operation takes so long.

You don't use Macs much, I guess. This easily got around by using
a few, standard formats. Apps generally write their own private
format, and either Text (+ styl, if styl info is included) or
PICT.

This conversion, incidentally, is only done when the app is switched
into the background.

If this one conversion is very slow, thats a problem but the Windows
technique wont help; You still have to do the conversion. Its just
a question of WHEN.

The clipboard data will also be shuffled to disk as necessary, and
the recieving app will only reload what it wants to use. (I _think_;
not entirely sure about that point)

This means that (a) you dont have rediculous amounts of data,
(b) cut/copy is fast (not much rendering- usually only 1 render, from
the internal format to TEXT/styl or PICT) and (c) Apps only have
2 formats they must support (actually, they are not requried to support
the styl part of TEXT/styl.. just ascii text); So they DO support it.

I have heard that Windows does not have a standard image or formatted-text
format, so Apps just have to wing it. And that means lotsa formats, if
you want to have it work. (unless, of course, I am wrong about that)

|> >[deletia- About Apple Menu like features]
|> >|> 
|> >|> Well, I prefer icons on my desktop denoting running applications
|> >|> and icons inside windows denoting startable applications. On
|> >|> my home machine, I have a notepad, the calendar loaded with my
|> >|> generic calendar file, a alarm clock and a few other things in
|> >|> my autostart group, all running as icons (some static, others
|> >|> displaying usefull info) on the bottom of my screen. Everything
|> >|> I need is not more than a single click away. 
|> 
|> >In which case they are always in memory, even if you aren't
|> >using them. Of course, all those thigns sound very small.
|> 
|> Well, the same thing could probably be said about the things
|> usually found on the Apple Menu.

But, whoever said so would be wrong. :) Apple menu items
are loaded when used, not before.

|> In addition, Windows memory management is quite dynamic - and
|> has always been -, so that a well written application, which
|> isn't loaded with a huge document does use only a very small
|> amount of memory while it is idle.

I know. This is nice. I wish Apple would do this, but...

|> This is because Windows
|> loads and discards code segments on demand, so that, at least
|> in principle, only the largest code segment of an application
|> has to fit into memory, in order to load and run it. Idle
|> application use only a small part of their code, so in case
|> of memory shortage, all other code segments - even those on
|> the call stack of that application - which aren't recently
|> used get discarded. I've read that the about 250K WRITE
|> application (which uses about 75 K if you start it without
|> a document) has code segements of 8Kbyte and less, so it
|> could be shrinked to about (I'm guessing here) 20 KByte.
|> What I've just described has been so since version 1 of
|> Windows. In addition to that, Windows 3 in Enhanced Mode
|> on 386 processors has virtual memory, so idle applications
|> consume space on the disk, not in memory, if memory is
|> tight. In this case, the data part - which does participate
|> in the discard/reload game only if the application cooperates,
|> while that feature is automatic for code - is swapped out
|> automatically, too.

The Macintosh can do most of this- it cant unload segments
that are in use, but it can do the rest. The VM stuff showed
up in System 7, and only works if a PMMU is present (ie 020 w/
external PMMU, 030 and 040 macs)

The reason this does not help is that each app gets a fixed-
size hunk of memory, just like a Windows local heap but MUCH bigger-
its size is user-set. I seen 'em up to 6 megs. And that heap
is the only place you can load resources (without a nasty
rigamarole); You can allocate memory outside of it with
special calls but even so you still have this big nasty partition
sitting around, chewing up memory. Yuck.

-- 
			- Dan Johnson
And God said "Jeeze, this is dull"... and it *WAS* dull. Genesis 0:0

These opinions have had all identifiying marks removed, and are untraceable.
You'll never know whose they are.
Newsgroups: comp.sys.mac.advocacy