The Gamehacking Foundation Classes [GHF]

Page 1 of 2

05/20/2010 00:20 MrSm!th#1

Hello everybody,
I am working at a little bigger project called the GHF (Gamehacking Foundation).
It is a (hopefully soon) big compilation of classes that are usefull for gamehacking (detours, memory writing, botting, etc...)

It is written in C++ with Visual Studio 2010 (because I want to make well designed classes, I could need some guys with a good programming style); it should be completly object oriented.

There are also a few little (easy to make) Makros and defines to make programming in general easier.

If you know at least the basics of object oriented programming in C++ (better is a good knowledge) and you are interested, it would be very nice, if you post here.

Atm, the GHF only consists of the GHF Base and a almost-done Detours class.

The current source is in the attachment.

Infos in the master header:

Spoiler

I hope, you will download the source and give me some feedback ;)

05/20/2010 06:04 Nullable#2

Sweet project, I'm looking forward for this.
And about the style since you're using MSVS, what about using properties for getting/setting variables?

05/20/2010 09:12 Chippu#3

Hee. Good luck with that. Hope it goes well.

05/20/2010 13:57 MrSm!th#4

Nullable, what do you mean exactly by this?

05/20/2010 13:59 Adroxxx#5

using getter and setter functions is a very bad coding style.

05/20/2010 14:02 MrSm!th#6

Quote:

Originally Posted by Adroxxx

using getter and setter functions is a very bad coding style.

yes? o.O

I read, that public variables are bad and getting/setting methods are the right way.
So please tell me, what would be better?

05/20/2010 15:29 Nullable#7

Quote:

Originally Posted by MrSm!th

Nullable, what do you mean exactly by this?

For ex. instead of calling setHookType and getHookType, you would add a public variable that will call them, looks like this:

Code:

__declspec(property(get = getHookType, put = setHookType)) int HookType;

Where using the var as follows:

Code:

GHFHook.HookType = 1;
int Type = GHFHook.HookType;

Will call the get/put functions and return/update the private variables.

Quote:

Originally Posted by Adroxxx

using getter and setter functions is a very bad coding style.

Provide facts please.

05/20/2010 15:49 MrSm!th#8

Quote:
Originally Posted by Nullable
For ex. instead of calling setHookType and getHookType, you would add a public variable that will call them, looks like this:
Code:
__declspec(property(get = getHookType, put = setHookType)) int HookType;
Where using the var as follows:
Code:
GHFHook.HookType = 1;
int Type = GHFHook.HookType;
Will call the get/put functions and return/update the private variables.

lol and where exactly is the sense?
i dont see any reason, why i should make a new variable, so the return goes over 3 points (variable -> function -> return)
and i didnt know, that the propperty keyword is also available in c++

Quote:

Provide facts please.

[Only registered and activated users can see links. Click Here To Register...]

they provide access to the implementation ;)

but i think, Detour is one of the situations, in which getters/setters are unavoidable. it is not really an implementation detail, but an important information for the user (how should i hook without access to the target?)

getters/setters are supposed to be replaced by methods that let the object do the work itself (at the website, the example is a GUI system and a getter called getAttribute (of course, if the drawing method is in the object, a getter is not necessary)), but a detour cant set the target itself.

and btw. c++ is not completly object oriented :p

05/20/2010 15:56 Nullable#9

Quote:

Originally Posted by MrSm!th

lol and where exactly is the sense?
i dont see any reason, why i should make a new variable, so the return goes over 3 points (variable -> function -> return)

I'm not 100% sure about the mechanism but from what i learned is that the variable used is nothing but an image to the getters/setters, so it doesn't really go variable -> function -> private variable(the compiler kind of translates it to a function call, it's only used for increasing the readability of the code which is - according to my beliefs - vital.)
EDIT: Actually after reading the documentation, it is correct that any reference to a property is translated to a function call, reason why it can be used is 1 line above :P.

Quote:

Originally Posted by MrSm!th

and i didnt know, that the propperty keyword is also available in c++

It's only supported in MSVS.

Quote:

Originally Posted by MrSm!th

they provide access to the implementation ;)

I don't really see why getters/setters shouldn't be used in this case, since using getters/setters would actually help a lot in this case, since you can simply change code implementation inside the getter/setter without worrying about other classes that might as well use the variables.
However when refreshing the private variable comes at expensive costs, using public variables would be the only solution, and setters would be merely for refreshing the variable.
Also I don't see the logic behind sticking to the rule and accept it as a holy rule that should be followed at all costs, people forget about the intentions behind this rule.

05/20/2010 16:13 MrSm!th#10

Quote:

Originally Posted by Nullable

I'm not 100% sure about the mechanism but from what i learned is that the variable used is nothing but an image to the getters/setters, so it doesn't really go variable -> function -> private variable(the compiler kind of translates it to a function call, it's only used for increasing the readability of the code)

hm, ok, this is your opinion.
i find it more difficult to read ;)

Quote:

I suppose only in MSVS, didn't have any luck with Dev-C++ :)

ah ok

Quote:

I don't really see why getters/setters shouldn't be used in this case, since using getters/setters would actually help a lot in this case, since you can simply change code implementation inside the getter/setter without worrying about other classes that might as well use the variables.
However when refreshing the private variable comes at expensive costs, using public variables would be the only solution, and setters would be merely for refreshing the variable.
Also I don't see the logic behind sticking to the rule and accept it as a holy rule that should be followed at all costs, people forget about the intentions behind this rule.

That's what I said ;) In this case, at least the setters are unavoidable!

05/20/2010 16:29 Nullable#11

Quote:

Originally Posted by MrSm!th

hm, ok, this is your opinion.
i find it more difficult to read ;)

I guess it is just a matter of opinions here since style isn't really affected :p.
Again, good luck with the project. I will be willing to help with anything i can help with. :)

05/20/2010 17:23 Bot_interesierter#12

You should use an enum for your hook types instead of those #define macros, one should avoid using macros if possible.
And your class design is somewhat wacky, do you think creating a class instance for every new hook is a good idea? Wouldn't it be a much better approach to create a singleton class that keeps all your hooks in a container?
And btw, the whole if defined MSVC stuff is pretty pointless since you're already using an #ifdefined macro to prevent multiple includes of your header.

05/20/2010 17:54 high9#13

Would help but I can't stand VS 2010's cleartype bullshit.

05/20/2010 19:08 MrSm!th#14

Quote:

Originally Posted by Bot_interesierter

You should use an enum for your hook types instead of those #define macros, one should avoid using macros if possible.

Yeah, thought that also ;)
These defines were my first idea, in my new version, it is an enumaration.

Quote:

And your class design is somewhat wacky, do you think creating a class instance for every new hook is a good idea? Wouldn't it be a much better approach to create a singleton class that keeps all your hooks in a container?

I thought about that, too.
Maybe I will add this, first a GHF_Detour object should represent one hook.

Quote:

And btw, the whole if defined MSVC stuff is pretty pointless since you're already using an #ifdefined macro to prevent multiple includes of your header.

1. pragma once makes the compiler open the file only once (files with include guards are always opened), so the process of compilation takes less time
2. I tried to use Include Guards only already, but they didn't work.... I just read about that and it seems that it worked, but I had an error in reasoning and so it just didn't work like I had expected it.
But there is still reason 1 ;)
Hmm....maybe I will delete pragma once again, but this little thing is not very important atm.

05/20/2010 19:49 high9#15

Make sure that you can unhook without deleting the detours instructions. It annoys me that with ms detours you cannot remove a detour inside the detour because it removes the instructions.

Page 1 of 2