News for hackers. Stuff that matters.
Re:If you're just going to sit there doing nothing, at least... by jeroenhd on Friday February 16, 2024 @08:14PM (#39405275)
This is something I kind of like about the Microsoft APIs. Their error codes aren't always perfect, but at least they give you some indication where things went wrong.

From MSDN:

> An HRESULT value consists of the following fields:

> A 1-bit code indicating severity, where zero represents success and 1 represents failure.

> A 4-bit reserved value.

> An 11-bit code indicating responsibility for the error or warning, also known as a facility code.

> A 16-bit code describing the error or warning.

The "reserved value" also includes a bit for non-Microsoft code (which driver vendors and other API producers can use, although I don't know how often they do)

There's a list of common "facilities" here: https://learn.microsoft.com/en-us/openspecs/windows_protocol...

As a regular user, you will see errors like 0x8ACEF00D, but if you decode them, you can get a sense of what part of the system ran into the failure. Compared to the "negative value indicates failure, look up the possible failures and what they mean for every function" approach many other APIs follow, that's a welcome change.

Of course there's no guarantee that Microsoft doesn't return some kind of meaningless internal E_SOMETHING_WENT_WRONG value, but for a lot of APIs, there are details hidden in plain sight. It won't tell you your ISP's fiber has snapped, but it'll tell you if the problem is within the driver, a security limitation, an HTTP error, or a generic network stack issue.

Re:If you're just going to sit there doing nothing, at least... by rerdavies on Saturday February 17, 2024 @05:25AM (#39408174)
HRESULTs are well intentioned. They originated in OS/2; but Microsoft always seemed to use them half-heartedly.

Users should not be seeing "08CAE5D012" error messages. They should be seeing "Connection refused. (08CAE5D012)" messages, or "No connection. (83255321)" messages instead.

There's is a non-trivial protocol for translating HRESULTs into error text; but it is often not supported properly by Windows applications, or Windows OS components.

e.g. DirectX which returns generic 0x8004005 E_FAIL errors. Or the WinSock APIs, which return HRESULTs, but don't provide text message translations; or Microsoft Installers that report raw HRESULTs with no attempt to capture the associated error text.

With discipline, the entire system could have worked. But there wasn't, and it didn't.