Editorial Microsoft Adds Ability to Block Win32 Apps from Install on Windows 10

[qubit]

I think that Microsoft has introduced this feature for these reasons and in this order:

1 To eventually make it mandatory to only install approved apps from their Windows Store. They then get a cut of all revenue generated, just like Apple do. And Apple take a hefty 30%. Just think what a money spinner it would be for Microsoft. It will take them a long time, but they've got it. I believe Google gets a cut from the Play Store too, but don't quote me.

2 Control what you can run on your computer. Control is power in many different forms.

3 Improve the security of your computer to reduce the likes of garbage like cryptolocker from infecting it.

Oh, and yes, if there is any question, this is an editorial in the fullest sense of the word. Enjoy.

Shame on you! Keep 'em coming.

 

[FordGT90Concept]

I wouldn´t be surprised if some manufacturers start shipping their PCs/laptops with Win 10 Cloud only.

That's actually a certainty already. Microsoft wants to create a competing product against Chromebook. I'm sure this is one of the features that bring them closer to that.

For which API, UWP or Win32? Care to elaborate?

UWP is "significantly slower" than Win32. Probably 10-30%. UWP is completely managed (memory pointers are forbidden) like .NET Framework is. They're very closely linked. UWP can be made to run on any processor architecture (ARM, x86, and AMD64 right now). I believe UWP has a path for emulating Win32 too (they demonstrated this in a Windows Phone 10 feature).

 

[rtwjunkie]

1 To eventually make it mandatory to only install approved apps from their Windows Store.

Hopefully they don't beat YOU down. I mentioned this (and yes this concept also included gaming) and almost got laughed out of the forums. I have held onto this ever since Uncle Gabe said with W8.1 that it was set up to be a walled garden if MS wanted to.

It doesn't mean I want it to happen, but I do believe MS wants this eventually.

 

[FordGT90Concept]

I think Microsoft is aiming more for a 60/40 ecosystem where the majority of users are on UWP, because that's all they need, and the rest are professionals and power users that sparingly use UWP. I don't think Microsoft expects to eliminate Win32 any time soon simply because the performance differences make it impractical. Case in point: compare the UWP versions of Office programs to the Win32 version of Office. The former is good when you're mobile, the latter is good when you're stationary. The capabilities of the latter far exceed the former.

 

[Franzen4Real]

I have wondered something for quite some time, and this seems the perfect time/place to ask those with more knowledge than I... Is there anything fundamentally different in an app, and a program? I understand apps currently as being lightweight, slimmed down software that is more mobile friendly, and just have core features that average users may want/need. Whereas a program is full featured, robust, and optimized for an X86 environment. (so say Photoshop vs. Photoshop Lite) Assuming that is correct, what, if anything, keeps software developers from designing all software from the ground up as an app, solely from a technical perspective? (I do see the sales/distribution differences and they are quite big). Are there limits to size, available resources (threads, memory), or perhaps limits to multiscreen use, etc etc. that are inherent to an app as opposed to traditional W32 programs? I did see the statement made of a performance loss, so I have considered that already. And I guess I'm thinking of mostly professional and content creation software such as the Adobe Suite, AutoCAD, Solidworks, and AAA games.

Thanks in advance for the insight.

 

[FordGT90Concept]

Yes, UWP is an interpreter, an app running in UWP can't function without the interpreter. Only the UWP core has access to the actual hardware, the app does not.

By not having direct access to the hardware, they perform slower. UWP has to translate everything and make sure it passes safety and security checks.

If UWP has issues, all of the apps running on top of it also will. I've seen that in early release of Windows 10 where all UWP based, Windows-included apps broke (Edge, Calculator, Mail, etc.). Granted, it was only broke in one user account.

 

[Shihab]

That's actually a certainty already. Microsoft wants to create a competing product against Chromebook. I'm sure this is one of the features that bring them closer to that.


UWP is "significantly slower" than Win32. Probably 10-30%. UWP is completely managed (memory pointers are forbidden) like .NET Framework is. They're very closely linked. UWP can be made to run on any processor architecture (ARM, x86, and AMD64 right now). I believe UWP has a path for emulating Win32 too (they demonstrated this in a Windows Phone 10 feature).

Aren't pointers functions of the language? Or am I confusing pointers?

 

[FordGT90Concept]

Memory pointers are intrinsic to memory architecture in most processors. The problem is that a minor error in a pointer can lead to very unpredictable outcomes. Managed programs wrap pointers up and hide them away. When you create a variable or an object, a memory pointer has to exist referencing that in virtual memory. It is transparent to the developer because they reference that variable or object by name instead of by location. The interpreter translates those names into locations and returns the data.

 

[timta2]

Every other place, where I've read about this, has mentioned Microsoft copying Apple's Gatekeeper. I'm not surprised that it wasn't mentioned here.

 

[ManofGod]

Hopefully they don't beat YOU down. I mentioned this (and yes this concept also included gaming) and almost got laughed out of the forums. I have held onto this ever since Uncle Gabe said with W8.1 that it was set up to be a walled garden if MS wanted to.

It doesn't mean I want it to happen, but I do believe MS wants this eventually.

To believe this, you must abandon all common sense and logic. No, you were not ever laughed out of the forums, almost, you just simply do not have a leg to stand on with this point. I need not explain why because I am sure all those games that you have will explain for me.

 

[rtwjunkie]

To believe this, you must abandon all common sense and logic. No, you were not ever laughed out of the forums, almost, you just simply do not have a leg to stand on with this point. I need not explain why because I am sure all those games that you have will explain for me.

Well hit me up when MS turns out to not live up to those altruistic and trustworthy traits you attribute to them. Maybe we can have a good laugh together then.

 

[lexluthermiester]

Way to go Microsoft! One more method of public control we don't want and don't need. You've also succeeded in getting that one foot you have in the grave just a little bit further in..

 

[Trovaricon]

UWP is "significantly slower" than Win32. Probably 10-30%. UWP is completely managed (memory pointers are forbidden) like .NET Framework is. They're very closely linked. UWP can be made to run on any processor architecture (ARM, x86, and AMD64 right now). I believe UWP has a path for emulating Win32 too (they demonstrated this in a Windows Phone 10 feature).

Are you serious? I have seen so much misinformation (intentional including) about UWP and Windows Runtime in last year and half, yet you managed to leave me in awe.

UWP is more like a API profile (by device type) of Windows Runtime + fancy installer.
UWP apps use the Windows Runtime, a native API built into the operating system. This API is implemented in C++ and supported in C#, Visual Basic, C++, and JavaScript in a way that feels natural for each language. [ms docs]

Memory pointers are used extensively in Windows Runtime even when used from C#.

btw .NET doesn't support memory pointers?
IntPtr is in .NET from version 1.1. It is used for all kinds of Handles or when using native libraries (dllimport / pinvoke).
Do you know what /unsafe compiler switch is for when compiling C# code? Yes, it is to allow usage of Pointer types in C#

Yes, in the end we might end up with "simplification for the masses" mis-naming like in the case of Direct3D used even by MS, AMD & NVidia as "DirectX" in PR materials because of "reasons". But please, keep things technically correct on technical sites.

 

[FordGT90Concept]

"UWP is completely managed (memory pointers are forbidden) like .NET Framework is."
I was talking about apps built for the UWP framework, not UWP itself. I'm fully aware that UWP and .NET Framework are predominantly coded in C++ like much of Windows.

IntPtr is a managed pointer. It is almost strictly used for external calls where pointers are unavoidable.

/unsafe can lead to not getting Windows Store certification.

 

[Trovaricon]

"UWP is completely managed (memory pointers are forbidden) like .NET Framework is."
I was talking about apps built for the UWP framework, not UWP itself. I'm fully aware that UWP and .NET Framework are predominantly coded in C++ like much of Windows.

You are trying to tell me, that if you write a C++ application with UWP template in Visual Studio, you are forbidden to use memory pointers? How would that "work"?

IntPtr is a managed pointer. It is almost strictly used for external calls where pointers are unavoidable.

Sure, it is still somehow in conflicts with your "memory pointers are forbidden" statement.

/unsafe can lead to not getting Windows Store certification.

Only after reading this it finally hit me what is the problem at hand. You seems to possess some theoretical knowledge from the time of inception of Windows Store. (Windows Phone 7, 8)
If you are targeting Windows Phone 8 with C# application (template renamed to WP 8 "Silverlight" in newer VS to imply the obvious for those that missed it) then you are spot on! - no unsafe code in C#

Now If we talk about Universal Windows application (target W8.1) or Universal Windows Platform (target W10), then we talk about different APIs available and different restrictions imposed.
Please take a look at one of the image manipulation (camera) related MS UWP C# samples - pointers everywhere!

I know that you are more likely to spot a unicorn than to see a non-Microsoft software developer with knowledge about Windows Runtime* (God forbid he uses it at work!), but believe me, they exist...


On Topic:
Isn't this restriction related to Windows 10 "Cloud edition" we keep hearing about? Like one step up from it (cheap Windows version for OEMs) which will buzz you with this message (annoying you to press Install anyway) instead of Security warning that publisher couldn't be verified seen when on many installers (probably not Chrome...)


*personal experience from software dev. companies specializing in MS technologies (esp. .NET) - at least 95% devs has no clue (and I am being optimist)

 

[FordGT90Concept]

You are trying to tell me, that if you write a C++ application with UWP template in Visual Studio, you are forbidden to use memory pointers? How would that "work"?

C/C++ never had to use the .NET framework even though it was available. I expect the same to be true of UWP. Memory pointers are intrinsic to C/C++ design. They're not managed by nature.

Only after reading this it finally hit me what is the problem at hand. You seems to possess some theoretical knowledge from the time of inception of Windows Store. (Windows Phone 7, 8)
If you are targeting Windows Phone 8 with C# application (template renamed to WP 8 "Silverlight" in newer VS to imply the obvious for those that missed it) then you are spot on! - no unsafe code in C#

Indeed, I have not yet dabbled in UWP. I probably should but I really see no reason to.