Yay! This project is moving
just fyi, things are moving. Thanks to lostreception who is helping me out a lot.
Looking forward too this DLL
the dll wont be a problem. Still trying to figure out a way to calculate where your speed is without too much work on the user's end. Using a new app I wrote we were able to locate a byte that indicates whether or not the speed is in fact the speed...and not a random thing jumping around. I assume its some kind of boolean. But its at an offset of 3 bytes before the byte location of the speed.
need a vote, should the dll read an ini file, or should it just accept raw commands example, Speed = readByte("IGuidance",12FA64), or should it be Speed = readByte(iniSpeed) ?
peoples we both know that the value changes in different versions of windows whos to say the next vers of IG wont have a diff addr as well
i think rather than hard coding it the ini is the best option. who knows about media center ot 2k3 or Vista. one extra step will make it that much easier to fix down the line i think
Im no expert at assembly, but isnt it true that variables with memory locations moving around have to be dynamically assigned? If thats the case then there should be a pernament memory location that holds the pointer to the speed location. Have you tried looking for that?
But like I said, im no expert, if I was I would be finding the pointer myself.
well, i wouldnt hardcode the values in here anyway.
My question is this. Should the dll read an ini with a list of values, or should the 3rd party app do this. My DLL is going to be very basic.
All it is really is a dumbed down API call to peek memory values.
If someone is going to write a program using this dll, are they going to want to specify an ini argument ex:"igudiance","speed" or are they going to read from the ini themselves and send the full raw address?