 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
David Andersen
Joined: 15 Jul 2005
Posts: 140
Location: Denmark
|
 Posted: Tue Feb 10, 2009 1:52 pm Post subject: [Solved] Gotcha with DllCall |
 |
|
Hi,
I have just undertaken some serious exercise resulting from the anger caused by this strange behavior. Thought I should save you some time by describing it here. I am not sure whether it should be defined as a bug, or maybe a bug in the documentation of DllCall (arrest me if I am wrong).
I have a DLL that I am calling using the following code: | Code: | egg := "ABCDEFGHIJ"
offset := DllCall("adll.dll\FindStringW","UInt",0,"Str", egg, "UInt",0,"UInt",0,"Uint",0,"UInt",0) |
This works fine and I learned that the DLL catches the Str argument as LPCSTR.
Then to save some code lines I made the slight change to the following: | Code: |
offset := DllCall("adll.dll\FindStringW","UInt",0,"Str", "ABCDEFGHIJ", "UInt",0,"UInt",0,"Uint",0,"UInt",0)
|
This slight change means that the Dll receives a different string from the code above. As I am unable to debug the Dll I cannot give you more details. I am also not allowed to provide the DLL. Sorry for not giving you much to work on.
[ Moderator!: Moved from Bug Reports ]
Last edited by David Andersen on Tue Feb 10, 2009 3:19 pm; edited 1 time in total |
|
| Back to top |
|
 |
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Tue Feb 10, 2009 2:09 pm Post subject: |
|
|
| I'm curious how you reached your conclusion. It's not a bug of AHK. You better move it to Ask for Help section. |
|
| Back to top |
|
|
David Andersen
Joined: 15 Jul 2005
Posts: 140
Location: Denmark
|
| Posted: Tue Feb 10, 2009 2:22 pm Post subject: |
|
|
Hi Sean,
The dll undertakes a search and when I run the search using the first code bit, it can find the expected string, but if I use the second one it cannot find the string.
I will try to provide more details, but it could take lots of time to retrieve them. |
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Tue Feb 10, 2009 2:35 pm Post subject: |
|
|
| Looks like you're searching NULL character in the string with the above code? Anyway, usually the mysterious suffix W in APIs, like FindStringW means that it's a UNICODE version, i.e., the string should be in UNICODE, but you just passed ANSI string, so the result is unpredictable. First examine if there exists an ANSI version, usually named like FindStringA. If not, you have to convert first the ANSI string to UNICODE string before using in FindStringW. |
|
| Back to top |
|
|
David Andersen
Joined: 15 Jul 2005
Posts: 140
Location: Denmark
|
| Posted: Tue Feb 10, 2009 2:39 pm Post subject: |
|
|
Hi Sean,
That is a good tip and you are right about the unicode, except for that the two are mixed up FindStringW is in my case the ANSI code, while FindStringA is the Unicode.
The results are not unpredictable as far as I can see (20 trials of each) and the results are consistanly as described earlier.
Isn't it possible that when storing a string in a variable, that the encoding is changed? This is as far as I can see the only explanation for this. |
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Tue Feb 10, 2009 3:11 pm Post subject: |
|
|
| David Andersen wrote: | | The results are not unpredictable as far as I can see (20 trials of each) and the results are consistanly as described earlier. |
How could I say, I suppose you were just lucky.
There may be a delicate difference between passing string via variable and passing it inline.
If you declared variable in AHK, the variable/string is allocated in Heap, which is unlikely to be polluted much at early stage. On the contrary, if you pass the string inline, I guess that AHK temporarily allocate it in Stack, which is likely already polluted even at initial stage. By pollution, I mean garbage bytes different from null/zero.
So, for example, if you're searching UNICODE NULL, which is double-byte, it's likely to give constant position, just at the single-byte ANSI NULL as the next byte is likely to be null/zero, when passing via variable. But, it is less likely with Stack, i.e., passing inline, so the results can be different each after each trial. |
|
| Back to top |
|
|
David Andersen
Joined: 15 Jul 2005
Posts: 140
Location: Denmark
|
| Posted: Tue Feb 10, 2009 3:19 pm Post subject: |
|
|
| That sound like a reasonable explanation. It sounds like you have undertaken so extensive testing that you are sure about the correctness of DllCall. |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
