StreamInProc proc hFile:DWORD, pBuffer:DWORD, NumBytes:DWORD, pBytesRead:DWORD

invoke ReadFile, hFile,pBuffer, NumBytes, pBytesRead, 0
xor eax,1
ret
StreamInProc endp

StreamOutProc proc hFile:DWORD, pBuffer:DWORD, NumBytes:DWORD, pBytesWritten:DWORD
invoke WriteFile, hFile, pBuffer, NumBytes, pBytesWritten, 0
xor eax,1
ret
StreamOutProc endp
How are the return values from these functions always correct? ReadFile/WriteFile return zero if there is an error, or the bytes transfered if there is no error. The EditStreamCallback function returns zero if no error. The only way the return value would always be correct, is if ReadFile/WriteFile always return one on success! Can someone explain this?

The PSDK says the return value from ReadFile/WriteFile is non-zero on success, but why the assumption it will be 1? This seems to be used everywhere, but why?
Posted on 2002-07-14 05:42:35 by bitRAKE
ReadFile/WriteFile do return 1 on success and 0 on error, so xor eax, 1 would be a good way to flip the return value.
Posted on 2002-07-14 12:49:15 by comrade
comrade, it is just that the PSDK states non-zero return is success. I am aware of the assumption of 1 being the only non-zero state, but I lack the experience to know if this is a correct assumption. HLLs don't make this assumption. So, I must question why? :) Until I know better, I'm going to use:
cmp eax,1

sbb eax,eax
Posted on 2002-07-14 13:33:43 by bitRAKE
My Win32 API documentation clearly states ReadFile/WriteFile return TRUE on success and FALSE on error. You can choose to make such assumption, or not since PSDK tells you otherwise. But I guess it really doesn't matter to discuss or spend time pondering about such simple issues.
Posted on 2002-07-14 22:46:11 by comrade
From my own understanding, the values are not important it's the concept behind it.

FALSE == 0
TRUE == 1
NULL == 0
ZERO == 0

Sometimes, when we say FALSE it's different when saying NULL or ZERO or 0 or 0.0.

NULL usually means nothing/nada, can't complete the execution.

FALSE means "an error occured", same thing as NULL but the concept of TRUE and FALSE doesn't include NULL as an option.

ZERO means a value. Usually when the return means a value, there's always a corresponding meaning to that returned value.

Of course these are just my own concepts, you can always create your own ... probably MS has some plans in the future for the returned values of the EditStreamCallback API. ;)
Posted on 2002-07-14 23:12:55 by stryker
The fact of the matter is that my API reference states the value is non-zero -- it does not say the value will be TRUE or 1. I'm aware of the logic, but I do not understand the interface. I must base my code on the definition of the interface, or the practices of those who define the interface (indirect definition). Is that the common practise: to state non-zero return value when they mean the return value will be TRUE?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fileref_39id.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/CommCtls/richedit/richeditcontrols/richeditcontrolreference/richeditcallbackfunctions/editstreamcallback.asp
Posted on 2002-07-14 23:24:08 by bitRAKE
Probably, it's either the programmer/s who created the procedure screwed up his mind into thinking that this is this/that...Who knows it could be an error on MS part or it could be a future plan for something else.

If it has a future plan, programmer's would have to change how they will treat EditStreamCallback. It has an impact on logic if the API concepts are changed. Of course it's not a big deal but...

I remember 2 professors I had before, assumed 0 as FALSE/FAIL but the other one assumed TRUE/SUCCESS as 1 and the other assumed TRUE/SUCCESS as any non-zero number. Who knows, maybe the programmer who created the function had a different view of what's the value of SUCCESS or FAIL... ;) There's a lot of factors involved, I'm not going to explain each in detail because it's so absurd and weird. :grin:

Personally, TRUE/SUCCESS is any non-zero number.

blame the teachers... :grin:
Posted on 2002-07-14 23:36:43 by stryker
I do not understand why is there such a discussion about this. If bitRAKE is so afraid of ReadFile/WriteFile returning something other than 1 for success, he should just fix his code accordingly. Otherwise, do some tests and see what they really return. Its highly unlikely the API is going to change its return value in any other version, since it would cause compatibility problems. Oh and by the way, Visual Basic defines TRUE as NOT FALSE. FALSE being 0, TRUE becomes (NOT 0) which is -1. Silly, don't you think?
Posted on 2002-07-15 00:08:13 by comrade

TRUE/SUCCESS is any non-zero number.
That is the way C/C++ work, and probably the reason behind the definition. Personally, I'd like it to be binary (meaning a bit - not the DWORD BOOL that some nut came up with), or flag bit Z. :)

comrade, I have already done all that you
say - there is nothing to fear. :)
Posted on 2002-07-15 00:11:57 by bitRAKE
You want the sign bit? jns js

Intel/AMD should devote one bit of the EFLAGS register for TRUE or FALSE or better yet, extend it to 64 bit for more functionality.

jt / jf :grin:
Posted on 2002-07-15 00:25:29 by stryker