>>First off, if VFP differentiates between an INTEGER and a LONG (presumably 2 and 4 bytes, respectively?), the hInternet parameter should be a LONG. Under 9x, this change may have no practical result, but in NT failing to use the full 32bits of a handle will nearly always cause problems.
>
>VFP does differentiate. And I was having problems with this. The error being returned was "The handle passed is the wrong type", or something to that effect. So I ws confident that changing the declaration to use a LONG instead of an integer would change things, and it didn't. I have a bunch of other WinInet wrappers written, and I went back and doublecheked them, and they too are using INTEGER for hInternet, with no problems.
>

INTEGER and LONG in a DLL declaration are identical to VFP, both representing a signed 32 bit integer - SHORT is a signed 16 bit integer, but the docs imply that SHORT can be used for a return type not a parameter type. If you pass an INTEGER by reference where a SHORT is really required, make certain to use BITAND(nIntegerReturnValue,0xFFFF) to mask off the low order bits to make sure there's no garbage left strewn about. A handle is always a 32 bit integer, so either declaration is correct, regardless. A 32 bit value with the most significant bit set will be represented to VFP as a negative number, but you can use a hex value like 0xFFFFFFFF.