Microsoft suspends development of touch-friendly UWP Office apps for Windows(arstechnica.com)
arstechnica.com
Microsoft suspends development of touch-friendly UWP Office apps for Windows
https://arstechnica.com/gadgets/2018/09/microsoft-suspends-development-of-touch-friendly-office-apps-for-windows/
14 comments
"If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?"
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.
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.
> 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.
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.
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.
I think it matters a lot. If I develop an application that's supposed to be in development for many years I want to use a framework that has a forward path to the latest OS features.
> a framework that has a forward path to the latest OS features.
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.
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.
If I'm starting development on a Windows 10 app tomorrow, with no legacy codebase, and I'm going to target only Windows 10, which framework would you suggest? I want it to be the best of both worlds: when running on a Surface or other detachable with the keyboard detached, it should have no compromise compared to an iPad Pro app in its UX, with fluid gestures, working well with high PPI screens, and so on. At the same time, when running on a system with keyboard and mouse, it should have no compromise relative to a classic desktop app with all the power users expect, like full multitasking.
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?
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?
WPF hasn’t been seriously upgraded for a long time now. I love WPF, but it is beginning to feel like WinForms.
Didn't realize, I really like WPF too, hope that executives aren't trying to push too many efforts towards whatever they think the trends might be, I tried Xamarin for mobile but ended up switching to Android Studio and just targeting there.
"Preparrrre for Q#........" (jk on that....for now)
"Preparrrre for Q#........" (jk on that....for now)
You can but it would be better for developers if you could rely on a framework being developed rather than frozen in time. I'm pretty sure there are no classes supporting touch in MFC.
[deleted]
> I'm pretty sure there are no classes supporting touch in MFC.
https://docs.microsoft.com/en-us/cpp/mfc/reference/cwnd-clas...
https://docs.microsoft.com/en-us/cpp/mfc/reference/cwnd-clas...
Thanks, I was clearly wrong on that point.
Except that's not what Microsoft does at all. The .NET Framework is forward compatible and very rarely breaks compatibility. You can select multiple compilation targets for .NET and have a single piece of code that compiles to multiple frameoworks concurrently.
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++.
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++.
We aren't talking about .NET in general bit about desktop UI frameworks. If you started with ASP.NET MVC years ago you still are on the main platform that's in full development. With desktop development you have several frameworks that are either in support mode or not fully featured.
GDI, Win32, and XAML are the only ones that come to mind for me, am I missing some? 3 frameworks in 3 decades seems reasonable considering they all still work. The same can't be said for MacOS
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.
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.
What do you mean same can’t be said for macOS? Carbon and Cocoa. Cocoa has been around since 2001 (17 years), and is still going. Since 2007 UIKit has been around (11 years) and doesn’t seem as if it’s going anywhere either. I personally think Apple has the nicest UI frameworks to develop for, and the longevity is quite good. The frameworks (particularly UIKit) regularly get meaningful updates to make it modern, and now there’s an entire new modern language that’s 100% compatible while moving things forward.
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.
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.
> What do you mean same can’t be said for macOS?
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.
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.
You are missing Winforms and several XAML frameworks (WPF, Silverlight, WinRT and UWP). Even if you use one of the XAML frameworks porting any app of decent size is really hard to almost impossible.
I think trouble started with .NET. Since then there was a change in direction almost every 2-3 years.
Edit: Forgot WinJS...
I think trouble started with .NET. Since then there was a change in direction almost every 2-3 years.
Edit: Forgot WinJS...
Because before the reorganization, .NET used to be part of DevTools, while C++ and related tooling was part of WinDev.
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.
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.
I guess the MS org chart is still accurate:
http://www.globalnerdy.com/2011/07/03/org-charts-of-the-big-...
http://www.globalnerdy.com/2011/07/03/org-charts-of-the-big-...
Everything lives on top of win32. Even UWP is a wrapper around win32, if you look at the modules list you'll see gdi.dll in the list.
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.
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 don't think that's correct. In Winforms and MFC every control is a Win32 window. As far as i know WPF has only one root window and then does all the drawing by itself on a canvas.
How it uses windows is orthogonal to whether it’s based upon win32 APIs. The framework may add some of its own controls, but copy+paste and even touch hit testing are win32. This is very unlike say KDE vs Gnome.
I used to work on the office UWP apps, and I’ve seen the underlying code.
I used to work on the office UWP apps, and I’ve seen the underlying code.
ASP.Net MVC 5 (ASP.NET Core) was a complete rewrite of MVC/Web API. The MVC work that was done previously would have to be completely rewritten.
Why are you targeting net standard and core in your nuget packages? Targeting standard should be all you need to cover both.
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.
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.
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.
True, but it's not like frameworks stop working. I still write an occasional app in WinForms and it works great.
I personally know of some companies that are still running VB6 programs on Windows 10. We're talking about 1998 tech here. Even the development tools are still working 20 years later on the newest version of Windows.
Developing UWP apps is challenging though, it's not a straightforward experience and as a result many people hate it.
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).
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).
The UWP version of Office has never really made sense. Office is a massive project and a moving target from a features perspective. It seems like a monumental task to reimplement it from scratch.
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.
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 "gradually porting" the control panel since Windows 7... with like three different UI frameworks in its Windows 10 version it's one of the best examples of Microsoft's schizophrenic approach to code updates
"gradually porting Control Panel and other legacy Win32 apps to the Settings App"
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?.
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?.
Parts of it are public API with the API specifying the look and even the size of the panels. It’s impossible to rewrite without breaking compatibility.
With all the bits that have lived in there since Win95, I suspect it is something of a Lovecraftian horror.
>If Microsoft can't even release their marquee apps on it, why should anyone else feel confident in developing on the platform?
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?
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?
While it seems ironic and uncoordinated at first glance, perhaps UWP is right for OneNote since it has far fewer features than Word or Excel, and less legacy, being a newer app?
This whole headline feels like deja vu... how many times has Microsoft promoted and then abandoned Windows Mobile?
The headline is misleading. Microsoft is suspending development of the UWP Office applications, which happen to be touch-friendly. However, the headline implies that the remaining Win32 versions do not have a touch-friendly mode, which is false.
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.
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.
Just as additional information, Win32 touch APIs were introduced in Windows 7, and are part of the Hilo C++ sample application.
Does Office in touch mode work as well as on the iPad Pro, say?
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?
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?
I've only seen UWP versions of Microsoft products. Really, it's a way of keeping a foot in both mobile and desktop, when mobile-first has been embraced so widely.
Ok, we've squeezed in UWP above.
I wonder what the overall adoption rates are for UWP. As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years.
This is exactly what is holding back Win32: there has not been any serious development of the desktop developer story since WPF in 2005 (WPF only received token updates since then, the last major update was in 2010 when they finally added a DataGrid control, lol) - but WPF is not well-suited for many types of software which have to fall-back on “pure” Win32 and the story there is nothing but depressing.
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.
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.
> The story is so bad Microsoft’s own flagship software has to build their own UI frameworks
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 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 do Windows development since 3.0, currently maintaining a couple of Forms and WPF applications, the Forms are the hardest to maintain due event handling spaghetti code instead of proper MVVM with data binding, no use of Table/StackLayout components and still do background handling in BackgroundWorker classes.
How is the Visual Studio WPF designer these days? I worked on a WPF app around 5 years ago, and the form designer in Visual Studio was appalingly slow and quite buggy.
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.
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.
High DPI support for WinForms has been improved in the .NET Framework 4.8 https://github.com/Microsoft/dotnet-framework-early-access/b...
"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."
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.
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.
WPF was really nice from what I remember of it. MVVM was super easily integrated with XAML.
MVVM is great if you want to unit test all your UI code but who wants to do that.
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.
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.
With some more work like better Visual Studio integration and maybe some compiler magic it could have been fantastic.
The majority had stopped at (right before) WPF it seems
> 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/
> 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/
When Apple introduced Cocoa they also introduced Carbon however, an extension of the legacy MacOS APIs. Apple already slowly killed their Win32.
It's actually kind of impressive how much transitional stuff Apple has introduced and then removed with Mac OS X and how right many of their decisions turned out. I guess Cocoa itself was an extension of the legacy NextStep API too. They also had Classic for running old Mac apps directly in OSX and later Rosetta for running PowerPC binaries on Intel (I guess the same tech was used for the 32->64 bit transition). So many technologies have been smoothly deprecated and removed over the years by Apple.
I don’t think you really can compare Apple’s and Microsoft’s situation here. Think of the extreme bigger amount of software that was written for Windows including all that custom made business software for small companies. Apple was always in the situation that a lot of their 3rd party developers were also „fans“, who are more willing to keep up with their transitions, where however most the Microsoft tech developers were just doing their job and want to keep their stuff only running with the least amount of work necessary.
Apple was always in the situation that a lot of their 3rd party developers were also „fans“, who are more willing to keep up with their transitions,
That's true, but Apple also got behemoths like Adobe and Microsoft to port over their applications to modern APIs (Cocoa and Cocoa Touch).
That's true, but Apple also got behemoths like Adobe and Microsoft to port over their applications to modern APIs (Cocoa and Cocoa Touch).
Because Apple does the "take it our way or leave" approach.
Which is also a reason why they hardly have a meaningful market share across the enterprise world.
Which is also a reason why they hardly have a meaningful market share across the enterprise world.
Sure they do. It’s on mobile. While MS isn’t going anywhere in the Enterprise, anyone who is focused on the desktop when it comes to MS development instead of web, cloud, or even cross platform mobile development is headed down a dead end.
A little secret, laptops and 2-1 convertibles are desktops as well, while being mobile.
If we want to be pedantic, a desktop could be considered mobile too since you can pick it up.
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.
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.
In the real world people are working on laptops, while using iOS and Android mostly to consume content, play games, browse web and show plane tickets.
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.
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.
I am not saying that people aren’t using desktops to do work. What I’m saying that relatively few companies are putting money into writing desktop software. The jobs are limited compared to writing web based software.
If I ever got back into desktop software, it would be highly specialized low level C/C++ code and not WPF/Sharepoint/UWP software.
If I ever got back into desktop software, it would be highly specialized low level C/C++ code and not WPF/Sharepoint/UWP software.
Yes and no. They've taken down the documentation, but there's still a number of (non-GUI, non-kernel) Carbon APIs that are still not deprecated (as of 10.11, at least), and still allowed in the Mac App Store.
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).
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).
They're about to removed (carbon apis) AFAIK with the move to 64bit only no?
What's bad about GDI? (I used to do windows but have not been following, I remember that you need to do GetDC and ReleaseDC on a window handle to get the device context and then to release it - in pairs, else...)
It's a graphics API designed for early-1990s needs. It's missing things we expect today like 30-bit colour support and all-VRAM memory (GDI was hardware accelerated but they gimped it in Windows Vista to ensure compatibility with the DWM).
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.
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.
[deleted]
SharpDX and SlimDX are fantastic wrappers for Direct2D, last time I was doing anything with it. SharpDX is the more active of the two.
> 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
They do for Direct2D on UWP, https://github.com/Microsoft/Win2D
It doesn't do antialiasing.
GDI+ does.
GDI+ Is better in a lot of ways, but has the major downside of being limited to software rendering only.
GDI+ is a completely different replacement API, not just an extension/update of GDI.
> The story is so bad Microsoft’s own flagship software has to build their own UI frameworks
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.
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.
remember WinJS, another vapourware
> As someone who's written Windows software since the 90s, I can't shake the feeling that Microsoft just churns out completely new development stacks every few years.
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."
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."
Very very very low.
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.
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.
Like everyone else, the biggest difference is that Microsoft keeps the old tech around, while most other companies are willing to loose customers that don't want to move into the new stacks.
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.
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.
Microsoft shot themselves in the foot with UWP. It's actually pretty nice to write apps with it (in my personal opinion, anyway). But UWP only supports Windows 10.
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.
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.
Exactly. One of the biggest reasons why Carbon (and Mac OS X) succeeded is that Carbon apps also ran on OS 8/9. Big apps like Acrobat, Final Cut Pro, Mozilla, and many others were able to use Carbon and run on OS 9 and X.
Yeah, UWP not supporting win7 pretty much killed it.
Might not be an issue in 5 years, by then MS will probably has a new new framework .
Might not be an issue in 5 years, by then MS will probably has a new new framework .
"Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support)."
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.
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.
I have found one working enterprise use case.
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... )
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... )
"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."
This would be a great thing for us. But we already have a huge investment into WPF. How do we get this to UWP?
This would be a great thing for us. But we already have a huge investment into WPF. How do we get this to UWP?
Apparently via XAML Islands as shown at BUILD and this week's Ignite.
Now in face of this announcement, not sure.
Now in face of this announcement, not sure.
You need Windows 10 machines to develop for/deploy IoT Core last I checked, so that killed it for us (corp world still holding onto Windows 7).
One way that it is better are the visual layer and accelerated composition engine.
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.
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.
WinForms will out live UWP, WFP and pretty much everything else Microsoft develops in terms of GUI frameworks. It works for the vast majority of programs that businesses need, it's easy to use and so far it's been the best investment in terms of learning a "framework".
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.
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.
"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.
They could have done this 10-15 years ago. It's too late now.
There is also Electron/Javascript.
Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.
Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.
Honestly, if I had to develop a new desktop app for Windows I would seriously think about Electron. It's frustrating that there is no premier desktop app framework for Windows anymore. UWP is too limited, WPF is pretty much deprecated. Win32 has a huge learning curve and finding devs would be very difficult. Pretty sad situation.
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.
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.
I have been developing new WPF applications during the last couple of years.
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.
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.
Why not Qt?
True. A while ago I looked into Qt and one problem was that there weren't too many 3rd party components on the market. For WPF and Winforms you can buy extremely powerful components like data grids and tree views (I have been using Developer Express) but I didn't find any for qt.
Checkout QML (as opposed to widgets).
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
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
Skype has become so clunky and slow lately, so I find myself avoiding it whenever possible. Could this be the reason behind the worse quality?
There's also Qt which they used for OneDrive
I’m not sure if it’s true but it seems to me like they replaced their own client with an alternative one they bought from another company, which has parts written in Qt.
Yup, and you don't even need to touch C++ these days. All C# and QML!
https://github.com/qmlnet/qmlnet
(I'm the author)
https://github.com/qmlnet/qmlnet
(I'm the author)
I don't even know how to use UWP. I'm learning Rust and writing some applications using WinAPI is my plan. WinAPI usage seems to be fairly straightforward. But I have no idea how to write UWP application with Rust.
They are suspending the UWP versions. But Office is imho already fairly touch friendly if you turn "touch mode" on, in which all buttons, toolbars and menus become a little bigger. It is not that they don't want touch support (they do, thinking of the Surface family), they just don't want to invest in two parallel version of which one is mature and the other will always be lagging behind. And the customer will probably not see the difference, maybe even get confused.
Ms is my favorite tech company. They, however are their own worst enemy. They produce many awesome but crippled stuff - like honey stained with drops of bird shit.
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.
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.
> like honey stained with drops of bird shit.
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?
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?
I'm not a beekeeper. I used to write professionally but quit.
The honey/bird poo imagery was simply the most striking I could think of.
The honey/bird poo imagery was simply the most striking I could think of.
FWIW, here in Eastern Europe we have a similar saying that "A spoonful of tar ruins a whole cask of honey" .
We also have something similar in Chinese (Cantonese only?) - one bit of mouse shit ruins the whole pot of congee (一粒老鼠屎，壞了一鍋粥).
It is also one of my favorite ones, I think the continuous throw away of technology like Singularity, Midori, XNA, Longhorn, UWP,... is the usual outcome of the internal politics between WinDev, DevTools and Marketing divisions.
It was supposed to get better after the reorganization, but apparently it hardly changed.
It was supposed to get better after the reorganization, but apparently it hardly changed.
Since MS is no stranger to regularly building new frameworks, they should build one that is natively supported in Windows, with no compromises relative to other APIs like WPF or Win32, while also supporting macOS, iOS and Android as targets. Some functionality that's not supported in iOS, say, like full multitasking, should degrade gracefully.
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.
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.
Yeah I don't see the need for a fragmentation, as they abandoned Windows RT. IMO, the Win32 Office apps already are very much touch-friendly.
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.
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's top2 issue on uservoice https://onenote.uservoice.com/forums/327186-onenote-for-wind...
When I first looked at WinRT app development I thought "how are they going to sell it with these limitations and incompatibilities?" and they did not. UWP was a slightly improved version on WinRT, but it still had some of the same core issues. Luckily, Microsoft has some kind of exit strategy already - I just wonder where that leads.
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.
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.
It's nice that they're at least bringing WinForms and WPF to .NET Core.
I'm looking forward to using UWP components in WPF apps, though I imagine that'll only work on Windows 10.
I'm looking forward to using UWP components in WPF apps, though I imagine that'll only work on Windows 10.
As I understand it UWP is still the official and canonical API. However knowing how many other APIs had such a status it's not saying much.
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.
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.
As a 2 in 1 Wundows 10 notebook user (XPS 13) it is obvious that the touch "mode" is completely unfinished. Simple things like not displaying the keyboard when you select a textbox make difficult to choose the tavlet mode except for basic reading.
I think the vision of multi-factor OS is right but the execution doesn't pass a basic UX test.
I think the vision of multi-factor OS is right but the execution doesn't pass a basic UX test.
Touch centered desktop uis need to die
One of the features I specifically look for in a laptop is "NO TOUCH SCREEN". I really don't understand it. Why would I want touch on a laptop or desktop PC?
Story time. At a previous company, we had an annoying crash bug - it crashed on some of the client's computers, but never on any of ours. Finally the client lent us the personal laptop of one of their workers, which reliably reproduced the crash, and we debugged it while sitting on one of the client's meeting rooms and found the cause. It was a crash deep in the obsolete framework we were using, which manifested when receiving a particular kind of accessibility message, which came from one of the components for Microsoft's touch screen system.
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).
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).
This reminds me of an ongoing issue with our org's website. The devs are using an ancient jquery for an image gallery widget. The gallery doesn't respond to mouse clicks on any of our PCs because that jquery version sees touch support and expects you to use only that. All of our devices have touch screens.
I sometimes use touch on my XPS. I realized it's only when I'm showing stuff to others, and because the touchpad is inadequate (like broken side scrolling).
But I'm a "don't leave smudge marks on my screen" type of person.
But I'm a "don't leave smudge marks on my screen" type of person.
Given how smudgy my iPad looks from just reading a book or watching Netflix...my laptop would be a literal mess after not very long.
I actually love mine on my Razer Blade. Admittedly, I don't use it too much, but I find myself on occasion wanting to touch my MBP.
for doing mobile development obv
What will happen to Win32 when Windows 7 stops being security supported in 15 months?
Wow, the comments make it seem like this has anything to do with Windows UWP platform. So much misunderstanding here and the OP is even quite a bit misleading.
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.
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.
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...