back to article Pity the poor Windows developer: The tools for desktop development are in disarray

When Microsoft came up with Windows 8 a couple of years ago, the message was clear: the future is tablet-shaped. The Windows desktop is still there, but not much changed from Windows 7 - some things went backwards, such as translucent “Aero” windows, available in 7 but gone in 8. Now the company is scrambling to fix its desktop …


  1. Anonymous Coward
    Anonymous Coward

    Probably why software developed for OSX tends to be better.

    1. Hans 1 Silver badge

      Yes, but only works on a specific release ... upgrade to Mavericks and lots of stuff no longer works, upgrade to Yosemite and hardly anything works.

      1. robin thakur 1

        This is nonsense. I upgraded to both and everything works with no issues. Troll much?

      2. This post has been deleted by its author

      3. Katz

        Yep, this is nonsense. I use PC's and Macs, no bias either way. But I can say categorically that there aren't many compatibility issues. Depends what you use exactly, but there really aren't many issues. I've had none personally.

    2. Lee D Silver badge

      "tends to be better"?

      Not at all sure about that assertion, and I have tried to get both Eclipse and XCode environments up and running on MacOS. In the end, it's easier to just use the Mac as nothing more than a cross-compiler and then apply appropriate OS X glue in XCode to make it work. I wouldn't like to develop on a Mac for a living.

      And, actually, upgrading to Yosemite can easily break things development-wise. Have a look on Google - quite a few XCode setups break on upgrade. I don't hold that against Apple necessarily - it's like expecting your Windows 7 build environment to move to Windows 8 seamlessly - a reasonable expectation until you start dealing with real-life commercial operating systems.

      Honestly, try and get something as simple as a small SDL-based app compiling on Windows, Linux and Mac. Mac will cost you more from the start, and cause more hassles. Strangely, even bringing across existing Eclipse configurations to all three platforms can be fraught with trouble.

      1. wikkity

        quite a few XCode setups break on upgrade

        I completely agree. NEVER, upgrade xcode until the project is shipped or you have plenty of slack to waste time getting a project that builds again. I've lost count the number of corrupted files I've left with (no I can't revert from scm as xcode simply corrupts them again next time).

    3. Daniel von Asmuth Bronze badge

      What software was developed for the Mac?

      You mean Microsoft Office and Adobe Creative Suite?

  2. AndrueC Silver badge

    Until a year ago I'd only ever worked with Winforms. And I moved to Winforms from Borland's VCL so arguably I've got over 17(*) years experience with it. I had a chance to experience WPF earlier this year and ouch the learning curve is steep. I'm still unconvinced about the benefits of WPF over Winforms. I don't deny that there are advantages but I have yet to find a need for them and I don't appreciate the extra time it takes to produce a WPF application. Or the clunky nature of the form designer. Frankly it was like going back to an early version of Borland's tools.

    As for MVVM - meh. You can do MVC with Winforms and that's most of the battle fought.

    (*)Started using it with Delphi 2, then Borland Builder(**) then C#

    (**)Yeah that's right, fellow C++ers. I've been using RAD for my GUIs since 1998 ;)

    1. DragonLord

      I migrated to wpf about 4 years ago now, and once I got over the learning curve of how wpf windows fit together and learnt how to work with wpf rather than trying to shoehorn wpf into winforms (Things like using hierarchical data templates and providing a pre-built tree rather than trying to walk the visual stack to find out what's selected). Over the last year we've been learning MVVM, and now the value of WPF really shines. As by divorcing the screen from the code means that we can implement customisable screens (load xaml from a file or database on startup) without it breaking the window. What we've also found is that the extra time spent setting up an MVVM application pays itself back in spades later during maintenance.

    2. Irongut

      Since 1998? Pfft I was using RAD in 1995 with Delphi 1! ;)

      I've tried WPF and I'd love to say it works and I use it but It doesn't and neither do I. I've stuck with WinForms except where there is a requirement for WPF in the project. As you say WPF is clunky and feels like using a form designer from the 90s. But then a lot of .Net and Visual Studio feels like its still trying to catch up with Delphi 7.

      1. DragonLord

        The biggest problem I had with switching to wpf was that in order to use databinding properly requires a massive shift in the way that you think about problems. I gave myself many many headaches while learning in order to Grok it. I'd imagine that you'd have the same sort of headaches learning functional programming if you're used to procedural. (never tried functional)

        The main piece of advice I can give about WPF is that the UI designer is really there for modifing properties that are a pain in the arse to type in manually. Everything else should be done in the xaml text editor (with the visual bit still showing).

        Also lean about mc:ignorable and d:datacontext as they will make your life so much easier.

      2. AndrueC Silver badge

        Since 1998? Pfft I was using RAD in 1995 with Delphi 1! ;)

        Me too now I think about it. D2 supported Win32 and my first Delphi experience only targeted Win16. But anyway that was Pascal. What I meant by the second footnote was that I was using RAD from C++. The vast majority of Windows C++ developers have only ever used MFC.

  3. Hans 1 Silver badge

    >rendering of XAML controls [...] change[s] with each minor .NET release (which are now in-place upgrades, thereby breaking your clients' apps when they install a simple update)

    I was told on here that .Net backwards compatibility was awesome ...

  4. Andrew Commons

    Situation Normal - (SNAFU,TARFU,SAPFU,FUBAR,....)

    This is symptomatic of the software industry over the years. Revolution rather than Evolution.

    You have a set of tools that work reasonably well, experience with them has resulted in incremental improvements, defects in new developments are dropping.


    Do While i < Age of Universe

    Enter Moses i.0.

    'Hey man, look at this new platform, it is sooo cool!'

    And the multitudes are amazed and flock like lemmings to this new technology

    that has no documentation or tool support but is the FUTURE!!!

    Over time experience accumulates and tool support increases.



    We are doomed.... stick with COBOL :-)

  5. Phil W


    In my opinion it's all been downhill since Visual Studio 2008.

    I'm not really a developer but I tinker occasionally, perhaps it's down to me because I use it so rarely but I find that Visual Studio 2010 and 2013 seem like they had more time spent on making them look shiney than on making them useful or straight forward to use.

    1. robin thakur 1

      Re: Downhill

      I only develop for SharePoint, and the massive shifts in MS's focus to develop for Azure, almost making their systems less customisable and less powerful has not gone unnoticed, although this has the noble goal of making them more stable. The obvious conclusion I draw from this article is that fewer and fewer Windows applications will be developed for the desktop in the coming years due to MS not having focussed on it and not wexactly making it easy for evs to know where to start. I would also say that if they think developers are going to target Windows Apps for the Store instead, they've got another thing coming. As Windows computer shipments drop ever lower, it makes far more sense to develop the next big thing as a web or mobile app which has a much bigger audience thaan Windows. MS has dropped the ball too many times, asking people to learn new stuff like Silverlight which then falls by the wayside after a short time but still is kicking around as an API.

    2. adam_peter_hu

      Re: Downhill

      Yeah, they had more time spent on making them look shiney than on making them useful, yes, of course:

  6. LDS Silver badge

    Embarcadero went fully the mobile route, forgetting Windows desktop too.

    Even third party tools like Delphi in many ways abandoned Windows desktop development (and it was never really strong for server development) chasing the mobile route, because 'everybody' thought money were there. Also, to reduce costs, development has been moved to Romania and Spain, resulting in quality issues and lack of critical skills in areas like compiler technology.

    While Delphi became very late to support many Windows desktop features and put lots of efforts in developing its own cross-platform GUI, MS put more roadblocks in Windows development when access to APIs needed for Windows Store App was severely limited for third party development tools.

  7. }{amis}{ Silver badge

    WPF = Pain!

    As a full time C# WPF developer i have to agree the behavior of the XMAL syntax is opaque at best. I would sell my left leg for a decent reference but even O'RELLY don't publish a decent and up to date WPF/XMAL book!!

    1. G Watty What?

      Re: WPF = Pain!

      Try XAML rather than XMAL. You might get more results.

    2. Jonathan 27

      Re: WPF = Pain!

      They publish programming reference books now? I thought all that stuff was just on the internet. Hold on for a second while I go pay big publisher money for an already-outdated version of something I could get off the internet for free.

  8. Sean OConnor

    I'd love to get back into developing games for Windows but it just seems to be a swamp of bewildering technologies. All I want really is a way of loading a PNG and drawing it on the screen with hardware acceleration of some kind, and I want the game to run on any version of Windows and be available in some sort of App Store. I don't think that's too much to ask for!

    But as far as I can tell I'd need C++ for DirectX and hope the user has the correct version of D3DX9_nn.DLL installed that I'm asking for just so I can simply load a PNG, or C# if I wanted to use Direct2D (not sure, there doesn't even seem to be a single book on Amazon on Direct2D). Should I stick to the Windows API I'm so familiar with, or learn Windows Forms or WPF? .NET? Glad I never bothered with MFC. And do I really need to make separate .exe files for a desktop and an AppStore version FFS! Using different versions of Visual Studio!?!?! I could have a look at Unity but it seems overkill for simple 2D games, or I've read up on SlimDX and SharpDX but do I want to risk committing to some technology that might go obsolete in the future?

    I think whoever is in charge of this at MS should be told their number one priority is to make sure that it's a piece of piss to be able to write some simple game and the choice of technology is a no-brainer. Otherwise their AppStore is going to look like a ghost town. Oh, it does.

    Rant over. Back to iOS development now for me, because Apple have made it just so easy.

    1. Tom_

      Have a go with Unity. It does feel a bit like overkill, but it also makes all the compatability stuff very easy. They've also been adding a lot more 2D specific features over the last year, so you'll probably find a weekend is enough to get everything set up, work through a few tutorials and have a playable 2D game running. One that you can export as a PC executable or for the web or to iPhone or Android, etc.

      It might feel like overkill, but a day or two with it will let you know whether it's going to make game development on the PC fun for you again.

      1. Anonymous Coward
        Anonymous Coward

        Have a go with Unity. It does feel a bit like overkill, but it also makes all the compatability stuff very easy.

        I haven't tried programming in Unity (yet) but I've seen some pretty neat things done in it. We use it at my workplace as a frontend to SCADA.

    2. ShelLuser


      "I think whoever is in charge of this at MS should be told their number one priority is to make sure that it's a piece of piss to be able to write some simple game and the choice of technology is a no-brainer."

      Uhm, but it already is a nobrainer where technology is concerned. A mere Google search for "visual studio gaming" would point your direction towards the XNA Game Studio environment.

      I don't develop games myself, but from what I can tell this has been around for quite a while already. It's basically yet another approach of their "write once, use everywhere" doctrine since this platform should allow you to develop for all Microsoft gaming platforms (Windows, XBox & Windows Phone).

      As I understand it its a replacement for DirectX; more of a framework (like so many others) which more or less abstracts some of the requirements. Here is an interesting discussion with regards to the differences between the two platforms.

      Although I do agree with your comments; Microsoft makes certain things a whole lot harder then they need to, I also don't think it applies here.

      1. Sean OConnor

        Re: @Sean

        But according to Wikipedia:

        According to an email sent on 31 January 2013, XNA is no longer actively being developed,[2] and it is not supported under the new "Metro interface" layers of Windows 8 nor on the Windows RT platform.[3]

        Maybe I'd have gone for it if I hadn't been so busy moving away from Windows to iOS, but maybe I'd be kicking myself now as it looks like yet another technology that has hit a dead end.

    3. Chris Ashworth

      As said, Unity is fine for simple 2D games, if you've any game dev experience you should be churning out prototypes in a matter of hours, and hitting all the major platforms.

      1. Sean OConnor

        I'm sure Unity is amazing but I'm wary of committing to one technology like that. I write my games now so all the game and user interface code is device independent, and there's just a tiny bit of device specific code that does nothing more than start the app and send screen taps and timer ticks to my device independent code, and knows how to load and draw a PNG.

        I've been selling my games since 1994 and I don't want to hit a dead end. Who knows if something will better Unity in 10 years time and Unity will stop being developed? I'm banking on C++ still being around when I come to retire in 20+ years time and I'll just keep porting my games to whatever device(s) are popular over the coming years.

        If MS could make a simple way of doing that small amount of device specific stuff I need I could start porting for their AppStore tomorrow. But maybe they've given up caring and they're relying on Unity now cos there aren't many old fart programers like me left?

    4. Lee D Silver badge

      SDL 2.

      Problem solved.

      Loading a PNG is a one line command (install the SDL_image module!). Blitting it with hardware acceleration is a couple of lines one-off window setup and one blit command. You're a couple of lines away from a complete, usable OpenGL context for everything it does.

      It'll run on any Windows. It'll run on Mac OS. It'll run on Linux. It'll run on a multitude of third-party systems including obscure handheld consoles and homebrew for big-name video game machines. It'll take the burden of audio, music, controllers, etc. off your hands.

      You can program against it in just about any language imaginable. I do my stuff in C99 still. And you can see it used in Steam games, emulator projects (DOSBox, etc.), iPad apps, you name it.

      Best of all, you don't have to be tied to any one development platform either.

      (Currently writing a game using C99 and SDL, via Eclipse IDE, targetting and having full development environments on Linux, Windows and MacOS).

      1. Nick Ryan Silver badge

        Was probably put off by the earlier SDL which was a dog on many fronts. The v2 revision fixed so many annoyances that if anybody tried it before, it's worth having another look now.

  9. codejunky Silver badge

    For me

    I know I will be the odd one out for saying it but the best thing MS ever produced for me as a developer was VB6. I dont care that some people hated the syntax or whatever, it did the job with the minimum fuss and I could bang out quality projects quickly and with almost no compatibility issues depending on how much interaction was required with the windows API.

    As a personal preference I gave up on the .NET versions as it provided little improvement to me but a lot more hurdles. I did dip into a few languages and they had their benefits but if I needed a GUI I couldnt find better for a windows machine.

    1. btrower

      Re: For me

      Me too. Had MS stuck to their knitting and properly upgraded VS6 we would all be light-years ahead of where we are now. Practiced VB6 developers can bang off a non-trivial working application including installation routine and documentation in a day or two. Except for Delphi I don't know of any IDE that has come close to VB6. It is still by far the easiest to use.

      VB6 as a language has some serious annoyances and conflating forms and applications is brain-damaged. However, none of its warts are show-stoppers and in a pinch you can always just call COM objects or C/Assembly DLLs if you need more function or better performance.

      I think VB6s big failing, ironically, is that it was so easy to use.

      1. Rob Gr

        Re: For me

        VB6 was very bad in other ways. String-handling in particular had notoriously bad performance. It had a habit of reallocating the string every time you appended a single character. One of our applications had to have large chunks rewritten in C++ because performance dropped off exponentially due to string handling.

    2. Zane

      Re: For me

      Hm - I agree that VB is nice and simple for... simple things.

      I am not sure what you mean by "development" - but when I think of development, I am thinking of applications of 10,000 or 100,000 LoC, or bigger. Have ever tried things like that in VB? Have you ever seen a VB applications written by a team of 20 developers jointly?

      All examples of "VB tools" I have seen were either really really simple, or they grew into a complexity that could not be handled with VB - in other words: they were dumped when they started to become useful.


    3. A N Other

      Re: For me

      Yes VB6 programming was probably the best all round. .Net added some improvements but lost out in other ways - particularly in speed and ease of development.

      But Microsoft chose to have a revolutionary rather than evolutionary approach (if you can call cloning Java a 'revolution'). With hindsight an updated VB6 programming language would have been better than VB.Net - and it would have retained compatibility with VBA programming too.

  10. ButlerInstitute

    Assuming an application is an application .....

    "developers should look at web, mobile and cross-platform "

    That rather depends on what you're developing. Not everything is an office application, or a domestic one. We do multi-PC networked control systems. They can't be web (though they are networked). They don't make much sense mobile. In many ways they are more like hardware than software.

    But we do include desktop applications, with GUIs. At the moment they may be Qt, or WIN32.

    1. Alan Bourke

      Re: Assuming an application is an application .....

      "developers should look at web, mobile and cross-platform "

      They should, and they should be prepared for the colossal, monumental ballache of achieving something with a UI that even comes near what can be achieved with a native desktop application that works across platforms and browsers.

      Horses for courses. Browser-based applications are still a long, long way from being the silver bullet here.

    2. Blitheringeejit

      Re: Assuming an application is an application .....

      >>We do multi-PC networked control systems. They can't be web (though they are networked). They don't make much sense mobile.

      So you don't want to run your control apps on tablets which people can carry around the shop-floor with them? Mobility can be useful on a LAN too.

      So you might want to look at Cordova, using JS sockets for the network comms. Such stuff can't work on t'internet, so doesn't fall into your definition of "mobile" - but it works nicely for control apps running on a LAN, and gives you the kind of socket-level comms you'll be used to.

      And the same code will run (or only need minor tweaking) in a desktop PC browser.

      Network sockets are an oft-overlooked feature in JS, because everyone thinks of it as an internet thing. Shame it's such a bastard to develop in. :)

  11. xyz's not bloody difficult

    You have a user a point A, a datastore or datastores not at point A and a method of communication between A and not A and no matter how hard you try, you ain't gonna get away from that fundemental.

    What we should be worrying about is security and speed (both in terms of development and user experience). I did "forms" for a bit in the late nineties and went all webby as soon as I could and now we're back to forms that are called apps with webby communications, but in the 15 odd years that's passed we're all still arguing the toss about how to connect to an effin datastore.

    Maybe the corporates (MS, Apple et al), who seem determined to keep drilling their own glory holes to stick their knobs through, could come up with some shared economic and techno model that provides a foundation for us building stuff on top of. Interfaces are always going to change and that's the exciting bit, but I'm fed up of all this "this is the new messiah" way of development and the neo nazi methodology crap that gets flung around by people to try and cover the fact they haven't got a clue what they're doing. I like new shit which is why I like IT, but I know the difference between good shit and just plain shit. Rant over.

  12. Andy Non

    I've given up writing applications for Windows full stop.

    I've been a Windows developer for thirty years. On the side I also develop and sell specialised software via my website. However, it is no longer viable to continue so I've switched to developing applications for Linux instead. Several reason have contributed to me abandoning Windows:

    1. The cost of keeping up to date - the cost of the latest and greatest Pro version of Visual Studio.

    2. Lack of direction from Microsoft where their development tools are going. It seems to be one random direction and set of technologies after another.

    3. Diminishing sales for the Windows desktop environment as more people switch to Android based tablets.

    4. Microsoft have thrown the baby out with the bath-water. If I attempt to download and install one of my desktop applications to a Windows 8.1 computer it warns me that the software is relatively unknown and may contain malware. (It doesn't) and finally, after downloading the software it refuses to install it and hides the install link. You have to click help to reveal the install button. It puts the fear of god into me about installing my own software, so I can guess how the average end user feels about installing such low volume lesser known software. I know there is a lot of malware out there, but crying wolf with all such software is just another nail in the coffin for small Windows developers.

    So in short, Microsoft make it expensive for me to keep up to date with their bewildering array of development technologies and they also try to scare people off from installing the resulting applications anyway. So I'm done.

    1. DragonLord

      Re: I've given up writing applications for Windows full stop.

      Have a look at the new Visual Studio community edition - it's free and is identical to the professional edition if you're a lone developer. (no msdn subscription included)

      Also the problem that you're having with your installers is probably that they're not signed with a certificate from a known authority.

    2. Colin Critch

      Re: I've given up writing applications for Windows full stop.

      Just get a code signing cert and sign the exe and dll. Package with an installer using the code cert there. Warning will vanish.2 years for 120 quid.

  13. Pascal Monett Silver badge

    "One answer is that this is now the wrong place to focus"

    So, basically put : Microsoft is telling developers that they're holding it wrong ?

    I seem to remember a video of Monkey Boy screaming "Developers! Developers! Developers!".

    Well, it seems like it really is the beginning of the end for MS.

    1. Anonymous Coward
      Anonymous Coward

      Re: "One answer is that this is now the wrong place to focus"

      " it really is the beginning of the end for MS."

      Where have you been the last couple of years?

      It's way past the *beginning* of the end, even if there is still quite a way to go yet.

  14. Anonymous Coward
    Anonymous Coward

    I can understand the Silverlight debacle; they tried to replace Flash and didn't notice that plugin-based RIAs were going to disappear altogether as a category in a few more years. It was a mistake, but this sort of stuff happens.

    But whoever came up with WinRT needs to be fired.

    Personally, I'm sticking to WPF for native development, and screw "Modern" apps. I'm NOT climbing another learning curve for something that may or may not still be alive in three years time.

    1. Anonymous Coward
      Anonymous Coward

      My understanding

      is the WinRT guys have already been fired. Last I heard, the head guy was writing some blog on shipping crappy products, then learning from the experience or something..

  15. This post has been deleted by its author

  16. elisix

    Define desktop development

    The problem is: define development... "Desktop" development is a mare magnum!

    Do you need to write a driver for desktop machines? Forget fancy RAD and frameworks!

    Are you entitled to spend some millions of dollars to write the next "3d free world" blockbuster game? Squeeze all power from video cards or you are doomed - but if you are writing the next AngrySomething pay per win clone your requirements will be entirely different.

    Are you writing some spaghetti code for a small accounting company? Better stick with whatever conforms their standards and is manageable, performances probably does not matter for indexing a few k invoices, but they will call you back every time they see a new message on screen!

    Are you writing a real time software for PC controlling some dangerous machinery or a software to customize hobbyist's remote control (or to sync karaoke)?

    Are you writing next version of Firefox or OpenOffice with worldwide collaboration (but you barely know how other people code), or are you writing Windows internals (and you have to conform only to your unit coding style)?

    Are you writing a social network front-end (yes, now you can use WinRT on desktop too!) or a number crunching application for the MIT?

    The definitive development (that now means also collaboration, and server/cloud side management) environment does not exists, so IMHO if a few tools ages and rusts a bit is not a big hassle for most developers.

    But now MS please start seriously developing a real tool for real programmers, YOU don't use WinRT for building Windows and Office due its limitations by design, don't insult US offering it as only (or primary) development environment.

    1. adam_peter_hu

      Re: Define desktop development

      The whole developer world whine for years about how Win32 is overbloated, needs restart, etc. - see WinRT, you got what you asked for. They cut the fat you relied - sad thing. Maybe you have done it in an ineffective way for years?


POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019