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
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?
40 Comments on Microsoft Adds Ability to Block Win32 Apps from Install on Windows 10
It doesn't mean I want it to happen, but I do believe MS wants this eventually.
Thanks in advance for the insight.
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.
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.
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.
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)