Now that Aeon Timeline has been shipped off to the Mac AppStore folk for review, I have a bit of dead time while I wait for their approval. Since I say on my website that I am considering a Windows version, and I am now getting several emails a day asking for one, I have spent the evening researching my options.
The results is not pretty: Microsoft has created a mess of half-finished technologies, with no clear path to move forward. If I am wrong in this, I would dearly love for a more experienced Windows developer to come along and point this out.
What follows will be somewhat more technical and developer-oriented than my usual blog posts. I have tried to keep it simple, but apologies if I lose any non-developers along the way. The implications, in turns of support for different operating systems, may still be relevant to you.
Contents:
– I am not an evangelist: I welcome superior knowledge.
– Starting out in Mac OS X
– Starting out in Windows
– Will anyone other than Microsoft bet on Windows 8?
– WPF: Best of the rest or lame duck?
– Why does Microsoft make it so hard?
– An appeal: which path should I take?
I am not an evangelist: I welcome superior knowledge
In full knowledge there are many developers on both platforms with far more knowledge than me, and not wanting to start a flame war due to my own ignorance, I will lay my background bare so that readers can decide the value of my comments and correct/criticise me accordingly:
- In my regular job, I use and develop in Windows, but we develop specialised computer vision applications in C++ (.NET is far too slow for the purpose), which is far removed from this consumer-targeted GUI project.
- I have used Macs as my home computers since 2006. Yes, there are negatives and downsides to either OS, and either parent company, it is just a personal preference.
- Around four years ago, I started working on Aeon Timeline for Mac OS X. I do not consider myself to be an expert Cocoa programmer, but I am comfortable that I have the knowledge to implement anything I need, or the ability to find and learn anything I am lacking when it becomes required.
In short, I believe I am a good developer, but my knowledge of particular frameworks and methodologies is always as shallow as I can get away with to do my job well.
In order to explain how Microsoft is making it difficult, let me first explain my first experiences programming for Macs.
At the time I began, there were two frameworks provided by Apple: Carbon, which was used for legacy applications, but was being phased out; and Cocoa, recommended for any new Mac OS X app moving forward.
If you wanted to develop for Mac OS X, it meant using the Cocoa framework, and learning to write in Objective C. I bought a book, worked through one or two of the most basic examples, and started writing my application within a week, learning more as required. Aeon Timeline is the result, and I am pretty proud of it.
If I wanted to switch to writing a version for the iPad, I would be using much the same technology: Objective-C and a slightly different Cocoa framework for iOS.
Everything is unified. It may not be perfect, you may not agree with Apple’s totalitarian stance on the AppStore and their 30% cut, but as a developer, at least you have confidence: Mac OS / iOS programming is Cocoa programming. You know that you are going to be supported.
Unlike my start with Cocoa, I actually have Windows programming experience, so you would hope that my experience of returning to Windows would be better. Instead, Microsoft has created a complete mess that divides and dismays even seasoned Windows programmers. Even finding out the trade-offs between the approaches is hard, since Google turns up more posts from 2008 than 2012.
Bearing in mind that I will be developing an application from scratch to be released a year from now and supported for years down the track, Microsoft presents me with the following options:
- Create a Windows Forms Application using .NET. My own experience is that .NET’s memory management is too slow, but that was for specialised, intensive video processing, so that experience may be largely irrelevant.
Still, this is the old technology. It is still supported, and probably will be for some time, and it could probably be bent to my needs, but the message from Microsoft is to use the newer technologies that will be better supported into the future.
- Use Windows Presentation Foundation (WPF). This was to be Windows Form’s replacement, first introduced in Vista, and carried on into Windows 7, but XP support was possible. Skipping over the technicalities, it was a modern framework encouraging better design principles, and seemingly exactly suited to the kind of clean, attractive user-friendly application that I wish to make.
From what I can tell, the general consensus among its adopters was that it showed a lot of promise, but was never given the time and effort by Microsoft to mature to the level of Windows Forms. And Microsoft seems to have moved on again.
- The newest option is a combination of WinRT and some HTML/Javascript stuff that has apparently evolved beyond the web technology I last used in 2002. This will be coming in Windows 8, as part of their new Metro interface (their latest tablet assault against the iPad).
I haven’t downloaded a Windows 8 preview yet, but most feedback I have read implies it is a pre-beta level step backwards from WPF, attempting to do much the same thing from scratch.
Will anyone other than Microsoft bet on Windows 8?
Naturally, Microsoft is pushing WinRT as the latest must-learn technology. Having invested heavily in Windows 8, much of its success will depend on developers taking up WinRT to create the apps to entice consumers onto the platform.
But where is the incentive for the developer? Windows 8 isn’t out yet, and there is already a lot of conjecture that consumers may ignore it the way they ignored Vista or Windows Phone.
Even allowing for the fact it may take a year before I release, why would I risk developing for a Windows 8 market that may not exist, and at the same time ignore backwards compatibility for XP and Win7 users that are asking for a Windows version now?
There will be plenty of developers waiting for customers to make the first move, just take a look at the comments and links in this thread: http://joshsmithonwpf.wordpress.com/2012/03/20/does-anyone-actually-care-about-winrt/
And given Microsoft’s treatment of WPF, their previous must-learn technology, is there any reason to believe this incarnation is going to last any longer? Will it too be superseded by another half-baked replacement within 3 years?
WPF: best of the rest or a lame duck?
Depending on which blog post or comment you read, WPF is either dead in the water, or still the best technology that is available for development right now.
Further development seems unlikely, and while WPF is supported on XP, Win7, and Win8’s desktop mode, I am not sure that I can rely on its continued existence if Windows 9 is hastily released in two years time.
Windows Forms, at least, is a 10+ year old, mature technology, and there are so many business applications built with it that Microsoft won’t risk dropping the technology completely. But it seems such a shame not to embrace something more modern and design for the future.
Why does Microsoft make it so hard?
I really would like to know.
I already have the User Interface design. I already have the complex date and layout algorithms done. I have already gone through alphas and betas and three years of customer feedback to reach an application I am happy with.
The hardest part of developing a Windows version should already be behind me. If Microsoft was Apple, I would have picked up Cocoa and knocked out a tiny prototype of the basic interface functionality in the time it has taken me to write this blog post. If I was porting the other way, I would already be sketching class structures and writing code.
Instead, I am stuck at the starting line, crippled with doubt. Any of the technologies could have the best long term future. Any of them could force me to abandon them and start again from scratch with a different framework 3 years from now. As a single developer working on a niche product, that is a big risk to take.
If Microsoft had a single clear direction, they wouldn’t be forced to support so many disparate technologies. It could be so much smoother for everyone.
An appeal: which path should I take?
If there are any Windows developers who have made it this far into the post, I would welcome your suggestions.
In brief, I have created a timeline application. From a technical standpoint, this means drawing potentially hundreds, or even thousands, of events and other data onto a large scrollable area. This involves drawing a lot of lines, a lot of rounded rectangles, and a lot of text next to or inside those rectangles.
The user can click and drag around events to different locations, they can zoom in or out of the timeline to adjust the time scale (modifying the width of the scrollable area, and the placement of the lines etc).
It means that I need a framework where I can perform hundreds/thousands of drawing operations inside a Canvas/View, drop that inside a Scroll View, using a framework that can handle it efficiently so that the display remains fast and responsive as all the scrolling and zooming takes place (eg. it would need some way for me to only perform the drawing inside the visible portion of the scroll view, if that doesn’t come as default behaviour).
Various split views, text fields, additional windows and toolbars etc. will go along with this, but I am assuming that the fast, efficient drawing will probably be the most likely deciding factor.
So, which framework would you suggest?
Is WPF, with its focus on user interfaces, the best option, or is it too slow? Do .NET forms provide the drawing capability required? Would it be fast enough? Am I better off dodging the Microsoft frameworks altogether and using wxWidgets or Qt instead?
Even links to good, up-to-date resources on the trade offs would be appreciated.
Aeon Timeline 
This is why many Microsoft devs, such as myself, are leaving for greener pastures. You have summarized the state of affairs very well, in my opinion. Microsoft is very volatile. They crank out a programming platform and immediately start on its replacement. I wish I could paint a prettier picture for you, or say it ain’t so, but I would be lying.
Thanks Josh, that’s what I feared.
So what would you suggest now that I have Windows users knocking down my door?
Embrace the new Metro and spurn Windows 7 users, start with WPF (not a pretty picture painted by Patrick below) or .NET Forms, or go with a 3rd party toolkit like Qt which may be forever chasing Microsoft’s tail, but at least be consistent?
There is no good answer, in my opinion. Patrick’s advice seems reasonable, but as he pointed out, it’s a crap shoot to target Win 8. If targeting Win 7 is your priority, I suggest using WPF but for an app like yours, but having it in an app store is probably a preferable way to collect payment and implement deployment. Making consumer software for Windows these days is a guessing game.
I’ve been deeply involved in developing the Windows version of the Mind Mapping application NovaMind (http://www.novamind.com). NovaMind started out as a pure Mac application. I joined the company when we created the first Windows version (based on C++/GnuStep/C#/GDI+/Winforms). We soon transitioned to a pure C#/GDI+/Winforms approach. When WPF was announcend it seemed to be the best step forward and I have spend 5+ years creating the WPF version you can download today. If you want to know what is possible with WPF when it comes to a visually rich application download it and give it a try.
Anyway, I would *not* recommend WPF for this type of application. Although it is probably possible to achieve acceptable (not outstanding) performance it is a very painful process. WPF is hard to learn, it has a very steep learning curve and I personally believe that with Windows 8 WPF has lost all appeal for independent software developers.
First, and most importantly, you cannot sell a WPF app through the upcoming Windows 8 store. If you take the risk to develop a Windows version you might as well play in the *lottery* that is Windows 8. With WPF or Winforms you don’t get to participate in this possible future for Windows.
The story behind Windows 8 Metro style apps (based on WinRT) is actually evem more messed up than you think. You don’t have just the HTML/JS approach you can also write your Metro style app in C++/DirectX or C#/VB/C++/XAML. The XAML mentioned here is a poor re-implementation of WPF/Silverlight and a lot of important features that you would require for your app are missing. You can find out more about my initial assessment here: http://social.msdn.microsoft.com/Forums/eu/winappswithcsharp/thread/380b4b7b-72e2-4435-b7f7-0d2afca4eac0. Things have improved a bit since then but I still think that XAML is not a good choice for the type of app you are trying to create.
Personally I think HTML/JS is, surprisingly, a good choice. I was extremely sceptical about this but after investigating the power of modern HTML/JS I’m pretty sure you could do your app in HTML/JS. Probably by combining the power of Canvas/SVG/HTML.
IE10 is extremely fast when it comes to HTML. Most things are hardware accelerated (which is not at all true for Winforms for example).
I would like to mention here that I was never interested in HTML/JS. I’ve always been someone preferring ‘native’ technologies but I am more than surprised of what is possible with HTML/JS today.
The other bonus is that you *can* create your HTML/JS Windows 8 app so that it should be fairly easy to make it available on the web or maybe Chrome store etc. Even in the unlikely case that Windows 8 somehow fails to be successful, you will not lose your investment if you go with HTML/JS
Hi Patrick,
Thank you very much for your insight. It is nice to hear from someone else who has moved in this direction.
It is a shame – WPF siounded interesting, and I was looking forward to getting away from WnForms.
Does Microsoft have any plans to bring the HTML/JS technology back to Windows 7? Or does that choice mean Win8 only?
Metro style apps are Windows 8 only and will not run on Windows 7. If you go with HTML/JS you might want to consider offering some form of web version of your app too in which case you could make it available for Windows 7/XP users through that.
As an experienced Windows (WPF, WinForms, WinRT, JavaScript/HTML) I would say that your assessment is pretty much correct.
Unfortunately for an application such as yours, it probably makes sense to have both a Win8 Metro and a regular desktop version of your app. This means that Win8 users can use it in both desktop and metro modes (I guess you are aware of the Win8 split personality? http://www.scottlogic.co.uk/blog/colin/2011/09/windows-8-an-os-of-two-halves/), but also Win7 users can still use your app. Unfortunately writing an app that spans both desktop and metro is a challenge, there are numerous subtle differences that frustrate.
I just want to respond to Patrick\’s point above:
\”The other bonus is that you *can* create your HTML/JS Windows 8 app so that it should be fairly easy to make it available on the web\”
I\’m afraid this is not the case. Win8 HTML5 apps use a Microsoft specific UI layer to render the Metro UI, and also make use of a Microsoft specific services / utilities layer, WinJS. This means that you end up creating a non-portable JavaScript app. I see this as something of an oxymoron!
You *can* develop without the WinJS non-UI libraries, using jQuery, or other portable JavaScript libraries instead. Although this is something I have not tried personally. My experience comes more from the phone side of things, writing cross-platform apps with PhoneGap:
http://www.scottlogic.co.uk/blog/colin/2011/09/developing-windows-phone-7-html5-apps-with-phonegap/
Anyhow, if this hasn\’t turned you off the whole project, the most important decision you need to make is whether you want to make a desktop app (for old-Windows and Win8-desktop-mode), or a Win8 Metro app, or both. This will influence your further decisions.
Colin E.
Hi Colin, thanks for the link. A very interesting read – I knew that both Desktop and Metro apps would run, but I am surprised that even IE will need to be shipped in two different versions.
It seems like Microsoft is trying to blunt Apple’s lead in the tablet market by blurring the distinction between the two, and trying to pull everything back under the one Windows 8 banner, presumably so they can market its integration.
With Lion and Mountain Lion, Apple has tried to incorporate successful features of iOS into their Mac platform – but they haven’t lost sight of the fundamental differences between the two. It seems like Microsoft has, and what the tablet users want, everyone gets.
I wouldn’t have a problem with needing to write two different versions – one for desktop, one for tablets – if they were presented as distinct platforms. At least we could have confidence that the “Legacy” Desktop system wasn’t going away.
At present, if forced to choose between Desktop and Metro, it sounds like Desktop is the safer option, at least as a starting point. I can adopt Metro/WinRT separately if it gains the traction that Microsoft hopes, rather than become a Guinea Pig for Microsoft (like Silverlight developers have been).
Which comes right back to choosing between WinForms and WPF. Which would be better for the kind of drawing and quick response times I am after? And which will be obsolete first?
Creating a desktop app first sounds like a sensible first step. I understand the comment about not wanting to be a Metro-Win8 Guinea Pig! (and don’t mention Silveright!)
Don’t worry about WinForms or WPF becoming obsolete any time soon. One this MS is excellent at is supporting older technologies.
I would recommend using WPF if it provides the performance you need. It is a much more elegant U framework and fun to use. It also means that if you choose to go for Win8-Metro-WinRT in the future, your code will be more portable, as will the skills you have learnt.
But performance *could* be an issue. The only way to be sure is to create a test application.
Patrick makes a good point, you can create HTML5-apps for WinRT that have minimal WinJS dependence. However, you would be on the bleeding edge of technology. Whilst this can be a lot of fun, I get the feeling you want to play it safe.
Good luck, let us know what you choose.
Colin E.
Hi Colin, Good point to point out that Metro style apps are fundamentally different from Desktop apps. Regarding your point about WinJS. You only need WinJS for Windows 8 specific features such as implementing Share contracts, updating your application tile and implementing the app bar. It is absolutely possible to create a Metro app with minimal reliance on WinJS and it is not hard to abstract things so that the core of the application is portable.
It would be interesting to see Steven Sinofsky answering these questions. Very good summary. My personal opinion is while RT is young I get the impression MS know if they come out with another framework in 3 years, developers will jump ship even faster than they are now.
Just in case you guys do entice Steven Sinofsky to comment on my blog, I have turned off moderation. Wouldn’t want to keep Steven waiting.
More seriously, I usually blog about version releases and receive no replies. I am quickly discovering moderation doesn’t work when people actually want to talk about something.
Interesting post and question. To me the answer is simple: If you are not targetting Windows 8 only, WinRT is a non starter. Therefore you are left with either WF or WPF really. I would say go for WPF every time, particularly for graphical apps rather than pure LOB apps, but there are many other benefits.
I don’t really understand the issue about being left behind etc. – WPF apps are going to be supported on Win 8 just as well as windows 7. I would be surprised if that’s not the case in windows vNext either – as you say, there’s too many apps out there. As WinForms and WPF are both part of .NET I can’t see it getting dropped any time soon.
At the same time, WinRT user interfaces are coded in XAML – the same XAML you use in WPF, with a few new controls. So from a UI perspective I really don’t get this “fragmentation” business. From a dev perspective, get clued up in XAML – then you can migrate over to WinRT in the future with minimal pain.
You may want to take a look at http://sharpdx.org/. This is a more hard-core solution than using only a higher level UI framework, but should give you control and performance.
This you can use with both Metro and Desktop Windows apps.
( http://channel9.msdn.com/coding4fun/blog/Sharpening-your-Metro-CXAML-projects-with-DirectX-and-SharpDX )
Being a long time Windows developer, I share your frustrations! It’s a really weird “message” MS is sending developers, they do some great stuff, but also some stupid stuff and silly decisions, at least seen from the outside. The last couple of years they become more secretive, and done weird things like killing Silverlight without telling developers about it! OTOH, lately they have open sourced, or otherwise made the source available, for lots of good stuff, so there are both ups and downs from a Windows developer’s perspective.
MS does have some good technology for developers, like C# 5 with async, which I suspect will make it much easier to write high performance apps for Windows 8 and Windows Phone 8 utilizing multicore, than Objective C (for OSX/iOS) and Java for Android.
MS even have a rather brilliant programming language (with full source code available under the Apache licence), blending the best from OO and functional programming, F#, which have the potential to become a big hit as it is a much more “beautiful/powerful” language than say C#, and not as complex as say Scala, but somehow most of the MS evangelists don’t seem to know about it or are afraid to mention it.
I have never used Objective C, but from what I see, isn’t it very hard to write apps handling concurrency and utilizing multicore with it, even harder than with Java? (I know about things like the GCD, but that’s not enough to make it easy)
“HTML 5” is also not exactly brilliant from a developer’s viewpoint, we’re forced to use (or at least compile down to) a language which where thrown together in two weeks, having lots of design bugs. And CSS is a black box which cannot be extended by developers, not to mention that nowadays we have to do stuff like:
-webkit-box-shadow: 0 -1px 5px rgba(0,0,0,0.20);
-moz-box-shadow: 0 -1px 5px rgba(0,0,0,0.20);
-o-box-shadow: 0 -1px 5px rgba(0,0,0,0.20);
-ms-box-shadow: 0 -1px 5px rgba(0,0,0,0.20);
box-shadow: 0 -1px 5px rgba(0,0,0,0.20);
IMO most of the mainstream developer technologies could need a reboot. 🙂
Thanks, I will take a look. Not that it is an issue here, but my biggest concern with these sorts of 3rd party frameworks is whether they look “native”. Coming from the Mac environment, I am probably more sensitive, as I think Mac users become more accustomed to the one look and feel, at least more so than Windows users.
To be honest, I haven’t had to deal with multicore in Objective C. I was able to optimise my drawing code sufficiently in other areas that it wasn’t necessary.
Although now that I have users trying to pull thousands of phone records into my application (rather than the timeline tool for writers/historians I envisioned), it is something I plan to investigate in a future update.
Whether multicore becomes more important with whichever Windows framework I adopt, I will have to wait and see.
Of course, my programming day-job of writing computer vision apps means that I am dealing with threads constantly, so I usually have to talk myself out of it when it isn’t required, rather than the other way around.
Interesting discussion.
I was in a similar(ish) position almost exactly two years ago. In June 2010, I was hired to head up the development of a brand new UK payroll software app for Windows, to replace the company’s ageing Visual Basic 4 version. It was to be developed from scratch with no ties to old technology, and I spent a considerable amount of time researching the framework options.
Even then, I felt frustrated with Microsoft’s direction, as you are today.
At that time, Visual Studio 2010 and .NET 4 had just been released a few months prior. Windows Forms were seen as a mature framework, but definitely old technology. WPF received some good updates for .NET 4, but the development community would have liked to see a lot more, including work on performance issues and other important areas (some annoying bugs from 3.5 were not even fixed!), though there was a general feeling that it wasn’t actually going to be sorted out any time soon, if at all. Silverlight seemed to be the topic of most of the developer evangelism coming from Microsoft, and there were multiple discussions on the web about WPF dying, and Silverlight taking its place, which I never understood. I also looked into a few other third party frameworks like Delphi, and even looked into using old-school C++.
I ended up settling on WPF, primarily because it offered some great features and frameworks that very much appealed to me. I figured that, sure, WPF wouldn’t last forever, but it would for the foreseeable future. The general consensus among developers was that XAML itself was very much relevant, and would continue into Microsoft’s future frameworks (which has been the case).
I still don’t regret the decision to use WPF. Although it was a surprisingly steep learning curve and required new programming skills and patterns, it has been a pleasure to use. I really like WPF and how it can often make the very complicated tasks very simple. My main issues have been (i) performance and (ii) bugs in the framework. But I battled through and am happy with the result (my app is at http://www.brightpay.co.uk, if you’re interested).
When the details of WIndows 8 finally emerged, my first reaction was a common one: “What programmer in their right mind is going to target just Windows 8, and so lose sales to Windows XP, Vista and 7 users?” I figured I’d keep an eye on it, but by no means bet on it.
Along with WinRT, Microsoft have also released .NET 4.5. To WPF, it adds some good features, fixes a lot of bugs, and addresses some common performance issues. Great!, I thought. I’ll still keep an eye on WinRT, and move to .NET 4.5 in the meantime! Except that I can’t. Here’s the catch: .NET 4.5 is incompatible with Windows XP. Can you believe it? It’s an in-place upgrade of .NET 4.0 (meaning 4.0 and 4.5 can’t run side-by-side), yet it won’t run on XP. I have a lot of Windows XP customers. I am not going to take a big hit in sales, just for the sake of a .5 upgrade.
And so, I stuck using the technology from 2010, and I can’t see that changing until mostly all of my Windows XP customers upgrade. That really frustrates me. Two years ago, I thought I was on the edge, using the latest and greatest. Now, two years later, I feel like I’m using old technology with no obvious upgrade path.
I am not happy with the option of creating two versions: a WPF version, and a WinRT version. Creating, maintaining, marketing and supporting two Windows versions?? That would be loads more effort, and confusing to customers. If I’m going to make a second version, it would be for OS X.
And so, to answer your question: what should you use? Well I think you have the same choice as me: WinRT (targeting WIndows 8 users only) or .NET 4.0 (targeting Win XP to Windows 8 users). If I was in your shoes, and I was keen to get programming right away, I’d go for WPF in .NET 4.0. WPF introduces you to XAML (which is in WinRT as well) and provides a much more graphics-friendly framework than Windows Forms. It will be a steep learning curve for you and you may have to do some fancy coding to get the performance you want in your large horizontally scrolling timeline controls. But it would work.
Or, you could start building your second OS X app and let the Microsoft Mess™ come to some sort of conclusion over the next year or two before joining in.
Whatever you choose, good luck!
Hey, I am an evangelist at Microsoft and I’d love to help you with this. Shoot me an email? chris.bernard at microsoft.com
Hi Chris,
Thanks for your offer. I have sent you an email, and look forward to your response.
Nice article, I understand your plight. Basically, the only misinformation you’ve been given is that WPF is slow. A lot of people complain about this, but they just haven’t learned enough about the technology to implement their ideas the “correct” way. WPF has a much, much steeper learning curve than WinForms, and it is easy to dig yourself into a performance quagmire. But, that is just a matter of learning what is going on. There are protests out there that demand Microsoft somehow “fix” this performance issue with WPF, but I don’t think there is much to fix. “Fixing” most of these problems would limit WPF’s power in other ways. Long story short, it’s easier to make a slow app in WPF than it was in WinForms.
I do, however, agree that Microsoft has more-or-less moved on from the technology. They’re not placing any emphasis on it anymore, and instead have moved on to WinRT (Metro for .NET).
So, where does that leave you? If you need to target Windows Vista or XP, you have to avoid Metro. And, because they both allow designing with XAML, I find that it is easier to transition from WPF to Metro than from Winforms to Metro. Thus, I would go with WPF if I had to target XP/Vista. If platform isn’t a concern, I’d move straight over to Metro. Note that some critical components of Microsoft’s XAML-based languages (WPF/Silverlight) are missing from Metro, so you may need to learn what those are when porting from one to the other. Also, in the beta anyway, Metro felt much more like a thin wrapper around unmanaged code than any other .NET technology. This meant cryptic exceptions and such (they may have improved this in the later builds).
It seems everyone has dismissed Silverlight as an option, but I wouldn’t. I’m not talking about for the web, either. SL5 for LOB apps or other types of apps can do just about anything you want it to do. Rocky Lhotka (whose CSLA framework I use) and other folks have written thoughts on reasons to perhaps use SL over WPF, as that may provide an easier migration path to Metro. http://magenic.com/Portfolio/WhitePaperWindows8DevelopmentPlatform.aspx
I’d like to suggest a completely different direction.
For years I’ve developed on various platforms like SPARC, Windows, Linux, and of course Mac OS X. Many of my previous employers have mandated that the work be done on the Windows platform. I’ve gyrated through tons of MFC, Borland, Turbo Pascal and a half a dozen other inferior products including .NET technologies. Many fellow Windows developers have tried and failed to convince me that today’s flavor of Visual Basic, C#, C++, or vastly superior to yesterdays technology. But they aren’t.
One underlying factor to this sad fact has been Microsoft itself. They continue to cling to some of the oldest source-code known to man. And it will remain buggy until they decouple their UI from their OS.
That is why I applauded Apple when they announce that Mac OS X would be their operating system for many years to come.
Now, I’d suggest that you look into Nokia’s QT frameworks. It’s multi-platformed and compiles for the native environment of choice. I have several apps I’ve developed for all 3 platforms, Mac, Windows, and Linux. One source code can be used with very little tweaking. The nice part of QT is that it is very well featured from GUI to CORE.
Take a look at Trolltech.com. You might find it helpful.
I have over 20 years of Windows app dev experience in C++/C# using MFC/Qt/WinForms/WPF. As you are 1) An experienced C++ developer, 2) Concerned primarily with desktop (as opposed to tablet) apps, on Mac and Windows, 3) have an existing Mac desktop app and want to come up with a Windows version ASAP, I second ScottC and recommend Qt.
With Qt, the widgets look/feel native, graphics performance is good with QGraphicsWidget, etc. You could even maintain one source code for both your Mac and Windows (desktop) versions. Even if you used Qt only for the Windows version, it is the best C++ GUI framework on Windows. And this will get you to market much faster than WPF, which has a steep learning curve as everyone else has also said. With C++ and Qt, you don’t need to worry about startup performance or excessive deployment issues (such as installing .NET 4 on XP).
The one thing no one has mentioned is that WPF has one strength in that it is the only one that is dpi independent. So when PC’s start getting Retina displays, your WPF app will just look correct. However, I don’t think this single advantage is enough to win over Qt.
I am also choosing a technology to build a LOB app, but unlike you, the tablet market means more to me (as it should to all desktop devs since the growth is so huge), and I am seriously considering HTML5 and ASP.NET MVC (possibly with Kendo UI). HTML5 is the only true cross platform framework, in that it runs on desktop, mobile, and web.
It’s a tough one certainly. I feel your frustration. I wrestled extensively before building Scrivener for Windows and Linux in C++ Qt. I just couldn’t force myself down the Java or .Net routes, or stomach any of the other proprietary paradigms offered – I wanted 100% complete control. C++ and Qt has given me the granularity to do pretty much anything. It will not be hard to build what you have done in Objective-C with Qt. I’d be hopeful that some bright spark ports Qt Quick to WinRT (I doubt this would be too onerous either – JS -> JS). Qt 4.8.x today will compile Windows 7 binaries which still run on Windows 8. Given that no one knows if Metro will be a success or not for MS and it’s user base, my guess is that Qt would be good enough regardless but until the dust settles and you can make a more informed decision you will not know how good.
You can develop the Microsoft solution on your Mac under OS X with Qt Creator too which is kinda cool – Lee
This may also appease some concerns:
http://www.computerworld.com.au/article/433160/digia_buys_qt_app_framework_from_nokia_plans_android_ios_windows_8_ports/?fp=4&fpid=18#closeme
After reading all the below comments, I think you have made some fundamentally wrong assumptions regarding how Metro functions. You talk as if it’s either WinRT or WPF, as in either desktop (XP to 7) or Metro (8). However, Metro and Desktop are as different as OS X and iOS, only on the same computer! As Metro is designed for touch-input, ie. tablets.
In my opinion, you should consider your target audience; Have they requested a Windows version? Yes. Have they requested a tablet version? Not as far as you’ve told us.
So start by doing a regular desktop version. I recommend WPF if it’s fast enough, and considering how long they have supported WF, it will be supported and in use for a long while yet.
Then, if you decide you want to, you could add a Metro version later. Maybe only a viewer to begin with, as touch interfaces are great for this type of panning and overviews. The great part of this being the same computer(tablet) is that when sitting at the desk typing, you have a dock with screen, mouse&keyboard etc, and are using standard desktop UI. Then, when you leave the desk, you pick up the tablet, sit down in the couch and open the Metro version designed for touch input, with fingerscrolling etc etc,right where you left off! Same computer, same files(!), different UI.
My point here being that you have to see how different parts of the OS have to be used in different ways. Start seeing the possibilities, not the limitations 🙂
(Sorry if this sounds cross, it really isn’t, just hard to make sense when writing long things on a phone)
Best regards, Asgeir
Pingback: Follow up to: ‘Why Does Microsoft make it so hard?’ | Aeon Timeline
“From Mac to Windows: Why is Microsoft making it so hard for developers?
| Aeon Timeline” was a terrific article and I really
was indeed really pleased to read it. Thanks for the post,Theresa
I agree with you 100%. I have been doing C++ for 15 years and I am totally baffled by the way that MS is “reinventing” C++. A huge disapointment.
Pingback: Follow up to: ‘Why Does Microsoft make it so hard?’ | Aeon Timeline Development Blog