Microsoft suspends development of touch-friendly UWP Office apps for Windows
arstechnica.com
arstechnica.com
Moreover, they have (had?) an entire multi-year roadmap planned around UWP, including the eventual release of a version of windows which was supposed to substantially reduce day-to-day reliance on Win32 for lower powered devices, codenamed Project Polaris [2], in an attempt to compete with Chromebook-like devices.
This is a massive destruction of confidence in the UWP platform. If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?
[1] https://www.theverge.com/2018/4/18/17252312/microsoft-office...
[2] https://www.windowscentral.com/understanding-windows-core-os...
That's why I avoid any kind of Windows desktop development. They release a new framework every 2-3 years and developers are expected to adopt it. But then they drop support for that framework quickly and release a new incompatible one.
In the Windows environment choice is bad. You only have bad choices and the frameworks that are being used for flagship apps like Office are not available to devs.
I really envy iOS devs where the path to an app is straightforward and your biggest problem is to use ObjectivC or Swift.
I currently am maintaining a handful of Projects that build Nuget packages compatible with .NET Core, .NET Standard and .NET Framework.
If you do have compatibility issues you can easily set preprocessor directives and implement platform specific work arounds just like in C or C++.
If you're referring to Silverlight, that was never a serious desktop UI framework. It was initially targeted as a Flash /Java killer but pivoted to cross platform desktop apps when it became clear that it would never be adopted on Mobile and that Apple/Google were actively trying to kill Flash on the desktop.
That being said, we got XAML from Silverlight and it's not terribly difficult to covert ti a XAML or even UWP app from a Silverlight codebase.
I think trouble started with .NET. Since then there was a change in direction almost every 2-3 years.
Edit: Forgot WinJS...
So since .NET was introduced there has been an ongoing power struggle between the two camps regarding how the future of Windows development should look like.
The whole Longhorn/Vista debacle was more a side effect of those political issues than actual technical problems. Likewise with lack of management support for bringing Singularity and Midori outcomes into mainstream Windows, or trying to replace .NET with WinRT.
The reorganization was supposed to help sort out such silos, apparently it wasn't successful at that.
http://www.globalnerdy.com/2011/07/03/org-charts-of-the-big-...
In a sense the rest of these frameworks are all just libraries. You can choose the one that makes your life easier but win32 will do the heavy lifting. Because of this its relatively easy for them to add support for new features to the various frameworks. They just wire up the win32 calls as necessary.
I used to work on the office UWP apps, and I’ve seen the underlying code.
Disclosure: I happen to work for Apple, but this was my previous opinion having spent many years using all the major frameworks/platforms out there.
I wasn't so much taking a shot at Apple as I was trying to point out the stability of Windows. The reality though is that APIs on either system outlive the usefulness of most applications.
In a purely technical sense though you can't run a 2001 era Cocoa App on a 2018 Mac without recompilation. You can't run a System 7 era App on a 2018 App without at least minor API tweaks (Cocoa isn't 100% compatible with System 9's API). You can run a 1990s era Win32 App on a 2018 Windows 10 PC without recompilation.
Doesn't matter, as a developer you're free to pick whichever you like. You can run VB6 apps on Windows 10. A software I've made on my first job with MFC for NT4.0 still runs on Win10. WPF is awesome, I still pick it now in 2018 when I need compatibility with older Windows.
"Preparrrre for Q#........" (jk on that....for now)
Microsoft usually adds support of OS features into old frameworks. For example, they have added touch support into their 25+ years old MFC.
Technically speaking, WPF gets updated regularly with each release of .NET framework. For example, in 4.6.2 they have implemented per-monitor DPI scaling support.
As a developer, I like stable APIs, and frameworks which don’t break my code with version upgrades.
Which framework provides the best of both worlds?
Not UWP, since it doesn't offer full multitasking and is limited in various other ways like sandboxing that I can't opt out of.
Is there ANY framework that provides the best of both worlds?
https://docs.microsoft.com/en-us/cpp/mfc/reference/cwnd-clas...
I agree with you. I would never take a job doing Windows desktop development and I am a big fan of .Net and Microsoft’s development tools.
But web development is far worse.
It makes more sense to gradually rewrite portions of it but that doesn't work well with the annual release model. It does however work with the O365 continuous release model they adapted from Windows 10.
Just as they're gradually porting Control Panel and other legacy Win32 apps to the Settings App. I could see them gradually convert Office to modern cross platform frameworks.
They have been porting the control panel since Windows 8 and it's still far from done.
How hard can it be to rewrite control panel in UWP?.
I don't know if you've ever had to debug a UWP app but compared to almost anything else it's painful. Exceptions don't propagate properly, and finding errors takes a ton of time. Development is likewise painful with elements of random things being required and the packaging and publishing process a nightmare compared to competitors.
UWP was made for phone and Microsoft then ported it to Core OS, but as a format it is not developer friendly. If you look at new Microsoft under Satya - and their goal of being developer friendly, this move makes sense. I wouldn't be surprised to see UWP and the current store deprecated entirely (as they are honestly failures).
Endemic at Microsoft. I believe the main reason the Xbox One Kinect - an impressive piece of hardware - failed, is that Microsoft themselves couldn't manage to make one big flagship game for it at launch. If Microsoft themselves are avoiding it, why on earth would third parties invest?
The Win32 versions can be switched between "mouse" and "touch" modes. In touch mode, the pointing targets are all much larger. But as with most user interfaces on modern Windows, even in mouse mode, the Office user interface can be used by touch. Running in mouse mode doesn't remove the helpful pop-up action bar when you've selected text, for example, it just makes the UI elements render more tightly.
For the several years I've used a Surface device with a touch screen, I've never used the UWP versions of the Office applications because they never reached feature parity with the Win32 versions. The UWP versions had a subset of functionality; not the same subset but similar in limitations to the web versions. But that doesn't mean I don't use a touch-friendly application suite—I simply use the Win32 versions in both mouse and touch modes.
Do I have to go around telling each app that supports touch mode to go to touch mode, or is there a way I can configure it centrally?
Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers).
Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.
Which is also a reason why they hardly have a meaningful market share across the enterprise world.
But in the real world when people talk about “mobile software” everyone knows that people are talking about iOS and Android. No one is chasing after the Windows software market, it’s been a diminishing platform for the past decade.
When they actually become a match to laptops and 2-1 convertibles, maybe.
And there Chromebooks are no where to be seen outside US school system, iPad Pros are mostly a gimmick in rich countries and Android 2-1 are basically phone apps with keyboard.
If I ever got back into desktop software, it would be highly specialized low level C/C++ code and not WPF/Sharepoint/UWP software.
That's true, but Apple also got behemoths like Adobe and Microsoft to port over their applications to modern APIs (Cocoa and Cocoa Touch).
I'm using AHGotoPage() because NSHelpManager has no equivalent and nobody has been able to explain to me how to make that class do a similar task reliably. (In hindsight, AppleHelp is such a disaster that I should have just avoided it entirely, as almost every other app does.) MAS reviewers have given me grief over many things my app does, but never any Carbon calls.
The last time I saw any Carbon APIs deprecated was 10.8, I think (6 years ago).
> In fact, at a recent conference I was at with a large group of C# consultants. When the audience was polled on which desktop UIs their clients were using, the vast majority were WinForms, a small group was WPF, and almost no one was UWP
https://iamtimcorey.com/ask-tim-is-winforms-dead/
And many did long before WinForms
> Less than a year ago, a manager asked me if I could write a library for a client that would allow VB6 to access a RESTful API.
https://blog.submain.com/death-winforms-greatly-exaggerated/
I think this might be the other way round: if they're not eating their own dogfood, it's much easier for the UI framework to come adrift from actual use cases.
It's really telling that in Windows 8/10 they "modernised" some, but not all, of the control panel UI. It's basically random as to whether a setting you need will be in a Metro-flavoured window or a Win32-flavoured one.
To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications.
I also wasn't a big fan of XAML - no matter how much time I spent using it, it mostly seemed more difficult and awkward to get components where you wanted them than with WinForms.
Never had any big problem that I can remember of since Visual Studio 2012.
That's really infuriating. Makes me wonder what all these devs they have are doing the whole day.
"To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications. "
WPF had great potential and I think they could have made it a wonderful environment if they had kept improving it. Clean up XAML syntax (maybe something like they with ASP.NET and Razor) , simplify data binding syntax and debugging, make MVVM first class citizen and it would be great. Instead they (almost) stopped development of WPF and cranked out a series of half baked successors like WinRT, Silverlight and UWP.
For me the whole thing was cumbersome and nowhere near as productive as WinForms. Not only that but problems it purported to solve like high-dpi support still had issues.
When working with Win32 it just isn't possible to avoid having to use GDI, for example dealing with painting to a window surface Win32 will give you a GDI device context by default - for example, similarly handling Win32 messages like WM_PAINT uses parts of the GDI API. Finally, each process on Windows has a limited number of GDI objects it can use as well. Oh, and using GDI/GDI+ in a service context (e.g. ASP.NET or a Windows Service, is not supported: https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-...)
Direct2D is nice - but setting it up in your code isn't easy - and Microsoft does not maintain an up-to-date C#/.NET library for Direct2D.
They do for Direct2D on UWP, https://github.com/Microsoft/Win2D
The story is so bad because the Microsoft units making flagship desktop apps aren't productizing their UI frameworks (not suggesting that this is their choice), instead leaving the firm with public UI framework offerings not tightly grounded in that kind of use experience.
Good frameworks don't lead to internal flagship use, internal flagship use leads to good frameworks through tight feedback between real-world use and framework development.
Win32 is a lower portability risk than UWP. Genuinely that’s what I’ve heard people say. Most of the UI and event stuff can be moved to wx or equivalent in a few months and deployed on other platforms.
UWP and you’re up shit creek.
Most companies are on the fence with running away from windows. It moved too fast, costs too much money to keep up with and has too much friction.
Take a look on the windows store for the massive uptake. Not. Half of it is still win32 and the rest is written by MSFT, crapware or abandoned.
Everything is in a right state despite the marketing to the contrary.
Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.
https://github.com/qmlnet/qmlnet
(I'm the author)
Maybe their secret plan is to push people into writing web apps with ASP.NET? Event that doesn't work because a lot of people will use Node instead.
http://doc.qt.io/qt-5/qml-qtquick-controls-treeview.html
http://doc.qt.io/qt-5/qml-qtquick-controls-tableview.html
Here are all the controls: http://doc.qt.io/qt-5/qmltypes.html
Those customers were now thinking of eventually start moving into UWP after the Windows 10 migration was complete, so given this, they will continue using WPF.
Also Forms, WPF and EF 6 support are the major roadmap items for .NET Core 3.0
Node is no match against .NET or Java for those that care about performance.
On one side it is a big reason why they have achieved their market size on the desktop, on the other side we reach this kind of situations where new tech improved tech like Singularity, Midori, Longhorn or now UWP gets thrown into the garbage can in the name of backwards compatibility. Quite sad.
Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support).
So, no matter how nice UWP gets, most companies that would still be willing to write a native Windows app are 5+ years out from being allowed to adopt it, entirely because of how Microsoft chose to release it.
Might not be an issue in 5 years, by then MS will probably has a new new framework .
You would be suicidial if you based any product you want to sell to business on UWP. Not only doesn't it Win 7 or 8 but I don't see in what way UWP is better than WPF.
UWP is great if you are exclusively deploying to brand new Windows 10 Embedded devices. (I think this is now called "Windows IoT Core" or something similar). That's what I've been using it for, and that's worked well. It carries a nice side benefit that our sales team all has Windows 10 Pro laptops, and UWP 'just works' there too for sales demos, presentations, and such.
But I agree, selling UWP apps to businesses for traditional desktop use is ridiculously difficult.
> I don't see in what way UWP is better than WPF.
For a long time, UWP was the only way to get a working WebView (one based off of Edge instead of IE). But I think they fixed that and backported Edge to WPF a few months ago. (EDIT: they did kind of fix that - https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie... )
This would be a great thing for us. But we already have a huge investment into WPF. How do we get this to UWP?
Now in face of this announcement, not sure.
Naturally this matters little to those enterprises doing plain CRUD applications with default L&F.
One big improvement in UWP is that Visual C++ finally merits the name Visual, although it still fails short of C++ Builder's RAD tooling.
And overall the sandbox model, however from the last Build it appears that Redstone will get an improved sandbox for Win32 apps as well, alongside MSIX support.
If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years.
They could have done this 10-15 years ago. It's too late now.
That's the theme behind one of Joel Spolsky's old essays, Fire And Motion:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."
UWP's appx format is awesome - one click installation, sandbox, clean uninstallation, potential for diff updates. All these have nothing to do with portability.
But they crippled it by making it store only until recently... Too late.
One reason I hate using Edge is because i like chrome and Firefox, it's impossible to install extensions from the browser.
Why can't I use the store through my browser? There's absolutely nothing stopping the store from acting as a downloader and installer in the background.
If the store worked from the browser, usage would pick up.
That is a very specific image that I've never encountered in real life. Is it something that only beekeepers get to witness or is there some bird that homes in on honey pots?
The honey/bird poo imagery was simply the most striking I could think of.
It was supposed to get better after the reorganization, but apparently it hardly changed.
I feel that reorganization was a financial sleight of hand to raise the stock price by emphasize money making projects and hide lack-lustre offerings.
Think of it as a hybrid app framework that also is the first-party framework on one OS. No one has done that so far, and it would be interesting to see someone try.
That will give developers a solid incentive to use this API, unlike others like WPF, Silverlight, WinRT, etc. The benefit for MS will be that Windows gets the best possible experience, rather than a least-common denominator one, as with Electron.
And hey MS, why your OneNote is going a totally different way alone? MS killed Win32 OneNote in Office 2019. I love Win32 OneNote so much as it has more features and more stable.
That all being said: Microsoft should still invest in their desktop stack (especially WPF / .NET for desktop applications in general). Bringing the positive parts from UWP to the established frameworks would be a big win for everyone.
I'm looking forward to using UWP components in WPF apps, though I imagine that'll only work on Windows 10.
How does the Xamarin.Forms look between other APIs? It's getting Linux and macOS support. I started to wonder if it will be the next official and canonical API. Or maybe something in the direction of their Electron, as they use it already with their Typescript.
But I don't really know anything about Windows development beyond Win32, so maybe it doesn't make sense at all.
I think the vision of multi-factor OS is right but the execution doesn't pass a basic UX test.
But I'm a "don't leave smudge marks on my screen" type of person.
The reason we could never reproduce the crash before was that, being techies, none of us had any modern laptop, personal or not, with a touch screen. The client, being less technical, had some of their workers with touch screen laptops and the then-recent touch-focused version of Windows (which we also tended to avoid).
1) UWP is the branding behind many technologies, but most commonly thought of as the containerization and sandboxed subset of the Win32 API available to the application. This would have been great had it not poorly abstracted a lot of very common I/O APIs. The first version didn't allow normal socket API, you had to use the HTTP or some janky intern's first project streaming socket API.
Another annoyance, none of the file system APIs that had 20 years of software written around worked anymore, instead you had to rewrite on top of a completely different API that was in no way compatible with the previous API set.
Contrast that with Apple's iOS sandbox story, the entire Foundation and Core Foundation library, including all of the expected POSIX (BSD variant) code continued to be available. Developers early in the platform's life could take their previous work and just recompile it for the phone and build a new mobile UI on top of it.
iOS in the very beginning had its fans but also only one or two developers who were eager to convince management they should write software for it. Whereas Microsoft's vision for requiring you to rewrite the majority of your software from the bottom to the top on this container system meant serious up front investment. For a new platform, the chicken and egg problem meant even Microsoft couldn't justify the cost.
2) Over time Microsoft has changed course and re-enabled a lot of the Win32 restrictions they engineered in place to write containerized applications. It's still not 100% there and I think they probably gave up trying to make it work. Instead they decided just to allow Win32 software in its entirety to run on the sandbox through another marketing platform, "Desktop Bridge." This brought a flood of 3rd party apps to the Microsoft Store since it was finally easy to port software over.
It's definitely not the same though, because UI (xaml) is still locked behind the container system. Yet all the work the Windows UI team is investing in is in this new container XAML UI. It's a nice UI surface, because you get a lot for free now, High-DPI and scaling just works and animations that don't look like garbage.
Unfortunately you cannot have both. You cannot have the newest UI framework and continue to have access to the entire platform API in a sandbox. Microsoft enabled a bunch of super hacks to try to allow you to write containerized UI but it's not straightforward and you're better off picking one platform or the other.
..
So thiiiiis is where I see the demise of Mobile Office. Desktop Bridge will allow Win32 Office to continue to work on all tablets and desktops. Even the ARM variant will run them, and Win32 Office already has an ARM port, so it's not likely that will change. They won't get access to the containerized UI, but Office has always been its on custom UI beast. So I doubt they need to suffer the limitations of the containerized API subset, get full access in the Win32 API and unify the teams.
It makes perfect sense to me and if I were the PMs in charge of this, I would have done this a while ago.