Tag Archives: wpf

.net, development, software development, tech, windows, windows 7

The future of WPF for developers who need to support Windows 7

If you talk to Microsoft about what is new for Windows Presentation Foundation (WPF), a framework for Windows desktop applications, the answer tends to revolve around the Windows UI Library (WinUI), user interface controls for the Universal Windows Platform and therefore Windows 10, which you can use with WPF. That is no use if you need to compile applications that work on Windows 7. Is WPF on Windows 7 in effect frozen?

Not quite. First, note that WPF (and Windows Forms) was updated for .NET Framework 4.8, with High DPI enhancements and bug fixes. The complete list of fixes is here. So there have been recent updates.

Microsoft says though that .NET Framework 4.8 is the “last major version” of .NET Framework. This suggests that WPF on .NET Framework will not change much in future. WPF is open source; but the open source project targets .NET Core, the cross-platform version of .NET. In addition, there are a few features in WPF for .NET Framework that will never be ported, including XBAPs (XAML Browser Applications) – probably not something you care about.

The good news though is that .NET Core does run on Windows 7 (currently SP1 is required). You can see the progress of WPF on .NET Core here. It is not yet done and there are a few things that will never be supported. But when this is production-ready, it is likely that the open source WPF will run on Windows 7 and thus benefit from any updates and fixes made to the code.

From what I have learned here at Build, Microsoft’s developer conference, it is that .NET Core work that is currently top of mind for the WPF team. This means that WPF on Windows 7 does have a future – provided that .NET Core continues to support Windows 7. This proviso is important, since it is the decision of a different team. At some point there will be a version of .NET Core that does not support Windows 7, and that will be the moment when WPF cannot really progress on that operating system.

There may also be a special case. Presuming Edge Chromium runs on Windows 7, WPF may get a new Edge-based WebView control that runs on Windows 7.

Summary: WPF (and Windows Forms) on .NET Framework is not going to change much in future. If you can transition to using these frameworks on .NET Core though, there is more hope of improvements, though there is no magic that will make Windows 10 features available on Windows 7.

.net, development, microsoft, software development, visual studio

What is happening with desktop development on Windows and will WPF be upgraded at last?

1 Comment

Once upon a time all Windows development was desktop development. Then there was web development, but that was a server thing. Then in October 2012 Windows 8 arrived, and it was all about full-screen, touch control and Store-delivered applications that were sandboxed and safe to run. Underneath this there was a new platform-within-a-platform called the Windows Runtime or WinRT (or sometimes Metro). Developing for Windows became a choice: new WinRT platform, or old-style desktop development, the latter remaining necessary if your application needed more features than were available in WinRT, or to run on Windows 7.

Windows 8 failed and was replaced by Windows 10 (July 2015), in large part a return to the desktop. The Start menu returned, and each application again had a window. WinRT lived on though, now rebranded as UWP (Universal Windows Platform). The big selling point was that your UWP app would run on phones, Xbox and HoloLens as well as PCs. It was still locked down, though less so, and still Store-delivered.

Then Microsoft decided to abandon Windows Phone, a decision obvious to Microsoft-watchers in June 2015 when ex-Nokia CEO Stephen Elop left Microsoft, just before the launch of Windows 10, even though Windows Phone was not formally killed off until much later. UWP now had a rather small u (that is, not very universal).

In addition, Microsoft decided that locking down UWP was not the way forward, and opened up more and more Windows APIs to the platform. The distinction between UWP and desktop applications was further blurred by Project Centennial, now known as Desktop Bridge, which lets you wrap desktop applications for Store delivery.

Perhaps the whole WinRT/UWP thing was not such a good idea. A side-effect though of all the focus on UWP was that the old development frameworks, such as Windows Forms (WinForms) and Windows Presentation Foundation (WPF), received little attention – even though they were more widely used. Some Windows 10 APIs were only available in UWP, while other features only worked in WinForms or WPF, giving developers a difficult decision.

The Build 2018 event, which was on last week in Seattle, was the moment Microsoft announced that it would endeavour to undo the damage by bringing UWP and desktop development together. “We’ve taken all the UI stacks and merged them together” said Mike Harsh and Scott Hunter in a session on “Modernizing desktop apps” (BRK3501 if you want to look it up).

According to Harsh and Hunter, Windows desktop application development is increasing, despite the decline of the PC (note that this is hardly a neutral source).

image

So what was actually announced? Here is a quick summary. Note that the announced features are for the most part applicable to future versions of Windows 10. As ever, Build is for the initial announcement. So features are subject to change and will not work yet, other than possibly in pre-release form.

Greater information density in UWP applications. WinRT/UWP was originally designed for touch control, so with lots of white space. Most Windows users though have mouse and keyboard. The spacious UWP layout looked wrong on big desktop displays, and it made porting applications harder. The standard layout is getting less dense, and a new Compact Size, an application setting, will pack more information into the same space.

image

More controls for UWP. New DataGrid, Forms with data validation, Menu bar, and coming in future, Status bar, tab controls and Ribbon. The idea is to make UWP more suitable for line-of-business applications, which accounts for a large part of Windows application development overall.

New Windowing APIs for UWP. WinRT/UWP was designed for full-screen applications, not the popup-dialogs or floating windows possible in desktop applications. Those capabilities are coming though. We will get tool windows, light-dismiss windows (eg type and press Enter), and multiple windows on one thread so that they work like a single application when minimized or cycled through with alt-tab. Coming in future are topmost windows, modal windows, custom title bars, and maybe even MDI (Multiple Document Interface), though this last seems surprising since it is discouraged even in the desktop frameworks.

What many developers will care about more though is new features coming to desktop applications. There are two big announcements.

.NET Core 3.0 will support WinForms and WPF. This is big news, partly because it performs better than the Windows-only .NET Framework, but more important, because it allows side-by-side deployment of the .NET runtime. Even better, a linker will let you deliver a .NET Core desktop application as a single executable with no dependencies. What performance gain? An example shown at Build was an application which uses File APIs running nearly three times faster on .NET Core 3.0.

image

XAML Islands enabling UWP features in WinForms and WPF. The idea is that you can pop a UWP host control in your WinForms or WPF application, and show UWP content there. Microsoft is also preparing wrapper controls that you can use directly. Mentioned were WebView, MediaPlayer, InkCanvas, InkToolBar, Map and SwapChainPanel (for DirectX content). There will be a few compromises. The XAML host window will be rectangular (based on an HWND) which means non-rectangular and transparent content will not work correctly. There is also the Windows 7 problem: no UWP on Windows 7, so what happens to your XAML Islands? They will not run, though Microsoft is working on a mechanism that lets your application substitute compatible Windows 7 content rather than crashing.

MSIX deployment. MSIX is Microsoft’s latest deployment technology. It will work with both UWP and Desktop applications, will support Windows 7 and 10, will provide for auto-updates, and will have tooling built into Visual Studio, as well as a packager for both your own and third-party applications. Applications installed with MSIX are managed and updated by Windows, have tamper protection, and are installed per-user. It seems to build upon the Desktop Bridge concept, the aim being to make Windows more manageable in the Enterprise as well as safer for all users, if Microsoft can get widespread adoption. The packaging format will also work on Android, Mac and Linux and you can check out the SDK here.

image

Will WPF or WinForms be updated?

The above does not quite answer the question, will WPF or Windows Forms be significantly updated, other than with the ability to use UWP content? I could not get a clear answer on this question at Build, though I was told that adding support for .NET Core 3.0 required significant changes to these frameworks so it is no longer true to say they are frozen. With regard to WPF Microsoft Corporate VP Julia Liuson told me:

“We will be looking at more controls, more capabilities. It is widely recognised that WPF is the best framework for desktop development on Windows. The fact that we’re moving on top of .NET Core 3.0 gives us a path forward.”

That said, I also heard that the team would rather write code once and use it across UWP, WPF and WinForms via XAML Islands, than write new controls for each framework. That makes sense, the difficulty being Windows 7. Microsoft would rather promote migration to Windows 10, than write new UI components that work across both Windows 7 and Windows 10.

.net, apple, development, mobile, professional, software, software development, visual studio, web authoring, windows

Infragistics building cross-platform development strategy on XAML says CEO

1 Comment

I spoke to Dean Guida, CEO at Infragistics, maker of components for Windows, web and mobile development platforms. Windows developers with long memories will remember Sheridan software, who created products including Data Widgets and VBAssist. Infragistics was formed in 2000 when Sheridan merged with another company, ProtoView.

In other words, this is a company with roots in the Microsoft developer platform, though for a few years now it has been madly diversifying in order to survive in the new world of mobile. Guida particularly wanted to talk about IgniteUI, a set of JQuery controls which developers use either for web applications or for mobile web applications wrapped as native with PhoneGap/Cordova.

“The majority of the market is looking at doing hybrid apps because it is so expensive to do native,” Guida told me.

Infragistics has also moved into the business iOS market, with SharePlus for SharePoint access on an iPad, and ReportPlus for reporting from SQL Server or SharePoint to iPad clients. Infragistics is building on what appears to be a growing trend: businesses which run Microsoft on the server, but are buying in iPads as mobile clients.

image

Other products include Nuclios, a set of native iOS components for developers, and IguanaUI for Android.

I asked Guida how the new mobile markets compared to the traditional Windows platform, for Infragistics as a component vendor.

“The whole market’s in transition,” he says. “People are looking at mobility strategy and how to support BYOD [Bring Your Own Device], all these different platforms, and a lot of our conversations are around IgniteUI. We need to reach the iPad, and more than the iPad as well.”

“There’s still a huge market doing ASP.NET, Windows Forms, WPF. It’s still a bigger market, but the next phase is around mobility.”

What about Windows 8, does he think Microsoft has got it right? Guida’s first reaction to my question is to state that the traditional Windows platform is by no means dead. “[Microsoft] may have shifted the focus away from Silverlight and WPF, but the enterprise hasn’t, in terms of WPF. The enterprise has not shifted aware from WPF. We’ve brought some of our enterprise customers to Microsoft to show them that, some of the largest banks in the world, the insurance industry, the retail industry. These companies are making a multi-year investment decision on WPF, where the life of the application if 5 years plus.

“Silverlight, nobody was really happy about that, but Microsoft made that decision. We’re going to continue to support Silverlight, because it makes sense for us. We have a codebase of XAML that covers both WPF and Silverlight.”

Guida adds that Windows 8 and Windows Phone 8 are “great innovation”, mentioning features like Live Tiles and people hub social media aggregation, which has application in business as well. “They’re against a lot of headwind of momentum and popularity, but because Microsoft is such an enterprise company, they are going to be successful.”

How well does the XAML in Infragistics components, built for WPF and Silverlight, translate to XAML on the Windows Runtime, for Windows 8 store apps?

“It translates well now, it did not translate well in the beginning,” Guida says, referring to the early previews. “We’re moving hundreds of our HTML and XAML components to WinJS and WinRT XAML. We’re able to reuse our code. We have to do more work with touch, and we want to maintain performance. We’re in beta now with a handful of components, but we’ll get up to 100s of components available.”

It turns out that XAML is critical to the Infragistics development strategy for iOS as well as Windows. “We wrote a translator that translates XAML code to iOS and XAML code to HTML and JavaScript. We can code in XAML, add new features, fix bugs, and then it moves over to these other platforms. It’s helped us move as quickly as we’ve moved.”

What about Windows on ARM, as in Surface RT? “We fully support it,” says Guida, though “with a straight port, you lose performance. That’s what we’re working on.”

.net, microsoft, silverlight, software development, web authoring

Why Microsoft is scrapping the MIX conference

Microsoft is scrapping its MIX conference, according to General Manager Tim O’Brien:

we have decided to merge MIX, our spring web conference for developers and designers, into our next major developer conference, which we will host sometime in the coming year. I know a number of folks were wondering about MIX, given the time of year, so we wanted to make sure there’s no ambiguity, and be very clear… there will be no MIX 2012.

O’Brien says that MIX started in the aftermath of the 2005 PDC because:

there was a lot of discussion around our engagement with the web community, and how we needed a more focused effort around our upcoming plans for Internet Explorer, the roadmap for our web platform, the work we were starting on web standards (we were shipping IE6 at the time), and so on.

That is not quite how I recall it. PDC 2005 was the pre-Vista PDC, no, not the “three pillars of Longhorn” in PDC 2003, but the diluted version of Longhorn that was actually delivered as Windows Vista. One thing Microsoft really did get around this time was that design mattered. Apple had cool design, Adobe had cool design (and a strong grip on the designer community), but Microsoft did not.

Windows Presentation Foundation (WPF) was intended to win designers to the Windows platform, with its graphically-rich and multimedia-friendly API. In order to do this, the company needed to win designers over to the idea of using Expression Blend rather than Adobe Flash and Photoshop.

This was doubly true when Microsoft decided to bring WPF to the browser in the form of Silverlight, a decision that was announced at PDC 2005 and expanded on at the first MIX in 2006.

One of the things I recall at the first and second MIX events were groups of bemused Flash designers who had been bussed in by Microsoft to enjoy the lights of Vegas and learn about Blend.

General web authoring was a factor as well, as Microsoft sought to bring Internet Explorer back on track and to persuade web designers of the virtues of Microsoft’s web platform.

I enjoyed the MIX events. They were small enough that you could easily get to speak both to attendees and to the Microsoft folk there, and once you allow for the fact that Vegas is Vegas, the atmosphere was good.

As an attempt to appeal to designers though, MIX was a failure. It was all too forced; many of the people attending were developers anyway; and Microsoft itself included more and more developer content in ensuing MIX events.

The 2010 MIX was hijacked by Windows Phone 7, an interesting topic but drifting far from the original intentions.

It comes as no surprise to hear than MIX is no more. It is associated with WPF and Silverlight, neither of which are now strategic for Microsoft in these days of Windows 8 and the Windows Runtime (WinRT).

That said, Microsoft still has difficulty appealing to designers.

What next then? O’Brien says:

we look ahead to 2012 and beyond, the goal is to ensure that global Microsoft developer events are of the caliber that many of you experienced at BUILD last September, in addition to the thousands of online and local developer events we host around the world to support communities and connect directly with developers. We will share more details of our next developer event later this year.

image

.net, delphi, development, microsoft, professional, software development, visual studio

DevExpress developers ask for more Windows Forms, say Silverlight and WPF not ready

3 Comments

DevExpress, which creates add-on components and tools for Windows and Delphi, has posted its 2011 roadmap. This shows more convergence between components for Silverlight and WPF:

In essence, by the end of the year, the functionality of DXGrid, DXEditors, DXDocking, and DXRibbon will be the same across both platforms.

As for Windows Forms, or winforms, the roadmap says:

With regard to the Windows Forms controls, it is most likely that there will be a large number of smaller enhancements and new features rather than any large complex new control. The reason for this is simple: we believe that our offerings for this platform are very mature and robust.

Customers posting comments to CTO Julian Bucknall’s blog are not happy:

It is sad to see Winforms pushed back so much. WPF is still too slow on most computers for major apps and SL is not mature enough for a complete ERP app.

says Sigurd Decroos, while Heiko Mueller is more blunt:

Sorry guys, but with this roadmap I will not extend my subscription. I use only WinForms and ASP.NET and I’m not interested in WPF/Silverlight – WPF at this time for me is not suitable for my kind of applications (larger business Apps). Silverlight in my eyes is a dead technology – HTML5 is the future for rich internet applications.

Porting is also an issue says Ioannis Mpourkelis:

I believe that you should put more resources on the WinForms controls for 2011. Winforms is here to stay for many years, especially for the companies who want to support existing Winfroms applications. Currently it is impossible to port WinForms applicaitons to Silverlight and very difficult to port WinForms applications to WPF.

Check the full comments for more.

More evidence for the uncertainty around where Microsoft is going with its rich client API.

Update: Bucknall comments on this specific issue here.

.net, microsoft, professional, silverlight, software development, visual studio, windows

Where is Microsoft going with its Rich Client API? Microsoft drops some clues as developers fret

7 Comments

A discussion taking place in a Windows Presentation Foundation (WPF) newsgroup, in a thread called WPF vNext, shows how Microsoft’s confused rich client development strategy is affecting developers, and offers some clues about what is coming.

Developer Rudi Grobler, who posted on his blog some wishes for Windows Phone, Silverlight and WPF, describes his difficulty in discerning Microsoft’s direction:

The strategy for the future is very vague… I daily get questions about should I use WPF or Silverlight? Is WPF dead? Is Silverlight dead? etc…

Jeremiah Morrill describes his frustration with WPF performance:

Microsoft has known of WPF’s performance problems since the first time they wrote a line of code for it.  You will be hard pressed to find a customer that hasn’t complained about perf issues.  And you will not have gone to a PDC in the last few years and not hear folks bring this up to the WPF team. This is 3rd party info by now, but I’ve been told the issues I have noted have been brought up internally, only to be disregarded.

and remarks his frustration with what has happened to Silverlight:

Silverlight’s strategy USED to be about cross-platform, get-the-runtime-on-every-device-out-there, but it’s obvious that is not the strategy any more.  What happened to Silverlight on set-top-boxes?  Android? I read an article that some people saw it on XBox, but nobody has talked about it since.  Cross-platform with OSX has become symbolic at best.

Developer Peter O’Hanlon describes how the uncertainty has affected his business:

I run a small consultancy, and I bet the company on WPF because I could sell the benefits of faster development time for desktop applications. We have spent a lot of time learning the ins and outs of the platform and saw that Silverlight gave us a good fit for developing web apps. In one speech Microsoft caused me months of work repairing the damage when Muglia seemed to suggest that these technologies are dead and Microsoft are betting the farm on Html 5. We hand our code over to the client once we have finished, and they ask us why they need to invest in a dead technology. I don’t care what you say on this thread, Microsoft gave the impression that html 5 was the way to go.

[…] Muglia’s statement about the future being html caused serious issues for my company. We lost two bids because the managers didn’t want to commit to "dead" technology.

Microsoft’s Jaime Rodrigues, WPF Technical Evangelist, offers the following response:

You are telling us to improve perf in WPF. We hear this loudly and we are trying to figure how to solve it. Unfortunately, there are a few pieces to consider:

1)      First of all,  a lot of our customers are telling us to invest more into Silverlight.  Let’s say (again made up) that demand is  4-to 1. How do we justify a revamp of the graphics architecture in WPF.  This is not trivial work; the expertise in this space is limited, we can’t clone our folks to 5x to meet everyone’s needs.

2)      Let’s assume we did take on the work.  My guess (again, I am not engineering) is that it would take two years to implement and thorougly test a release.  At the stage that WPF is at, a rearchitecture or huge changes on the graphics stack would be 80% about testing and 20% about the dev work.    It is not a trivial amount of work.   Would we get the performance you want across myriad of devices? We don’t know. WPF bet on hardware, and there is new devices out  there that are trading hardware for battery, weight, or simply for cost.  it would suck to do that much work, make you wait a long time, and then not get there. Let’s get real on the asks; you say "improve perf" but you are asking us to do a "significant re-write"; these two asks are different.

3)      By the time we get there, what will be a more powerful framework?  Silverlight, WPF, C++, or SuperNew.Next ??  we don’t know today.  We go back to #1 and look at demand We are in agreement that "customers" is the driving principle.

The WPF has looked at the trade-offs, and risk many times.  We are also looking at what customers need. Jer, to you it is all about graphics.  To many others, it is about data.  So, how do we serve all customers??
The strategy is exactly what you have seen/heard:

1)      WPF 4.5 is going to have some significant data binding performance improvements.

2)      We are not redoing the graphics framework, but we are doing a lot of work to let you interoperate with lower level graphics so that if you need more graphics perf you can get it, and still keep the RAD of the rest of the framework.

[…] Hope it helps; apologies if it does not, and again, wait for Rob Relyea or someone else to make it official.  That is just my 2c as a person who bet heavily on WPF but has seen the data that drives the trade-offs the team has to make.

This will be disappointing to former Microsoft evangelist Scott Barnes, who has initiated a Fix WPF campaign.

The problem though is lack of clarity about the strategy. Look at Rodrigue’s third point above. Nobody can predict the future; but what is Microsoft’s current bet? Silverlight, HTML5, or maybe SuperNew.Next – for example, the rumoured new native code UI for Windows 8 or some variant of it?

My own view is that the current difficulties are rooted in what happened with Longhorn and the fact that the Windows team abandoned WPF back in 2004. I’ve written this up in more detail here.

Lest this post be misinterpreted, let me emphasise that Microsoft has a good track record in terms of supporting its Windows APIs long-term, even the ones that become non-strategic. Applications built with the first version of .NET still run; applications built with Visual Basic 6 mostly still run; applications built for ancient versions of Windows often still run or can be coaxed into running. Build an application with WPF or Silverlight today, and it will continue to work and be supported for many years to come.

My guess is that events like the coming 2011 MVP Summit and Mix 2011 in April will bring some clarity about Microsoft’s mobile, tablet, Windows and cross-platform story for rich clients.

Update: Barnes has his own take on this discussion here.

microsoft, mobile, silverlight, software development, vista, visual studio, windows

Microsoft still paying the price for botched Vista with muddled development strategy

2 Comments

Professional Developers Conference 2003. Windows Longhorn is revealed, with three “pillars”:

  • Avalon, later named Windows Presentation Foundation (WPF)
  • Indigo, later named Windows Communication Foundation (WCF)
  • WinFS, the relational file system that was later abandoned

With the benefit of hindsight, Microsoft got many things right with the vision it set out at PDC 2003. The company saw that a revolution in user interface technology was under way, driven by the powerful graphics capabilities of modern hardware, and that the old Win32 graphics API would have to be replaced, much as Windows itself replaced DOS and the command-line. XAML and WPF was its answer, bringing together .NET, DirectX, vector graphics, XML and declarative programming to form a new, rich, presentation framework that was both designer-friendly and programmer-friendly.

Microsoft also had plans to take a cut-down version of WPF cross-platform as a browser plugin. WPF/Everywhere, which became Silverlight, was to take WPF to the Mac and to mobile devices.

I still recall the early demos of Avalon, which greatly impressed me: beautiful, rich designs which made traditional Windows applications look dated.

Unfortunately Microsoft largely failed to execute its vision. The preview of Longhorn handed out at PDC, which used Avalon for its GUI, was desperately slow.

Fast forward to April 2005, and Windows geek Paul Thurrott reports on Longhorn progress:

I’m reflecting a bit on Longhorn 5048. My thoughts are not positive, not positive at all. This is a painful build to have to deal with after a year of waiting, a step back in some ways. I hope Microsoft has surprises up their sleeves. This has the makings of a train wreck.

Thurrott was right. But why did Longhorn go backwards? Well, at some point – and I am not sure of the date, but I think sometime in 2004 – Microsoft decided that the .NET API for Longhorn was not working, performance was too bad, defects too many. The Windows build was rebased on the code for Server 2003 and most of .NET was removed, as documented by Richard Grimes.

Vista as we now know was not a success for Microsoft, though it was by no means all bad and laid the foundation for the well-received Windows 7. My point though is how this impacted Microsoft’s strategy for the client API. WPF was shipped in Longhorn, and also back-ported to Windows XP, but it was there as a runtime for custom applications, not as part of the core operating system.

One way of seeing this is that when Longhorn ran into the ground and had to be reset, the Windows team within Microsoft vowed never again to depend on .NET. While I do not know if this is correct, as a model it makes sense of what has subsequently happened with Silverlight, IE and HTML5, and Windows Phone:

  • Windows team talks up IE9 at PDC 2010 and does not mention Silverlight
  • Microsoft refuses to deliver a tablet version of Windows Phone OS with its .NET application API, favouring some future version of full Windows instead

Note that in 2008 Microsoft advertised for a job vacancy including this in the description:

We will be determining the new Windows user interface guidelines and building a platform that supports it. We’ll eliminate much of the drudgery of Win32 UI development and enable rich, graphical, animated user interface by using markup based UI and a small, high performance, native code runtime.

In other words, the Windows team has possibly been working on its own native code equivalent to XAML and WPF, or perhaps a native code runtime for XAML presentation markup. Maybe this could appear in Windows 8 and support a new touch-oriented user interface.

In the meantime though, Microsoft’s developer division has continued a strong push for .NET, Silverlight and most recently Windows Phone. Look at Visual Studio or talk to the development folk, and you still get the impression that this is the future of Windows client applications.

All this adds up to a muddled development story, which is costly when it comes to evangelising the platform.

In particular, eight years after PDC 2003 there is no clarity about Microsoft’s rich client or RIA (Rich Internet Application) designer and developer story. Is it really WPF, Silverlight and .NET, or is it some new API yet to be revealed, or will IE9 as a runtime play a key role?

There is now a little bit more evidence for this confusion and its cost; but this post is long enough and I have covered it separately.

microsoft, professional, silverlight, software development

Lessons from Evernote’s flight from .NET

35 Comments

Evernote has released version 4.0 of its excellent note-taking product. Software developers have taken particular interest in the blog post announcing its release, because of what it says about .NET, in this case the Windows Presentation Foundation, versus native code:

Evernote 4 is a major departure from Evernote 3.5 in every way. While 3.5 added tons of great new features, there were some problems we simply couldn’t fix: the blurry fonts, slow startup times, large memory footprint, and poor support for certain graphics cards were all issues that the technology behind 3.5 (Windows .net and WPF) was incapable of resolving. As a result, we ended up chasing down platform bugs rather than adding the great features our users wanted.

So we decided to start over from scratch, with fast, native C++ that we knew we could rely on. As you’ll see, the results are amazing. This new version will set a foundation for rapid improvement.

Evernote 4 is designed to give you a great experience on any computer that you use, whether you’re on a netbook, a five year old Windows XP machine or a super fast top-of-the-line Windows 7 computer.

On our test hardware, Evernote 4 starts five times faster, and uses half the memory of Evernote 3.5.

A bit of background. WPF was introduced in Windows Vista and was originally intended to be the main GUI API for Windows, until the notorious reset midway through the Vista development cycle which marked a retreat from managed code back to native code in the operating system. I’d guess that the issues faced by the Evernote team were not so different from those faced back then by the Windows team at Microsoft.

WPF is not only based on .NET. It also uses DirectX and hardware acceleration under the covers, enabling rich multimedia effects. The layout language of WPF is XAML, giving freedom from scaling issues which cause hassles in the native API.

So what are the lessons here? Is WPF no good?

It is not so simple. WPF is brilliant in many ways, offering the productivity of .NET coding and a powerful layout framework. However it was a technology which Microsoft itself hardly used in its key products, Windows and Office – a warning sign.

When Microsoft built Visual Studio 2010 and .NET 4.0, the development team used WPF for the Visual Studio shell. This move by an internal team to create such a complex product in WPF was good for the framework itself. The font issue was addressed, performance improved. Evernote might not have found all its issues fixed in version 4.0, but it would likely have been better.

After I tweeted about Evernote’s experience, a couple of Microsoft folk contacted me to make this point. The trouble is, even version 3.5 of WPF was not the first version, and it never sounds altogether convincing if, when a customer complains about your product, you tell them everything is fine in the latest and greatest build. Why did Microsoft not get this right before?

That said, I am sure the latest WPF is better than before, though it is still heavyweight relative to native code. Factors that might suggest a WPF solution include:

  • The application only needs to run on Windows
  • There is no need to support older machines
  • The application makes use of data visualisation or other multimedia effects
  • The development team lacks the resources to build equivalent functionality in native code

The last point is important. Maybe a hotshot team of C/C++ developers could make a better job, but if you don’t have such a team or the money to hire it, it is not so relevant.

There is another possible approach, without abandoning .NET. Silverlight has many of the features of WPF, is lightweight, and runs on the Mac as well as Windows.

.net, adobe, flash, iphone, java, microsoft, mobile, software development, visual studio, web authoring

Latest job stats on technology adoption – Flash, Silverlight, iPhone, Android, C#, Java

13 Comments

It is all very well expressing opinions on which technologies are hot and which are struggling, but what is happening in the real world? It is hard to get an accurate picture – surveys tend to have sampling biases of one kind or another, and vendors rarely release sales figures. I’ve never been happy with the TIOBE approach, counting mentions on the Internet; it is a measure of what is discussed, not what is used.

Another approach is to look at job vacancies. This is not ideal either; the number of vacancies might not be proportionate to the numbers in work, keyword searches are arbitrary and can include false positives and omit relevant ads that happen not to mention the keywords. Still, it is a real-world metric and worth inspecting along with the others. The following table shows figures as of today at indeed.com (for the US) and itjobswatch (for the UK), both of which make it easy to get stats.

Update – for the UK I’ve added both permanent and contract jobs from itjobswatch. I’ve also added C, C++, Python and F#, (which hardly registers). For C I searched Indeed.com for “C programming”.

  Indeed.com (US) itjobswatch (UK permanent) itjobswatch (UK contract)
Java 97,890 17,844 6,919
Flash 52,616 2,288 723
C++ 48,816 8,440 2470
C# 46,708 18,345 5.674
Visual Basic 35,412 3,332 1,061
C 27,195 7,225 3,137
ASP.NET 25,613 10,353 2,628
Python 17,256 1,970 520
Ruby 9,757 968 157
iPhone 7,067 783 335
Silverlight 5,026 2,162 524
Android 4,755 585 164
WPF 4,441 3,088 857
Adobe Flex 2,920 1,143 579
Azure 892 76 5
F# 36 66 1

A few quick comments. First, don’t take the figures too seriously – it’s a quick snapshot of a couple of job sites and there could be all sorts of reasons why the figures are skewed.

Second, there are some surprising differences between the two sites in some cases, particularly for Flash – this may be because indeed.com covers design jobs but itjobswatch not really. The difference for Ruby surprises me, but it is a common word and may be over-stated at Indeed.com.

Third, I noticed that of 892 Azure jobs at Indeed.com, 442 of the vacancies are in Redmond.

Fourth, I struggled to search for Flex at Indeed.com. A search for Flex on its own pulls in plenty of jobs that have nothing to do with Adobe, while narrowing with a second word understates the figure.

The language stats probably mean more than the technology stats. There are plenty of ads that mention C# but don’t regard it as necessary to state “ASP.NET” or “WPF” – but that C# code must be running somewhere.

Conclusions? Well, Java is not dead. Silverlight is not unseating Flash, though it is on the map. iPhone and Android have come from nowhere to become significant platforms, especially in the USA. Beyond that I’m not sure, though I’ll aim to repeat the exercise in six months and see how it changes.

If you have better stats, let me know or comment below.

.net, microsoft, silverlight, software development, visual studio

More on Microsoft’s difficult choices: WPF, Silverlight, HTML 5

8 Comments

Earlier today I posted a story speculating about the future direction of Microsoft’s development platform, which has proved controversial and to some extent has been misunderstood. Although it is speculative, the issues are important since developers want to target platforms with a strong future. Here’s another take on why Microsoft, whichever way it decides to go, faces some difficult choices.

First, let me be clear: I don’t see Microsoft abandoning Windows Presentation Foundation let alone Silverlight. Microsoft has an good track record when it comes to continuing support for its technologies, better than competing platforms. Visual Basic 6 applications mostly still run today on Windows 7, perhaps with a few issues caused by User Account Control for which there are workarounds. Whatever you target, there is an excellent chance Microsoft will continue to support it long into the future. The main exception I can think of is Windows Mobile, which is incompatible with the new Windows Phone 7 series, but given the challenges Microsoft faces in mobile you can understand the decision.

Nor is there any chance of Microsoft reviving old frameworks. There will not be a return to Windows Forms. WPF is a better GUI framework in every way, other than performance on older systems – though note that Windows Forms applications still run fine today, and I imagine will run fine on Windows 8 and probably 9 as well.

The real question is not about support, but future investment. Microsoft has finite resources. It is in overdrive right now on Internet Explorer, on Silverlight, on Windows Phone 7, and on Azure, for example. There will be other products and technologies that receive less attention, because someone has decided they are not strategic.

It also seems to me that Microsoft’s server and cloud story is less conflicted. From the developer’s perspective it is thoroughly .NET based, and you can be confident that technologies like C#, IIS, ASP.NET, SQL Server, Exchange and SharePoint will be around for the foreseeable future.

With that out of the way, a few further comments.

Windows Presentation Foundation

The history of WPF goes back to the early days of Windows Vista, then called Longhorn. WPF was one of the the “three pillars”, Avalon, where the others were Indigo (WCF) and WinFS. Avalon was the future of the Windows GUI API, based on .NET code and XAML layout.

If Longhorn has proceeded as planned, WPF would be the loose equivalent of Cocoa on Apple’s OS X, the standard way to code Windows GUI applications. Unfortunately, in 2004, Microsoft discovered that Longhorn was heading for disaster. The project was reset, delaying release and resulting in Vista being both late and rushed. The reset project included Avalon as a supported framework, but made it incidental to the workings of Windows itself. The Windows team, in other words, lost faith in Avalon and reverted to native code with a dash of DirectX.

Windows 7 is more of the same. WPF is there but it is not at the heart of the OS. Developers are encouraged to use it for their own apps, but the Windows team is focused on native code.

When Visual Studio 2010 was released, with a shell built in WPF, Microsoft made some noise about how it showed its commitment to the framework. It was also noted that the Visual Studio team had worked with the WPF team to fix some issues. However, there is little sign of WPF changing its role as a layer in Windows primarily to support custom applications, rather than being used for the shell of Windows itself.

The question now: how much should Microsoft invest in future WPF development? It is not essential for Windows itself. Nor it is compelling for developers wanting to take advantage of the cloud model and support diverse clients. Frankly it does not look strategic unless it becomes the Windows shell API; and you could understand Microsoft having a “once bitten twice shy” attitude to that possibility.

I find it plausible that Microsoft would throttle back on WPF development.

Silverlight

Silverlight by contrast is strategic. Silverlight is a framework that runs in the browser, out of browser, and on Windows Phone 7. It is lightweight and cloud-oriented, and it runs .NET code, ticking lots of boxes for developers moving on from Windows desktop applications. It is also designer-friendly, with rich graphics and multimedia support. There are still a few gaps – printing is crude, for example – but it makes more sense for Microsoft to invest in Silverlight than WPF. It is significant that the new LightSwitch tool for rapid development of database apps targets Silverlight, not WPF, and not ASP.NET (except on the server). Silverlight is also the application platform for Windows Phone 7.

Then again, Silverlight is WPF. It was originally WPF/Everywhere, and uses the same XAML language for layout.

I will be surprised if Microsoft back-pedals on Silverlight. Nevertheless, I can also understand this being a matter of debate. Despite Microsoft’s efforts to distinguish them, there is considerable overlap between what Silverlight does, and what HTML 5 in IE9 does, especially when in the browser. There is also the Apple problem: HTML applications will run on iPhone and iPad, but Silverlight will not. What if Microsoft focused on the new IE engine instead of Silverlight, supporting it properly in Visual Studio, and providing ways for developers to create out-of-browser apps that run with full trust and have access to local system APIs? This would be along the same lines as the Palm WebOS and Google’s Chrome OS.

Put another way, does it make sense for Microsoft to invest equally in HTML 5 and Silverlight, when possibly IE 9 could be the basis of a unifying technology, a subset of which would work on any modern browser on any client?

It seems to me that Microsoft will have to invest in tooling for HTML 5 clients in some forthcoming edition of Visual Studio, and that this will be a selling point for its cloud platform, while possibly undermining the role of Silverlight.

There is also a continuing case for Silverlight, both because of the inherent advantages of a plug-in – consistency of client platform as well as features that HTML 5 lacks – and because it supports .NET. The .NET languages (Mono aside) tie developers to Visual Studio and to Microsoft’s platform. Visual Studio combined with .NET is a formidable tool for both client and server and a key advantage for the platform.

Watch this space.