Re: What Window Manager/Desktop Environment do you use, and why?

On Thu, 12 Jun 2025 16:17:31 -0700, John Ames wrote:

On Thu, 12 Jun 2025 21:49:40 -0000 (UTC)
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
 

Classic MacOS *almost* nailed this, if only it hadn't been so quick
to dismiss the keyboard and the command line (and were designed from
the start for preemptive multitasking and memory protection...) 

 
It took extra-cost hardware to do that stuff back then. That’s why
the Unix boxes cost so much more.

 
MMUs cost extra at the time, yes, but that changed pretty quickly - by
the time the 68030 rolled out in 1987 it was built in to the CPU (and
the Mac line adopted the '030 just a year later, with the Mac IIx.)

Which, if you remember, was not exactly a cheap machine.

(I had an original-model Mac II on my desk in 1987. I thought it was the
most wonderful machine in the world.)

Unfortunately, as Andy Hertzfeld has written, there were a couple parts
of MacOS where they failed to "design ahead" for this; the transition
to 32-bit addressing was more complicated than it should've been as a
result, and I'm not sure if they ever did get memory protection going.

Not in classic MacOS, no.

But remember the transition to “32-bit clean” operation was pretty much
done by 1990, just 3 years after the original Mac II, and involved very
little change to MacOS APIs. Contrast this with the 16-to-32-bit
transition in the Microsoft-compatible x86 world, which took about a
decade *after* the first 80386-based machine started shipping. And
required an all new “Win32” API for writing programs. And which came in
subtly-incompatible variants for Windows NT versus old-style Windows.

The memory model, while forward-thinking in some respects, also imposed
weird limitations on application heap size that never did get cleared
up 'til the OSX transition finally obsoleted the whole thing.

Application heaps had to be a fixed size. To change the size, you had to
quit the app, set the new size (conveniently accessible in the Finder’s
“Get Info” dialog) and launch it again.

There was a “temporary memory” API available to get around this, but that
only allowed for relocatable memory blocks. I got around this by doing
allocation of nonrelocatable blocks in the system heap, which was
dynamically resizable and so avoided the need to keep reconfiguring the
application heap size in my app.

The downsides were 1) you had to remember to free up the memory before
quitting the app, otherwise it would stay allocated, and 2) the system
heap was not pageable on PowerPC machines. But I don’t think anybody
really wanted to put up with memory paging on their PowerPC Macs
anyway ...

As for pre-emptive multitasking, all you need for *that* is a timer
interrupt, which the Mac had from the very start.

One thing the Mac did have from the beginning was asynchronous, interrupt-
driven I/O. Oddly, the file-access part of this worked with floppies from
the beginning, but SCSI hard drives had to wait until SCSI Manager 4.3,
introduced in 1993, to get the full benefits of it.

The Classic MacOS GUI was purpose-built for the technology of its
day, but it grew increasingly complex to cope as the technology
evolved. Same is true of every GUI. They don’t scale, or evolve
gracefully. That’s why they keep needing to be redesigned.
 
And that’s why a platform where the GUI layer is fully modular and
replaceable, indeed optional (*cough* Linux, BSD *cough*), is the
best- placed to cope with ongoing technological evolution in
computing.

 
I can't fully agree with this. The GUI layer in an OS certainly ought
to be modular enough that the rest of the system doesn't depend on it,
or it becomes difficult to use in server environments (and tends to
limit scripting/automation.) Classic MacOS certainly fell short on that
front.
 
But the *nix approach of treating it as a secondary (tertiary?) priority
tends to lead to exactly what we saw in the *nix world, historically: a
handful of disparate efforts that mostly tend to make it to "eh, good
enough" and never quite achieve *niceness.*

Where is there a GUI that has achieved “niceness”? It’s just that some
companies have bigger publicity budgets than others, to tell everyone how
wonderful they are. Consider Microsoft’s “Aero Glass” effort in Vista,
which the *nix world could easily match--even outshine--at much lower
hardware cost, to the point where Microsoft had to abandon its approach
and try to convince everyone that translucency and other 3D effects
weren’t all that fashionable anyway, while we still have that available in
the *nix world.

...but the downside to that is there's fundamentally no such thing as a
*consistent* GUI experience in *nix-land ...

You either have choice or you don’t. There’s no third way about it.

Well, there is GNOME, which some people stick with and complain about, as
though other choices did not exist ...

It's better to have the ability to choose than to not have it; but it's
*nicer* to have and not *need* it.

That isn’t how freedom of choice works.

The *nix approach to the GUI, sadly, achieves the first aim but never
does fulfill the second.

Where is there, in real life, a situation that gives you both?