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 …
This post has been deleted by its author
"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.
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).
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 ;)
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.
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.
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.
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.
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.
<code>
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.
Loop
</code>
We are doomed.... stick with COBOL :-)
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.
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.
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.
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.
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.
"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.
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.
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?
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).
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.
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.
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.
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.
/Zane
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.
"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.
"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.
>>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. :)
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.
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.
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.
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.
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.
This post has been deleted by its author
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.
"we'll switch to C# when it gets better"
Sitting in a billion dollar company with some product based solely on C# and with something of the order of 5,000 person years of dev in it and customers running their global businesses on it - I'd say it was good enough.
Not saying it hasn't be easy - but writing enterprise class/wide software will never be. But it did allow us to send all our screens etc to all manner of end points customers want - and are willing to pay for. Nice.
+1 for C# in the enterprise, particularly on the front end. I've worked in a number multi-billion dollar, >100,000 people enterprises that have huge deployments of extremely complex WPF based software.
The level of expressive power that WPF gives you per employee-year of dev effort *far* outstrips anything that can be produced with Win32. It's not even close. Hell, it's not even the same race.
Commonplace? In which universe? I have not recently seen a single one in a work environment (except those used as iPad stands at NBC News). The last Windows-based tablet I actually saw in a work environment was an older HP job, roundabout 2008 or so, and only used because one piece of specialized, hospital-internal software could no longer be ported to anything else because the developer had died and taken the source code more or less with him.
It's a Delphi Clone with all the bad bits left out. Therefore it's easy to write portable code for it which simply compiles on Linux, MacOSX and even Windows. And on each of those platforms you get a nicely statically linked application without any need to install.
Though I haven't tried it yet, it also seems to work for Android.
To be fair, Microsoft's offerings on the Windows development market never were on par with the rest of the industry. In fact up to the 3.x series of Windows it was not uncommon to develop Windows software under DOS and then just run it on Windows to test it. Even after that, Microsoft offered Visual Basic as its rapid application development tool. It required a framework to get your software to run and was essentially interpreted. Borland, for example, offered Delphi as a competitor product, which, just like Lazarus today, gave you fully compiled statically linked binaries you could just start.
the guy on the thread clearly said he is
"calling while the "TouchDevice.ReportDown/Move/Up" are invoked in another thread."
meaning he is trying simulating touch events, I assume for testing, not saying it
shouldn't work as documented but it's hardly a fatal flaw, unless your a complete unitestard.
WPF has been doing touch since before ballmer lost his mind and set loose that ftrad sinofsky.
remember the 20,000$ surface coffee table? it used WPF surface SDK, notice its always trolls and
uniformed that have the big problem with WPF, if your afraid of WPF now, get ready to be terrified baby boys,
not only is WPF the only way to make proper High DPI desktop WPF app it's perfect for Win10.
pity the metro/modern/universal kids that fell for the marketing if you want, but the trolling by some who know little to nothing about WPF just makes them look frightened and ever more desperate. I don't see any real WPF experts complaining.
"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."
I'd say, more accurately, they thought they could displace Flash; but in their arrogance, they failed to notice that the Windows-only plugins that preceded Flash were displaced by Flash BECAUSE of it being ported to multiple platforms. They thought they could displace multi-platform Flash with Windows-only Silverlight, and use it as a disincentive against using anything but Windows to surf the web. HTML5-style functionality wasn't really a factor back when SL came out.
At the time SL came out, Flash supported Windows back to Win98, OS9, OSX, Linux, Solaris, and I think a few other UNIXes. Silverlight supported Windows 2000 on up. And a little later a somewhat buggy OSX port. Moonlight (based on Mono) doesn't really count, I tried it on Linux and it didn't actually work; I got ONE demo (that showed a cube) to load, a second demo that just showed a single triangle failed; I never saw a single Silverlight-based site (the few that there were) work under Moonlight before I removed it as a waste of space.
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.
@Tim I, addressed the touch "critical bug report" of , the test code was flawed, there is no touch bug in WPF, I was surprised with the WPF team response, I been doing touch for a long time with WPF going back to when the surface was a coffee table. the real problem WPF has is all the FUD it has endured a lot of which came from MS people with a vested interest in promoting there pitiful Metro/Toy/Tiles agenda. some are still clinging to the delusional that marketing can drive demand for inferior Tech when only superior tech can draw demand, you can't push a string. @tim take a look at "critical bug report" thread or the working code at https://github.com/DSkywalker/WPFTouchTests and try it for yourself, and maybe consider updating you article, thanks
I love WPF, which is useful because I make a chunk of my living from it. But this article is spot on - the whole desktop has been horribly neglected for years now. Moving to web front ends is fine for some situations, but it really doesn't work in, for instance, front office trading environments in banking, or in many other situations which require the sort of rich functionality that only thick-ish clients can manage.
Even after the U-turn with Windows 10, Microsoft is still struggling to realise the importance of looking after one of its main sources of revenue - enterprise customers wedded to the Windows desktop.
It's over two years since this was written and the path still seems to be unclear. In fact, this article is still one of the top results when you search for which stack to use for a Windows desktop application.
The most amazing thing is that "Win32 & COM" seems to have been promoted to a higher priority on Microsoft's landing pages than it was a couple of years ago.
despite all above mentioned, people continue using Windows OS devices and thus more and more apps are being developed, as stated by redwerk here https://redwerk.com/technologies/windows-app-development.
all in all, turns out that no matter how lame microsoft is, it still has enough chances to survive.
In a sense, perhaps.
Where people are able to make their own choices, many (most?) are happy to choose something other than Windows (phones, tablets, embedded kit, etc).
Where people can't make their own choices because the IT department says "it's Windows or it's not connecting", then eventually even the IT department will get the message.
Where people can't make a fair choice because MS are paying half thisvendor's advertising budget if thisvendor's adverts will say "thisvendor recommends Windows 10" (or whatever), then eventually maybe even the vendors (and the application providers) will get the message.
"no matter how lame microsoft is, it still has enough chances to survive."
How long do you think that will last?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
