MS-Access / Getting Started

---

Working with 64-Bit Access Visual Basic for Applications

With the creation of 64-bit versions of the Office 2010 applications, Microsoft has introduced a new 64-bit version of Visual Basic. In general, your Visual Basic code runs without modification with 64-bit Visual Basic. However, there are a few issues and opportunities when using 64-bit Visual Basic. For any programming language, the biggest source of issues when moving between different-sized architectures is the size of pointers. As you learned earlier in this tutorial, pointers are variables that hold memory addresses. When you are working on 32-bit systems, these pointers are 32-bit variables; and on 64-bit systems, they are 64-bit variables.

One of the great things about Visual Basic is that pointers are managed on behalf of programmers, relieving them of the tedium of managing pointers themselves. Still, there are situations in which a programmer needs to manage a pointer manually, in particular when interacting with the Windows API. Prior to Office 2010, Visual Basic had no official pointer data type. Moving to 64-bit with Access 2010 has both advantages and disadvantages. The advantage is that since there are no pointers, most existing Visual Basic code in your applications works just fine with 64-bit Access without any modifications. None of the data types in Visual Basic change their size when moving to 64-bit; in particular, a Long is still 32 bits. The disadvantage is that although "officially" there was no pointer data type, some Visual Basic code used Long variables to hold memory addresses as an "unofficial" pointer. Microsoft, in fact, promoted this behavior for making calls to the Windows operating system.

Since Long variables did not increase in size when moving to 64-bit, executing code that stored pointers in Long variables will result in unexpected behavior for your applications-even possibly crashing.

So what does this mean to you as an Access developer? This means that you need to identify all the places where a pointer could enter or exit Visual Basic and modify them. These include:

• Declare statements
• VarPtr functions
• StrPtr functions
• ObjPtr functions

Thankfully, the 64-bit Visual Basic compiler helps identify these situations.

Using Declare Statements

The Visual Basic Declare statement is commonly used to access Windows APIs, although it can also be used to call any DLL entry point. For example, the following Declare statement sets up a call to the Windows RegOpenKeyA API for opening a Windows registry key:

Declare Function RegOpenKeyA Lib "advapi32.dll" _
   (ByVal Key As Long, ByVal SubKey As String, _
     NewKey As Long) As Long

The Key and NewKey parameters above are Windows handles-a handle is a pointer. When you run the statement on 32-bit computers running Windows, Key and NewKey are 32-bit values and fit nicely into a Long variable. This method of coding is precisely what was done for years.

When you are using a 64-bit version of Office 2010, however, pointers and handles are 64-bit values. The big problem here is that the Long variable in Visual Basic is still 32 bits. Using our example here, consider what happens with NewKey, which is filled in by the API call. If Visual Basic allocates only 32 bits to hold NewKey and Windows thinks this is a 64-bit quantity, Windows overwrites the adjacent memory to NewKey, resulting in undefined behavior, including possibly crashing Visual Basic. For this reason, Visual Basic blocks this Declare statement from running on 64-bit Visual Basic until you properly update the statement.

You can set a registry key on your computer to force Windows to use memory allocations into the upper 32 bits of memory to help find instances in your application code where a Long was not properly upgraded to a LongPtr.