<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: WWDC 2008: Is Mac OS X 10.6 the Death of Carbon?</title>
	<atom:link href="http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/</link>
	<description>Daniel Eran Dilger in San Francisco</description>
	<lastBuildDate>Sun, 05 Feb 2012 17:03:33 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mac OS Rumors</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-20535</link>
		<dc:creator>Mac OS Rumors</dc:creator>
		<pubDate>Tue, 08 Sep 2009 23:46:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-20535</guid>
		<description>[...] frameworks in OS X weren&#8217;t available anywhere but Carbon, in particular Quicktime. And as Daniel Eran Dilger of Roughly Drafted points out, these 2 APIs aren&#8217;t really in competition with each other as some would like to [...]</description>
		<content:encoded><![CDATA[<p>[...] frameworks in OS X weren&#8217;t available anywhere but Carbon, in particular Quicktime. And as Daniel Eran Dilger of Roughly Drafted points out, these 2 APIs aren&#8217;t really in competition with each other as some would like to [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: tecosystems &#187; On GNOME: Gruber&#8217;s Wrong, But That Doesn&#8217;t Make Me Right</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-15162</link>
		<dc:creator>tecosystems &#187; On GNOME: Gruber&#8217;s Wrong, But That Doesn&#8217;t Make Me Right</dc:creator>
		<pubDate>Tue, 14 Oct 2008 22:17:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-15162</guid>
		<description>[...] their issues - ABI breakage, redundancy and so on. But what platform&#8217;s API story is perfect? Carbon vs Cocoa, [...]</description>
		<content:encoded><![CDATA[<p>[...] their issues &#8211; ABI breakage, redundancy and so on. But what platform&#8217;s API story is perfect? Carbon vs Cocoa, [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: I know What I want! &#124; byJoeyBaker</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-10272</link>
		<dc:creator>I know What I want! &#124; byJoeyBaker</dc:creator>
		<pubDate>Thu, 03 Jul 2008 04:28:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-10272</guid>
		<description>[...] has had the ability to leverage the GPU from it&#8217;s first launch, Carbon is on it&#8217;s way out, and Photoshop is facing all sorts of problems because Adobe hasn&#8217;t ported it over [...]</description>
		<content:encoded><![CDATA[<p>[...] has had the ability to leverage the GPU from it&#8217;s first launch, Carbon is on it&#8217;s way out, and Photoshop is facing all sorts of problems because Adobe hasn&#8217;t ported it over [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Myths of Snow Leopard 5: No Carbon! &#8212; RoughlyDrafted Magazine</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9972</link>
		<dc:creator>Myths of Snow Leopard 5: No Carbon! &#8212; RoughlyDrafted Magazine</dc:creator>
		<pubDate>Wed, 25 Jun 2008 14:48:35 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9972</guid>
		<description>[...] WWDC 2008: Is Mac OS X 10.6 the Death of Carbon? [...]</description>
		<content:encoded><![CDATA[<p>[...] WWDC 2008: Is Mac OS X 10.6 the Death of Carbon? [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AppleMania.info » Mac OS X Snow Leopard terá, sim, muitos novos recursos</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9950</link>
		<dc:creator>AppleMania.info » Mac OS X Snow Leopard terá, sim, muitos novos recursos</dc:creator>
		<pubDate>Wed, 25 Jun 2008 03:05:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9950</guid>
		<description>[...] Será isso resultado apenas da otimização de código e compartilhamento de recursos? Um dos fatores provavelmente está relacionado à Independência de Resolução, que substitui gráficos em bitmaps (que definem cada pixel) por arquivos de vetores gráficos menores (que desenham elementos e controles na interface por receita). (&#8230;) As dramáticas reduções de tamanho nessas aplicações devem envolver também localização mais eficiente. Por exemplo, o Mail do Mac OS X Leopard atualmente pesa mais de 285 MB, mas a maior parte desse peso vem de 18 localizações [idiomas] dentro da aplicação, que consomem 276 MB. O código Binário Universal de verdade tem apenas alguns megabytes e mesmo os gráficos associados e outros recursos somam somente 2,8 MB. Por que a Apple por padrão embute suporte a 18 ou mais idiomas em cada aplicação sem oferecer nenhum meio simples e centralizado de eliminar os desnecessários? Essa questão talvez seja respondida no Snow Leopard, no qual o Mail tem apenas 91 MB. Ainda assim, é grande demais para que seja uma versão crua para desenvolvedores apenas em inglês, mas é bem menor que a do Leopard. Parece que as aplicações do Snow Leopard têm cerca de um terço do tamanho de suas equivalentes do Leopard. Assim, enquanto o Snow Leopard paradoxalmente ganha mais recursos úteis através do melhoramento do código ao invés da aplicação do estilo Microsoft de gerar &#8216;uau&#8217; com peripécias visuais que caem bem no marketing, o sistema está ficando menor e mais leve. Deve haver também algumas outras subtrações, certo? Será que o Snow Leopard vai acabar com a velha API Carbon?&#8221; [...]</description>
		<content:encoded><![CDATA[<p>[...] Será isso resultado apenas da otimização de código e compartilhamento de recursos? Um dos fatores provavelmente está relacionado à Independência de Resolução, que substitui gráficos em bitmaps (que definem cada pixel) por arquivos de vetores gráficos menores (que desenham elementos e controles na interface por receita). (&#8230;) As dramáticas reduções de tamanho nessas aplicações devem envolver também localização mais eficiente. Por exemplo, o Mail do Mac OS X Leopard atualmente pesa mais de 285 MB, mas a maior parte desse peso vem de 18 localizações [idiomas] dentro da aplicação, que consomem 276 MB. O código Binário Universal de verdade tem apenas alguns megabytes e mesmo os gráficos associados e outros recursos somam somente 2,8 MB. Por que a Apple por padrão embute suporte a 18 ou mais idiomas em cada aplicação sem oferecer nenhum meio simples e centralizado de eliminar os desnecessários? Essa questão talvez seja respondida no Snow Leopard, no qual o Mail tem apenas 91 MB. Ainda assim, é grande demais para que seja uma versão crua para desenvolvedores apenas em inglês, mas é bem menor que a do Leopard. Parece que as aplicações do Snow Leopard têm cerca de um terço do tamanho de suas equivalentes do Leopard. Assim, enquanto o Snow Leopard paradoxalmente ganha mais recursos úteis através do melhoramento do código ao invés da aplicação do estilo Microsoft de gerar &#8216;uau&#8217; com peripécias visuais que caem bem no marketing, o sistema está ficando menor e mais leve. Deve haver também algumas outras subtrações, certo? Será que o Snow Leopard vai acabar com a velha API Carbon?&#8221; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Berend Schotanus</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9134</link>
		<dc:creator>Berend Schotanus</dc:creator>
		<pubDate>Mon, 09 Jun 2008 12:55:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9134</guid>
		<description>&quot;Apple could port the Cocoa API to other platforms, allowing developers to create applications using Xcode that could be deployed on both Mac OS X and Windows&quot;

Not being a software engineer and not used to working with API&#039;s it&#039;s not always easy to understand the technicalities explained. However, on a more strategic level it is interesting to see Apple appears to be focussing on the top layers of computer infrastructure. Apple is interested in end-users and the interface with them. Apple is interested in the top layer of programming. And for good reason, that&#039;s where the value is. Having a &quot;monopoly&quot; on simple but essential core technology is one thing, having a relation with the people who are actually using it and being allowed to help them with their problems is something else.

So we have iTunes for Windows, we have Safari for Windows, we get Cocoa for Windows, what&#039;s next: selling Window Cocoa apps through the Windows iTunes store?
Maybe even signed Cocoa apps, proving there is no malware onboard?</description>
		<content:encoded><![CDATA[<p>&#8220;Apple could port the Cocoa API to other platforms, allowing developers to create applications using Xcode that could be deployed on both Mac OS X and Windows&#8221;</p>
<p>Not being a software engineer and not used to working with API&#8217;s it&#8217;s not always easy to understand the technicalities explained. However, on a more strategic level it is interesting to see Apple appears to be focussing on the top layers of computer infrastructure. Apple is interested in end-users and the interface with them. Apple is interested in the top layer of programming. And for good reason, that&#8217;s where the value is. Having a &#8220;monopoly&#8221; on simple but essential core technology is one thing, having a relation with the people who are actually using it and being allowed to help them with their problems is something else.</p>
<p>So we have iTunes for Windows, we have Safari for Windows, we get Cocoa for Windows, what&#8217;s next: selling Window Cocoa apps through the Windows iTunes store?<br />
Maybe even signed Cocoa apps, proving there is no malware onboard?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: StrictNon-Conformist</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9129</link>
		<dc:creator>StrictNon-Conformist</dc:creator>
		<pubDate>Mon, 09 Jun 2008 08:08:14 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9129</guid>
		<description>I just a few minutes ago had a weird logical inspiration/epiphany as to what Apple *really means* with the two bridges, or at least what it could mean: it doesn&#039;t mean porting Cocoa Frameworks to Windows at all, not in the least!  I think we can safely agree on a few points:

1.  Apple is into selling the TUE which requires native software on controlled and known hardware configurations, which greatly aids in stability.

2.  Regardless of OS and native GUI, non-native GUI&#039;s on software always rankles the user because it breaks away from the system self-consistency in a jarring fashion.

3.  Nice hardware and a great OS without all the applications users want and need is a really worthless &quot;solution&quot; and can be exemplified to some degree by the examples of the Apple Newton and the Lisa:  however great they were, they never had a large amount of usable software, and their overall price was way too high for mass market sales.

4.  Being able to run applications for another OS has some advantages, but it isn&#039;t ideal due to GUI issues, and is fraught with the &quot;Keeping up with the Jones&#039;s&quot; problem: the other OS will always be advancing and changing, and is a moving target.  See WINE, or OS/2 when it could run Windows apps.  It isn&#039;t totally outside of the realm of possibility, but I don&#039;t see it as an ideal situation.

5.  This is a developer&#039;s conference, and such things tends to have things announced of greater interest to developers than to typical end-users, but of course, that&#039;s not always the case: what&#039;s of interest to developers has an overall larger picture interest to end-users, even if typical end-users don&#039;t have the background to fully comprehend how it all fits together.

6.  Whatever Apple can do to enhance the availability of software for their OS and hardware combination, the better things are, but it doesn&#039;t make an awful lot of sense from the TUE marketing to make too much of the Mac/iPhone/iPod Touch platform available for the easy taking.

7.  Run-time emulation/layers for other APIs sucks down performance, even done well.

8.  There is some middle ground with the most common OS platform, at least for a limited subset of applications: .NET frameworks.

9.  The Windows GUI messaging and overall model is notably different from Cocoa, but .NET is bound to be closer, and also .NET is setup to deal better with compositing GUIs than old Win32.

10.  If Apple were to release a sufficiently updated version of the OS to warrant 10.6 for this WWDC and make it available, it&#039;d make sense that the features involved wouldn&#039;t actually have much side-effects with application compatibility of existing Leopard applications, but would have another feature.

Ok, that&#039;s a bunch of reasons, not just a few :)

There are two ways Apple could go: 

1.  They could do the less likely, kludgy way (for the user perhaps getting less native-feeling applications) and reuse LLVM to do run-time JIT compiling of .NET IL applications into a Mac-native (mostly) application, with a few added on support libraries to do some of the Windows-&gt;Mac abstractions.  This has the issue of the constantly changing .NET libraries to deal with, and the resulting non-native feeling applications.

2.  A far more satisfying way (if third party developers would go for it) would involve enlisting the interested third party developers for Windows applications to run their existing .NET (or, if really ambitious) Win32/Win64 code through a code converter that would assist (as much as possible) converting Windows-specific things over to Mac-compatible code, and leave the rest intact.  This wouldn&#039;t be a perfectly complete port in all cases, most likely: DirectX would be  a PITA, and COM would also have issues.  This would leverage LLVM already used in the OpenGL stack, but purposed for converting abstract syntax trees of Windows code to equivalent Mac code.  This seems relatively reasonable for feasibility, considering it&#039;d be easier to take the MVC frameworks and write wrappers around the Windows event handling/GUI model, than the other way around.

Of course, I may be completely wrong, and I&#039;ll find out before noon PST :)</description>
		<content:encoded><![CDATA[<p>I just a few minutes ago had a weird logical inspiration/epiphany as to what Apple *really means* with the two bridges, or at least what it could mean: it doesn&#8217;t mean porting Cocoa Frameworks to Windows at all, not in the least!  I think we can safely agree on a few points:</p>
<p>1.  Apple is into selling the TUE which requires native software on controlled and known hardware configurations, which greatly aids in stability.</p>
<p>2.  Regardless of OS and native GUI, non-native GUI&#8217;s on software always rankles the user because it breaks away from the system self-consistency in a jarring fashion.</p>
<p>3.  Nice hardware and a great OS without all the applications users want and need is a really worthless &#8220;solution&#8221; and can be exemplified to some degree by the examples of the Apple Newton and the Lisa:  however great they were, they never had a large amount of usable software, and their overall price was way too high for mass market sales.</p>
<p>4.  Being able to run applications for another OS has some advantages, but it isn&#8217;t ideal due to GUI issues, and is fraught with the &#8220;Keeping up with the Jones&#8217;s&#8221; problem: the other OS will always be advancing and changing, and is a moving target.  See WINE, or OS/2 when it could run Windows apps.  It isn&#8217;t totally outside of the realm of possibility, but I don&#8217;t see it as an ideal situation.</p>
<p>5.  This is a developer&#8217;s conference, and such things tends to have things announced of greater interest to developers than to typical end-users, but of course, that&#8217;s not always the case: what&#8217;s of interest to developers has an overall larger picture interest to end-users, even if typical end-users don&#8217;t have the background to fully comprehend how it all fits together.</p>
<p>6.  Whatever Apple can do to enhance the availability of software for their OS and hardware combination, the better things are, but it doesn&#8217;t make an awful lot of sense from the TUE marketing to make too much of the Mac/iPhone/iPod Touch platform available for the easy taking.</p>
<p>7.  Run-time emulation/layers for other APIs sucks down performance, even done well.</p>
<p>8.  There is some middle ground with the most common OS platform, at least for a limited subset of applications: .NET frameworks.</p>
<p>9.  The Windows GUI messaging and overall model is notably different from Cocoa, but .NET is bound to be closer, and also .NET is setup to deal better with compositing GUIs than old Win32.</p>
<p>10.  If Apple were to release a sufficiently updated version of the OS to warrant 10.6 for this WWDC and make it available, it&#8217;d make sense that the features involved wouldn&#8217;t actually have much side-effects with application compatibility of existing Leopard applications, but would have another feature.</p>
<p>Ok, that&#8217;s a bunch of reasons, not just a few :)</p>
<p>There are two ways Apple could go: </p>
<p>1.  They could do the less likely, kludgy way (for the user perhaps getting less native-feeling applications) and reuse LLVM to do run-time JIT compiling of .NET IL applications into a Mac-native (mostly) application, with a few added on support libraries to do some of the Windows-&gt;Mac abstractions.  This has the issue of the constantly changing .NET libraries to deal with, and the resulting non-native feeling applications.</p>
<p>2.  A far more satisfying way (if third party developers would go for it) would involve enlisting the interested third party developers for Windows applications to run their existing .NET (or, if really ambitious) Win32/Win64 code through a code converter that would assist (as much as possible) converting Windows-specific things over to Mac-compatible code, and leave the rest intact.  This wouldn&#8217;t be a perfectly complete port in all cases, most likely: DirectX would be  a PITA, and COM would also have issues.  This would leverage LLVM already used in the OpenGL stack, but purposed for converting abstract syntax trees of Windows code to equivalent Mac code.  This seems relatively reasonable for feasibility, considering it&#8217;d be easier to take the MVC frameworks and write wrappers around the Windows event handling/GUI model, than the other way around.</p>
<p>Of course, I may be completely wrong, and I&#8217;ll find out before noon PST :)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: retnuh</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9123</link>
		<dc:creator>retnuh</dc:creator>
		<pubDate>Mon, 09 Jun 2008 03:25:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9123</guid>
		<description>@dicklacara

1) Doh.... yup didn&#039;t think of that one.
2) um... requires hard links, and I&#039;d have to read up on ntfs internals to know if this would work, and its been awhile so honestly I don&#039;t remember if its even an option.
3) yes and no.

The main thing is Apple makes money on the whole package, mainly hardware margins, software yes but they would probably have to charge more for their software to really make it a profit center. While your three suggestions could work, is it in Apples best interest to help sell more PCs? Apple&#039;s very good at holding various features or colors (black macbook) as an up sell, same with their Pro apps being only OS X, having more cross platform apps kind of washes down the up sell considering its all Intel hardware now.

The more I think about the idea the more I dislike it. If your main competitive advantage is the whole package, why spend time pushing something good enough on a market that is used to just that. I think it might undercut all their effort in getting people to switch since they really wouldn&#039;t have to. The closest example I can think of is Sega, but I&#039;d have to lookup how they&#039;re doing now just being a software house.

Its unfortunate that Apple had all the problems during the 90s that it did, otherwise things might be very different now. How exactly, who knows, NextStep or anything like it might have never been made for example.

There&#039;s still one thing missing that Apple really should take some more focus on, gaming, yes its much better now, but its one thing holding back the &quot;computer experts&quot; of most families and they&#039;re going to push their families into what they know how to fix. And it shouldn&#039;t be too hard as most non windows game development is opengl already, and yes they do need to cleanup the spec some, but after Microsoft&#039;s failed push of DX10 it&#039;d be nice to see someone else actively pushing in that direction, unless consoles are it now.

Oh almost forgot, the iPhone SDK might already be enough to woo windows developers towards OS X. It certainly is for me, a potential 10+ million iPhones by the end of the year plus Touches,  I don&#039;t know the numbers but its got to be higher than the iPhones,  on the same platform with wifi, storage, app store with software updates = yes please!!!! Actually what we&#039;ll probably start seeing from this is more and more corporate apps being written for the iPhone after v2 firmware gets released. Afterwards if the development process is nice enough you&#039;ll start seeing a push for more and more corporate desktop apps for OS X. Once you have that market its a win for Apple. 10.6 really needs to have more enterprise networking/administration type support to win over the corporate world. So lets see, earlier this year release SDK that gets a bunch of people interested in iPhone development, June release enterprise feature set for iPhone, Jan 09 ish release 10.6 with better/broader support for various network environments into a market that has just spent 6-8 months learning Cocoa touch apis all while using a mac and its not a hard shift to normal desktop apps from there.</description>
		<content:encoded><![CDATA[<p>@dicklacara</p>
<p>1) Doh&#8230;. yup didn&#8217;t think of that one.<br />
2) um&#8230; requires hard links, and I&#8217;d have to read up on ntfs internals to know if this would work, and its been awhile so honestly I don&#8217;t remember if its even an option.<br />
3) yes and no.</p>
<p>The main thing is Apple makes money on the whole package, mainly hardware margins, software yes but they would probably have to charge more for their software to really make it a profit center. While your three suggestions could work, is it in Apples best interest to help sell more PCs? Apple&#8217;s very good at holding various features or colors (black macbook) as an up sell, same with their Pro apps being only OS X, having more cross platform apps kind of washes down the up sell considering its all Intel hardware now.</p>
<p>The more I think about the idea the more I dislike it. If your main competitive advantage is the whole package, why spend time pushing something good enough on a market that is used to just that. I think it might undercut all their effort in getting people to switch since they really wouldn&#8217;t have to. The closest example I can think of is Sega, but I&#8217;d have to lookup how they&#8217;re doing now just being a software house.</p>
<p>Its unfortunate that Apple had all the problems during the 90s that it did, otherwise things might be very different now. How exactly, who knows, NextStep or anything like it might have never been made for example.</p>
<p>There&#8217;s still one thing missing that Apple really should take some more focus on, gaming, yes its much better now, but its one thing holding back the &#8220;computer experts&#8221; of most families and they&#8217;re going to push their families into what they know how to fix. And it shouldn&#8217;t be too hard as most non windows game development is opengl already, and yes they do need to cleanup the spec some, but after Microsoft&#8217;s failed push of DX10 it&#8217;d be nice to see someone else actively pushing in that direction, unless consoles are it now.</p>
<p>Oh almost forgot, the iPhone SDK might already be enough to woo windows developers towards OS X. It certainly is for me, a potential 10+ million iPhones by the end of the year plus Touches,  I don&#8217;t know the numbers but its got to be higher than the iPhones,  on the same platform with wifi, storage, app store with software updates = yes please!!!! Actually what we&#8217;ll probably start seeing from this is more and more corporate apps being written for the iPhone after v2 firmware gets released. Afterwards if the development process is nice enough you&#8217;ll start seeing a push for more and more corporate desktop apps for OS X. Once you have that market its a win for Apple. 10.6 really needs to have more enterprise networking/administration type support to win over the corporate world. So lets see, earlier this year release SDK that gets a bunch of people interested in iPhone development, June release enterprise feature set for iPhone, Jan 09 ish release 10.6 with better/broader support for various network environments into a market that has just spent 6-8 months learning Cocoa touch apis all while using a mac and its not a hard shift to normal desktop apps from there.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dicklacara</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9122</link>
		<dc:creator>dicklacara</dc:creator>
		<pubDate>Mon, 09 Jun 2008 00:50:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9122</guid>
		<description>@retnuh
Thanks for the detailed explanation-- I understand!

As to being worth Apple&#039;s time, I can see several advantages:

1) Apple could sell its iLife and iWork suites on Win and tie it into a new, improved (renamed) .mac services platform
2) Make Time Machine available as above with remote backup
3) Sell its Pro apps on the Win platform

Ideally, these would not work as well with the additional Cocoa layer.  But they could have a superior (OS X-like) interface/integration amongst the Apple-supplied apps.  This would show Apple well to Win users &amp; possibly lead them to consider migration to the Apple platform.

Finally, my intuition tells me that Steve Jobs feels that MS (and Sculley) deprived Apple of its due-- widespread acceptance of the Mac &amp; Mac OS.  I believe, that this remains a goal &amp; hijacking the Win APIs and wooing Win Developers is a step towards that end.</description>
		<content:encoded><![CDATA[<p>@retnuh<br />
Thanks for the detailed explanation&#8211; I understand!</p>
<p>As to being worth Apple&#8217;s time, I can see several advantages:</p>
<p>1) Apple could sell its iLife and iWork suites on Win and tie it into a new, improved (renamed) .mac services platform<br />
2) Make Time Machine available as above with remote backup<br />
3) Sell its Pro apps on the Win platform</p>
<p>Ideally, these would not work as well with the additional Cocoa layer.  But they could have a superior (OS X-like) interface/integration amongst the Apple-supplied apps.  This would show Apple well to Win users &amp; possibly lead them to consider migration to the Apple platform.</p>
<p>Finally, my intuition tells me that Steve Jobs feels that MS (and Sculley) deprived Apple of its due&#8211; widespread acceptance of the Mac &amp; Mac OS.  I believe, that this remains a goal &amp; hijacking the Win APIs and wooing Win Developers is a step towards that end.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: retnuh</title>
		<link>http://www.roughlydrafted.com/2008/06/07/wwdc-2008-is-mac-os-x-106-the-death-of-carbon/comment-page-1/#comment-9119</link>
		<dc:creator>retnuh</dc:creator>
		<pubDate>Sun, 08 Jun 2008 23:15:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.roughlydrafted.com/?p=1908#comment-9119</guid>
		<description>@dicklacara

Sorry it was the &quot;re-implementing both .Net and Win32 APIs?&quot; that threw me off.

To help cover some of the other responses, and some of the other good and bad stuff.

First up if you have everybody coding to the top layer of and API then you&#039;re free to swap out any lower unexposed layers as long as the functionality remains the same at the top. Proof of this can be seen with Delphi&#039;s VCL which wraps up all the GUI side of win32 programming into a real nice OO framework. Its a shame Borland/Inprise/Borland didn&#039;t do better advertising to the developers because most applications need very little changes when moving between new versions of Delphi. I&#039;d use this as proof of how to deal with the changes in .net and win32 apis, its been done. Also if Cocoa were to be on top of .Net it would be bound to a single version of .Net, and if you&#039;re only coding to Cocoa then the version of .Net below it wouldn&#039;t matter much. That said I&#039;m not sure that adding another layer on top of .Net would be a good idea performance wise.

Speaking of performance though, a lot of developers aren&#039;t all that worried about it anyways, they&#039;re more concerned with how easy something is. This would have a good and bad outcome, mostly good for Apple and bad for Microsoft. Cocoa apps would probably run a little slower on windows and reinforce any negative stereotypes of windows because of the extra layering, both Cocoa and any extra services required to expose other required OS X services. The good being that it runs fine on OS X. 

Overall I&#039;m not convinced that doing any of this would be worth Apple&#039;s time. I think its possible and could hurt Microsoft in the long term if done right. But I see it as a distraction to Apple&#039;s core focus. Having been a windows developer for um.... 11 years now Microsoft has done enough to annoy me into buying a iMac 1.5 years ago to try something new. That experience along with the iPhone has made me start learning Objective-C. To this end Apple will have a large enough market between the iPhone and Touch to make developers really take notice and once there might start looking at normal desktop apps. If this happens then it could be worth having Cocoa for win32, but why they&#039;ve already switched a lot of people by this point.

And yes I&#039;ve been following the win32 -&gt; OS X article on Ars, waiting for the  last part, there&#039;s a lot of things I agree with there. I could rant on this for awhile but I&#039;ll save you all the discomfort.</description>
		<content:encoded><![CDATA[<p>@dicklacara</p>
<p>Sorry it was the &#8220;re-implementing both .Net and Win32 APIs?&#8221; that threw me off.</p>
<p>To help cover some of the other responses, and some of the other good and bad stuff.</p>
<p>First up if you have everybody coding to the top layer of and API then you&#8217;re free to swap out any lower unexposed layers as long as the functionality remains the same at the top. Proof of this can be seen with Delphi&#8217;s VCL which wraps up all the GUI side of win32 programming into a real nice OO framework. Its a shame Borland/Inprise/Borland didn&#8217;t do better advertising to the developers because most applications need very little changes when moving between new versions of Delphi. I&#8217;d use this as proof of how to deal with the changes in .net and win32 apis, its been done. Also if Cocoa were to be on top of .Net it would be bound to a single version of .Net, and if you&#8217;re only coding to Cocoa then the version of .Net below it wouldn&#8217;t matter much. That said I&#8217;m not sure that adding another layer on top of .Net would be a good idea performance wise.</p>
<p>Speaking of performance though, a lot of developers aren&#8217;t all that worried about it anyways, they&#8217;re more concerned with how easy something is. This would have a good and bad outcome, mostly good for Apple and bad for Microsoft. Cocoa apps would probably run a little slower on windows and reinforce any negative stereotypes of windows because of the extra layering, both Cocoa and any extra services required to expose other required OS X services. The good being that it runs fine on OS X. </p>
<p>Overall I&#8217;m not convinced that doing any of this would be worth Apple&#8217;s time. I think its possible and could hurt Microsoft in the long term if done right. But I see it as a distraction to Apple&#8217;s core focus. Having been a windows developer for um&#8230;. 11 years now Microsoft has done enough to annoy me into buying a iMac 1.5 years ago to try something new. That experience along with the iPhone has made me start learning Objective-C. To this end Apple will have a large enough market between the iPhone and Touch to make developers really take notice and once there might start looking at normal desktop apps. If this happens then it could be worth having Cocoa for win32, but why they&#8217;ve already switched a lot of people by this point.</p>
<p>And yes I&#8217;ve been following the win32 -&gt; OS X article on Ars, waiting for the  last part, there&#8217;s a lot of things I agree with there. I could rant on this for awhile but I&#8217;ll save you all the discomfort.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

