Comment by trinix912
4 days ago
I remember a thin book describing changes to the API in Vista and 7 compared to XP and it was really thin. Just a few extra APIs to be able to show controls in the taskbar preview and things like that. Win32 is a stable API and I hope they don't let anyone from the Windows 11 modernization team touch it.
>Win32 is a stable API and I hope they don't let anyone from the Windows 11 modernization team touch it.
I've heard a Microsoft executive talk about win32 as legacy that they want to replace. I don't think that's realistic though, it's probably the last piece of technology keeping people on the platform.
It was the goal with UAP and UWP, but they clearly messed up the execution.
https://learn.microsoft.com/en-us/uwp/win32-and-com/win32-an...
Win32, the C API, is stagnant since Windows XP, other than some ...Ex and ...ExN kind of additions.
As mentioned above, the new APIs are mostly delivered as COM, occasionally with some .NET bindings.
There is still a silo trying to push WinRT now on Win32 side, although given how they made a mess of the developer experience only those with Microsoft salaries care about it.
This oldie shows some of the background,
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
Last year I ran into the issue of .NET network bindings not returning all NICs. [0] This issue has been present in the .NET since the genesis and only resolved in .NET 9. I had to create my own Win32 wrapper so everything works properly in .NET 4 frameworks ... still need to maintain Windows 7 pre-SP1 support in some applications.
Smells like Microsoft was trying to create APIs based on assumptions versus a 1:1 method that exposes managed code and hides unmanaged.
[0] https://github.com/dotnet/runtime/pull/100824
Except for anything that came after XP, you need to at least make use of COM.
WinRT can be avoided if you don't do any modern stuff like the new context menu, WinUI, or Windows ML.
And those new APIs (at least the context menu API) apparently require a "package identity", which requires a signed MSIX installer, which requires paying for a code-signing certificate, unless I'm missing something in the docs.
That is because of what people claiming UWP is dead, haven't gotten the whole picture.
UWP as separate subsystem, yes it is deprecated, and no one should be using it, although Microsoft was forced to introduce .NET 9 support on UWP, because many refuse to move away from UWP into WinUI 3.0, given the lack of feature parity.
Now, when WinRT was made to also work on Win32 side, it also brought with it the concept of package identity, which forms a part of the whole app isolation from UWP similar to Android, now on Win32 as well, hence the MSIX.
https://learn.microsoft.com/en-us/windows/win32/secauthz/app...
On the specific case of the context menu, it depends on what is being done,
https://blogs.windows.com/windowsdeveloper/2021/07/19/extend...
You can work around app identity when using the suggested alternative of unpackaged Win32 apps with sparse manifests.