* On Tue, 3 Oct 2006, Detlef Riekenberg wrote: > * On Di, 2006-10-03 at 20:40 +0300, Saulius Krasuckas wrote: > > Well, thanks. I'll change that, but is it wrong just because it > > slightly increases code complexity for no direct benefit? I just want > > to know for future. > > For the normal case, SetLastError() is called only on failure. > > http://msdn.microsoft.com/library/en-us/debug/base/setlasterror.asp
Do we trust MSDN when we can check things ourselves? No, we don't trust, right? :) > There might be some broken Applications, that expect GetLastError() to > return a special Value, even when a Function returns success, but they > will fail very fast on native Windows with a different version of > Windows, SP, Hotfix or Driver. That could be a way for a program to differentiate between 9x and NT versions without calling GetVersion*(). I saw one code/app in the past, which did such check by querying kernel32.dll for the OpenVxD export ;) > Do you have such a Application? No, I didn't. If I had, that would be my primary argument. I even doubt there exist any application that calls LZOpenFileW() in the world, but still Wine implements it plus it contains W-to-A cross-call, by eliminating which I want to ensure no algorithmic logic was flawed in A-version or in W-version of mentioned function. Hence my intense testing for SetLastError(). I hoped this would let me easier to (re)build code for LZOpenFile[AW]. It would make the code stricter. So I won't be lost in some lots of possible solutions ;) But nevermind, Detlef. I will add those "wrong" checks just in some of my internal branches to make my fantasyless life easier and won't disturb the life of the whole project :]
