If Windows came to PPC...

[giza]

[Poll #366877]

Source: Slashdot

Comments

Rat-flavoured ice cream.

[cjthomas.livejournal.com]

I'd have said, "Yuck. Why?", but many other people had beaten me to it by the time that article appeared. Running Windows on PPC is an utterly pointless exercise, for several reasons:

• Windows' architecture sucks enough that running on PPC won't give you much of a performance boost.
  
  No incentive to switch.
  
  
• Emulating x86 applications on PPC will suck dead bunnies through a straw, no matter what Mac-heads claim about their virtual-PC software. So your vast library of PC applications and games (the main reason to use Windows at all) will either not work, or will work buggily, or will work at a crawl, on Windows-PPC.
  
  Big applications hit for switching.
  
  
• AMD has an established 64-bit chip on the market. Intel is close behind. Windows will have full 64-bit support on x86, if not "shortly", then at least long before it'd be ported to PPC, even if Microsoft decided to do that again.
  
  No future incentive to switch.
  

So, I think the Paige Fox comment stands:

"Yuck. Why?"

Seriously tho...

[coyoteden.livejournal.com]

If MS ported windows to PPC, I think you'd see Windows kick some ass. MS already has WinXP on crufty x86 at a level of performance comparable to OSX/PPC.

The Windows kernel on PPC should SCREAM. Linux does, and let's face it, Linux/Windows/OSX benchmark on most real userland tasks neck and neck.

Not to mention AltiVec might be just the thing to make LOnghorn's "Aero" GUI engine as snappy as.. oh.. Quartz?

I'd rather my next generation machine and OS be native 64bit RISC rather than 64bit hacked onto 32 bit hacked onto... you get the picture.

But the real problem doing this isn't the OS... porting Windows to another architecture would be just as easy as porting Linux... if you had the source. MS does, so they could do it. They certainly do it with Pocket PC: PDAs have a wide variety of architectures.

The real problem is the hardware/drivers and applications. A lot of PC hardware has on-board firmware that expects a x86 processor. Drivers need to be ported, and applications need to be ported or run a compatibility layer at a performance cost. The one big advantage to Windows is the hardware and application base. Windows PPC would never get a foothold compared to what's already out there for OS X.

Do you really think Windows developers can be buggered to make fat binaries for two COMPLETELY different archetectures?

[foxcutter.livejournal.com]

I think it's doable, MS has an old HAL for the PPC (Windows NT was the first native OS for the platform). They just need to update the HAL, and maybe the driver model, and they will be set.

It would be cool if they did it, it would lower the price of the components, and lower the price of Macs.

On the other paw, it would mean apps that run on both, which would confuse users. In a perfect world, you would just flip a switch on the compiler, in RL it would take a few days (but still faster and easier then going to Win64) so only 30% of apps would be out for it.

The platform confusion between Intel and PPC would be enough of a reason (and a good one) for MS not to do it.

But if they wanted do abandon the x86, it would be a good step.

As for the question, if I owned a PPC platform (and I don't the only Mac I have is a Classic Mac so old it was just called a Mac ;) I might give it a try.

[mindslide.livejournal.com]

Voted PDP-11 option, because thats just awesome. :)

[furahi.livejournal.com]

So I'm the only one who remembers Windows NT4 running on PPC?
And MIPS and ALPHA

Actually we used Windows NT 3.51 on PPC at school when I was in high school, it was excentric ^^

Those PPC were IBM of course

[unciaa.livejournal.com]

I voted for all of the above, because I could. n.n

I don't ...

[doco.livejournal.com]

... do Windows, you insensitive clod! :)

[plonq.livejournal.com]

I chose "The goggles! They do nothing!" because they don't.. er, they do.. uh, nothing I mean.

I'd love to see Windows on a PPC.

[lurene.livejournal.com]

It'd be pretty hot - imagine trying to pull off windows auth token wrangling with PPC shellcode?? That'd be crazy tough...

Re: I don't ...

[giza.livejournal.com]

In SOVIET RUSSIA, Windows ports YOU!

[foxmagic.livejournal.com]

What *I* would like to see happen is for Windows to move to the Linux kernel, just like Mac OS X Aqua runs on top of BSD.

[lurene.livejournal.com]

That'd be kind of rough considering how message passing and signals differ...

Sanity check.

[cjthomas.livejournal.com]

Not to mention AltiVec might be just the thing to make LOnghorn's "Aero" GUI engine as snappy as.. oh.. Quartz?

GUI speed is mostly a function of how well you access your graphics card's hooks. And you may have missed it, but x86 has had SIMD floating-point capability for quite a while now too, so I'm skeptical of how much of an advantage AltiVec really gives you for any geometry transformations you still have to do on the primary CPU. Not to mention the fact that if you have to push hundreds of thousands of polygons to render a UI, something's very wrong. I'd be surprised if any GUI, including Quartz, pushed more than a few thousand per second. That makes the graphics card the bottleneck, and possibly the algorithms that tell you what should be rendered on the GUI in the first place (that's the only explanation I can think of for why Windows needs to access _disk_ when redrawing the GUI - it's either looking up the desktop directory for the nth time, or had swapped out backing-store information to disk).


I'd rather my next generation machine and OS be native 64bit RISC rather than 64bit hacked onto 32 bit hacked onto... you get the picture.

So how much time _do_ you spend context-switching? Between that and a bit of fiddling when allocating page table entries and so forth, that's the only part of the OS-proper that's architecture sensitive. Even peripherals are accessed through memory-mapped apertures, nowadays. Yes, IWADD (driver developer).

The x86 architecture has problems, and lots of cruft, but unless you're a compiler writer, you won't really notice it most of the time, and it impacts performance surprisingly little. You already noted this at the beginning of your post with your comment about XP's speed.


But the real problem doing this isn't the OS... porting Windows to another architecture would be just as easy as porting Linux... if you had the source. MS does, so they could do it. They certainly do it with Pocket PC: PDAs have a wide variety of architectures.

They have no incentive to, because nobody would bother switching (Windows users have no reason to move away from x86, and PPC users have no desire for Windows). If that changed, sure, they'd switch. Heck, I'm told they came up with an RS6000 (PPC workstation/server family) port of NT way back when.

FWIW, there's also a very large difference between WinCE and the WinNT line. While I've heard it rumoured that the WinCE architecture started off as a modularized port of NT, in practice they're very, very different families now. So porting of Windows (CE) to various portable device architectures doesn't help with porting XP (which is an NT derivative).


The real problem is the hardware/drivers and applications. A lot of PC hardware has on-board firmware that expects a x86 processor.

Um, no. No peripheral that I'm aware of ever touches the x86 processor. What they do is access system memory (on both x86 and Mac). The only important system difference here is storage format (endianness), and the peripherals that do this kind of access (sound, graphics, and network adapters) generally already have support for endianness switching so that they can work on the Mac (much cheaper to do that than to make two versions of a given graphics card). This doesn't always work _well_, but it's implemented, and making a more robust implementation isn't a problem.

Peripherals are mainly accessed in non-DMA mode by mapping control registers and memory spaces on the peripheral to apertures in physical memory that the processor can muck about with like any other form of memory. Again, endianness matters, but support for transparent endianness-swapping is already in place, and has been for a while (definitely for the graphics cards I was working with years ago, and almost certainly for sound, network, and other cards that need it as well).


In summary, most of the reasons you cite for porting to PPC turn out not to give benefits, and the peripheral stumbling block turns out not to really apply.

[cjthomas.livejournal.com]

What *I* would like to see happen is for Windows to move to the Linux kernel, just like Mac OS X Aqua runs on top of BSD

Why? The NT kernel actually handles the _OS_ components just fine. Windows instability comes from a deliberately broken permissions model that makes life easier for users and application developers at the expense of security, and because of brain-dead application design choices ("sure, I'll run the javascript in this email, or the VBScript in this Word document!"), and because of driver instabilities (which kill a system just as effectively under Linux - trust me, I've debugged driver code under Linux).

In theory, a microkernel system like BSD's could protect against buggy driver code, but the system would have to have been designed from the beginning with this feature in mind (my understanding is that BSD wasn't). The other problems aren't going away at all.

The HAL would have to stay the same unless you wanted to rewrite every driver in all creation, and the API would have to stay the same unless you wanted to rewrite every _application_ in all creation.

So I'm not sure what a kernel change would accomplish.

[lurene.livejournal.com]

I've got to wiegh in here as an infosec cat and say that the windows permission tokens system is excellent. It makes it significantly harder to maintain permissions after a program has been compromised.

For more information on how this works and why it's good, check out "The Shellcoders Handbook"

What is braindead is the lack of an auth mechanism for message passing, but then it's local root - who can't get that on any system?

[nius.livejournal.com]

Interesting discussions from everyone... I'll stick to toying with operating systems for fluency, but I like my voltages, gimme Layer 1 and 2 any day...

I voted for the cluster, since I'm sitting about 100 feet from an 1100 node X-serve G5 cluster :-D

It's so purty...

Benchmarks are in the works - it's been off-limits because the DOD has been using it for the past month or so, but now it's time to squeeze in one more round of Linpack before the November Top500 list... Oh, and the X-serves here are loaded with 2.3Ghz G5s, not the standard 2.0s available from the apple store. We've got enough cooling to push them farther than a normal commercial unit ^_^

[cjthomas.livejournal.com]

I've got to wiegh in here as an infosec cat and say that the windows permission tokens system is excellent. It makes it significantly harder to maintain permissions after a program has been compromised.

For more information on how this works and why it's good, check out "The Shellcoders Handbook"

What is braindead is the lack of an auth mechanism for message passing, but then it's local root - who can't get that on any system?

By "deliberately broken permissions", I was referring to the practice of installing systems with users running as administrator by default. No security system on earth will save you in that case. What's broken is the default permissions granted, not how the permissions are enforced.

There was also a long-standing problem with applications being able to access each others' memory space by design (something about it simplifying access to things like the clipboard, if memory serves), but I think that was a Win9x problem.