> I've never debugged anything looking at WinNT/Win32 error codes I think your lack of experience explains the issue. I do it pretty damn frequently. > so poo

> I've never debugged anything looking at WinNT/Win32 error codes I think your lack of experience explains the issue. I do it pretty damn frequently. > so poor that useless 32 bits hex error code, component dependant, are pretty much the only (useless) thing that users are seeing All you need to do is look up the error code in either the headers or in MSDN [1] and then read the error message. It explains what's going on and does it far better than the minimal number of errnos possible. And no, I didn't cherry-pick anything. Like I said, I picked the first function I thought of. If you really cared enough to provide an example you could/would have, but you didn't. And this is ignoring the fact that I then told you why the listing of error codes or lack thereof was not possible in general. And it's not like in Linux you don't need to write and run and re-write and re-run code fifty times before you know all the edge cases. I remember having one hell of a time trying to figure out how to use epoll, for example. The documentation could easily be 2-3x as long. Regarding WINE: WINE is not software that uses the Windows API. It replicates the Windows API. Nobody ever claimed Windows's error reporting behavior is easy to replicate. We're talking about APIs, i.e. interfaces for programmers that program TO the system. An open set of error codes makes a ton of sense for all the reasons I listed. Of course an open sense means you'll have a much harder time replicating the behaviors. Windows was not designed to be easy to copy; it was designed to be easy to use. I would've thought that would be obvious. [1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms681381.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...