Reading Game Memory is Slow! Looking for advice.

[Cypher]

My bad. Misread the API.



Also applies to 32-bit apps running on 64-bit windows. I'm intentionally running 32-bit Wow.exe because many more people are digging through it for offsets, etc., not to mention the fact that it makes the simple and fast caching scheme described above possible.

I'm pretty sure that's incorrect. Like I said, for 32-bit software running on 64-bit Windows, it has access to the entire 4GB address range, there is no "split".

Reference to prove I'm not (totally) crazy: Using /LARGEADDRESSAWARE on 64-bit Windows for 32-bit programs - The Old New Thing - Site Home - MSDN Blogs

I'll have to re-architect my system a bit and test out a few other tricks but I'm confident I'll be able to improve my overall system with this. Thanks again!



I'm still running 32-bit only because everyone can, but not everyone can run 64-bit. Unfortunately.

Huh? If you're running a 32-bit version of Windows then what ioctl is suggesting to you won't work, because you won't have enough VA space in your program. To do the caching that is being suggested you need a 64- bit version of Windows, a 64-bit bot/hack, and a 32-bit version of WoW.

Also, who are these people who can't run 64-bit software in this day and age? I want to find them and hurt them. x86 needs to die, and so does XP. I'm going to throw a damned party at work when I no longer have to support XP.

[ioctl]

I'm pretty sure that's incorrect. Like I said, for 32-bit software running on 64-bit Windows, it has access to the entire 4GB address range, there is no "split".

Reference to prove I'm not (totally) crazy: Using /8 on 64-bit Windows for 32-bit programs - The Old New Thing - Site Home - MSDN Blogs

Oh, interesting. Guess it depends on whether Wow.exe is /LARGEADDRESSAWARE. How to determine the appropriate page file size for 64-bit versions of Windows

[Torpedoes]

Huh? If you're running a 32-bit version of Windows then what ioctl is suggesting to you won't work, because you won't have enough VA space in your program. To do the caching that is being suggested you need a 64- bit version of Windows, a 64-bit bot/hack, and a 32-bit version of WoW.

I'm not quite going to implement the same thing until I apply a few other techniques first. I'm hoping that ioctl's full solution won't be necessary. I may also be completely wrong in which case you're right. But I'll need to run some benchmarks first.

Also, who are these people who can't run 64-bit software in this day and age? I want to find them and hurt them. x86 needs to die, and so does XP. I'm going to throw a damned party at work when I no longer have to support XP.

I'm still on the fence with this one. I no longer support windows XP but I feel it necessary to support 32 bit because I'm still under the impression that many people use 32-bit Windows. Perhaps I'm still living in the previous decade I don't know.

[Master674]

I'm not quite going to implement the same thing until I apply a few other techniques first. I'm hoping that ioctl's full solution won't be necessary. I may also be completely wrong in which case you're right. But I'll need to run some benchmarks first.



I'm still on the fence with this one. I no longer support windows XP but I feel it necessary to support 32 bit because I'm still under the impression that many people use 32-bit Windows. Perhaps I'm still living in the previous decade I don't know.

Take a look at china. They are mostly using 32 bit XP.

[Cypher]

Oh, interesting. Guess it depends on whether Wow.exe is /LARGEADDRESSAWARE. How to determine the appropriate page file size for 64-bit versions of Windows

It didn't used to be, but then people noticed and started patching the exe in order to allow the game to handle larger draw distances etc. After that they fixed it afaik. I don't have WoW installed anymore, but it's trivial to check with dumpbin, CFF explorer, etc etc. (Btw I mentioned the /LARGEADDRESSAWARE flag in my original reply to you. You may have missed it.)

Take a look at china. They are mostly using 32 bit XP.

Meh. They're also the demographic least likely to pay for your software (especially the ones running XP x86), so I can't say I'd feel bad about not supporting their pirated and unsupported (most of them still run SP2 I think, which is EOL, except that they use custom patches to keep it 'updated') OS configuration.

Unless you're feeling particularly charitable, or have a large customer who specifically needs such support, I wouldn't worry about it.

Each to their own though...

[Torpedoes]

Meh. They're also the demographic least likely to pay for your software (especially the ones running XP x86), so I can't say I'd feel bad about not supporting their pirated and unsupported (most of them still run SP2 I think, which is EOL, except that they use custom patches to keep it 'updated') OS configuration.

Unless you're feeling particularly charitable, or have a large customer who specifically needs such support, I wouldn't worry about it.

Each to their own though...

You know, you've made an excellent point. I think I will transition to 64-bit. Thanks!

[Master674]

Meh. They're also the demographic least likely to pay for your software (especially the ones running XP x86), so I can't say I'd feel bad about not supporting their pirated and unsupported (most of them still run SP2 I think, which is EOL, except that they use custom patches to keep it 'updated') OS configuration.

Unless you're feeling particularly charitable, or have a large customer who specifically needs such support, I wouldn't worry about it.

Each to their own though...

Thats a perfectly valid point but with the XP support in new MSVC 120 compiler it's not really any overhead to support it.

[_Mike]

Thats a perfectly valid point but with the XP support in new MSVC 120 compiler it's not really any overhead to support it.

The overhead is that you need to have XP machines for testing and product support. You also can't use any new api calls that doesn't exist in XP.