操作系统的位数是否重要，还是仅仅是我需要担心的应用程序? [英] Does the bitness of the OS ever matter, or is it just the application I need to worry about?

问题描述

忽略16位内容，可以在32或64位Office主机上运行VBA. 64位Office只能在64位OS上运行，而您可以在32位或 Windows/macOS/其他操作系统的32位版本上运行32位Office.

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 you can run 32-Bit office on a 32 or 64-bit version of Windows/macOS/other Operating System.

从VBA7开始，我们具有LongPtr类型，在32位Office(#Win64 = False)上变为Long，在64位Office(#Win64 = True)上变为LongLong，无论操作系统的位数

As of VBA7, we have the LongPtr type, which becomes a Long on 32-bit Office (#Win64 = False), LongLong on 64-bit Office (#Win64 = True), regardless of the OS bitness

我的问题:在处理指针(内存中的地址)的API中，操作系统的位无关紧要，还是仅仅是运行我们关心的代码的应用程序(32 /64位Office主机/VBA)?

My question: In APIs that deal with pointers (addresses in memory), does the OS bitness ever matter, or is it only the application running the code that we care about (32/64-bit Office host/VBA)?

一方面，我明白了为什么可能没关系:

On the one hand I can see why it might not matter:

• 在32位Excel中运行的VBA将具有32位地址空间(与操作系统无关)
• 因此，指向其自身内存的任何指针都应为32位(即Long s-LongPtr给我们提供了此指针)
• 类似地，64位VBA(在64位OS中是必需的，但实际上可以在任何地方)具有64位地址空间(每个指针本身的长度为64位，并指向64位宽的内存块)
• 因此，指向其自身内存的任何指针都应为64位(即LongLong s-LongPtr给出了这一点)
• 所以LongPtr准确地表示了我的代码自己的内存的指针，而不考虑操作系统的位数

• VBA running in 32-bit Excel will have a 32-bit address space (regardless of OS)
• Therefore any pointers to its own memory should be 32-bits (i.e. Longs - LongPtr gives us this)
• Similarly 64-bit VBA (necessarily in 64-bit OS, but really could be anywhere) has a 64 bit address space (each pointer is itself 64-bits long and refers to a 64-bit wide block of memory)
• Therefore any pointers to its own memory should be 64-bits (i.e. LongLongs - LongPtr gives us this)
• So LongPtr accurately represents a pointer to my code's own memory, regardless of OS bitness

但是我可以想象操作系统的重要性 重要的时间

However I can imagine times where the OS bitness could matter

• 在64位OS上运行32位VBA，但要引用其他64位应用程序的内存中的区域，LongPtr类型的计算结果为Long，并且太短以致不能代表最大值该操作系统中可用的指针大小.
• 类似地，访问32位应用程序的64位VBA会发现其指针类型太大而无法保存地址
• 现在，值得信赖的LongPtr类型实际上是错误的长度，用来表示指向VBA自身地址空间之外的内存中地址的指针！

• Running 32-bit VBA on 64-bit OS, but wanting to refer to areas in memory of a different 64-bit application, the LongPtr type would evaluate to Long and would be too short to represent the maximum pointer size available in that OS.
• Similarly a 64-bit VBA accessing memory of a 32-bit application would find its pointer type too large to hold the address
• Now the much trusted LongPtr type is actually the wrong length to represent a pointer to an address in memory outside VBA's own address space!

现在可能会出现问题，具体取决于操作系统位数，而不是Office/VBA位数.如果我们在32位OS上运行VBA7，则LongPtr将是您可能要扔给它的任何内存块的正确长度；在99.9％的情况下，它是一种合适的指针数据类型，因为操作系统所做的一切都是32位(忽略16位).

Problems can now arise depending on OS bitness, not Office/VBA bitness. If we're running VBA7 on 32-bit OS, then LongPtr will be the right length for any chunk of memory you could want to throw at it; it is a suitable pointer datatype in 99.9% of cases since everything the OS does is 32-bit (ignoring 16 bit).

但是，当尝试使用LongPtr来保存32位地址时，在32位VBA7代码上运行而不是在64位OS上运行会遇到困难.我觉得在64位操作系统上混合使用32位和64位应用程序非常普遍，因此这可能是一个现实问题.

However the same 32-bit VBA7 code instead running on a 64-bit OS would run into difficulties when trying to use LongPtr to hold 32-bit addresses. I feel it's quite common to mix 32-bit and 64-bit applications on a 64-bit OS so this could be a real issue.

在32位和64位操作系统上运行的32位VBA6和更早版本的应用程序可能会遇到类似的问题，只有在没有LongPtr

32-bit VBA6 and earlier applications running on 32 vs 64 bit Operating Systems could face similar issues, only without the help of LongPtr

现在，我意识到这是一个非常虚构的情况，谁愿意访问另一个应用程序的内存，对吗?实际上，它是如此的人为设计，以至于我不确定我是否会遇到这种情况很重要并且值得担心的情况.一个应用程序能否获得到另一个具有不同位数的应用程序的内存地址?也许有一些读写保护措施可以防止这种情况.

Now I appreciate that's a pretty contrived situation, who would ever want to access another application's memory, right? In fact it's so contrived that I'm not sure I could ever come up with a situation where this is important and worth worrying about. Could an application ever obtain an address to the memory of another application with different bitness? Maybe there are some read-write protections preventing this.

也许访问另一个应用程序的窗口句柄就是这种情况.那是公共内存，也许窗口句柄的位数反映了应用程序或操作系统的位数，在这种情况下，我的32位VBA希望保留对64位Hwnd的引用，我不确定...

Perhaps accessing another application's window handle would be one such occasion; that's public memory and perhaps the bitness of the window handle reflects the bitness of the application or the Operating system, in which case it would be feasible for my 32-bit VBA to want to hold a reference to a 64-bit Hwnd, I'm not sure...

PS我知道，除了指针长度以外，在某些情况下OS位可能很重要.我知道一个； SetWindowLong函数在64位和32位Windows上需要不同的声明-尽管IIUC已通过SetWindowLongPtr函数解决了，这两个函数都是相同的.但是了解任何其他类似的怪癖也很有用，我在这里只关注指针长度，因为我有一个需要特定信息的问题.

PS I'm aware there are situations other than pointer length where OS bitness may be important. I know of one; the SetWindowLong function required different declarations on 64-bit vs 32-bit Windows - although IIUC that's now been solved with the SetWindowLongPtr function which is identical for both. But any other similar quirks would be useful to know about, I'm only focussing on pointer length here because I have a problem that requires that specific info.

PPS想到了这一点，您甚至可以在编译时获得OS位.我认为您可以从MAC_OFFICE_VERSION推论得出，ofc Win64 = True表示64位Office和事实上的64位OS.但是我不确定是否有办法判断32位VBA是否在64位Windows上运行...

PPS come to think of it, can you even get OS bitness at compile time; I think you can infer it from MAC_OFFICE_VERSION, and ofc Win64 = True means 64-bit Office and de-facto 64-bit OS. But I'm not sure if there's a way to tell whether 32-bit VBA is running on 64-bit Windows...

推荐答案

对于您的过程，LongPtr始终是正确的 .您无需担心其大小.您不需要WIN64常量即可使用它.实际上，通常唯一需要的常量是VBA7，它告诉您LongPtr是否可用.如果是，请使用它；如果不是，请使用xc.所以请使用Long.

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.

此外，Windows x64具有称为 WoW64 的整个兼容性层.作为在64位Windows上运行的32位应用程序，您不会注意到任何东西，并且就像操作系统是32位一样运行.指针大小为4个字节，指针大小的数据类型(如HWND)为4个字节，因此，再次声明，如果只查询VBA7并将LongPtr正确放置在其中，则无需担心任何情况.必须出现指针大小的参数的所有位置.

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.

因此，对于过程中的例行事务以及与OS及其对象的交互，您不必担心 自己或OS的麻烦，而您不必担心也不需要WIN64常量.

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.

现在，您特别提到获得和使用对具有与您自己不同的位的进程有效的指针.是的，这可能是一个问题，但这不是VBA特有的问题.

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.

如果作为VBA应用程序，您发现自己需要读取任意位数的任意进程的内存，则需要将自己的位数与其位数进行比较.此时，您可以使用WIN64常量，但是在这种情况下，在运行时检查Len(long_ptr_variable)比拥有单独的代码分支要方便得多.

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.

进行了测试

• 如果位数较高，则可以不受限制地读取另一个进程的内存.
• 如果位数较小，则可以在4字节指针允许的范围内扩展大家伙的虚拟内存.
  • 如果您需要超越此范围，就必须失败(否则).
  • 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).

    但是请注意，即使在这种情况下，您也不在乎操作系统的位数或WIN64 const！您只关心自己的进程位和其他进程位.

    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.

    这篇关于操作系统的位数是否重要，还是仅仅是我需要担心的应用程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！