Dharma: Cocoa on Windows... Again?

[pixelfreak]

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.

Java is great for writing web apps, but has serious problems creating high performance desktop applications and OS level services.

Unless it's written in something other than C (Singularity is still only a research project) non trivial OS level development may require a significant amount of JNI code. There are also performance issues with translating values though the native interface. Unless you're simply making a few calls to a single library, this can be very tedious, error prone and a performance hit.

This is where Cocoa is comes into play. It's much simpler than C++, yet includes dynamic language features from Small Talk that are not available in Java. I'm actually a Java web developer by day, and I've grown to prefer Cocoa over Java in many respects. Especially it's named arguments.

Here's an example.
- - - -

NSMutableDictionary * attributes = [NSMutableDictionary dictionary];

[attributes setValue"http://www.pixelfreak.net" forKey"URL"];
[attributes setValue"pixel at pixelfreak dot net" forKey"email"];

NSLog(@" URL: %@", [attributes valueForKey"URL"]);
NSLog(@" Email: %@", [attributes valueForKey"email"]);

- - - - -

Notice how memory management is invisible in this example. Since I did not create the dictionary directly (it was created using a class method instead), it is returned autoreleased. Unless explicitly requested, the memory of autoreleased objects are reclaimed at the end of the method call.

If I needed to keep a reference to this dictionary beyond the current method call, I would simply call [attributes retain] to increase the objects retain count by one. When I'm done with the object, I simply call [attributes release] to indicate it is no longer needed. When the dictionary's retain count reaches zero, all of it's keys and values are sent a release message and it's memory is reclaimed by the runtime.

When you create objects directly, it's becomes a bit more complex, but it really not that difficult once you understand the conventions.

 

[JFlac]

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.

Well, they have Office working on Linux, they have IE working on Linux, they even have some flavours of Photoshop running on Linux. But I'll give you that they don't always work as well as they work on Windows.

But it just adds strength to the "Threat of WINE" as you call it: half-working Windows apps are IMHO far worse than fully working windows apps. They give that clunky feel to the OS that OS X could live without.

(edited for typos)

 

[isgoed]

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.

No one has mentioned WINE over the last 25 posts. Maybe you have a slow reaction?

Anyway, by your logic it was ok for the Russians (during the cold war) to develop nuclear bombs, because hey!, they are not yet finished. And besides the weapons they do have require submarines and everyone knows how unpleasant living on a submarine is, so we do not have to fear (I am extrapolating the use of VMware and Virtual PC to the cold war).

 

[Blackcat]

Well, they have Office working on Linux, they have IE working on Linux, they even have some flavours of Photoshop running on Linux. But I'll give you that they don't always work as well as they work on Windows.

But it just adds strength to the "Threat of WINE" as you call it: half-working Windows apps are IMHO far worse than fully working windows apps. They give that clunky feel to the OS that OS X could live without.

(edited for typos)

But the point is developers won't drop Mac support or avoid porting to Mac because of WINE as has been suggested. If you can't guarantee it runs you don't risk a support nightmare.

Xcode compiling to Mac and Windows is an excellent way to avoid such problems. No idea if it's true, but as Mac OS is compiled in Xcode, it makes a lot of sense.

 

[Randall]

WINE is really a terrible emulator, I wouldn't be worried about it at all if I were in Apple's shoes. Switching to x86 would potentially allow the actual Windows OS to dual boot with OS X on a Mac. Now that is better then any kind of emulator or substitute for the real thing like Virtual PC attempts to do. Now you can really have the best of both worlds. There are some obscure windows applications that will never be ported over to OS X, and a lot of those applications are used by people for their jobs everyday. (Microsoft Visio for example). A lot of people I know are holding off from switching to Mac for this very reason. Give these people an opportunity to buy a Mac that can dual boot with Windows, and they'll jump all over it. It is the last barrier to break for some people.

 

[rayz]

Java is great for writing web apps, but has serious problems creating high performance desktop applications and OS level services.

Unless it's written in something other than C (Singularity is still only a research project) non trivial OS level development may require a significant amount of JNI code. There are also performance issues with translating values though the native interface. Unless you're simply making a few calls to a single library, this can be very tedious, error prone and a performance hit.

This is where Cocoa is comes into play. It's much simpler than C++, yet includes dynamic language features from Small Talk that are not available in Java. I'm actually a Java web developer by day, and I've grown to prefer Cocoa over Java in many respects. Especially it's named arguments.

Here's an example.
- - - -

NSMutableDictionary * attributes = [NSMutableDictionary dictionary];

[attributes setValue"http://www.pixelfreak.net" forKey"URL"];
[attributes setValue"pixel at pixelfreak dot net" forKey"email"];

NSLog(@" URL: %@", [attributes valueForKey"URL"]);
NSLog(@" Email: %@", [attributes valueForKey"email"]);

- - - - -

Notice how memory management is invisible in this example. Since I did not create the dictionary directly (it was created using a class method instead), it is returned autoreleased. Unless explicitly requested, the memory of autoreleased objects are reclaimed at the end of the method call.

If I needed to keep a reference to this dictionary beyond the current method call, I would simply call [attributes retain] to increase the objects retain count by one. When I'm done with the object, I simply call [attributes release] to indicate it is no longer needed. When the dictionary's retain count reaches zero, all of it's keys and values are sent a release message and it's memory is reclaimed by the runtime.

When you create objects directly, it's becomes a bit more complex, but it really not that difficult once you understand the conventions.

Then why does Safari leak like a sieve? If Apple can't get it right, then I'll probably stick to a full GC implementation, or none at all thanks.

Take your point though, there are a lot of applications that I wouldn't use Java for (device drivers for example!), but I'm running some pretty complex desktop apps that are pure Java, and the speed is close enough to native that I can't tell the difference (I am running it on a suped up Windows box though)

 

[kainjow]

Then why does Safari leak like a sieve? If Apple can't get it right, then I'll probably stick to a full GC implementation, or none at all thanks.

Take your point though, there are a lot of applications that I wouldn't use Java for (device drivers for example!), but I'm running some pretty complex desktop apps that are pure Java, and the speed is close enough to native that I can't tell the difference (I am running it on a suped up Windows box though)

I can't stand not using pointers. I've been doing some C# and .NET coding recently, and it kills me not to be able to pass by reference easily (you can use "ref" but it feels fishy...)

 

[Fukui]

Then why does Safari leak like a sieve? If Apple can't get it right, then I'll probably stick to a full GC implementation, or none at all thanks.

THIS HAS TO DO WITH KHTML (C++) NOT THE COCOA (Objective-C) WRAPPER THAT IS SAFARI.

Safari leaks buckets because Webcore is still a leaky pile of (C++) code.

(Sorry for bold text, just, I already posted this earlier...)

 

[ClimbingTheLog]

I used to do development for a very large Mac shop. There came a time when Windows 3.1 started to be popular, especially through mergers and acquisitions, so there was a need to do cross-platform apps. We used a vendor's toolkit but it was mostly the *****.

Then came Apple with YellowBox for Windows. It was perfect. We'd upgrade our large Mac base to OSX, buying a couple thousand new macs along the way, and have a good development environment for both Windows and Mac users. Everybody was happy.

So, we got started. By this time Windows 95 was going strong and lots of apps were coming in Windows-only, so we had strong need to support both platforms. The users were usually happier on a Mac, so all was well.

Then Apple pulled the plug on YellowBox for Windows. From a business perspective, our course of action wasn't a hard decision. Instead of buying a couple thousand new Macs, a couple thousand new Windows boxes with NT4 were bought instead. The App was ported to MFC and Apple lost a few million dollars on our account that year. I hear this same story over and over again at conferences.

With Macs making a comeback due to the success of OSX we're roughtly in about the same situation now as we were then. I've gone off to Java and wxWindows work, since I need to develop for Linux, MacOS, and once in a while Windows. I'd jump on the AppKit bandwagon again in a heart beat - if there was any kind of guarantee of Lucy not pulling the football out from under me again.

If Apple does allow Windows to run under a paravirtualization mode, this will make data sharing even easier, but I don't know how they'd make that an economically feasible strategy.

I can't stand not using pointers. I've been doing some C# and .NET coding recently, and it kills me not to be able to pass by reference easily (you can use "ref" but it feels fishy...)

Java handles this better. Everything is a reference. Pass-by-value seems silly after a while - we have fast computers now.

 

[pixelfreak]

Java handles this better. Everything is a reference. Pass-by-value seems silly after a while - we have fast computers now.

"Fast" is a relative term. If your talking about web apps or an IDE, yes, Java works well for these types of applications. But if you need to manipulate the bytes of thirty 640x480 images every second, Java certainly isn't "fast enough". Nor would I want my video stream to glitch when the VM decides to perform garbage collection.

Objective-C lets you work at a high-level for your UI yet drop to C or C++ to process video buffers or perform other performance critical tasks if required.

 

[GregA]

Then came Apple with YellowBox for Windows. It was perfect. We'd .... have a good development environment for both Windows and Mac users. <snip>
Then Apple pulled the plug on YellowBox for Windows.

Well you are in an ideal position to answer a question some have posed here.

How much harder was it to develop for "Mac & Windows" than just "Mac"?

 

[ClimbingTheLog]

"Fast" is a relative term. If your talking about web apps or an IDE, yes, Java works well for these types of applications. But if you need to manipulate the bytes of thirty 640x480 images every second, Java certainly isn't "fast enough". Nor would I want my video stream to glitch when the VM decides to perform garbage collection.

Objective-C lets you work at a high-level for your UI yet drop to C or C++ to process video buffers or perform other performance critical tasks if required.

Yeah, what I meant by 'fast' in that context is that the additional overhead of simulating pass-by-value in your own code is almost negligable.

But as to your point about video processing - Java lets you use C or C++ for that kind of stuff too. You build a library and wrap it with a JNI shell. You get the same kind of portability issues as if Java wasn't in the picture, but it's fast and it works. The last app I worked on that used that technique was in the era of 800MHz P3 machines, but even those were fast enough to update the screen at 30fps using Swing and a JNI-wrapped C++ library for the video segment of the screen. This was using the Sun JRE on Windows. The Mac JRE on 10.2 at the time was about 5x slower for the same code.

 

[RacerX]

I used to do development for a very large Mac shop. There came a time when Windows 3.1 started to be popular, especially through mergers and acquisitions, so there was a need to do cross-platform apps. We used a vendor's toolkit but it was mostly the *****.

Then came Apple with YellowBox for Windows. It was perfect...

I must have missed something in this post... the description of events seems pretty far off what actually happened.

Yellow Box for Windows wasn't seeded to developers until 1997, and Apple didn't pull the plug on Yellow Box until WWDC 2000.

More importantly, Yellow Box as a development environment wasn't going to effect Mac users until Mac OS X shipped... and wasn't going to have any effect until everyone had transitioned to Mac OS X. Most people didn't start making the move to Mac OS X until after v10.2 was released (August 2002), which means that even if Apple hadn't pulled the plug, it wasn't going to be an effective Mac/Windows development environment until around 2003.

So why would anyone be talking about this like it was happening in the era of Windows 95 and Windows NT 4.0?

Beyond the fact that the early developer releases ran on Windows 95/NT 4.0, Yellow Box was still a non-factor as a cross platform development environment... specially from the perspective of the Mac community. The only apps that were made cross platform during the short life of Yellow Box were OPENSTEP and Rhapsody apps... nothing that anyone would have considered to be "Mac" apps back in those days.

And I don't see where Apple killing Yellow Box in 2000 would make anyone run out and buy Windows NT 4.0 systems... maybe Windows 2000 Pro, but not NT 4.0. Specially as Microsoft was on the verge of releasing Windows XP.


Maybe you can see where I'm a little confused by your post. It just doesn't square up with the actual timeline of events. And more importantly... no one in the Mac community at the time would have considered it "perfect" because you couldn't make apps for Mac OS 8/9 with it.

Java handles this better. Everything is a reference. Pass-by-value seems silly after a while - we have fast computers now.

It is funny, Apple was really pushing Java along side Objective C in Yellow Box early on. One of the things that most developers hated was how slow the Java based apps were.

For example, Apple remade TextEdit for Rhapsody using Java... which made it really slow compared to the version of TextEdit from OPENSTEP. Finally a number of developers got together and converted it back to Objective C. On my Rhapsody systems that can run the Objective C version (it was only made for the PowerPC version of Rhapsody) I have replaced Apple's TextEdit with the one made by the community.

 

[ClimbingTheLog]

Well you are in an ideal position to answer a question some have posed here.

How much harder was it to develop for "Mac & Windows" than just "Mac"?

It's hard to say - it was a small team so we had a single product that deployed to both platforms and it was a least-common-denominator approach. The app looked bad on both platforms.

The right way to do it would have been to hire one additional programmer, have him do the Windows GUI, put the x-plat GUI guy on a Mac GUI and have the logic be written in something portable (c++ was the only suitable hammer at that time).

So, the overhead would probably have been going from an 8-person team to a 9-person team. The QA I think would have been a wash because you could have used VirtualUser to QA the logic and then do a manual test of Windows GUI widgets. As it was the whole thing was manual, so having a real Mac client would have helped there tremendously.

But for corporate development you have to figure on total costs. So, all those Mac users require less tech support than if they had a Windows box on their desk (about 60% lower cost in my experience). So, enumerated over thousands of users that would have been a net-savings even with the extra programmer.

But there was a need to have Windows for certain "essential" apps and quite a bit of animosity towards Apple for repeatedly scuttling our strategies (we were previously working on an OpenDoc solution). Balmer made a sweaty fool of himself with his Developers Developers Developers dance, but he wasn't wrong.

 

[Sunrunner]

It's hard to say - it was a small team so we had a single product that deployed to both platforms and it was a least-common-denominator approach. The app looked bad on both platforms.

The right way to do it would have been to hire one additional programmer, have him do the Windows GUI, put the x-plat GUI guy on a Mac GUI and have the logic be written in something portable (c++ was the only suitable hammer at that time).

So, the overhead would probably have been going from an 8-person team to a 9-person team. The QA I think would have been a wash because you could have used VirtualUser to QA the logic and then do a manual test of Windows GUI widgets. As it was the whole thing was manual, so having a real Mac client would have helped there tremendously.

But for corporate development you have to figure on total costs. So, all those Mac users require less tech support than if they had a Windows box on their desk (about 60% lower cost in my experience). So, enumerated over thousands of users that would have been a net-savings even with the extra programmer.

But there was a need to have Windows for certain "essential" apps and quite a bit of animosity towards Apple for repeatedly scuttling our strategies (we were previously working on an OpenDoc solution). Balmer made a sweaty fool of himself with his Developers Developers Developers dance, but he wasn't wrong.

The key is using portable code. Shortsighted developers that just pull out VB and other similar nonsense because they think the initial development may be easier end up shooting themselves in the foot when it comes to porting their software...

 

[GregA]

But there was a need to have Windows for certain "essential" apps and quite a bit of animosity towards Apple for repeatedly scuttling our strategies (we were previously working on an OpenDoc solution). Balmer made a sweaty fool of himself with his Developers Developers Developers dance, but he wasn't wrong.

Thanks for the info. I've assumed this stuff happened over several years for you - hence the Windows 3.1 references.

For the record, MS also promised a cross platform development environment, I believe it was using Visual Basic (though may have had C in there). I know this because I looked into this for my father's company, whose parent company was about to invest in some Mac programmers and the MS announcement scuttled that. It would have been around 1999 iirc.

 

[ClimbingTheLog]

I must have missed something in this post... the description of events seems pretty far off what actually happened.

Well, it was a summary, not a 20 page recital. No doubt some details got lost in the mix.

Yellow Box for Windows wasn't seeded to developers until 1997, and Apple didn't pull the plug on Yellow Box until WWDC 2000.

Right, this was c. 98 that we started looking at it seriously. I went to all the WWDC '98 sessions on it.

Most people didn't start making the move to Mac OS X until after v10.2 was released (August 2002), which means that even if Apple hadn't pulled the plug, it wasn't going to be an effective Mac/Windows development environment until around 2003.

You're stretching for a conspiracy theory. We were ready to jump on Mac OS 10.0.0.

So why would anyone be talking about this like it was happening in the era of Windows 95 and Windows NT 4.0?

That's what was around in 1998. Windows 95/98 - same difference and NT 4. By 2000 Windows NT 4 was heavily entrenched in the corporate environment. Win2K had just come out (Feb 2000) and had high CPU requirements (350MHz+) and corporations weren't rushing to get in line.

Beyond the fact that the early developer releases ran on Windows 95/NT 4.0, Yellow Box was still a non-factor as a cross platform development environment... specially from the perspective of the Mac community. The only apps that were made cross platform during the short life of Yellow Box were OPENSTEP and Rhapsody apps... nothing that anyone would have considered to be "Mac" apps back in those days.

And what does that have to do with corporate development?

And I don't see where Apple killing Yellow Box in 2000 would make anyone run out and buy Windows NT 4.0 systems... maybe Windows 2000 Pro, but not NT 4.0. Specially as Microsoft was on the verge of releasing Windows XP.

NT4 had already made significant inroads. Corps like standardization. And XP didn't come out until the end of 2001.

no one in the Mac community at the time would have considered it "perfect" because you couldn't make apps for Mac OS 8/9 with it.

Apple had privately committed to an OS 8 version of YellowBox c. 1998.

It is funny, Apple was really pushing Java along side Objective C in Yellow Box early on. One of the things that most developers hated was how slow the Java based apps were.

Right - Steve Jobs declared that the Mac would be the best Java platform ever. Pfft. Ya, right. Are we seeing a pattern here? How's that Java Object Bridge doing these days? I believe Apple will keep Cocoa on Objective-C on Mac OS X alive for the forseeable future. Everything else is subject to being cancelled. Firm committments from Apple to the contrary would be welcome.

 

[RacerX]

Well, it was a summary, not a 20 page recital. No doubt some details got lost in the mix.

Apparently. I guess I'm just not used to people shuffling events to such a degree. Specially someone who was there.

Right, this was c. 98 that we started looking at it seriously. I went to all the WWDC '98 sessions on it.

I still have quicktime versions of all the sessions from WWDC 98, it was quite a conference.

Of course the fact that you were there and still seem to have the history that far off is even more puzzling than if you had just been looking into developing with Yellow Box. But I guess mixing details will do that.

You're stretching for a conspiracy theory. We were ready to jump on Mac OS 10.0.0.

Really? See I've been a long time NEXTSTEP, OPENSTEP, Rhapsody and Mac OS X user, and even though I've had a system with Mac OS X installed on it continuously since Developer Preview 4 (and was using Rhapsody as a daily OS at that time) I didn't move to Mac OS X as my main system until 10.2... and I still use mostly the same titles of software that I do in Rhapsody and OPENSTEP, which were all available for 10.0.0. That still didn't make 10.0.0 a usable system. The main drawback with 10.0/10.1 was that Apple hadn't finished working out most of the bugs in Carbon (so the Finder was painful) and in Quartz (which was still a work in progress compared to Display Postscript on my Rhapsody and OPENSTEP systems).

Sorry, no conspiracy theory needed here... just the facts of the development process.

That's what was around in 1998. Windows 95/98 - same difference and NT 4. By 2000 Windows NT 4 was heavily entrenched in the corporate environment. Win2K had just come out (Feb 2000) and had high CPU requirements (350MHz+) and corporations weren't rushing to get in line.

By 2000 the lack of native USB support in NT 4.0 had started pushing it out of the workstation market and the only place it remained strong was in the server market (part of the reason Microsoft bought VirtualPC was to give people the ability to run NT 4.0 Server as a virtual system on newer hardware that NT 4.0 could not be installed on).

Buying NT 4.0 licenses in 2000 wasn't what I would call a smart strategy.

Besides, by 2000 a 350 MHz PC was common... that was the standard speed for a low end Gateway in 1999 (I know because I was working with a company back then that bought a ton of them).

And what does that have to do with corporate development?

(with reference to:"The only apps that were made cross platform during the short life of Yellow Box were OPENSTEP and Rhapsody apps... nothing that anyone would have considered to be "Mac" apps back in those days.")

Why would you need a Mac that could only run a single custom app and no other software that Mac users were used to? What would be the point of such a deployment?

Other than data entry, most positions that require a computer make use of a lot of shrink wrapped software running right next to custom developed software. If you are talking about strictly data entry... why use Macs? Cheep PCs running Linux would be a better choice (even back in 1998/99).

NT4 had already made significant inroads. Corps like standardization. And XP didn't come out until the end of 2001.

And yet today most corporations and government agencies are still using 2000 as their primary OS... mainly because most of them moved to 2000 early on and XP didn't hold enough advances over 2000 to justify another transition.

Which comes back to the question... who would have been buying NT 4.0 systems in 2000?

Apple had privately committed to an OS 8 version of YellowBox c. 1998

Odd. Apple had planned a quick move to Rhapsody, and hadn't been worried about backwards compatibility of Rhapsody apps at the time... at least that is what I had gotten from Apple back then.

Apple was under the control of people who had not gone through the Copland project, so they didn't know that Apple had already run through this very same scenario already.

Developers had come back to Apple early on in Copland and said that they would not rewrite their apps for the new operating system. This had forced Apple to rework the application environment for Copland to use most of the Macintosh Toolbox APIs.

When Apple ran into this again with developers, they (mistakenly) thought that the solution was already pretty close to complete. Apple had used MAE to create Blue Box, they could take the Copland APIs and use them to make Carbon. This was why Apple gave unrealistic release dates for Mac OS X, they thought it was closer to being finished than it actually was.

Of course you already knew that. You were there when Apple demoed the first version of Rhapsody with Carbon. And you were there when the head of Adobe's Photoshop development told everyone that he had ported Photoshop 5.0 to Carbon in under two weeks, and then showed Photoshop 5.0 running in Rhapsody as a native Carbon app.

But I have no idea who would have privately told you that a version of Yellow Box was going to be ported to Mac OS 8... unless it was someone from Mac OS 8 development wishfully thinking that this would extend it's life a little longer (which wasn't needed, as the delays with Carbon would successfully do that).

Right - Steve Jobs declared that the Mac would be the best Java platform ever. Pfft. Ya, right. Are we seeing a pattern here? How's that Java Object Bridge doing these days? I believe Apple will keep Cocoa on Objective-C on Mac OS X alive for the forseeable future. Everything else is subject to being cancelled. Firm committments from Apple to the contrary would be welcome.

And are not coming.

Apple has pretty much ended Java as a Cocoa development language. They are not going to make anymore advances with Java within Cocoa and have told developers (I assume like you) not to continue to develop Cocoa apps using Java as the feature set is not going to continue to increase with that of Objective C.

I'm seeing a pattern... but not with Apple.


Yellow Box as a cross platform development/deployment environment for both Macs and Windows systems wasn't anything that I would have tried to sell to corporate software developers. Even at the time when Apple had still planned a public release of Rhapsody. Without either a Mac OS 8 version of Yellow Box (which never existed) or a shipping version of Rhapsody/Mac OS X, Yellow Box had no market.

Besides, You really didn't need Yellow Box to deploy that environment on Windows... Apple continued to sell OpenStep Enterprise for Windows until about 2000... I've had no problems running OpenStep apps for Windows in Yellow Box DR2 and WebObjects 4.x for Windows. Might not have made any difference in compatibility with Macs (which just didn't exist back then, contrary to your original assertions... which was mainly what I took issue with), but it was available.

 

[ClimbingTheLog]

The main drawback with 10.0/10.1 was that Apple hadn't finished working out most of the bugs in Carbon (so the Finder was painful) and in Quartz (which was still a work in progress compared to Display Postscript on my Rhapsody and OPENSTEP systems)....Why would you need a Mac that could only run a single custom app and no other software that Mac users were used to? What would be the point of such a deployment?

That's what the BlueBox was for.

By 2000 the lack of native USB support in NT 4.0 had started pushing it out of the workstation market and the only place it remained strong was in the server market

I'm not sure what kind of corporations you're used to working in but they're very different from the ones I've worked in. Even today, most corporate PC's I work with are still using PS/2 keyboards and mouses with _new_ computers. They're cheaper to manufacture so that's what comes with the computer. The only reason for USB ports for them is the occasional scanner or a USB pen drive. Clearly different worlds. Besides, both Compaq and HP were shipping USB stacks for NT 4.

Buying NT 4.0 licenses in 2000 wasn't what I would call a smart strategy.

What would you buy in January 2000 for a multi-thousand client site? Win2K licenses that aren't available? Or do you just think it's a good idea to launch whole-hog into a brand-new Microsoft OS? There was even a policy there not to evaluate a new Microsoft OS until SP1.

Besides, by 2000 a 350 MHz PC was common... that was the standard speed for a low end Gateway in 1999 (I know because I was working with a company back then that bought a ton of them).

And corporations typically have a 3-5 year PC replacement cycle. In a big company you have standard builds - you don't just deploy whatever happens to come in from Dell that week, you standardize as much as possible across your fleet, as you mention later on.

And yet today most corporations and government agencies are still using 2000 as their primary OS... mainly because most of them moved to 2000 early on and XP didn't hold enough advances over 2000 to justify another transition. Which comes back to the question... who would have been buying NT 4.0 systems in 2000?

Wait - buying NT4 licenses in 2000 was crazy, despite the fact that 2000 hadn't shipped yet but buying 2000 licenses in 2006 makes sense? I can't keep up.

But I have no idea who would have privately told you that a version of Yellow Box was going to be ported to Mac OS 8... unless it was someone from Mac OS 8 development wishfully thinking that this would extend it's life a little longer (which wasn't needed, as the delays with Carbon would successfully do that).

When you say "I have no idea who would have.." you suggest that you would have been in a position to have known about it. Are you a former NeXT'er at Apple? If so, step forward because you would have known what was really going on at the time. All I have is what Apple was telling us.

Anyway, it was this guy called Avie Tevanian. If you work at Apple you probably would have heard of him.

Let's go to Google and see what we can find. Ah, here we go. At:
http://www.javaworld.com/javaworld/jw-06-1997/jw-06-idgns.apple.html

Aside from supporting Java, Yellow Box will also support applications development using C++, C, and Objective C programming languages, Tevanian said. As for the future of the Mac OS following the release of Rhapsody, Apple will continue a dual operating system strategy. "We have no plans to replace the Mac OS with Rhapsody," said Tevanian. Yellow Box will also run on Allegro, the follow-on release to Mac OS 8 scheduled for introduction in July.

Yellow Box as a cross platform development/deployment environment for both Macs and Windows systems wasn't anything that I would have tried to sell to corporate software developers. Even at the time when Apple had still planned a public release of Rhapsody. Without either a Mac OS 8 version of Yellow Box (which never existed) or a shipping version of Rhapsody/Mac OS X, Yellow Box had no market. ... Might not have made any difference in compatibility with Macs (which just didn't exist back then, contrary to your original assertions... which was mainly what I took issue with)

So you weren't in Apple Enterprise Sales because that's what they were selling. If you know that Yellow Box for Allegro never existed, then you can prove that they were bald-faced lying to us. But we, as customers, didn't have your level of insider information and assumed they weren't lying.

If you aren't/weren't an Apple insider please let us know that so we can live with the comfort that the Apple Enterprise Sales Team wasn't actually selling us complete fabrications.

 

[RacerX]

That's what the BlueBox was for.

When was the last time you used Blue Box?

Blue Box provided an environment that is about as integrated into Rhapsody as Windows is in the Mac OS while running in VirtualPC. If Blue Box was any type of solution for Mac OS apps in Rhapsody, then I wouldn't have a need for a dedicated Mac OS 8.6 system. But Blue Box is in no way a replacement for a stand alone Mac OS system... which is why I tend to use Blue Box very sparingly on my systems today.

Apple made major advances when developing Classic, which is a far better environment than Blue Box was.

I'm not sure what kind of corporations you're used to working in but they're very different from the ones I've worked in.

Fair enough.

Besides, both Compaq and HP were shipping USB stacks for NT 4.

USB was not supported by Microsoft in NT 4.0. Which made any USB solution in NT 4.0 little more than a hack... which is never good for an IT department.

What would you buy in January 2000 for a multi-thousand client site? Win2K licenses that aren't available?

Why are you talking about January 2000?

Lets refresh your memory... You said:

"Then Apple pulled the plug on YellowBox for Windows. From a business perspective, our course of action wasn't a hard decision. Instead of buying a couple thousand new Macs, a couple thousand new Windows boxes with NT4 were bought instead."​

That puts us in June/July of 2000 (assuming that you turned around and placed the orders within a couple weeks of Apple pulling the plug on Yellow Box for Windows).

And if you did your major purchases in January (as you seem to be pushing that month) then the change due to Yellow Box would have effected the January 2001 purchases.

Wait - buying NT4 licenses in 2000 was crazy, despite the fact that 2000 hadn't shipped yet but buying 2000 licenses in 2006 makes sense? I can't keep up.

The problem is that you don't have your dates right... otherwise you would have no problem both telling us your original story and arguing these finer points.

When you say "I have no idea who would have.." you suggest that you would have been in a position to have known about it. Are you a former NeXT'er at Apple?

Yes, I've been in a very good position (both then and now to a degree) to know these types of things.

No, I do not, and have never, work for Apple Computer. And no, I would never work for Apple Computer... specially knowing what I know.

I'm close friends with people who worked for both NeXT and Apple (some have since left) and of former third party NeXT developers who are now working at Apple.

... Of course these days information from inside Apple isn't very free flowing. But back in the days of the merger through to the release of Mac OS X people I knew felt free to talk about most of these issues (and their frustrations) within Apple.

If so, step forward because you would have known what was really going on at the time. All I have is what Apple was telling us.

Anyway, it was this guy called Avie Tevanian. If you work at Apple you probably would have heard of him.

I'm pretty sure I've heard of Avie Tevanian.

Avie has been there pretty much from the start of NeXT... but in May of 1997 the merger of Apple and NeXT wasn't completed and NeXT software engineers (like Avie) who had never worked with the Mac OS had tons of big plans that were quickly sidelined.

You want to know what was going on in Apple at the time... Okay.

After the merger the NeXT'er quickly found out that they were now under the same pressure that the former Copland development team had been under, which was to produce a product quickly. This changed the focus from developing new technologies to finding new uses for old technologies to save time. Blue Box was developed from the foundations of MAE, Carbon was developed from the Copland API, Yellow Box was a modified version of the OpenStep APIs. Anything that would have meant starting from scratch was scrapped (ie Yellow Box for Mac OS 7/8). Anything that couldn't guaranty a return was scrapped or sidelined (ie Yellow Box for Solaris and HP/UX). Everything became focused. The only reason Yellow Box for Windows survived as long as it did was because it was the same environment as WebObjects for Windows.

The other thing was that Apple wanted to relieve itself of licensing ties that had kept the cost of NEXTSTEP/OPENSTEP so high (noting that the price was already artificially high to make sure that NEXTSTEP/OPENSTEP wasn't sold in the desktop market as per the settlement agreement with Apple back in 1986). Rhapsody still had all these licensing ties which made it expensive (compared to Mac OS 8). When Apple was force to take the time to add Carbon to Mac OS X, they took that time to remove as many thing of that nature from the system as possible (which lead to Darwin) and they decided that Display Postscript was a little too expensive to continue using.

Because Display Postscript was jointly developed between NeXT and Adobe, Apple now had the back ground to reinvent this wheel... using the license free PDF standard rather than Postscript.

Another important behind the scenes development was that the big name developers didn't trust Apple when it came to Carbon. They felt that Carbon was going to be a second class environment compared to Cocoa. So to prove to developers that Apple believed in Carbon as much as Cocoa they decided to base the most important application in the system on Carbon... the Finder. Of course, Carbon wasn't ready for prime time when Mac OS X shipped (and the Finder showed this weakness off in spades), but by the time 10.2 was release Carbon had become a virtual equal to Cocoa as Apple had promised.

So you weren't in Apple Enterprise Sales because that's what they were selling. If you know that Yellow Box for Allegro never existed, then you can prove that they were bald-faced lying to us. But we, as customers, didn't have your level of insider information and assumed they weren't lying.

If you aren't/weren't an Apple insider please let us know that so we can live with the comfort that the Apple Enterprise Sales Team wasn't actually selling us complete fabrications.

The sales team at Apple Enterprise back then was manned by NeXT employees. Apple Enterprise was NeXT Software. It sold WebObjects 3.x, OPENSTEP 4.2, Enterprise Objects Frameworks 2.x, Portable Distributed Objects 4.x, and OpenStep Enterprise for Windows, Solaris and HP/UX.

If they were telling you that there was going to be a version of Yellow Box for the Mac OS... then they were pretty far off the mark. But Apple did keep a lot of people in the Enterprise/WebObjects division out of the loop on a lot of things. It was a constant complaint from 1997 to around 2001. There was a lot of bitterness within Apple and lines of communication were often sabotaged. This, more than any other factor, hurt the continuing growth of the Enterprise/WebObjects division... which was winning tons of software awards, yet was having a hard time winning new clients.

The Enterprise/WebObjects division had a massive head start on everyone else in the industry in 1997... and it was lost do to the mismanagement during that period.

I wouldn't characterize it as bald-faced lying, it was more like they were severely crippled when it came to information within their own company.

It wasn't a pretty thing to watch back then... and it's not a pleasant thing to talk about now.

Currently, I don't see (or hear) of that type of bitterness at Apple anymore. Which is most likely why the company has been doing so much better. But between 1997 and 2002 there was a lot of bitterness.

I hope that covers most of your questions about what was going on in the background back then. And gives a little insight into was happening and what was motivating choices made at the time.

 

[rayz]

It is funny, Apple was really pushing Java along side Objective C in Yellow Box early on. One of the things that most developers hated was how slow the Java based apps were.

The problem wasn't Java; it was the bridge. It was just too slow to be of any use.

Right - Steve Jobs declared that the Mac would be the best Java platform ever. Pfft. Ya, right. Are we seeing a pattern here? How's that Java Object Bridge doing these days? I believe Apple will keep Cocoa on Objective-C on Mac OS X alive for the forseeable future. Everything else is subject to being cancelled. Firm committments from Apple to the contrary would be welcome.

I think this is the main reason why could never bring myself to develop fo Mac boxes. Too many strategic reversals, changes of direction and restarts.

Like using other folks stuff though ...

 

[steeldrivingjon]

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.

There's a word for any programmer for whom learning Objective-C is an obstacle: wuss.

Learning *any* language is a small effort. The main difficulty is learning the class frameworks, APIs, build environment, and idioms. That mass of information dwarfs the piddling amount of learnin' needed to master the use of square brackets in Objective-C message passing, which is about all that you need to know to start with Objective-C.

The challenge in moving to Mac is not learning square brackets. It's learning the APIs. The difficulty would be virtually identical if Apple switched Cocoa to C++ or Java, because Apple would not be using the same class frameworks that people know from Java or Windows or Unix.

 

[steeldrivingjon]

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.

I think you significantly overstate the difference between YellowBox for Windows and OpenStep Enterprise for Windows. They were essentially the same product.

Secondly, the "simply ticking a check box" thing hardly worked in NEXTSTEP/OPENSTEP/Rhapsody when dealing with different hardware platforms,

Hardly worked? This is a wild exaggeration. It worked brilliantly. If it 'hardly worked', the NeXT-oriented software ftp sites would not have been populated by lots of quad-fat software.

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.

This, however is true. There was no checkbox. You could not cross-build: a Windows build had to be done on a Windows box. Lots of time was certainly required, using IB and the other rather clunky OpenStep development apps on NT.

On the other hand, it worked well enough, once you had the required header-file cruft in place for Windows. I worked on a trading system in the late 90s, with my main development machine being an OpenStep/Mach box, and a second machine for doing OpenStep/Windows-specific work and testing when necessary. At that point the app was deployed to trading desks on Windows; in fact, it was deployed via Citrix. (I always found it surprising that that even worked.)

 

[rayz]

There's a word for any programmer for whom learning Objective-C is an obstacle: wuss.

Learning *any* language is a small effort. The main difficulty is learning the class frameworks, APIs, build environment, and idioms. That mass of information dwarfs the piddling amount of learnin' needed to master the use of square brackets in Objective-C message passing, which is about all that you need to know to start with Objective-C.

The challenge in moving to Mac is not learning square brackets. It's learning the APIs. The difficulty would be virtually identical if Apple switched Cocoa to C++ or Java, because Apple would not be using the same class frameworks that people know from Java or Windows or Unix.

I don't think that learning a new language/API is the problem; most developers I come across enjoy that. But they won'rt do it unless they think its worth the effort. ObjectiveC/Cocoa is not really used anywhere outside the Mac, so for a lot of developers, it's probably not worth spending the effort on, even if it is as good as Mac developers say it is.

 

[RacerX]

I think you significantly overstate the difference between YellowBox for Windows and OpenStep Enterprise for Windows. They were essentially the same product.

I don't think I overstated anything... I've even said within my posts that apps written for OpenStep Enterprise for Windows generally run just fine in Yellow Box for Windows.

But Yellow Box is different from OpenStep. Yellow Box as an application environment in Rhapsody is significantly different from the application environment in OPENSTEP.

And as I said... the term Yellow Box wasn't a NeXT term, it was an Apple term.

Hardly worked? This is a wild exaggeration. It worked brilliantly. If it 'hardly worked', the NeXT-oriented software ftp sites would not have been populated by lots of quad-fat software.

Well, I'm a current user of this software and these environments. I run two of the most visited and referenced sites in the NEXTSTEP/OPENSTEP and Rhapsody communities. We are talking about systems I use as much today as most Mac users use Macs today.

So, pardon me if I take your statements in the same way that I would a Windows user who once used a Mac trying to tell me how things really are on Macs.

I stand by what I said... because the facts uphold it. The population of quad-fat software was painfully sad. I have had SPARC and HP systems up and running... and had almost no software to run on them. They were over looked by developers because most couldn't afford to have one of those systems around for testing.

And until you have actually tried the check box, you should refrain from making wild exaggerations like "It worked brilliantly"... which only underscores the fact that you shouldn't be speaking on the subject to begin with.

It worked... okay, but only on the simplest of apps. But once the apps became more complex, it wasn't that straight forward.

But why listen to me... I've only been working with this line of software for the last 15 years or so. You should run out, get a SPARC or HP system, put this to the test. That's what I did. Take and see just how much (or how little) software there is for these platforms. See how easy it is to compile source that isn't set up for those platforms to make an app.

I'll tell you what you'll find... most apps are for 68k and Intel systems. Towards the end, the balance was towards Intel systems. And even when developers were nice enough to include source code, it most often didn't work on platforms they didn't have to begin with.

On the Rhapsody side, I've been given source code for many apps that were made for PowerPC... and no amount of checking of the "Intel" box makes them run on the Intel version of Rhapsody.

On the other hand, it worked well enough, once you had the required header-file cruft in place for Windows. I worked on a trading system in the late 90s, with my main development machine being an OpenStep/Mach box, and a second machine for doing OpenStep/Windows-specific work and testing when necessary...

Well enough for certain classes of apps... and not for others.

There was a reason that this was used in some areas and not others. I can tell you that the porting of Create to Windows wasn't that straight forward. And OmniWeb, have you ever even tried OmniWeb for Windows... I don't know anyone who was able to get it to run correctly. And TIFFany, do you honestly think that porting it to Windows made it's developers think the system worked "well enough"?

It work well enough when you were writing the front end to a database... but real apps that had to stand on their own, it was quite a headache.

You would have gotten less of an argument from me if you would have used your "well enough" in place of your "worked brilliantly" earlier.


Yeah, if the last time you spent any time on an OPENSTEP box was in the late 90's and your statements are that far off the mark... I'd say time has greatly clouded your memory. I use this stuff today, I use it every day. Sorry, this is no faint and distant memory for me, these environments are as current to me now as Mac OS X is.

But feel free to join in with the community. There are still a number of us who are very active. And many of the developers of software from back then have given me permission to provide the community with license strings for their software.

... just don't take your own "it worked brilliantly" statement to heart and try setting up a SPARC or HP system, you'll end up disappointed.