Hello Sir,
I'm using VirtualAlloc API to allocate memory. I used VA_SHARED macro to allocate memory. It works perfectly when I boot System from C:\.If I boot from any other Drive say D:\ it doesnot work. VirtualAlloc Fails. What May be the reason. Please Explain
I'm using VirtualAlloc API to allocate memory. I used VA_SHARED macro to allocate memory. It works perfectly when I boot System from C:\.If I boot from any other Drive say D:\ it doesnot work. VirtualAlloc Fails. What May be the reason. Please Explain
What kind of OSes you have on C: and on D: ?
P.S.: BTW, who is that Sir? I can't remember the member with this nickname. ;)
P.S.: BTW, who is that Sir? I can't remember the member with this nickname. ;)
I'm having Win2k in C:\ and WinXP in D:\
Hm, it's a little bit strange for me. In all cases it's not because of drives you boot, it's because of OS. Can you post some example source?
regards.
regards.
That's what I'm thinking off. My source code is given below where my .asm code fails and returns. Actually I got idea from the Internet. So I can't able to find the solution.
Invoke VirtualAlloc,NULL,inject_code_size,MEM_COMMIT + VA_SHARED,PAGE_EXECUTE_READWRITE
Thank You
Invoke VirtualAlloc,NULL,inject_code_size,MEM_COMMIT + VA_SHARED,PAGE_EXECUTE_READWRITE
Thank You
There is not VA_SHARED flag in my documentation. Maybe this is something from newest versions of Window. But to use the most new features of the OS is not a good idea at all IMHO.
Why not to use some older, but common approach? BTW: I am using only heap functions (GetProcessHeap, HeapAlloc, HeapFree) not VirtualAlloc.
flAllocationType
Specifies the type of allocation. You can specify any combination of the following flags:
Flag Meaning
MEM_COMMIT Allocates physical storage in memory or in the paging file on disk for the specified region of pages.
An attempt to commit an already committed page will not cause the function to fail. This means that a range of committed or decommitted pages can be committed without having to worry about a failure.
MEM_RESERVE Reserves a range of the process's virtual address space without allocating any physical storage. The reserved range cannot be used by any other allocation operations (the malloc function, the LocalAlloc function, and so on) until it is released. Reserved pages can be committed in subsequent calls to the VirtualAlloc function.
MEM_TOP_DOWN Allocates memory at the highest possible address.
Specifies the type of allocation. You can specify any combination of the following flags:
Flag Meaning
MEM_COMMIT Allocates physical storage in memory or in the paging file on disk for the specified region of pages.
An attempt to commit an already committed page will not cause the function to fail. This means that a range of committed or decommitted pages can be committed without having to worry about a failure.
MEM_RESERVE Reserves a range of the process's virtual address space without allocating any physical storage. The reserved range cannot be used by any other allocation operations (the malloc function, the LocalAlloc function, and so on) until it is released. Reserved pages can be committed in subsequent calls to the VirtualAlloc function.
MEM_TOP_DOWN Allocates memory at the highest possible address.
Why not to use some older, but common approach? BTW: I am using only heap functions (GetProcessHeap, HeapAlloc, HeapFree) not VirtualAlloc.
I have psdk february 2003 and there is not VA_SHARED.
If you want to share memory between process you can also use MapViewOfFile.
Use virtual alloc only to allocate large space of memory (at least 2 mega). If you have smaller memory block you should use HeapAlloc, ...
If you want to share memory between process you can also use MapViewOfFile.
Use virtual alloc only to allocate large space of memory (at least 2 mega). If you have smaller memory block you should use HeapAlloc, ...
Wenn man kann deutsch lesen:
http://www.sistemo.com/Articles/ForceLibrary.htm
#define VA_SHARED 0x8000000 // Matt Pietrek
It was user defined.
http://www.sistemo.com/Articles/ForceLibrary.htm
#define VA_SHARED 0x8000000 // Matt Pietrek
It was user defined.
Thank You for the link. But I can't understand anything in that page. Will you please give me a link that has the English version of the link. So that I can understand.
Maybe because there isn't one?
I'll try to translate the surrounding text for you.
On Windows 9x (95, 98, ME) one could realize Shared Memory, for example with MMFs (Memory Mapped Files), which on these enterprise systems generally are stored just where we want them, in the kernel memory region (> 0x80000000). With the help of the APIs OpenFileMapping and CreateFileMapping one can easily and in an easy way get global storage. One creates a file mapping object and gets a pointer to the storage area just won in return. One could naturally manipulate the IDT (Interrupt descriptor table) and through one of our routines obtain redirected IDT vector access to Ring 0 (kernel mode) and subsequently call the kernel API HeapAllocate, which allocates shared memory as well. The following possibility is much more elegant though. An absolute system programmer hero, Matt Pietrek [4], has found out and published in his book, "Windows 95 System programming SECRETS", that an undocumented flag exists for the VirtualAlloc API, which makes no normal memory available of the specified size, but instead returns a pointer larger than 0x80000000 (2 GB). Year. We'll use just that. I have defined it in the ForceLibrary source code which follows (with a reference to the originator of course)
#define VA_SHARED 0x80000000 // Matt Pietrek
This store is deallocated in a conventional way, with VirtualFree, no complications come forth with this. One needs not to be afraid that this undocumented and therefore prohibited (?) use fails in future versions either. That should usually not happen. This flag functions reliably on all 32-bit 9x Windows operation systems of the present, and since the sequence ends with Windows ME and Microsoft's future enterprise systems are exclusively based on NT, it is therefore supported on all existing Windows 9x systems.
I'll try to translate the surrounding text for you.
On Windows 9x (95, 98, ME) one could realize Shared Memory, for example with MMFs (Memory Mapped Files), which on these enterprise systems generally are stored just where we want them, in the kernel memory region (> 0x80000000). With the help of the APIs OpenFileMapping and CreateFileMapping one can easily and in an easy way get global storage. One creates a file mapping object and gets a pointer to the storage area just won in return. One could naturally manipulate the IDT (Interrupt descriptor table) and through one of our routines obtain redirected IDT vector access to Ring 0 (kernel mode) and subsequently call the kernel API HeapAllocate, which allocates shared memory as well. The following possibility is much more elegant though. An absolute system programmer hero, Matt Pietrek [4], has found out and published in his book, "Windows 95 System programming SECRETS", that an undocumented flag exists for the VirtualAlloc API, which makes no normal memory available of the specified size, but instead returns a pointer larger than 0x80000000 (2 GB). Year. We'll use just that. I have defined it in the ForceLibrary source code which follows (with a reference to the originator of course)
#define VA_SHARED 0x80000000 // Matt Pietrek
This store is deallocated in a conventional way, with VirtualFree, no complications come forth with this. One needs not to be afraid that this undocumented and therefore prohibited (?) use fails in future versions either. That should usually not happen. This flag functions reliably on all 32-bit 9x Windows operation systems of the present, and since the sequence ends with Windows ME and Microsoft's future enterprise systems are exclusively based on NT, it is therefore supported on all existing Windows 9x systems.
Try using LocalAlloc with both processes using same handle. This is how the operating system communicates between processes. It assigns the same local descriptor table to multiple processes so they share the same memory.
Nope. LocalAlloc in Win32 works nothing like the normal LocalAlloc. It will return a low address. Even when using LMEM_MOVEABLE it will return a low address and thus it can only be used in the same process.
The returned pointer is not a logical address. The processes are above 80000000h. Anyway I never tried it that way but I would think the handle would point to the same memory reguardless of what process is using it. I woud say do not unlock or free the memory. And use same handleFile mapping can be used to share a file or memory between two or more processes. To share a file or memory, all of the processes must use the name or the handle of the same file-mapping object.
This is from Win32 "API's":
To share a file, the first process creates or opens a file by using the CreateFile function. Next, it creates a file-mapping object by using the CreateFileMapping function, specifying the file handle and a name for the file-mapping object. The names of event, semaphore, mutex, and file-mapping objects share the same name space. Therefore, the CreateFileMapping and OpenFileMapping functions fail if they specify a name that is in use by an object of another type.
To share memory that is not associated with a file, a process must use the CreateFileMapping function and specify (HANDLE)0xFFFFFFFF as the hfile parameter instead of an existing file handle. The corresponding file-mapping object accesses memory backed by the system paging file. You must specify a size greater than zero when you specify an hfile of (HANDLE)0xFFFFFFFF in a call to CreateFileMapping.
This is from Win32 "API's":
To share a file, the first process creates or opens a file by using the CreateFile function. Next, it creates a file-mapping object by using the CreateFileMapping function, specifying the file handle and a name for the file-mapping object. The names of event, semaphore, mutex, and file-mapping objects share the same name space. Therefore, the CreateFileMapping and OpenFileMapping functions fail if they specify a name that is in use by an object of another type.
To share memory that is not associated with a file, a process must use the CreateFileMapping function and specify (HANDLE)0xFFFFFFFF as the hfile parameter instead of an existing file handle. The corresponding file-mapping object accesses memory backed by the system paging file. You must specify a size greater than zero when you specify an hfile of (HANDLE)0xFFFFFFFF in a call to CreateFileMapping.
There is no "real" global memory on NT - the closest you get is Memory Mapped Files, and the requires cooperation between processes. That is, there's no (easy) way you could allocate some memory that would be available in all processes and/or kernel mode, ie for the use of patching system DLLs and adding code.