Yes, this is interisting but I'd like for example to create a memory image of some part of ram to see exactly what is there. In old dos days it was possible to do like for i:=0 to 65535 do for j:=0 to 15 do write(f,mem[i,j]); or similarly. But how can be done this in Windows?

Pianoman----- Original Message -----
From:
To:
Sent: Thursday, April 28, 2005 12:00 PM
Subject: fpc-pascal Digest, Vol 8, Issue 26

inner-working

these

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndebug/htm l/msdn_debugEH.asp

Hello Pianoman,

Thursday, April 28, 2005, 1:44:43 PM, you wrote:

P> Yes, this is interisting but I'd like for example to create a memory image P> of some part of ram to see exactly what is there. In old dos days it was P> possible to do like for i:=0 to 65535 do for j:=0 to 15 do P> write(f,mem[i,j]); or similarly. But how can be done this in Windows?

Here's an excerpt from WinAPI reference:

=== cut ===
The ReadProcessMemory function reads memory in a specified process. The entire area to be read must be accessible, or the operation fails.

BOOL ReadProcessMemory(

HANDLE hProcess, // handle of the process whose memory is read LPCVOID lpBaseAddress, // address to start reading LPVOID lpBuffer, // address of buffer to place read data DWORD cbRead, // number of bytes to read
LPDWORD lpNumberOfBytesRead // address of number of bytes read

   );

Parameters

hProcess

Identifies an open handle of a process whose memory is read. The handle must have PROCESS_VM_READ access to the process.

lpBaseAddress

Points to the base address in the specified process to be read. Before any data transfer occurs, the system verifies that all data in the base address and memory of the specified size is accessible for read access. If this is the case, the function proceeds; otherwise, the function fails.

lpBuffer

Points to a buffer that receives the contents from the address space of the specified process.

cbRead

Specifies the requested number of bytes to read from the specified process.

lpNumberOfBytesRead

Points to the actual number of bytes transferred into the specified buffer. If lpNumberOfBytesRead is NULL, the parameter is ignored.

Return Value

If the function succeeds, the return value is TRUE. If the function fails, the return value is FALSE. To get extended error information, call GetLastError.
The function fails if the requested read operation crosses into an area of the process that is inaccessible.

Remarks

ReadProcessMemory copies the data in the specified address range from the address space of the specified process into the specified buffer of the current process. Any process that has a handle with PROCESS_VM_READ access can call the function. The process whose address space is read is typically, but not necessarily, being debugged.
The entire area to be read must be accessible. If it is not, the function fails as noted previously.

See Also

WriteProcessMemory
=== cut ===

On Thu, April 28, 2005 13:52, Alexey Pavluchenko said:

.
.

Alternatively, you can create shared memory area (memory mapped file) - see e.g.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/creating_named_shared_memory.asp for Win32 API example.

Tomas

[ Charset ISO-8859-1 unsupported, converting... ]

Yes, this is interisting but I'd like for example to create a memory image of some part of ram to see exactly what is there. In old dos days it was possible to do like for i:=0 to 65535 do for j:=0 to 15 do write(f,mem[i,j]); or similarly. But how can be done this in Windows?

Not like this. There are some ways via win32 api calls probably, but these are probably privileged (requires adminstrator rights)

I'd search for "physical memory access" or so on MSDN.

Subject: Re: [fpc-pascal] FPC and Memory
To: FPC-Pascal users discussions
Date sent: Sun, 1 May 2005 12:27:30 +0200 (CEST) From: (Marco van de Voort)
Send reply to: FPC-Pascal users discussions

Although I'm no Win32 programmer, I'd expect that "physical memory access" should be only possible from drivers (and that wouldn't help here anyway, because one doesn't know the real "physical memory address" used by the other process). Accessing memory of another process (without special support in this process) is probably only possible through the debugging API mentioned by somebody else (which needs NT privilege for debugging). Another (IMHO better) alternative could be by using shared memory (allocated as such in the "monitored" process), or by providing hooks in the monitored process for enquiring the current status. These hooks could be provided by having a dedicated thread in the monitored process listening for requests sent through a named pipe (local only, very easy to setup) or a TCP/IP socket (allows remote monitoring too, but somewhat more overhead).

Tomas