StuChat 29. My take on OS10.

If the below comes across as a little "about time too!" it's because we've been begging Apple to do this for years! Also bear in mind that the only info available at the moment is a little "vague", so if all this turns out to be wrong, then just remember that hindsight is 20/20.

There is currently a lot of hoo-haa around the net about MacOSX. Unfortunately a lot of it by ill informed, but somewhat "influential" commentators (and no, I won't mention names).
MacOS 10 - what is it? How is it different? How does it affect you? The answer to all three questions are answered here.

What it is, is a natural progression of the MacOS "as is". Over the last three years Apple has been busy re-writing the MacOS, or more specifically, each manager has been ported to native PPC code. Irrespective of whatever else was happening, this was an obvious thing to do even if we take into account such failed promises as Copland.

Apple has always known that the MacOS must be buzzword compliant and to do that you have to do two things.

1. Run Apps in protected memory so when an App crashes, it can be purged without affecting anything else - specifically the OS and other apps.

2. Provide low level messaging services and resource sharing in a controlled manner to be able to pre-emptively multi-task applications.

This is typically achieved by leveraging an existing micro-kernal onto ones hardware. The microkernal provide 4 things.

1. Protected memory
2. Low level messaging services (semaphores, bemaphores, locks etc).
3. Low level hardware resource sharing services and control.
4. And as a result of the above three, pre-emptive multitasking.

Copland ran on a microkernal, Rhap runs on one and soon MacOS will too. No big deal.
Indeed, we expected the MacOS to be running on one this year, not next! Be programmers will be familiar with the environment.

On top of the the kernal sits the OS, and on top of the OS sits your app. Currently the MacOS sits directly on top of the hardware.

You need to change all the Mac API's to talk to the kernal rather than the hardware which is a fair amount of work, but not in the realms of "Herculean". You also need to change the API's so that they are pure (re-entrant) , or if not possible, provide a mechanism to lock out a call until it is clear (locks).

"pure" means this:
Consider the processor is right in the middle of an OpenResFile call. Now in a pre-emptive multitasking OS a switch can accur anywhere, at any time. So, a switch accurs and the next app runs. This app now calls OpenResFile. If OpenResFile isn't pure the system will probably crash because OpenResFile's current context is with the previous app.

If OpenResFile is not pure, one way round this problem is to use a "lock". On OpenResFile will set a lock that says it is currently running for App X. When the second App tries to run OpenResFile the OS will see that there is a lock on OpenResFile and will cease processing the second App. If the kernal is smart it will revert back to App 1 until OpenResFile "unlocks". If not, the OS will continue to switch Apps until eventually the OS will schedule App1 again and the lock on OpenResFile will clear when it finishes, allowing App2 to process it's call to OpenresFile. It's also possibnle for sections of code to be marked as "impure", this means that if they start running, then no task switching can occur until the section of impure code ends.

Thus "pure" means that a function can be interupted in mid-flow and restarted from another caller. When it finishes it will carry on processing (from where it left off) for the first caller. I assume that the 2000 calls Apple has removed for OS10 is a result of either non-use by developers or simply they were too difficult to move into the new architecture because of this pure/impure problem.

This is what MacOS 10 is - MacOS8 plus natural enhancements modified to talk to a kernal rather than directly to the hardware. Apple could have (and should have) done this years ago, even when 030's were all the rage.

So, how does it affect developers? Well not much really. There's a lot of nonsense being talked about new compilers being needed etc. Rubbish. All that is needed is information, and same header mods. Here's the major things you need to change to run under OS 10 as I can determine at this very moment in time, in order of priority.

1. 68K is out. PPC only. This is a bit sad, but strictly necessary. Goodbye MixedMode. Goodbye UPP's. UPP's are completely ignored by OS10 to maintain comaptibilty with OS8.

2. Do not used system memory any more - no more NewHandleSys, NewPtrSys or any other system heap calls. Change your app to use "local" memory. Shared memory has not been defined at this time (i.e. how one app can talk to another by placing data in a piece of memory another app accesses) - indeed this may not be necessary any more - it isn't desirable in this environment.

3. StandardFile is replaced with Navigation Services. NavServices return AEDesc lists, rather than FSSpecs. No big deal. The SDK is available. You can't use StandardFile in MacOS 10, it won't exist. If you use LXT or Universal_OS_calls.def we can do this for you at a basic compatibility level.

3a. Don't manually make FSspecs - let the system do it for you with FSMakeFSSpec. Working directories are no more.

4. Do not directly access low memory globals. . Use the accessors exported from the System libraries or provided in LXT or universal_os_calls.def for example.

5. Use accessors for system data structures - don't go poking window or menu manager data for example. These are promised from Apple.

6. Pretty minor - but don't try to manually control your heap or stack sizes. This will probably require some Gestalt work at run time to find out the architecture - if you get "Standard Mac OS" you may need to shrink your heap to expand the stack as you currently do. If you get "MacOS10", forget it - just skip your stack sizing and master pointer generation code.

7. Some API's are gone - QDGX and MIDI Manager are two examples off the top of my head.

If you are using LXT or even UniversalOSCalls.def things are easy - keep using those macros and you'll have few worries (as noted, we can probably do the Standard File to NavServices translation and SysMem stuff for you at a basic compatibility level. You'll obviously have to write your own code to use the advanced facilities of NavServices for example. We can certainly do the low mem accessors).

And that in a nutshell is it. All you have to do to run and multitask in a protected environment in OS10. And about time too!

Finally, just some common sense things.
1. Do not rush into this. Remember; three years ago it was Copland. Last year it was Rhapsody, now this it's MacOS 10. A lot of developers have been burned. However, MacOS 10 looks fairly realistic and sensible. It has done for a long time. Coder beware.

2. There has already been some debate about whether it will require a G3 processor. It is possible that OS10 will only run on a G3 machine. Not for any technical reasons - the PPC family is one of the most compatible processors ever devised. All adhere to the basic architecture.

No the reason may be simply the fact that Apple needs to make money. Now with all these buzzwords and speed (and believe me, OS 10 with no mode switches and pre-emptive MT will really fly!) OS 10 is going to be a helluva product for Apple. People will want this one. They will probably gladly upgrade to get it too.

Hopefully Apple will do the "right thing".