Win32Api.inc error

[Dominic Mitchell]

The return type in this defintion is wrong

DECLARE FUNCTION GetFileAttributes LIB "KERNEL32.DLL" ALIAS "GetFileAttributesA" (lpFileName AS ASCIIZ) AS LONG

It should be

DECLARE FUNCTION GetFileAttributes LIB "KERNEL32.DLL" ALIAS "GetFileAttributesA" (lpFileName AS ASCIIZ) AS DWORD

The current defintion causes code like the following to fail

IF GetFileAttributes(szFile) <> %INVALID_FILE_ATTRIBUTES THEN

[Michael Mattias]

Is the return type of the function wrong?

Or is the explicit casting to DWORD of the INVALID_FILE_ATTRIBUTES constant wrong?

Actually, neither is "wrong;" they are however "incompatible."

FWIW I gave up on doing 'raw' equality tests with anything in the supplied Windows headers files precisely because of the willy-nilly "let's make all LONGs DWORDs 'upgrade' " in those files a couple of years ago. I 'd use...

' compare long with DWORD
MACRO EQ32(a,b) = (BITS???(a)=BITS???(b))

   IF Eq32(GetFileAttributes(szfile), %INVALID_FILE_ATTRIBUTES) THEN ...

[Kev Peel]

> Is the return type of the function wrong?

According to the Win32 docs, yes it is.

[Michael Mattias]

>According to the Win32 docs,

You found Win32API docs with the examples in PowerBASIC syntax?

Where?

(See also: This whine's time has come)

MCM

[Kev Peel]

Not sure what the argument is here?

The original SDK code shows a DWORD (unsigned double-word) should be used. Since the constants were recently updated to DWORDs, so should the PB translations of function prototypes. Note we are talking about function return values, and not parameters, where it doesn't matter if a DWORD or LONG is used.

Your code is simply a workaround to a fundamental issue with the PB translations. I, and probably others, simply would like to see it fixed one day, though I expect it would be a huge undertaking with a whopping 3 MB of definition files to sift through.

[Aleksandr Dobrev]

BTW, this APIs should be corrected too

wrong:

DECLARE FUNCTION GetCompressedFileSize LIB "KERNEL32.DLL" ALIAS "GetCompressedFileSizeA" (lpFileName AS ASCIIZ, lpFileSizeHigh AS LONG) AS LONG

DECLARE FUNCTION GetFileSize LIB "KERNEL32.DLL" ALIAS "GetFileSize" (BYVAL hFile AS DWORD, lpFileSizeHigh AS LONG) AS LONG


DECLARE FUNCTION GetMenuItemID LIB "USER32.DLL" ALIAS "GetMenuItemID" (BYVAL hMenu AS DWORD, BYVAL nPos AS LONG) AS LONG


DECLARE FUNCTION ResumeThread LIB "KERNEL32.DLL" ALIAS "ResumeThread" (BYVAL hThread AS DWORD) AS LONG

DECLARE FUNCTION SetFilePointer LIB "KERNEL32.DLL" ALIAS "SetFilePointer" (BYVAL hFile AS DWORD, BYVAL lDistanceToMove AS LONG, lpDistanceToMoveHigh AS LONG, BYVAL dwMoveMethod AS DWORD) AS LONG

DECLARE FUNCTION SuspendThread LIB "KERNEL32.DLL" ALIAS "SuspendThread" (BYVAL hThread AS DWORD) AS LONG

DECLARE FUNCTION TlsAlloc LIB "KERNEL32.DLL" ALIAS "TlsAlloc" () AS LONG

should be:

DECLARE FUNCTION GetCompressedFileSize LIB "KERNEL32.DLL" ALIAS "GetCompressedFileSizeA" (lpFileName AS ASCIIZ, lpFileSizeHigh AS LONG) AS DWORD


DECLARE FUNCTION GetFileSize LIB "KERNEL32.DLL" ALIAS "GetFileSize" (BYVAL hFile AS DWORD, lpFileSizeHigh AS LONG) AS DWORD

DECLARE FUNCTION GetMenuItemID LIB "USER32.DLL" ALIAS "GetMenuItemID" (BYVAL hMenu AS DWORD, BYVAL nPos AS LONG) AS DWORD


DECLARE FUNCTION ResumeThread LIB "KERNEL32.DLL" ALIAS "ResumeThread" (BYVAL hThread AS DWORD) AS DWORD

DECLARE FUNCTION SetFilePointer LIB "KERNEL32.DLL" ALIAS "SetFilePointer" (BYVAL hFile AS DWORD, BYVAL lDistanceToMove AS LONG, lpDistanceToMoveHigh AS LONG, BYVAL dwMoveMethod AS DWORD) AS DWORD

DECLARE FUNCTION SuspendThread LIB "KERNEL32.DLL" ALIAS "SuspendThread" (BYVAL hThread AS DWORD) AS DWORD

DECLARE FUNCTION TlsAlloc LIB "KERNEL32.DLL" ALIAS "TlsAlloc" () AS DWORD

[Theo Gottwald]

Whats the normal and best way with these things?
Sent it to the PB-Support via E-Mail or post it here?

[Richard Angell]

Both

Sending it to PB makes sure that it gets attention there.

Posting it here as well gets more comment and work-around options that can help to deal with the situation one believes is incorrect. Of course to ilusrate why one believes it is incorrect, the official MS SDK documentation online could be linked both here and in the e-mail.

[Michael Mattias]

The original SDK code shows a DWORD (unsigned double-word) should be used...

The original SDK code shows a DWORD (unsigned double-word) should be used when coding in 'C'.

And while I have exactly zero examples, I would swear on a stack of Bibles there are portions of the SDK documentation which assume you are using a Microsoft-brand 'C' compiler.

Far better IMO to use any 'code' provided in the MS-Documentation as a secondary source of info, instead relying on the text descriptions of parameters and return values.

[Roger Garstang]

I'm still confused why there is a claim that a <> compare will fail when comparing a LONG and a DWORD. < or > by themselves would fail since DWORD wouldn't be negative or a HIGH DWORD would be a negative value to a LONG, but <> should work fine...or am I missing something here?

[Kev Peel]

The original SDK code shows a DWORD (unsigned double-word) should be used when coding in 'C'.

And while I have exactly zero examples, I would swear on a stack of Bibles there are portions of the SDK documentation which assume you are using a Microsoft-brand 'C' compiler.

Far better IMO to use any 'code' provided in the MS-Documentation as a secondary source of info, instead relying on the text descriptions of parameters and return values.

No, it means that an unsigned double word should be used if the compiler supports it. I am simply perplexed at why this is so hard for you to understand.

As for LONG vs DWORD, one example is that INVALID_FILE_ATTRIBUTES is "FFFFFFFF". Try and squat that into a LONG and equality tests go out the window.

[Michael Mattias]

My point is the same one i've been trying to make for years: There is no such thing as a "word for word" or "verb for verb" or "function for function" interchange between different computer languages, and that the best way to effect a port is to engage one's brain instead of trying to find an easy glide path in some set of table data.

The LONG/DWORD thing is complicated by the fact that in PB/DLL versions thru 6x, LONG and DWORD comparisons using IF or SELECT CASE were 32-bit comparisons; in 7x those comparisons changed to signed comparisions. (ie., what used to work did so no more). (FWIW, SELECT CASE AS LONG still does 32-bit comparisons).

e.g, in your example above: Windows is documented to an integer of value 0xFFFFFFFF; you may either use a PB DWORD and compare against &hFFFFFFFF???, or a PB LONG and compare against -1&. Either is correct; neither is wrong.

MCM