[jackfraser]

The problem I always had with this was that Windows has this whole layer of objects and what might even be elegance in places all hidden under the hood, and unless you're a C++ hacker you can't actually work with most of it. CMD and the GUI tools never exposed half of it to you; Powershell helps, but it's all still very hidden and hard to get to.

In comparison, Unix provides all the tools needed to take it apart and put it back together again. When you do need to interact with some syscall interface, there's almost always a complete CLI around it. It really makes it much easier to get into the nooks and crannies, inconsistencies aside.

[yjftsjthsd-h]

Yeah, as a person who hates Windows and loves all things unix, the NT kernel and underlying system have long struck me as a well-designed, nice system... with a poor userland and a terrible UI on top. But the kernel is nice.

[atombender]

He's talking about the kernel. The Windows NT kernel and the Windows APIs use handles to represent kernel/API objects, and every handle has things like security associated with it.

For example, CreateProcess() gives you back a HANDLE value representing the process, and you can close it with CloseHandle(). Everything is a HANDLE: Files, pipes, threads, etc. A notable exception is sockets, which for historical reasons use an API modeled on BSD sockets.

The object stuff you're talking about is presumably COM, which is different. COM is great, but has nothing to do with the kernel.

[hyperman1]

He's not talking about COM. Thé HANDLEs are a handleiding to a kernel object. This means multiple differentiatie handles light exist to the same object, and handles in different processen have probably differentiatie numeric values for the same object. Think win32 handle = Unix file descriptor (roughly)

[atombender]

No, the poster said: "unless you're a C++ hacker you can't actually work with most of it." That strongly implies COM. The Windows APIs are C.