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
Posted on 2003-09-16 09:53:19 by SDhivya
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. ;)
Posted on 2003-09-16 10:09:14 by JohnFound
I'm having Win2k in C:\ and WinXP in D:\
Posted on 2003-09-16 10:20:52 by SDhivya
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.
Posted on 2003-09-16 10:31:51 by JohnFound
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
Posted on 2003-09-17 12:20:30 by SDhivya
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.

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.


Why not to use some older, but common approach? BTW: I am using only heap functions (GetProcessHeap, HeapAlloc, HeapFree) not VirtualAlloc.
Posted on 2003-09-17 12:34:18 by JohnFound
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, ...
Posted on 2003-09-17 14:44:25 by greenant
Wenn man kann deutsch lesen:
http://www.sistemo.com/Articles/ForceLibrary.htm

#define VA_SHARED 0x8000000 // Matt Pietrek

It was user defined.
Posted on 2003-09-17 21:30:52 by grv575
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.
Posted on 2003-09-19 09:41:49 by SDhivya
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.
Posted on 2003-09-19 12:42:18 by Sephiroth3
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.
Posted on 2003-09-20 06:35:51 by mrgone
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.
Posted on 2003-09-20 08:43:02 by Sephiroth3
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.
Posted on 2003-09-20 14:04:51 by mrgone
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.
Posted on 2003-09-21 05:48:07 by f0dder