31–40 of 158 posts
The keyword here is probably "extending". I am not aware of what it really means, but I wouldn't be surprised if MS tried everything it could to get more developers on its UWP. And keep them.
Earlier quoted context omitted.
The introductory phrase of UWP explains why they pushed it: "A Universal Windows Platform (UWP) app can run on any Windows-based device, from your phone to your tablet or PC" . The point was getting more applications for their mobile platform by coaxing developers who might have otherwise built a desktop-only application. I'd say this new development is essentially an admission of defeat on mobile.
The problem is that it may take their desktop with it. The industry doesn't want to invest in a desktop windows app because there is no clear direction. WPF/Win32 etc seem to be getting deprecated, but UWP is too limited.
If it had worked it would have been a smart move, but it was wildly over-optimistic.
So if I understand it right, this is basically running apps in a Win32-emulator/sandbox where all 'unsafe' Win32 file and registry accesses are redirected into sandboxed locations. I wonder why MS didn't go this way from the beginning instead of pushing that Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on us. The UWP application model has been modelled after the (now 10 years old) iOS/A…
Let's just take a moment to remember Games For Windows Live here.
So if I understand it right, this is basically running apps in a Win32-emulator/sandbox where all 'unsafe' Win32 file and registry accesses are redirected into sandboxed locations. I wonder why MS didn't go this way from the beginning instead of pushing that Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on us. The UWP application model has been modelled after the (now 10 years old) iOS/A…
UWP isn't a mobile OS ported to Windows. The whole WinRT is an OS and WinRT is an API set confused things. Forget that there was an ARM tablet. WinRT means the Windows Run Time. It's a set of API's that are built with the Windows OS. The "they made it mobile" part was really a side effect of trying to move to a more managed execution model where the OS took a more aggressive approach to managing the execution of an app over it's lifetime.
That has certainly needed improvement since it has been released. The WinRT API set was and is limited to a set of API's that are governed by a security broker. Applications are intended to have an identity, that is a SID, and execute in a very tight sandbox ala Chrome or Edge. It's a good model that makes some of the traditional malware vectors very hard to exploit. (You can't call LoadLibrary, for instance.)
OK. Set that aside for a moment. The desktop bridge uses technology called App-V that has been available to enterprise customers for a long time. It lets you run an installer and it watches all of the things it does to a clean system. It then bundles all of those things into a single file. It provides shims to your code that, for instance, will intercept your attempt to write to a global part of the registry and directs it to a registry hive kept in the file.
What they did in the anniversary edition was include parts of AppV in Win10, and they built a set of technologies that help with the process of "sequencing" a Win32/.Net app. Your application still runs just like it used to. There is no emulation. If you want to use API's that are available in UWP you need to follow some guidance on adopting them. Some are less invasive than others. Its a tradeoff, but it's one that you get to control as a dev and you can share a bulk of your code between Win7 and Win10 builds that use the strengths of both platforms.
So, its a sandbox, but not an emulator. The AppX installation method is more like the ".app" model in desktop OS X where you have a bundle of things for your app. There are also new security model things that you can adopt over time to gain access to new functionality.
You DO NOT have to install AppX packages from the store. You can download them from the Web and double click on them or use powershell to install them. The store is separate from the app packaging tech and API set.
Your comment reads like someone who doesn't use Windows enjoying some schadenfreude at the trouble they have had over the last couple of years. You're going to need to get over that. They are getting their shit together in a big way. Yes their mobile platform failed. They have admitted that and moved on. They produce a lot of software for Android and IOS. You can develop native Linux software with Visual Studio now. They contribute to Linux, Mesos, and Docker. .Net is open source. They contribute to FeeBSD. What more do you want? No one is making you use their stuff. You have never had more options. Why do you feel like that for you to be doing better other people have to be doing worse?
> converting their app or game with the Desktop App Converter and then enhancing and extending it with UWP functionality The keyword here is probably "extending". I am not aware of what it really means, but I wouldn't be surprised if MS tried everything it could to get more developers on its UWP. And keep them.
It doesn't mean...whatever paranoid thing you think it means. Also, its a developer related thing. If you don't have a desktop app that you want to move to the store or bundle in an Appx package for distribution on the web, it doesn't mean anything to you.
Earlier quoted context omitted.
The introductory phrase of UWP explains why they pushed it: "A Universal Windows Platform (UWP) app can run on any Windows-based device, from your phone to your tablet or PC" . The point was getting more applications for their mobile platform by coaxing developers who might have otherwise built a desktop-only application. I'd say this new development is essentially an admission of defeat on mobile.
The problem is that it may take their desktop with it. The industry doesn't want to invest in a desktop windows app because there is no clear direction. WPF/Win32 etc seem to be getting deprecated, but UWP is too limited.
In fact, they don't really deprecate things. They may stop pushing something as the new hotness...but VB6 apps still run on windows. Those data access technologies that no one uses anymore...those still work on windows. If you are worried about your investment in time not being the new hotness, well that's one thing. If you are worried about your investment in effort being abandoned...they have done more to support backwards compatibility that I think is even reasonable.
So if I understand it right, this is basically running apps in a Win32-emulator/sandbox where all 'unsafe' Win32 file and registry accesses are redirected into sandboxed locations. I wonder why MS didn't go this way from the beginning instead of pushing that Frankensteinian half-desktop/half-mobile monstrosity called WinRT^H^H^H UWP on us. The UWP application model has been modelled after the (now 10 years old) iOS/A…
Wow. UWP isn't a mobile OS ported to Windows. The whole WinRT is an OS and WinRT is an API set confused things. Forget that there was an ARM tablet. WinRT means the Windows Run Time. It's a set of API's that are built with the Windows OS. The "they made it mobile" part was really a side effect of trying to move to a more managed execution model where the OS took a more aggressive approach to managing the execution of…
I want Windows to remain the dominant gaming platform. But for this, UWP is completely heading into the wrong direction.
Earlier quoted context omitted.
The problem is that it may take their desktop with it. The industry doesn't want to invest in a desktop windows app because there is no clear direction. WPF/Win32 etc seem to be getting deprecated, but UWP is too limited.
UWP is limited as it is relatively new. The new (capabilities based) security model is clearly better than the old "if you are admin, you can do whatever you want" model. The old model was inadequate even at the start of the multimedia age, but it was not recognized until recently. The new sandboxed operation creates more portable and reproduceably operating apps. The limitations will show, as more and more usecases…
* No app closure callbacks. You don't know if it's suspending or exiting.
* No "are you sure you want to exit? Save/Don't save" dialogs. If you close or crash pray your data was saved, and if it takes a long time to flush to disk...really pray.
* No minimizing/backgrounding to tray icons allowed.
Earlier quoted context omitted.
You run the converter on your complied exe installer, not your applications code. That a fairly low barrier. Seems to make the Store very backwards compatible, it can even convert VB6 apps: http://www.hanselman.com/blog/PuttingMyVB6WindowsAppsInTheWi... Also if you want to go from exe rather than installer you can use makeappx directly https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop...
What if I'm using something more modern, like chocoaltey? MSI has never played well with CI servers and wix is way too complicated.
Earlier quoted context omitted.
The problem is that it may take their desktop with it. The industry doesn't want to invest in a desktop windows app because there is no clear direction. WPF/Win32 etc seem to be getting deprecated, but UWP is too limited.
UWP is limited as it is relatively new. The new (capabilities based) security model is clearly better than the old "if you are admin, you can do whatever you want" model. The old model was inadequate even at the start of the multimedia age, but it was not recognized until recently. The new sandboxed operation creates more portable and reproduceably operating apps. The limitations will show, as more and more usecases…