3 ms·

I believe you and I admit Im quite ignorant about UWP, but from what I remember, Windows works fundamentally works with kernel objects and ref counted handles,

I believe you and I admit Im quite ignorant about UWP, but from what I remember, Windows works fundamentally works with kernel objects and ref counted handles, where if you say, open a file, a socket, create a mutex, or a Win32 control, you create a kernel object, and you get a ref counted handle to it in userspace. How is this process different in UWP, and why is it heavier? I'd guess, that since Win32 apps allocate one handle/kernel object per ui control, an UWP/WPF does not, your typical UWP app would use less handles than your typical WinForms one.

pjmlp 2y ago
COM requires that you call AddRef()/Release () methods at every single point the set of owners might change, including as function parameters and return values. This is so error prone, that naturally there are smart pointers that keep track of this. Like Apple did with Objective-C, and Cocoa's retain/release, VB 5 and 6, Visual C++, Delphi also have language extensions that keep track of this instead. In Microsoft's C++ world, these language extensions are seldom used, because of the internal riot that killed C++/CX, replacing it with C++/WinRT. So you still have the choices of using the smart pointers from MFC, ATL, WRL, C++/WinRT, WIL, or rolling up your own. All of them with the caveat, that the Objective-C/Swift optimizations of removing needless pairs of calls does not take place. So anyone that already knows the COM usage relatively well, tends to take shortcuts in the ways we are supposed to call AddRef()/Release (), as means to decrease the call count. In .NET land, the runtime takes care of being more clever, via CCW/RCW infrastructure, caching instances and such. Additionally there is the issue that a COM component can run in-proc, out-proc, or in-proc but hosted by specific Windows services, thus add OS IPC on top of each method call. EDIT: Some of the guidelines, https://learn.microsoft.com/en-us/windows/win32/learnwin32/com-coding-practices https://learn.microsoft.com/en-us/windows/win32/learnwin32/c... Better way is to get one of those COM programming bibles, "Inside COM", "COM+ Unleashed", " .NET and COM: The Complete Interoperability Guide", "Windows Runtime via C#"

pjmlp 2y ago

COM requires that you call AddRef()/Release () methods at every single point the set of owners might change, including as function parameters and return values. This is so error prone, that naturally there are smart pointers that keep track of this. Like Apple did with Objective-C, and Cocoa's retain/release, VB 5 and 6, Visual C++, Delphi also have language extensions that keep track of this instead. In Microsoft's C++ world, these language extensions are seldom used, because of the internal riot that killed C++/CX, replacing it with C++/WinRT. So you still have the choices of using the smart pointers from MFC, ATL, WRL, C++/WinRT, WIL, or rolling up your own. All of them with the caveat, that the Objective-C/Swift optimizations of removing needless pairs of calls does not take place. So anyone that already knows the COM usage relatively well, tends to take shortcuts in the ways we are supposed to call AddRef()/Release (), as means to decrease the call count. In .NET land, the runtime takes care of being more clever, via CCW/RCW infrastructure, caching instances and such. Additionally there is the issue that a COM component can run in-proc, out-proc, or in-proc but hosted by specific Windows services, thus add OS IPC on top of each method call. EDIT: Some of the guidelines, https://learn.microsoft.com/en-us/windows/win32/learnwin32/com-coding-practices https://learn.microsoft.com/en-us/windows/win32/learnwin32/c... Better way is to get one of those COM programming bibles, "Inside COM", "COM+ Unleashed", " .NET and COM: The Complete Interoperability Guide", "Windows Runtime via C#"