Microsoft releases new tools for Developers to more easily convert existing Classic apps to UWP apps in VS 2017 15.4

[Guest]

10 minutes ago, AluminiumTech said:

<Snipped>

Add cleaner uninstalls to that list (Kinda goes hand in hand with sandboxing but still)

7 minutes ago, AluminiumTech said:

Windows 10 S is secure and safe by design.

Still waiting for app-v support (This is the containerization/virtualization of apps if I'm not mistaken) in non enterprise versions... Would be nicer to use than docker or hyper-v.

[AlwaysFSX]

11 minutes ago, AluminiumTech said:

That's not how normal email clients work.

Clients usually poll the server in a different way.

It works for me on both of my Windows 10 Devices I currently use.

I guess mine is broken? I've tested trying to get emails in a timely manner, sometimes they can take well over an hour even when you're manually trying to sync it. And just.. it doesn't work right to store emails.

 

 

I should have so many more emails than this.

[HarryNyquist]

And despite this, Win32 will STILL persist because there's so many business level applications that still use Win32, that don't involve a UI in any way. They want to move UI code to UWP but that doesn't mean Win32 will die or go away ever. There's no profit in that.

 

Whether or not the lowly consumer will have ACCESS to it is a different story, but if anything I would expect them to keep it how it is now, with 10 S/Home/Pro/Enterprise. Seems to be working out well enough.

[Sniperfox47]

1 hour ago, AluminiumTech said:

UWP is sort of similar to WPF except it's more modernized.

That too. The Registry was a really bad idea.

 

AppData too.

And it locks you down to using Microsoft's driver and filesystem interfaces (i.e. no third party ext4 drivers. No Vulkan. No OpenCL. No industry standard APIs. Just Microsoft's version.)

 

And what's wrong with AppData? God forbid I, as a user, have access to the files that my application uses and can back it up and make changes... Do you know how much of a pain constantly restoring my computer would be when Windows breaks if I couldn't just drop my old AppData back into and restore all my tabs in chrome and Firefox?

 

1 hour ago, AluminiumTech said:

The registry is a mess.

A lot of Win32 developers seem to love using AppData and the reigstry.

Some people have a HiDPI device like I do....

 

Win32 apps scale very poorly on it. UWP apps scale correctly.

 

Windows Forms uses CPUs for rendering. This is bad for apps which require minimal CPU overhead. It also is bad because you can't really animate anything or make beautiful transitions.

 

I could list many more factual reasons why UWP is better.

HiDPI?

 

Modern APIs with support for literally any new feature added in a new Windows 10 Build such as their new design language stuff?

 

It doesn't sound like a lifted stuff from Microsoft PR....

 

Imagine you're an IOS dev having to deal with APIs in IOS 6 versus IOS 11. Wouldn't you rather use new and exciting APIs in IOS 11?

Wow beautiful argument. That's not vague or general at all.

 

You can handle HiDPI on Win32 just fine... The solution is to not use Windows Forms or Windows Presentation Model... Use a halfway decent framework like QT...

 

QT is also GPU accelerated... Again why is your argument "well it's better than Windows Forms!"? There's been no reason to use Windows Forms or WPM for at least like 5-6 years now...

 

And yeah, your arguments kinda do sound like an infomercial. They're very strong on buzz and hype, and very small on actual critical information.

 

Or you know, since iOS and Android were developed by sane individuals write an application that takes advantage of the features in the new API versions when available and gracefully fall back to the older features when they're all that's available?

 

The *only* benefit to UWP over Win32 is the improved sandboxing, and for advanced users the way it handles sandboxing is more of a PITA than a benefit.

 

Linux containers? I can still see and interact with the filesystem inside if I have root.

 

ChromeOS? Same thing.

 

Android apps? If I have root I can still rip the data partition and see everything apps are storing.

 

MacOS? Again, have that option.

 

The only container systems where that's not available are iOS and UWP, and with iOS that's only because there's no official way to get root, but if you jailbreak you *can* see and interact with everything.

 

It locks users out of their own systems for absolutely no good reason. The only thing it does successfully is lock developers into Windows, just like .net has always been designed to do.

[Guest]

46 minutes ago, Sniperfox47 said:

QT and GTK+ both work better on Win32 than Windows Forms does, and maintain code portability...

26 minutes ago, Sniperfox47 said:

Use a halfway decent framework like QT...

QT is also GPU accelerated... Again why is your argument "well it's better than Windows Forms!"? There's been no reason to use Windows Forms or WPM for at least like 5-6 years now...

I've been meaning to check those out, just haven't had the time to recently. Nice to hear that they work so well on Win32, are they generally better to work with too?

[AlTech]

7 minutes ago, tjcater said:

I've been meaning to check those out, just haven't had the time to recently. Nice to hear that they work so well on Win32, are they generally better to work with too?

QT apps like OBS Studio have awful HiDPI support though.

[Sniperfox47]

Just now, tjcater said:

I've been meaning to check those out, just haven't had the time to recently. Nice to hear that they work so well on Win32, are they generally better to work with too?

I haven't worked with Windows forms in like an eternity so couldn't tell you. I don't do much Windows development.

 

I use QT all the time and find it pretty easy to work with, but I also use it all the time so I have a lot of experience. It would undoubtedly be a bit of an adjustment if you're used to forms or WPF.

 

Forms is massively dated at this point and afaik the recommended framework tool is WPF, with all its DirectX based goodies. QT has some lisencing constraints (it's LGPL) but for most applications that should affect you for anything other than your installer.

[Guest]

2 minutes ago, AluminiumTech said:

QT apps like OBS Studio have awful HiDPI support though.

Are there any safe practices to alleviate that?

1 minute ago, Sniperfox47 said:

I haven't worked with Windows forms in like an eternity so couldn't tell you. I don't do much Windows development.

 

I use QT all the time and find it pretty easy to work with, but I also use it all the time so I have a lot of experience. It would undoubtedly be a bit of an adjustment if you're used to forms or WPF.

 

Forms is massively dated at this point and afaik the recommended framework tool is WPF, with all its DirectX based goodies. QT has some lisencing constraints (it's LGPL) but for most applications that should affect you for anything other than your installer.

Haven't worked with forms or WPF, but I plan to try out PyQT some time soon once college settles down again (Seems like exams and essay due dates wanted to align this week, and I start applying for the next semester's courses tomorrow.)

[AlTech]

Just now, tjcater said:

Are there any safe practices to alleviate that?

Haven't worked with forms or WPF, but I plan to try out PyQT some time soon once college settles down again (Seems like exams and essay due dates wanted to align this week, and I start applying for the next semester's courses tomorrow.)

Forms and WPF allegedly got a HiDPI mode in .NET 4.7 but it's not a big enough improvement.

[AlTech]

2 minutes ago, Sniperfox47 said:

Forms is massively dated at this point and afaik the recommended framework tool is WPF, with all its DirectX based goodies. QT has some lisencing constraints (it's LGPL) but for most applications that should affect you for anything other than your installer.

I'd be fine with QT if it didn't require the terrible LGPL license for the Open Source version.

 

QT Commercial plans look wayyy too expensive also I'm not an expert in C++.

[Sniperfox47]

1 minute ago, AluminiumTech said:

I'd be fine with QT if it didn't require the terrible LGPL license for the Open Source version.

 

QT Commercial plans look wayyy too expensive also I'm not an expert in C++.

Except it doesn't require you to use the LGPL for your code, it just lisences you the module under LGPL... What's so bad about that?

10 minutes ago, AluminiumTech said:

QT apps like OBS Studio have awful HiDPI support though.

That's on OBS, not QT. QT fully supports HiDPI support.

 

2 hours ago, AluminiumTech said:

Windows Forms uses CPUs for rendering. This is bad for apps which require minimal CPU overhead. It also is bad because you can't really animate anything or make beautiful transitions.

WPF uses DirectX Rendering though... And is what you should be using instead of forms of building anything since 2011.

 

5 minutes ago, tjcater said:

Are there any safe practices to alleviate that?

Haven't worked with forms or WPF, but I plan to try out PyQT some time soon once college settles down again (Seems like exams and essay due dates wanted to align this week, and I start applying for the next semester's courses tomorrow.)

Yeah, the same ones you need to take with UWP. Which is to say, provide your app resources at the different scaling levels, use DPI aware widgets, and mark your app as DPI Aware: http://doc.qt.io/qt-5/highdpi.html

[AlTech]

Just now, Sniperfox47 said:

Except it doesn't require you to use the LGPL for your code, it just lisences you the module under LGPL... What's so bad about that?

Are you sure?

Just now, Sniperfox47 said:

Yeah, the same ones you need to take with UWP. Which is to say, provide your app resources at the different scaling levels, use DPI aware widgets, and mark your app as DPI Aware: http://doc.qt.io/qt-5/highdpi.html

In practice, UWP apps scale significantly better than most other types of apps on Windows Desktop.

[Sniperfox47]

1 minute ago, AluminiumTech said:

Are you sure?

From https://www1.qt.io/qt-licensing-terms/:

Quote

In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

So you just need to link dynamically. Which with .net you'd be doing anyways.

[Sniperfox47]

7 minutes ago, AluminiumTech said:

In practice, UWP apps scale significantly better than most other types of apps on Windows Desktop.

In practice that's also because most UWP apps that aren't games are written by Microsoft or close partners >.>

 

A ton of third party UWP apps, including most of the dice rolling apps if you want specific examples, scale terribly with HiDPI.

[LAwLz]

5 hours ago, AluminiumTech said:

The registry is a mess.

That is not a technical explanation.

 

5 hours ago, AluminiumTech said:

A lot of Win32 developers seem to love using AppData and the reigstry.

And why is this bad?

 

5 hours ago, AluminiumTech said:

Some people have a HiDPI device like I do....

 

Win32 apps scale very poorly on it. UWP apps scale correctly.

I do too. Or well, it's not that high DPI but it's enough to require scaling.

It is not impossible to make a Win32 program scale properly, and Microsoft is (despite the FUD you try to push) constantly improving support. They have at several points introduced new APIs for Windows 10 to help with scaling.

 

5 hours ago, AluminiumTech said:

Windows Forms uses CPUs for rendering. This is bad for apps which require minimal CPU overhead. It also is bad because you can't really animate anything or make beautiful transitions.

So don't use Windows Forms? Nobody is forcing you to use that for Win32 applications.

That's the beauty of "legacy" applications. You are not forced to use merely the tools provided to you by Microsoft. Sadly the same can't be said for UWP.

 

5 hours ago, AluminiumTech said:

I could list many more factual reasons why UWP is better.

Please do.

Right now you have mentioned three, out of which 2 are bullshit.

• Scaling, which is an issue because developers don't want to put in the time and money required to implement it properly, but if they won't do that then I don't see why they would invest the time and money to port it to UWP either.
• Not using the registry or appdata, which is something developers choose to do but don't have to. So you're just removing options from developers rather than actually giving them superior tools to do things with.
• It has hardware acceleration which WinForms doesn't have, but since WinForms is far from the only GUI library you can use I don't see why this matters. Want a high performance graphics library? How about using DirectX? Or QT like @Sniperfox47 suggested. That's a great library. It's cross-platform too.

 

5 hours ago, AluminiumTech said:

HiDPI?

 

Modern APIs with support for literally any new feature added in a new Windows 10 Build such as their new design language stuff?

 

It doesn't sound like a lifted stuff from Microsoft PR....

It sounded like PR fluff because you kept saying it was "modern" and "cool" and other things like that.

 

5 hours ago, AluminiumTech said:

Imagine you're an IOS dev having to deal with APIs in IOS 6 versus IOS 11. Wouldn't you rather use new and exciting APIs in IOS 11?

No, I would not rather use the new and "exciting" APIs for iOS 11 over the iOS 6 ones if they didn't have any tangible benefits but serious drawbacks. I don't care when something was introduced. I care about practical things like performance, compatibility, functions, and so on.

Assembly is almost 70 years old at this point, but when I see that parts of x264 is written in assembly I don't go "wow what outdated garbage, they should write this in C# instead!". I go "wow, the developers of this program are extremely skilled and really cares about their work".

[Guest]

My understanding of the APIs isn't that deep so pardon my ignorance, but does the OS get more control over how the applications function under UWP? The only benefit I could see would be smarter pausing/throttling to get better battery life dependent on the systems state and potentially being improved as the OS updates later on.

[Drak3]

6 hours ago, Sauron said:

And tie you in to the UWP framework. At least the registry can be emulated to some extent if you want to try and run windows apps on a different platform. UWP just locks it down.

Only for so long, but the registry serves as a source for huge headache when it needs maintenance. Wouldn't surprise me if MS only cared about making UWP good enough that joe average doesn't necessarily need the registry, and make it opt in for b/c.

[Dabombinable]

Since UWP are just repacked desktop apps I'm not surprised.

[yian88]

this is bad you want less apps in the Store so that the store dies already and gets removed from windows pfft

[LAwLz]

53 minutes ago, gabrielcarvfer said:

To sum up:

• UWP sucks in terms of performance, but are much better in isolation/maintainability/so on.
• Win32 sucks in terms of isolation/maintainability/so on, but are much better in terms of flexibility and API.
• Mac apps are better than both in terms of installation, because the app is self contained and just moving to the applications folder can trigger install/uninstall scripts, but they lack in isolation because apps can write to /Users/yourUser/Library/AppSuport/..., just like AppData crap.
• Linux has multiple implementations of those things, and all of them sucks.

 

All of them have their flaws... In my opinion, the Mac app system is the best in terms of ease of use, but they should isolate the AppSupport stuff inside the .app folder, and when you move the app, for example when copying to another computer, it just triggers a script that asks if the user wants to keep or delete the AppSupport data.

Those are some terrible generalizations which I'd say are completely wrong.

 

UWP does not necessary suck in terms of performance. They will never be as good as properly written Win32 programs, but I wouldn't be surprised if a crappily written UWP program will perform better than the average crappily written Win32 program.

The big issues are the huge limitations it puts on developers, and portability.

 

Win32 does not suck in terms of maintainability. It's all up to the developers. That's what's so great about Win32. It is all up to the developers. They can make a great update system if they want.

 

I don't know much about MacOS, but what's wrong with programs being able to write to /AppSupport/? Having one central location where programs can store their user-specific files is very convenient. Just like AppData. If everything was saved in the installation folder then it would be hard to properly separate individual user files on a multi-user system.

[LAwLz]

8 hours ago, gabrielcarvfer said:

UWP doesn't suck in terms of performance? APIs with more overhead, throttling, etc, plus don't forget MS bullshit like the forced V-Sync.

It depends on what you compare it against. That's why I brought up the average poorly coded program on both. Win32 has a wider spectrum of overhead and performance. UWP might not be able to ever reach the same performance as a very well written Win32 program, but on average I wouldn't say it sucks in terms of performance. It's average or maybe even good in terms of performance. It will just never be great.

V-sync is no longer forced.

 

8 hours ago, gabrielcarvfer said:

I really expected them to make UWP a two way bridge, so that you can develop for all platforms, probably using the same techniques they used with SQL Server on Linux.

That might have been cool, but sadly Microsoft is trying to force everyone over to UWP. They are not interested in developers developing for all platforms. They want developers and users locked into Microsoft products.

 

8 hours ago, gabrielcarvfer said:

What is wrong? Just like someone said earlier, why can't you simply drag a folder named .app to another PC and get the entire program plus caches/configurations/passwords/etc, without needing to install or configure anything? Having a folder inside the self-contained app is way better.

Without looking into things, my guess would be that you would still require the program to be installed because of dependencies. The only way around that would be to include all dependencies inside the folder, but that would lead to a lot of bloat. It would also not work with programs that needs daemons (which needs to be registered by the OS in order to run automatically).

 

8 hours ago, gabrielcarvfer said:

Properly separating for user files is the same thing as it's now, create a folder Users/AppData inside the .app and you're done. In OS X you even have two different Applications folder, one global and another private, so you shouldn't have a problem with that.

Again, I don't know much about MacOS but my gut instinct is that handling multiple users without causing excessive bloat on the system would be tricky without storing things at separate locations.

Since all OSes does it in similar ways I assume there is a good reason for it.

 

8 hours ago, gabrielcarvfer said:

Depending on developers to take care of their shit is not usually a good idea, as you can check that you probably have multiple folders of programs that you uninstalled, plus a lot of dead registry just occupying space.

Joke's on you! I am extremely anal about what programs I install on my system. I have only uninstalled one program since I installed Windows, and that was deleted properly.

But yes, a lot of uninstallers are bad and leave files behind. I am not worried about the registry being full of dead keys though.

[Delicieuxz]

12 hours ago, Dabombinable said:

Since UWP are just repacked desktop apps I'm not surprised.

Reduced performance, restricted developer features, limited user configurability desktop apps.

 

Win32 isn't going anywhere, because it's already a more sophisticated, functional, and satisfying platform, in same sense that a normal, windowed, furnished room is more sophisticated, functional, and satisfying than an empty, padded-wall room whose primary aim is to 'protect you from yourself' (AKA, to make people use the Microsoft Store).

[Sniperfox47]

10 hours ago, gabrielcarvfer said:

Properly separating for user files is the same thing as it's now, create a folder Users/AppData inside the .app and you're done. In OS X you even have two different Applications folder, one global and another private, so you shouldn't have a problem with that.

...you mean just like ProgramData and %USERPROFILE%/AppData...? ProgramData for global stuff and AppData for user stuff?

 

12 hours ago, gabrielcarvfer said:

• Linux has multiple implementations of those things, and all of them sucks.

What's wrong with Linux Containers? Or even just properly used SELinux? There's a reason why a lot of secure servers are running Linux...

 

And as @LAwLz has pointed out a bunch of times now, higher isolation leads to higher redundancy. If you totally isolate all apps from one another you wouldn't be able to share implementation details between them. No shared libraries, no shared caches, no shared settings. All of this balloons not just the storage cost of apps but also the performance cost of the isolation.

 

If all your apps are isolated from one another, how do you implement an update process that works across them? How do you share images and other large binaries between them?

 

Some isolation is good but UWP takes it way too far.

[Sniperfox47]

4 hours ago, gabrielcarvfer said:

If the app is self-contained, it shouldn't need external dependencies, or at least let the dependencies be resolved by the OS, in case of OS X, using that XML. Leads to a lot of bloat? Just like Windows, DLL hell and so on, but nobody complains that it works. Deamons exist on OS X, it's registered using the same XML/plist that is inside of every .app. When you move the .app to the trash, it triggers an script to remove the scheduled task.

A) Very very few apps are self contained. Pretty much everything with a GUI has some kind of external dependency, even if it's just Apple's MacOS Framework.

 

B) OS side dependency resolution is messy, regardless of what OS you're on...

 

C) DLL Hell isn't bloat, it's the dependency issues that result as a means of reducing that bloat. Shared libraries reduce bloat by having multiple programs use the same library. Might some programs use different versions of that library? Sure. But the worse case scenario, where every application uses it's own different version, is no worse than the alternative of using unshared libraries.

I'm not really sure what you're saying here. OSX doesn't

 

3 hours ago, gabrielcarvfer said:

Yeah, but inside of the UWP package folder or the .app on OS X. No data directly related to a program should be outside of its own package.

No data directly related to a user should be inside an application's package. It should exist solely in the user's domain. There's a reason why Windows default AppData to being inside your user profile, and most Linux systems default .[appname] to being inside your home directory. Regardless of how well you lock the folders down, a user who is able to get into the application directory to view their own information is going to have the ability to see that other users have information. Users should be entirely isolated from one another.

 

Also makes transferring a single user to another machine or backing up a single user easier, because you just copy that user's information, rather than having to scrape the information of every single app to extract their data from those apps.

 

3 hours ago, gabrielcarvfer said:

There are a lot of different reasons why a lot of servers are running linux, and none of them are ease of use for end-users.

Go take a loot at FlatPak, AppImage, Ubuntu Snap, Debian packages, Pacman packages, and the list goes on.

Umm... FlatPak (Which uses Linux Containers) on Fedora is as easy as using the gnome software center for anything else... Download the flatpak of choice, double click it, and click install... done.

 

But that wasn't even my point. My point was that all these Linux options are secure, yet still allow a user with root permissions access to the low level details of their system. Android is secure, yet still allows a user with root permissions access to the low level details of their system. MacOS is secure, yet still allows a user with root permissions access to the low level details of their system. iOS is secure, yet still allows a user with root permissions access to the low level details of their system.

 

UWP explicitly prevents me as a user from peeking into any application's filesystem and seeing what it's doing.

 

3 hours ago, gabrielcarvfer said:

Yes, higher isolation and higher redundancy. That's why you can have a Windows pc running a program compiled for Windows 95 and on linux you would need to recompile everything to do something like that. And you can take a look at your programs/game folders, that you will see a lot of duplicate libraries. It takes space, it's a pain to manage, but works.

A) You can have a binary application that works across Fedora 15,16,17,18,19,20,21,22,23,24,25,26, and 27 without any need to recompile it... Hell you can have a program that will work with all of those, a bunch of versions of Ubuntu, some Arch and Suse builds, and more... Or do you think that Linux Steam games get different versions compiled for every different GNU/Linux Distro they run on?

 

B) But working shouldn't be the only thing that matters. Shared libraries exist for a reason.  You'll notice most games that bundle libraries rather than using shared libraries do so either because they use a modified version of the library, because they depend on a very specific version of the library, or because there's no standardized runtime installer for the library.

 

3 hours ago, gabrielcarvfer said:

About shared libraries, UWP already support them. Packages can require the installation of other packages in order to be installed and run.

Yes, but those libraries are still strangled the same way as the UWP package itself. No low level system access. No loading into kernel drivers to access third party standards like Vulkan. No loading up open interfaces like an EXT4 userspace driver to let other apps take advantage of it. Everything is self contained and isolated.

 

My rant about no shared libraries wasn't saying UWP doesn't have shared libraries, it was making the point that if we keep following this trend of restricting shared libraries, we soon won't have access to these fundamental things.

 

3 hours ago, gabrielcarvfer said:

What does update has to do with packaging? If the OS is managing it, just take the difference from the latest thing published by the developer, download it to the package folder and that's it. If you're not using the OS to manage it, then download a new package and overwrite the previous one.

Except your application doesn't have permissions to make changes to another application's folder with UWP, and cannot overwrite itself while in use. If you can tell me how to make a UWP with a self-updating feature, I'm all ears.

 

The OS should *never* have sole responsibility for handling application updates. Period.

 

3 hours ago, gabrielcarvfer said:

Share images and binaries, the same way you share libraries, registering a dependency. Or in the case of user-generated files, like making a file with Word and saving to Dropbox folder, using the proper API.

Why do I need an API for that? There's a filesystem for a reason... And with UWP, all of those resources are locked up in the application or publisher shared folder... Not to mention that publisher shared folder requires that both apps accessing that shared data are by the same publisher... Or I could create an app service... which just adds a ton of overhead and asinine complication to something that should be straight forward...

 

Android's solution to this with Android N and O is pretty elegant. Just let the app have access to the user filesystem, but use a permission model to restrict it to specific subdirectories. Like if my app doesn't need all of /sdcard/ and just needs /sdcard/Pictures/myapphere, I can just request that, the user gets a prompt asking for permission to that specific directory, and I get it, without exposing everything else to my app. The key difference being, I'm exposing my app data in a place the user can access it. They have their data. They have control. Unlike UWP that just hides everything away.