Visual Studio 2008
-
Hey guys, just wanted to ask around, does anybody got a major issue with the next FLHook Plugin version being compiled with Visual Studio 2008 (vc9) ?
I think plugins that use FLHook imports need to be compiled with the same visual studio version, thats why Im asking.
Id really like to get rid of VS 2003 because its a bit dated
-
There was an issue with ShipDestroyedHook(), crazy had server crashes because of it afaik (I did not on my vista system ^^). The dll also gets a lot of bigger for an unkown reason (yet). You also had to change the rights queried at readprocmem and writeprocmem (for details ask crazy or cannon).
-
As far as I remember none of the hooks worked so he asked Cannon and he gave him the changes, which were```
HANDLE hProc = OpenProcess(PROCESS_VM_OPERATION|PROCESS_VM_WRITE|PROCESS_VM_READ, FALSE, GetCurrentProcessId());I don't know why, I guess Cannon does. -
I think there is a compatibility issue with the plugins compiled under 2003 and flhook under 2008. I haven’t looked at this closely. I’m happy to recompile and release of all my plugins for 2008 in any case.
There are quite a few warnings generated by 2008 when the flhook svn head is compiled. These are mostly related to casting of unsigned short * to wchar_t*.
I also suspect I’ll need to rewrite some of the hooks I’ve written because I was lazy and didn’t use naked functions. These hooks work okay under 2003 but will possibly fail under 2008 because 2008 might use a different function prolog.
-
Schmackbolzen wrote:
As far as I remember none of the hooks worked so he asked Cannon and he gave him the changes, which were```
HANDLE hProc = OpenProcess(PROCESS_VM_OPERATION|PROCESS_VM_WRITE|PROCESS_VM_READ, FALSE, GetCurrentProcessId());I don't know why, I guess Cannon does.Thanks for the info, that makes sense looking at the OpenProcess MSDN page
This is a nasty bug, having the OpenProcess function only fail on XP/Win2003 …
-
Don’t know if you wizards can do anything about it but FlakCommon still hates Windows 7 a lot (tested on 7 RC1 x64) and crashes systematically before even finishing to load the server.
-
flak_common really needs to be updated…it has old code that isn’t used in Flak’s FLHook anymore and is in general pretty out of date. I suspect that when I do get around to updating it and the rest of the plugins that rely on it the problems will go away (since Flak’s FLHook doesn’t crash on Win7 as far as I know).
As for switching to VC2008…well I just got it installed about a week ago and haven’t had a chance to use it. As long as it’s stable I shouldn’t have a problem with it. I did have seemingly random crashes (didn’t seem to be related to dying at all) with Crazy’s VC2008 FLHook build though, and I’m running XP Pro.
-
Moved this topic to public discussion, no reason for this in a protected area.
There was an issue with ShipDestroyedHook(), crazy had server crashes because of it afaik
I just had the same problem and I figured out whats happening:
http://msdn.microsoft.com/en-us/library/1deeycx5.aspx
It would cause the line
try { dmg = *_dmg; } catch(…) { return; }
to not catch the access violation exception, using /EHa fixes this. -
**Just as long as you fix those for(int i… code you made, they are not kosher with 2005 or 2008. I fixed those in the version Im using but dont know if you fixed them in yours…
Variables are supposed to be defined at the start of a routine, not in a loop, no offence intended…**
-
Just FYI: Ive now completely switched to VC9 and the next official binary will be compiled with VC9 I guess.
Also, Im currently hooking the outgoing network interface (meaning outgoing packets can be intercepted or you can send out packets on your own). So stay tuned
-
Lancer Solurus wrote:
Variables are supposed to be defined at the start of a routine, not in a loop, no offence intended…
No, variables need to be defined in the way they are used and with less accessibility as possible. That keeps the source clean as well as memory usage of the program.
To define variables in loops is valid and a common way in C++ whereas in C this is not allowed…Anyway - using VS9 will change the linkage, probably the optimizers are working better. Could be that the the new linkage may - but must not - affect the execution program (in this case a dll). What i do not know by now - is it compatible with 64bit, previous versions of Windows? Do all clients need to update their systems so the new vcredist is installed as well?
Just asking those questions although i dont use it - thought one of those question might be for interest for some others
-
Cannon wrote:
I think there is a compatibility issue with the plugins compiled under 2003 and flhook under 2008. I haven’t looked at this closely. I’m happy to recompile and release of all my plugins for 2008 in any case.The compatibility issue is, I believe, because VC2008 considers wchar_t to be a built-in datatype while VC2003 doesn’t. If you disable this in the project properties (C/C++ -> Language -> Treat wchar_t as Built-in Type) then the existing plugins compiled with VC2003 will probably work. And you won’t have to explicitly cast unsigned short* to wchar_t*.
