[prophei]

Hello all...

long ago, when rhapsody was going to be the savior of apple, i went to a store to look at the new macs. there were some developers hanging around looking at the machines, and i struck up a conversation with one. i asked him lots of questions about the coming new rhapsody os, and he told me a lot of weird things about what it could supposedly do. one of these things has been on my mind, and i was wondering if any of you developers has any insight to what he was talking about. it has been a while since that day, so i will try to explain the concept as well as i can...

basically, i was told that something called the redbox was going to be possible in rhapsody. this redbox was much like the original bluebox...except that instead of emulation old macos, it would emulate windows. the thing that made this more interesting than an integrated VPC was that it would supposedly be able to do this at near native speeds. he said that this could be accomplished in rhapsody because of the way that the os was setup... that you could do the translation of the code in a module directly communicating with a very deep part of the os (kernel?).
he said that currently, things like VPC had to go through much greater layers of the os to do what it does. it seemed like it would be another block on the now well known osx diagram showing how everything in the guts of the os was stacked (ie...carbon, cocoa, redbox(?), openGL, quicktime...etc)

any insight on any of this? please excuse my ignorance in explaining this

-prophei

[Vader's Robotic Stump]

I thought Red Box was only a rumor.
Apple never said anything official about it as far as I remember.

[Scrod]

First, the "red box" could not be another "layer" of Mac OS X. That wouldn't really make sense, because it's not an API.

And second, I'm pretty sure that the "red box" was only going to be available under the x86 version of Rhapsody. So in that respect it would be similar to the Classic environment under OS X; it's only a hardware abstraction layer. For the "red box" to function under the PPC version of rhapsody, it would HAVE to emulate code the way Virtual PC does.

[prophei]

"For the "red box" to function under the PPC version of rhapsody, it would HAVE to emulate code the way Virtual PC does."


if it HAS to connect the way VPC does, i wonder if VPC for osx has any added benefits over the previous mac os versions...

i know it is known for being fairly buggy right now, but is there a way to greatly increase the speed of emulation (due to the underpinnings of osx) in any way substantially better than before?

-prophei

[Scrod]

Originally posted by prophei:
<STRONG>if it HAS to connect the way VPC does, i wonder if VPC for osx has any added benefits over the previous mac os versions...

i know it is known for being fairly buggy right now, but is there a way to greatly increase the speed of emulation (due to the underpinnings of osx) in any way substantially better than before?
</STRONG>

I don't know. I'm not a Darwin developer. But I do know that most of VPC's speed comes from directly mapping x86 to PPC calls, so Connectix will probably have to write a kernel extension to do it as quickly as the OS 9 version did it. Right now the OS X version of VPC is a LOT slower than the one for OS 9.

[godzookie2k]

Now what are the possibilities of porting wine over to OSX (I think its called wine) Its a windows emulator of sorts that allows windows programs to run under linux, I've heard performance is pretty impressive. Does anyone have experience with this program, and what are the technical problems with a possible port?


(next step: beos emulator )


Nick

[ppmax]

&gt;&gt;Now what are the possibilities of porting wine over to OSX

no porting necessary. just visit these forums each day--theres enough whine already

couldnt resist...

WINE isn't really an emulator but some kind of implementation of Win32 APIs that run on X. Not really an emulation environment so there's no way to "port" the thing to OSX.

Same as VPC there's the endian problem

[pseudonomous cowturd]

Originally posted by godzookie2k:
<STRONG>Now what are the possibilities of porting wine over to OSX (I think its called wine) Its a windows emulator of sorts that allows windows programs to run under linux, I've heard performance is pretty impressive. Does anyone have experience with this program, and what are the technical problems with a possible port?

Nick</STRONG>

Wine stands for "wine is not an emulator."

Wine provides an environment within linux for x86 where windows programs can run on a (real, phyiscal) x86 processor and have access to windows libs, etc, so they think they're in a windows environment. (or something... i don't know if you have to boot windows within wine.)

Anyhow, it works like "classic" does in OS X -- running an environment for programs to live in, and allowing the programs to access the chip. This is VERY VERY different from VPC which maps calls to an x86 chip to calls to a PPC chip. That is emulation. To allow x86 binaries to run on a PPC chip you NEED an emulator. (Or dynamic code translation, a la transmeta and whoever else was doing that.) Wine cannot do this.

[asagoo]

What the guy originally told you makes sense, but I'm not sure whether it could realistically be implemented.

Originally, the Mach kernel used to emulate BSD Unix. With version 2 or so, it was reduced to a pure microkernel, containing only hardware-dependent code. All other functionality of BSD was moved to an external layer and could actually be replaced by other emulations, for example Mac, Linux or Windows. It can even run several emulations simultaneously. I'm guessing that this is how the Classic environment is implemented, but please correct me if I'm wrong.

So, this is what I think that Apple guy was on about. Any Darwin developers care to give us some insight into whether a Windows emulation alongside BSD and Classic is realistic?

Amar

[Scrod]

asagoo, you're very confused. Classic is not emulation. Classic is a hardware abstraction layer. The applications running in Classic are completely binary-compatible with the processor that Classic is running on. Emulating another processor requires emulating HARDWARE. This HAS to be done in order to allow applications that were COMPILED for this other processor to RUN. The Mach kernel, if it does any sort of "emulation" at all, purely does so in terms of SOFTWARE INTERACTION.
Do you understand that a difference exists between the x86 processor architecture and the PowerPC architecture? This difference is one of HARDWARE. IT IS PHYSICAL. The difference between BSD and Linux exists purely in SOFTWARE.

[asagoo]

Originally posted by Scrod:
<STRONG>asagoo, you're very confused. Classic is not emulation. Classic is a hardware abstraction layer. The applications running in Classic are completely binary-compatible with the processor that Classic is running on. Emulating another processor requires emulating HARDWARE. This HAS to be done in order to allow applications that were COMPILED for this other processor to RUN. The Mach kernel, if it does any sort of "emulation" at all, purely does so in terms of SOFTWARE INTERACTION.
Do you understand that a difference exists between the x86 processor architecture and the PowerPC architecture? This difference is one of HARDWARE. IT IS PHYSICAL. The difference between BSD and Linux exists purely in SOFTWARE.</STRONG>

You should read this article. My explanation is based on that and on the book "Operating System Concepts" by Galvin and Siberschatz.

Some quotes:
"Operating system emulators running as user processes (or tasks in the Mach parlance) used these services as the basis for higher-level functions such as file system and network support. In this way, Mach could masquerade as another operating system, even running several OS emulators simultaneously."

"The production version [of Mac OS X] may be based on Mach 3.0, with BSD 4.4 and MacOS emulators."

"Finally, more than one OS emulator can run simultaneously, allowing (for instance) Yellow Box and Blue Box applications to run side-by-side."

Mach itself does much of the hardware abstraction you mentioned. Together with an emulator, which handles higher level functions, it can replace a particular operating system on a particular hardware platform. The term "emulation" here refers to something at a very low level of the OS, and therefore doesn't have the performance issues of higher level emulations like VPC.
So, if Apple wrote a Windows emulator module to run on top of Mach, Windows applications should be able to use that, thinking they are on a real Windows system, yes?
There would be an important restriction, of course, as with Classic: No direct hardware access.

Amar


[edited to add note about hardware access]

[ 08-31-2001: Message edited by: asagoo ]

[murk]

Originally posted byVader's Robotic Stump:
I thought Red Box was only a rumor.Apple never said anything official about it as far as I remember.

I think I remember official discussions during Amelio's time identifying the ability to run Windows programs as an important goal of Rhapsody. Maybe it was all just part of the Mac OS Rumors fantasy, but I kind of think this was reported somewhere else. I also remember rumors that they got the Win32 APIs in the deal with Microsoft. I don't know if it technically possible to run Windows software under the Mac OS without Windows. If it is, however, it seems to me to be a catch 22. Part of the difficulty of getting PC users to switch is that they have to buy all new software. On the other hand, if Windows software runs well on a Mac, why would software developers continue with Mac versions?

[asagoo]

Originally posted by murk:
<STRONG>
If it is, however, it seems to me to be a catch 22. Part of the difficulty of getting PC users to switch is that they have to buy all new software. On the other hand, if Windows software runs well on a Mac, why would software developers continue with Mac versions?</STRONG>

That's a very interesting thought

However, it would be a similar situation as with Classic now:
1. Windows apps wouldn't use the Aqua interface and wouldn't have any of Mac OS X's features. They might not even be able to use the system wide clipboard.

2. Users will always favour native software over non-native, so developers have to adapt if they want to survive.

3. Cocoa still offes the most attractive way of developing, at least on the long run.

If Apple implemented a Red Box, it would rather be to lure Windows users into buying a Mac and then using that greater user base to get more developer support.

Amar

[moki]

Originally posted by asagoo:
<STRONG>3. Cocoa still offes the most attractive way of developing, at least on the long run.
</STRONG>

*If* you have no existing code base, have no interest in xplat code, and want to use/learn Objective C and another framework, yes, I agree.

(he says, as he goes back to working on his cocoa project )

[ 08-31-2001: Message edited by: moki ]

[asagoo]

Originally posted by moki:
<STRONG>
*If* you have no existing code base, have no interest in xplat code, and want to use/learn Objective C and another framework, yes, I agree.
</STRONG>

That's why I carefully put in those words, "on the long run"

Amar

[moki]

Originally posted by asagoo:
<STRONG>
That's why I carefully put in those words, "on the long run"
Amar</STRONG>

Well, it still isn't accurate unless in the long run, you don't care about the things I listed (many people/companies do). Cool as Cocoa is, I wonder if it won't be relegated mostly to OS-included apps, hobbyist apps, and RAD/custom apps.

[asagoo]

Originally posted by moki:
<STRONG>

Well, it still isn't accurate unless in the long run, you don't care about the things I listed (many people/companies do). Cool as Cocoa is, I wonder if it won't be relegated mostly to OS-included apps, hobbyist apps, and RAD/custom apps.</STRONG>

Hm, I can really imagine Cocoa overtaking Carbon in terms of developer support at some point in the future. Most people who come from a very object-oriented background and have learnt Java as a "first language", like many students currently do (including myself), will find Cocoa the obvious choice. Also, if you wanted to give a new developer a reason why they should come to the Mac, presenting them Cocoa would make a better impression than talking about Carbon, wouldn't it? And that's what Apple is doing. It's marketing.
Also, I disagree that Cocoa won't do to support all ranges of apps. After all, it was NeXTStep's sole API.

Amar

[Clive]

I think the red/yellow/blue box scheme runs something like:

Red: runs X86 stuff on X86 (may be that means a Windows runtime, a little like how Classic is with X - to run Win apps you'd obviously need to run/emulate Win APIs, who knows what the "windows"/UI would look like!?).

Yellow: basically what Cocoa is now, x86 and PPC compiled Yellow Boxes, run nuetral applications.

Blue: MacOS/Classic, what's in X now, only for PPC AFAIK

So, you get a Red/Yellow Box in the x86 Rhapsody, and a Yellow/Blue Box in the PPC version - I don't think there was ever much chance of getting Red/Yellow/Blue on x86 and PPC.

[Scrod]

Originally posted by asagoo:
<STRONG>Also, I disagree that Cocoa won't do to support all ranges of apps. After all, it was NeXTStep's sole API.</STRONG>

Yes, and we all know how successful and popular NeXT was.

[Angus_D]

The idea that was discussed over at MOSR some time ago was for a Carbon-like library for the Win32 API to speed up porting. It would make it possible to "tune up" your windows apps to run on Mac OS X much in the same way that Classic developers can with Carbon. However, I haven't heard anything else about it since then. It was still a pretty cool idea, IMHO. It would *NOT* retain binary compatibility with x86 for the obvious reason that it's not possible

[theolein]

Originally posted by moki:
<STRONG>

Well, it still isn't accurate unless in the long run, you don't care about the things I listed (many people/companies do). Cool as Cocoa is, I wonder if it won't be relegated mostly to OS-included apps, hobbyist apps, and RAD/custom apps.</STRONG>

I've been wondering this myself. I cannot imagine any company who has their applications running on multiple platforms using cocoa. The best Toolkit for porting at the moment is probably Qt from trolltech, but it's not cocoa. The people who write in cocoa will be pure apple developers, Shareware authors and Students. It is defintely a pity because ObjC is much easier than C++ and could be very well used for brilliant ditributed computing stuff. But no one is ever going to port the cocoa run time anywhere else and that bolts it to osx. I can imagine however, that if OSX takes off in a big way that there will be more people writing their little killer apps in it.

[Oneota]

Here's an interesting little nugget that I learned from an Apple emp. the other day (that may or may not be relevant to the discussion at hand):

Carbon started out as the QuickTime 4 APIs.


Which means that, with a little work, Carbon could be cross-platform. Which, since Carbon is being plugged as a clean-up job on the Mac OS Toolbox, means that Classic could, with a little work, be cross-platform (Star Trek, anyone?).

So if the Mac OS we know and love is so close to being x86 capable, it's certainly possible that Redbox, if it ever existed, was running on Mac hardware. Alas, we'll never know. Unless we find out. In which case, we'll know.

But that's another story altogether.

&lt;/rambling&gt;

[BuonRotto]

This discussion is starting to run into the old "Windows-to-Mac" or "Mac-to-Windows" debate. That is, would it be better for us (and Apple) if we could run Windows apps on our machines, or would it be better for us if developers could write cross-platform apps with Apple's tools? In the first case, we get tons of apps that day that we never had before. But the risk is that no one would bother writing apps for Macs specifically if the Windows ones run well enough, thus nullifying any substantial reason to use Macs or the Mac OS. On the other hand, we get native Mac OS apps with the long-term possibility that developers will use the API for its OO goodness and avoid porting stuff, but the risk is whether these developers will bother to use this API on Windows at all.

Personally, I think Cocoa for windows would have better long-term upside with far less risk. The worst case is that no one uses it for Windows and Apple pays the cost of keeping the API up-to-date on wintel hardware, but no loss of business for the Mac side. The alternative wouls seem to be far riskier in the long run, possibly threatening Apple's business fundamentally.