[MikeM32]

Okay I'm running a G3/266 Desktop here with 352 MB ram. I haven't used OSX or even Classic through OSX much yet, but I may be changing my habits soon, after observing the following......

I decided to see if I could Crash Classic the way I did in the Public Beta, by openning many Classic App's until the whole Classic environment went down like a sinking ship.

So I openned the following with thier OS 9.1 Ram Allocations:

QuarkXpress 4.11 - 50 MB
Photoshop 5.0.2 - 100 MB
Illustrator 9.0.2 - 75 MB -- (Under the Beta I crashed by this point)
InDesign 1.5.2 - 50 MB
Acrobat 4 (Full Version) - 12 MB
Acrobat Distiller 4 - 10 MB
Suitcase 3 - 1 MB
FileMaker Pro 5 - 6 MB
Tex Edit Plus (Not Text Edit another utility) - 1 MB
Toast 4.1.2 - 6 MB
Painter 5.0.3 - 250 MB <---(Worse memory/CPU Hog than Photoshop, but my favorite App.)

Grand Total Under OS 9.1 = 561 MB

All these App's remained running in the dock simultaneously.

Sorry if I'm stating the obvious to many here, but this is my first time seeing that I may actually be able to get stuff done in OSX through Classic until the real OSX app's start rolling out.

I guess Classic isn't so damned bad after all

Mike



[This message has been edited by MikeM32 (edited 04-11-2001).]

[Cipher13]

Regarding the title: Protected Memory for Classic Apps -

If Jobs wasn't such a devious bastard who wants nothing more than to make his pet NeXT succede under the guise of the MacOS then the new OS9 microkernel would have been released with 9.1 offering protected memory.
He just didn't want it to step on OSXs toes (I mean 9's already better in most ways - give it protected memory and theres a lot less reason to use OSX).
Heh.
Need I even mention Copland... *sigh*


------------------

[The Dude]

Part of the reason that Classic performs so well is that the TruBlueEnvironment gives Classic about a gig of VM. That, and Classic has it's memory all mapped out.

Makes me want a version of OS 9 that Cipher speaks of.

[macnetic]

Originally posted by Cipher13:
Regarding the title: Protected Memory for Classic Apps -

If Jobs wasn't such a devious bastard who wants nothing more than to make his pet NeXT succede under the guise of the MacOS then the new OS9 microkernel would have been released with 9.1 offering protected memory.
He just didn't want it to step on OSXs toes (I mean 9's already better in most ways - give it protected memory and theres a lot less reason to use OSX).
Heh.
Need I even mention Copland... *sigh*

"Buffer pages" (or whatever it's called) is _not_ protected memory. It merely makes crashes due to apps writing all over each others memory partitions less likely.

And Copland..? They scrapped it because they were essentially getting nowhere. And that was before Jobs came back...

[Cipher13]

The new microkernel had more than that - but every little bit helps. OS9 crashes seldom enough without that.

COPLAND WAS ASSASSINATED!
JEEZ. It transformed into Pink and disappeared!
I'm not gonna go through it all again... UGH.


------------------

[Millennium]

If Jobs wasn't such a devious bastard who wants nothing more than to make his pet NeXT succede under the guise of the MacOS then the new OS9 microkernel would have been released with 9.1 offering protected memory.

Sorry to shatter your illusions, Cipher, but such a kernel never existed. Furthermore, it could never have truly existed without breaking compatibility.

There is no one such thing as "protected memory," you see. It's actually a collection of techniques. Since OS8.6, Apple had been trying to implement one of those techniques, called "guard pages." The concept behind these is pretty simple: a buffer of empty RAM between each app, so that if an app overflows a little bit it won't corrupt another app.

However, this by itself is NOT memory protection. It does nothing to prevent an app from writing into memory that does not belong to it (the major cause of one app bringing down the whole system); it just makes this somewhat less likely. That's not the same.

[Smircle]

Originally posted by Cipher13:
The new microkernel had more than that - but every little bit helps. OS9 crashes seldom enough without that.

This kernel was promised over and over. First as the NuKernel of Copland, later as a new kernel to 9. It seems, however, that it was not possible to add memory protection to 9 because the OS-libraries were not up to the task. Besides, it is easy to imagine how often average applications would blow up.
Thats one reason why the transformation of the libs into Carbon took that long.

COPLAND WAS ASSASSINATED!
JEEZ. It transformed into Pink and disappeared!
I'm not gonna go through it all again...

Cipher, you are easily the most uninformed 4-star member here. Pink was the predecessor of Copland and later (named taligent) a joint IBM-Apple project in the early 90s. If anything, Copland killed pink.
http://www.mactech.com/articles/mact...eApples/<br />
http://www.ddj.com/articles/1997/9719/9719k/9719k.htm

Copland, btw, collapsed because of poor project management and lost focus (like every of Apples 5 or more attempts to "leapfrog" someone).

[Cipher13]

Originally posted by Millennium:
Sorry to shatter your illusions, Cipher, but such a kernel never existed. Furthermore, it could never have truly existed without breaking compatibility.

There is no one such thing as "protected memory," you see. It's actually a collection of techniques. Since OS8.6, Apple had been trying to implement one of those techniques, called "guard pages." The concept behind these is pretty simple: a buffer of empty RAM between each app, so that if an app overflows a little bit it won't corrupt another app.

However, this by itself is NOT memory protection. It does nothing to prevent an app from writing into memory that does not belong to it (the major cause of one app bringing down the whole system); it just makes this somewhat less likely. That's not the same.

Technicalities dude!
It isn't Protected Memory, but it is protected memory. Note the difference?
You know what I'm saying.

And there were attempts at full featured memory protection with kernel updates...


------------------

[Cipher13]

Originally posted by Smircle:
Cipher, you are easily the most uninformed 4-star member here. Pink was the predecessor of Copland and later (named taligent) a joint IBM-Apple project in the early 90s. If anything, Copland killed pink.
http://www.mactech.com/articles/mact...eApples/<br />
http://www.ddj.com/articles/1997/9719/9719k/9719k.htm

Copland, btw, collapsed because of poor project management and lost focus (like every of Apples 5 or more attempts to "leapfrog" someone).

Learn to count.

No - thats not how Copland died. Look into it, you'll see.

You sure Pink was a predecessor? I don't think so... Hm... Yeah, Taligent was after Pink... hm.
Ok, what you're saying makes sense but I'm not positiev which way it went... Pink&gt;Copland or Copland&gt;Pink...

I'll check up on that - not now, its late and I can't think.

But if your chronological sequencing abilities are anything like your simple arithmetic... I may well be right
J/K, just messin'.

I'll look into it. You're probably right on the order.

But, you are wrong about Copland - it was killed. I may explain later if I can be bothered to do it AGAIN...


------------------

[lgerbarg]

Originally posted by Cipher13:
Learn to count.

No - thats not how Copland died. Look into it, you'll see.

You sure Pink was a predecessor? I don't think so... Hm... Yeah, Taligent was after Pink... hm.
Ok, what you're saying makes sense but I'm not positiev which way it went... Pink&gt;Copland or Copland&gt;Pink...

I'll check up on that - not now, its late and I can't think.

But if your chronological sequencing abilities are anything like your simple arithmetic... I may well be right
J/K, just messin'.

I'll look into it. You're probably right on the order.

But, you are wrong about Copland - it was killed. I may explain later if I can be bothered to do it AGAIN...

Egads, how can you so consistently err on the facts and then criticize others.

Pink was an OS developed internally at Apple, and then later at Taligent when Apple and IBM formed Taligent aand Kelieda (sp?). Pink was supposed to run on top of the PowerOpen abstraction layer (based on Mach interestingly enough) eventually, though that was not an immediate goal. Copeland was transitional OS that oft delayed, and was meant to be followed up by Gershwin, which was supposed to break compatibility with all classic apps at that point, although it would retain compatibility with Copeland native apps.

What do you mean Copeland was killed. Copeland died on the vine. What Ellen Hancock and Gil Amelio did was a mercy killing. It would have never shipped. It had too many engineers on it, and they had no reasonable development metrics.

Guard pages are cool, but they can cause significant comaptibility problems in some cases, and are not a reliable solution. Apple is pretty darn concerned about compatibility for OS 9. Do you know that Mac OS 9.1 actually transitions into 68k emu and back at certain points because a few major applications were written with assumptions that some OS calls would return from 68k code, and so when it was redone for PPC it broke them, so they added a 68k shim back in. And yes, I have sat down with a person who wrote a very large chunk of the "nanokernel" and discussed with him what was added between 9.0 and 9.1.

Louis

------------------
Louis Gerbarg
Darwin Developer

[Millennium]

It isn't Protected Memory, but it is protected memory. Note the difference? You know what I'm saying.

I think I do, but you're still wrong. Putting a ten or so pages between programs isn't going to protect them from corruption any more then putting ten or so feet between me and some guy with a gun will protect me from bullets. Sure, he could miss, but there's nothing preventing him from hitting. So that's not protection at all.

And there were attempts at full featured memory protection with kernel updates...

Not in MacOS as we know it. Pink, Taligent, and Copland... yes. But none of these had any plans for backward-compatibility, because it would have been impossible. Even Carbon apps have to be rewritten slightly to make them run native in OSX; that was the closest they could come to true compatibility. Everything else has to run in one big memory space within OSX, which is itself protected as all OSX programs are, but within it no such protection exists.

[wadesworld]

Need I even mention Copland... *sigh*

Copland was killed by Gil Amelio, not Steve Jobs. Why? Because it was an unorganized mess and was never going to come together. (Remember Ellen Hancock's letter to developers before WWDC when developers were expecting Copland's release? The letter stated that Copland would not be coming, but would be released "at a later date." It never was. The letter was masking the fact that Copland only existed as a bunch of independant projects at Apple with no connection)

Wade

[mumble]

Originally posted by Cipher13:
Learn to count.

hmm, Opus, TaligentOS, Magiccap, Kaleida, Copland, Gershwin = 5 or more.

You sure Pink was a predecessor? I don't think so... Hm... Yeah, Taligent was after Pink... hm.

The Pink project began in 1988, Copland in '93. Plus protected memory was a projected feature for Gershwin - which if you didn't know never had any actual code.

Oh, and Copland didn't have a microkernel, it had a nanokernel, like (but not the same as) OS 9.

[Smircle]

Originally posted by Cipher13:

But if your chronological sequencing abilities are anything like your simple arithmetic... I may well be right

Bah, no need to poke fun at people who can't count ;-)

[lgerbarg]

Well, Copeland had this convoluted module, where it had a preemptive scheduler, and one of the schedule tasks was an old API application. Those apps where all cooperatively scheduled within that task. It is quite likely that copeland would have had protection between the new (Copeland/Gershwin) style apps. All in all it is really not worth speculating about unfinished, dead OSes would have done.

Copeland used a microkernel called NuKernel. I don't know what the old documentation said it was (nano or micro). I once asked a few Apple guys what exactly a "nanokernel" was, since it is not a well defined term. My assumption was that it was an abstraction layer that serialized access to the MMU (not quite the functions of a traditional microkernel, but necessary for using things like SMP and VM simultaneously), their response was that I had basicly the right idea, and the OS 9 nanokernel might have been like that for a week or two when it was first written, but it currently does everything a microkernel does (in fact more than a minimalist kernel like L4).

For reference: The Mac OS 9 nanokernel supports both preemptive multi-tasking and protected memory. Mac OS is started as a single task within that, and all of the applications share that one tasks memory, and are scheduled within that one tasks context cooperatively. Bringing these features up to the application level is not feasible, as it would break most applications. The memory protection is used to protect fragile hardware regions, such as NVRAM (don't know if NVRAM is actually protected, what is and is not varies from model to model), from random writes by marking it read only, and allowing writes through standard interfaces like Device Manager. The preemptive multiprocessing is an artifact of how the threadmanager API is implemented in the nanokernel.

Louis

------------------
Louis Gerbarg
Darwin Developer

[Smircle]

Originally posted by lgerbarg:

For reference: The Mac OS 9 nanokernel supports both preemptive multi-tasking and protected memory. Mac OS is started as a single task within that, and all of the applications share that one tasks memory, and are scheduled within that one tasks context cooperatively.

If I recall right, it was possible to write preemptive Apps that targeted the old API, but it was a real pain in the lower back, since you had to separate the preemtive part from all the UI and Memory management.
Sound App worked that way.

[lgerbarg]

Originally posted by Smircle:
If I recall right, it was possible to write preemptive Apps that targeted the old API, but it was a real pain in the lower back, since you had to separate the preemtive part from all the UI and Memory management.
Sound App worked that way.

Yup. ThreadManager was introduced to allow for scheduling AMP (Asymmetric Multi-processing) under Mac OS 7.something, when daystar released the Genesis MP. It had the side effect of allowing for preemptively scheduled threads so long as they did not make any reentrant toolbox calls (read that as did not make any toolbox unless you really knew what the heck you were doing).

Louis

------------------
Louis Gerbarg
Darwin Developer

[Millennium]

For reference: The Mac OS 9 nanokernel supports both preemptive multi-tasking and protected memory. Mac OS is started as a single task within that, and all of the applications share that one tasks memory, and are scheduled within that one tasks context cooperatively. Bringing these features up to the application level is not feasible, as it would break most applications. The memory protection is used to protect fragile hardware regions, such as NVRAM (don't know if NVRAM is actually protected, what is and is not varies from model to model), from random writes by marking it read only, and allowing writes through standard interfaces like Device Manager. The preemptive multiprocessing is an artifact of how the threadmanager API is implemented in the nanokernel.

Um... you sure about that? This is the first I've heard of anything even remotely like this, and from the looking into OS9 that I've done this doesn't sound very feasible.

By the way, what do you do with Darwin?

[lgerbarg]

Agg, UBB hates me.

I work mostly on kernel random number code.

Note: none of what I said above effects anything from the users perspective. Applications cannot be preemptively scheduled, only very specific kinds of threads. The applications are not protected from each other, huge chunks of the memory space is protected, but none of the traditional OS 9 space is. It allows Apple's engineers to speed up many things internally, and improved general OS reliability, but a crash in OS 9 space is functionally equivalent to OS 7 crash, since OS 9 itself is not protected, just the nanokernel and some pieces of hardware.

Mac OS 9 Applications (cooperatively scheduled toolbox threads, preemptive threadmanager threads)
---------------------
Mac OS 9 (Cooperatively scheduled threads, as well as premptively scheduled background threads on multiple processor threads, either from thread manager or for internal OS functions (asynchronous I/O completion, etc)
----------------------
nanokernel (Primitive threading and control constructs).


In fact this is how Classic works. OS X bypasses the nanokernel, replacing it with a shim called the pseudokernel that allows OS 9 to interface to Mach.

Louis

------------------
Louis Gerbarg
Darwin Developer

[This message has been edited by lgerbarg (edited 04-11-2001).]

[This message has been edited by lgerbarg (edited 04-11-2001).]

[Orbit]

Hey, this is great info... thanks for posting this stuff... really interesting! Does the normal Apple developer documentation include that much in-depth info on the nanokernel? ( I haven't looked myself )

[lgerbarg]

Originally posted by Orbit:
Hey, this is great info... thanks for posting this stuff... really interesting! Does the normal Apple developer documentation include that much in-depth info on the nanokernel? ( I haven't looked myself )

I do not think so. I had it explained to me mostly over lunch with a couple of Apple Engineers. There is really very little reason to document it, since it is not accessible, and likely to change (semanticly, if not structurally) without warning. I know the OS X documentation does discuss the pseudokernel a bit (kernel environment?). Some of it might have been mentioned in a forward that was sent to the Darwin Development list a couple of months ago about how OS 9 does processor cycling and other power saving.

Louis

------------------
Louis Gerbarg
Darwin Developer