Does the bitness of the OS ever matter, or is it just the application I need to worry about?

Question

Some assumptions: (correct me if wrong)

Ignoring 16-bit stuff, VBA can be run on 32 or 64-bit Office hosts. 64-bit Office can only be run on a 64-bit OS, whereas yo

Answer 1

Certainly, bitness of the OS matters.

You can see this answer for a case where we need specific code for 32-bits office on 64-bits Windows (registering COM DLLs properly for use in 32-bits applications).

The test I use there is:

#If Win64 Then
    Const Win64 = True
#Else
    Const Win64 = False
#End If
If Not Win64 And Environ$("ProgramW6432") <> vbNullString Then
    '32 bits Office on Win 64
Else
    'Either 32-bits Windows, or 64-bits Office on 64-bits windows
End If

Afaik, you can't determine this at compile time, only at runtime.

When working with external APIs/applications, it can often matter. I'm not going to compile a list of possible scenario's since it'll never be full, but there are many possible cases.

For memory access, it shouldn't matter, though, since accessing another processes non-global memory should throw a segfault and hard-crash your application. And if you're working with globals it's not really a problem.

Answer 2

A LongPtr is always correct for your process. You do not need to worry about its size. You do not need the WIN64 constant to use it. In fact, the only constant you normally need is VBA7 that tells you whether the LongPtr is even available. If it is, use it, if it's not, you are definitely x86 so use Long.

Additionally, Windows x64 has an entire compatibility layer called WoW64. As a 32-bit app running on 64-bit Windows, you do not notice anything and you run as if the OS was 32-bit. Your pointer size is four bytes, your pointer-sized data types such as HWNDs are four bytes, so again, you do not need to worry about any of that if you only consult VBA7 and correctly place LongPtr in all places where a pointer-sized argument must appear.

So, for routine things inside your process, and for interacting with the OS and its objects, you don't need to worry about either your own or the OS'es bitness, and you don't need the WIN64 constant either.

---

Now, you specifically mention obtaining and using pointers that are valid for processes with different bitness than your own. Yes, that might be a problem, but this problem is not specific to VBA.

If, as a VBA app, you find yourself in a need to read memory of an arbitrary process of arbitrary bitness, you do need to compare your own bitness to its bitness. At this point you could make use of the WIN64 constant, but it's much more convenient in this case to check the Len(long_ptr_variable) at runtime than to have separate code branches.

Having made the test,

• If your bitness is higher, you can read the other process'es memory without restrictions.
• If your bitness is smaller, you can reach as far up the big guy's virtual memory as your 4-byte pointer allows.
  • And if you need to reach beyond that, you would have to fail (or not).

But note that even in this case, you don't care about the OS bitness or the WIN64 const either! You only care about your process bitness vs the other process bitness.