64bit AutoIt

[LarryDalooza]

Is there a nutshell description of what was required to conform AutoIt to compile 64bit?

Lar.

[Valik]

Make sure pointer's aren't stored in int32. Use the Microsoft defined *_PTR type so certain things will be the right size when the size is different on 32-bit/64-bit. Use a proper size_t or equivalent type instead of int/unsigned int when you need a size counter or array index.

Making sure code compiles under /W4 (Highest level of Visual C++ warnings) goes a long way. The rest is just checking casts to make sure they aren't changing sizes in a way that will bite you. And there are only a few API's that use the *_PTR types and they are fairly obvious.

We also had to rewrite DllCall() which Jon truly enjoyed.

Edited July 16, 2008 by Valik
Typo

[LarryDalooza]

Thank you.

[Jon]

Here's a repost of I post I put in the dev forum at the time:

I've been mucking around learning about 64bit stuff and how it works with the Win32 API. I understand why Valik was bitching about the things he was now muttley

So, moving forward this is a list of coding practices that we should follow when adding new code. Or when editing existing code that needs to be "fixed". Reply to the thread with missing points and I'll add them to this post.

First read and understand these articles:

http://msdn2.microsoft.com/en-us/library/aa384267.aspx

http://msdn.microsoft.com/msdnmag/issues/0...64/default.aspx

http://msdn2.microsoft.com/en-us/library/aa383731.aspx

http://developer.amd.com/article_print.jsp?id=13

http://www.codeproject.com/system/64BitOSA...rtingIssues.asp

C-Style Casts

Banned. No more. Change all you see.

Use static_cast and reinterpret_cast. Easiest way: try static_cast first - if the compiler bitches try reinterpret_cast.

In some cases it's like "what's the point - they do the same thing". But the C++ ones do more compiler type checking to stop you doing something _really_ stupid and also you can use "find" for words like "static_cast" to quickly check a source file for 64bit related issues. Impossible with C-Style casts.

64-bit Win32 Functions

Some Win32 API functions have been upgraded with ...Ptr() versions that use the new LONG_PTR / nnnn_PTR types. These change depending on if they are compiled on 32 or 64 bit machines to make writing compatible code easier. Some functions (like SendMessageTimeOut) have also started using these new _PTR types via the backdoor - so the next time you write a new API call just check what values it's expecting and if the types have changed from DWORD to DWORD_PTR or something then ensure you change your code (don't just cast!).

The new Ptr() related stuff seems to be implemented with Macros so that they work on older OSes too. So backwards compatibility shouldn't be a problem.

Some other functions to watch out for (or need changing to Ptr() versions):

- GetWindowLong

- SetWindowLong

There are new ..Ptr() versions of these that should be used whenever we get/set pointer related info (like the WindowProc).

Casting pointers to ints

There are a few places where we've cast between ints and HWND or strings for outputting. HWND under x64 is 8bytes NOT 4 bytes as it used to be. This code all breaks under x64. We need to be carefull with this stuff and start using LONG_PTR instead. I _think_ that most of our pointer crimes will be HWND related - it's not something we have had to do a lot.

Example from one of the articles:

In some cases, you'll need to make a few code changes. For example, 32-bit code uses a 32-bit pointer; 64-bit code uses a 64-bit pointer. If your 32-bit apps stores pointers in a LONG integer, it'll work fine – but it'll break when you recompile for 64-bit, because a LONG is 32 bits even under Win64. The solution there is to always store pointers in one of Windows' new polymorphic pointer types. If you define the pointer as a LONG_PTR instead, it'll compile as a 32-bit integer under Win32, and a 64-bit integer under Win64.

For example, the following is bad C/C++ code, because defining a pointer as a long integer will always be a 32-bit integer, no matter what you do.

char *p;
long Lval
Lval = p;    //bad! Truncated in 64-bit mode

Instead, you should use the polymorphic type, which will be set to either 32 bit or 64 bit appropriately at compile time:

char *p;
LONG_PTR Lval;   //either 32 bits or 64 bits
Lval = p;    //works fine

Tracking down and fixing pointers will probably be the single nastiest bit of work in the porting process.

[James]

Interesting post Jon! I read an article recently about 32 vs 64bit and the results were that more people prefer 32bit because of things like this muttley

[Jon]

Interesting post Jon! I read an article recently about 32 vs 64bit and the results were that more people prefer 32bit because of things like this muttley

I don't really understand that. If you have a 64bit machine and all your software works on it (either in native x64 mode or in x86 mode) then 64bit rules all the way. The native 64bit version of Autoit is waaaay faster and that's with zero x64 specific tweaks.

From a programming point of view, once you understand the way to do things it's a non issue (apart from low level stuff like asm/DllCall/DllCallback which was hell).

[Valik]

Interesting post Jon! I read an article recently about 32 vs 64bit and the results were that more people prefer 32bit because of things like this muttley

Doing things like 64-bit and UNICODE support really aren't a big deal and I don't see why people avoid it. Sure, Jon had a hell of a time porting AutoIt to 64-bit/UNICODE, but that's because he was retrofitting something. Writing new code, though? Pretty much the same thing as not supporting it.

[James]

It's what the article said. I will try and find it again.

[Jon]

It's what the article said. I will try and find it again.

Pre-Vista x64 support was annoying mainly because lack of drivers, but with Vista they changed the requirements for the "logo" so that a vendor _must_ provide a x64 driver for it to be signed and put on Windows update (they actually don't have to provide an x86 driver!). I run my gaming rig on x64 now quite happily.

[James]

Pre-Vista x64 support was annoying mainly because lack of drivers, but with Vista they changed the requirements for the "logo" so that a vendor _must_ provide a x64 driver for it to be signed and put on Windows update (they actually don't have to provide an x86 driver!). I run my gaming rig on x64 now quite happily.

Ahh, well maybe I got confused if they were talking about the pre or current versions. I will still try and find it again though.