[RuneLancer]

Aha! Perfect! That's exactly what I was hoping. :)

Here's the C solution. Sorry, this is off the top of my head, so the syntax for malloc may be off a little... Some debugging will be required. ;)

[DeveloperX]

[RuneLancer]

Ohhh, now I get it. That's a lot more complicated than you'd think, frankly. I only know how to do it via Windows, as it involves some stuff with the API. To be fair, I've only done this on Win98, and I don't know if XP has any further protections that would disallow this sort of thing. I wrote a trainer for FF3 running under SNES9x in VB quite a while ago which did some basic stuff like monitoring some values and freezing others.

First, you should know that different processes run in their own "bucket" of memory, seperate from the others. You can't just attempt to access another process's memory or Windows will throw an error your way and most likely crash your program for attempting to do something it didn't have permission to do. So you need to grab a handle to the application you want to read from in order to mess around with it.

hWnd = FindWindow(NULL, "Window Name");

This function returns a handle to the application with the name "Window Name" as a window name. There's also (name may be a little off...) GetWindowFromPoint or something like that which allows you to specify a point onscreen and returns the handle to the window there.

GetWindowThreadProcessId(hWnd, &pID);

This returns the thread process ID of the window you selected. Once you have this, you can tell Windows which thread you want to access.

hProcess = OpenProcess(PROCESS_ALL_ACCESS, 0, pID); //Note sure if that's the right constant name... I'm copying this from my VB trainer. :P

Here, you basically tell Windows you want access to a process to do stuff with it. You have to pass a flag telling it what kind of access you're looking for, a boolean telling wether the handle is inherited or not, and the process ID you got from GetWindowThreadProcessID.

WriteProcessMemory(hProcess, Address, &Value, Len_To_Write_In_Bytes, &x);
ReadProcessMemory(hProcess, Address, &ReturnValue, Len_To_Read_In_Bytes, &x);

Either of these will return how many bytes were actually written/read in "x".

Finally, make sure you release the process!

CloseHandle(hProcess);

Last but not least, ALWAYS check stuff before every step. Make sure you DID grab a handle from something before using it. Yeah, yeah, common sense, I know, but it bears mentionning. :)

Give MSDN a look if you want more info on these functions. Dunno how you can get it to work in console though, as the Win32 API isn't accessible then. Or on another OS, but as this is an OS-specific issue, using the API would probably fail even if you could. ;P
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[DrunkenCoder]

@DevX: If you had any sort of clue you would quite quickly realize that all the "ports" are basicly correct but that your understanding with the architechture you're working with is flawed. Basicly the code you have in QB is working under something that's called realmode a 20bit segmented memory model and if you're looking to make a straight port you'll need to dig up some ancient C compiler (I've heard that Borland Turbo C v2 or 3 is available online from their museum) that can complie to such target. Then you'll have to look at the compiler specific extensions to handle the segmented memory model, in the TC case it's the added keyword "FAR" and MAKE_FAR_PTR (or something very similary 6years since I used it).

If you're trying to compile it under anyother enviornment than plain dos without a dos-extender then basicly you'll have to rethink your approach since you're then likely in protected mode, even worse you could be under a proper OS (NT based Windows or *nix derivate/clone) that implements memory protection specifically aimed at not letting you trample the memory of other processes.

And in that case RuneLancer gave you some nice pointers, the problem is that physical memory address have very little todo with whatever memory addresses gets mapped into your process.

LordGalbalan is correct under some very very pecuilar circumstances like home-rolled memory extenders for dos or home brewn OS's without virtual memory and things like that.

Basicly your problem is that you'll have to consider your target architechture when porting code and if you're aiming to use silly unportable memory tricks from Qb then you'll simply have to stay stuck in the DOS days.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[DeveloperX]

DC: Oh.
I see.
Alright, well, this topic is closed then.
Sorry about all this, it makes sense now. :D
I forgot about the realmode /protectedmode thing, as I have only read about it in 1 of my books, and that book got left behind in LA. :P

Oh well, theres more fun things I can find to code. :D
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio