Next Generation Emulation banner

1 - 20 of 53 Posts

·
Registered
Joined
·
20 Posts
Discussion Starter #1
I spent today hacking with the Cxbx code from Shogun's SVN branch and I have managed to prevent the 0xC000007b error from occuring on Windows 64-bit.

Cxbx still doesn't run correctly due to the well known LDT/FS register issues, but at least it doesn't immediately get killed by Windows anymore.

It turns out that the Cxbx code that produces a .exe file fills in the SizeOfImage field of the PE Header incorrectly, causing some versions of windows to prevent the image from loading.

I solved this by patching Exe.cpp of the Cxbx project to write the final raw file size of the produced EXE to the SizeOfImage field. (Verified by CFF Explorer as being correct)

Screenshot proof and edited Exe.cpp attached.
 

·
Premium Member
Joined
·
6,071 Posts
This is interesting. Thank you sir.
 

·
Registered
Joined
·
20 Posts
Discussion Starter #4 (Edited)
So, I've hit a major snag with Cxbx on 64-bit systems.

I noticed that the code within X64 version EmuFS.cpp causes an access violation when attempting to patch the main executable memory space. In order to make sure this wasn't just an error in this code, I made all FS related functions return upon entry.

If Cxbx execution is allowed to get past FS initialisation with the above hack, it then generates an access violation within EmuInstallWrapper(). This means that on 64-bit systems, Cxbxkrnl.dll no longer has write access to the default.exe address space, preventing the kernel from performing any patches at all on the Xbox executable.

This is due to Windows 64bit having stricter memory protection, an attempt by Microsoft to help prevent malware from modifying code on the fly in RAM.

Due to this, the entire patching system of Cxbx would need to be re-written with 64bit support in mind.

I can see two different paths from here, both of which requiring an extensive amount of re-working.

Solution 1:
Modify Cxbx to perform all HLE patches in the same stage as XBE-EXE conversion, so that everything that was previously in cxbxkrnl.dll gets injected in the main default.exe process. This would work as during the output stage, the executable is treated as data and not executable code, so it can be modified at this stage.

This is a very complex task, as the entirity of Cxbxkrnl would have to bei scrapped, it would probably end up a completely different emulator.

Solution 2: (This one would likely be more feasible)
Hackily make Cxbxkrnl.dll open a handle to the Xbox executable and attach to it as a debugger. This would allow for Cxbxkrnl to call the functions VirtualProtect() and WriteProcessMemory() from the WinAPI to modify the main executable memory in ram.
However, this would still require some heavy working within cxbxkrnl.dll as with this API, the main executable's data cannot be edited directly on a single byte level, as all writing has to go through the WriteProcessMemory() function, which is more similar to a memcpy API.

My plan for this (which I may work on implementing this weekend, if I'm not too busy) is to add a function into Cxbxkrnl.dll which will open a debugger handle to the main executable in order to get write access to the process, copy it's entire data into Cxbxkrnl's address space to allow for the current patching functionality to work, but from a different memory location and then use WriteProcessMemory() to write the patched executable back over the original image in RAM with one single function call before emulation starts.

I have no idea how well, if at all this will work, so I can't make any promises, especially since this is my first time working in C/C++ for anything more complex than a Z80 interpreter or 2D OpenGL renderer.
 

·
Premium Member
Joined
·
6,071 Posts
Ah, you've done your homework. Since I don't have Win64 installed, I can't verify much.

Now, from what I've seen regarding previous posts here, you can't simply ignore the FS code because Xbox's TIB is very different from the PCs. There's a really informative thread regarding it, and so far it's been the closest to getting x64 working. I have no idea how to get x64 support on Cxbx tbh, and I haven't touched Cxbx in a while. Been too busy with other things, got a new contract with Microsoft, indie games, etc.

Hopefully, you can figure something out. If you do, I'll update the SVN with your changes.
 

·
Registered
Joined
·
137 Posts
Hi Soul I just wanted to say this is great news for the 64bit version I have a 64 bit computer windows 8 but I don't know too much about xbox emulation so sorry about that one all I can say is keep up the great work and we appreciate it very much! I hope you can get some graphics and games to work as well that would be cool too when I used 64bit computer inside a virtual machine of dxbx emulator I could get the title screen of gauntlet to work until my computer crashed much later on oh well I hope you pull it off big time with the emulation and the making of the emulator!
 

·
Registered
Joined
·
20 Posts
Discussion Starter #9
I agree with Squall, disabling DEP may make the 64 bit port easier, however I would rather not have end users disable a feature of the operating system that is designed to improve security.
 

·
Registered
Joined
·
20 Posts
Discussion Starter #10
Good news everyone!

Cxbx is now able to successfully patch and being execution of Xbox code on Windows 64-bit, thanks to solution 2 I mentioned above.

The bad news, however, is that it is still unable to produce a playable game, due to accesses to the FS register.

The good thing here, is now the FS register is the only thing standing in the way of 64-bit Windows as the issues relating to memory protection have been successfully fixed.
 

·
Premium Member
Joined
·
6,071 Posts
For previous work done to fix the FS register problem in 64-bit Windows, check out this thread: http://forums.ngemu.com/showthread.php?t=134748

The OP came close, but not quite enough for a stable build. I tried running it in 32-bit mode and it actually got me closer to ingame with one game (one I can't remember off the top of my head).

Unfortunately, my new contract with Microsoft is going to be rather demanding time wise, so finding time to help out of give advice isn't going to be as frequent as I'd like. Thanks for the update.
 

·
Registered
Joined
·
20 Posts
Discussion Starter #12 (Edited)
I'll just leave this here.

Please note that Futurama is the only title I can currently get to display anything, every other game I attempt to run will crash shortly after allocating the heap, when accessing FS registers, because my Thread Local Storage emulation is only partially implemented as of yet.

Edit:
Futurama is crashing within NtUserIoApcDispatcher() in EmuKrnl.cpp.
The crash occurs during the DbgPrintf routine during the C runtimes chkstk.
Commenting out DbgPrintf in this function allows for Futurama to progress further, past the Menu and crashing on the Loading screen when attempting to get in game.

Edit2:

It seems Futurama is crashing here due to a DirectSound function not being detected by the HLE database. This should be easily fixable as I have known Futurama to run on other Cxbx branches in the past.

The second two screenshots are what happens if printf is disabled.
 

·
Premium Member
Joined
·
6,071 Posts
Great work. Thanks for keeping us updated on this.

Unfortunately, I don't have Futurama. If I get a copy of it, I will fix it right away. Also, if you like you can share your sources and I'll upload the changes to the SVN.
 

·
Registered
Joined
·
20 Posts
Discussion Starter #15
So, I got Turok to work and Ultra Bust-a-move to display a "Disk is dirty or damaged" error screen, but only in Release mode. When making a debug build both of these titles immediately exit due to an access violation error.

Even stranger, is when running in Release mode, Futurama no longer boots.

Is Cxbx usually this picky?
 

·
Registered
Joined
·
34 Posts
So, I got Turok to work and Ultra Bust-a-move to display a "Disk is dirty or damaged" error screen, but only in Release mode. When making a debug build both of these titles immediately exit due to an access violation error.

Even stranger, is when running in Release mode, Futurama no longer boots.

Is Cxbx usually this picky?
It can be. I've always assumed it was related to FS registers being different.
 

·
Registered
Joined
·
20 Posts
Discussion Starter #18
Turok now seems playable.

I still have some work to do, there are FS register accesses I still haven't hooked into the emulated FS register yet, among other small issues which may be causing the remaining problems I'm having.
 

·
Registered
Joined
·
137 Posts
Hey Soul I have one question will your games you get to work will they work on 64bit computers right now or later on? thanks for the great news your work is paying off totally!
 
1 - 20 of 53 Posts
Top