Faking Unsigned Data Types

If I want to fake an unsigned int ( ie: unsigned 32 bit ) can I essentially just ignore the fact that the number is reporting back incorrectly and use it anyway?

For example, Windows98 Process ID's are unsigned 32bit integers, so I need to be able to pass the correct ID's. It doesn't really matter if I can't print them, I can always use a long for printing.

For example

PID:Int=4294789903
Print PID

It prints a negative number. But if I pass that to a function which expects an unsigned 32bit datatype, will it still read it as 4294789903?

I'd love to test, but don't have Win98 and I'd like to be fairly confident in my solution before I ask for more testers.

I suppose it would work, but can't you just submit the Process ID as a long and convert it back outside of BMax?

this work... if a function get 32-bits - it interprete this as unsigned or signed value

When you want to store your value into a variable, store it into a Long.

Local MyValue:Long=$FFEEDDCC or whatever

It then won't think that the 32nd bit indicates a negative number. So all numbers, up to 2^32, would be unsigned/positive.

Then use an Int Ptr:

Local MyIntPtr:Int Ptr=VarPtr(MyValue)+1 '+1 actually adds 4 bytes because it's an Int Ptr

Then to pass the value to Windows, read from the Int Ptr:

MyIntPtr[0]

It wont matter what value is in it. It will work as an unsigned integer. And you can store a value back from windows at that same address.

If you dont want to use a Long, you can just use an Int, but you'll need to `convert` your values into signed data format before you write to the variable, and convert back to unsigned when you read from it. - ie take into account that it will say -number if the uppermost bit is set. So maybe -$EEDDCCAA would actually be +FEDDCCAA or something.

I won't be writing to the variable at all. The API writes to it and then asks for it back later. So I think I'll just stick with an Int and not worry about not being able to print it.

AngelDaniel's trick using the Long and the Int Ptr is very clever though, and I'll certainly keep that in mind if I need this again.

If Windows reads and writes to it only and you don't need to interpret it, then I agree yes you don't have to worry about how it's being stored. Windows probably interprets the space as an unsigned int.