Prev: Adding reference to netmodule; vbc al
Next: Bundling VB Files?
From: Karl E. Peterson on 27 Jul 2010 15:11
5k3105 pretended :
> On Jul 27, 12:14�pm, Karl E. Peterson <k...(a)exmvps.org> wrote:
>
>> Define "base address" as you use it. �In Win32, all processes have a
>> 4gb virtual address space. �So the quick/dirty answer would be 0x0 in
>> that case.
>
> Hi Karl,
>
> I'm using an emulator program called winvice to emulate the commodore
> 64. I want to be able to read and write to it's memory space while
> it's running in the emulator.
>
> From my reading I think I need to get the hWND or window handle and
> this number may be the base address of the section of memory that
> program is using (winvice). From there I will add another offset to
> find further the base address of the emulated computer's 64k by
> experiment.
>
> I imagine if I boot the program from vb maybe it will return the
> address I can use, like:
>
> BaseAddress = StartProgramFunction("C:\winvice.exe")

Well, I honestly don't know anything about that emulator, but the last
line is a bit spooky. I really don't think you can start another
application and have it run within your own application's address
space. That's, in VB speak, like an in-process DLL. Not likely. So
it will naturally have its own virtual address space, and you'll get
spanked something nasty if you try accessing that. These are exactly
the sorts of things that Win32 tried to save us from, as they were so
common under Win16. Sorry to be the bearer of bad news, but unless I'm
really missing the boat on all this, I think the whole notion just
isn't gonna fly.

--
..NET: It's About Trust!
http://vfred.mvps.org


From: 5k3105 on 27 Jul 2010 16:00
On Jul 27, 2:05 pm, ralph <nt_consultin...(a)yahoo.net> wrote:

> Peeking or reading the memory of another process is relatively easy.
> (Easy compared to trying to Poke or write into another process, that
> is. <g>)
>
> Take a look at this article:http://www.codeguru.com/vb/gen/vb_system/win32/article.php/c7525
>
> You'll have to do some further searching on how to Poke. (I'm not even
> sure it can be done - although there is nothing truly impossible in
> programming.)


http://www.xbeat.net/vbspeed/i_VBVM6Lib.html

and

http://edais.mvps.org/Tutorials/Memory/Memch2.html

If this CreateProcess function returns the base address of the process
I send to it, this will be what I need. I will test. Thank you.


From: dpb on 27 Jul 2010 16:17
Karl E. Peterson wrote:
....

> ... I really don't think you can start another
> application and have it run within your own application's address
> space. That's, in VB speak, like an in-process DLL. Not likely. So it
> will naturally have its own virtual address space, and you'll get
> spanked something nasty if you try accessing that. These are exactly
> the sorts of things that Win32 tried to save us from, as they were so
> common under Win16. Sorry to be the bearer of bad news, but unless I'm
> really missing the boat on all this, I think the whole notion just isn't
> gonna fly.

I'm thinkin' the same thing, Karl...he's going to spawn another process
I'm virtually certain and won't have access to it owing to OS saying
"not yours!"...

--

From: Thorsten Albers on 27 Jul 2010 16:36
5k3105 <christianlott1(a)yahoo.com> schrieb im Beitrag
<76cd3d0c-b0ba-44b4-b52d-5f51f7563567(a)x13g2000vbe.googlegroups.com>...
On Jul 27, 12:14�pm, Karl E. Peterson <k...(a)exmvps.org> wrote:
> I'm using an emulator program called winvice to emulate the commodore
> 64. I want to be able to read and write to it's memory space while
> it's running in the emulator.
>
> From my reading I think I need to get the hWND or window handle and
> this number may be the base address of the section of memory that
> program is using (winvice). From there I will add another offset to
> find further the base address of the emulated computer's 64k by
> experiment.
>
> I imagine if I boot the program from vb maybe it will return the
> address I can use, like:
>
> BaseAddress = StartProgramFunction("C:\winvice.exe")

The instance handle of a process (VB: App.hInstance) is a pointer to the
binary image of the executable of the processes in memory. But the only
thing which is sure is that the memory allocated dynamically by the process
is located at memory addresses somewhere behind (or 'above') the last
memory address used by the binary image.
A window handle has >>no<< relation to memory of the process.

In your case it wouldn't be of much use to get the 'memory address' of the
emulator because simply it is an emulator, i.e. it emulates another machine
with its special memory peculiarities. The game's code and data are
located somewhere in the virtual address space of the emulated machine the
code and data of which is located somewhere in the virtual address space of
the emulator which emulates the machine. In other words: The emulator
process is a Win32 application the virtual memory space of which can be
accessed with Win32 API procedures (although it is difficult to do this
from another process since both the emulator process and your own VB
application process have a virtual memory space of their own, as has been
explained by the others in this thread). But the game itself isn't a Win32
process, it is a 'C64 process' running on the virtual machine emulated by
the emulator process.

If you want to manipulate the memory of the game running in the emulator
you should use the method provided by the emulator to do so - and usually
emulators do provide such a method. In the times of the old home computers
such a method usually was called a 'monitor' which allows to save parts of
the virtual machine's memory, fill it, clear it, dissassemble it and so on.
Usually there is a hotkey which has to be hit to enter the monitor while an
application is running in the emulator. AFAIK WinVice has a built in
monitor.

--
Thorsten Albers

albers (a) uni-freiburg.de

From: Mike Williams on 27 Jul 2010 16:40
"dpb" <none(a)non.net> wrote in message
news:i2nf34$r87$1(a)news.eternal-september.org...

> I'm thinkin' the same thing, Karl...he's going to spawn another
> process I'm virtually certain and won't have access to it owing
> to OS saying "not yours!"...

Many years ago (too long to remember!) I used to do stuff like this on
admittedly much simpler machines like the Oric and the C64, but I think it
is still possible (although much more difficult) to do it on modern PCs. In
my day there were two main basic methods. One was to modify the game code
itself before the game was run and the other was to modify the contents of
the memory addresses it used to store various data items at runtime. It was
very easy many years ago on simpler machines, but I am far too long in the
tooth now to even consider delving into how it can be achieved on modern
PCs! A dedicated game hacking group would probably be the best place to look
for such stuff. A very quick 'Google' turns up the following site, which
seems to indicate that it can be done on modern PCs using Visual Basic, but
I don't know any of the details:

http://www.freakitude.com/2006/10/22/how-game-trainers-work/

Mike



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Adding reference to netmodule; vbc al
Next: Bundling VB Files?