windows.inc for POASM

[hutch--]

Pelle's assembler is stricter on equates and variations of duplicates than MASM so I have modified a version of windows.inc for beta testing POASM.

[attachment deleted by admin]

[Jimg]

Since you've removed the def for wsprintf, do we need to remove the  IFNDEF in user32?

IFNDEF _wininc_
  wsprintfA PROTO C :DWORD,:VARARG
  wsprintf equ <wsprintfA>
ENDIF

or did you post a new user32 for poasm that I missed?

Also, is there any reason this new windows.inc can't be used for general purposes?

[hutch--]

Jim,

All I did with it was chomp out anything that crashed so that there was a version that could be used for beta testing of Pelles new macro assembler. I can probably get a version that will work fine on both but I don't have the time at the moment.

[Ratch]

hutch-- ,

     In regard to windows.inc.  The value of FALSE is EQU'ed to 0.  This is fully correct, because ALL bits in the word must be zero to comply with the definition of FALSE.  For TRUE however, any single bit or multiple bits set in a word are a definition for TRUE.  So we have ONE value for FALSE, and over 4 billion values of TRUE.  Out of the over 4 billion values, you have chosen the value of 1 to represent TRUE.  While this is certainly a particular correct value, it favors the least significant bit and ignores the other 31 bits within the word.  Therefore, I suggest that you instead use TRUE EQU NOT FALSE.  This will set ALL the bits in the word, thereby giving EVERY bit a unique and equal TRUE representation.  Don't you think that is more fair and logical?  Ratch

[zooba]

The C definition of true is 1.

VB uses the more appropriate -1 (ie. all bits set) but most languages take the C convention (or convert an integer to a boolean 1 or 0 before comparing)

[MichaelW]

I don't recall for VB, but the early BASICs had only a bit-wise NOT, so if TRUE were 1 instead of -1, logic like this would not work as intended:

Code Select Expand


disabled = TRUE
...
IF NOT disabled THEN
...

But I can't see how any of this could matter when you have a logical NOT available.

[zooba]

VB (and possibly earlier BASICs) don't have any logical operators at all, so operators will only work for boolean values if all the bits of true are set (ie x AND TRUE = x, x OR TRUE = TRUE, etc.). A non-zero result is interpreted as true (for the purposes of an expression), and this will be converted to TRUE (-1) at the next CBool() statement or (in)equality operation.

In theory (assuming a 'precise' implementation on both parts), this reduces some overhead from C's style. In reality it makes not much difference.

Cheers,

Zooba :U

[hutch--]

The virtue of boolian values fits into the "Law of excluded middle", something IS or it AIN'T but it can't be both. If you define FALSE as zero, then anything that is not zero is TRUE.

[QvasiModo]

I think there's a #define TRUE 1 in the SDK header files. I think we should stick to that one, for a matter of consistency.

[zooba]

I think there's a #define TRUE 1 in the SDK header files. I think we should stick to that one, for a matter of consistency.

My original statement.  :bg

Of course, that's why we test with 'or eax, eax \ jnz/jz' instead of 'cmp eax, 1' :U

[Synfire]

Well, truthfully C itself (as a language) doesn't support TRUE or FALSE, as it's a boolean operation which was introduced in C++. Not sure how the platform sdk defines it, but according to the ansi standard its supposed to be like this:

Code Select Expand


#define FALSE 0
#define TRUE ( ! ( FALSE ) )


As something is true so long as it has value (ie isn't equal to 0) of course I too have been known to skimp on this in C by creating my own boolean type using:

Code Select Expand

typedef enum { FALSE, TRUE } bool;

Which would be more or less the same as saying TRUE=1, but to actually be correct you should do as the #define statements above (since 2, 3, 4, etc are also TRUE)

[MichaelW]

FWIW, for the February 2003 version of the PSDK there are 5 header files that define TRUE and FALSE, and they all define TRUE as 1 and FALSE as 0.

[asmfan]

AFAIK 0 is always converted/treated as false in bool C++ type, other numbers (not null) is converted/treated as true.

[hutch--]

I am not sure what the problem is in terms of a system definition, the poasm version of windows.inc has TRUE set to 1 as per the vendors spec. It is simply the difference of needing s preset flag rather than how you write a procedure using any other value than 0 for a conditional return value. Unless someone actually tests for 1, using 0 for a boolean value is reliable and testing zero will give you the correct results.