Baliji - Here are suggestions as to how to troubleshoot 64-bit migration of WinAPI calls. Apologies for the length, but there are several items that need to be clearly explained in order to be helpful.
1. I'll repeat myself from earlier posts - Keep your app 32-bit. Your 32-bit app works and you can avoid what could be extremely frustrating hours/days trying to get these WinAPI calls working in 64-bit. There are clues & hints & examples on the web, but you may not easily find all of pieces to the puzzle. The Microsoft documentation of WinAPI calls largely ignores 64-bit ramifications. What follows here may not be all the pieces of the puzzle you will need, either.
2. Create a small, simple, single-window PB test application and work with it to figure out the details. Use the ProcessBitness member of the Environment object to determine bitness when the test app is executing. Copy in the 32-bit code from your "real" app and verify this works when running the test app from the PB IDE, which is 32-bit. Once you get the WinAPI calls working in your test app in 32-bit, leave this code alone. Use a separate button, etc. for 64-bit testing and verify the process bitness. You'll have to Build/Deploy your test app exe & pbd in 64-bit in order to test it, probably many, many times. Also, if you're not already using the WinAPI GetLastError function, you'll probably want to, at least in the test app, if WinAPI documentation indicates error conditions are accessible via GetLastError.
3. Handles. Face it, the WinAPI is handle-happy. Just about everything is identified with a handle. hWnd is a handle to a window, hDC is a handle to a device context, hBitmap, hFont, hProcess, etc., etc., etc. In a 32-bit process, a handle is a 32-bit, unsigned integer value (an UnsignedLong, or ULong in PB). In a 64-bit process, handles are 64-bits. PB has a cool, relatively new datatype: LongPtr (Long Pointer). When the PB app is executing in 32-bit, a LongPtr variable occupies 4 bytes. When the PB app is executing in 64-bit, the same LongPtr variable occupies 8 bytes. Therefore, change the datatype of handle argument parameters in Local External Function declarations from ULong (or Long) to LongPtr, and use variables of type LongPtr when you need the value of a handle in PowerScript or in a PB structure that will be passed to Windows. The 64-bit integer data type LongLong may also be used.
4. Memory addresses occupy 8 bytes in 64-bit processes. Since PB doesn't support an address datatype, there's pretty much nothing to see here. However, when the REF keyword precedes a parameter in a Local External Function declaration, take note and understand that under the covers, PB is passing the address of the argument value to Windows...so thankfully, the PB compiler manages this 4-byte/8-byte address concern for us. Keep 8-byte boundary concerns in mind when values are passed by reference.
5. Structures. Structure members that will contain a Windows handle also need to be declared of type LongPtr. In addition, a LongPtr value in memory MUST be aligned on an 8-byte boundary (the memory address of the variable must be evenly divisible by 8). Depending on the structure, some "padding" members may be needed to ensure this condition is met. You can safely assume that the memory allocated to an instance of a structure begins on an 8-byte boundary. These differences imply that the 64-bit version of a structure passed into or out of Window may be different than the 32-bit version.
6. Structures, part 2: Some Windows structures use a member (usually the first member of the structure) to contain the size, in bytes, of the structure. Since structures for 64-bit processes may differ in composition from the 32-bit versions, the length of the structure may differ depending on the bitness. An additional, but perhaps lesser known condition is that in some cases, Windows requires the structure length in a 64-bit process to be evenly divisible by 8. This may require the addition of one or more "reserved" structure-padding members to the end of the structure.
Note: An excellent resource is Roland Smith's TopWizProgramming web site, where he provides dozens of free PB code examples, most of which call WinAPI functions. I know Roland has tweaked many of his examples so they will work as a 64-bit app. Unfortunately, in your particular case, it appears he does not have an example that calls the WinAPI functions that your app is using. You may be able to find sample code in other languages on the web that calls the WinAPI functions you are interested in, such as Visual Basic.NET, that may provide clues you can use. One night last week I found a code sample in a language I did not recognize, but I could understand the syntax well enough that it gave me the hint I needed to solve a 64-bit WinAPI migration I had struggled with for many evenings.
These are the tips, suggestions, and recommendations I've borrowed or discovered over many evenings of experimentation with calling WinAPI functions from a 64-bit PB application. I hope you and maybe other PB developers find this information helpful.
John
