From: strobl@gmd.de (Wolfgang Strobl)
Subject: Re: Why Macs are better (and the others aren't)
Organization: GMD, Sankt Augustin, Germany
Date: Tue, 29 Sep 1992 15:27:16 GMT

In <+!kz16n@rpi.edu> johnsd2@jec306.its.rpi.edu (Daniel Norman Johnson) writes:

>In article <strobl.717768907@gmd.de>, strobl@gmd.de (Wolfgang Strobl) writes:
>|> In <ftjz3=k@rpi.edu> johnsd2@rs6219.ecs.rpi.edu (Daniel Norman Johnson) writes:
>|> 
>[deletia- Cut&Paste annoyingness]
>|> 
>|> >I know about that. That's implementation stuff; the user should
>|> >not see it. Its supposed to ACT like you were copying something
>|> >to a clipboard, then pasting it back somewhere. Unlike Excel,
>|> >where "copy" means "select until I do something else"...
>|> 
>|> Its NOT supposed to act like you were copying something to
>|> a clipboard, then pasting it somewhere. The Human Inferface Guidlines
>|> may say so, but why should Windows try to stick to that simple
>|> model? In my opinion, the users decision whether to paste something
>|> as text, picture, or as some object that has an internal construction that
>|> depends on an agreement of the two cooperating applications,  belongs to 
>|> the user, and it is better to give him the ability to delay
>|> that decision until he actually *uses* (i.e. pastes) the object.
>|> 
>|> Often, this decision is an implied consequence of into what
>|> application the paste goes. I.e. if I'm going to paste my
>|> just cut out formula into my text processor, it's probably a
>|> picture. But if I paste it into my spreadsheet, I'll probably
>|> want it as a macro or a function definition. 

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

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.

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

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

Wolfgang Strobl
#include <std.disclaimer.hpp>