It makes me think Electron is the new Java. Trying to make things cross-platform inevitably introduces inefficiencies and lowest-common-denominator functionality. The UI may look native but the contrast in everything else is instantly noticeable.
That said, these samples seem to be mostly UWP/C# stuff which I wouldn't consider "real native" i.e. Win32 --- I've been programming in Win32 for a long time and even the differences in resource usage between Win32 and .NET apps are noticeable.
That UWP thing is the new real native. On some Windows platforms, win32 API is emulated and very limited.
It works fine without .NET. The API is COM-like, can be consumed from C++ and JavaScript. However, C# is much simpler than C++ for that, one reason is many APIs are asynchronous and C++ has no async-await.
I have been forced to use COM a few times, and that doesn't sound very encouraging... IMHO Win32 is simpler for a lot of things, compare for example the task of using the file selection dialog the Win32 way:
UWP is a sandbox. I wouldn't call that native. You can't even do any sort of local IPC with it if your other process is Win32.
Furthermore:
- You can't run a UWP as Administrator.
- A UWP app has less access to the system and user data.
- You can't develop a UWP app that has in-process plugins.
- You can't hook into a UWP app like you can with actual native Win32 apps, to send keys, hook keys or do screen overlays.
In summary, UWP is full of artificial limitations and that's why nobody is building on it. I'm looking forward to the day when Microsoft announces that UWP is either going away or being pulled out of it's sandbox. Then I'll consider using it.
Just because you don’t have permissions to do something, doesn’t mean something is wrong with the API. Technically, you can restrict permissions in a similar way on any NT-based OS. Doesn’t mean the Win32 API is not native. Doesn’t mean those ACL permission checks everywhere are “artificial limitations”.
Most of those UWP’s limitations are here to protect users. Microsoft learned their lesson about the security. I don’t want your app to be able to do local IPC or hook keys on my PC.
Furthermore, you can’t have unrestricted access to the lower levels of the system, and universal apps at the same time. There’s no Win32 subsystem on the phones, or on embedded windows 10.
There is going to be a Win32 subsystem on phones. That's the next thing Microsoft is trying. They already showed Windows 10 running on arm with Win32 apps running on it.
The things I mentioned or not permissions. They are limitations. No UWP app is permitted to do them so they might as will not exist. However those things do exist and there must be a reason why. Maybe people have needed to use them before? I think so.
It’s called “progress”. Over time, better and safer APIs replace dangerous lower-level things. For example, DirectX deprecated direct access to the graphics and audio hardware. Similar way, UWP deprecates direct access to system and user data, physical display and keyboard.
Apparently, Microsoft prioritized user’s safety and battery life over needs of those few software vendors who heed the functionality for legitimate reasons.
"Regress" would be more appropriate, it's taking away useful features. Gimping what an application is capable of should not be the solution to security.
How are you going to secure user against key loggers when there’s a “useful feature” allowing any app to listen keyboard events of the whole windows station?
Keep in mind there’re another useful features, allowing users to run an unsigned application from any source, with administrator privileges.
There are permissions for which apps can use my Mic, Camera, Contacts, Call history, etc... Microsoft could easily add one that lets me run UWP apps with a higher privilege that allows IPC with Win32 apps.
As it is right now, you can't even build a UWP app that can talk to a server app running on the same exact machine. Instead, you have to build all of your UWP apps so that they depend on some Internet server.
Permission settings only work for the minority of people who’re into that information security thing.
Look at the mobile apps.
Many apps require geolocation permission, not because they need it, but because they include some ads, and ad provider who made their ad serving control needs GPS coordinates to serve better ads.
The majority of users don’t care.
They just click “I agree” on those permission popups, so unlimited number of third-parties able to literally track their each step.
> On some Windows platforms, win32 API is emulated and very limited.
hm, very limited, maybe. There is actually no public Win32 for the platforms you have in mind, I think, but a subset is common with UWP. However, it's not emulated... and probably nearly all of Win32 are standing right there, only you just can't use it...
For ex in Win8 RT the whole (or nearly whole) Win32 was there and could even be used by a non-Windows program: Office.
That said, these samples seem to be mostly UWP/C# stuff which I wouldn't consider "real native" i.e. Win32 --- I've been programming in Win32 for a long time and even the differences in resource usage between Win32 and .NET apps are noticeable.