[steve1977]

> In Windows, everything is a handle (except sockets, which are copied from BSD).

A handle to an object. I think that is the main difference that is also visible in tools like PowerShell (as compared to the UNIX shell).

Linux is very free form, Windows is much more structured and strongly typed.

[Longhanks]

I'm not sure I understand, the APIs are opaque HANDLEs, nothing prevents me from passing a file handle to ShowWindow(), just as nothing prevents me from passing a timerfd to write(), of which neither makes any sense.

PowerShell is .NET and operates a few more abstraction layers above the Win32 API.

[mananaysiempre]

HWNDs are actually a bit special. HANDLEs you get from CreateFile and so on are implemented by the NT kernel and are real capabilities (like Unix fds), so the actual bits of a HANDLE from one process are useless in any other one.

On the other hand, HWNDs are global (at least within a window station, I don’t know how that works). If you display the numeric value of a HWND in a message box in program A and type it by hand into program B, program B can (usually) pass it to PostMessage and successfully reach program A. I don’t know if other USER and GDI “handles” (e.g. HMENU, HRC) are like that, but I wouldn’t be surprised if they are.

I also think defining STRICT before windows.h will still prevent you from passing a HANDLE where an HWND is needed, even though the last (also the first and the only) time Microsoft promoted this feature was in the Win16-to-Win32 migration docs in the early 90s. A HANDLE to a file vs a HANDLE to a named pipe or even a mutex is another matter—those are all genuine NT objects, and handles to them are to an extent all the same kind of thing.