On Thu, 28 Nov 2019 at 21:08, Stephen Leake wrote: > I keep hoping Microsoft will do better, but I'm always > disappointed. The most common error I get is "file not found" because > PATH is wrong or the file is not installed, when it's perfectly clear > that the system knows the name of the file it's looking for, but _I_ > don't, and it's not telling me! _very_ frustrating; Gnu/Linux is much > better here. So I assume that's the error message GetLastError will > return here. > > I'm also assuming that whoever wrote w32_delayed_load tested calling > GetLastError, got an unhelpful message, and deleted it. It would be nice > if there was a comment saying that. If I get motivated, I might try that > experiment, but given the above, it's not high on my list. > I see where you're coming from but I'm not sure you're being even-handed. I'm not their advocate, but you can work reasonably seriously with Microsoft Windows operating systems if you have to, despite the obvious disadvantages. GetLastError() is just an integer, like errno. You must have to do a little more work to get descriptive errors from other systems? There's probably an equivalent. The Application error log in Event Viewer springs to mind. The doc for LoadLibrary (< https://docs.microsoft.com/en-gb/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya>) says: "To enable or disable error messages displayed by the loader during DLL loads, use theSetErrorMode function". I think the errors are displayed in a message box, but it might be helpful for debugging, at least if it's an application you can recompile. ("Dependencies" gets detailed information somehow. But for all I know (I haven't looked) it emulates the loader to see what happens.)