My apologies for the delay -- I had to put out a version control
fire. (Hate forthcoming.)
On Oct 3, 2008, at 5:32 AM, Peter da Silva wrote:
On 2008-10-03, at 02:47, Joshua Juran wrote:
I used to have what-to-do-on-close logic in the kernel, but now
the window will always close when the last file descriptor
referring to it is closed. So run a trivial program that does
"while ( true ) pause();" to keep it open.
I don't need to do that to keep a file in the file system from
being deleted, why should I have to do that when I just want to
redirect the output of "ls" to a new window?
Well, piping it into a program isn't any harder, is it?
Pipes and filters and redirection is a human tool, at least as much
as a scripting tool. The UNIX shell is a very humanistic API, it's
something created for people to use, directly, casually, if you
have to do things like writing a program to keep a file open, you
might as well be using JCL.
Okay, so you're modeling the window as a file. Does that mean you'd
close the window by calling unlink() on its pathname?
My concern here is how to close the window programmatically.
Although /dev/console currently has a window that only the user can
close, so I'd consider a distinction between 'user' and 'system'
windows.
Also, rather than opening the new-window device yourself (when in
the shell), it's advised to use a dedicated program that handles
setting up a new session. If the window isn't the controlling
terminal of its foreground process group's session, then clicking
the close box does nothing (i.e. the processes holding its file
descriptor don't receive a SIGHUP).
The whole "session", "process group" nonsense is irrelevant for this.
This is a little window, it's not a terminal, it's not a session,
it's "ls > /dev/win/anon/default".
A 'terminal' is an endpoint in a circuit and possibly a point of
contact between two circuits. In my model, a terminal is an
interface between the user and the system. This is as true of a text-
editing window as it is a shell window.
If you close it before the program's finished, the program gets a
SIGPIPE, not a SIGHUP.
This can work for output-only scenarios. I'll consider it.
Are people crazy for building little trains that can't carry
passengers or cargo, can't go anywhere, and don't make any money?
No, but they're crazy if they think balsawood is "more solid" than
steel.
Balsawood is more solid than straw (especially in man-form). I don't
argue that OS 9 is robust (and I accept your 'masochist' label), but
that the API is mostly well-designed, particularly in comparison to
Win32.
Mac OS 8 ran faster under Sheepshaver than native.
Your complaint says that one machine is faster than a different one,
No, this was on the same computer. Same disk, same memory, same
CPU, the only difference was booting from the BeOS partition or the
Mac OS partition. Because BeOS didn't have to run disk I/O and the
application in lockstep.
Oh, BeOS. That didn't occur to me, since I've never used it, but
that makes sense now. Too bad OS X didn't do nearly as good a job
performance-wise virtualizing OS 9.
This is "hates-software", not Ars Technica. I hate classic Mac OS
with a burning hate, for all the time I wasted trying to make it
work even vaguely reliably. For all the mollycoddling I had to do
to keep it from ripping its belly open and wandering around
bleating about the way its hooves were digging into its trailing
intestines.
Just think of my work as an entry in an imaginary retro-programming
contest.
Just running Finder and ANY program on my 7600, switching from a
Finder window to another window took longer to complete than
running the NeXT file manager and any program under NeXTStep.
I loved the responsiveness of NeXTstep, even on a 68030 (provided it
had a beefy 16 MB of RAM instead of a measly 8 MB).
I upgraded my 7600 from 9.22 to 10.1.5 and all of a sudden I could
play music while using the file system without having dropouts.
Yes. Really. Just using the file system from another program, any
other program, would bring the Great Multitasking Charade to a
screeching halt and the music ended.
I wonder if your audio player wasn't using interrupt-driven I/O. Or
maybe you were running File Sharing?
My iBook had only 320 MB of RAM, not enough to use OS X effectively
without excessive paging, which could very well cause dropped audio.
Moving windows was annoying, at first. No hardware acceleration.
Once I found out how to turn off the window shadows, it was even
fast doing plain old window manipulations.
I never developed an interest in 'how do I hack the system in ways
Apple didn't intend to disable so-called features that Apple added
that I didn't ask for and don't want and which don't have a proper
switch to shut off'. I always loved how booting into OS 9 made
everything fast again.
I got a G3 processor and upgraded to 10.2, and it was even better.
I dropped back to 9.22 on the same machine, and it STILL dropped
music in iTunes when I tried to do file transfers in the background.
Sounds like iTunes/SoundJam kinda sucked.
On my Amiga, in 1989, I frequently ran a video game in the
background, for background music, while I was working on the source
code for that game, compiling, editing, and chatting on a dialup
session with the other developer, without any worries, without even
the slightest glitch in the music, without any delays I could tell
in the compile process. I did benchmark that one time... running a
pretty intensive MIDI app added 3% to the total time from "make" to
another prompt... and the compiler didn't cause any delays in the
MIDI pipeline. That's on a 7.14 MHz 68000 with 2.5 MB of RAM.
Yet a 400 MHz G3 with 768MB of RAM got dropouts in iTunes just
copying files?
Well, emulating 68K interrupts doesn't help, I'm sure. I used
SoundApp, and I only got dropouts using ToolServer. I don't know
what was special about ToolServer/MPW Shell. It's not like the Get
Info window has a panel labeled "Here's all the crazy shit we did to
get this application to work (including various things we told *you*
not to do but did anyway because we're special)."
Please imagine an operating system that looks and feels like
classic Mac OS, but without the faults.
I can't. I literally can't. I wasted too much time trying in vain
to hide the faults from myself, to work around them, to avoid
triggering them without *completely* giving up every expectation I
had for what a computer should be able to do. I still have
occasional use for it, but I can't imagine using it for anything
more than the driver for my lovely old HP scanner.
I just can't resist the challenge. Maybe I have an easier time
dealing with OS 9's faults than OS X's or Linux's, where my
expectations are higher.
Start over from scratch. Throw away the horrible 1982-era OS-as-a-
GUI-library legacy. Yes, I could see doing that. I could see making
something that looked like Mac OS, but I sure wouldn't want to make
it feel like Mac OS, because so much of the feel of Mac OS, to me,
is bound up in "oh no, you can't do that, because I'm just a Mac".
No, the 'feel' just means that Home and End scroll the page rather
than move the insertion point, and clicking the close box once closes
the window, rather than, say, bringing up a menu. What you're
describing is more like the 'attitude', or maybe 'work ethic'. :-)
Eventually I'll make an exodus to Linux, but among other things I'm
waiting for a good text editor. *ducks*
Josh
