A perspective: developers vs Microsoft

[Karl L.]

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.

Developers are ultimately the ones who write applications used by users whereas Microsoft develops the OS these applications run on. A common shared goal between the two is the desire that applications previously written continue to work. Users use Windows not to use Windows, but the applications that they need after all. Developers on the other hand have finite resources and time and the need to constantly tweak an existing program because of an unstable ABI/API is often an unwelcome distraction. Even worse for developers is when support for an API is eliminated outright, which would require a complete rewrite. Loss of a platform happens much less in the Windows world than in the open source world, and even there it is a rare event because of how ****ed off the developers who make up that sphere would get. Developers also often want the platform that they are using to be continually updated either with bug fixes or new features to make certain tasks easier. Contrary to what many users might think, we generally want to be able to keep supporting our customers/users and want to add new features while keeping existing ones working. This task becomes very difficult however once a framework/platform is deprecated as certain things may simply not be possible without underlying upgrades.

Sometimes however, such clean breaks are necessary because a platform has accrued too much technical debt and architectural issues to improve further without prohibitive cost. Developers for Windows have known this to be true for the win32 API for years now. After all, the win32 API started out as an API for 16bit platforms and has been extended to support 64bit platforms. It is also ridiculously clunky in many places and often very, very verbose and with the increased emphasis on using C++ for development, the C centric win32 API was showing more of its age with every passing year. The Microsoft Foundation Classes library was an attempt to provide a C++ centric API to the underlying win32 platform, but it still suffered from the verbosity problem and was infamously inflexible the moment one tried to do something that was not explicitly supported. There has been a lot of rumbling amongst Windows developers of a need for some kind of break, as painful as it would be. Microsoft started down this road with the .NET framework and an updated WinForms platform, to try to make development less painful. .NET however is a managed platform and while it became very popular, it did not entirely fit the needs of people who were doing native Windows development. For a time Microsoft released something called the Windows Template Library, which tried to abstract away some of the more irritating aspects of the win32 API while being much more flexible and lightweight than MFC. While many people liked WTL and felt it should have eventually become the defacto way to program Windows, there was another perspective that ultimately killed off that possibility.

The problem Microsoft faced was not just the clunky nature of the win32 API. The underlying system was also very, very old and had not really kept up with the times. The graphics engine in Windows was written at a time when the CPU was the principle unit responsible for graphics rendering. GPUs however had become increasingly powerful and flexible in the intervening years, but the Windows graphics engine was simply not designed to take advantage of this new power. The choice was 'obvious' but not trivial. Microsoft could create an entirely new graphics engine and build a new API on top of it to provide a more modern programming and user experience. At the same time however, they absolutely had to maintain compatibility with existing frameworks and applications, as otherwise no one would have a reason to buy the new version of Windows. The first step on this road was Windows Vista, which fairly or unfairly is remembered as a resource hog and suffering from many application incompatibilities. The change however was necessary, since Microsoft needed some kind of foundation to give developers easy access to the ever growing power of GPUs. Forcing developers to write Direct3D applications is massive overkill, especially when trying to use Direct3D for what were essentially 2D applications involved a lot of code overhead.

Microsoft was not yet ready to release a new native API yet and instead dropped the Windows Presentation Foundation, Silverlight, and XNA on developers. Users of the .NET framework were delighted, as the three were all things considered very nice tools. WPF did suffer from some severe performance issues due to an architectural design flaw, but Microsoft slowly improved the underlying system. Silverlight on the other hand grew very popular for corporate intranet applications, spawning off basically a mini-industry in the IT world. It also likely helped increase the attractiveness of Windows servers, something that Microsoft has often tried to push to try and supplant Linux in server environments. Whereas many companies previously used Windows servers primarily for active directory, now they had more reason to treat the web hosting aspects of the Windows server more seriously. XNA on the other hand offered a very nice abstraction layer of the fairly complex and verbose Direct3D API, allowing managed application developers to tap more of a GPUs power without needing a lot of boilerplate bootstrapping. Microsoft also offered some tentative steps to woo indie game developers by opening up the Xbox Live Arcade a little bit, though getting a game into the marketplace turned out to be non-trivial. It was however in the XNA community that Microsoft had theoretically created a cadre of developers that would have made a Microsoft controlled appstore viable. It was also probably the biggest ****-up that Microsoft made, but we'll touch upon that later.

All of these improvements were again targeted at managed application developers and there was increasing frustration from native developers. They too wanted to take advantage of the more powerful underlying hardware, not just GPUs but the increased processor core count, but none of their existing options were anywhere as simple or friendly as that of the .NET developers. With Windows 7 however, Microsoft released Direct2D, a native API that provided new functions for 2D drawing offloaded to GPUs, and various parallel development libraries. Now native developers finally had a relatively modern API that allowed them to tap into GPUs without the need to explicitly program for them and some additional help for multi-threaded applications. The potential for Direct2D was obvious to many people, including game developers, especially with the improvements likely rolling out in the future. After all the pain of the long drought between Windows XP and Vista and then Vista itself, the future looked promising. And that was when things took a very strange turn.

Most people will remember that it was during this period that Apple became wildly successful with their iPad/iPhone and AppStore combination. Microsoft's executives probably looked at this success and the associated revenue and wanted in. In the process however they made a series of decisions that seems very, very strange. The first thing to keep in mind is that the success of the AppStore, or any app store for that matter, is heavily reliant on the number of developers developing for it. Both Google and Microsoft understand this and both tried to woo developers by offering simple to use yet still powerful and flexible APIs and good tooling support. Microsoft has traditionally been very good with the tooling support part, as anyone who uses Visual Studio can attest to. Microsoft even made some token movements to make XNA a platform to use for developing applications for its phones. And then with the introduction of the Metro/Modern API, Microsoft basically showed the finger to huge swaths of its current developer base.

The biggest casualties were the Silverlight and XNA platforms, which Microsoft has effectively deprecated in what appears to be a misguided effort to get developers to use the "Modern" API for Windows 8. The problem with this however is that Silverlight's use case does not match that of Modern. Silverlight is essentially a browser plugin for web applications, whereas Modern is intended for OS applications. Even worse is the deployment mismatch. Silverlight is generally hosted on a web server, whereas Modern applications are only available via the Microsoft appstore. Corporate customers are obviously not amused, nor are their developers. In one stroke, Microsoft has managed to not only decrease the value of their own Windows servers as web hosts, but also lessen the desirability of Windows 8 to their corporate users. What is strange about this move is that Silverlight developers are not people who could naturally transition to writing apps for the appstore. Their usage of Silverlight simply does not match Modern apps. Microsoft's position on this, besides that of basically ignoring complaints, is to tell people to use HTML5. This again is a stupid response, since Silverlight developers are not creating websites in the conventional sense. They are most often building line of business applications that just happen to be deployed via a web server. These LOB applications can be fairly complex and they chose Silverlight because it offered a lot of tooling to make the complexity manageable. Despite the promotion of HTML5 by various interests, HTML5 and AJAX are vastly inferior and its use would increase development time and decrease developer productivity. Why Microsoft did this is still a bit unclear. There may have been a desire to unify development to a single API for more complex applications, but the one size fits all paradigm has never worked in software development before and nothing in the near term suggests it will somehow become viable.

The people who might "naturally" be able to transition to the appstore happen to be members of the XNA community, but Microsoft has likely done itself even more damage there. Their treatment of indie developers in XBLA has been fairly atrocious, with the people who manage Xbox Live seeming to do everything they can to maximize direct revenue to Microsoft even at the expense of relations with the developer community. In a way this might make sense as Microsoft's entertainment division suffered losses for many years, but in the long term they seriously soured the early enthusiasm people had for XNA and the Microsoft ecosystem as a whole. And then Microsoft deprecated XNA, again in favor of Modern, without providing any sort of migration/transition process. This is hilarious on many levels, not least of which is suddenly managed application developers suddenly lost their access to direct GPU manipulation. This creates a somewhat reversed situation compared to previous iterations, wherein the managed developers were getting lots of shiny new toys while native developers were stuck with old crufty ones. However, just as native developers were often unable or unwilling to migrate to a managed environment, managed developers are often just as unable or unwilling to migrate to native development. This new asymmetry is probably even worse for Microsoft because others have duplicated Microsoft's managed environment much more completely in the form of Mono. With the Mono developers also announcing the implementation of a framework that is API compatible with XNA, what was left of the XNA community is pretty much abandoning Microsoft's ecosystem as quickly as possible. Others are being picked up by the likes of Sony, who also released a SDK using C#. In one stroke, Microsoft basically killed off a significant portion of their developer community, the portion that was most likely to have been willing and able to develop for their appstore. Instead, Microsoft has basically had to build that community from scratch.

And what of the native developers? After all, we were the ones that were given a shiny new API that is relatively modern and powerful, especially compared to the antique that is win32. And yet many of us are also scratching our heads. Many of us were desktop application developers, people who enjoyed all the flexibility that entailed. Instead Microsoft has imposed restrictions to applications written against this new API that make it abundantly clear they designed this new API not for desktop applications, but for tablets and phones. And our response to this is pretty much, to hell with that.

Microsoft has established for itself a strategic goal to move into the phone and tablet ecosystem. To do this, they understood that they needed applications and developers to write those applications. As such, they have focused a tremendous amount of effort into giving developers the tools to write those applications. In the process however, they have systematically ****ed off significant portions of their existiing developer base, either by deprecating the platforms they relied on, treating them disrespectfully, or by outright trying to force them to write phone/tablet applications by imposing restrictions. The bet Microsoft seems to have made is that they will attract enough converts and new developers that they can shrug off the defections that they will inevitably suffer. Had those defections been relatively small, yes, they could have. On the other hand, losing entire communities of developers like they did with XNA is going to have long term strategic implications. Those were the people most likely to have been able to make the Microsoft appstore a success by providing quality applications and games. They will remember the way Microsoft treated them and they will spread word of this to other independent developers that Microsoft needs to develop for them. Whether Microsoft's shareholders are savvy enough to understand the implications of this is another matter entirely.

What this all boils down to is, Microsoft has effectively made the "clean" break that many desktop developers asked for. The way they did it however was analogous to trying to deprecate the desktop itself instead of giving developers new and better tools to continue developing for the desktop. That was not what developers were asking for and Microsoft is currently pretty much in damage control mode in many respects. The only question now is whether Microsoft is willing to go far enough in accommodating the desktop developers with the tools that they need/want or are they so dead set on trying to ram the appstore down developers' throats that they are willing to write off anyone who resists or if the appstore model is actually going to be successful in a desktop environment to begin with. Something Microsoft does not seem to quite get is that, besides games, there are a finite number of programs that a regular user actually uses in their everyday lives, which means the number of applications that could be in the appstore before saturation point is actually fairly low. A far greater number of applications are productivity applications written by the very desktop application developers that have requirements that the Modern API's restrictions interfere with or do not fit within the appstore model at all. Based on this, Microsoft needs games, but it has already screwed over the independent game development community, which as I stated above has serious implications for the long term viability of their appstore. They have also hung out to dry the desktop application developers, the same ones that have ensured Windows' dominance as a workstation and content generation platform. It will certainly be interesting to see if Microsoft's executives are mentally flexible enough to realize this, or if they really think that they can build a platform that will be successful for the long term by crippling existing strengths to fixate on short term revenue growth, which is what is likely to be so tempting about the appstore model.

Source: http://reactos.org/node/637

As fellow Windows developers, what are your thoughts on this? The author agrees with my perspective perfectly.

[Max Norris]

Well, I can see where he's coming from with XNA... rather puzzled by that one too and rather poorly executed. But for my line of work anyway, which is purely desktop (forms and console based,a mix of C# and C++) and web stuff, I personally haven't been impacted in the slightest. In fact, their latest toolset (VS2012) has been working extremely well for me, and overall quite happy with the new features and tools that were added. I agree with a majority of the article but not at all with the last paragraph.. nothing's been shoved down my throat or crippled in any way as far as desktop development goes, certainly not "left hung out to dry", if anything it's improved quite a bit. XNA was a stupid move, but there are other alternatives for indie game developers, and that's including XNA in VS2012 if you fudge the install... unsupported but not hard to do, and obviously won't do jack for the modern UI.. it's still got the same platform support as 2010. Of course if the powers that be at Microsoft suddenly go brain dead and pull the "killing off the desktop" thing that some bloggers like to go on about (in general, not this specifically) then that's another story, and I'll be the first one to kick it to the curb...but I'll believe that one when i see it.

[Torolol]

yeah, like hell corporates would post their internal apps on MS controller appstores.

something THIS obvious, becoming obvilious to apple-envy stricken Microsoft.

[BannanaNinja]

I don't see killing XNA as a big deal. I have been using SharpDX and its been great. It has a very similar high level API to XNA, but it also gives you low access to the native DirectX parts if you wish. It's also something like 10 times faster than XNA. The only problem is its not supported on Xbox, but it is on Windows 8 (WinRT and desktop) and Windows Phone. I do believe however that the next Xbox should support WinRT and if that's true then it will work on Xbox as well.

Silverlight I haven't used (I don't do web development) so I can't say much but it does not seem to have a replacement. Of course, with browsers finding the "magic" of HTML 5 they seem to be moving off of plug-ins anyway.

[Andre S. Veteran]

The problem with Microsoft is they don't seem to know where they're going, and there's a lot of internal fighting going on between the Windows and Dev division. Windows wants to push Windows and Dev wants to push .NET. After telling us for 10 years that the future was all .NET and technologies built on top of .NET (XNA, Silverlight, WPF, etc), now it's WinRT and the ****ing "C++ Renaissance" or however they're calling that nonsense. Of course the Windows team loves C++ because that means code written directly on top of the OS, that doesn't mean it's what developers need. Developers need productive, interoperable and safe languages on top of a comprehensive, consistent, well-documented and portable (as much as feasible) API. All this talk about performance on tablets is largely a red herring.

Meanwhile they let XNA developers on the fence for 2 years before admitting that the API is dead, they're still "investing" in WPF and desktop app development but given how Modern-centric Windows 8 has been so far it's not clear where they really intend to go with the desktop. And I doubt they know it themselves.

I'm still a firm believer in .NET but the message from Microsoft is sort of confusing and a bit worrying. On one hand .NET is still "supported" and "evolving" and "first-class" and all these reassuring words, on the other hand all the marketing and enthusiasm is on the new native APIs and that C++ is getting ****ing lambda expressions, and we're not seeing the performance and bug fixes we should see in WPF, and they killed off Silverlight and XNA. I understand Microsoft has, after all, limited resources, and cannot go all-out on every technology, but I still feel like there's quite a bit of poor planning and most importantly poor communication going on.

Oh and the way they managed XNA and ended up letting it die is very, very sad. Right now there would 2 times the games on Windows 8 Store if XNA was promoted and worked out-of-the-box for it. Yeah there's MonoGame which sort of works but it's nowhere near the ease of setup and deployment as if Microsoft officially supported it. They had a great API, great documentation, and great traction from the community, they just ****ed up and it's inexcusable.