Liberty BASIC Community Forum
« ULONG Vs LONG »

Welcome Guest. Please Login or Register.
Jan 23rd, 2018, 7:23pm


Rules|Home|Help|Search|Recent Posts|Notification


« Previous Topic | Next Topic »
Pages: 1  Notify Send Topic Print
 sticky  Author  Topic: ULONG Vs LONG  (Read 963 times)
MKnarr
Senior Member
ImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 432
xx ULONG Vs LONG
« Thread started on: Jan 25th, 2007, 10:43pm »

I have seen several discussions regarding the use of ulong instead of long. I have a program with over a hundred dll calls and I don't know how many "as long" instead of "as ulong" and I do use Windows XP SP1 and the program has been working well for years. In fact its a program I sell and I have yet to get any complaints.

However, several people a lot smarter than I about LB are recommending changing the long to ulong. So I have been dutifully makeing all the changes and testing each one. I have however found this line, which occurs about 10 times in the program,

Code:
CallDLL #user32, "GetAsyncKeyState",_VK_RETURN as ulong, fKeyPress as long 


In which the last "long" can not be changed to "ulong" because the code no longer works.

So my question is, is there a rule about which items should be ulong instead of long. I saw Janets post about handles but I'm guessing that returned items can remain as long??
« Last Edit: Jan 25th, 2007, 10:50pm by MKnarr » User IP Logged

Janet
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM


Posts: 4111
xx Re: ULONG Vs LONG
« Reply #1 on: Jan 25th, 2007, 10:59pm »

ulong means unsigned, so it will drop any preceding negative sign. When using the GetAsyncKeyState code, the defined key, in your case _VK_RETURN is 0, unless and until it is pressed. When the key is depressed, the returned value is a negative number. The code looks for a negative number to determine if that key was pressed. By removing the negative sign (using ulong rather than long), fKeyPress is always positive. Thus, your code doesn't work.

The Always Use Ulong rule only applies to handles. There are still a lot of examples out there that pass handes as long and we're all trying to get the word out. Prior to XP, this wasn't a problem. Now it's becoming a problem.

The error messages usually say something about "word expected." At least you'll know where to start debugging if all of a sudden you start getting calls about your program fails sporadically.

Janet

User IP Logged

Windows 7 Professional, SP1, 64 bit Intel Core i5-4200U CPU @ 1.60 GHz 2.30 GHz 6.00 GB

"I am very busy finding out what people mean by what they say." -
Colin McMurchie
Full Member
ImageImageImage


member is offline

Avatar




PM


Posts: 226
xx Re: ULONG Vs LONG
« Reply #2 on: Jan 26th, 2007, 02:46am »

If we know that a variable is signed or unsigned there is not a problem. 'Ulong' for unsigned, 'Long' for signed. The problem is when we may not be sure which is which.

Can I make a suggestion? Pass all 'long' values to dlls as 'ulong', and convert those we think that logically may be negative before or after the dll call. In extreme cases, check one variable at a time. The following should do the trick.

Say a is a value that we think could be negative that needs to be passed to a dll.
Code:
if a < 0 then a = a + 4294967296

call #mydll, a as ulong, result as void
 

Say we expect a result that could be logically negative.
Code:
call #mydll, q$ as ptr, result as ulong

if result >  2147483647 then result = result - 4294967296
 


We still have to know when to apply this rule, but in the process of development we are less likely to generate fatal errors etc, so the process should be less painfull and more informative. When we know exactly how a call operates, we can then replace the correct 'Ulong' calls with 'Long' calls and drop the tests, for more efficient code.

Colin

User IP Logged

Alyce Watson
Administrator
ImageImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Female
Posts: 14918
xx Re: ULONG Vs LONG
« Reply #3 on: Jan 26th, 2007, 05:26am »

The origin of this problem is the Visual Basic Declares that we originally used to translate calls to LB syntax. VB doesn't distinguish between ulong and long. Everything is listed as being type "long".

My first comment is that if your code isn't broken, there's no need to fix it. If you've tested it extensively on the most recent version of Windows and your customers don't complain, there's no reason to change anything.

You absolutely should not make all types of "long" into type "ulong."

The only definitive way to know what type to use is to check the C documentation. Look at the MSDN, the Borland SDK helpfile, or C header files that come with many C compilers. Anything with a type of "handle" or "dword" or "uint" should be a ulong.

I spent months correcting the API calls in my ebook for the new "APIs for Liberty BASIC" so I understand how much work it is to do this. When LB first went to 32-bit, some of us old-timers had a long discussion about passing handles as type long or ulong. I was in the minority in thinking they should be type ulong. The others who were discussing it were of the opinion that handles should be type long, so I deferred to their greater knowledge and that worked for years. It was only when Win2000 and XP came out that we started having problems, and by then there were many, many demos and programs in circulation.

In fact, I probably still have demos on my site that haven't been converted. embarassed Clearly, I need to take the time to weed them out and correct them.
User IP Logged

Alyce
Liberty BASIC Workshop - a complete IDE for Liberty BASIC


Alyce's Restaurant
for Liberty BASIC code, tools and references
MKnarr
Senior Member
ImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 432
xx Re: ULONG Vs LONG
« Reply #4 on: Jan 26th, 2007, 09:15am »

Thanks all, I think I have a better understanding. However, I took a quick look this morning at my program and I have many, many handles that are passed to user32, gdi32 etc. that seem to work on my machine running XP Home with SP1. And as you can imagine Alyce, a lot of the code is based on examples from the ebook. For example, the main window toolbar code, code to replace or extend menus, status bar code and all have handles passed a long and all work.

I have replaced most of the long with ulong and with the exception of the code referenced in my first post, they all still seem to work. There are a few "long" references in URLMON, WININET, KERNEL32 and a few others that I haven't changed yet. When I look at these, they all appear to be positive numbers that are not handles so if I understand correctly, they would not have to be changed anyway.

Having said that, I'll check the MSDN documentation against what I'm using now that Alyce has given me the hint to look for.
User IP Logged

Stefan Pendl
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Computers are like babies, you must teach them what you like them to do ...


Homepage PM

Gender: Male
Posts: 5303
xx Re: ULONG Vs LONG
« Reply #5 on: Jan 26th, 2007, 10:16am »

Support for WinXP SP1 is stopped now by M$.
Your problems may start with installing SP2.

Here are the ranges of Long and ULong:
TypeLonguLong
Upper Limit

2147483647

4294967295
Lower Limit-2147483647

0


So ULong will always be a positive number and will only accept positive numbers.
User IP Logged

Stefan

Make sure to read and follow the Forum Guidelines

Liberty BASIC Pro 4.04, Windows 10 Professional x64, Intel Core i7-4710MQ 2.5GHz, 16GB RAM
Dan Teel
Guru
ImageImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 1130
xx Re: ULONG Vs LONG
« Reply #6 on: Jan 26th, 2007, 2:39pm »

If a ulong if FFFFFFFF and a long is -1, are they different? Do they look the same in memory? Im just curious.
User IP Logged

ZPtr.net
Stefan Pendl
Global Moderator
ImageImageImageImageImage


member is offline

Avatar

Computers are like babies, you must teach them what you like them to do ...


Homepage PM

Gender: Male
Posts: 5303
xx Re: ULONG Vs LONG
« Reply #7 on: Jan 26th, 2007, 2:46pm »

They are the same in memory, but the software will handle the sign bit differently according to the type it looks for.
User IP Logged

Stefan

Make sure to read and follow the Forum Guidelines

Liberty BASIC Pro 4.04, Windows 10 Professional x64, Intel Core i7-4710MQ 2.5GHz, 16GB RAM
Dan Teel
Guru
ImageImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 1130
xx Re: ULONG Vs LONG
« Reply #8 on: Jan 26th, 2007, 2:52pm »

on Jan 26th, 2007, 2:46pm, Stefan Pendl wrote:
They are the same in memory, but the software will handle the sign bit differently according to the type it looks for.
If there the same in memory, how would the software thats receiving the data know what your passing it as, if there the same? It's not like you pass what kind of data your sending the function.
« Last Edit: Jan 26th, 2007, 2:55pm by Dan Teel » User IP Logged

ZPtr.net
Chris Iverson
Administrator
ImageImageImageImageImage


member is offline

Avatar

20% Cooler


Homepage PM

Gender: Male
Posts: 2294
xx Re: ULONG Vs LONG
« Reply #9 on: Jan 26th, 2007, 4:10pm »

actually, you do pass the datatype to the function. And I think the problem is that the DLL will scan the datatypes, and if it isn't the same type, even if it is the same data length, and could work in theory, it will give you an error.
User IP Logged

"Do you believe in destiny?" - Pyrrha Nikos, RWBY
"With what wish will your Soul Gem shine?" - Kyubey, Puella Magi Madoka Magica
fqvarfort
Senior Member
ImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 253
xx Re: ULONG Vs LONG
« Reply #10 on: Jan 26th, 2007, 5:15pm »

on Jan 26th, 2007, 4:10pm, Chris Iverson wrote:
actually, you do pass the datatype to the function. And I think the problem is that the DLL will scan the datatypes, and if it isn't the same type, even if it is the same data length, and could work in theory, it will give you an error.


The DLL doesn't scan for the data types as the DLL has no way of determining if a parameter is of type LONG or ULONG. In memory they both occupy 4 bytes, the only difference is how those 4 bytes are to be interpreted. There is no way to specify how a value are to be interpreted, the program always assumes the value is stored the correct way. It is up to the caller (the program that calls the DLL) to store the value in the correct way.

What you are looking at is a sideeffect of the proccess that is done just just before the DLL is called...

Internally Smalltalk doesn't use LONG or ULONGs, so whenever you call a DLL, Smalltalk needs to convert the numbers into LONG/ULONG or whatever format is used by the DLL. It is during this conversion that some information may be lost. Take a look at the table provided by Stefan Pendl...

TypeLongULong
Upper Limit21474836474294967295
Lower Limit-21474836470


Now let's say you want to send the value 4294967295 to the DLL.

If you send it to the DLL as a LONG you will see that that specific value does not fit into the specified range of the LONG data type, so Smalltalk will have to somehow convert it into a value that fit into the LONG data type, haven't tried this out myself so I am not sure what happens, but it might just remove any values that are out-of-bounds and just use the upper limit of LONG instead, that is it converts the value to 2147483647. The program keeps running, but the DLL retrieves an incorrect value.

Now if you send the same value as ULONG the value fits into the specified range of that data type and Smalltalk can successfully convert the value to an ULONG without having to remove any (excess) information. The DLL retrieves the correct value.
User IP Logged

fmtBasic - a new code editor for all your Liberty Basic needs
Dan Teel
Guru
ImageImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 1130
xx Re: ULONG Vs LONG
« Reply #11 on: Jan 26th, 2007, 9:28pm »

on Jan 26th, 2007, 4:10pm, Chris Iverson wrote:
actually, you do pass the datatype to the function. And I think the problem is that the DLL will scan the datatypes, and if it isn't the same type, even if it is the same data length, and could work in theory, it will give you an error.
Lol
User IP Logged

ZPtr.net
Dan Teel
Guru
ImageImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 1130
xx Re: ULONG Vs LONG
« Reply #12 on: Jan 27th, 2007, 9:01pm »

Heres a little demo demonstrating how they are the same in memory...
Code:
struct values,value as long
struct num1,val as ulong
struct num2,val as long

calldll #kernel32,"GetCurrentProcess",hProcess as long

values.value.struct=-100
gosub [readvals]

print "When given a -100..."
print "ULONG value ";num1.val.struct
print "LONG  value ";num2.val.struct

values.value.struct=4294967196
gosub [readvals]
print
print
print "When given a 4294967196..."
print "ULONG value ";num1.val.struct
print "LONG  value ";num2.val.struct

wait

[readvals]
calldll #kernel32,"ReadProcessMemory",_
    hProcess as long,_
    values as struct,_
    num1 as struct,_
    4 as long,_
    t$ as ptr,_
    ret as long

calldll #kernel32,"ReadProcessMemory",_
    hProcess as long,_
    values as struct,_
    num2 as struct,_
    4 as long,_
    t$ as ptr,_
    ret as long
return
 

I dont really see how if you get the handle FFFFFF5 from a dll, and you dont modify that value at all in the program, and you pass that value later to close that handle it will become unstable and blow the computer up.
« Last Edit: Jan 27th, 2007, 9:13pm by Dan Teel » User IP Logged

ZPtr.net
MKnarr
Senior Member
ImageImageImageImage


member is offline

Avatar




Homepage PM

Gender: Male
Posts: 432
xx Re: ULONG Vs LONG
« Reply #13 on: Jan 28th, 2007, 10:01am »

First I would like to thank all who responded to my question. After many hours and checking over a hundred dll calls, I think I now have a better understanding of "long" vs "ulong". As I mentioned, I am still using SP1 with Win Xp and many of my handles were defined as "long" and everything worked as expected. After much reading and a lot of debugging, I believe I have corrected all calls with the correct format. I did make one mistake in my Tool Bar calls and had changed a ulong to a long. When I attempted to DeleteObject the bitmap handle with a ulong, the program would not close. So the handle was being created with long and sometimes came out minus but I was trying to kill it with the unsigned version.

Unfortunately, I have not been sucessful at installing SP2 to my system in two attempts so I can't test the program with SP2 yet. It looks like next week will be filled with fun while I reinstall windows and SP2.
User IP Logged

Pages: 1  Notify Send Topic Print
« Previous Topic | Next Topic »

Rules|Home|Help|Search|Recent Posts|Notification

Donate $6.99 for 50,000 Ad-Free Pageviews!

| |

This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls