[goMac]

http://www.macrumors.com/pages/2005/...07183900.shtml

"A first time poster to MacGeneration (French) forums posted the contents of an email, which was originally sent to another website.

The writer claims that Apple is reviving "Yellow Box for Windows" -- a development environment which promised Mac OS X developers the ability to develop and then deploy of both Mac OS X and Windows environments. The original plans for Yellow Box were promised during early developer sessions by Apple, but later killed.

The letter claims that the project has been relaunched internally under the name "Dharma". Resultant applications will be true "Universal Binaries", allowing developers to release their applications under the Windows environment also.

The reasoning behind this is the same as it was before -- lure developers (Mac and Windows alike) to the Mac OS X platform to stimulate more Mac applications and compatibility. Safari is reportedly already running on Windows XP and is expected to be released as a free application for Windows.

Obviously, anonymous forum posts are amongst the least reliable sources of information, but is linked here for interest sake."

Obviously it's an anonymous rumor, but Dharma would be an appropriate name for such a project. Also, with the move to Intel, this would make sense. Windows users could run Mac applications without even having to recompile.

[The Godfather]

Cool. I wish I could make stuff up just like that.

[goMac]

Originally Posted by The Godfather

Cool. I wish I could make stuff up just like that.

Meh. To me it makes sense. Codename fits well. Concept fits well. Technologically it works. And Apple already has done it once before. It's also another good reason why Apple might have moved to Intel.

And even if it's not true, it makes for good discussion.

[The Godfather]

Originally Posted by goMac

Meh. To me it makes sense. Codename fits well. Concept fits well. Technologically it works. And Apple already has done it once before. It's also another good reason why Apple might have moved to Intel.

And even if it's not true, it makes for good discussion.

Technologically it works, but not done by Apple. Examples: GTK and Real Basic, but they have to be compiled for Windows. Or maybe you are talking about making a Wine equivalent that allows x86-Cocoa to run in Windows?

On the other hand:
Reasons to do it do not indicate evidence, not even desire to do it.

[ambush]

A lot of the current Yellow Box (AKA Cocoa) is based on OSX only ****...
Plus they would have to redo AppKit to fit windows guidelines, and change OSX only classes, etc.


n: I think it was invented. It doesnt make sense at all.

[KeriVit]

I like pink boxes, not yellow.

Wait, that didn't sound right...

oh well, take the thread where u will...

[Brass]

Originally Posted by The Godfather

Technologically it works, but not done by Apple. Examples: GTK and Real Basic, but they have to be compiled for Windows. Or maybe you are talking about making a Wine equivalent that allows x86-Cocoa to run in Windows?

On the other hand:
Reasons to do it do not indicate evidence, not even desire to do it.

Are you familiar with the Yellow Box that Apple advertised for Mac OS X (before Mac OS X was first released)? It was promoted by Apple as being the Cocoa API for windows. So in a sense, yes, it would be the WINE equivalent. It's the set of libraries required for Cocoa/Windows applications to run.

Apple killed it before Mac OS X was ever released (or even named "Mac OS X").

Originally Posted by ambush

A lot of the current Yellow Box (AKA Cocoa) is based on OSX only ****...
Plus they would have to redo AppKit to fit windows guidelines, and change OSX only classes, etc.


n: I think it was invented. It doesnt make sense at all.

It may be invented but Apple was definitely working on it before Mac OS X was originally released. They advertised it as being one of the great advantages of their next generation OS. Unfortunately, they renegged and killed it.

Now that Mac OS X is to run on Intel, it may be easier for them to revive it.

Whether they actually do or not remains to be seen. But it is certainly possible, and could be a very big advantage for Apple if they are able to pull it off.

Like you say, getting the UI to work on both platforms' guidelines is a challenge, but it's not insurmountable. Even if it requires developers to provide a tweaked version of the NIB (UI) files for the other platform to be workable, that would not be unacceptable.

[ambush]

old enums in current Cocoa.framework

Code:
typedef enum {
   NSNoInterfaceStyle = 0,
   NSNextStepInterfaceStyle = 1,
   NSWindows95InterfaceStyle = 2,
   NSMacintoshInterfaceStyle = 3
} NSInterfaceStyle;

But really, I don't think so. What would the advantage be?

What if an app uses CoreImage? CoreVideo? AddressBook? all external frameworks commonly used by cocoa apps and that are not available on Windows

What about WebKit? will they port it too?

Sorry, but that new Yellow Box thing is Bullcrap.

[TETENAL]

Originally Posted by goMac

this would make sense. Windows users could run Mac applications without even having to recompile.

Then what is their incentive to buy a Mac?

[goMac]

Originally Posted by TETENAL

Then what is their incentive to buy a Mac?

Because you couldn't run any application with Carbon code in Yellow Box.... such as iLife...

[goMac]

Originally Posted by ambush

But really, I don't think so. What would the advantage be?

What if an app uses CoreImage? CoreVideo? AddressBook? all external frameworks commonly used by cocoa apps and that are not available on Windows

What about WebKit? will they port it too?

You would just include the frameworks with the application. WebCore has already been ported to Windows. There is already an Objective C compiler for Windows in GCC.

The idea would be Apple could combat .Net and Win32. Developers would be attracted to Cocoa on Windows by it's ease of use. As a nice side effect, anything they program works on an Intel Mac. As was the plan in 1998.

[ambush]

deepee (effing lag)

[TETENAL]

Originally Posted by goMac

Because you couldn't run any application with Carbon code in Yellow Box.... such as iLife...

With the exception of iTunes (which already runs on Windows) all the iLife applications are Cocoa.

Originally Posted by goMac

You would just include the frameworks with the application.

"You"? Only Apple could do that since only Apple owns them.

[ambush]

deepee

[TETENAL]

Originally Posted by goMac

Because you couldn't run any application with Carbon code in Yellow Box.... such as iLife...

With the exception of iTunes (which already runs on Windows) all the iLife applications are Cocoa.

Originally Posted by goMac

You would just include the frameworks with the application.

"You"? Only Apple could do that since only Apple owns them.

[- - e r i k - -]

WebCore runs on Windows? In what app?

[ambush]

And there's already a big transition going on (OSX->Intel)
(Cocoa->Windows) could cause a lot more confusion than needed.

Please, go back to coding vaporware.

[ambush]

And there's already a big transition going on (OSX->Intel)
(Cocoa->Windows) could cause a lot more confusion than needed.

Please, go back to coding vaporware.

[goMac]

Originally Posted by TETENAL

With the exception of iTunes (which already runs on Windows) all the iLife applications are Cocoa.

I would bet very good money they still contain Carbon code.

I think the point would be getting Windows programmers to create Macintosh apps, not getting Mac programs to port their apps to Windows.

[goMac]

Originally Posted by ambush

And there's already a big transition going on (OSX->Intel)
(Cocoa->Windows) could cause a lot more confusion than needed.

Please, go back to coding vaporware.

Huh? It wouldn't be a transition for Macintosh developers. The point would be to convert Windows developers to Cocoa, and get them coding applications that would work on Intel Macs.

[CharlesS]

Originally Posted by The Godfather

Technologically it works, but not done by Apple. Examples: GTK and Real Basic, but they have to be compiled for Windows. Or maybe you are talking about making a Wine equivalent that allows x86-Cocoa to run in Windows?

I'm fairly sure that the app would probably have to be compiled for Windows. Not that this is a great big deal (see: universal binary).

Originally Posted by ambush

A lot of the current Yellow Box (AKA Cocoa) is based on OSX only ****...
Plus they would have to redo AppKit to fit windows guidelines, and change OSX only classes, etc.

Not really - as I understand, they had this working back in the NeXT days. The app would have two different nib files, one that would contain the Windows-compilant interface and one that would contain the Mac-compliant interface.

Originally Posted by ambush

But really, I don't think so. What would the advantage be?

More people using Cocoa, more software getting ported from Windows to Mac, and less suckage in the apps that are ported from Windows to Mac.

Think about it. If Objective-C/Cocoa became established as a development environment on Windows, and you were a Windows developer with a Cocoa/Win app, why would you not port to OS X, considering how much work would already be done for you?

What if an app uses CoreImage? CoreVideo? AddressBook? all external frameworks commonly used by cocoa apps and that are not available on Windows

Same thing if an app used the Registry, DirectX, or ActiveX on Windows. You'd rewrite the parts that needed to be rewritten, and not have to worry about the rest, as opposed to having to rewrite the whole thing.

Besides, there's no reason Apple can't port CoreImage, CoreVideo, etc. if they so desire. Heck, maybe they've been living a "secret double life" also, like OS X and Yellow Box have been.

Originally Posted by ambush

Apple already "combats .net and Win32" with OSX, you idiot.

Now that was uncalled for.

Originally Posted by ambush

Sorry, but I see this as impossible. Cocoa is too deep inside with OSX with all the new frameworks that have been added since 1998.

It's clearly not impossible. Whether or not it is probable is another issue which I'm not going to get into since my crystal ball has a pretty bad track record lately. But it does make sense, and I would really welcome this if they decided to do it.

[goMac]

What he said.

The reality is we're moving into a time when we're going to have to deal with WINE. This means two things:

a) People just run Windows applications instead of using Mac ports.

-or-

b) We risk Win32 becoming the major programming API on the Mac, and have to deal with straight Win32 ports.

Cocoa on Windows would combat this, by turning the tables on Win32.

[Big Mac]

I agree with you partially, goMac, except we're not dealing with WINE as much as we're dealing with Windows dual-boot. Unless WINE takes a huge developmental leap forward, it will remain more or less a geeky diversion. It will be far, far easier to simply boot into Windows. If I were to own a Mactel at some point I would be strongly tempted to boot into Windows to use programs not available for OS X - and I'm speaking as a guy who pledges allegiance to the Mac. If that's a convenient option for users, it's going to be the nightmare scenario I've been predicting. Unfortunately, Cocoa for Windows, if it truly exists, won't do much to offset that threat. For all of its advantages, Cocoa has not taken the Mac developer community by storm. While Cocoa for Windows would be A Good Thing, it's not a panacea.

[The Godfather]

When I get an Intel Powerbook, the first thing I am going to install is Windows XP. Really.

[Kevin]

Originally Posted by ambush

WebKit!=WebCore.

What I mean is, if they're going to port Cocoa to Windows, they will have to port other frameworks, and that's a lot of work.

Sorry, but this is like the worst fake rumor ever. And the guy's just a Lost fan trying to get a laugh after his fix.

Apple already "combats .net and Win32" with OSX, you idiot.

Sorry, but I see this as impossible. Cocoa is too deep inside with OSX with all the new frameworks that have been added since 1998.

Sorry mate.

You were doing so well till this.

[JoshuaZ]

Originally Posted by The Godfather

When I get an Intel Powerbook, the first thing I am going to install is Windows XP. Really.

I want to see a pic of your first blue screen on your PBook. I mean, that would be like super funny.

[vmarks]

I ran YellowBox for Windows NT back in the old days.

I ran a few applications on it, mail, rbrowser, stone studio.

It worked well. Would we see this again? Uncertain. It absolutely makes sense for Apple in order to make applications available for Windows (Quicktime, iTunes, future app?)

And iTunes 6 is becoming Cocoa. The rest of the iLife series is Cocoa. Believe it.

Does it make sense for Apple to release it for other developers' use? Uncertain. The notion some of you posit is, what if Cocoa and objC became dominant?

The alternative position is, what happens to Macintosh if all the software goodness doesn't require a Mac? (Let us not dispute that Macintosh software tends to be of a higher quality in function, stability, and usability than much of Windows software.)

[rickey939]

Originally Posted by The Godfather

Cool. I wish I could make stuff up just like that.

[starman]

I don't see the point. You can run OS X apps on Windows....why? I'd bet any amount of money that you'd have a terrible time with file formats, copy/paste, and a slew of other issues.

Maybe I'll dig up my Yellow Box stuff and find a 486 to run it on . I have it around here somewhere.

Also, has anyone seen the number of frameworks that are involved with developing for OS X? God Almighty, that's a LOT of work! On top of the recompile for x86, you have to make the frameworks work with Windows. Bah, no. This is BS.

MIke

[analogika]

The one point that makes sense is to get hitherto Windows-ONLY developers to switch to Objective-C/Cocoa and thus support the growing Mac market with little to no additional effort.

I couldn't see that happening, though, since what developer in his right mind would jump onto an Apple-provided API for Windows, at the risk of Apple pulling out in five years' time and no longer offering Yellow Box for Windows?

It would instantly make all apps Mac-only, and if done at critical mass, would be the utter Microsoft-killer tactic, but I doubt many developers would fall for it.

[Millennium]

Originally Posted by The Godfather

Technologically it works, but not done by Apple. Examples: GTK and Real Basic, but they have to be compiled for Windows. Or maybe you are talking about making a Wine equivalent that allows x86-Cocoa to run in Windows?

Neither, actually. One of the interesting things about Apple's package format is that you can actually have multiple binary files inside. This is how OSX's "Universal Binaries" are said to work: there are actually two copies of the app in the package, one for PPC and one for Intel. Add in Yellow Box for Windows, and you need three copies, but that's easy enough to handle. So you do have to recompile the app, but you could distribute the recompiled app as part of a universal binary. Mind you, I still don't think those things are going to catch on with many developers.

As for how they'd actually run on Windows, it would require an installation of some runtime libraries, just as the old OPENSTEP for Windows did. But once that was installed, there would be no problem.

[TETENAL]

Originally Posted by vmarks

And iTunes 6 is becoming Cocoa.

iTunes 6 is certainly staying Carbon.

[ambush]

Originally Posted by CharlesS

I'm fairly sure that the app would probably have to be compiled for Windows. Not that this is a great big deal (see: universal binary).


Not really - as I understand, they had this working back in the NeXT days. The app would have two different nib files, one that would contain the Windows-compilant interface and one that would contain the Mac-compliant interface.


More people using Cocoa, more software getting ported from Windows to Mac, and less suckage in the apps that are ported from Windows to Mac.

Think about it. If Objective-C/Cocoa became established as a development environment on Windows, and you were a Windows developer with a Cocoa/Win app, why would you not port to OS X, considering how much work would already be done for you?


Same thing if an app used the Registry, DirectX, or ActiveX on Windows. You'd rewrite the parts that needed to be rewritten, and not have to worry about the rest, as opposed to having to rewrite the whole thing.

Besides, there's no reason Apple can't port CoreImage, CoreVideo, etc. if they so desire. Heck, maybe they've been living a "secret double life" also, like OS X and Yellow Box have been.


Now that was uncalled for.


It's clearly not impossible. Whether or not it is probable is another issue which I'm not going to get into since my crystal ball has a pretty bad track record lately. But it does make sense, and I would really welcome this if they decided to do it.

Sorry, but the last thing Apple developers need is another "transition".

Too many applications rely on classes like
NSTask, ABClasses, NSAppleScript, [I think DO is a feature of Mach, so porting it would be hard. So had NSDistantObject to that, NSProxy, etc], NSMachBootstrapServer, NSMachPort, NSMetadataItem (and all the family), WebKit classes, IM.framework, CoreData, CoreImage, PDFKit, NSPrefPane, QTKit, QuartzComposer, SyncServices, ScreenSaver. Heck, even Automator. Add CD burn framework to that too. And all the security stuff which depends on UNIX perms.

My thesis is that Cocoa is too "macish" to be ported to Windows.


For instance, if Apple wanted to port all these to windows, it'd take time and money. And then there's the feasibility questions.

And if they don't, then we'll have windows developers coding windows/osx app that don't rely on these OSX only frameworks (e.g. they use their "own" address book à la MS, their "own" screensaver platform, their "own" script platform). A lot of OSX apps would lose their "cachet" . We'd end up with a lot of "lime wire" type apps on the mac. Steve Jobs doesn't want that.

[itistoday]

Originally Posted by ambush

Sorry, but the last thing Apple developers need is another "transition".

Too many applications rely on classes like
NSTask, ABClasses, NSAppleScript, [I think DO is a feature of Mach, so porting it would be hard. So had NSDistantObject to that, NSProxy, etc], NSMachBootstrapServer, NSMachPort, NSMetadataItem (and all the family), WebKit classes, IM.framework, CoreData, CoreImage, PDFKit, NSPrefPane, QTKit, QuartzComposer, SyncServices, ScreenSaver. Heck, even Automator. Add CD burn framework to that too. And all the security stuff which depends on UNIX perms.

My thesis is that Cocoa is too "macish" to be ported to Windows.


For instance, if Apple wanted to port all these to windows, it'd take time and money. And then there's the feasibility questions.

And if they don't, then we'll have windows developers coding windows/osx app that don't rely on these OSX only frameworks (e.g. they use their "own" address book à la MS, their "own" screensaver platform, their "own" script platform). A lot of OSX apps would lose their "cachet" . We'd end up with a lot of "lime wire" type apps on the mac. Steve Jobs doesn't want that.

Now, I'm not completely sure on this, but here's my take:

The hardest part is already done: porting Cocoa to x86. So, why can't Apple just release the entire Cocoa framework as a dynamic library for windows? It would be like running "part of OS X" on Windows. Any application installer made with this Yellow Box thing would first check and see if the latest version was installed on the user's computer and if it wasn't install it. Then all applications written in this way would use the dynamic library.

I'm not sure how they'd get low-level stuff like CoreImage working, but I'd assume they'd just have to use the equivalent Windows API stuff to get similar behavior... (since I don't think Windows would allow CoreImage to control the graphics card and do its own thing).

It's entirely possible, and it places no burden on the independent developer, all they do is click a checkbox that says "Windows". Some OS X-centrix features might not be available to them, but those might be obscure... Who knows, we'll just have to wait and see at the next WWDC. After Apple announced it had been compiling all versions of OS X on x86 I'm open to all sorts of rumors

I hope it's true though, it would make me actually want to learn Cocoa/ObjC, and it would greatly increase the amount of software available for the Mac.

My final guess: They'll port everything that has to do with simple UI widget stuff. Low-level functionality will not be ported. Basically it'll make writing a GUI for Windows as easy as writing one for Mac.

[Big Mac]

Originally Posted by starman

I don't see the point. You can run OS X apps on Windows....why? I'd bet any amount of money that you'd have a terrible time with file formats, copy/paste, and a slew of other issues.

Maybe I'll dig up my Yellow Box stuff and find a 486 to run it on . I have it around here somewhere.

Also, has anyone seen the number of frameworks that are involved with developing for OS X? God Almighty, that's a LOT of work! On top of the recompile for x86, you have to make the frameworks work with Windows. Bah, no. This is BS.

MIke

Unlike most of us, vmarks actually used EOF (Yellow Box) and said it worked well. Did you read his post?

[Big Mac]

Originally Posted by starman

I don't see the point. You can run OS X apps on Windows....why? I'd bet any amount of money that you'd have a terrible time with file formats, copy/paste, and a slew of other issues.

Maybe I'll dig up my Yellow Box stuff and find a 486 to run it on . I have it around here somewhere.

Also, has anyone seen the number of frameworks that are involved with developing for OS X? God Almighty, that's a LOT of work! On top of the recompile for x86, you have to make the frameworks work with Windows. Bah, no. This is BS.

MIke

Unlike most of us, vmarks actually used EOF (Yellow Box) and said it worked well. Did you read his post?

[Big Mac]

Originally Posted by starman

I don't see the point. You can run OS X apps on Windows....why? I'd bet any amount of money that you'd have a terrible time with file formats, copy/paste, and a slew of other issues.

Maybe I'll dig up my Yellow Box stuff and find a 486 to run it on . I have it around here somewhere.

Also, has anyone seen the number of frameworks that are involved with developing for OS X? God Almighty, that's a LOT of work! On top of the recompile for x86, you have to make the frameworks work with Windows. Bah, no. This is BS.

MIke

Unlike most of us, vmarks actually used EOF (Yellow Box) and said it worked well. Did you read his post?

[Oneota]

Originally Posted by - - e r i k - -

WebCore runs on Windows? In what app?

iTunes (the iTMS). That's how the store content looks the same on both platforms.

[TETENAL]

Originally Posted by Oneota

iTunes (the iTMS). That's how the store content looks the same on both platforms.

Nope.

[php]
otool /Applications/iTunes.app/Contents/MacOS/iTunes -L
/Applications/iTunes.app/Contents/MacOS/iTunes:
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.2)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.81)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 271.0.81)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 47.0.0)
/System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 182.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 222.0.0)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook (compatibility version 1.0.0, current version 472.0.0)
[/php]

[goMac]

Originally Posted by ambush

Sorry, but the last thing Apple developers need is another "transition".

Too many applications rely on classes like
NSTask, ABClasses, NSAppleScript, [I think DO is a feature of Mach, so porting it would be hard. So had NSDistantObject to that, NSProxy, etc], NSMachBootstrapServer, NSMachPort, NSMetadataItem (and all the family), WebKit classes, IM.framework, CoreData, CoreImage, PDFKit, NSPrefPane, QTKit, QuartzComposer, SyncServices, ScreenSaver. Heck, even Automator. Add CD burn framework to that too. And all the security stuff which depends on UNIX perms.

QTKit, WebKit, CoreData, and the IM framework would be a snap to port.

As far as the others I'm sure Apple wouldn't port them, so that the good Mac applications would stay on the Mac.

[CharlesS]

Originally Posted by Millennium

Neither, actually. One of the interesting things about Apple's package format is that you can actually have multiple binary files inside. This is how OSX's "Universal Binaries" are said to work: there are actually two copies of the app in the package, one for PPC and one for Intel. Add in Yellow Box for Windows, and you need three copies, but that's easy enough to handle. So you do have to recompile the app, but you could distribute the recompiled app as part of a universal binary. Mind you, I still don't think those things are going to catch on with many developers.

Actually, while what you described is possible, the Mach-O binary format itself seems able to encapsulate several different binaries. To see what I mean, look inside the package of any universal binary app, and look in the "MacOS" folder. You'll see only one binary, and if you use the "file" command on it, you'll get this:

/Applications/SomeApp.app/Contents/MacOS/SomeApp: Mach-O fat file with 2 architectures
/Applications/SomeApp.app/Contents/MacOS/SomeApp (for architecture i386): Mach-O executable i386
/Applications/SomeApp.app/Contents/MacOS/SomeApp (for architecture ppc): Mach-O executable ppc

Incidentally, this means that command-line tools, as well, can be Universal Binaries.

Originally Posted by TETENAL

iTunes 6 is certainly staying Carbon.

Not to get into this argument, but if Yellow Box were ported to Windows, then it might actually start to make sense to make iTunes Cocoa, because then Cocoa would suddenly be making it easier to port rather than harder.

[Millennium]

Originally Posted by ambush

My thesis is that Cocoa is too "macish" to be ported to Windows.

OPENSTEP was ported to Windows NT way back in The Day. Until WebObjects 5, Apple kept this port up to date, because it was offered as part of that package.

My point here is that most of the low-level stuff has already been ported, and although most of it would require at least a little updating for Windows XP, it's not outside the realm of feasibility. Once that part is done, porting most of the rest should be much easier.

The GNUSTEP project is also worth considering. This began way back in The Day as a port of the OPENSTEP APIs to Linux, but they've shifted focus somewhat and are now mirroring Cocoa. Although building apps using both frameworks is not yet popular, it has been done for a few reputable applications, notably GNUMail.app. A Windows port of GNUSTEP is coming along nicely; there's no Mac port because the Cocoa API already exists there. My point is: it's possible.

[Brass]

Originally Posted by ambush

old enums in current Cocoa.framework
What if an app uses CoreImage? CoreVideo? AddressBook? all external frameworks commonly used by cocoa apps and that are not available on Windows

um... that's exactly what the Yellow Box is (was). Itas all the external frameworks commonly used by Cocoa apps (ie, all the Cocoa frameworks and their dependencies), for Windows.

That is the whole point of the Yellow Box. Ie, to make all these frameworks (such as CoreImage, CoreVideo, and the more generic ones) available on Windows.

[goMac]

http://weblogs.mozillazine.org/hyatt...06.html#005666

iTunes does not use WebKit for rendering the store.

For the record:

http://gtk-webcore.sourceforge.net/

already has WebCore running on Windows.

[olePigeon]

Perhaps this new "Dharma" isn't YellowBox for Windows, but a translation layer for OS X to run Windows native applications. I think Apple filed a patent for doing that. You can install Windows like you do with Mac OS 9 and run it seemlessly (well, sort of) in OS X.

My concern is what incentive is there for developers to write Cocoa apps if they can just wring apps for Windows and tell Mac users to install Windows.

[goMac]

Originally Posted by olePigeon

Perhaps this new "Dharma" isn't YellowBox for Windows, but a translation layer for OS X to run Windows native applications. I think Apple filed a patent for doing that.

I talked to some Apple engineers off the record at WWDC, and the impression I got was that while Apple had played with this it wasn't anything serious. It was after some comment I made about getting WINE working.

Dharma roughly translates to universal truth, so Dharma would be a horribly poor code name for Win32 binary compatibility. Win32 binary compatibility is very dangerous to the Intel Macs right now. I've had vendors tell me in previous jobs that they sell Mac compatible applications, and by Mac compatible they mean it runs in Virtual PC. WINE opens to door to straight lazy recompiles, or even in some situations running natively. Apple needs to do everything they can to keep developers coding nice clean Cocoa applications.

[ambush]

dharma and john locke are references to LOST....

[itistoday]

Originally Posted by ambush

dharma and john locke are references to LOST....

No, you product of television, dharma is a reference to Hinduism and John Locke is a reference to John Locke, a 17th century English philosopher.

[goMac]

Originally Posted by ambush

dharma and john locke are references to LOST....

Sure, but the guy purposely changed his name, perhaps in reference to Dharma. Dharma fits very well as a code name for such a project.

[goMac]

Originally Posted by ambush

dharma and john locke are references to LOST....

Sure, but the guy purposely changed his name, perhaps in reference to Dharma. Dharma fits very well as a code name for such a project.