Monday, February 27th 2017

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

In a story headline that is sure to ruffle some reader's feathers, Microsoft has done exactly that: Added the ability to block installation of any app using the oldest remaining major API in Windows: Win32.

But hold on to your nerd-battlewagons, brave tech warrior. Microsoft is not enabling this feature by default. It is currently only in an experimental build, and per MS, it will not be on by default in any mainline build ever produced. It's simply there for "added security."

And yet, is this not a sort of admission of Win32's supposed inferiority from Microsoft? The fact that you can block this and not block the Windows Universal apps is in a way saying "here, these are safe. No, win32 is not."

Oh, and yes, if there is any question, this is an editorial in the fullest sense of the word. Enjoy.
What makes the Universal Windows platform safe? Is it the sandboxing inherent to the platform? Is it the finer grained permissions system the API provides? Yes, to a degree maybe. But I think the main tactic that Microsoft is taking to keep you safe is to take you out of the driver seat.

Think about that for a bit. That "Windows Store?" Is it any different from Apple's "App Store?" Who controls it? Who decides what gets in and what doesn't? What you see and what you don't? Here's a clue: It isn't the users. Even the word "App" is offensive to me personally, as a power user. I mean what the heck is an "app" anyways and where did my "applications" go? Was the word seriously too big to comprehend so they had to stupify it for the average user?

And yet, as I write this, I feel a tinge of remorse. I don't need this restraint. I don't need that MS-nanny-state watching over me. But I know a lot of people who do. Family. Elderly. People I love. People who mean well but don't know any better. Why should they? It took me most of my life to get here? Can I honestly ask them to devote the same dedication? Is that fair?

But still, this strikes me in an odd place. On one hand, I see it as good as I can turn this on for "problem users." On another hand, I can't help but see it as the first nail in the coffin of an API that puts you in the driver seat and makes you responsible for whatever you do there. Yes, that driver seat has power, and can do awesome things. It can also make you crash in a ditch and no amount of singing "Jesus Take the Wheel" will save you from something like a cryptolocker malware. I want to protect those people, but if MS ever pulls the plug on an API where I'm in charge and can wreck my computer properly, the next thing I'll be installing is the nearest OS that lets me break things again.

So, fellow user, I then turn the discussion to you. Where do you draw the line? When is too much taken away, and how much do we need to take away to protect those who are for lack of a better term "menaces on the highway?" What about those like me, who are menaces on the highway no matter what you do? Hmmm?
Source: MSPowerUser
Add your own comment

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

#26
FordGT90Concept
"I go fast!1!11!1!"
EndeavourI 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.
ShihabyoooFor 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).
Posted on Reply
#27
rtwjunkie
PC Gaming Enthusiast
qubit1 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.
Posted on Reply
#28
FordGT90Concept
"I go fast!1!11!1!"
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.
Posted on Reply
#29
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.
Posted on Reply
#30
FordGT90Concept
"I go fast!1!11!1!"
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.
Posted on Reply
#31
Shihab
FordGT90ConceptThat'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?
Posted on Reply
#32
FordGT90Concept
"I go fast!1!11!1!"
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.
Posted on Reply
#33
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.
Posted on Reply
#34
ManofGod
rtwjunkieHopefully 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.
Posted on Reply
#35
rtwjunkie
PC Gaming Enthusiast
ManofGodTo 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. ;)
Posted on Reply
#36
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..
Posted on Reply
#37
Trovaricon
FordGT90ConceptUWP 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.
Posted on Reply
#38
FordGT90Concept
"I go fast!1!11!1!"
"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.
Posted on Reply
#39
Trovaricon
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.
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)
Posted on Reply
#40
FordGT90Concept
"I go fast!1!11!1!"
TrovariconYou 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.
TrovariconOnly 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.
Posted on Reply
Add your own comment
Mar 15th, 2025 22:19 EDT change timezone

New Forum Posts

Popular Reviews

Controversial News Posts