Panther and Windows?

[Snowy_River]

Originally posted by daveL
... 2) you will not be able to run Linux. ...

This is becoming a less and less significant threat, as so much is possible under OS X. I even had KDE running for a while under X11...

 

[Snowy_River]

Re: Re: x86 emulation by Apple?

Originally posted by chmorley
On another note, the censorship around here has gotten ridiculous.

Chris

What censorship are you referring to?

I guess the flip side of that is that if people don't want censorship, then they need to learn to control themselves. I've been around for a few threads that were just disgusting before they got censored (loaded with insults, etc.).

To date, I haven't noticed any extreme censorship, though.

 

[legion]

Originally posted by 123
What hardware? And what's the problem there?

Oh no , this is a bit of a bag of worms if I don't know your background, so just some quick info about big-endian vs little-endian (stolen from another website; scary thing is Microsoft actually has a really good explaination, but I fear it might be a bit heretical to post a link to a microsoft site )

"Bi-endian
There are two possible byte ordering conventions for representing scalar (that is, non-string) quantities in system memory. Big-endian byte ordering places the most significant byte of the scalar at the lowest memory address, whereas little-endian byte ordering places the least significant byte of the scalar at the lowest memory address. Virtually all CPUs support either one convention or the other, but a CPU that can be configured to handle both schemes is called bi-endian. The PowerPC is bi-endian in nature, which allows it to execute both big-endian 680x0 binaries and little-endian x86 binaries under emulation, without running afoul of byte-ordering conflicts.

Big-endian
A term specifying a byte-ordering convention for scalar data items. In the big-endian scheme, the most significant byte of a scalar is stored at the lowest memory address, the next most significant byte of the scalar is stored at the next higher address, and so on. The Motorola 680x0 line of CPUs is big-endian in nature. The PowerPC, while defaulting on power-up to big-endian mode, is in fact bi-endian and can operate either in big-endian or little-endian mode as required.

Little-endian
A term specifying a byte-ordering convention for scalar data items. In the little-endian scheme, the least significant byte of a scalar is stored at the lowest memory address, the next most significant byte of the scalar is stored at the next higher address, and so on. The Intel x86 line of CPUs is little-endian in nature."

[gross simplification]
So the deal is when things were moved to the PPC, Apple had a choice to use little-endian, however since it had history with the Moto 680x0 line, it chose to go with big-endian. In PCI buses and AGP, this effects how the information is transported between the system and the card. It's like when you want to describe a circle to the monitor through a graphics card, the system will send 0 1 2 3 4 5 6 to the AGP slot on a x86 system which will then be sent to the GPU for rendering. On a PPC (big-endian) system, the info to the AGP slot needs to be "flipped" so the system will send 6 5 4 3 2 1 0 to the AGP, but the GPU has that flipped to what it can understand before using the info.

What card makers do is they have ROM translate how to receive the info (or some other embedded system depending on how complicated the info.) This is why Apple requires different hardware from the same manufacturer of PC hardware (and why flashing ROMS sometimes works) Also, performance hits can occur if the hardware manufacturer is lazy and then you'll notice things like the exact same GPU on a x86 and PPC will run slower on the PPC. If Apple went to little-endian, then all the x86 hardware would become available to Macs (as long as, of course, they are physically compatible.) All that would really need to be done is a software driver solution for OS X (and since hardware manufacturing costs are a big reason why specialty cards are not developed for smaller niche platforms (Macs), software development would be a negligible cost to open up another market)

This may seem of little concern for consumer products, but it is one of the larger concerns for scientific markets and graphics/video/audio markets if they want to move to Macs
[/gross simplification]

Hope that makes sense. My DEC Alpha (a 64bit RISC processor) is also bi-endian like the PPC. If I start it in VAX/VMS it is running big-endian, if I start it in WinNT, it is running little-endian so that it can transparently use x86 code. The system board chipset manages what to send to add-on boards on the buses, so there is no concern about what system is running at the moment for the hardware.

 

[daveL]

Very informative post. Thanks!

 

[XnavxeMiyyep]

Just out of curiousity, if I were to get a PC running Linux, and I installed Wine on it, would I be able to play Windows games?

 

[legion]

WINE and Windows games on x86

Usually it works (I won't claim it works for all, but I've seen people using it without problems.)

I'd almost bet that WINE is really only developed, these days, so games from Windows will run on Linux.

I, myself, am not really a computer game player (I like consoles if I feel like playing a game), but I have never seen anyone using WINE to run business apps on linux (usually because there are already better, native linux solutions.)

 

[jaykk]

Disney uses WINE to run Photoshop

Penguin Moves to Disney

"Rather than wait, Disney, along with two other motion picture animation studios (which declined to be named for this article), decided to jointly fund the development of a Windows-to-Linux porting solution. The idea: develop technology using the Wine emulator to run Adobe Photoshop on Linux."

 

[nichrome]

Originally posted by Snowy_River
Perhaps my recollection is faulty, but that's not what I remember Red Box to be. As I recall, Rhapsody was originally slated to be a cross platform OS, and Red Box was the X86 equivalent of Blue Box on the PPC.

Partly true, but your recollection is still faulty. The x86 Red Box was the Windows APIs running natively as a Rhapsody process, not unlike Blue Box (Classic) for PPC. However, Red Box also existed in Rhapsody PPC, in emulator form.

Rhapsody Enterprise/Universal was to ship with Yellow Box, Blue Box and Red Box for PPC, and with Yellow and Red for x86. Rhapsody Standalone was supposed to be Yellow only on both platforms.

This non-functional Yellow-centric vision, brought in by the old NeXTies when Apple acquired NeXT, was of course later scrapped in favor of Yellow/Blue/Carbon.

To quote an old MacKiDo article:

On Intel, RedBox will be the Windows API's running natively on top of the other services. On PowerPC, the RedBox will be an Emulator that will allow Windows Application to work on Rhapsody. Apple may not directly offer RedBox on the MacOS since there are already a few good emulators available, or they may just make a licensing deal with Connectix (or Insignia) to bundle their emulators.

Side note, Apple was also rumored to be working on an OS/2 box to run alongside Yellow, Blue and Red. Of course, OS/2 never became a big hit, so that project, if there ever was one, was probably killed off pretty quickly.

 

[Snowy_River]

Originally posted by nichrome
However, Red Box also existed in Rhapsody PPC, in emulator form.

Thank you for the correction...