For the people here who know windows and Linux, what are some of the major differences between the two that you like/dislike?
I know nothing about windows internals, but I’m curious
I know nothing about windows internals, but I’m curious
In Linux, configuration is done via plain text files. In Windows, there is the registry.
In Linux, there is the root filesystem, where everything else is mounted beneath. In Windows, there is C: and more.
In Linux, the native string encoding is UTF-8 code units stored in char of one byte size. In Windows, the native string encoding is UTF-16, stored in wchar_t of two bytes size.
In Linux, there is fork. In Windows, there is no fork.
In Linux, there is no unified graphics API. There is GTK and Qt for UI, and OpenGL and Vulkan for games (roughly speaking). On Windows, there is Win32, WinForms, WPF, WinUI, DirectX and also OpenGL and Vulkan.
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.
PowerShell is .NET and operates a few more abstraction layers above the Win32 API.
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.
Also The Windows API pattern is typically:
1. Initialize a "descriptor" struct
2. Pass that descriptor struct by reference to a "create" function
3. Get ComPtr<> for resource
Where a ComPtr<> is a smart pointer that manages the lifecycle of an object across different processes
Also Windows built UTF-16 support into their APIs 30 years ago, so a lot of API calls involve constructing UTF-16 literals