Item — HN Reader

What are you talking about? None of it is relevant to the point i am making.

Also you do not need COM to program in C/C++ directly on Windows API since they are all C interfaces anyway. COM is just an architecture you choose to use or not depending upon your needs.

Ever since managed languages/virtual machines became "standard" programming platforms most Windows programmers only write to these. Everything is at such a high-level now that only curious programmers delve deeper into the rabbit-hole.

1 comments

You definitely do, unless you are stuck in Windows XP view of computing world.

It is like using ReactOS instead.

All Windows APIs since Vista are delivered via COM.

How much Windows development are you doing actually?

Not that much apparently.

Also someone has to surface Windows APIs to managed languages, they don't appear by magic.

> All Windows APIs since Vista are delivered via COM.

Nope, This right here tells me you do not have much actual programming experience in Win32/Win64 apis nor of Windows Internals. The C-style windows apis are from kernel32/gdi32/user32/etc. user-mode dlls which call into intermediate ntdll/win32u dlls which then calls into kernel mode ntoskernel.exe/win32k.sys. With modern Windows there are another layer of abstractions with "Windows API Sets" (https://learn.microsoft.com/en-us/windows/win32/apiindex/win...) which decouple those user api from their actual implementation dlls.

COM is at user-mode and so interfaces to the first set of dlls only. Since the windows api breadth is vast not all of them are exposed via COM. WinRT uses/enhances classic COM but also calls Win32 api as needed. So Win32 api and WinRT api coexist with the latter providing the "modern" way to api access - https://en.wikipedia.org/wiki/Windows_Runtime But because WinRT is oriented towards secure sandboxed apps many low-level Win32 apis dealing with memory management, thread/process manipulations, system hooking etc. are limited/removed entirely from WinRT api.

For your edification see this detailed older article; Turning to the past to power Windows’ future: An in-depth look at WinRT - https://arstechnica.com/features/2012/10/windows-8-and-winrt...

Your claims must be backed up with references before asking others about their experience. I only see you name dropping and quoting historical data in all your comments which is not relevant to discussing/understanding anything.

Every new API since around NT5.2/6.0 era had to get explicit waiver to be provided as anything other than COM interface. Some additionally have weird hybridization going on IIRC that lets you have some kind of faster path but still has COM exposed (IIRC that's only DirectX?)

That is for new APIs, not extensions of existing APIs.

IIRC, most non-COM methods you'll see for those are wrappers around COM calls. Back when WinRT was promoted as the next big thing, once you got outside of the small circle of WinRT propaganda there was explicit acknowledgement that all of the APIs are actually COM based enabling continued development of non-.NET compilers.

Of course underneath it all, especially once you get to userland-kernespace interactions you go back to combinations of IOCTL, memory mapped IO, some basic object calls and undocumented fun of OpenVMS-derived IPC, but a considerable chunk of that is not exposed or documented for non-blessed programmers.

Right; the links i provided above explain it in more detail.

WinRT is made up of component dlls and therefore exposes functional interface bundles. But the implementation of these components mostly took the path WinRT -> Win32 api -> ntdll (aka "Windows Native api" which is undocumented). But since MS wanted to push WinRT they allowed some paths to be WinRT -> ntdll. AFAIK this is what the mandate/waiver was for.

So you have the current situation that some Win32 apis have no analogues in WinRT and vice-versa. The DirectX path uses "Nano-COM" (a stripped down version of COM) which calls into user-mode runtime dlls which then takes another path to the kernel.

Lets not even get into how .NET projections/interfaces/wrappers do their job ;-)

The key point to know is that COM is only a packaging architecture/framework/middleware for structuring at a user-mode binary level.

It is all quite elaborate and complicated and so making a one-line statement like "everything is COM" is sheer cluelessness.