Задача — из 32-х битного процесса узнать объем памяти, который используется другим процессом. Этот объем более 4 Гб.
Если процесс использует более 4 Гб, GetProcessWorkingSetSize возвращает 4 Гб.
Есть какое-то API для такой задачи?

Здравствуйте, maks__, Вы писали:

__>Задача — из 32-х битного процесса узнать объем памяти, который используется другим процессом. Этот объем более 4 Гб.
__>Если процесс использует более 4 Гб, GetProcessWorkingSetSize возвращает 4 Гб.
__>Есть какое-то API для такой задачи?

AFAIK только создать 64-битный процесс, попросить его сделать требуемое и вернуть каким-нибудь способом результат.

__>>Задача — из 32-х битного процесса узнать объем памяти, который используется другим процессом. Этот объем более 4 Гб.
__>>Если процесс использует более 4 Гб, GetProcessWorkingSetSize возвращает 4 Гб.
__>>Есть какое-то API для такой задачи?
PD>AFAIK только создать 64-битный процесс, попросить его сделать требуемое и вернуть каким-нибудь способом результат.
Еще можно:
1) загрузить в свое АП 64хбитную длл путем посылки своему треду APC из 64хбитного процесса и затем коммуницировать с ней через какой нить IPC. Но это потребует опять же временного х64 процесса
2) Из 32хбитного контекста "провалиться" в long mode в нужный момент и юзать системные сервисы через нативную ntdll. Но это очень черная магия, я не буду ее показывать.

Здравствуйте, ononim, Вы писали:

O>1) загрузить в свое АП 64хбитную длл путем посылки своему треду APC из 64хбитного процесса и затем коммуницировать с ней через какой нить IPC. Но это потребует опять же временного х64 процесса

Хм. А разве это можно делать ?

Similarly, if a 64-bit process queues an APC to a 32-bit process or vice versa, addresses will be incorrect and the application will crash.

http://msdn.microsoft.com/ru-ru/library/windows/desktop/ms684954(v=vs.85).aspx

O>>1) загрузить в свое АП 64хбитную длл путем посылки своему треду APC из 64хбитного процесса и затем коммуницировать с ней через какой нить IPC. Но это потребует опять же временного х64 процесса
PD>Хм. А разве это можно делать ?
PD>Similarly, if a 64-bit process queues an APC to a 32-bit process or vice versa, addresses will be incorrect and the application will crash.
Фигню пишут, все работает замечательно Тока
1) Слать надо не с помощью QueueUserApc (т.к. она использует промежуточную заглушку, располагающуюся в kernel32, которой в том процессе нет), а с помощью NtQueueApcThread
2) по адресу APC должен лежать 64хбитный код, юзающий тока 64хбитную ntdll.
3) И если этот код будет грузить другую длл (при помощи LdrLoadDll) — та другая длл тока должна юзать тока ntdll.
А если как обычно попытаться позвать QueueUserApc для исполнения LoadLibrary из Kernel32 — тогда действительно, addresses will be incorrect. Причем все

Здравствуйте, ononim, Вы писали:

То есть все же, пусть и недокументированным способом, смешивать в одном процессе 32- и 64-битный код можно ? MS вроде клялась, что нет...

PD>То есть все же, пусть и недокументированным способом, смешивать в одном процессе 32- и 64-битный код можно ?
Можно, но без особой на то необходимости не нужно

PD>MS вроде клялась, что нет...
Ну я клятв таких не видел, но могу предположить что имелось в виду использование win32. Его 64хбитной версии действительно в wow64 процессе нету просто потому что 64хбитная kernel32 не грузится на этапе инициализации процесса. Да и даже если ее насильно загрузить — она не проинициализируется т.к. будет послана csrss'ом в пешее эротическое путешествие. А так — wow64 процесс сам по себе представляет собой такую смесь. В нем же есть обычная ntdll которая исполняет обычный 64хбитный код .