UPDATED (2x): OpenSauce and Halo CE Crashing *PLEASE TEST FOR FEEDBACK*

[Heathen]

I have been slowly modifying the poll as the cases are resolved. I believe where it stands now is fairly accurate, unless you can refer me to a post I missed where someone who answered "no" got it working.

Nah, if you are watching I guess it should be accurate.

[Dwood]

Umm I can't even get Halo CE to load in the first place :/.

This is after a few months of not playing/starting it at all.

[jables]

 Operating System: Windows 7 Ultimate 32-bit (6.1, Build 7100) (7100.winmain_win7rc.090421-1700)
           Language: English (Regional Setting: English)
System Manufacturer: Gateway                         
       System Model: MD2614U                         
               BIOS: Rev 1.0                 
          Processor: AMD Turion(tm) X2 Dual-Core Mobile RM-72 (2 CPUs), ~2.1GHz
             Memory: 3072MB RAM
Available OS Memory 2814MB RAM

works

[.Wolfâ„¢]

Well i didnt get it to work..Probably something in the halo custom edition folder or something.

[Kornman00]

The method I want you to float your mind around is dll injection. Not only can you inject the dll whenever you want, but you can also eject it whenever you want without having risk of crashing Halo because it would no longer have a loaded d3d9 module to use. This will also make it easier to debug and test code, without having to keep opening and closing Halo to load the dll over and over. External injection can also be very noob friendly, just like a proxy would. It can be as simple as opening an executable that has no interface controls and loads it automatically when it finds the game. Building your own custom dll injector sounds awesome anyway, to me. You brought up the point of modifying Halos executable code to load your dll, but this is not necessary since injection from an external source is possible without needing to touch Halo's code. Therefor there would be no need to lug around patched executables, only an injector and your dll.

As far as changes to your own dll code, it would be significantly small and very little work. There are many different ways to hook Direct3D, but I will propose what I think is the most logical method in this situation, which would have to be VMT pointer modifications. Instead of detouring or creating an old fashioned jmp hook, you just replace Halo's VMT pointers with the addresses of your own functions. This has some advantages. The return can be a call to the original d3d9 function, so programs like xfire, gamecam, fraps, gcc can all still be hooked and running properly. Also, unhooking is just as easy as hooking and you don't have to unwrap the entire interface, only hook and unhook individual functions freely. There is a lot more flexibility here and the only thing you will need to keep track of is Halo's device pointer, which is global and static, but I'm not sure if it changes between CE versions or not. I bet you already have the version checking code, so you would just need to add this variable under that check. You could also pattern scan for the CreateDevice call, which returns the device pointer and grab the address from a relative offset, so a version check is not even needed. Alternately a less viable method is to inject immediately when Halo starts and hijack Direct3dCreate9 and then CreateDevice, but that shouldn't be necessary.

There are some downsides to this method, just like any method, but I think it's more reasonable than the current one. You will have to lug an injector around, but this is not a bad thing. It can be used universally to inject any dll into any process and only needs to be downloaded once. Injectors are all over the place, so if one does not work, there is one that will, they all have the same basic method of entry. So, like I said, keep an open mind as will I. I didn't bash your method to break your heart, but as constructive criticism to think about other possibilities. There seems to be many problems hovering around this proxy method and I am just offering my advice and will help where I can.

Dll injection wouldn't work with how Yelo works. Yelo has to process the game's code before it actually starts running any of its subsystems. There isn't a sure bet way of injecting before any of these systems become initialized to my knowledge.

Dll injection still runs the risk of crashing the game as much as a dll hook as its still the same code being ran. So if the code in a dll hook crashes the game, so will one which is just injected. If I wanted to support unloading the DLL, I would also have to write rollback functions to turn the game back into its original state.
Dll injection is invaisive compared to a behind the scenes dll hook. The user has to run an extra step to get the extension running. Anytime you increase the amount of steps a user must perform, you increase the complexity. Someone could easily forget to load it.

VMT modification only helps in the DX area. However, if I modify the DX vtables, then any hooks from other apps (xfire) are rendered null and could potentially crash due to some data not being gathered.

The only problem associated with the dx hook is with sapien, and thats only if they have the HEK installed to their game directory. Like I said earlier, I know how to adjust for this.

[Dwood]

Okay, so I got Open sauce to work.

Xfire didn't want to work with me when Open Sauce was on so there went that.
And second, when trying to join games, I can't join any others, because there aren't any displayed. Remove Open Sauce from the picture and it's fine.

------------------
System Information
------------------
Time of this report: 5/28/2009, 18:32:27
Machine name: ************
Operating System: Windows XP Professional (5.1, Build 2600) Service Pack 3 (2600.xpsp_sp3_gdr.090206-1234)
Language: English (Regional Setting: English)
System Manufacturer: MSI {really, a custom build, msi is mobo just fyi}
System Model: MS-7250
BIOS: Default System BIOS
Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, MMX, 3DNow (2 CPUs), ~2.0GHz
Memory: 3328MB RAM
Page File: 796MB used, 3904MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
DxDiag Version: 5.03.2600.5512 32bit Unicode

(Problem of Xfire solved however I am able to run without any others joining the map so I am choosing *yes* on the poll)

[supersniper]

Would modified haloceded.exe affect it?

[Skarma]

Dll injection wouldn't work with how Yelo works. Yelo has to process the game's code before it actually starts running any of its subsystems. There isn't a sure bet way of injecting before any of these systems become initialized to my knowledge.

Dll injection still runs the risk of crashing the game as much as a dll hook as its still the same code being ran. So if the code in a dll hook crashes the game, so will one which is just injected. If I wanted to support unloading the DLL, I would also have to write rollback functions to turn the game back into its original state.
Dll injection is invaisive compared to a behind the scenes dll hook. The user has to run an extra step to get the extension running. Anytime you increase the amount of steps a user must perform, you increase the complexity. Someone could easily forget to load it.

VMT modification only helps in the DX area. However, if I modify the DX vtables, then any hooks from other apps (xfire) are rendered null and could potentially crash due to some data not being gathered.

The only problem associated with the dx hook is with sapien, and thats only if they have the HEK installed to their game directory. Like I said earlier, I know how to adjust for this.

I see dx initialization ending with Yelo components initialization. Could you please explain the components a bit and how they work? Like what is it doing exactly? All these macros and typedefs are giving me a headache and I can't figure out what's going on where. I don't understand why Yelo has to initialize before Halo does, please explain so I know.

Um, all the crashes posted here are being related back to the dx hook. If it was updated or changed, there would be none, regardless of whether or not you changed any code other than the DX stuff.

Injection is not complex at all, as I explained it is very user friendly. The only extra step is opening an executable and possibly a press of a button. We are all capable of double clicking our browser icons to get to the web, so I don't see how this is much of a compared challenge. Ejecting is also very simple with a single API call, of course with a few simple checks to make sure the thread exits safely. I don't really understand your source very well, which is probably why I don't see where you are coming from and why you are being so defensive about your stuff here. If there is something that I don't seem to understand, please share! I'm not trying to be ignorant, I really would like information.

Last thing, you are not correct about vmt. I wasn't talking about modifying d3d9 module vtable. Halo has it's own device and vmt to d3d9. The method doesn't require even touching d3d9 module. All you are doing is replacing Halo's vtable pointers, so it's essentially an engine hook. So, for example let's assume Halo comes along to a Reset call, because I changed the screen resolution and let's assume I have replaced Halo's vTable Reset function pointer with my own Reset function. Well, Halo loads up ITS device pointer, then loads up the Reset pointer from ITS vTable(which is in the halo.exe space btw). It calls our Reset function, which returns by calling the original Reset function in the d3d9.dll module. Xfire has the original Reset hooked, so it must jmp to Xfires function, which returns to the original again and continues on it's normal path. There is no risk of crashing here, because Xfire and other d3d hooks do not mess with the games' device, only the d3d module. Replacing d3d9 module vTable pointers would not do anything, unless they were replaced before the game device was created, there would be no effect.

[Kornman00]

The components macros are just there to cleanly layout the function points to the initializer and disposer for each component. There are a couple variants of the macro since some components aren't for client builds or aren't for dedi builds, or should only be used in debug-only builds of the code. Using macros hides the component list's data initialization. Like said, some components don't run under certain conditions (ie dx is not under dedi), so instead of checking what build type is being used for each component, I only do it once at the macro definitions.
I don't mean to sound crude, but macros aren't really that hard to comprehend. Just look at the macro's definition and visualize replacing the macro's argument instances with what are passed to it when the macro is used. Its no different from learning how a function in source code works. Just with a macro, you can easily inline code statements. The same can't be done with inline functions as the function arguments are strict types and can't be reused and retyped. Where I only use one argument for the component macro, which then expands into a string, and then two function pointers, I would have to manually type out all three. Why would I do such a thing when I can have the preprocessor do it for me and also provide a mark up of whats going on while hiding the details?

The only halo related problems with the dx hook is with sapien. Xfire is third party.

And as I explained, using injection creates an extra step for the user. Note how CMT was arguing that just by having an extra dll that it creates a complexity with the user, even though it can be handled by an installer.

The code has to be ran before halo's does due to which code it modifies (at least in Update 2). If I wanted to do a late-bind injection I would have to go about disposing of most of the game resources, patching the code, then re-initializing the resources again. That means more code to write and more assembly to reverse equaling more time I have to spend on implementation details when I already have one that works and doesn't require user intervention.

Halo was written in C, there are no vtables in it's code. The device pointer they have is a pointer to what DX gives them, so you're not modifying halo's "vtable" entry for Reset and such as you're still modifying DX's memory. Using a DX dll hook, modification is implicit (plus all C++ code, no assembly tricks) as its just a interface proxy. Using your idea, I would have to create the patch code myself which allows more errors to be introduced and required debugging. I try working smarter, not harder without being too lazy in the process.
The bloom program and xfire are just convenience programs, they don't directly affect map development (xfire can be argued since some like to do these so called broadcasts). I'm not going to sit down and rewrite my code which has already been tested and works when I can be writing new code that end users can enjoy and potential OS developers can use.

[Love De Lux]

FAILED. Game exceptions on load! Got the same error report as Wolf.

------------------
System Information
------------------
Time of this report: 5/29/2009, 17:26:42
Machine name: ALEX PC
Operating System: Windows XP Home Edition (5.1, Build 2600) Service Pack 2 (2600.xpsp_sp2_gdr.090206-1233)
Language: French (Regional Setting: French)
System Manufacturer: n/a
System Model: n/a
BIOS: n/a
Processor: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+, MMX, 3DNow (2 CPUs), ~2.0GHz
Memory: 2048MB RAM
Page File: 695MB used, 2275MB available
Windows Dir: C:\WINDOWS
DirectX Version: DirectX 9.0c (4.09.0000.0904)
DX Setup Parameters: Not found
DxDiag Version: 5.03.2600.2180 32bit Unicode

Type de l'événement*: Erreur
Source de l'événement*: Halo
Catégorie de l'événement*: Aucun
ID de l'événement*: 1000
Date*: 28/05/2009
Heure*: 21:03:43
Utilisateur*: N/A
Ordinateur*: ALEX PC
Description*:
Faulting application haloce.exe, version 1.0.8.616, faulting module haloce.exe, version 1.0.8.616, fault address 0x0015b0f9.

Pour plus d'informations, consultez le centre Aide et support Ã* l'adresse http://go.microsoft.com/fwlink/events.asp.
Données*:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 68 61 6c ure hal
0018: 6f 63 65 2e 65 78 65 20 oce.exe
0020: 31 2e 30 2e 38 2e 36 31 1.0.8.61
0028: 36 20 69 6e 20 68 61 6c 6 in hal
0030: 6f 63 65 2e 65 78 65 20 oce.exe
0038: 31 2e 30 2e 38 2e 36 31 1.0.8.61
0040: 36 20 61 74 20 6f 66 66 6 at off
0048: 73 65 74 20 30 30 31 35 set 0015
0050: 62 30 66 39 0d 0a b0f9..

Got it running and working ( gravity command at least worked) by using a dll injector. I just injected the d3d9.dll after HaloCE started. For some odd reason it put Halo back to 1.00.09.0616.