Convert 32-bit code to 64-bit

[zombiemaster]

I may be barking up the wrong tree, or at least making this sound easier than it probably is.

I have a LARGE code that someone wrote almost 20 years ago that is going to stop working once our systems upgrade to 64-bit. How hard is it to convert from 32-bit VBA to 64-bit? When I was playing around, I got this error message:

COMPILE ERROR: THE CODE IN THIS PROJECT MUST BE UPDATED FOR USE ON 64-BIT SYSTEMS. PLEASE REVIEW AND UPDATE DECLARE STATEMENTS AND THEN MARK THEM WITH THE PTRSAFE ATTRIBUTE.

I highly doubt that it's as simple as changing wherever I find "32" to "64"...right?

I'm going to try to include a screenshot below, if it helps. This is not my code and I am not familiar with most of what it's talking about. If this gets too complicated, I'll have to reach out to our IT department for help, but since this is a "home-grown" application in our department, they don't usually help with those.

Thanks for taking a look!
~ZM~

 

[6StringJazzer]

I highly doubt that it's as simple as changing wherever I find "32" to "64"...right?

No. In fact, don't do that!

This is not really hard at all but if you are not a VBA coder you may find it intimidating. But you got this.

In the API calls when Long is used to type a pointer, it needs to be retyped as LongPtr. The API functions must be declared as PtrSafe. Please see this explanation from Microsoft.

I would have updated the code for you but I can't update a picture. Next time please consider pasting the actual code into your post, the select it and click the VBA button to preserve the code formatting. If you try again I will make the updates.

 

[zombiemaster]

No. In fact, don't do that!

This is not really hard at all but if you are not a VBA coder you may find it intimidating. But you got this.

In the API calls when Long is used to type a pointer, it needs to be retyped as LongPtr. The API functions must be declared as PtrSafe. Please see this explanation from Microsoft.

I would have updated the code for you but I can't update a picture. Next time please consider pasting the actual code into your post, the select it and click the VBA button to preserve the code formatting. If you try again I will make the updates.

Thanks, Jeff - I knew it wouldn't be as easy as 32=64 (but a guy can hope, right?).

What I provided is just one sample of the code that I have to work with...as I said, it's LARGE and is in pieces scattered over multiple processes used in a PowerPads feature in a BlueZone mainframe. That's why I didn't bother just putting the code here, I just wanted someone to see what I was looking at for that one module as an example of the bigger picture!

Tomorrow I will take a look at that MS link you provided, thank you!
~ZM~

 

[John_w]

For those two API functions all you need is to add the "PtrSafe" keyword:

Private Declare PtrSafe Function GetPrivateProfileStringA .....
Private Declare PtrSafe Function WritePrivateProfileStringA .....

If you want to keep the 32-bit API declarations so the code continues to work on 32-bit Excel (Office <=2007), whilst also updating them to work on 32-bit or 64-bit Excel (Office >= 2010) then separate API declarations must be used with the VBA7 compiler constant:

#If VBA7 Then
    'New VBA version 7 compiler, therefore >= Office 2010
    'PtrSafe means function works in 32-bit and 64-bit Office
    'LongPtr type alias resolves to Long (32 bits) in 32-bit Office, or LongLong (64 bits) in 64-bit Office
    Private Declare PtrSafe Function GetPrivateProfileStringA .....
    Private Declare PtrSafe Function WritePrivateProfileStringA .....
    Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long)
    Private Declare PtrSafe Function SetForegroundWindow Lib "user32.dll" (ByVal hwnd As LongPtr) As LongPtr
#Else
    'Old VBA version 6 or earlier compiler, therefore <= Office 2007
    Private Declare Function GetPrivateProfileStringA .....
    Private Declare Function WritePrivateProfileStringA .....
    Private Declare Sub Sleep Lib "kernel32" (ByVal milliseconds As Long)
    Private Declare Function SetForegroundWindow Lib "user32.dll" (ByVal hwnd As Long) As Long
#End If

The above code shows the use of the LongPtr data type alias.

These pages are useful:

64-bit Visual Basic for Applications overview

Office VBA reference topic

docs.microsoft.com

Declaring API functions for 64 bit Office (and Mac Office)

JKP Application Development Services, Microsoft Office Application Development

jkp-ads.com

 

[6StringJazzer]

For those two API functions all you need is to add the "PtrSafe" keyword:

I could be mistaken but don't they also have to return As LongPtr? And any variables they are assigned to also typed as LongPtr?

 

[Jaafar Tribak]

I could be mistaken but don't they also have to return As LongPtr? And any variables they are assigned to also typed as LongPtr?

Hi Jeff,

No. Not necessarly.

When in doubt, It is always useful to read the official function decumentation despite being written in C.

In this particular case, GetPrivateProfileStringA returns the number of characters copied to the buffer (in a DWORD). Actually, even without doing any data type conversions, just by reading what the function does, it is often quite easy to figure out the correct corresponding vb data types. Since this api returns the number of characters, we can assume it is likely to be a Long (large enough to hold chars count) .. Same goes for WritePrivateProfileStringA .

Like you said above, LongLong is for holding larger numerical values such as handles, memory addresses etc .

Also, when in doubt, there is alwys this Win32API_PtrSafe.TXT api viewer which gives you the required x64 api declarations.

Interstingly, the api viewer is incomplete. It doesn't contain api declarations for many less frequently used libraries such as gdiplus, OleAut32, shlwapi ... etc.

Regards.

 

[zombiemaster]

Thanks to everyone for your input! I've been reading up on this and understand it a little...ok, very little of it...lol

So, bare-bones, if I look at my code and change every instance of Declare Function to Declare PtrSafe Function and every instance of Long to LongPtr, would that allow the 64-bit system to work, once we get it? What we currently have is working for now, so I don't think we need to worry about solving the problem for both 32- and 64-bit at the same time (unless something changes between now and then, of course).

I understand what I'm asking for is just a band-aid, but being a side-project, I'm just looking for the quickest fix possible that won't require me to take a bunch of VBA courses on company time...LOL

~ZM~

 

[John_w]

if I look at my code and change every instance of Declare Function to Declare PtrSafe Function and every instance of Long to LongPtr, would that allow the 64-bit system to work, once we get it?

No, it isn't as easy as that, unfortunately. This section titled "Which Longs should become LongPtr?" has a good explanation:

Declaring API functions for 64 bit Office (and Mac Office)

JKP Application Development Services, Microsoft Office Application Development

jkp-ads.com

You have to change the API function arguments and return values as appropriate and the variables which are passed to those arguments and the variables which receive the return values.

 

[zombiemaster]

No, it isn't as easy as that, unfortunately. This section titled "Which Longs should become LongPtr?" has a good explanation:

Declaring API functions for 64 bit Office (and Mac Office)

JKP Application Development Services, Microsoft Office Application Development

jkp-ads.com

You have to change the API function arguments and return values as appropriate and the variables which are passed to those arguments and the variables which receive the return values.

Hmm. Ok, this is way above my paygrade. I don't know anything about variables and return values...looks like I'll have to let someone more experienced do the dirty work on this one. Thanks for trying to help and the extra information - at least I can compile everything I've learned, then let them figure out what to do with it!

~ZM~