Yes, this is what they did with Carbon for Classic apps.
This is why I think it would be a great thing to do for MSWin developed apps --> Carbon Apps. Well, you wouldn't need the Windows ported apps to be on par with Cocoa or Carbon apps. Yes, ported apps show the difference in elegance between Windows apps and slick MacOSX apps, but at least you'd increase your software base and remove the arguement that the software isn't avaliable on the mac. Almost all popular games on the mac are Windows ports. What if 90% of Windows games were avaliable on the Mac? Yeah, the games wouldn't be as slick as they would be designed from the ground up.... but at least the public would see them as avaliable on the Mac. They wouldn't even have to bother buying them. It's the "idea" of lack of software that gets a lot of people turned off the mac. Not the actual lack of software. If people saw the OSX icon on the boxes of 90% of the software on the shelves or advertisments, it would go very far in removing the myth that there isn't enough software for the mac. I'm babbling, but do you see my point?
Also, yes, it would be exponentially more difficult... That is why I would consider it a big break through. If it was trivial it would have already been accomplished, if not by Apple by MacSoft... or Metroworks.</strong><hr></blockquote>
The only benefit I see here, is that Macs get more apps available than are currently. The big draw backs I see are:
1)No matter how good this 'converter' is it would still require a lot of reworking for the developer. When I said the conversion would be more difficult than Carbonising, I meant for the devs. Many Classic apps still aren't Carbonised because, as easy as the conversion is in theory, in practice it can still be a lot of work. Cocoa on Windows on the other hand would be a far easier/efficient write-once-run-anywhere solution.
2)The apps would be considered 2nd class apps. Even now, Carbon apps are considered by many to be inferior to Cocoa apps. Even though it has been shown the Carbon API's are every bit as robust as the Cocoa API's, there is still this perception. Image how much worse this perception would be toward these Windows converts. Apple would gain the reputation of having access to many Windows apps, but they would be considered second class versions of the apps.
3)The apps would be written originally for the Windows API's. Apple would have no control over these. Apple loves having control over the API's.
All benefits provided by a Windows to OSX converter, would be provided by a Windows compiler for Cocoa apps, except the issue of re-writes. Cocoa for Windows doesn't deal with these apps, but instead deals with new apps being developed. Develop them with Cocoa once and deploy on multiple platforms.
I am unsure why Quartz has to be such a concern for bringing Cocoa to Windows. Surely, Apple could bring over the bulk of the API's, with the exception of the Quartz API's. The Windows compiler could use the MS compositor. While nowhere close to the complexity or functionality of Quartz, XP uses a pretty advanced imaging process (compared to previous Windows anyways). This would mean devs would have to tweak their Windows compiles, but probably less so than Carboning required, since every API except Quartz related should be able to compile as is.
Other than Quartz, is the a reasonable reason not to put Cocoa on Windows? The advantages seem huge.
Exactly! How do you think DOS was created by Microsoft?
[ 07-12-2002: Message edited by: Jeff Leigh ]</strong><hr></blockquote>
Mebbe you are thinking of Compaq reverse engineering IBM's original ROM...they did it as a clean-room blind reverse engineering, and they were clean legally
Isn't there a clause in the Windows licensing agreement specifically prohibiting reverse compiling/engineering? If so, then wouldn't admitting that you developed your program by reverse engineering a windows program, or someone else proving that you did, mean that you violated your licensing agreement? Then MS could come after you for that? I'm sure such violation is a ridiculous amount like the $100,000 fine on the FBI warnings on movies, per occurance.
Not that this is likely, but if MS wanted to flex on you, wouldn't this be one way that could work?
The only benefit I see here, is that Macs get more apps available than are currently.
</strong><hr></blockquote>
Well, yeah. That IS the only benefit. But getting the Mac a lot more apps is a pretty dang big benefit when a lot of Wintel customers say their decision to not buy a mac was because of lack of software selection.
Of course the truth is likely they can get all the software they need on the Mactinosh. So the decision was based on a perception that lack of software was going to be a problem. The solution is about changing a perception.
[quote]Originally posted by Tulkas:
<strong>
1)No matter how good this 'converter' is it would still require a lot of reworking for the developer. When I said the conversion would be more difficult than Carbonising, I meant for the devs. Many Classic apps still aren't Carbonised because, as easy as the conversion is in theory, in practice it can still be a lot of work.
</strong><hr></blockquote>
Yes. I know this. This is exactly what I'm saying. The 'new' breakthrough converter would actually be a breakthough!
Present converters require a lot of reworking for the developers. The big breakthrough would be a converter that does NOT require much reworking by the developer. There would be nothing new if it still required a lot of reworking... those products exists now. You're right, it would hardly be a David's stone if it was just a release of a product that already exists.
[quote]Originally posted by Tulkas:
<strong>
Cocoa on Windows on the other hand would be a far easier/efficient write-once-run-anywhere solution.
2)The apps would be considered 2nd class apps. Even now, Carbon apps are considered by many to be inferior to Cocoa apps. Even though it has been shown the Carbon API's are every bit as robust as the Cocoa API's, there is still this perception. Image how much worse this perception would be toward these Windows converts. Apple would gain the reputation of having access to many Windows apps, but they would be considered second class versions of the apps.
</strong><hr></blockquote>
I agree with you. They would be second class applications. This is partially a good thing. It gives Mac developers a reason to exist. Mac owners (even converts) would rather have the better application for their machine. Only when there is not an equivelant Mac developed application would you need to purchase the second class windows application. And yes, that would mean that they these 2nd class ports wouldn't get the same sales. Again, that is why it be important that the port was done at super minimal cost. Without that, the whole thing doesn't work.
Again, I am mostly talking about removing a perception. If people walk into Best Buy or CompUSA and see that 90% of the programs also run on MacOS X, I believe it would really give the Mac hardware sells a boost.
The reality would likely be that the typical customer would run AppleWorks or Office v.X, their Internet apps and buy a few games now and then. Possibly buy a few ported applications. Apple is fighting perception problems more than real problems right now in my opinion.
[quote]Originally posted by Tulkas:
<strong>
3)The apps would be written originally for the Windows API's. Apple would have no control over these. Apple loves having control over the API's.
</strong><hr></blockquote>
This is true. But, again, don't forget, I'm talking about Apple writing a super breakthrough porting program. Something much better than currently exists.
Yes. I know this. This is exactly what I'm saying. The 'new' breakthrough converter would actually be a breakthough!
Present converters require a lot of reworking for the developers. The big breakthrough would be a converter that does NOT require much reworking by the developer. There would be nothing new if it still required a lot of reworking... those products exists now. You're right, it would hardly be a David's stone if it was just a release of a product that already exists.
</strong><hr></blockquote>
Apple needed current Mac developers to bring their apps over as fast as possible to OSX. They owned the Classic APIs, and these were their core developers. Carbon was their most important initiative outside of OSX. Getting core Mac apps on OSX was far more important than getting Windows apps on OSX. Yet, even with all these needs, their best effort resulted in Carbonizing. Can you imagine the amount of effort Apple would need to put forth for this Super Windows converter? They don't own the API's, so there would have to be lots of reverse engineering. They would have to expend many, many more resources on this converter than they had to on Carbonizing, yet would see a far lower return for their investment. if the best they could do with their own API's results in devs needing to to much tweaking, I can not imagine them being able to produce a better process for Windows developers. Best outcome? Macs get lots of second class applications and developers stop writing Mac optimized versions of their apps. In the end, consumers realize their Macs can only run wannabe versions of their needed apps, and they go Windows instead.
[quote]Originally posted by IQ78:
<strong>
I agree with you. They would be second class applications. This is partially a good thing. It gives Mac developers a reason to exist. Mac owners (even converts) would rather have the better application for their machine. Only when there is not an equivelant Mac developed application would you need to purchase the second class windows application. And yes, that would mean that they these 2nd class ports wouldn't get the same sales. Again, that is why it be important that the port was done at super minimal cost. Without that, the whole thing doesn't work.
</strong><hr></blockquote>
So, here Apple invests multiple times the resources they invested in Carbon, to allow Windows developers to release second class apps on the Mac? If as you say, these second hand apps would not result in dramatically increase sales for these devs, what is their incentive to use the converter? It seems this would give Windows devs the same ability that Cocoa on Windows would give Mac devs. Except at a far, far higher cost to Apple and at a far lower return for the Windows devs. A Mac dev
using Cocoa, would suddenly see a 25X increase in their potential market, while Windows devs using the converter would see a 1.3X increase in their potential markets.
[quote]Originally posted by IQ78:
<strong>
But, again, don't forget, I'm talking about Apple writing a super breakthrough porting program. Something much better than currently exists.</strong><hr></blockquote>
Here again, I must reinterate the expense for Apple here. Carbon took years and siphoned tonnes of resources from the OSX team. A Super Windows converter would take much more time, cost massively more money and I don't think could hope to produce as good a process as Carbonizing did for Mac developers.
I understand your logic. More Apps mean more sales for Apple, even if they are of lesser quality. But, Apple could have produced a crude version of this by simply implementing a Red Box Windows emulation environment for a relative drop in the bucket compared to the Converter project. Even in the short term, this would have produced the same results as a Converter. However, Apple realised it would effectively kill Mac optimized development. Even many Mac devs would go the route of least resistance and switch to Windows development...their apps would reach a far greater market (25X) and would run on Macs too.
In the end, you and I agree...the best way for Apple to increase applications available for Macs is to give devs an easy way to write once and run on both platforms. I just think that an Apple owned and controlled solution that encourages Mac development first, is a better way to go.
I think Apple's only realistic option for getting more apps
Yeah, Billy Boy bought DOS after he signed a contract to write a DOS for IBM. I don't think the company was called CP/M. Bill did help write a BASIC for the Altair. His one and only actual contribution to the computer intdustry. Of course, Stevie has done even less. Though, there is no doubt which which one of the two 'drove' innovation and which one hitched a ride.
Compaqs story is interesting as well. They were especially careful when hiring people for the reverse engineering jobs. They did super duper background checks and made sure they had NO personal knowledge of IBMs BIOS. Pretty neat. I just wonder if Connectix made sure to do the same thing with Virtual Game Station that allowed them to chew up the Sony lawyers.
I don't know if the company was called CP/M but the operating system that had the original DOS code in it was. Oddly enough that company literally stole the code from someone else, who got it in a shady pub deal from someone else yet again. The guy that should(almost) get the original credit for writing CP/M was a professor way back in the day. Well he got sued several times for publishing portions of the code, but never fought back because he was afraid someone would learn his "dirty little secret". He didn't even write the code, several of his grad students did! He just put it all together and published under his name. Eventually one of the grad students sold the code in that shady pub deal, shady because he didn't own it either. Well the prof eventually became so overcome with guilt he drank himself into his grave, a bit of a local legend out here.</strong><hr></blockquote>
Gary Kildall wrote the original version of DOS called CP/M and sold it through his company called Digital research. IBM approached him first when they needed an OS for their first PC. he sort of rebuffed them, for reasons that are lost in legend. Some say he didn't like their corporate attitude, some say he was out surfing when the IBM execs were schedule to meet him at his home and when his wife explained this, they were insulted and went to Gate for an OS in addition to the language they had agreed to purchase from him (BASIC). Gates had used time on university computers at Harvard to develop BASIC from a version that was in the public domain and sold it. So, he in effect used 'stolen' computer time to develop and 'stolen' language and sell it as his own. When the IBM execs approached him about an OS he fibbed and said he had an OS almost ready. Paul Allen, co-founder of MS then visited Tim Patterson of Seattle Computer, who was developing a knockoff (stolen) version of CP/M called QD-DOS (quick and dirty DOS...dirty cuz it was someone elses work) Says Bill Gates: "We also knew Digital Research wasn't taking IBM seriously enough. So we decided, Why not? It got kind of tense, because there was about a 48-hour period after [Steve] Ballmer and I had officially offered to license QDOS to IBM that we didn't really own it. Paul hadn't yet closed the deal with Seattle Computer, and I was really giving him a really hard time". So, at this point Gates sells a 'stolen' language and a 'stolen' OS, which he didn't have a legal claim to, and the rest is history.
As an interesting aside, Kildall and Gates were close while Bill was at Harvard. Kildall was sort of a mentor for Gates. Gates ultimately played the ultimate Brutus and knife his Caesar right in the back. After many years of lawsuits over DOS, Kildall died, rumor is that he killed himself over this incredible incident, and Gates went on to become the richest man in the world. Ironically, MS benefitted from what was essentially Open Source language and was could be considered a stolen OS, yet now wants to kill the open source movement and is one of the most protective companies of their IP. Too bad they weren't so sensitive out other peoples IP when they were young.
This is true. But, again, don't forget, I'm talking about Apple writing a super breakthrough porting program. Something much better than currently exists.</strong><hr></blockquote>
I don't mean to rain on anyone's parade, but I've been doing software development for almost 20 years now and I can tell you with the greatest of confidence: There is no such thing and there will not be (in our life time).
The simple task of code generation from models is problematic. Now imagine that this converter has to map between operating system API, windowing system behavior, file system differences and it must preserve the application creator's intent.
Actually, software development is more of an art than a hard science. It requires a human to write a piece of code some other human would want to spend money on.
Although Cocoa (NextStep) is a brilliant piece of work Apple still has a lot of work left to do in the documentation department I can assure you. <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" /> Alas, there is no translator on the horizon...
I don't mean to rain on anyone's parade, but I've been doing software development for almost 20 years now and I can tell you with the greatest of confidence: There is no such thing and there will not be (in our life time).
The simple task of code generation from models is problematic. Now imagine that this converter has to map between operating system API, windowing system behavior, file system differences and it must preserve the application creator's intent.
Actually, software development is more of an art than a hard science. It requires a human to write a piece of code some other human would want to spend money on.
Although Cocoa (NextStep) is a brilliant piece of work Apple still has a lot of work left to do in the documentation department I can assure you. <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" /> Alas, there is no translator on the horizon...
Hey you're not ruining my day. Of course there is no such thing. That is why it would be a breakthrough application.
There likely will not be anything in our lifetime. That is also why it would be considered a breakthrough application. Some major insight way different than what is being done now. That is the nature of a major breakthrough... they are considered leaps beyond the current measured progress.
Of course, this reasoning does not support the probability of the exisitance of such technology, in fact, it more states the unlikely nature of it. Breakthrough ideas/technologies are unlikely. So the idea of a super-converter is very unlikely.
Here again, I must reinterate the expense for Apple here. Carbon took years and siphoned tonnes of resources from the OSX team. A Super Windows converter would take much more time, cost massively more money and I don't think could hope to produce as good a process as Carbonizing did for Mac developers.
</strong><hr></blockquote>
I agree. Good point. It was important for them to get a good classic -> carbon converter, and they would have put maximum effort in this. The results were pretty decent but not even good enough to accomplish what I'm talking about.... AND, your right, the task would have been a lot more difficult. The only slight argument in the other direction is that they had more of a time crunch for the classic --> carbon converter, and have had a few years extra (plus the knowledge from the classic -> carbon development). But, I agree, it seems beyond the possibility considering the priority apple would (and should) give it.
[quote]Originally posted by Tulkas:
<strong>
I understand your logic. More Apps mean more sales for Apple, even if they are of lesser quality. But, Apple could have produced a crude version of this by simply implementing a Red Box Windows emulation environment for a relative drop in the bucket compared to the Converter project.
</strong><hr></blockquote>
Yes, I really stand firm on the idea that if the Mac had 80-90% of the Windows applications it would drastically increase mac sales, even if they are lesser quality (but functionality is still there). Now the quality shouldn't be that much less than the Windows application, it just would be less than a comparable MacOSX cocoa application.
You mention emulation, which means that you are still forgetting my point about perception. Emulation does not help with the perception, unless every mac has the emulation (which you did infer), and then it is too slow for many Windows applications AND emulation would decrease the amount of applications ported to the mac (win developers would just say... well, mac users can use their built in 90% of the sotware is Windows (even if it can run on the mac... not changing the perception that there is a lot of software for the mac).
But, the point is mute if it would take an unreasonable amount of resources (even IF it was possible). So, ultimately, you make great points and I agree with you. I just don't agree that emulation could take the place to remove the lack of software perception.
[quote]Originally posted by Tulkas:
<strong>
Even in the short term, this would have produced the same results as a Converter. However, Apple realised it would effectively kill Mac optimized development. Even many Mac devs would go the route of least resistance and switch to Windows development...their apps would reach a far greater market (25X) and would run on Macs too.
</strong><hr></blockquote>
Yeah, This is also a good point. It would somewhat create a no win situation. The better the converter the less incentive mac developers have in using cocoa and developing primarily for the mac. The worse the converter is, the less effective the results are for the win developers.
I guess, I mostly came up with the idea because I agree that a great solution would be write code once and compile for both platforms. But I'm concerned that there would be much motivation for Windows developers to switch to a Cocoa envirenment. Keeping the Mac greatly behind in the avaliability of software. It's not a big deal practically (because macs have plenty of software for 98% of the people), but the perception really hurts Apple sales.
Now, for people who already develop for both, the Cocoa envirenment which could compile to windows would be great. It would keep them faithful to the mac and might even serve as examples to new companies that the cocoa envirenment makes great Windows apps as well as Mac apps, bringing more software developers to the mac. But I don't really see a pure Win developer dropping MS dev tools and switching to apple devepment, especially with MS playing dirty tricks with competing developer envirenments by modifying their new OSes to wreak havik with the non-MS developer tools.
Your proposal is likely the most realistic solution, but not a solution that would result in near par application count on both platforms.
Comments
<strong>Not Apple ants more market share big, or run windoze apps. big, think revolutionize computing.
</strong><hr></blockquote>
Hmm, she's doing word salad... Must be big to bring on a stroke like that.
Computing's a damn tough thing to revolutionize, and doesn't happen often. I hope you're right. This stuff sucks.
<strong>
Hmm, she's doing word salad... Must be big to bring on a stroke like that.
Computing's a damn tough thing to revolutionize, and doesn't happen often. I hope you're right. This stuff sucks.</strong><hr></blockquote>
Sorry I get REALLY excited about this.
<strong>
Yes, this is what they did with Carbon for Classic apps.
This is why I think it would be a great thing to do for MSWin developed apps --> Carbon Apps. Well, you wouldn't need the Windows ported apps to be on par with Cocoa or Carbon apps. Yes, ported apps show the difference in elegance between Windows apps and slick MacOSX apps, but at least you'd increase your software base and remove the arguement that the software isn't avaliable on the mac. Almost all popular games on the mac are Windows ports. What if 90% of Windows games were avaliable on the Mac? Yeah, the games wouldn't be as slick as they would be designed from the ground up.... but at least the public would see them as avaliable on the Mac. They wouldn't even have to bother buying them. It's the "idea" of lack of software that gets a lot of people turned off the mac. Not the actual lack of software. If people saw the OSX icon on the boxes of 90% of the software on the shelves or advertisments, it would go very far in removing the myth that there isn't enough software for the mac. I'm babbling, but do you see my point?
Also, yes, it would be exponentially more difficult... That is why I would consider it a big break through. If it was trivial it would have already been accomplished, if not by Apple by MacSoft... or Metroworks.</strong><hr></blockquote>
The only benefit I see here, is that Macs get more apps available than are currently. The big draw backs I see are:
1)No matter how good this 'converter' is it would still require a lot of reworking for the developer. When I said the conversion would be more difficult than Carbonising, I meant for the devs. Many Classic apps still aren't Carbonised because, as easy as the conversion is in theory, in practice it can still be a lot of work. Cocoa on Windows on the other hand would be a far easier/efficient write-once-run-anywhere solution.
2)The apps would be considered 2nd class apps. Even now, Carbon apps are considered by many to be inferior to Cocoa apps. Even though it has been shown the Carbon API's are every bit as robust as the Cocoa API's, there is still this perception. Image how much worse this perception would be toward these Windows converts. Apple would gain the reputation of having access to many Windows apps, but they would be considered second class versions of the apps.
3)The apps would be written originally for the Windows API's. Apple would have no control over these. Apple loves having control over the API's.
All benefits provided by a Windows to OSX converter, would be provided by a Windows compiler for Cocoa apps, except the issue of re-writes. Cocoa for Windows doesn't deal with these apps, but instead deals with new apps being developed. Develop them with Cocoa once and deploy on multiple platforms.
I am unsure why Quartz has to be such a concern for bringing Cocoa to Windows. Surely, Apple could bring over the bulk of the API's, with the exception of the Quartz API's. The Windows compiler could use the MS compositor. While nowhere close to the complexity or functionality of Quartz, XP uses a pretty advanced imaging process (compared to previous Windows anyways). This would mean devs would have to tweak their Windows compiles, but probably less so than Carboning required, since every API except Quartz related should be able to compile as is.
Other than Quartz, is the a reasonable reason not to put Cocoa on Windows? The advantages seem huge.
[ 07-12-2002: Message edited by: Tulkas ]</p>
<strong>
Exactly! How do you think DOS was created by Microsoft?
[ 07-12-2002: Message edited by: Jeff Leigh ]</strong><hr></blockquote>
Mebbe you are thinking of Compaq reverse engineering IBM's original ROM...they did it as a clean-room blind reverse engineering, and they were clean legally
Isn't there a clause in the Windows licensing agreement specifically prohibiting reverse compiling/engineering? If so, then wouldn't admitting that you developed your program by reverse engineering a windows program, or someone else proving that you did, mean that you violated your licensing agreement? Then MS could come after you for that? I'm sure such violation is a ridiculous amount like the $100,000 fine on the FBI warnings on movies, per occurance.
Not that this is likely, but if MS wanted to flex on you, wouldn't this be one way that could work?
<strong>
The only benefit I see here, is that Macs get more apps available than are currently.
</strong><hr></blockquote>
Well, yeah. That IS the only benefit. But getting the Mac a lot more apps is a pretty dang big benefit when a lot of Wintel customers say their decision to not buy a mac was because of lack of software selection.
Of course the truth is likely they can get all the software they need on the Mactinosh. So the decision was based on a perception that lack of software was going to be a problem. The solution is about changing a perception.
[quote]Originally posted by Tulkas:
<strong>
1)No matter how good this 'converter' is it would still require a lot of reworking for the developer. When I said the conversion would be more difficult than Carbonising, I meant for the devs. Many Classic apps still aren't Carbonised because, as easy as the conversion is in theory, in practice it can still be a lot of work.
</strong><hr></blockquote>
Yes. I know this. This is exactly what I'm saying. The 'new' breakthrough converter would actually be a breakthough!
Present converters require a lot of reworking for the developers. The big breakthrough would be a converter that does NOT require much reworking by the developer. There would be nothing new if it still required a lot of reworking... those products exists now. You're right, it would hardly be a David's stone if it was just a release of a product that already exists.
[quote]Originally posted by Tulkas:
<strong>
Cocoa on Windows on the other hand would be a far easier/efficient write-once-run-anywhere solution.
2)The apps would be considered 2nd class apps. Even now, Carbon apps are considered by many to be inferior to Cocoa apps. Even though it has been shown the Carbon API's are every bit as robust as the Cocoa API's, there is still this perception. Image how much worse this perception would be toward these Windows converts. Apple would gain the reputation of having access to many Windows apps, but they would be considered second class versions of the apps.
</strong><hr></blockquote>
I agree with you. They would be second class applications. This is partially a good thing. It gives Mac developers a reason to exist. Mac owners (even converts) would rather have the better application for their machine. Only when there is not an equivelant Mac developed application would you need to purchase the second class windows application. And yes, that would mean that they these 2nd class ports wouldn't get the same sales. Again, that is why it be important that the port was done at super minimal cost. Without that, the whole thing doesn't work.
Again, I am mostly talking about removing a perception. If people walk into Best Buy or CompUSA and see that 90% of the programs also run on MacOS X, I believe it would really give the Mac hardware sells a boost.
The reality would likely be that the typical customer would run AppleWorks or Office v.X, their Internet apps and buy a few games now and then. Possibly buy a few ported applications. Apple is fighting perception problems more than real problems right now in my opinion.
[quote]Originally posted by Tulkas:
<strong>
3)The apps would be written originally for the Windows API's. Apple would have no control over these. Apple loves having control over the API's.
</strong><hr></blockquote>
This is true. But, again, don't forget, I'm talking about Apple writing a super breakthrough porting program. Something much better than currently exists.
<strong>
Yes. I know this. This is exactly what I'm saying. The 'new' breakthrough converter would actually be a breakthough!
Present converters require a lot of reworking for the developers. The big breakthrough would be a converter that does NOT require much reworking by the developer. There would be nothing new if it still required a lot of reworking... those products exists now. You're right, it would hardly be a David's stone if it was just a release of a product that already exists.
</strong><hr></blockquote>
Apple needed current Mac developers to bring their apps over as fast as possible to OSX. They owned the Classic APIs, and these were their core developers. Carbon was their most important initiative outside of OSX. Getting core Mac apps on OSX was far more important than getting Windows apps on OSX. Yet, even with all these needs, their best effort resulted in Carbonizing. Can you imagine the amount of effort Apple would need to put forth for this Super Windows converter? They don't own the API's, so there would have to be lots of reverse engineering. They would have to expend many, many more resources on this converter than they had to on Carbonizing, yet would see a far lower return for their investment. if the best they could do with their own API's results in devs needing to to much tweaking, I can not imagine them being able to produce a better process for Windows developers. Best outcome? Macs get lots of second class applications and developers stop writing Mac optimized versions of their apps. In the end, consumers realize their Macs can only run wannabe versions of their needed apps, and they go Windows instead.
[quote]Originally posted by IQ78:
<strong>
I agree with you. They would be second class applications. This is partially a good thing. It gives Mac developers a reason to exist. Mac owners (even converts) would rather have the better application for their machine. Only when there is not an equivelant Mac developed application would you need to purchase the second class windows application. And yes, that would mean that they these 2nd class ports wouldn't get the same sales. Again, that is why it be important that the port was done at super minimal cost. Without that, the whole thing doesn't work.
</strong><hr></blockquote>
So, here Apple invests multiple times the resources they invested in Carbon, to allow Windows developers to release second class apps on the Mac? If as you say, these second hand apps would not result in dramatically increase sales for these devs, what is their incentive to use the converter? It seems this would give Windows devs the same ability that Cocoa on Windows would give Mac devs. Except at a far, far higher cost to Apple and at a far lower return for the Windows devs. A Mac dev
using Cocoa, would suddenly see a 25X increase in their potential market, while Windows devs using the converter would see a 1.3X increase in their potential markets.
[quote]Originally posted by IQ78:
<strong>
But, again, don't forget, I'm talking about Apple writing a super breakthrough porting program. Something much better than currently exists.</strong><hr></blockquote>
Here again, I must reinterate the expense for Apple here. Carbon took years and siphoned tonnes of resources from the OSX team. A Super Windows converter would take much more time, cost massively more money and I don't think could hope to produce as good a process as Carbonizing did for Mac developers.
I understand your logic. More Apps mean more sales for Apple, even if they are of lesser quality. But, Apple could have produced a crude version of this by simply implementing a Red Box Windows emulation environment for a relative drop in the bucket compared to the Converter project. Even in the short term, this would have produced the same results as a Converter. However, Apple realised it would effectively kill Mac optimized development. Even many Mac devs would go the route of least resistance and switch to Windows development...their apps would reach a far greater market (25X) and would run on Macs too.
In the end, you and I agree...the best way for Apple to increase applications available for Macs is to give devs an easy way to write once and run on both platforms. I just think that an Apple owned and controlled solution that encourages Mac development first, is a better way to go.
I think Apple's only realistic option for getting more apps
Compaqs story is interesting as well. They were especially careful when hiring people for the reverse engineering jobs. They did super duper background checks and made sure they had NO personal knowledge of IBMs BIOS. Pretty neat. I just wonder if Connectix made sure to do the same thing with Virtual Game Station that allowed them to chew up the Sony lawyers.
<strong>
I don't know if the company was called CP/M but the operating system that had the original DOS code in it was. Oddly enough that company literally stole the code from someone else, who got it in a shady pub deal from someone else yet again. The guy that should(almost) get the original credit for writing CP/M was a professor way back in the day. Well he got sued several times for publishing portions of the code, but never fought back because he was afraid someone would learn his "dirty little secret". He didn't even write the code, several of his grad students did! He just put it all together and published under his name. Eventually one of the grad students sold the code in that shady pub deal, shady because he didn't own it either. Well the prof eventually became so overcome with guilt he drank himself into his grave, a bit of a local legend out here.</strong><hr></blockquote>
Gary Kildall wrote the original version of DOS called CP/M and sold it through his company called Digital research. IBM approached him first when they needed an OS for their first PC. he sort of rebuffed them, for reasons that are lost in legend. Some say he didn't like their corporate attitude, some say he was out surfing when the IBM execs were schedule to meet him at his home and when his wife explained this, they were insulted and went to Gate for an OS in addition to the language they had agreed to purchase from him (BASIC). Gates had used time on university computers at Harvard to develop BASIC from a version that was in the public domain and sold it. So, he in effect used 'stolen' computer time to develop and 'stolen' language and sell it as his own. When the IBM execs approached him about an OS he fibbed and said he had an OS almost ready. Paul Allen, co-founder of MS then visited Tim Patterson of Seattle Computer, who was developing a knockoff (stolen) version of CP/M called QD-DOS (quick and dirty DOS...dirty cuz it was someone elses work) Says Bill Gates: "We also knew Digital Research wasn't taking IBM seriously enough. So we decided, Why not? It got kind of tense, because there was about a 48-hour period after [Steve] Ballmer and I had officially offered to license QDOS to IBM that we didn't really own it. Paul hadn't yet closed the deal with Seattle Computer, and I was really giving him a really hard time". So, at this point Gates sells a 'stolen' language and a 'stolen' OS, which he didn't have a legal claim to, and the rest is history.
As an interesting aside, Kildall and Gates were close while Bill was at Harvard. Kildall was sort of a mentor for Gates. Gates ultimately played the ultimate Brutus and knife his Caesar right in the back. After many years of lawsuits over DOS, Kildall died, rumor is that he killed himself over this incredible incident, and Gates went on to become the richest man in the world. Ironically, MS benefitted from what was essentially Open Source language and was could be considered a stolen OS, yet now wants to kill the open source movement and is one of the most protective companies of their IP. Too bad they weren't so sensitive out other peoples IP when they were young.
<strong>
This is true. But, again, don't forget, I'm talking about Apple writing a super breakthrough porting program. Something much better than currently exists.</strong><hr></blockquote>
I don't mean to rain on anyone's parade, but I've been doing software development for almost 20 years now and I can tell you with the greatest of confidence: There is no such thing and there will not be (in our life time).
The simple task of code generation from models is problematic. Now imagine that this converter has to map between operating system API, windowing system behavior, file system differences and it must preserve the application creator's intent.
Actually, software development is more of an art than a hard science. It requires a human to write a piece of code some other human would want to spend money on.
Although Cocoa (NextStep) is a brilliant piece of work Apple still has a lot of work left to do in the documentation department I can assure you. <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" /> Alas, there is no translator on the horizon...
[ 07-13-2002: Message edited by: iCode ]</p>
<strong>
I don't mean to rain on anyone's parade, but I've been doing software development for almost 20 years now and I can tell you with the greatest of confidence: There is no such thing and there will not be (in our life time).
The simple task of code generation from models is problematic. Now imagine that this converter has to map between operating system API, windowing system behavior, file system differences and it must preserve the application creator's intent.
Actually, software development is more of an art than a hard science. It requires a human to write a piece of code some other human would want to spend money on.
Although Cocoa (NextStep) is a brilliant piece of work Apple still has a lot of work left to do in the documentation department I can assure you. <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" /> Alas, there is no translator on the horizon...
[ 07-13-2002: Message edited by: iCode ]</strong><hr></blockquote>
Hey you're not ruining my day. Of course there is no such thing. That is why it would be a breakthrough application.
There likely will not be anything in our lifetime. That is also why it would be considered a breakthrough application. Some major insight way different than what is being done now. That is the nature of a major breakthrough... they are considered leaps beyond the current measured progress.
Of course, this reasoning does not support the probability of the exisitance of such technology, in fact, it more states the unlikely nature of it. Breakthrough ideas/technologies are unlikely. So the idea of a super-converter is very unlikely.
<strong>
Here again, I must reinterate the expense for Apple here. Carbon took years and siphoned tonnes of resources from the OSX team. A Super Windows converter would take much more time, cost massively more money and I don't think could hope to produce as good a process as Carbonizing did for Mac developers.
</strong><hr></blockquote>
I agree. Good point. It was important for them to get a good classic -> carbon converter, and they would have put maximum effort in this. The results were pretty decent but not even good enough to accomplish what I'm talking about.... AND, your right, the task would have been a lot more difficult. The only slight argument in the other direction is that they had more of a time crunch for the classic --> carbon converter, and have had a few years extra (plus the knowledge from the classic -> carbon development). But, I agree, it seems beyond the possibility considering the priority apple would (and should) give it.
[quote]Originally posted by Tulkas:
<strong>
I understand your logic. More Apps mean more sales for Apple, even if they are of lesser quality. But, Apple could have produced a crude version of this by simply implementing a Red Box Windows emulation environment for a relative drop in the bucket compared to the Converter project.
</strong><hr></blockquote>
Yes, I really stand firm on the idea that if the Mac had 80-90% of the Windows applications it would drastically increase mac sales, even if they are lesser quality (but functionality is still there). Now the quality shouldn't be that much less than the Windows application, it just would be less than a comparable MacOSX cocoa application.
You mention emulation, which means that you are still forgetting my point about perception. Emulation does not help with the perception, unless every mac has the emulation (which you did infer), and then it is too slow for many Windows applications AND emulation would decrease the amount of applications ported to the mac (win developers would just say... well, mac users can use their built in 90% of the sotware is Windows (even if it can run on the mac... not changing the perception that there is a lot of software for the mac).
But, the point is mute if it would take an unreasonable amount of resources (even IF it was possible). So, ultimately, you make great points and I agree with you. I just don't agree that emulation could take the place to remove the lack of software perception.
[quote]Originally posted by Tulkas:
<strong>
Even in the short term, this would have produced the same results as a Converter. However, Apple realised it would effectively kill Mac optimized development. Even many Mac devs would go the route of least resistance and switch to Windows development...their apps would reach a far greater market (25X) and would run on Macs too.
</strong><hr></blockquote>
Yeah, This is also a good point. It would somewhat create a no win situation. The better the converter the less incentive mac developers have in using cocoa and developing primarily for the mac. The worse the converter is, the less effective the results are for the win developers.
I guess, I mostly came up with the idea because I agree that a great solution would be write code once and compile for both platforms. But I'm concerned that there would be much motivation for Windows developers to switch to a Cocoa envirenment. Keeping the Mac greatly behind in the avaliability of software. It's not a big deal practically (because macs have plenty of software for 98% of the people), but the perception really hurts Apple sales.
Now, for people who already develop for both, the Cocoa envirenment which could compile to windows would be great. It would keep them faithful to the mac and might even serve as examples to new companies that the cocoa envirenment makes great Windows apps as well as Mac apps, bringing more software developers to the mac. But I don't really see a pure Win developer dropping MS dev tools and switching to apple devepment, especially with MS playing dirty tricks with competing developer envirenments by modifying their new OSes to wreak havik with the non-MS developer tools.
Your proposal is likely the most realistic solution, but not a solution that would result in near par application count on both platforms.