Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
Not open for further replies.
At a minimum, Cocoa on Windows would have internal benefits for Apple.

The Quicktime client on Mac OS X is now written in Cocoa. iTunes will probably receive a serious overhaul when the new video centric version is released and may be rebuilt in Cocoa.

With a version of Cocoa for Windows, Apple could unify their code base between both platforms, significantly reducing their development costs. Essentially, they could build Windows versions of the Quicktime client, Safari, iTunes and iChat, almost for "Free."

However, Apple may limit this technology to internal use only, which would really be disappointing.
 
Well, Apple only fail to release a free runtime environment for Yellow Box when the project was killed. Without that runtime environment, applications written for Yellow Box for Windows wouldn't run.

Apple had promised (originally) that the runtime environment would be made available for free or could be included with developer's applications. That was the part that Apple backed out of when ending Yellow Box for Windows.

Anyone wanting to play with Yellow Box for Windows and Yellow Box applications need only find an old copy of WebObjects 4.x for Windows. Everything needed is there.


As for the validity of this e-mail, it seems quite questionable to me. This passage:
"As you probably know it, the Yellow Box for Windows was NeXT's project of porting Project Builder (known as Xcode today) and the complete NeXT API (known as Cocoa today) to Windows, allowing developers to create a Windows binary by simply ticking a check box."
makes me wonder about the writer's understanding of Yellow Box.

First, Yellow Box was Apple's name for the APIs used in Yellow Box for Windows, Rhapsody/Mac OS X Server 1.x and WebObjects 4.x. It was based on NeXT's OpenStep APIs, but had a number of changes. NeXT didn't exist anymore when the term Yellow Box was first introduced.

The previous runtime environment before Yellow Box for Windows was OpenStep Enterprise for Windows. That was a NeXT project.

Secondly, the "simply ticking a check box" thing hardly worked in NEXTSTEP/OPENSTEP/Rhapsody when dealing with different hardware platforms, it was absolutely not as simple as clicking a check box to make Windows apps. Those required a lot of extra work including a ton of time in Interface Builder.


Now, that having been said, the question of Apple doing this is still an interesting one. The main reason that I saw for Apple dropping Yellow Box for Windows was that it provided too many of the underlying features of WebObjects which would have cut into sales.

Of course WebObjects isn't the revenue earner these days that it was back in 1998/1999, so the idea that Apple would go forward on this isn't that far fetched.

... I just don't see this e-mail as having any link to Apple in anyway.


As for wanting an open source version of Cocoa, the GNUstep project has been attempting to keep the OpenStep Specifications as up-to-date (as close to Cocoa) as possible. It seems like most of their time has been spent on trying to recreate the NEXTSTEP/OPENSTEP environment rather than making a development platform. The last time I checked, it didn't seem like there was a lot of apps for GNUstep... specially compared to the number of apps i have installed (or can install) on my OPENSTEP system.
 
Information about John Locke

John Locke, born on Aug. 29, 1632, in Somerset, England, was an English philosopher and political theorist.

"All men are liable to error; and most men are, in many points, by passion or interest, under temptation to it." (Essay Concerning Human Understanding)


Lost (TV Series)
Episode 19: Deus Ex Machina
John Locke, the 17th century English philosopher whom the character in the show is named after, was friends with the earl of Shaftesbury, Anthony Ashley Cooper. The last name of Locke's father in "Lost" is Cooper
 
pixelfreak said:
At a minimum, Cocoa on Windows would have internal benefits for Apple.

The Quicktime client on Mac OS X is now written in Cocoa. iTunes will probably receive a serious overhaul when the new video centric version is released and may be rebuilt in Cocoa.

With a version of Cocoa for Windows, Apple could unify their code base between both platforms, significantly reducing their development costs. Essentially, they could build Windows versions of the Quicktime client, Safari, iTunes and iChat, almost for "Free."

However, Apple may limit this technology to internal use only, which would really be disappointing.
I agree! At the very least, Apple deploying this technology internally will save them on development costs, and will make release of future products to Windows users that much easier.
 
I'm not sure Apple really cares about releasing products to Windows users. iTunes generates revenue and sells iPods. There was a definite reason for it to be released onto Windows. Regardless of how easy it would be to port Safari and iChat to Windows, they would need a model that would generate income before they would do such a thing. Giving it a way wouldn't exactly make them a ton of money. I could almost see them selling iLife at a premium on Windows before giving away Safari and iChat. But I don't think that's gonna happen either. If you want the "Mac" experience, you'll still have to buy a Mac (or find a cracked version of the OS for your Dell :eek:;) ).
 
isgoed said:
Ironically you already said the answer. The connection is the television series Lost (filmed on Hawaii, John Locke being a character). Or are you just being funny and you already knew this?

JFlac got it right!
JFlac said:
Since "Man of Science, Man of Faith" is the name of the first season 2 episode, I think Mechcozmo already knew this. :)

Well, just to stay on topic, your comments on OSNews' screenshot?

Screenshots can be faked. Take an iTunes for Windows screenshot and merge some Safari for OS X stuff into it, then drop it onto a Windows XP background. Pretty simple.

Booga said:
Not gonna happen. Cocoa will be abandoned before Carbon.

Besides, Cocoa is what people in the 1980's thought would make a good object-oriented API. While a revolution in productivity in the 1980's, it's really not anything special anymore.

They'd be better off adopting Mono and C#, or some sort of Java API. Forcing developers to write Objective C code to work with the Mac is a non-starter. I can't think of any quicker way to destroy the Mac software market.

Yes, and Carbon was everyone's good idea in the 1970's. So it isn't too special anymore. So why hasn't it been dropped yet? C# is a Microsoft product... doubt Apple will use it. Java too is not an Apple product.

Objective-C is the best language around for the Mac. Easy to use, too. So why is the Mac market being destroyed by a GOOD programming language?
 
Seems like a page one rumor to me, when running windows apps in the intel osX seems a bad idea, this looks like the perfect solution to bring more apps to our platform PPC and Intel alike. Honestly i think there is no other option than to add this functionality.
 
Mechcozmo said:
JFlac got it right!


Screenshots can be faked. Take an iTunes for Windows screenshot and merge some Safari for OS X stuff into it, then drop it onto a Windows XP background. Pretty simple.



Yes, and Carbon was everyone's good idea in the 1970's. So it isn't too special anymore. So why hasn't it been dropped yet? C# is a Microsoft product... doubt Apple will use it. Java too is not an Apple product.

Objective-C is the best language around for the Mac. Easy to use, too. So why is the Mac market being destroyed by a GOOD programming language?
You do make a valid point, which I agree with completely. The problem is that Objective-C isn't used anywhere else that I know of, so it's relatively unknown to programmers. This is one of the things that turns some developers off of coding for the Mac.
 
wrldwzrd89 said:
You do make a valid point, which I agree with completely. The problem is that Objective-C isn't used anywhere else that I know of, so it's relatively unknown to programmers. This is one of the things that turns some developers off of coding for the Mac.

Apple cannot drop Cocoa and Objective-C without fundamentally changing Mac OS X itself. This will not happen.

With the intel switch we have seen that Apple put all its cards on Cocoa/Objective-C, because they are telling developers to switch from Carbon to Cocoa. It looks like Carbon WILL be dropped in the near future. Cocoa is the future, NOT Carbon. Whoever said Cocoa will be dropped before Carbon needs a reality check.

Microsoft's .NET is a competitor, but that simply can't be implemented into Mac OS X as a first class framework. Java is a non-issue in this respect, it has as much status in Mac OS X as it has in Windows.

However, it's true that Objective-C and Cocoa suffer from the fact that it is generally not well known. Also, the language and framework do not support multithreading as well as others do. Garbage collection is not supported either. Those will be big issues in the future of software development. It will be interesting to see how Apple will handle that.
 
MacNeXT said:
With the intel switch we have seen that Apple put all its cards on Cocoa/Objective-C, because they are telling developers to switch from Carbon to Cocoa.
Where do you get this from? Apple has not said any such thing.

ps... to others.... are Java and Objective-C equally valid now in mac development?
 
GregA said:
Where do you get this from? Apple has not said any such thing.

ps... to others.... are Java and Objective-C equally valid now in mac development?

I'm sorry, I stand corrected.

Developers have to move to Xcode. It does makes more sense to do a new project in Cocoa instead of Carbon.

And no, Java and Objective-C are not equally valid. A significant part of the operating system is written in Obective-C/Cocoa. It is native. That is not the case for Java. Like I said, Java has the same status on Mac OS X as it has on Windows.
 
MacNeXT said:
Developers have to move to Xcode. It does makes more sense to do a new project in Cocoa instead of Carbon.
It depends on whether they are starting from scratch, or porting their previous Mac program.

Mostly, they'll be porting, which means the frameworks they have code for are using Carbon. It will be easier to stick with those than start from scratch (for most developers).
 
Which media player on Windows doesn't have a totally different interface? Windows Media Player works nothing like any other programs, Winamp totally different interface, Real Player totally different interface.

Windows media programs try to emulate the UI of dvd players and other consumer devices. Not have their own computer like UI, a lot of windows media player is very typically windows.
 
MacNeXT said:
However, it's true that Objective-C and Cocoa suffer from the fact that it is generally not well known. Also, the language and framework do not support multithreading as well as others do. Garbage collection is not supported either. Those will be big issues in the future of software development. It will be interesting to see how Apple will handle that.

Garbage collection is the future of lazy programmers. Objective-C's retain/release/autorelease system is very easy to learn and it doesn't take much practice to get it down - it's also more efficient.

I'm not sure if it doesn't support multithreading well - XCode's debugger isn't very good at multithread debugging, but that can be fixed.

I agree with you that Obj-C and Cocoa aren't well known outside of Mac circles, and that's something Apple's going to have to work on if this rumor turns out to be true.
 
Beg pardon?

Garbage collection is the future of lazy programmers. Objective-C's retain/release/autorelease system is very easy to learn and it doesn't take much practice to get it down - it's also more efficient.

Mmm ... no.

Just because Apple doesn't have it, doesn't mean it isn't a useful thing to have.

Garbage collection doesn't catch all problems by any means, but it's a housekeeping task that should be handled by any half-decent runtime, on any OS that can run at a half decent speed.

As long as you don't assume that its completely infallible, then it certainly frees you to concentrate on more important things; like the actual application you're writing, rather than the OS you're running it on.
 
The technology is easy, business strategy is hard

Apple has had the Cocoa runtime for Windows available for many years -- it's how Cocoa-based Web Objects applications run on Windows servers. The only reason that Cocoa developers haven't been using it to ship Cocoa applications for Windows is that Apple has refused to license the runtime to them for redistribution.

So while there's no technological impediment, there's a business issue -- so far Apple has decided to use the Cocoa framework to promote Mac OS X (and thus sell more hardware). If they allow developers to ship Cocoa applications for other operating systems, they're allowing their developers to ship their applications for Windows and Mac (same CD, even), which might lose Mac OS X a differentiator. On the other hand, it might allow more developers to support the Mac, which would be good for Apple.
 
Objective-C is not Java. It's designed for application *and* OS level software, which is usually developed in C.

Objective-C is a superset of C. This means that any valid C code can be mixed directly with Objective-C. There is also a variant called Objective-C++ which allows direct use of C++ code along side with Objective-C.

This gives you access to the staggering amount of code and libraries written in C and C++, some of which have already been wrapped in Objective-C classes to simplify there use. You can also interface with BSD and Posix code directly. And, as hayesk stated, once you become familiar with the language, the release and retain system really isn't that difficult to use.

As an example, I was able to drop the C version of HTML Tidy in a Mac OS X service to create TidyService. There's no Java Native Interface stubs to deal with, I just copied the C source into my project and called the Tidy API directly. 90% of the Service uses retain/release except when I need to convert between NSStrings and C strings as defined by Tidy.

This positions Objective-C at the sweet spot between high-level, OO languages with garbage collection and low-level languages such as C and C++.
 
bousozoku said:
Microsoft didn't develop OS/2 Warp and that's when IBM added Win16 to OS/2. It also wasn't a compatibility layer, it was Windows 3.1, re-compiled with Watcom C, which meant that it ran faster under OS/2 than it did as a shell over MS-DOS. Each Win3.1 application ran in its own virtual mode process completely safe from the other.

Your OS/2 history is somewhat off. First off, the Win-OS/2 layer was added to OS/2 v2.0 -- OS/2 didn't pick up the "Warp" monicker until OS/2 v3.0 was released. OS/2 v2.1 and v3.0 came in two different versions when it came to Windows compatibility: one which included Win-OS/2 (which was recompiled by IBM), and one which would integrate the Microsoft-built Windows 3.1 into OS/2 automatically.

Each Windows 3.1 application didn't necessarily run within its own virtual machine. The default execute method was to conserve RAM by running Windows applications within a single instance. However, you did have the ability to change this, or mix-and-match to run combinations of applications either wihtin the same VM, or in different VM's, which, considering how unstable Win16 apps could be, and that they used a cooperative multitasking model (whereas OS/2 was preemptive all the way back in '87), was a huge benefit.

(Former IBM'er and OS/2 developer, logged in thanks to BugMeNot).
 
pixelfreak said:
Objective-C is not Java. It's designed for application *and* OS level software, which is usually developed in C.

Objective-C is a superset of C. This means that any valid C code can be mixed directly with Objective-C. There is also a variant called Objective-C++ which allows direct use of C++ code along side with Objective-C.

This gives you access to the staggering amount of code and libraries written in C and C++, some of which have already been wrapped in Objective-C classes to simplify there use. You can also interface with BSD and Posix code directly. And, as hayesk stated, once you become familiar with the language, the release and retain system really isn't that difficult to use.

As an example, I was able to drop the C version of HTML Tidy in a Mac OS X service to create TidyService. There's no Java Native Interface stubs to deal with, I just copied the C source into my project and called the Tidy API directly. 90% of the Service uses retain/release except when I need to convert between NSStrings and C strings as defined by Tidy.

This positions Objective-C at the sweet spot between high-level, OO languages with garbage collection and low-level languages such as C and C++.
Wow, I didn't know Objective-C could be used that way...thanks pixelfreak! Knowing this makes Objective-C development far more appealing...however, I wonder about those C++ developers that will be sorta left out of this. Apple can fix that by supporting Objective-C++, but I don't know how easy or hard that would be to do.
 
Objective-C is not Java. It's designed for application *and* OS level software, which is usually developed in C.

Objective-C is a superset of C. This means that any valid C code can be mixed directly with Objective-C. There is also a variant called Objective-C++ which allows direct use of C++ code along side with Objective-C.

None of which proves that garbage collection isn't a desirable feature in any modern language. As I said, just because Apple hasn't got it, doesn't mean that it isn' a very useful programmers tool.

Objective-C is a superset of C. This means that any valid C code can be mixed directly with Objective-C. There is also a variant called Objective-C++ which allows direct use of C++ code along side with Objective-C.

This gives you access to the staggering amount of code and libraries written in C and C++, some of which have already been wrapped in Objective-C classes to simplify there use. You can also interface with BSD and Posix code directly. And, as hayesk stated, once you become familiar with the language, the release and retain system really isn't that difficult to use.

You can do all that in Java through the JNI, and C# has a native call interface too.
However, the number of frameworks available for Java usually makes direct calls to the OS unnecessary.

This positions Objective-C at the sweet spot between high-level, OO languages with garbage collection and low-level languages such as C and C++.

Whether this is a 'sweet-spot' or not depends on what you're doing. I have to write some rather large applications for my line of work, and the job is certainly alot easier with garbage collection. It's justa housekeeping chore that detracts from the job in hand.

I've looked into the auto release and it certainly looks like a good idea, but since it relies on the programmer for its management, then its certainly not close to a full GC implementation.

I'm sure it works very well, but I notice that even a relative simple(ish) applications like Safari has horrendous memory leak issues. I wonder if proper GC would help stamp some of the problems with it.
 
rayz said:
You can do all that in Java through the JNI, and C# has a native call interface too.
Well, sure, but JNI is terrible awkward to use. Including C code in an Objective C project is as simple as including C code in a C project.
 
rayz said:
I'm sure it works very well, but I notice that even a relative simple(ish) applications like Safari has horrendous memory leak issues. I wonder if proper GC would help stamp some of the problems with it.
That may have more to do with the KHTML back end (C++) than with cocoa.

Cocoa definitely needs memory management, but its not as bad as other languages because Key Value Coding takes care of this, at least at the object level.

Objective-C is actually implemented in C, but the "non-object" parts of the runtime are a question to consider when implementing garbage collection, e.g should structures and arrays also be collected?

Objective-C's pure C heritiage is an advantage, not a hinderance. Objective C is very dynamic and doesn't require type casting for example, so its very easy to bridge to other languages such as Java, Python and C#, its survived this long for the very reason that it actually works and works well.
 
gekko513 said:
Well, sure, but JNI is terrible awkward to use. Including C code in an Objective C project is as simple as including C code in a C project.

Well, I never had too much of a problem with it, and as I said; the huge number of third party Java libraries and the sheer breadth of functionality covered by the standard JDK, means that cover a lot of the OS level stuff doesn't actually require an additional C library anyway.
 
Existing kind-of yellow box

See GNUstep at http://www.gnustep.org/

From the page: "GNUstep is a cross-platform, object-oriented framework for desktop application development. Based on the OpenStep specification originally created by NeXT (now Apple), GNUstep enables developers to rapidly build sophisticated software by employing a large library of reusable software components. GNUstep is used in production environments at several organizations... "

GNUstep provides kind-of Cocoa compatibility framework that allows some Cocoa applications to be easily ported, without rewriting, between OS X, Linux and MS Windows.
 
Wine

People keeping talking about the "Threat of WINE" as if it will allow ANY Windows app run. It doesn't. It's a valiant effort by open source coders to get the APIs working but even under Linux it's at best a cool hack. It is no substitute for Windows, and DarWINE is further back still.
 
Status
Not open for further replies.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.