11 Mai 2013



A perspective: developers vs Microsoft

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 pissed 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 cock-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 pissed 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.

Kommentare (12)

  • anon

    Nice post! :)

    Mai 11, 2013
  • anon

    As far as I know, Windows 7 and 8 also use old API together with new (http://msdn.microsoft.com/en-us/library/windows/desktop/hh920508(v=vs.85).aspx). So developers can rely on both old and new API.

    As for phone and tablet... Microsoft is completely wrong following modern trends this way.

    P.S. by the way, the article is really wonderful, Z98, thank you for your efforts and explanations!

    Mai 12, 2013
  • anon

    First class article. I for one am still a VB6 dev at heart and looking for a stable platform that will keep my old WIN32 apps going. I gave up on MS years ago because every tool I have picked up and learnt has been deprecated. The only MS tool I now use is Windows. I wish to abandon it as soon as poss. ReactOS would be my natural home after MS has gone...

    Mai 12, 2013
  • anon

    @Yaraslau, yes, Win 7 and 8 use the old API too, but in that API there's no new itch scratched, and is probably there only for backwards compatibility.
    The point of the post is it only got better for tablet and smartphone apps developers, while the same or worst for everyone else.

    Mai 13, 2013
  • anon

    Although this article mentions the great break in desktop development and tablets, regarding Windows 8 and the deprecation of XNA and Silverlight, there was another great break in the past. Not in the absolute volume, but in the relative volume.

    Windows Phone 7 broke abruptly from Windows Mobile (aka Pocket PC in older versions). This break was much worse than having the desktop as a Modern square, where you still have all Win32 applications running. Every Windows Mobile application, or Windows CE application that happened to run just as fine in Windows Mobile (intentionally or not), became obsolete.

    Obsolete to the user whenever he'd have a new phone, but much worse, obsolete to the developer, since there was no porting path, no recommendations or documentation like the .NET and Win32 comparison, no development tools (VS 2008 had Windows Mobile in more expensive editions, VS 2010 brings Windows Phone 7 and removes Windows Mobile entirely in a single version) and certainly no incentive to remain with Microsoft in this field (user base: iOS, Android, Blackberry, Symbian; WP7 was starting from scratch too late!).

    So, it seems that Microsoft isn't just betting and showing the finger, they're throwing money away in the attempt to stay relevant facing Apple's breakthrough, and lately Google's/Samsung's breakthrough, and the finger is being shoved as in "not only we don't actually care about you [developer, software company], we'd like you to stop doing whatever you're doing in the near future, because now we're aknowledging that our own yesterday's platform sucks in the shadow of today's cliché platform", which of course no one knows how long it'll last.

    Sincerely, I believe we're living a dark age of applications. All the years invested in making applications, documents, etc. talk to each other are now completely thrown away with single icon, single purpose, totally sparse and no embedding (exception: a browser pane! go figure!) "applications". I mean, we're back to a time where every application is similar in scope to the calculator application, and the only thing you may do is hook into what the underlying OS allows the user to do: seaching.

    This is the main reason Facebook wants to run fullscreen, owning your Android: basically because they cannot do it otherwise. Remember the notification area? Remember the "sidebar"? Remember inserting an AutoCAD sketch in a Word document? Forget that with these new "platforms", they're made to raise commissions to the application store's owner, not to make you a buck based on merit (probably on luck and marketing), and most certainly not to give the user a better experience (unless "better" means they control it).

    So, the great breaks will continue, not just in Microsoft, washing away the efforts of making heterogeneous ecosystems, towards complete control from OS/store providers and single-purpose isolated "apps".

    Mai 16, 2013
  • Bild des Benutzers Robert97906

    I agree Z98!

    Over the last few years I have built two pieces of desktop software using WPF (and was briefly excited about Silverlight as a possible mechanism for porting the application to the web). These are powerful, beautiful and easy-to-use (ihmo!! :-) thanks to the flexibility of WPF. These are complex applications both with very large code bases - around 300,000loc. One of these is scientific research software designed for use in research facilities, and not at all appropriate for Metro! Unfortunately (?!) both pieces of software highly leverage the great strengths of WPF, so switching to a different GUI paradigm would be difficult (and Mono doesn't support WPF - sigh).

    I'm not exactly sure what path to take in the long-term with my software. But I'm really starting to feel like relying on Microsoft while Steve Balmer is at the helm is a dangerous thing to do.


    Mai 20, 2013
  • anon

    All of who do work on workstations, follow a little bit a different path people who use consumption devices like tablets & phones. Companies who make applications for all of us who "work" on a PC, are not to happy about this change. I am not either. I have spent years following the platform. I been faithful in new releases and spent my money on tools to do what I do. I am done. I can get my programming done in Linux, and for what I can not do there - a Mac will do. I am seeking greener pastures. I can not invest in a platform that seems to have abandoned its purpose as a workstation and it's future is quite vague. I have new machines with lots of RAM & storage and I am not getting the performance I need out of Windows 7. Things are painfully slow as far as my work flow. I admit 8 is bit faster and the foot print is smaller, but Redmond does not have both feet on the ground anymore. This is my opinion and I respect others, I do not want it to be this way.

    Mai 20, 2013
  • anon

    Microsoft seems to have totally forgotten corp developers. I know a LOT of companies that are just making the move to Win7 right now, never mind win8, and they have totally written off win8/winRT. They don't want to play games, they are HAPPY with the VB6 UI, never mind the .net winforms UI. Getting to THINK about WPF/MVVM is hard, (and I'm NOT talking the developers - I'm talking the management). Microsoft doesnt seem to want to realize that the Fortune500 (a large part of their bread and butter) thinks about applications in terms of a decade. A couple of years ago, I left a company that was still maintaining, and had in every day use, a VB3 app, because the cost of porting to even VB6 was too high (there was a lot of use of a spreadsheet VBX that changed object models when it went to the OCX)

    They don't want 'rich UI' - they want programs that work. Heck, a lot of them won't even allow access to the internet for data security reasons

    Mai 20, 2013
  • anon

    Lot of developpers think so and i'm happy to see some have courage to write it.
    M$ used to give us better tools to produce good big desktop apps.
    In the past we used .net winform and we adopt Silverlight recently with big satisfaction.
    20 years of investment on the same app...and the road stop here, without any word or hope to have one, without issue.
    I wrote to M$ : they never gave answer.
    I don't know if i will find energy and money to have a new start, but if i can, it will be without M$ : NEVER MORE !
    People who think so must tell it ! M$ must hear it !

    Mai 20, 2013
  • anon

    As a seasoned native C and C++ developer I have fiercely defended Microsoft over and over again to many of the OSX and Linux crowd, people repeating bad information and to many who just didn't have a clue as to what they were talking about. With the one exception being the .NET Framework. I have never cared for that for many reasons.

    So, you can imagine the great levels of consternation I started to experience about 2 - 3 yrs. ago when I found Microsoft getting as whimsically crazy as a teenage girl pop star.

    That was about the point I started to say to myself, it's time for something different because I do not like the many different roads MS is going down at all. And worst of all, I like to spend my time writing code, improving upon applications that I've already written and adding new functionality. I DO NOT like trying to keep up with Microsoft's latest technologies and worrying that a new OS release is going to obsolete or break my applications or cause a major rewrite.

    They've made me feel like (to go back to my teenage girl pop star reference) every new technology is a "LOOK at me :)", "DON'T look at me :(" undertaking. A complete waste of time and effort, again and again.

    So I started to look into Fedora and the more I've learned the more I've liked it. I've been enjoying using CodeBlocks IDE, minGW compiler and for a cross-platform window and x-window api using GTK+ and wxSmith. Yes, I still have to have to boot into Windows for many things but I think it's worth the effort of learning Linux now because I NOW believe the future is in Linux. And Yes, as far as desktop software goes, Linux still has a long way to go to catch up to MS popularity. However, with the decisions that Microsoft seems to making under Steve Ballmer's leadership I believe they are setting themselves up for bad times at MS, not to mention all of us who develop applications.

    They have given us native C/C++ developers the middle finger over and over. Now I've started to give them back because simply put...I don't trust Microsoft anymore.

    I think this post was very well written and was glad to read it. If you look into the native C/C++ community you will find a GREAT MANY of developers out there feel the same exact way.

    Mai 22, 2013
  • anon

    I've experienced the same frustration... You've described it perfectly!

    Remember the old saying "fish rots from the head"? The solution for Microsoft is simple in essence: get rid of Steve Ballmer and his army of Yes-men before it is too late for everyone. But I'm afraid that will not happen soon enough and it might be too late already, the damage was done and too many are already alienated.

    I am coming from the .Net side and I'm impressed to hear this from native developers. You have my respect!
    I've been 25 years on the M$ stack. Well, lesson learned. It is not the corporation, it is the people behind it. And, unfortunately, it is not the thousands of well-meant workers in the trenches - it is the likes of Ballmer that have the power to make it or screw it up...

    Agree that M$ must hear much more of this!

    Jun 05, 2013
  • anon

    I have developed primarily for Microsoft products for many years.  (I have also done some very minor Linux programming.)  I have done native, .NET, and XNA development of both games and desktop applications.As one of the XBLIG developers who was impacted by Microsoft's poor treatment and neglect of the system and, finally, their complete dropping of what was the best game development pipeline that they had developed, I am utterly disgusted with Microsoft at this point.  Your point concerning Metro/RT development and expecting XNA developers to cross over was right on point.  XNA was an easy to learn system that made game development much easier than programming with any of the iterations of DirectX.  They hyped the system and, when it did not suit what they saw as their needs, dropped it.  As a developer, I will not switch to the Microsoft App Store.  If they dropped XNA like they did, what is to stop them from dropping the App Store and Metro/RT when they release Windows 9?  That is before I get started on them treating XBLIG like the stepchild of game development.

    Jun 17, 2013
This blog post represents the personal opinion of the author and is not representative of the position of the ReactOS Project.