4 ms·

You cherry-picked one function for which some errors were specified (and even in this case; few of them), yet you ignore the general case where MSDN seems to te

by temac 9y ago

You cherry-picked one function for which some errors were specified (and even in this case; few of them), yet you ignore the general case where MSDN seems to tell "go fuck yourself" to the programmer looking for the possible different error cases. Which are important to known in case you want to react programmatively to some, and in a different way to others. Given how poor the error reporting is under Windows (so poor that useless 32 bits hex error code, component dependant, are pretty much the only (useless) thing that users are seeing), the theory of "more of those" are better is also utterly ridiculous. I've never debugged anything looking at WinNT/Win32 error codes, or even the event log, etc, while I've in plenty of occasion debugged things with Unix errno, strace (which gives errno for failed syscalls) logs in /var/log (often dumping Unix errno + some context) or even just reading stderr. If you want to understand how much of the getlasterror specs are missing in Win32, just take a look at the Wine unit tests in various are. For each of those cases (maybe 99% of which are undocumented in MSDN), that can correspond to programmers needing to replicate their own qualification beforehand usage of affected functions, or worse to implicitly make some (sometimes false) hypothesis. And the overwhelming majority of them are not related whatsoever to any kind of driver and whatnot, it is just that not even the upper layer errors are properly specified/documented. This is the kind of info which should appear somewhere in MS doc, and which does not. It's insanely ridiculous because it's obvious MS have it in a form or another, given it is crucial for backward compatibility (or compatibility in general, if you take the Wine case -- but I guess when you remain within MS the main issue is backward compat)

wfunction 9y ago
> 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...
- temac 9y ago
  ex: CreateProcess As for the openness because of installable FS; WTF? Other systems have (more) installable FS. As for my lack of experience: WTF bis? I once got an NT error through a Win32 call. That is not even supposed to happen. It was (obviously) not useful to debug. I had to put a workaround in my code. I know what is Wine. I once read its code to understand some of the ACL api of windows, and what some win functions are supposed to return. You would be surprised what is returned and in which case. MSDN seems to be so poor in this area that I found some example indicating not even some people working at MS know how some functions in this area are supposed to be used...

by temac 9y ago

wfunction 9y ago

> 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...

temac 9y ago
ex: CreateProcess As for the openness because of installable FS; WTF? Other systems have (more) installable FS. As for my lack of experience: WTF bis? I once got an NT error through a Win32 call. That is not even supposed to happen. It was (obviously) not useful to debug. I had to put a workaround in my code. I know what is Wine. I once read its code to understand some of the ACL api of windows, and what some win functions are supposed to return. You would be surprised what is returned and in which case. MSDN seems to be so poor in this area that I found some example indicating not even some people working at MS know how some functions in this area are supposed to be used...