Home       Imprint / Impressum Select Color Scheme 
 
 
My Other Sites
myrotacol.net
mail-erinnerung.de
pdadmin-forum.de
wohnzimmerhosting.de
mydxs.de
Fischerseiten  german text
Fischerprüfungen
Angeln in den USA
Oak Island  german text
Wo liegt Oak Island?
Geschichte
Das Geldloch
Fotos
Links
Kombucha  german text
Was ist Kombucha?
Eigenschaften
Herstellung
Bezug
Häufige Fragen (FAQ)
Links
Proxy-Dll Concept
Introduction
The Concept
Realisation
HowTo 1
HowTo 2
References
Users' Contributions
Downloads
 
Realisation
-- Section: Proxy-Dll --

We focus on DirectX8/9 3D calls here. This said, we need to create a d3d8.dll (d3d9.dll) that will be called by the application instead of the "real" (system-provided) library.

Note: For testing the proxy-dll, I used Krakout-Arkanoid (DX8) and Flatspace Demo (DX9), amongst others. Both are nice games, and they were at hand that time. For debugging purposes, DebugView is a nice tool. Ah, and check out dependency walker for the examination of dlls.

First, let's take a look at an application that uses DirectX 3D calls. It enables D3D support by loading the d3d8.dll, then obtains the IDirect3D8 interface via Direct3DCreate8 and creates a IDirect3DDevice8 with CreateDevice).

If we can manage to get our d3d8.dll/d3d9.dll loaded by the application, thus getting the call to Direct3DCreate8/Direct3DCreate9 redirected to our code, we could create a IDirect3D8/9 Interface object by ourselves. Same goes for the IDirect3DDevice8/9 Interface. We would then offer all funcionality like the original objects to the caller's code (in fact just redirecting every call to a IDirect3D/IDirect3DDevice we secretetly created of our own).
This gives us the possibility to change data and/or add new things.

How the proxy model works...

Any drawbacks on that ? Yes.

Normally, an application looks for a dll within its working directory first, then browsing the system's path. Applications may prevent that by directly targetting the system directory. And we can't just replace the system's d3d8/9.dll, as we need its functions as described above (btw., I strongly advise to not touch the original system dll. You may screw your DirectX installation).

Furthermore, an application might implement its own e.g. texture manager (or even use undocumented calls). As we will not be able to handle such calls (obviously), the app would possibly not work with a proxy-dll.

Finally, we know what we need...

  • a file named d3d8.dll/d3d9.dll that will be placed within the application's working directory (and hopefully get loaded by the app).
  • a function named "Direct3DCreate8" being exposed by that dll ("Direct3DCreate9" respectively).
  • an interface provided by the dll that exactly looks the same as the "real" IDirect3D8/9 interface
  • an interface provided by the dll that exactly looks the same as the "real" IDirect3DDevice interface
Luckily enough, some header files that come with the DX SDK point out what calls should be handled by our "faked" interfaces.

So, my "basic proxy-dll" implementation consists of

  • global routines for the dll handling (entry point, load the system d3d8.dll/d3d9.dll, and so on)
  • an object called myIDirect3D8/9, derived from Direct3D8/9, exposing over a dozen functions
  • an object called myIDirect3DDevice8/9, derived from IDirect3DDevice8/9, exposing about 100 functions
Basically, all functions within the "my..." objects pass parameters on to the original system dll, providing the possibility to change or add data. A few routines need special attention though.

Release (both Objects)
In case the application releases the interface (and no more references are present), we destroy our own object as well.

QueryInterface (both Objects)
If the application queries for certain interfaces, we do of course pass the address of our very own routine, not passing the system-dll response this time.

myIDirect3D8/9::CreateDevice
Once this is called, we create our own D3DDevice (internally), as we need it to process the application calls. Then, we respond in sending our own object's address.

For testing purposes, the function myIDirect3DDevice8/9::ShowWeAreHere was added. It is called within myIDirect3DDevice8/9::Present and does nothing but create a yellow rectangle in the upper left screen. This might give you an impression of how to add own content. Drawing own real 3D Objects is possible as well, believe me (if you can handle the application-internal world coordinates, hehe).

[Update 4/22/06]
Tests on recent games show that some of them (like Tomb Raider - Legend) use IDirect3DSwapChain9::Present for showing their screens, never calling IDirect3DDevice9::Present (as e.g. World of Warcraft does).
Obviously, a proxy-dll has to cover IDirect3DSwapChain9 then, too. An updated code example has beed submitted to the downloads page. Check for the Basic d3d8/9.dll Implementation section.

Next: HowTo1

 
Computer
ChartLinkCreator
TokenBuilder (3DGS)
HexMapCreator
Well-o-Mat  german text
Building a Webserver
Game Tools List
DXStudio Goodies
GetKeyState Plugin
Cryptor Plugin
Particles2D Plugin
Utility Plugin
DXSTwitterListener
DXSPather DLL
Summer'09 Competition
DXSCheckMem DLL
pnpTC DXMesh plugin
Turnipmaster Online
L3DT DXMesh plugin
Embedding and Enet
Multiplayer Test App
Tokenbuilder Redux
CannonModule
Models/Renders
Robot Model
Winebarrel Model
Cigarette Box Model
Remote Control Model
Irrlicht3D Goodies
CGUIexScrollWindow
CGUIexChatWindow
ChaseMe: Demo Game
My Project Skeleton
MikoChess: Test Game
 
 

miko-cms v5/2009  |  http://validator.w3.org/check/referer  |  admin