cannon wrote:Sorry about bringing back a very old thread. I'm writing a direct play emulation layer for a different game. I notice the download link in the first post is dead and I was wondering if anybody still has a copy of it and could share it.
Of course I have it. But it won't help you much cause it's not including the source (I ofc have just as well).
What game you're working on? Is it Risk?
What's your intent with it? It's actually easy to write a layer like this but if you want to adapt it to a new network engine, why not supporting botf?
Let me summarize how you do a simple layer. Most important is the interface of the dll you want to hook in. For directplay there's a defined interface that only got extended for later versions, at least before of the managed code. Later DirectPlay got completely dropped by Microsoft and sadly they just kept some documentation on the managed code interface.
However there are still tutorials, api-references and sdk copies lurking in the web. First you need to find out which version you need / is in use by the game you're working on. 2nd you should learn how to use the DirectPlay interfaces, e.g. by a tutorial like this:
http://www.gamedev.net/reference/progra ... efault.asp.
For BotF, using DirectPlay 6 or 7? Something in between? Nm, I used this source:
http://www.vbgamer.de/cgi-bin/loadframe ... ctx7.shtml (german) as API reference. They also offer the old SDK for download, it helps alot to have the source.
So when you know the interface and know how it works, all you need to do is write a dll with a similar interface but name global functions different if you want to call the real ones inside your dll, else they'll conflict and cause compiler errors.
When renaming your exported functions, and also giving the dll a different name, you ofc also have to adjust the game exe to use your dll and your functions instead. If there are too many functions (not the case for directplay, but if there are), you could instead load the real directplay dll (dplayx.dll) dynamically and just rename the dll but not the functions you're using.
There are two ways exported functions get addressed in the dll, either by their exported order, or by their function name.
If their are addressed by their name you should keep same name length, that's a simple change. If it's by position it depends on the compiler you're using. For gcc exports are ordered alphabetically, so giving the functions an appropriate prefix is a simple solution.
If using gcc/MinGW like me and having to match function names, there's another issue I once solved by hexediting but is simpler to do using the --kill-at linker flag: By default, the gcc linker adds postfixes telling the argument sizes to the exported function names like "functionname@4@8".
And keep care of function declarations like WINAPI / __stdcall or __cdecl, cause else you'll cause stack overflows and stuff.
If you want to see what exported functions of the dlls get called by your game, I recommend:
http://www.dependencywalker.com/
Btw, for dpnemu, beside of dplayx.dll I also had to hook CoCreateInstance, CoInitialize and CoUninitialize of ole32.dll, so if ole32.dll is also in use for other things than directplay in the game you're working on, you might have a problem.
This should get you go, if you still need my dpnemu source as example I might search my disk.
P.S. wow, so much time passed by, why the hell do you have to bring up that old reminders right now?