He is clearly asking if it is possible to produce one application that would successfully execte on a Mac with a PowerPC or Intel (Mactel) processor in addition to a computer which is running Windows (Wintel). Is it that confusing?
It's not PowerPC, Mactel, and Wintel. It is PowerPC and x86.
PowerPC is the processor architecture used in most macs from the mid-90s up until this year.
x86 is the processor architecture used in Intel-Macs, and most Windows-compatible PCs.
Wintel and Mactel are fan-created terms created to mean "a Windows compatible PC with an Intel processor" or "A Macintosh computer with an Intel processor". They both generally use the x86 architecture.
Oh come on. It's perfectly clear that he was referring to different ABIs: PowerPC Darwin, x86 Darwin, x86 Windows NT, and that he was asking if it would be possible to have a binary that runs on all three.
To which the answer is quite simple: yes, it would. However, to actually run an application that does anything remotely useful, you would also need to have the underlying frameworks available in x86 Windows NT binary form. They, too, could be universal binaries.
Thirdly, it would be necessary for Windows's NT kernel to actually parse Darwin's binaries, which it currently doesn't. It might be possible for Apple to create a wrapper, but that gets messy fast. As of now, Windows can't handle Mach-O at all, nor NeXT-/OS X-style bundles in general.
So is it possible to have one and the same binary run in Mac OS X, both PowerPC and x86, and in Windows? Yes, certainly. But is it possible without Microsoft's help? I'm not so sure about that. While Windows has a capability to extend its understood file systems, I doubt the same is true for binary formats.
And it would not only be messy for the programmers and the systems to handle. It would in no way be transparent for the user either. Just think of the difference in the user interfaces.
And what about application preferences? I see no way around having to set them for each type of system.
Just like the iPhone and the ExpressCard shaped Nano it might cater a small percentage of the users. But the cost/benefit is WAAAAAYYYYYYY too high.
It would in no way be transparent for the user either. Just think of the difference in the user interfaces.
Well, that's a whole other topic to get into. The thread didn't particularly specify whether we're even talking about GUI apps at all. Strictly speaking, Windows apps are already fairly unstandardized, especially compared to Mac OS; many apps use cross-platform UI toolkits without users complaining. (That alone is a big reason for me not to use Windows in an everyday environment.)
Quote:
And what about application preferences? I see no way around having to set them for each type of system.
That wouldn't be much of a problem. In fact, you'll find that Apple already uses some such features on Windows the same way they do on OS X. Just take a closer look at QuickTime's and iTunes's Windows versions and you'll find a lot of OS X-style things, such as .lproj folders inside a Resources folder, storing different localizations.
Modern OS X apps all use Apple's UserDefaults technique to store and retrieve preferences; the Windows equivalent could easily use the Registry without the need to change code, or it could store it in .plist files just like on Mac OS; users wouldn't care either way.
In general, I don't find the idea appealing or practical; my previous post was merely 'thinking out loud' (that, and I was getting tired at the general nit-picky/pedantic attitude in this thread: sure, the original poster didn't use 'proper terms', but that has been pointed out often enough already).
AFAI-Can Tell... THe question is why doesn't the compiler compile for "*DELL" machines so he can run OS X on a DELL. (*not particular to DEL, just a PC example) I'm not sure, but I don't think it's the compiler that isn't letting you install you Mac OS on your *DELL. It's Mac OS itself that is checking to see that your running it on a Mac. But I could be wrong. Nevertheless I doubt the compiler has anything to do with it.
Indeed. The code runs on a Dell, and OS X can be run (with some small modifications) on a Dell. There is no limitation to that, legal circumstances and ramifications aside.
It might be possible for Apple to create a wrapper, but that gets messy fast. As of now, Windows can't handle Mach-O at all, nor NeXT-/OS X-style bundles in general.
That's Red Box. We had a thread about it a while ago. The whole thing would be trivial if Apple decided to port the Cocoa frameworks to Windows. Any Cocoa app could then be recompiled for Win/x86, just as they have recently been recompiled for Darwin/x86. Creating Red Box for Windows would be a pain, since that's where all the mucking about in low-level call mapping would have to occur. But if Apple decided to do it, I'm sure they could manage. And any Cocoa app could them be compiled into a three-platform universal binary. You would just need to make sure you had Red Box installed on Windows before you tried to run it. But I doubt Apple will take the plunge just yet.
And any Cocoa app could them be compiled into a three-platform universal binary.
You haven't answered how they would create a binary that matches both Mach-O and PE formats at the same time. Mac OS X could be tweaked to understand PE, but Apple can't exactly extend the NT kernel to understand Mach-O.
A universal binary is just a wrapper for individual binaries which are then pointed to based on the host platform. Call it a 'chunk' for all I care, you'd have three of them instead of two.
Beating yourself with a clue stick would be more effective.
Quote:
A universal binary is just a wrapper for individual binaries which are then pointed to based on the host platform.
Precisely, and it requires the kernel's understanding of the wrapper format. Mach-O supports hosting multiple binaries in one file natively. Windows's PE implementation does, to the best of my knowledge, not, and even if it did, its wrapper format would almost inevitably be different.
Quote:
'K?
'K.
No, it's not "k". But since you insist, here's what's being reported about iTunes:
Code:
wohba:/Applications/iTunes.app/Contents/MacOS\\
chucker$ lipo -detailed_info iTunes
Fat header in: iTunes
fat_magic 0xcafebabe
nfat_arch 2
architecture ppc
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_ALL
offset 4096
size 9127472
align 2^12 (4096)
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 9134080
size 9085552
align 2^12 (4096)
Now, where do you expect all that information is coming from? Is OS X's kernel XNU pulling it out of its behind? No, it's stored as Metadata for the file, in the header. And what defines how header information is stored? A file format. And what file format is that? The Mach-O binary format. Does Windows support the Mach-O binary format? No, it does not.
So toss the Windows PE executables in the /Windows directory in the bundle. That's why the folder setup is there, take a look back at the NeXT usage and you'll see the same bloody thing. What were they called? Fat binaries. Was that literally one binary that was fat? No. It was a bundle that held multiple binaries in a bundle structure. Did it make sense? Yes. Universal binaries, for Mach_O aware kernels, are handled via one binary file, but I've yet to see anything that says that the older bundle approach couldn't also be used effectively in tandem.
Jesus, you guys are making this way more difficult than it needs to be.
Apple now has the ability to add support for other hardware platforms, or even other OSs, if they want to, without disrupting anything for current consumers. That's all that really needs to be understood by the phrase 'Universal Binaries'.
If you guys want to continue to beat the dead horse, please feel free to do so, but it's really pretty pointless.
So toss the Windows PE executables in the /Windows directory in the bundle. That's why the folder setup is there, take a look back at the NeXT usage and you'll see the same bloody thing. What were they called? Fat binaries. Was that literally one binary that was fat? No. It was a bundle that held multiple binaries in a bundle structure. Did it make sense? Yes. Universal binaries, for Mach_O aware kernels, are handled via one binary file, but I've yet to see anything that says that the older bundle approach couldn't also be used effectively in tandem.
Jesus, you guys are making this way more difficult than it needs to be.
Apple now has the ability to add support for other hardware platforms, or even other OSs, if they want to, without disrupting anything for current consumers. That's all that really needs to be understood by the phrase 'Universal Binaries'.
If you guys want to continue to beat the dead horse, please feel free to do so, but it's really pretty pointless.
As noted, "Universal" binaries can support multiple architectures of OS X - same as NeXTStep/OPENSTEP did in the NeXT days (i386,m68k, sparc and HP PA-RISC) - I used to regularly do builds for all four.
Anyway, you'd be fine adding additional processors so long as it was OS X.
OS X uses a binary format called "Mach-O" that support multiple code segments.
Windows has no idea how to deal with these kind of binaries, so adding in a Windows binary would do no good.
The OPENSTEP for Windows aka "Yellow Box" implementation NeXT did (now used only in WebObject deployment for Windows I believe), did not support universal (fat) binaries because the Windows exe format does not support it - which is why in the NT days when MS was building NT for RISC architectures (PPC and Alpha IIRC), you had to do separate builds of your code for Alpha as you did for Intel - we had an Alpha running NT, and I recall it was a pain, esp. because the dev tool support for the RISC NT implementation sucked.
Actually, just theorizing here... if Apple wanted to have Cocoa-for-Windows, then why not register .app as a CocoaLauncher.exe file format, and have this mythical CocoaLauncher.exe do the proper executable selection out of the bundle? Then the Cocoa framework would handle the rest of the NIB loading, etc, etc. It just seems to me that the problem here is the initial bootstrapping of the proper executable file to the Cocoa libraries.
Someone who's been subjected to more Windows development want to take a stab at this one?
Geeez some of you guys are really on the high horse aren't you. . . does it make you feel better to rip apart what is ( to me ) quite an interesting idea? Oh no, if he's not spelt it correctly then its not a valid subject. Catch a grip of yourselves.
----------------
As for the original question, the idea of it does appeal, it would be possible, but i think the biggest stumbler would be as already said, working the different interfaces together.
Comments
Originally posted by rogue27
It's not PowerPC, Mactel, and Wintel. It is PowerPC and x86.
PowerPC is the processor architecture used in most macs from the mid-90s up until this year.
x86 is the processor architecture used in Intel-Macs, and most Windows-compatible PCs.
Wintel and Mactel are fan-created terms created to mean "a Windows compatible PC with an Intel processor" or "A Macintosh computer with an Intel processor". They both generally use the x86 architecture.
Oh come on. It's perfectly clear that he was referring to different ABIs: PowerPC Darwin, x86 Darwin, x86 Windows NT, and that he was asking if it would be possible to have a binary that runs on all three.
To which the answer is quite simple: yes, it would. However, to actually run an application that does anything remotely useful, you would also need to have the underlying frameworks available in x86 Windows NT binary form. They, too, could be universal binaries.
Thirdly, it would be necessary for Windows's NT kernel to actually parse Darwin's binaries, which it currently doesn't. It might be possible for Apple to create a wrapper, but that gets messy fast. As of now, Windows can't handle Mach-O at all, nor NeXT-/OS X-style bundles in general.
So is it possible to have one and the same binary run in Mac OS X, both PowerPC and x86, and in Windows? Yes, certainly. But is it possible without Microsoft's help? I'm not so sure about that. While Windows has a capability to extend its understood file systems, I doubt the same is true for binary formats.
And what about application preferences? I see no way around having to set them for each type of system.
Just like the iPhone and the ExpressCard shaped Nano it might cater a small percentage of the users. But the cost/benefit is WAAAAAYYYYYYY too high.
Originally posted by Anders
It would in no way be transparent for the user either. Just think of the difference in the user interfaces.
Well, that's a whole other topic to get into. The thread didn't particularly specify whether we're even talking about GUI apps at all. Strictly speaking, Windows apps are already fairly unstandardized, especially compared to Mac OS; many apps use cross-platform UI toolkits without users complaining. (That alone is a big reason for me not to use Windows in an everyday environment.)
And what about application preferences? I see no way around having to set them for each type of system.
That wouldn't be much of a problem. In fact, you'll find that Apple already uses some such features on Windows the same way they do on OS X. Just take a closer look at QuickTime's and iTunes's Windows versions and you'll find a lot of OS X-style things, such as .lproj folders inside a Resources folder, storing different localizations.
Modern OS X apps all use Apple's UserDefaults technique to store and retrieve preferences; the Windows equivalent could easily use the Registry without the need to change code, or it could store it in .plist files just like on Mac OS; users wouldn't care either way.
In general, I don't find the idea appealing or practical; my previous post was merely 'thinking out loud' (that, and I was getting tired at the general nit-picky/pedantic attitude in this thread: sure, the original poster didn't use 'proper terms', but that has been pointed out often enough already).
Originally posted by Chucker
It might be possible for Apple to create a wrapper, but that gets messy fast. As of now, Windows can't handle Mach-O at all, nor NeXT-/OS X-style bundles in general.
That's Red Box. We had a thread about it a while ago. The whole thing would be trivial if Apple decided to port the Cocoa frameworks to Windows. Any Cocoa app could then be recompiled for Win/x86, just as they have recently been recompiled for Darwin/x86. Creating Red Box for Windows would be a pain, since that's where all the mucking about in low-level call mapping would have to occur. But if Apple decided to do it, I'm sure they could manage. And any Cocoa app could them be compiled into a three-platform universal binary. You would just need to make sure you had Red Box installed on Windows before you tried to run it. But I doubt Apple will take the plunge just yet.
Originally posted by Towel
And any Cocoa app could them be compiled into a three-platform universal binary.
You haven't answered how they would create a binary that matches both Mach-O and PE formats at the same time. Mac OS X could be tweaked to understand PE, but Apple can't exactly extend the NT kernel to understand Mach-O.
Originally posted by Kickaha
Er? You wouldn't have to. You'd have three binaries instead of two.
Eh? You currently have one binary, not two. The PowerPC and Intel binary parts are both in one and the same file.
You could, of course, put the Windows part into another file.
E.g.:
iTunes.app/Contents/MacOS/iTunes <-- PowerPC and x86, Darwin ABI, Mach-O format
iTunes.app/Contents/MacOS/iTunes.exe <-- x86, Windows NT ABI, PE format
or:
iTunes.app/Contents/MacOS/iTunes <-- PowerPC and x86, Darwin ABI, Mach-O format
iTunes.app/Contents/Windows/iTunes.exe <-- x86, Windows NT ABI, PE format
Of course, you still have to deal with the whole bundle thing, which could get a little ugly for the user.
A universal binary is just a wrapper for individual binaries which are then pointed to based on the host platform. Call it a 'chunk' for all I care, you'd have three of them instead of two.
'K?
'K.
Originally posted by Kickaha
Er? You wouldn't have to. You'd have three binaries instead of two. No big deal.
Huh? How many programs are only two or three binaries long? You don´t make any sense at all Kickaha.
Originally posted by Kickaha
*beats head against wall*
Beating yourself with a clue stick would be more effective.
A universal binary is just a wrapper for individual binaries which are then pointed to based on the host platform.
Precisely, and it requires the kernel's understanding of the wrapper format. Mach-O supports hosting multiple binaries in one file natively. Windows's PE implementation does, to the best of my knowledge, not, and even if it did, its wrapper format would almost inevitably be different.
'K?
'K.
No, it's not "k". But since you insist, here's what's being reported about iTunes:
wohba:/Applications/iTunes.app/Contents/MacOS\\
chucker$ lipo -detailed_info iTunes
Fat header in: iTunes
fat_magic 0xcafebabe
nfat_arch 2
architecture ppc
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_ALL
offset 4096
size 9127472
align 2^12 (4096)
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 9134080
size 9085552
align 2^12 (4096)
Now, where do you expect all that information is coming from? Is OS X's kernel XNU pulling it out of its behind? No, it's stored as Metadata for the file, in the header. And what defines how header information is stored? A file format. And what file format is that? The Mach-O binary format. Does Windows support the Mach-O binary format? No, it does not.
Case closed.
So toss the Windows PE executables in the /Windows directory in the bundle. That's why the folder setup is there, take a look back at the NeXT usage and you'll see the same bloody thing. What were they called? Fat binaries. Was that literally one binary that was fat? No. It was a bundle that held multiple binaries in a bundle structure. Did it make sense? Yes. Universal binaries, for Mach_O aware kernels, are handled via one binary file, but I've yet to see anything that says that the older bundle approach couldn't also be used effectively in tandem.
Jesus, you guys are making this way more difficult than it needs to be.
Apple now has the ability to add support for other hardware platforms, or even other OSs, if they want to, without disrupting anything for current consumers. That's all that really needs to be understood by the phrase 'Universal Binaries'.
If you guys want to continue to beat the dead horse, please feel free to do so, but it's really pretty pointless.
Originally posted by Kickaha
*throws hands in air*
So toss the Windows PE executables in the /Windows directory in the bundle. That's why the folder setup is there, take a look back at the NeXT usage and you'll see the same bloody thing. What were they called? Fat binaries. Was that literally one binary that was fat? No. It was a bundle that held multiple binaries in a bundle structure. Did it make sense? Yes. Universal binaries, for Mach_O aware kernels, are handled via one binary file, but I've yet to see anything that says that the older bundle approach couldn't also be used effectively in tandem.
Jesus, you guys are making this way more difficult than it needs to be.
Apple now has the ability to add support for other hardware platforms, or even other OSs, if they want to, without disrupting anything for current consumers. That's all that really needs to be understood by the phrase 'Universal Binaries'.
If you guys want to continue to beat the dead horse, please feel free to do so, but it's really pretty pointless.
I agree. Close this thread I hate it.
As noted, "Universal" binaries can support multiple architectures of OS X - same as NeXTStep/OPENSTEP did in the NeXT days (i386,m68k, sparc and HP PA-RISC) - I used to regularly do builds for all four.
Anyway, you'd be fine adding additional processors so long as it was OS X.
OS X uses a binary format called "Mach-O" that support multiple code segments.
Windows has no idea how to deal with these kind of binaries, so adding in a Windows binary would do no good.
The OPENSTEP for Windows aka "Yellow Box" implementation NeXT did (now used only in WebObject deployment for Windows I believe), did not support universal (fat) binaries because the Windows exe format does not support it - which is why in the NT days when MS was building NT for RISC architectures (PPC and Alpha IIRC), you had to do separate builds of your code for Alpha as you did for Intel - we had an Alpha running NT, and I recall it was a pain, esp. because the dev tool support for the RISC NT implementation sucked.
Someone who's been subjected to more Windows development want to take a stab at this one?
----------------
As for the original question, the idea of it does appeal, it would be possible, but i think the biggest stumbler would be as already said, working the different interfaces together.
The 4-way meant 4 native versions of Openstep on 4 distinct CPU Chipsets.
Pardon me if someone already pointed this out. It gets really annoying when people don't know the what the FAT binaries actually means.