Jump to content

API Issues Under The Covers


NoelC

Recommended Posts

With Windows 8 making "ugh, desktop" development unfashionable, and with obvious reductions in desktop functionality (e.g., the removal of Aero Glass, etc.), I've wondered whether the software may be suffering neglect under the covers, in the parts we don't see.

 

I can confirm that it is.  It's a trend that will spell the demise of Microsoft if left unchecked.

 

No, I'm not talking about the debacle with the August updates.

 

Lately I've been working to bring some software to release, and we have a LOT of instrumentation inside it to catch unexpected errors, leaks, etc.

 

With Windows 8.1 we're seeing a lot more unexplained system errors (the kind you can retrieve with GetLastError()) between events.

 

What I mean is this:  We get an event from Windows, do a GetLastError() call, and unexpectedly instead of ERROR_SUCCESS there's an error such as "Invalid Window Handle" or "Access Denied" just sitting in there.

 

This is a difference in behavior as compared to Windows 7 and earlier. 

 

That's not to say we never saw errors this way with Win 7, but for the most part when we did we were always able to trace them back to a particular source and actually DO something about it.  Sometimes it was the background code we are running, and occasionally it was a problem in a common control that's well-known.

 

Microsoft documents many of its API calls as setting the "last error" value if there's a problem, and specifically documents that the "last error" may not be cleared if a call succeeds, but in practice it's been rare that you get a success status back and GetLastError() returns something other than ERROR_SUCCESS.

 

Now there are whole new sets of these errors showing up with Windows 8.  Anyone who appreciates the rigor it takes to make an application work perfectly will see this for what it is - a very bad trend.  To me it indicates a whole new low level of discipline or possibly even lack of knowledge in Microsoft's technical ranks.

 

-Noel

Link to comment
Share on other sites


Right, I know that.  But my point here is very subtle.

 

Even though we have direct error checking, we also instrument our code to look for unexpected error codes cropping up anyway at the start and end of event handling, so as to pick up on any subtle errors our local error handling may have missed.

 

In the past we've always been able to get to the bottom of why such errors show up, and eliminate them.  It makes the code more robust.  Problem is, there's a whole new set with Windows 8 and it's starting to look like we're not going to be able to eliminate them all.

 

That tells us subtle things about the robustness of the operating system.

 

-Noel

Link to comment
Share on other sites

I don't think it means much. No point in expecting undocumented behavior to stay. You might even call it counter-documented.

 

Who knows, maybe it's some sort of internal optimization to not set the error code to 0. You might step into it in 8 vs 7 and see what changed. :)

 

BTW, did you try running it in the various compatibility modes?

Edited by shae
Link to comment
Share on other sites

I'm sure it's not a problem, per se, but I see it as a possible minor insight into the minds and culture of Microsoft.

 

I have compared it with Win 7 and there are quite a bit fewer errors showing up there.

 

No, I haven't run it in compatibility mode as it shouldn't need it.

 

-Noel

Edited by NoelC
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...