[quote] Is it possible that any Cocoa app can actually run on X86 under OS X with a simple "switch" thrown in gcc at compile time?<hr></blockquote>
Yes but that would require OS X on x86: The Topic That Will Not Die. Cocoa may be portable to Windows but that's a bit risky when Apple doesn't control the rest of the OS.
Hey Lemon, any chance of cutting the sig, I think we've all read it now? It gets a bit boring when you all you do is post a smiley and 100 words of sig - and you do that a lot!
But, and I'm really just a programming newbie, if I understand it correctly. Cocoa apps basically have a type of VM in which the apps are actually executed (sorta like Java only with a much smaller performance penalty). Is it possible that any Cocoa app can actually run on X86 under OS X with a simple "switch" thrown in gcc at compile time?
....</strong><hr></blockquote>Cocoa apps do not require a virtual machine to run. They run natively on whichever platform they have been ported to. To date, only the PPC version of Cocoa has seen the light of day. Cocoa is the successor environment to Rhapsody's Yellow Box. The Yellow Box was planned to be portable across operating operating systems as well as processors.
It should be borne in mind that Cocoa APIs are interoperable with the APIs of Carbon and Darwin. For example, Apple actually recommends that developers generate their Carbon apps' GUIs using Cocoa. Mozilla is an example of mixing Darwin Mach and Carbon, IIRC. These "mixed-mode" applications would not be possible in an environment of virtual machines.
<strong>Maybe AMD are just helping with yields?</strong><hr></blockquote>
I somewhat doubt that given they can't even get decent yields on their Barton or Hammer cpus and have had major set backs with fabrication over the past year.
[quote][QB]Cocoa apps do not require a virtual machine to run. They run natively on whichever platform they have been ported to. To date, only the PPC version of Cocoa has seen the light of day. Cocoa is the successor environment to Rhapsody's Yellow Box.[QB]<hr></blockquote>Please. Please go do some work with (or even reading on) Cocoa before spreading such disinformation! Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.
Not only was Cocoa not developed by Apple, it wasn't even designed for the powerPC platform. It has been and is available for many platforms including x86. Cocoa is over a decade old and was not developed as a successor to yellow box.
<strong>Please. Please go do some work with (or even reading on) Cocoa before spreading such disinformation! Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.</strong><hr></blockquote>A set of preinstalled binary libraries do not in and of themselves make a virtual machine. By that definition all major operating systems today are virtual machines.
[quote]<strong>Not only was Cocoa not developed by Apple, it wasn't even designed for the powerPC platform. It has been and is available for many platforms including x86. Cocoa is over a decade old and was not developed as a successor to yellow box.</strong><hr></blockquote>You are confusing OpenSTEP with Cocoa.
<strong>Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.</strong><hr></blockquote>
Cocoa is just a set of libraries with public API headers. It has nothing to do with virtual machines. Don't confuse VM (virtual machine) and VM (virtual memory).
<strong>... There's got to be a reason why Apple execs hang with AMD earlier this year. Reports of AMD/Apple 'secret' meetings? </strong><hr></blockquote>
<strong>Please. Please go do some work with (or even reading on) Cocoa before spreading such disinformation! Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.
Not only was Cocoa not developed by Apple, it wasn't even designed for the powerPC platform. It has been and is available for many platforms including x86. Cocoa is over a decade old and was not developed as a successor to yellow box.</strong><hr></blockquote>
A virtual machine allows programs to be run on different hardware without compilation by specifying its own instruction set that is emulated by all platforms. Programs written for it are therefore complied to this virtual machine and hence aren't native to any real hardware (unless somebody happens to implement your virtual machine in hardware). Cocoa uses gcc or CodeWarrior to compile the Objective-C software into native PowerPC machine instructions, therefore it is not a virtual machine. Its is a class framework which is very portable and can be implemented to sit atop other native API (like the Win32 version of it did). It does not let apps built atop it port for free, but it does make it easier. If the app contains machine-specific code then that code must still be rewritten. Otherwise it may just need to be recompiled.
[quote] Hey Lemon, any chance of cutting the sig, I think we've all read it now? It gets a bit boring when you all you do is post a smiley and 100 words of sig - and you do that a lot!
A virtual machine allows programs to be run on different hardware without compilation by specifying its own instruction set that is emulated by all platforms. Programs written for it are therefore complied to this virtual machine and hence aren't native to any real hardware (unless somebody happens to implement your virtual machine in hardware). Cocoa uses gcc or CodeWarrior to compile the Objective-C software into native PowerPC machine instructions, therefore it is not a virtual machine. Its is a class framework which is very portable and can be implemented to sit atop other native API (like the Win32 version of it did). It does not let apps built atop it port for free, but it does make it easier. If the app contains machine-specific code then that code must still be rewritten. Otherwise it may just need to be recompiled.</strong><hr></blockquote>Heheh, while my comments on cocoa provoked a couple of responses, I prefer to reply to yours (The others somehow presumed I was confusing OpenStep for Cocoa or a virtual machine for virtual memory. )
There has never been a consensus on precisely what comprises a 'virtual machine'. Java's 'virtual machine' has made the term even more ambiguous as did the popularity of MIPS 'virtual machines' in many US programming courses.
Rest assured, I fully realize the differences between hardware abstraction/emulation and the functionality provided by Cocoa. I was merely trying to point out that the Cocoa 'API' falls into a gray area that usually separates other lower-level and less-dynamic languages from the category of 'virtual machines'.
I was mainly trying to refute the following two statements:
Cocoa is the successor environment to Rhapsody's Yellow Box.
To date, only the PPC version of Cocoa has seen the light of day.
Rest assured, I fully realize the differences between hardware abstraction/emulation and the functionality provided by Cocoa. I was merely trying to point out that the Cocoa 'API' falls into a gray area that usually separates other lower-level and less-dynamic languages from the category of 'virtual machines'.
I was mainly trying to refute the following two statements:Cocoa is the successor environment to Rhapsody's Yellow Box. To date, only the PPC version of Cocoa has seen the light of day.
For Cocoa to run on different hardware would require a recompile to the new machine code. To me that means it does not run on a "virtual" machine. Cocoa is a class framework, plain and simple. It just happens to be implemented in Objective-C which has a more dynamic form of runtime binding that is normal in C/C++ (but less than in various other languages).
Cocoa is Yellow Box which is NeXTStep. These are all just a series of versions of the same class framework, albeit implemented atop a changing set of low-level services. Looked at like this, the PowerPC version follows the 68k and x86 versions.
For Cocoa to run on different hardware would require a recompile to the new machine code. To me that means it does not run on a "virtual" machine. Cocoa is a class framework, plain and simple. It just happens to be implemented in Objective-C which has a more dynamic form of runtime binding that is normal in C/C++ (but less than in various other languages).
Cocoa is Yellow Box which is NeXTStep. These are all just a series of versions of the same class framework, albeit implemented atop a changing set of low-level services. Looked at like this, the PowerPC version follows the 68k and x86 versions.
Well... not exactly. That is why I'm pointing out that what is actually at issue is the definition of a 'virtual machine'. The functionality of cocoa is quite easy to pin down. Its classes like NSSound and NSEvent that blur the definition. Neither class is remotely possible without platform/hardware specific code. That hardware specific code is as much a virtual machine as the JVM.
We really need more than the two classifications of virtual machine and non-VM. It?s like trying to define whether an SUV is a car or a truck. Its neither and both, so a new term was coined.
I think we're also in agreement about the relationship of Yellow Box and Cocoa. It is just important to note that Cocoa was around prior to Apple's Box nomenclature. Cocoa is not a Yellow box derivative.
Well... not exactly. That is why I'm pointing out that what is actually at issue is the definition of a 'virtual machine'. The functionality of cocoa is quite easy to pin down. Its classes like NSSound and NSEvent that blur the definition. Neither class is remotely possible without platform/hardware specific code. That hardware specific code is as much a virtual machine as the JVM.
Yes, well my point was that a machine is only virtual if its not "concrete" (being the opposite of virtual). A machine which has a few abstractions but leaves some piece still anchored on a specific piece of hardware is still concrete, and therefore not virtual. I agree that it could be a fuzzy line, but the generally accepted meaning these days of "virtual machine" means that the executable is not represented in the specific machine code of any particular physical processor. We've had support libraries for a very long time, and nobody bothered to call them "virtual machines".
Quote:
We really need more than the two classifications of virtual machine and non-VM. It?s like trying to define whether an SUV is a car or a truck. Its neither and both, so a new term was coined.
There is a term that describes Cocoa just fine: "framework". Or "class framework" to be a little more specific. What is interesting is that when you use this class framework in conjunction with the Java Virtual Machine then your code is running in a virtual machine... but that's due to Java's VM, not Cocoa.
Quote:
I think we're also in agreement about the relationship of Yellow Box and Cocoa. It is just important to note that Cocoa was around prior to Apple's Box nomenclature. Cocoa is not a Yellow box derivative.
This depends on what you mean by "derivative". YellowBox was a derivative of NeXTStep in the sense that they took the NeXTStep technology and used it to build the YellowBox. Cocoa is derivative in that they took parts (or possibly all) of the YellowBox work and named that Cocoa and made whatever changes were necessary to make it interoperable with the Carbon runtime environment (i.e. they made the Foundation classes visible to Carbon, which may or may not have required changes to their original Objective-C implementation). I'm not privvy to the details of the current Cocoa implementation, but from the point of view of the developer using the framework they are all just successive versions of exactly the same thing. YellowBox and Cocoa may be exactly the same thing in all but name -- and YellowBox was called that simply because Apple hadn't come up with the name Cocoa yet but they had this box representing the NeXTStep framework on their slides, and it happened to be the colour yellow.
Why do you keep wanting to talk about AMD/PPC? This is far more interesting...
Comments
<strong>
'are'
Lemon Bon Bon</strong><hr></blockquote>
<pretending not to be 16>
kids these days...no respect for the english language
</pretending not to be 16>
<hr></blockquote>
<img src="graemlins/lol.gif" border="0" alt="[Laughing]" />
Lemon Bon Bon
<strong>Remember, kids: Don't feed the trolls.</strong><hr></blockquote>
"eez eediots"
Charo!
Where ya been?
Yes but that would require OS X on x86: The Topic That Will Not Die. Cocoa may be portable to Windows but that's a bit risky when Apple doesn't control the rest of the OS.
<strong>
<img src="graemlins/lol.gif" border="0" alt="[Laughing]" /> </strong><hr></blockquote>
Hey Lemon, any chance of cutting the sig, I think we've all read it now? It gets a bit boring when you all you do is post a smiley and 100 words of sig - and you do that a lot!
<strong>....
But, and I'm really just a programming newbie, if I understand it correctly. Cocoa apps basically have a type of VM in which the apps are actually executed (sorta like Java only with a much smaller performance penalty). Is it possible that any Cocoa app can actually run on X86 under OS X with a simple "switch" thrown in gcc at compile time?
....</strong><hr></blockquote>Cocoa apps do not require a virtual machine to run. They run natively on whichever platform they have been ported to. To date, only the PPC version of Cocoa has seen the light of day. Cocoa is the successor environment to Rhapsody's Yellow Box. The Yellow Box was planned to be portable across operating operating systems as well as processors.
It should be borne in mind that Cocoa APIs are interoperable with the APIs of Carbon and Darwin. For example, Apple actually recommends that developers generate their Carbon apps' GUIs using Cocoa. Mozilla is an example of mixing Darwin Mach and Carbon, IIRC. These "mixed-mode" applications would not be possible in an environment of virtual machines.
[ 03-16-2003: Message edited by: Mr. Me ]</p>
<strong>AMD can sure make chips cheap as 'chips'
Maybe AMD are just helping with yields?</strong><hr></blockquote>
The whole story is hard to believe, although not at all impossible. One thing is sure: it would be a great scandal in the Wintel world.
<strong>Maybe AMD are just helping with yields?</strong><hr></blockquote>
I somewhat doubt that given they can't even get decent yields on their Barton or Hammer cpus and have had major set backs with fabrication over the past year.
Not only was Cocoa not developed by Apple, it wasn't even designed for the powerPC platform. It has been and is available for many platforms including x86. Cocoa is over a decade old and was not developed as a successor to yellow box.
<strong>Please. Please go do some work with (or even reading on) Cocoa before spreading such disinformation! Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.</strong><hr></blockquote>A set of preinstalled binary libraries do not in and of themselves make a virtual machine. By that definition all major operating systems today are virtual machines.
[quote]<strong>Not only was Cocoa not developed by Apple, it wasn't even designed for the powerPC platform. It has been and is available for many platforms including x86. Cocoa is over a decade old and was not developed as a successor to yellow box.</strong><hr></blockquote>You are confusing OpenSTEP with Cocoa.
[ 03-17-2003: Message edited by: Mr. Me ]</p>
<strong>Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.</strong><hr></blockquote>
Cocoa is just a set of libraries with public API headers. It has nothing to do with virtual machines. Don't confuse VM (virtual machine) and VM (virtual memory).
<strong>... There's got to be a reason why Apple execs hang with AMD earlier this year. Reports of AMD/Apple 'secret' meetings? </strong><hr></blockquote>
you've got pictures
<strong>Please. Please go do some work with (or even reading on) Cocoa before spreading such disinformation! Cocoa requires preinstalled binary libraries that include many virtual machine like functions, maintaining user information not associated with any particular program.
Not only was Cocoa not developed by Apple, it wasn't even designed for the powerPC platform. It has been and is available for many platforms including x86. Cocoa is over a decade old and was not developed as a successor to yellow box.</strong><hr></blockquote>
A virtual machine allows programs to be run on different hardware without compilation by specifying its own instruction set that is emulated by all platforms. Programs written for it are therefore complied to this virtual machine and hence aren't native to any real hardware (unless somebody happens to implement your virtual machine in hardware). Cocoa uses gcc or CodeWarrior to compile the Objective-C software into native PowerPC machine instructions, therefore it is not a virtual machine. Its is a class framework which is very portable and can be implemented to sit atop other native API (like the Win32 version of it did). It does not let apps built atop it port for free, but it does make it easier. If the app contains machine-specific code then that code must still be rewritten. Otherwise it may just need to be recompiled.
<hr></blockquote>
Just for 'Caustic' Clive.
Lemon Bon Bon
<strong>
A virtual machine allows programs to be run on different hardware without compilation by specifying its own instruction set that is emulated by all platforms. Programs written for it are therefore complied to this virtual machine and hence aren't native to any real hardware (unless somebody happens to implement your virtual machine in hardware). Cocoa uses gcc or CodeWarrior to compile the Objective-C software into native PowerPC machine instructions, therefore it is not a virtual machine. Its is a class framework which is very portable and can be implemented to sit atop other native API (like the Win32 version of it did). It does not let apps built atop it port for free, but it does make it easier. If the app contains machine-specific code then that code must still be rewritten. Otherwise it may just need to be recompiled.</strong><hr></blockquote>Heheh, while my comments on cocoa provoked a couple of responses, I prefer to reply to yours
There has never been a consensus on precisely what comprises a 'virtual machine'. Java's 'virtual machine' has made the term even more ambiguous as did the popularity of MIPS 'virtual machines' in many US programming courses.
Rest assured, I fully realize the differences between hardware abstraction/emulation and the functionality provided by Cocoa. I was merely trying to point out that the Cocoa 'API' falls into a gray area that usually separates other lower-level and less-dynamic languages from the category of 'virtual machines'.
I was mainly trying to refute the following two statements:
- Cocoa is the successor environment to Rhapsody's Yellow Box.
- To date, only the PPC version of Cocoa has seen the light of day.
Say... anyone hear something about AMD and PPC?[ 03-17-2003: Message edited by: dfiler ]</p>
Originally posted by dfiler
Rest assured, I fully realize the differences between hardware abstraction/emulation and the functionality provided by Cocoa. I was merely trying to point out that the Cocoa 'API' falls into a gray area that usually separates other lower-level and less-dynamic languages from the category of 'virtual machines'.
I was mainly trying to refute the following two statements:Cocoa is the successor environment to Rhapsody's Yellow Box.
To date, only the PPC version of Cocoa has seen the light of day.
For Cocoa to run on different hardware would require a recompile to the new machine code. To me that means it does not run on a "virtual" machine. Cocoa is a class framework, plain and simple. It just happens to be implemented in Objective-C which has a more dynamic form of runtime binding that is normal in C/C++ (but less than in various other languages).
Cocoa is Yellow Box which is NeXTStep. These are all just a series of versions of the same class framework, albeit implemented atop a changing set of low-level services. Looked at like this, the PowerPC version follows the 68k and x86 versions.
Originally posted by Programmer
For Cocoa to run on different hardware would require a recompile to the new machine code. To me that means it does not run on a "virtual" machine. Cocoa is a class framework, plain and simple. It just happens to be implemented in Objective-C which has a more dynamic form of runtime binding that is normal in C/C++ (but less than in various other languages).
Cocoa is Yellow Box which is NeXTStep. These are all just a series of versions of the same class framework, albeit implemented atop a changing set of low-level services. Looked at like this, the PowerPC version follows the 68k and x86 versions.
Well... not exactly. That is why I'm pointing out that what is actually at issue is the definition of a 'virtual machine'. The functionality of cocoa is quite easy to pin down. Its classes like NSSound and NSEvent that blur the definition. Neither class is remotely possible without platform/hardware specific code. That hardware specific code is as much a virtual machine as the JVM.
We really need more than the two classifications of virtual machine and non-VM. It?s like trying to define whether an SUV is a car or a truck. Its neither and both, so a new term was coined.
I think we're also in agreement about the relationship of Yellow Box and Cocoa. It is just important to note that Cocoa was around prior to Apple's Box nomenclature. Cocoa is not a Yellow box derivative.
AMD? PPC? Anyone?
(ok off to GD to rant about the new look)
Originally posted by dfiler
Well... not exactly. That is why I'm pointing out that what is actually at issue is the definition of a 'virtual machine'. The functionality of cocoa is quite easy to pin down. Its classes like NSSound and NSEvent that blur the definition. Neither class is remotely possible without platform/hardware specific code. That hardware specific code is as much a virtual machine as the JVM.
Yes, well my point was that a machine is only virtual if its not "concrete" (being the opposite of virtual). A machine which has a few abstractions but leaves some piece still anchored on a specific piece of hardware is still concrete, and therefore not virtual. I agree that it could be a fuzzy line, but the generally accepted meaning these days of "virtual machine" means that the executable is not represented in the specific machine code of any particular physical processor. We've had support libraries for a very long time, and nobody bothered to call them "virtual machines".
We really need more than the two classifications of virtual machine and non-VM. It?s like trying to define whether an SUV is a car or a truck. Its neither and both, so a new term was coined.
There is a term that describes Cocoa just fine: "framework". Or "class framework" to be a little more specific. What is interesting is that when you use this class framework in conjunction with the Java Virtual Machine then your code is running in a virtual machine... but that's due to Java's VM, not Cocoa.
I think we're also in agreement about the relationship of Yellow Box and Cocoa. It is just important to note that Cocoa was around prior to Apple's Box nomenclature. Cocoa is not a Yellow box derivative.
This depends on what you mean by "derivative". YellowBox was a derivative of NeXTStep in the sense that they took the NeXTStep technology and used it to build the YellowBox. Cocoa is derivative in that they took parts (or possibly all) of the YellowBox work and named that Cocoa and made whatever changes were necessary to make it interoperable with the Carbon runtime environment (i.e. they made the Foundation classes visible to Carbon, which may or may not have required changes to their original Objective-C implementation). I'm not privvy to the details of the current Cocoa implementation, but from the point of view of the developer using the framework they are all just successive versions of exactly the same thing. YellowBox and Cocoa may be exactly the same thing in all but name -- and YellowBox was called that simply because Apple hadn't come up with the name Cocoa yet but they had this box representing the NeXTStep framework on their slides, and it happened to be the colour yellow.
Why do you keep wanting to talk about AMD/PPC? This is far more interesting...