当exe是x86(32bit)时，dll将作为32bit或64bit加载在64 bit机器上？
例如，在VS2008中，我有一个构建为x86(32bit)的exe，因为我希望它即使在64 bit机器上也能以32bit运行。此exe将通过反射和调用动态加载其他DLL。
现在我的问题是，如果我将我的dll构建为“所有CPU”，而不是x86，当我在64位机器上运行exe主机时，一旦我的dll被加载或调用，该dll将被视为64位或32位？（我的测试显示它被视为32bit，但我想和大家确认一下。我想一般来说，32bit不能访问64bit。因为exe是32bit，所以DLL总是被加载为32bit？）
共有1个答案
是的，你是对的。除非您跳过一些严重的障碍，否则进程的每个部分（至少是用户代码部分）都将是32位的。
-
在我的机器上，JAVA_HOME的环境用户变量被设置为32位jdk，地址为“C:\Program Files(x86)\java\jdk1.6.0_31”，路径包括JAVA_HOME。但是当我从命令提示符检查java-version时，它显示64位版本正在运行。 java版本“1.6.0_31” java(TM)SE运行时环境（构建1.6.0_31-B05) java HotSpot(TM)64位
-
我预计在将Xmx参数从32GB重新配置为64GB之后，内存中保留的“有用”对象的数量将会有很大的内存开销。 我试图通过在运行小堆(8GB)的本地计算机上应用来模拟和估计差异，但还不能得出结论。根据运行时计算，在这两种情况下，我的对象占用的内存是相同的。使用的堆关闭了优化，往往会多一点，但绝不会多两倍，正如我可以预期的那样，阅读了一些解释。 在我的用例中，我只是在程序的整个生命周期中保持大量相对较大
-
我加载适配器。所以这将适用于另一个 图书馆平铺 用此java编译的jar(1.7.0_79 64位）
-
问题内容： 我正在尝试在x86_64上编译glibc（作为次要的，不是系统的替代品）2.6，并试图使其生成32位对象。当我给它一个标准配置时，它可以很好地编译，生成通常的64位库对象。一些信息： 07:32:21 \ EST 2010 x86_64 x86_64 x86_64 GNU/Linux 除其他外，我尝试了以下方法： 尝试1： 尝试2： 配置成功，但是会导致一系列编译错误，如下所示： 如果
-
摘要：我在查看程序集代码以指导我的优化，并且在将int32添加到指针时看到了大量的符号或零扩展。 起初，我认为我的编译器在添加32bit到64bit的整数时遇到了挑战，但我已经在Intel ICC 11、ICC 14和GCC 5.3中证实了这种行为。
-
我需要只使用%RAX、%RBX、%RCX、%RDX、%RSI和%RDI（还有%RSP和%RBP）编写像素化汇编代码 GCC编写的程序集代码： 已将%dl更改为%rdx：