VirtualAllocEx来自32位的64位进程,超越边界 [英] VirtualAllocEx from 64bit process on 32bit, over the boundary

查看:598
本文介绍了VirtualAllocEx来自32位的64位进程,超越边界的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

所以我有一个运行64位的进程,用于在外部32位进程中分配内存,我想知道是不是可以在32位进程的0x7FFFFFFF内存地址限制上分配内存?

So I have a process running 64bit, which I use to allocate memory in a foreign 32bit process, I was wondering isn't it possible to alloc memory over the 0x7FFFFFFF memory address limit on the 32bit process?

推荐答案

我不知道你为什么要这么做,但这种分配取决于平台。此外,分配如此多内存的实际可能性取决于此刻内存的实际使用情况;我想你明白了。



让我们看看。 32位进程的地址空间受其地址字类型的限制,它为32位,为您提供4G。你需要2G。在32位平台上,这是专用于所有代码的所有内存,外部(用户)保护环中的代码。其他2G专用于OS内部。根据文档,可以更改系统配置以将3G留给应用程序,但我从未尝试过。



但看起来你只对分配64位系统上的内存。然后,即使你的进程是一个32位的,它可以使用高达4G的内存(不包括代码和静态数据已经使用的内存,加上一些开销,当然,很难说多少;你可以试验它)。这是因为每个进程都有自己的地址空间(32位地址空间,在你的情况下是4G);不同的32位进程不会在通用4G空间上竞争;相反,它们是使用Windows子系统WoW64独立加载的,这是一个用于支持32位进程的64位层:

http://en.wikipedia.org/wiki/WoW64 [ ^ ]。



-SA
I don't know why are you doing all that, but such allocation depends on the platform. Also, the actual possibility to allocate so much memory depends on the actual use of the memory at the moment; I guess you understand it.

Let's see. The address space of a 32-bit process is limited by the type of its address word, which it 32 bits, which gives you 4G. You require 2G. On a 32-bit platform, this is all the memory dedicated to all code taken together, those in the outer (user) protection ring. Other 2G is dedicated to the OS internals. According to documentation, system configuration can be changed to leave 3G to the applications, but I never tried it.

But it looks like you are only interested in allocation of the memory on a 64-bit system. Then, even if your process is a 32-bit one, it can use up to 4G of memory (excluding the memory already used by code and static data, plus some overhead, of course, hard to say how much; you can experiment with it). This is because each process is given its own address space (32-bit address space, in your case, 4G); different 32-bit processes don't compete over the common 4G space; instead, they are loaded independently using the Windows sub-system WoW64, which is a 64-bit layer used to support 32-bit processes:
http://en.wikipedia.org/wiki/WoW64[^].

—SA


First据我所知,不可能在另一个进程中从一个进程分配内存。所以从那时起,你的问题对我来说没有意义。可能,你的意思是你想在另一个进程中访问内存。



其次,在32位Windows进程中,内存空间的上半部分(7FFFFFFF到FFFFFFFF) )保留给操作系统。因此,进程无法在那里分配内存,也无法访问内存的那一部分。 (在较新的Windows版本中,该限制可以从2GB向上移动到3GB边界,或者换句话说,只有地址空间的高四位由系统保留。此选项可以通过选项开关启用创造时间)。



所以无论如何:你的问题的答案是:不。
First of, to my knowledge it is not possible to allocate memory from one process in another process. So from that point, your question doesn't make sense to me. Possibly, you mean that you want to access memory in another process.

Secondly, in 32-bit Windows processes, the upper half of the memory space (7FFFFFFF to FFFFFFFF) is reserved to the operating system. So a process cannot allocate memory there nor access that part of memory. (On newer Windows versions, that limit can be shifted upward from the 2GB to the 3GB boundary, or in other words, only the upper forth of the address space is reserved by the system. This option can be enabled by an option switch on process creation time).

So in any case: The answer to your question is: "No".


这篇关于VirtualAllocEx来自32位的64位进程,超越边界的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆