3 ms·

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

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.

userbinator 10y ago
The API is COM-like 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: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646829(v=vs.85).aspx#open_file https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ...with the COM "replacement": https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx#basic_usage https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... (There's a 10-level nested if in that code. I recall exclaiming WTF the first time I saw that.)
- Const-me 10y ago
  > forced to use COM a few times, and that doesn't sound very encouraging I use COM a lot and I love it. The problem with COM is it’s too many things at once. It’s an excellent ABI. At the same time it’s crappy RPC and overengineered serialization framework. In addition, registration could become a point of failure. You can only use good parts and ignore the bad ones. See how MS did it with their Direct3D or MediaFoundation. > 10-level nested if in that code You can write shitty code like that with any framework and in any language. Doesn’t say anything about a framework or language. Apparently, there’s some stupid policy that prevents them from using ATL in their code samples. With CComPtr instead of raw interface pointers, you can just return the code when FAILED(), the destructor will release the objects as needed.
WayneBro 10y ago
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.
- Const-me 10y ago
  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.
  - WayneBro 10y ago
    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.
    - Const-me 10y ago
      > going to be a Win32 subsystem on phones Maybe, but currently there’s none. > Maybe people have needed to use them before? 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.
      - flukus 10y ago
        "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.
xorblurb 10y ago
> 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.
- Const-me 10y ago
  Yeah, I know there was classic Win32 environment on Windows 8 RT, just it wasn’t public. However we’re talking about UWP apps here, Windows 8 is unrelated. And there’s no Win32 environment on Windows Mobile 10, or Windows 10 IoT Core.
  - xorblurb 10y ago
    I don't think there is any emulation of Win32 either? You just have some of the functions; those that are part of UWP.

userbinator 10y ago

The API is COM-like 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: https://msdn.microsoft.com/en-us/library/windows/desktop/ms646829(v=vs.85).aspx#open_file https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... ...with the COM "replacement": https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx#basic_usage https://msdn.microsoft.com/en-us/library/windows/desktop/bb7... (There's a 10-level nested if in that code. I recall exclaiming WTF the first time I saw that.)

Const-me 10y ago
> forced to use COM a few times, and that doesn't sound very encouraging I use COM a lot and I love it. The problem with COM is it’s too many things at once. It’s an excellent ABI. At the same time it’s crappy RPC and overengineered serialization framework. In addition, registration could become a point of failure. You can only use good parts and ignore the bad ones. See how MS did it with their Direct3D or MediaFoundation. > 10-level nested if in that code You can write shitty code like that with any framework and in any language. Doesn’t say anything about a framework or language. Apparently, there’s some stupid policy that prevents them from using ATL in their code samples. With CComPtr instead of raw interface pointers, you can just return the code when FAILED(), the destructor will release the objects as needed.

WayneBro 10y ago

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.

Const-me 10y ago
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.
- WayneBro 10y ago
  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.
  - Const-me 10y ago
    > going to be a Win32 subsystem on phones Maybe, but currently there’s none. > Maybe people have needed to use them before? 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.
    - flukus 10y ago
      "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.

xorblurb 10y ago

> 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.

Const-me 10y ago
Yeah, I know there was classic Win32 environment on Windows 8 RT, just it wasn’t public. However we’re talking about UWP apps here, Windows 8 is unrelated. And there’s no Win32 environment on Windows Mobile 10, or Windows 10 IoT Core.
- xorblurb 10y ago
  I don't think there is any emulation of Win32 either? You just have some of the functions; those that are part of UWP.