Will Apple Adopt Windows?

[oldaccount1]

:) I wish I could use Windows on a Mac!!!!!

[djesteban]

What do you hate about it? The stability? The lack of compatibility with malware and viruses? I guess you could classify that as "software".

:laugh:

No... I hate it because when I needed to run Shake, final cut and maya at the same time... it freakin freezed on a god damn dual G5 okay!

Now I've completely switched to PC... (was using both before) I can run maya, fusion, premiere (<--not that it's the best editor, but i'm not into hardcore editing, more into compositing) + burn a DVD at the same time + run Framecycler at the same tim which I COULDN'T freakin do on a mac and it's suppose invulnerable stability. YES final cut was better than premiere... and yes I loved shake, but the workflow SUCKED HARD!

I would choose my dual Xeon anyday over my old dual G5. Not that the OSX was worst or better than Windows... not at all, actually I think that windows non-themed makes me want to regurgitate, but it was just not as stable as what i'm used to now with XP...

my 2 cents

:) I wish I could use Windows on a Mac!!!!!

go on Ebay... search for "apple G5 case -ipod" minus the quotes and buy a G5 case only... put your PC aparatus in it and BAM, you have your G5-pc hybrid :) with windows on it ;P

[Brandon Live Veteran]

What's your source for this? I doesn't jive with the with the calls the system makes (run a profile for yourself and take a look).

I could be mistaken, but I remember looking into this with a Mac guy several months ago and that was certainly how it appeared. I know for sure that's what they do in the Dock (with a couple of special exceptions, like Quicktime).

[Rastereffects]

Agreed. I don't think I've ever read a piece from Dvorak that I've completely or even partly agreed with.

As for whether or not Apple will ever adopt Windows for Apple systems. Simply put, no! I cannot imagine that they'd ever offer Windows.

Just my two cents...

He once had an article 2 or 3 years ago that I thought was completely BS. So now, everytime I see an link of an article authored by him, it's always ignored.

[the evn show]

I could be mistaken, but I remember looking into this with a Mac guy several months ago and that was certainly how it appeared.

RESPONSE COMING SOON. I'm checking profiles to be sure.

If they'd written OS X themselves, they wouldn't have the nightmare that is threading on OS X today.

Once again I ask you: What is hard about writing threaded code on OS X? The core libraries are almost entirely thread safe (both cocoa and carbon) and they provide great high-level abstractions for process and thread management. For those that are more familiar with pthreads, those are fully supported as well.

You keep making this claim that threading is difficult on OS X—sure, but it's difficult to write well threaded code on any platform—will you please back it up!

You wouldn't have the limitation of only one thread executing in the brain-dead FreeBSD kernel at a time.

10.4 did away with the split funnel and introduced fine grained kernel locking. Mac users aren't using Windows ME as a basis for comparison, maybe you could do them the courtesy of talking about an up-to-date version of OS X.

The BSD Sub system (user-land) is part of the OS X kernel but doesn't handle any of the typical kernel thing like interrupts, virtual memory management and protection, kernel threads & preemption, and inter-process communication. The BSD subsystem provides higher-level interfaces like filesystem drivers, TCP stack, user-permisisons and support for bsd-style (as opposed to mach) system calls, sockets, etc.

You can find all of this detailed in the OS X Kernel Programming Guide; page 50 and 94 are good places to start.

How can we expect to have any sort of reasonable discussion when you're constantly playing loose with terminology and avoiding direct questions or backing assertions?

[Brandon Live Veteran]

10.4 did away with the split funnel and introduced fine grained kernel locking. Mac users aren't using Windows ME as a basis for comparison, maybe you could do them the courtesy of talking about an up-to-date version of OS X.

Could you point to some documentation of this change? I don't see anything on Apple's site describing the change. And yes the "split funnel" and pairing of Cocoa threads to pThreads to Mach threads is the nightmare is just the nightmare I was talking about.

The BSD Sub system (user-land) is part of the OS X kernel but doesn't handle any of the typical kernel thing like interrupts, virtual memory management and protection, kernel threads & preemption, and inter-process communication. The BSD subsystem provides higher-level interfaces like filesystem drivers, TCP stack, user-permisisons and support for bsd-style (as opposed to mach) system calls, sockets, etc.

You can find all of this detailed in the OS X Kernel Programming Guide; page 50 and 94 are good places to start.

How can we expect to have any sort of reasonable discussion when you're constantly playing loose with terminology and avoiding direct questions or backing assertions?

Loose with what terminology? I'll admit, I'm more familiar with FreeBSD (and its terrible threading support) than I am with recent incarnations of OS X. But everything I've ever understood about the OS X architecture has indicated that it has both a lot of overhead and that it's inefficient for compute-intensive tasks. I am by no means claiming that any particular operating system is "better" than another. However, there's no doubt in my mind that the threading implementation in NT is significantly cleaner than that of OS X, FreeBSD, or Linux - mostly because it was an afterthought in all three.

[.Neo]

Actually, Expose does exactly the same thing (takes screenshots of the windows and moves them around), just like TopDesk. However, unlike the Dock minimization (where its a static screenshot), they update the screenshot.

So let's say I have 4 windows on my desktop:

-iTunes with Visual Effects (very CPU demanding)

-QuickTime playing a movie

-VLC playing a movie

-Safari's Download window with active progress bars

You're saying Mac OS X takes screenshots, resizes and updates them fast enough (maybe like 12+ times per second?) when Expos? is active to make everything appear run smoothly? Because everything keeps running, including the iTunes Visual Effects. If so it's amazing my 1.33 GHz eMac G4 can cope with that.

P.S.

All the windows, again including the iTunes Visual Effects, VLC playing a movie etc., continue to run while Mac OS X is making the sliding effects when repositioning my windows (even when holding Shift down, which delays most animations such as the Expos? sliding effect). Can TopDesk do that too?

Seems a bit unlikely that Mac OS X or any system for that matter can manage stuff like that just by taking screenshots. It also wouldn't correspond with the fact my CPU usage remains fairly low when Expos? is active and the temporarily increase in CPU usage to ?80% when taking a single screenshot.

Edited February 27, 2006 by Neowave

[John Veteran]

Interesting article. Apple could indeed make their own GUI shell for Windows and sell it. That would be legal, wouldn't it? It would still be Windows, but it could look like OSX... Profit for both companies, and yet only one platform.

[.Neo]

Interesting article. Apple could indeed make their own GUI shell for Windows and sell it. That would be legal, wouldn't it? It would still be Windows, but it could look like OSX... Profit for both companies, and yet only one platform.

To what end? None of the Windows applications have been coded to fit in with Aqua. One of the amazing things of Mac OS X is, IMO, that practically every application uses the same look, feel and capabilities of Aqua for a unified system GUI. Unless they modify the system in such a way that only specifically coded applications can run on it, but then you wouldn't have one platform anyway.

[the evn show]

Could you point to some documentation of this change?

The kernel programming guide has the details about the fine grained locking, the ars technica has some details (though I can't remember if they cite sources) and if you read the sources for kern/locks.h and some of apple's example code (tcplognke) give a little more detail. There's an ADC session on all of this from WWDC 2004 but I don't have DVDs handy to give the details.

However, there's no doubt in my mind that the threading implementation in NT is significantly cleaner than that of OS X, FreeBSD, or Linux - mostly because it was an afterthought in all three.

That may be the case, but you're still making pretty bold claims without anything to back them up - some of them are demonstrably incorrect. For example: expose being an application: it's not, it's a dock.app process which works by asking windowserver to perform gl transformations on views (the os x equivilant of low-level "windows" on windows) before quartz compositor takes over.

Even without firing up the developer tools this one is easy to demostrate:

1) Expos? is a function of dock.app: 1) kill dock.app, try running expose -> it won't work. End dock's process while expose is invoked and watch expose die - a seperate application would continue to run.

2) Expose takes screenshots and updates often. We'd expect to see memory useage increase substantially when expose is invoked, we'd also expect to see an increase in CPU load and memory usage while expose was invoked - we don't. Dock.app stays happy at < 3 mb of memory which isn't even enough to hold a single 32-bit ARGB image of of this screen.

3) We'd expect to see video playback suffer on formats that are through-put heavy (ie: uncompressed HD) as expose effectively doubles the drawing work: we don't.

Now if dock.app spawned a thread to handle key/mouse input and then just asked windowserver to perform some transformations before compositing then we'd expect to see:

1) a negligible increase in cpu load (equal to resizing all windows so that none overlap).

2) no noticable increase in memory usage because no additional graphics need to be created.

3) some opengl calls to transformation methods followed by calls to glxcomposite

4) no calls to things like cgbitmapcontextcreateimage and cgscapturewindowcontentstorect

5) a single call to _pthreadcreate (with a call to a carbon create-thread call beforehand because dock is a carbon app)

And strangely enough that's exactly what we see. Again, confirm it for yourself by running a malloc/system/memory bandwidth profiles.

increase in CPU usage to ?80% when taking a single screenshot.

Taking a screenshot spawns a new process (screencapture) which loads up a bunch of libraries, runs the captured image through png compression, and then does a little bit of disk IO. Most of the additional processor usage is IO, pressing capturing a screenshot to memory(cmd+ctrl+shift+3) has much smaller impact.

[Guol]

interesting theory i guess...but no way in hell this will ever happen...

[Argi]

Yeah, jumping straight to the point personally I cant see this happening any time in the near future. Apple's OS is both it's advantage and disadvantage. All they really need to do is provide a way to emulate windows apps on OSx86 (through WINE) and I think they'll provide a real oppourtunity.

[.Neo]

Taking a screenshot spawns a new process (screencapture) which loads up a bunch of libraries, runs the captured image through png compression, and then does a little bit of disk IO. Most of the additional processor usage is IO, pressing capturing a screenshot to memory(cmd+ctrl+shift+3) has much smaller impact.

cmd+shift+3 = ?90% CPU

ctrl+cmd+shift+3= ?75% CPU

I really need a new Mac huh;);)

Edited February 27, 2006 by Neowave

[saiz66]

I highly doubt it.