Hello all.
Could anybody with access to a Win95 machine run this simple program and report the result?
void test(void) { HANDLE hMapping; void *p; MEMORY_BASIC_INFORMATION info; DWORD dwRet;
hMapping = CreateFileMappingA(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE | SEC_RESERVE, 0, 0x0400f000, NULL); printf("hMapping = %04x\n", hMapping); p = MapViewOfFile(hMapping, FILE_MAP_READ ,0, 0, 0x00010000); printf("p = %p\n", p); UnmapViewOfFile(p);
dwRet = VirtualQuery(p, &info, sizeof(info)); printf("VirtualQuery(%p) ret=0x%lx\n" "BaseAddress = %p\n" "AllocationBase = %p\n" "AllocationProtect = 0x%08lx\n" "RegionSize = 0x%08x\n" "State = %08lx\n" "Protect = %08lx\n" "Type = %08lx\n", p, dwRet, info.BaseAddress, info.AllocationBase, info.AllocationProtect, info.RegionSize, info.State, info.Protect, info.Type); }
Thanks in advance.
On Fri, 20 Apr 2001 21:05:30 +0800, you wrote:
Hello all.
Could anybody with access to a Win95 machine run this simple program and report the result?
void test(void)
win95 on a vmware machine.
H:>test hMapping = 0005 p = 826DB000 VirtualQuery(826DB000) ret=0x1c BaseAddress = 826DB000 AllocationBase = 826DB000 AllocationProtect = 0x00000001 RegionSize = 0x0400f000 State = 00002000 Protect = 00000001 Type = 00020000
H:>
Rein.
"Rein Klazes" rklazes@xs4all.nl wrote:
win95 on a vmware machine.
H:>test hMapping = 0005 p = 826DB000 VirtualQuery(826DB000) ret=0x1c BaseAddress = 826DB000 AllocationBase = 826DB000 AllocationProtect = 0x00000001 RegionSize = 0x0400f000 State = 00002000 Protect = 00000001 Type = 00020000
This means that Win95/98 doesn't free region allocated with SEC_RESERVE flag set. Could you please test other SEC_ flags? Is the result the same?
I wtote:
"Rein Klazes" rklazes@xs4all.nl wrote:
win95 on a vmware machine.
H:>test hMapping = 0005 p = 826DB000 VirtualQuery(826DB000) ret=0x1c BaseAddress = 826DB000 AllocationBase = 826DB000 AllocationProtect = 0x00000001 RegionSize = 0x0400f000 State = 00002000 Protect = 00000001 Type = 00020000
This means that Win95/98 doesn't free region allocated with SEC_RESERVE flag set. Could you please test other SEC_ flags? Is the result the same?
Comment about SEC_RESERVE in memory/virtual.c tells enough, besides the fact that Win95 does not unmap regions allocated with that flag set. Attached patch makes the debugged installer proceed much further with -winver win95 switch now. Unfortunately currently there is no way to distinguish regions allocated with SEC_RESERVE flag set.
Now installer DebugBreak's after another VirtualQuery call.
Could you (or anybody else with a Win95 machine) add the following lines at the end of the previous test program and report the result?
dwRet = VirtualQuery(p + 0x10000, &info, sizeof(info)); printf("VirtualQuery(%p) ret=0x%lx\n" "BaseAddress = %p\n" "AllocationBase = %p\n" "AllocationProtect = 0x%08lx\n" "RegionSize = 0x%08lx\n" "State = %08lx\n" "Protect = %08lx\n" "Type = %08lx\n", p + 0x10000, dwRet, info.BaseAddress, info.AllocationBase, info.AllocationProtect, info.RegionSize, info.State, info.Protect, info.Type);
As usually thanks in advance (to Uwe Bonnes too! He sent his result privately).
continue talking to myself... Anybody here? :-)
Comment about SEC_RESERVE in memory/virtual.c tells enough, besides the fact that Win95 does not unmap regions allocated with that flag set.
From http://msdn.microsoft.com/library/psdk/winbase/filemap_79wn.htm
--- cut --- "To fully close a file-mapping object, an application must unmap all mapped views of the file-mapping object by calling UnmapViewOfFile, and close the file-mapping object handle by calling CloseHandle. The order in which these functions are called ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ does not matter. The call to UnmapViewOfFile is necessary because mapped views of ^^^^^^^^^^^^^^^ a file-mapping object maintain internal open handles to the object, and a file-mapping object will not close until all open handles to it are closed." --- cut ---
My patch is WRONG. MSDN says that until both CloseHandle and UnmapViewOfFile are called the file-mapping object still exists. This is wrong for NT but true for Win9x.
Could anybody add CloseHandle and yet another VirtualQuery calls at the end of my test and run it under Win9x?
I've been investigating the free Borland ilink32.exe , the one that locks under wine. Has this been discussed already? Well anyway, it probes several memory address with VirtualQuery(). This first location is 0x80000000 . On a normal windows system that would be system memory. Wine claims that area as free memory. Well apparently ilink32 doesn't want to see that region as free memory so it goes into an endless loop . There is a big list of memory location that it checks and if it doesn't get an acceptable result (Reserved) then it goes into an endless loop.
If I set all the address to,
info->State = MEM_RESERVED; info->Protect = PAGE_NOACCESS; info->AllocationProtect = PAGE_NOACCESS; info->Type = MEM_PRIVATE;
Then ilink32 doesn't lock, but it has four internal memory errors. It still doesn't work, but it exit with an error.
Here is the first set of addressed,
0x80000000 0x80FFF000 0x81FFE000 0x82FFD000 0x83FFC000 0xADC00000 0xAEBFF000 0xBFB70000 0xA0000000 0x83FFE000 0x81FFF000 0xA1FFF000 0x90000000 0x91FFF000 0xB1BFE000 0x91FFF000 0x98000000 0x99FFF000 0xB8000000 0xBA000000
Daniel Walker
"Dmitry" == Dmitry Timoshkov dmitry@sloboda.ru writes:
... Dmitry> Could you (or anybody else with a Win95 machine) add the Dmitry> following lines at the end of the previous test program and Dmitry> report the result?
This is with win98seg
hMapping = 0014 p = 82D7E000 VirtualQuery(82D7E000) ret=0x1c BaseAddress = 82D7E000 AllocationBase = 82D7E000 AllocationProtect = 0x00000001 RegionSize = 0x0400f000 State = 00002000 Protect = 00000001 Type = 00020000 VirtualQuery(82D8E000) ret=0x1c BaseAddress = 82D8E000 AllocationBase = 82D7E000 AllocationProtect = 0x00000001 RegionSize = 0x03fff000 State = 00002000 Protect = 00000001 Type = 00020000
-
Daniel Walker -
Dmitry Timoshkov -
Rein Klazes -
Uwe Bonnes