<strong><a href="http://www.eweek.com/article2/0,3959,767883,00.asp"; target="_blank">This articke @ eWeek</a> mentions that IBM will make 90 nm-porcessors for Xilinx H2'03. It states that IBM will make FPGA-chips, and not 970. But.. if they are making any chips in 90 nm the second half of next year, I'd be a happy Mac-user.
But.. the french article says exactly the same thing as the eWeek-article. No mention of 970 what so ever.</strong><hr></blockquote>
IBM is probably producing this chip first on the 0.09 process becouse they can make more money per chip off of it than they could. This will help pay for the plant and the equipment. The 970 may be good for Apple, but I dont get the idea that it was "made for Apple" IBM has internal plans for this chip, and thus is probably looking longer term in recouping development costs. Even in the shorter term, since it is on the 0.13 process to start, IBM can charge more for the chip...
Sorry if the post is a little incohearent, a long day at work and with the kid after...but I think you can get the general idea of my thoughts.
<strong>Actually, I was unclear, but the wrong statement above was:
Whereas, SMP performance is directly tied to Scheduler performance, and the scheduler is in the kernel. All of the uniprocessor gains in 2.5 linux kernels I gush about above are a result of (originally devised for SMP, for scalability) scheduler improvements, and on SMP machines, those same improvements greatly improve performance (obviously). More intelligent scheduling plus greatly reduced overhead.
Really cool stuff. Sorry for the off-topic posts. BTW, not suggesting 'linux rocks, osx sucks' type bs, just pointing out that scheduling, SMP, speed and kernels are all interrelated.
</strong><hr></blockquote>
The MacOS X scheduler is apparently quite good and has included SMP support from day one. Rumours of many-way SMP test systems have been floating around for a long time. The MacOS X kernel also contains a good deal more than a true micro kernel does, and what is in there is threaded somewhat and they are increasing the level of threading. SMP hardware can have multiple addresses spaces & processes active simultaneously which reduces the need for context switching that is the normal source of overhead in a highly modularized system.
Scheduling algorithms are a very interesting problem -- there are many trade-offs, and which ones are appropriate to a given OS depend on the expected usage of that OS. Nobody has yet found an ideal generalized scheduler so these things are going to get tweaked over time as the usage patterns and hardware configurations evolve.
[quote]Scheduling algorithms are a very interesting problem -- there are many trade-offs, and which ones are appropriate to a given OS depend on the expected usage of that OS. Nobody has yet found an ideal generalized scheduler so these things are going to get tweaked over time as the usage patterns and hardware configurations evolve.<hr></blockquote>
Agreed.
Side note: Not sure if this is boring the hell out o' y'all, but the latest 2.5 linux scheduler makes interesting trade offs wherein 'interactive' processes, eg GUI, or processes where you manually add input and expect output (window refreshes, app launches, etc) preempt everything and have as much CPU time as they need. Other processes wait until interactive processes have done their thing, and only then resume crunching away. So to the end-user, the system is always snappy, even under enormous load. And because computer spend 99.9% of their existence waiting for user input, 99.9% of the time the non-interactive stuff can do it's thing. I think this is brilliant! As a user who likes to web-surf while compiling software (on gentoo/ppc, you compile all your own software), I would be so stoked to have a fast, responsive system while web surfing, instead of 'fairly' sharing all processes equally. 'Nice' is nice, but doesn't cut it in this area.
The only downside is 2.5.50 doesn't compile on PPC yet so I have to use 2.4.21-preempt instead. I'm jonesin' here.
Yes, one item was that Apple had paid attention and made sure that audio system latency was minimized. Since then I'd heard that the Linux guys had done the same thing though.
. . . the latest 2.5 linux scheduler makes interesting trade offs wherein 'interactive' processes, eg GUI, or processes where you manually add input and expect output (window refreshes, app launches, etc) preempt everything and have as much CPU time as they need. Other processes wait until interactive processes have done their thing, and only then resume crunching away. So to the end-user, the system is always snappy, even under enormous load. . .
</strong><hr></blockquote>
I had been thinking about that sort of thing ever since I began using OS X on my 233 MHz Beige G3. It is nice to see that OS designers are beginning to do things to help the user interface. One idea I had was to put user interactive processes in a special small group that are checked frequently and given higher priority. However, it sounds like simply giving them a special priority to complete a task is all that it takes.
What troubles me about this technique is that it sounds like cooperative multitasking, which depends on the process. I wonder whether a problem in an application could lockup the entire OS, or whether applications could be written to take advantage of this feature, at the expense of other processes. Likely these concerns were all worked out.
<strong>I had been thinking about that sort of thing ever since I began using OS X on my 233 MHz Beige G3. It is nice to see that OS designers are beginning to do things to help the user interface. One idea I had was to put user interactive processes in a special small group that are checked frequently and given higher priority. However, it sounds like simply giving them a special priority to complete a task is all that it takes.
What troubles me about this technique is that it sounds like cooperative multitasking, which depends on the process. I wonder whether a problem in an application could lockup the entire OS, or whether applications could be written to take advantage of this feature, at the expense of other processes. Likely these concerns were all worked out.</strong><hr></blockquote>
The system is still pre-emptive, but interactive applications are given more time and they are given attention as soon as possible after a user event.
This has also been on my mind since I put DP4 on my Tangerine iBook (sniff...I miss it sometimes). Is there an explanation as to why Apple didn't implement a scheme like this? They could even do a check for hardware speed that scales the wait time for user input. That way a slower machines would run fast checking every millisecond let's say, and faster machines would still run at the same pace checking every millisecond rather than wasting extra cycles on waiting.
I mean, at the very least, this would shut up half the people that say XP or Win2K is "10,000 times faster" than OS X. As far as I can tell the faster (except for what can be attributed to GHZ) people feel isn't really there. It's response time as much as anything.
The system is still pre-emptive, but interactive applications are given more time and they are given attention as soon as possible after a user event.
</strong><hr></blockquote>
So the statement (not yours) that they, "preempt everything and have as much CPU time as they need," is not literally correct.
From what you mention, isn't "given more time" another way of saying they have a higher priority? If so, my idea to be "checked frequently and given higher priority" is not too different from what Linux 2.5 does. Since I thought of it over a year ago, it cannot be that unique of an idea. It seemed pretty obvious to me. I will upgrade from 10.1.5 just as soon as Apple does that.
[Edit] Just wanted to add another comment. If the scheduler does have a separate list of user interactive processes, than the only ones that should be on it are those running in the foreground. For example, when the user selects "hide" from the application menu, it should be taken off the "interactive" list, and scheduled normally.
Huh? MacOS X does give the active GUI process a higher priority, and it always has. Its new to Linux, not to MacOS X and Windows.
The feeling of sluggishness in MacOS X comes primarily from the display redraw times and from applications which are polling rather than waiting for events.
Quartz Extreme has gone a long way towards addressing the redraw times. Frankly, on my dual 1 GHz DDR PowerMac w/ ATI8500 I don't find the GUI to be slow at all... its faster than my Win2K Athlon machine.
Currently the biggest efficiency issue in the GUI, as far as I know, is that many applications written in Carbon are still polling for events. This means they ask the system for processing time continuously, and when they get it they check to see if any GUI events have arrived plus do whatever housekeeping they need to. This was the MacOS 1.x - 9.x way of doing things. The proper way to do this stuff in a preemptive multitasking OS is to ask the OS to tell you when events have arrived so that the OS can ignore your application until the user actually does something. This doesn't matter as much for the application in the foreground since that's the one the user is actively working with, but applications in the background can use up a noticable amount of time just figuring out that they don't have to do anything. As more applications are updated this will get better... although the set I tend to use all the time are Cocoa based and don't have this problem. There are other things that the applications can do to eliminate those annoying pauses and wait times, but many developers just don't bother. Some are Apple's fault, many aren't.
<strong>MacOS X does give the active GUI process a higher priority, and it always has.</strong><hr></blockquote>
Fair enough. It was just my impression that the system didn't work in the way you described. Apple should mess with the Carbon APIs then and return a null instead of polling for a response. Well, that's the ignorant simplified version anyway.
<strong>Fair enough. It was just my impression that the system didn't work in the way you described. Apple should mess with the Carbon APIs then and return a null instead of polling for a response. Well, that's the ignorant simplified version anyway.</strong><hr></blockquote>
They do as much as they can get away with, but if they changed the behaviour too significantly many apps won't work right. This is the downside of porting old APIs to a new OS -- you get some of the bad design decisions. Carbon does provide a better mechanism for capturing events without polling but for some reason Apple didn't force people to switch to that when Carbonizing... they probably whined too much that it would be hard and require work.
Carbon does provide a better mechanism for capturing events without polling but for some reason Apple didn't force people to switch to that when Carbonizing... they probably whined too much that it would be hard and require work.</strong><hr></blockquote>
This "pausing" and "waiting" subject seems to come up from time to time. In a past discussion I simply ended up contacting a developer/programer at Apple asking about the weird occurrence that still seems to be present in OS X. One of the most common examples is known as the "mouse-down freeze". This can be seen with various web browsers where if you click and hold the mouse button all the animations etc. on the page stop. Anyway, I decided to cut-paste a post from another forum that I contributed this information to at one point in time.
<Start>
On Carbon, Cocoa performance with respect to multitasking in OS X, OS9 and OS X Classic environment.
I asked a developer from Apple to give me the basic differences between Carbon apps and Cocoa apps and how it might affect particular UI performance along with general "snappiness" of "feel". Here is what he had to say when I inquired about multitasking under Carbon and under Cocoa:
Note: words within single [ ] are my emphasis on his comments.
[[[As for the UI stuff, part of the problem *is* Carbon, [which does cooperative multitasking] internally within a single app.
Another part of the problem is possibly the fact that programmers must program a Carbon app to be [responsive for both a preemptive multitasking OS (OS X) and one that doesn't support that scheme (OS 9) ], so you get something that works, but can't take advantage of any of the special features of OS X. ]]]
Aside: I suspect that as long as apps are coded to run under both OS X AND OS9, there will always be some performance lag due to how carbon works.
Anyway, the programmer continues with his explanation:
[[[Finally, it could be the inexperience with having a preemptive thread scheduler looking over your shoulder all the time and dropping your priority to zero if you hog the CPU.
Again, it depends on what the developers do. Some things in OS 9 are MP safe, like the File Manager. Of course the File Manager itself is single threaded, so it is not entirely clear how pounding on it with multiple other threads is going to get you anywhere, but I digress.
[Remember, It takes additional work to do preemptive multithreading in some cases. Not all developers think they have time for that.] Not all developers understand it enough either.
Two preemptively scheduled threads that share data can run into a whole series of new, exciting and highly irreproducible kinds of bugs that you will rarely or never see in cooperatively scheduled threads. It is a bit of a learning curve to learn how to avoid them. It also requires some pretty fundamental changes to the way an app. is written in many cases, so developers may choose to avoid these things until they find other good reasons to rewrite the app from the ground up. In these cases, they may decide not to use Carbon at all.
If the developer wants to invest the time into doing so, OS X offers superior advantages. However, developers make economic calculations about how much time such added complexity is going to take to add, how much it is going to cost in terms of dollars and other features and weigh that against how much it will benefit users.
[Another thing to keep in mind is that if you fashion additional cooperative threads in the same way that you made cooperative threads on 9, they will be cooperative threads on X too. ]
As on 9, you can make additional threads that are preemptively scheduled as well. However this was never very popular on 9 because of some rather large prohibitions about what you could do in them.
All the prohibitions are gone in X (mostly). However if your app is also going to run on 9 then you have to honor them anyway, even on X unless you special case your code.
The Carbon Event model uses a cooperatively scheduled series of callbacks for event handling (mouse click, keyboard entry, etc.). So while the app is busy responding to a drag on the scroll bar, it may not do an idle time action like check on the network to see if any more data has shown up.
Note that in X, cooperative threads are scheduled cooperatively with respect to other cooperative threads in the same app and preemptively against other apps. (Key point)
Thus, two different Carbon apps wont trip over each other, but a Carbon app could trip over itself.
There are no fundamental architectural flaws here that developers can't work around if they really want to. They just have to invest the time. Something like a web browser can be made incredibly efficient. However, a carbon app that has been ported from OS9 to OS X with cooperative threads can still act the same as it did in OS9. For instance (as an example), it still possible that clicking and holding a mouse will prevent the app from doing anything else until you release it, if the developers are lazy and do the simplest thing possible with respect to getting the application to function under OS X, this is what you will end up with.
You can do fancy workarounds that uses one method on one OS and another method on another OS, but this is of course not a lot better than just writing two separate apps, one for 9 and one for X.]]]
Anyway, I decided to post it because I figured that it would clear up a few things people were discussing.
Thanks -- I'd forgotten about the mouse-tracking silliness. I haven't written software for the old MacOS in quite some time and I'd forgotten about the typical approach used. Basically on a mouse-down an old app goes into a very small loop where all it does is repeatedly ask for the mouse's position and redraws the selection box... to the exclusion of anything else it might be doing. Software written for a pre-emptive OS would go to sleep until a "mouse has moved" event arrives, at which point they would update whatever needs updating and go back to sleep again. Apple has included the necessary support in Carbon to implement this properly, even in MacOS 9. It was only added when Carbon appeared on the scene, however, so it may take some developers a couple of releases to fix it... unless they are unable or unwilling, of course.
Comments
<strong><a href="http://www.eweek.com/article2/0,3959,767883,00.asp"; target="_blank">This articke @ eWeek</a> mentions that IBM will make 90 nm-porcessors for Xilinx H2'03. It states that IBM will make FPGA-chips, and not 970. But.. if they are making any chips in 90 nm the second half of next year, I'd be a happy Mac-user.
But.. the french article says exactly the same thing as the eWeek-article. No mention of 970 what so ever.</strong><hr></blockquote>
IBM is probably producing this chip first on the 0.09 process becouse they can make more money per chip off of it than they could. This will help pay for the plant and the equipment. The 970 may be good for Apple, but I dont get the idea that it was "made for Apple" IBM has internal plans for this chip, and thus is probably looking longer term in recouping development costs. Even in the shorter term, since it is on the 0.13 process to start, IBM can charge more for the chip...
Sorry if the post is a little incohearent, a long day at work and with the kid after...but I think you can get the general idea of my thoughts.
[ 12-18-2002: Message edited by: 1337_5L4Xx0R ]</p>
<strong>Actually, I was unclear, but the wrong statement above was:
Whereas, SMP performance is directly tied to Scheduler performance, and the scheduler is in the kernel. All of the uniprocessor gains in 2.5 linux kernels I gush about above are a result of (originally devised for SMP, for scalability) scheduler improvements, and on SMP machines, those same improvements greatly improve performance (obviously). More intelligent scheduling plus greatly reduced overhead.
Really cool stuff. Sorry for the off-topic posts. BTW, not suggesting 'linux rocks, osx sucks' type bs, just pointing out that scheduling, SMP, speed and kernels are all interrelated.
</strong><hr></blockquote>
The MacOS X scheduler is apparently quite good and has included SMP support from day one. Rumours of many-way SMP test systems have been floating around for a long time. The MacOS X kernel also contains a good deal more than a true micro kernel does, and what is in there is threaded somewhat and they are increasing the level of threading. SMP hardware can have multiple addresses spaces & processes active simultaneously which reduces the need for context switching that is the normal source of overhead in a highly modularized system.
Scheduling algorithms are a very interesting problem -- there are many trade-offs, and which ones are appropriate to a given OS depend on the expected usage of that OS. Nobody has yet found an ideal generalized scheduler so these things are going to get tweaked over time as the usage patterns and hardware configurations evolve.
Agreed.
Side note: Not sure if this is boring the hell out o' y'all, but the latest 2.5 linux scheduler makes interesting trade offs wherein 'interactive' processes, eg GUI, or processes where you manually add input and expect output (window refreshes, app launches, etc) preempt everything and have as much CPU time as they need. Other processes wait until interactive processes have done their thing, and only then resume crunching away. So to the end-user, the system is always snappy, even under enormous load. And because computer spend 99.9% of their existence waiting for user input, 99.9% of the time the non-interactive stuff can do it's thing. I think this is brilliant! As a user who likes to web-surf while compiling software (on gentoo/ppc, you compile all your own software), I would be so stoked to have a fast, responsive system while web surfing, instead of 'fairly' sharing all processes equally. 'Nice' is nice, but doesn't cut it in this area.
The only downside is 2.5.50 doesn't compile on PPC yet so I have to use 2.4.21-preempt instead. I'm jonesin' here.
[ 12-20-2002: Message edited by: 1337_5L4Xx0R ]</p>
<strong> I've heard there are a couple of parts of MacOS X which are actually faster than the competition. </strong><hr></blockquote>
Audio? Audio Units? :-)
<strong>Audio? Audio Units? :-)</strong><hr></blockquote>
Yes, one item was that Apple had paid attention and made sure that audio system latency was minimized. Since then I'd heard that the Linux guys had done the same thing though.
<strong>
. . . the latest 2.5 linux scheduler makes interesting trade offs wherein 'interactive' processes, eg GUI, or processes where you manually add input and expect output (window refreshes, app launches, etc) preempt everything and have as much CPU time as they need. Other processes wait until interactive processes have done their thing, and only then resume crunching away. So to the end-user, the system is always snappy, even under enormous load. . .
</strong><hr></blockquote>
I had been thinking about that sort of thing ever since I began using OS X on my 233 MHz Beige G3. It is nice to see that OS designers are beginning to do things to help the user interface. One idea I had was to put user interactive processes in a special small group that are checked frequently and given higher priority. However, it sounds like simply giving them a special priority to complete a task is all that it takes.
What troubles me about this technique is that it sounds like cooperative multitasking, which depends on the process. I wonder whether a problem in an application could lockup the entire OS, or whether applications could be written to take advantage of this feature, at the expense of other processes. Likely these concerns were all worked out.
<strong>I had been thinking about that sort of thing ever since I began using OS X on my 233 MHz Beige G3. It is nice to see that OS designers are beginning to do things to help the user interface. One idea I had was to put user interactive processes in a special small group that are checked frequently and given higher priority. However, it sounds like simply giving them a special priority to complete a task is all that it takes.
What troubles me about this technique is that it sounds like cooperative multitasking, which depends on the process. I wonder whether a problem in an application could lockup the entire OS, or whether applications could be written to take advantage of this feature, at the expense of other processes. Likely these concerns were all worked out.</strong><hr></blockquote>
The system is still pre-emptive, but interactive applications are given more time and they are given attention as soon as possible after a user event.
I mean, at the very least, this would shut up half the people that say XP or Win2K is "10,000 times faster" than OS X. As far as I can tell the faster (except for what can be attributed to GHZ) people feel isn't really there. It's response time as much as anything.
<strong>
The system is still pre-emptive, but interactive applications are given more time and they are given attention as soon as possible after a user event.
</strong><hr></blockquote>
So the statement (not yours) that they, "preempt everything and have as much CPU time as they need," is not literally correct.
From what you mention, isn't "given more time" another way of saying they have a higher priority? If so, my idea to be "checked frequently and given higher priority" is not too different from what Linux 2.5 does. Since I thought of it over a year ago, it cannot be that unique of an idea. It seemed pretty obvious to me. I will upgrade from 10.1.5 just as soon as Apple does that.
[Edit] Just wanted to add another comment. If the scheduler does have a separate list of user interactive processes, than the only ones that should be on it are those running in the foreground. For example, when the user selects "hide" from the application menu, it should be taken off the "interactive" list, and scheduled normally.
[ 12-20-2002: Message edited by: snoopy ]</p>
<strong>
I will upgrade from 10.1.5 just as soon as Apple does that.</strong><hr></blockquote>
you can update now - it's worth it :-)
The feeling of sluggishness in MacOS X comes primarily from the display redraw times and from applications which are polling rather than waiting for events.
Quartz Extreme has gone a long way towards addressing the redraw times. Frankly, on my dual 1 GHz DDR PowerMac w/ ATI8500 I don't find the GUI to be slow at all... its faster than my Win2K Athlon machine.
Currently the biggest efficiency issue in the GUI, as far as I know, is that many applications written in Carbon are still polling for events. This means they ask the system for processing time continuously, and when they get it they check to see if any GUI events have arrived plus do whatever housekeeping they need to. This was the MacOS 1.x - 9.x way of doing things. The proper way to do this stuff in a preemptive multitasking OS is to ask the OS to tell you when events have arrived so that the OS can ignore your application until the user actually does something. This doesn't matter as much for the application in the foreground since that's the one the user is actively working with, but applications in the background can use up a noticable amount of time just figuring out that they don't have to do anything. As more applications are updated this will get better... although the set I tend to use all the time are Cocoa based and don't have this problem. There are other things that the applications can do to eliminate those annoying pauses and wait times, but many developers just don't bother. Some are Apple's fault, many aren't.
<strong>MacOS X does give the active GUI process a higher priority, and it always has.</strong><hr></blockquote>
Fair enough. It was just my impression that the system didn't work in the way you described. Apple should mess with the Carbon APIs then and return a null instead of polling for a response. Well, that's the ignorant simplified version anyway.
<strong>Fair enough. It was just my impression that the system didn't work in the way you described. Apple should mess with the Carbon APIs then and return a null instead of polling for a response. Well, that's the ignorant simplified version anyway.</strong><hr></blockquote>
They do as much as they can get away with, but if they changed the behaviour too significantly many apps won't work right. This is the downside of porting old APIs to a new OS -- you get some of the bad design decisions. Carbon does provide a better mechanism for capturing events without polling but for some reason Apple didn't force people to switch to that when Carbonizing... they probably whined too much that it would be hard and require work.
<strong>
Carbon does provide a better mechanism for capturing events without polling but for some reason Apple didn't force people to switch to that when Carbonizing... they probably whined too much that it would be hard and require work.</strong><hr></blockquote>
Damn whiney Programmers...
<Start>
On Carbon, Cocoa performance with respect to multitasking in OS X, OS9 and OS X Classic environment.
I asked a developer from Apple to give me the basic differences between Carbon apps and Cocoa apps and how it might affect particular UI performance along with general "snappiness" of "feel". Here is what he had to say when I inquired about multitasking under Carbon and under Cocoa:
Note: words within single [ ] are my emphasis on his comments.
[[[As for the UI stuff, part of the problem *is* Carbon, [which does cooperative multitasking] internally within a single app.
Another part of the problem is possibly the fact that programmers must program a Carbon app to be [responsive for both a preemptive multitasking OS (OS X) and one that doesn't support that scheme (OS 9) ], so you get something that works, but can't take advantage of any of the special features of OS X. ]]]
Aside: I suspect that as long as apps are coded to run under both OS X AND OS9, there will always be some performance lag due to how carbon works.
Anyway, the programmer continues with his explanation:
[[[Finally, it could be the inexperience with having a preemptive thread scheduler looking over your shoulder all the time and dropping your priority to zero if you hog the CPU.
Again, it depends on what the developers do. Some things in OS 9 are MP safe, like the File Manager. Of course the File Manager itself is single threaded, so it is not entirely clear how pounding on it with multiple other threads is going to get you anywhere, but I digress.
[Remember, It takes additional work to do preemptive multithreading in some cases. Not all developers think they have time for that.] Not all developers understand it enough either.
Two preemptively scheduled threads that share data can run into a whole series of new, exciting and highly irreproducible kinds of bugs that you will rarely or never see in cooperatively scheduled threads. It is a bit of a learning curve to learn how to avoid them. It also requires some pretty fundamental changes to the way an app. is written in many cases, so developers may choose to avoid these things until they find other good reasons to rewrite the app from the ground up. In these cases, they may decide not to use Carbon at all.
If the developer wants to invest the time into doing so, OS X offers superior advantages. However, developers make economic calculations about how much time such added complexity is going to take to add, how much it is going to cost in terms of dollars and other features and weigh that against how much it will benefit users.
[Another thing to keep in mind is that if you fashion additional cooperative threads in the same way that you made cooperative threads on 9, they will be cooperative threads on X too. ]
As on 9, you can make additional threads that are preemptively scheduled as well. However this was never very popular on 9 because of some rather large prohibitions about what you could do in them.
All the prohibitions are gone in X (mostly). However if your app is also going to run on 9 then you have to honor them anyway, even on X unless you special case your code.
The Carbon Event model uses a cooperatively scheduled series of callbacks for event handling (mouse click, keyboard entry, etc.). So while the app is busy responding to a drag on the scroll bar, it may not do an idle time action like check on the network to see if any more data has shown up.
Note that in X, cooperative threads are scheduled cooperatively with respect to other cooperative threads in the same app and preemptively against other apps. (Key point)
Thus, two different Carbon apps wont trip over each other, but a Carbon app could trip over itself.
There are no fundamental architectural flaws here that developers can't work around if they really want to. They just have to invest the time. Something like a web browser can be made incredibly efficient. However, a carbon app that has been ported from OS9 to OS X with cooperative threads can still act the same as it did in OS9. For instance (as an example), it still possible that clicking and holding a mouse will prevent the app from doing anything else until you release it, if the developers are lazy and do the simplest thing possible with respect to getting the application to function under OS X, this is what you will end up with.
You can do fancy workarounds that uses one method on one OS and another method on another OS, but this is of course not a lot better than just writing two separate apps, one for 9 and one for X.]]]
Anyway, I decided to post it because I figured that it would clear up a few things people were discussing.
<end>
--
Ed M.