Windows API - GetLastError woes

[Brian Hulley]

Esa Ilari Vuokko wrote:
> Hi,
>
> My "use case" is in Win32-package, where we simply call a FFI
> imported call and on failures call GetLastError to get extended
> error code.  GetLastError of course only works on same OS thread
> and contains sensible results only before next Windows API call.
> It's much like C/posix errno.
>
> So, we *must* call GetLastError in the same OS thread, and there
> must not be any Windows API calls in between, including those caused
> by, say, rts' memory allocation or calls to lock mutexes.  Unless the
> error code is saved via Get/SetLastError.
>
> Also, I'd like not to run the code in a another OS thread (and
> that won't fix the rts-caused Windows API calls), because the calls
> are supposed to be fast, and OS-level context switch isn't fast.
>
> Is this problem real, or did I miss some magic feature of rts?
>
> The only way to solve this problem seems to be to wrap all
> calls in C-functions that take care of reading GetLastError.
> Not that it's impossible, just very annoying.

If there is no better solution, would it be possible on failure to somehow 
enter a critical section and repeat the call that caused the failure and 
then call get last error and exit the critical section so that normal calls 
would be fast but only failed calls would be slow?

Regards, Brian.
-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com