Guest post by “Most people understand that Windows is used by a variety of people who have a variety of needs, ranging from corporate server to workstation to POS terminals to home PC and beyond. Most people accept that whenever Microsoft updates Windows, it has to balance the competing requirements to find some kind of workable compromise. There is however another set of competing requirements that many do not really register, even those that call themselves power users or are IT admins. It is a conflict between developers/programmers and Microsoft itself.”
People had always hoped that some third party (e.g. and especially Linux) would kill Microsoft. As suspected, however, it’s going to be Microsoft that kills Microsoft. This article shows exactly how Microsoft is killing itself by turning its back on the very policy (developers developers developers) that made Windows win in the first place.
Their stubborn opposition to OpenGL and other cross platform frameworks will be their final downfall, since more and more developers will simply leave them behind in the long term.
Nobody can kill a product-line that is strong mostly because of “network effect” other than themselves.
http://en.wikipedia.org/wiki/Network_effect
I think Facebook is the same way, the only people that can kill Facebook is Facebook.
The death of Silverlight is an understandable one. Times changed. Just like WCF, which was a typed approach to web services, Silverlight is just mismatched for the current times. As originally envsioned, Silverlight was much more than a LOB app platform. It was an entire RIA stack and video delivery framework. HTML5 and especially the video tag took over for a lot of the reason that Silverlight existed. The things that remained that Silverlight was *really* good at was a small niche which didnt have enough clout to matter.
An interesting twist being Silverlight being repurposed for Windows Phone. It is still pretty actively used there but its obvious that Windows development is trending towards the Windows Runtime. The latest Silverlight incarnation in WP8 exposes a small subset of WinRT APIs on the phone.
Generally though, from the perspective of developers that Microsoft targets, they’ve done well. They target existing mobile app developers (Windows Phone, iOS, Android) and they target existing Game vendors with DirectX and various middleware technology.
For the purposes of Windows 8, this is enough. On the enterprise side, they have a very sizable and growing presence in Windows Azure along with SharePoint and other Office related properties. That’s significant and is attracting a new breed of developer to the Microsoft stacks.
What also cannot be downplayed is the fresh talent that the Windows Store platform is attracting. There are over 65,000 Windows Store applications. The barrier to entry to making money on Windows has never been lower. It is easier for small time developers to make money on Windows.
So, really the issue is that Microsoft is taking a phased approach to transitioning developers to the Windows Runtime. This time around, it was a consumer focused release with consumer focused APIs getting the lionshare of attention. WinRT is already in Windows 8.1 showing signs of improvement in functionality.
That’s not even mentioning the fact that today native developers can use a subset of the Windows Runtime APIs from their Desktop applications.
WPF turned into Silverlight which turned into the Windows Store platform. Its all the same underlying technologies, albeit smarter implementations with varying feature sets. Silverlight was always an offshoot of WPF for a different use case. The WinRT APIs are more comparable to WPF in use case, but pared down for the Windows Store sandbox.
Btw: Windows Forms was always a managed wrapper around MFC, a wrapper around Win32. Most of us understood that it was a stop gap measure, plus WPF was already showing up in PDC builds as Avalon. We knew more was coming. The only people who got fucked over on WinForms were the LOB people who generally don’t have much forward facing agendas once they’re developed to spec.
The Windows Runtime is Microsoft’s attempt to fix the problems of the past. WinRT enables a language neutral rich API set to be exposed to many languages. You can invoke an asynchronous API in WinRT, await its value, and chain a response with Javascript Promises. You can do the same in C++ with the PPL or in C# with async/await and the work stealing task scheduler.
It blurs the line between managed and native code. Microsoft can write WinRT components in C++ and consume them naturally from JS and C#. They can write the less performance sensitive ones in C# and consume them from JS and C++. Its really flexible.
It will make the exact problems this article brings up a thing of the past. The WinRT XAML stack is the UI framework for native AND managed code in Windows going forward. That’s the richness of WPF with the performance characteristics of native code.
From another angle, Microsoft is improving managed code performance with Cloud Compilation on Windows Phone 8 which makes start up times for apps nearly instant.
Microsoft is unifying its platforms across various form factors and execution models. Looking forward, things are incredibly exciting.
This is Microsoft’s .NET, Longhorn, and Avalon vision imagined.
AKA the unification church.
Silverlight was a web platform something like Flash.
One of the things I notice on my Android tablet is that websites work. Often slowly or not well, but I can get to what I need instead of the blue lego icon on an iOS device. Which means Flash. Flash is awful, but is what is there, not unlike Win 3.1, Win 9x (and “Me”).
Microsoft can’t be Apple, but they can declare they are now the same with the app store, etc.
(remember Steve Jobs comment) Mack and Cummins ando others make trucks or truck parts. Not cars. They would likely be terrible if they abandoned the truck business to build cars. But that is MSFT. Better a bad car company than a successful and profitable truck company?
Silverlight wanted to be a web platfom. It never got to be one before HTML5 got good enough and it instead turned into a very specialized Line of Business application platform.
Silverlight was extremely good because it supported cross platform execution Out of Browser and platform agnostic integration with the host. It was an extremely attractive proposition for existing .NET shops who were invested in Microsoft technologies.
Silverlight was cross platform in the same sense as how you could buy early Ford cars on any color you wanted, as long as it was black.
Sorry I must have imagined MoonLight.
http://www.mono-project.com/Moonlight
… perhaps you missed it because that project has been dead for a while. You must also have missed that monolight was not made by microsoft, and that they only got (barely working) a subset of the silverlight components. The irony is that the moonlight community ended up deeming that “cross-platform” was a secondary concern (at best) for microsoft regarding silverlight.
Nobody wanted cross platform silverlight and the project didn’t go anywhere. That is fine.
But there was never anything stopping Silverlight from being cross platform whether it was from Microsoft or from someone else.
Mono and Xamarin are doing quite well, so there is a want for cross browser .NET like runtime.
Have you ever used Moonlight? Serious question, because they had a lot more than “barely working”. They supported the entire SL3 profile.
I think it became one, after times changed. When Silverlight began to see more LOB use, the need for cross platform deployment left and the bigger deal was interfacing with COM and acessing devices, which Silverlight 4 brought.
Its interesting knowing about Silverlight’s history to put these things in context:
– Silverlight 1.0 was nothing more than XAML implemented on top of HTML Canvas and JS with some smooth streaming media APIs on top of it and a lightweight plugin iirc.
– Silverlight 1.1 (later renamed 2.0) implemented the CLR in browser (in a 6MB profile) with XAML being pushed into the plugin proper.
– Silverlight 3.0 implemented out of browser support, optional GPU composition (still S/W raster’d due to x-plat support), and things like
– Silverlight 4.0 implemented COM interop (which brought Mic/Webcam support and elevated Out of Browser support to do COM and x-domain sockets)
Moonlight implemented Silverlight profile 1.0 – 3.0, AND the parts that made sense from SL4. Some features in SL4 made no sense to implement on Moonlight due to it being mostly COM specific improvements (when Microsoft pivoted SL to be a LOB solution after HTML5 took hold).
So during Moonlight’s life time (before MSFT changed positions, HTML5 took hold, and Novell sold off Mono which became Xamarin) it supported almost every profile Silverlight 4 supported.
The only SL4 apps that didnt work were Windows specific LOB apps anyway which invoked COM because of customer requirements.
You see, this is why it makes sense to talk about shit like this when you’ve actually used it. I’ve actually deployed code running on Windows, Linux, and OSX using a combination of Silverlight and Moonlight. I’ve sat in the IRC chat rooms with them and helped them debug incompatibilities, I’ve asked and received help for Out of Browser plugins which resulted in contributed patches.
This is what’s particularly infuriating about this article, and your senseless dig at the Xamarin team, it’s devoid of fact and reeks of an ignorance of the technology that’s inexcusable.
Its nice that you can be a smartass and demean the work of others, you’re good at that, but its worth noting that you have no idea what you’re talking about. What so ever.
Thank you for this.
I work with people everyday that talk (a lot) about technology they have never used. Sadly, the loud, opinionated blow hards are usually rewarded and the guy who takes the time to figure out the facts is seen as being late to the game; a trend I don’t see changing.
Too many times, being loud trumps the facts, but I’ve come to realize that’s how most of the world works.
Small correction: WinForms is not a wrapper around MFC. It’s a managed replacement for the same idea, but doesn’t involve any MFC components. It does, of course, wrap the Windows API fairly closely. If you dig into the WinForms decompiled code, you run into API calls without having to go very far.
Personally I would like if they just use an optimizing compiler for .NET and throw away the VM stuff, or improve the code quality of NGEN.
Singularity had Bartok as native compiler for C# code, and Windows Phone 8 applications are compiled to native code with their optimized cloud compiler.
Now I just want to have the same for my C# code on the desktop/server.
You are ignoring the fact that anyone coding for XNA now has to find a new “middleware” technology. Generally I agree with you though, the damage seems so far to be fairly limited as most of them flocked to Unity as a result.
However Unity works everywhere, which from Microsoft’s traditional point of view is suboptimal as they prefer programs to only run on their systems.
I am not sure what you mean by this. From a native developers point of view Windows 8 appears as this oddly incomplete mixture of COM APIs (Direct3D, DXGI, etc), and then having to bridge into .Net with C++/CLI to truly cooperate with the Modern UI.
As an example of this, if you want to target Modern with Direct3D or Direct2D, you have to first create a .Net WPF window (using C# or C++/CLI), and then obtain a native IUnknown for the WPF CoreWindow object. Only after this can you call IDXGIFactory2.CreateSwapChainForCoreWindow which is required to setup a native rendering context.
In other words: there are no native interfaces working with Modern.
Strictly speaking WinForms is a wrapper around GDI+, with its API closer resembling Delphi (where Anders Hejlsberg came from) than MFC.
I am not sure I understand your point though. You are saying that people that had to write a C# UI, before WPF was ready, had it coming and gets what they deserved when Microsoft stopped updating this API?
From a native developers point of view WinRT is just a fancy word for deprecating all Win32 functions related to GDI. There is no C++ support for the newly introduced Modern APIs as those all require C++/CLI. You are coding about as much in C++ when using C++/CLI as when you’re coding C++ when writing an Objective C class with Objective C++. It is a nice bridging feature, but surely you wouldn’t claim that P/Invoke makes C# a first class citizen for Win32?
Microsoft marketing couldn’t have written it better. Sadly that doesn’t make it true. The “WinRT XAML stack” is a .Net assembly and has nothing to do with native.
Now on this we can at least agree. This is their second attempt at deprecating native development and force all future development to be CLR only.
That vision train-wrecked Vista. History will tell if it will do so for Windows 8 too.
XNA developers were never numerous, the majority of XNA apps are written as Windows Phone 7 apps, which can still be written today if you wish.
You can also use MonoGame which is a free and open source implementation of XNA across Windows 8, Windows Phone, iOS, and Android.
Its a better solution than XNA, which is why I never got the issue. XNA was never good and most people who used it disliked it. I’ve never liked it and thought it was an overengineered mess. Suddenly its dear to some people when Microsoft *finally* axes it.
No. There is no bridging with C++/CLI, in fact, if you all a C++ WinRT component from a C++ app the CLR isn’t even loaded.
WinRT components use COM to define the ABI, so under the hood they’re native code. The only time the CLR is loaded is if the WinRT component itself is written in C#.
The C++/CLI syntax you see is just Microsoft re-using it for C++/CX, their extensions to C++ for authoring WinRT components.
You can write WinRT code with ISO C++ if you don’t mind using the WRL template library.
WPF is not used with the new WinRT XAML APIs. They’re not the same thing. The XAML stack in WinRT is native.
Generally, yes. People knew it was a stop gap. Any .NET developer knew it didn’t feel like writing .NET code. WPF brought us a proper framework with the full benefits of .NET.
I was already writing Avalon code when people were just starting to use WinForms, if people adopted it beyond more than a temporary wrapper then that’s on them.
My God, this isn’t true. How do people like you get away with such misinformation and bullshit?
Write a C++ app, call into the WinRT APIs, look at the loaded modules with WinDbg or something and notice that mscorlib is NEVER loaded into the app. WinRT APIs are for the most part pure native code called from .NET code, or JS, or C++.
No it isn’t. Spend one day writing one line of WinRT code and you’d know that you’re wrong.
How people can be so absolutely ignorant of the facts astounds me.
WinRT is essentially a COM-based API, although relying on an enhanced COM. Due to its COM-like basis, WinRT allows interfacing from multiple languages, just as COM does, but it’s essentially an unmanaged, native API. The API definitions are, however, stored in “.winmd” files, which are encoded in ECMA 335 metadata format, the same format that .NET uses with a few modifications.
http://en.wikipedia.org/wiki/Windows_Runtime
The language extensions borrow syntax from C++/CLI but target the Windows Runtime and native code instead of the Common Language Runtime and managed code.
http://en.wikipedia.org/wiki/C%2B%2B/CX
while the XAML framework is part of the Windows Runtime, written in native code
http://en.wikipedia.org/wiki/Windows_Runtime_XAML_Framework
Since you’ve been shown to be so afraid of the facts, watch this video on the internals of the Windows Runtime where they hold your hand and walk you through explaining that its native code.
http://channel9.msdn.com/Events/Build/BUILD2011/PLAT-875T
In my opinion the point of the original ReactOS article was partly that Microsoft once again burned the developers that were using their technologies. I am well aware that there are countless alternatives to XNA, but that still means that if you relied on XNA all that knowledge is now totally useless, and any code you wrote up against it now has to be rewritten or at least ported.
And strangely enough this time Microsoft is even forcing people to port to technologies that doesn’t tie them into their platform. That is what I meant by calling it suboptimal from Microsoft’s point of view.
I have no love for XNA, nor WinForms, since I’m generally a native developer by trade. I used neither much beyond trying them out shortly. But this isn’t the 1990’s anymore where Microsoft could get away with burning developers left and right. Not everyone is in awe about everything Microsoft as you are, and they might simply chose to drop the platform.
Yes, this isn’t likely to happen for Desktop, but for Mobile this is can become a real threat to Microsoft.
OK, thank you. This is the missing piece that I’ve been overseeing whenever I got MSDN links about Modern. I thought I was seeing garbage collected C++/CLI (which generally interacts really poorly with other C++ code), while I was actually seeing reference counted C++/CX.
No need for all the insults. For someone that doesn’t follow all the Microsoft blogs daily it is a perfectly reasonable error to make. The two systems are almost identical visually after all.
There were many reasonable reasons to not target WPF. For starters, Microsoft tried to not support Windows XP in the beginning, until they realized the market would not adopt their new tech if they insisted on this. So many people were left with the unpleasant choice of either using MFC (eek!), use WinForms, or only support Vista which had no users yet.
I probably should have been more clear in my original posting, but my main issue with CLR has never really been the “native vs managed” angle. As a C++ developer the problem with C++/CLI has been that it integrated terribly with ordinary C++ code to the degree that you now were simply coding in a form of “poorly skinned C#”.
C++ and C# each have their strengths and weaknesses and if you’re going to be forced to adopt the C# weaknesses (such as IDisposable and finalizers), then you might as well take the advantages too and switch language. Which has always been my personal grudge against the CLR, that any other language targeting it had to adjust to becoming a worse C# (the language the CLR was effectively designed for).
C++/CX does seem to go about this differently from what I can tell so far (due to the switch from GC to refcount). I’ll have to toy around with it a bit to see how it integrates.
WRL on the other hand.. what a disaster! I doubt anyone will use that.
MonoGame maintains a great amount of compatibility. The only parts it doesn’t support are the XBox Live leaderboard API which only ever worked on the 36 and less useful APIs like the Microphone API.
I think there is an overriding priority to ease development. It reflects the fact that more Unity and Unreal devs exist than XNA devs. Microsoft doesn’t have a sizeable amount of XNA developers even complaining about this.
Its worth quantifying developers. Users of XNA were XBLIG users (not that many) and WP7 developers. WP7 developers can still use XNA on WP7 using the compatibility layer on WP8 or they can port to MonoGame, or port to other middleware.
XNA can even used reflection to access the WinRT API from WP7 projects and support new APIs on a WP7 app running on a WP8 device. There are a lot of options for people genuinely affected like this.
But then again this is the whole point: The only people complaining about XNA are people who don’t use XNA. Its people looking for clickbait that see a headline and automatically think that developers breathed more than a collective sigh of release.
Yes, some WP7 devs complained. Most by now have been convinced by the quality of MonoGame that things are not really that bad, and in fact, are better.
MonoGame is innovating on XNA, bringing it to more platforms. It runs on iOS, Android, Windows, Windows Store, Windows Phone 8, etc.
Prior to MonoGame Microsoft hadn’t updated XNA in a meaningful way in years. XNA was already a dead technology, not due to Microsoft axing it, but due to poor popularity.
C++/CLI has great interaction with existing C++, Microsoft just had the luxury of going many steps further and introducing the deep level changes needed to avoid a shim like C++/CLI.
I did find it a fun exercise to write a mixed mode WPF and C++/CLI program back in the day. The interop story actually isn’t that bad, but was bad was the mental model needed to even think in mixed mode.
It just shows the distorted lens through which people view Microsoft and WinRT, and it really is unfair. The Windows Runtime adresses *exactly* the problems that this article truly gets at, which is a disparity between native and managed code APIs.
With the WinRT, .NET is a first class citizen as a consumer of the Windows API. So is JavaScript, and so is C++.
.NET finally got a good API interop story with native code
Native Code finally got a native modern UI stack
JS got an optimizing AOT compiler, API interop, and some other misc things iirc.
I was hearing about Avalon going to XP since early 2004 probably if memory serves me correctly. It was a big effing deal at the time, so devs had plenty of time to see the tea leaves.
To me, the WinForms people are the same people that jumped on the Managed DX bandwagon.
The truth is that straight up wrappers like that rarely get long life times and you have to go in there knowing that. I knew from the start that WinForms wasn’t how true .NET UI code should be written. It felt too much like native code with managed code veneers.
The problem is that its’ been over a decade since Vista RTM’ed, even more since Avalon CTP builds went out.
How do people not have their ducks in a row yet? The real people who have a duty complaining are those in the most position to affect change People locked into WinForms using LOB contracts would’ve been in there were WinForms mainstreamed or depreciated. Thats how that game works, unfortunately.
I was getting WinForm jobs in 2010 the same way I get WPF jobs today.
My C++/CLI code never touched my pure ISO C++ just like my C++/CX code doesn’t touch my ISO C++. You could on a per-file basis change types to use the CLR or to use pure C++ when using C++/CLI.
The real annoying language extension was Managed C++, that was truly terrible.
IDisposable still exists for WinRT components because reference counting still isn’t determinalistic, and some things are too expensive to wait for.
Some types implement IDisposable (now moved into VCLibs and under ABI::Windows::Foundation::IClosable COM interface) which helps you get a determinalistic clean up of resources.
WRL isn’t that bad, just that documentation is lacking. You initially hate WRL, but once you try to write straight up C based WinRT code you quickly come to love it.
You could have distilled that down into one word: Astroturfing.
Yeah, because pointing out facts is astroturfing. Unlike the morons in this thread, or even the person who wrote the article, I’ve actually the technologies being discussed.
I’ve shipped deliverables using most of the technologies mentioned here and have followed their evolution. Is it astroturfing to point out that WPF, Silverlight, and WinRT share a similar lineage?
Or to correct falsehoods than WinRT is managed or is interoped using C++/CLI? Is that astroturfing?
Is it astoturfing to correctly point out the target demographic for Silverlight? All of this is independently verifiable. Silverlight was a RIA platform, it launched a long side RIA Services for .NET and had a scope that was different than what it ended up being.
Is it astroturfing to point out that XNA is terrible and has always been? Most people who actually used XNA, you know, the ones who would even give a damn, never liked it anyway and are glad to be on better middleware.
Unity, Unreal, or whatever are infinitely more supported and accepted by game developers and content creation tools. Its a more natural fit into the workflow. XNA was always deadweight and only on Windows Phone because Microsoft wasn’t ready to put native code on WP7 and they needed a managed graphics API.
Had Microsoft had more time, I have no doubt that XNA would’ve never launched on the platform in favor of DirectX interop with WinRT which is more natural.
It’s a long list of total utter bull straight out of the MSDN marketing department that addresses none of what the article is talking about.
I sincerely hope you’re getting paid for this.
I think you’re trying to be sincere, but along side the correcting of factual errors, you’re also attempting to excuse the absurd decisions that microsoft has made in the past and push the blame on to the developers that actually used them.
It really does read like it was taken straight out of .Net Architect. I used to read that for the sheer humor of it. The other MS article with the MS kernel developer rant rings more true: MS is so afraid of screwing up existing customer’s applications it just creates new parallel solutions to the same problems instead of adapting the existing one.
How is this different from any other OS commercial vendor?
When Microsoft was king, and dictated standards, it did plenty of damage already.
Now that it has to play catch up, it’s slowly adapting all their products one by one to the standards. Internet Explorer is finally accepting HTML5, SVG and (soon) WebGL, I never though that day would come.
Having to switch to C++ on their APIs from C# was also great. I hope a greater blow will come when they are forced to support OpenGL ES on mobile platforms or risk losing even more developers.
Some of their policies suck though, like not allowing third party browsers..
Edited 2013-05-13 03:00 UTC
C# and .NET are great. It’s too bad that Microsoft was only half-hearted in their willingness to let it be an open platform.
Despite it being good, it was developed as a lock-in competition to Java (the fact it ran on OSX doesn’t help, as java was mainly used on Unix servers and phones at the time).
There is no chance that Microsoft would have fund development of it if it was going to be an open technology.
DirectX is kind of the same, I honestly think it blows design wise (too unnecessarily low level) compared to OpenGL, and thanks to mobile devices catching up much faster than Desktop, it will likely be history pretty soon.
Why should it?
Game consoles don’t support OpenGL anyway.
Even the PS4 has dropped support for OpenGL ES, because the developers actually only use LibCGM on the PS3.
I signed NDA so i can’t really say, but there’s one console manufacturer that uses OpenGL exclusively nowadays, you are likely not licensed for it.
About Sony, you definitely don’t know what you are talking about, but developing for their native PS3 library is more painful than testicular torsion.
Yeah, that Ouya console or that SteamBox has really captured the imagination of the masses.
I’ll put it this way, 2 devices that you can purchase in GameStop today, that sell boxed retail games use OpenGL.
On phones? I think j2me was a bit later, after .Net was already at least well under way.
Says it all really. When people aren’t demanding .NET developers I might actually pay some attention.
That must be the reason why we moved from Java to .NET projects in 2010, we just love not to work.
If you’re lucky enough to have found someone to absorb all the costs and you’re happy to be screwed over via the app store and other avenues Microsoft channels you into to steal your income, great.
It just gets annoying to listen to people like you who tell us that our paychecks can’t possibly be real because Microsoft is anti-Developer with their platforms.
When I see stupid articles like this, I can’t help but laugh. People spout off about technology they haven’t used, and the people who actually have hands on experience with said technology are voted down.
.NET has enabled me to have the same code running on multiple platforms in a loosely coupled and maintainable way. I write better code, faster, with more reach than with any alternative platform out there. A lot of this richness is lost on people who have no other motivation in life but to ignorantly bash Microsoft.
But hey, developers who jumped in on the Windows Store early like I did have cashed out. It pays to be pragmatic.
Meanwhile you have an OSAlert comment.
Stop it please. I’ve had to get back on my chair from laughing.
Ever heard of Mono?
You guys are boring and predictable.
iOS, Android, Windows Phone, and the Windows Store. There was a possibility for more but this is a mobile app.
Using the .NET Framework’s Portable Class Library I was able to have 80% of my code be cross platform without a recompile by using the PCL support in Mono and .NET.
For the code I wrote which used platform specific APIs, I wrote small platform specific DLLs which referenced the portable business logic of the app.
I originally wrote the code for Windows Phone, and easily ported it to iOS, Android, and then Windows 8.
When you play with the big boys, license costs are rounding errors…
This totally.
Everyone goes “oh this is expensive because I can’t afford it”. The cost is trivial compared to the price of developers, testers, project managers, requirements gathering.
Edited 2013-05-13 20:48 UTC
The article makes it sound like this is the first transition done.
Mac OS9 –> OSX
required complete rewrites of almost all its apps
MSDOS –> Windows
this also included the move from CL to GUI
Microsoft has actually been very canny in this transition. The reality is, they don’t care nor need to care about indy developers. They never have. The point of maintaining compatibility for all these years was enterprise. Enterprise are suddenly hitting that big cliff of XP’s EOL.
Microsoft know as well as the rest of us that when these corporations upgrade, they are still the only viable option (no, linux without office is a non-starter and OSX requires breaking their hardware support contracts)
This is not correct. OSX included Carbon, which were a port of the classic Mac OS’s more modern APIs retained for backwards compatibility. This allowed existing apps to make the transition without requiring a full rewrite to OSX’s native Cocoa APIs. Obviously it wasn’t a free transition: developers still had to replace any code that used really old, gnarly parts of the MacOS Toolbox that weren’t supported in Carbon, update their GUIs for Aqua, and rebuild. But still far, far cheaper than a ‘complete rewrite’.
Indeed, the whole reason Apple created Carbon in the first place was that major application vendors such as Adobe and MS would not – and could not – have ever undertaken major rewrites of their massive productivity apps. Without Carbon to make the transition to OS X cost-effective, those vendors would have simply abandoned the Mac platform altogether. And this was all back in the days when graphics and publishing were still core markets, a big chunk of income which Apple could not afford to lose.
This doesn’t mean that Apple themselves ever saw Carbon as a full and permanent fixture in OS X, mind. The subsequent success of iPhone and iPad means that Apple’s primary focus is now the iOS and consumer markets, and old pro app vendors and users carry much less weight. Thus Apple never included Carbon support in iOS, and has gradually superseded and/or eliminated various Carbon APIs in OS X, first reversing previous plans to make Carbon’s GUI and QuickTime APIs 64-bit in 10.5, then legacying and/or deprecating many of the other Carbon APIs in 10.6 and 10.8.
This unpredictable, piecemeal hack-n-slash has caused some ruckus amongst longtime developers, peeved firstly at having to rewrite existing, mature Carbon-based code against Cocoa instead, and secondly that Apple’s new ‘replacement’ Cocoa APIs are often inferior in quality and/or features to the Carbon ones. But so far the pain has been sufficiently spread out that developers have soaked it up over time. And even if it did spike to a level where a vendor like Adobe or MS decided to jump ship, this’d have less impact now on Apple’s bottom line than it would’ve 15 years ago.
..
Microsoft, of course, are in a slightly different boat, since Windows’ big selling point has always been that it is a reasonable jack of all trades, rather than the master of any one. I suspect Windows developer culture is also a bit more innately conservative, especially in the corporate field where ancient codebases tend to persist long after their best-by dates (something that Apple never has to worry about since it has no traditional corporate market anyway).
I suspect MS’s current strategy does provide the best overall balance for both them and their users: freezing old, nasty APIs while retaining them long-term to ensure old extant apps continue to run, and focusing all their new development resources on clean, new APIs and features. Obviously, diehard users of the former are going to kvetch when they see users of the latter get all the shiny new toys; but then all those shiny new toys would probably never get created if MS had to spend all its days reflogging all its old, dead horses. You pays your money, etc.
The first step to pushing dev to the other direction for Microsoft was to kill VB6 when .NET was clearly not a drop-in replacement.
Then inconsistencies in their support of either the venerable (senile ?) win32 API or even .NET.
The VS Express edition was probably a step in the right direction, but the lack of native dev tool for windows RT plus the (artificial) lock-in to Metro and the store was the last straw.
What do you mean by ‘kill’? As I understand it, VB6 apps still work under Windows; they just don’t have access to all the shiny geegaws that the modern APIs allow.
My impression was that this was largely a product of political infighting between the Windows and Office teams (C++/Win32 orthodoxy) and the Business team (C#/.Net heretics) while the MS leadership sat back instead of cracking heads together for the greater good. WinRT seems to be a negotiated settlement, presumably born of a seeping realization that if they don’t stop fighting each other and start battling the competition then they’ll all be pulling social security before too long.
Obviously MS were trying get their Express users to bootstrap Metro development, but they very quickly removed the Metro-only restriction in response to negative feedback. Users don’t like the idea of losing something, even when they weren’t paying for it in the first place. (Indeed, the non-paying users may even be the noisiest.)
I suspect MS’d have far much better by offering prizes, kickbacks and other positive incentives to encouraging Metro development; carrots rather than sticks. Any legitimate technical gripes over Windows 8 have long since been swamped by sheer volume of PR ineptitude and good old public love for simplistic black-vs-white narratives that, internet-enabled, now turns heros to villains (or back again) faster’n you can say “Google Android”.
All I really want is a statement saying something like “Writing desktop apps in C#/.NET will be supported for at least another N years/versions” , for some fairly high N.
Not that I write too many of those; the last thing I did was in Java (it needed to run on a handful of different OSes, and WebStart was convenient).
http://support.microsoft.com/lifecycle/search/?sort=pn&alpha=.net+f…
??
Sometimes I have to wonder if those who despise Microsoft & Windows have any clue what-so-ever about the damage that would be caused by the companies demise, were it to happen. In most cases it seems they’re oblivious but I suppose that shouldn’t be any surprise.
Imagine if it was Oracle? I rather be flipping burgers.
Edited 2013-05-14 17:05 UTC