Next Generation Emulation banner

1 - 5 of 5 Posts

·
Premium Member
Joined
·
423 Posts
Discussion Starter #1
As you might have read already, I'm working on a new symbol-detection code-base. But because it's cumbersome work (debugging every case that still fails), I've done some in-between work on Dxbx too;

My latest few commits have been on stream-lining the XBE->EXE conversion code. The reason I've been working on that is, that I needed to understand more of this all because of a major Cxbx-deviation I'm contempting to start.

Let me explain the reason for this first :

Currently we convert an XBE to an EXE (just like Cxbx does), which makes it necessary to link the resulting EXE to a kernel DLL.
Because the generated EXE needs to have a kernel thunk table, we retrieve it from the kernel DLL at conversion-time. From that moment on, the EXE depends on the exact placement of those thunks in the DLL. This implies that the kernel-DLL must not change, or else the EXE won't work anymore.
The problem with this is, that almost all of the development takes place in the kernel DLL, which means that every little change in the kernel DLL invalidates any existing generated EXE!
Another problem with this approach is the question as to in what folder we should put the generated exe - especially a problem when the folder is read-only. There's also the situation that the generated exe is put in another folder as the original default.xbe, or when it's in a folder that doesn't contain our kernel DLL.

In summary : The current conversion of XBE to EXE is not very practical.

There's a solution however, which takes all these problems away, and at the same time opens up a few possibilities : We could build an "XBE loader".
Let me explain that too :

When an EXE loads, windows parses the exectuable, reserves virtual memory for all sections, reads those into memory, applies address relocation, handles the static DLL dependancies in much the same way, and finally jumps to the entry-point of the EXE.

Now, if we immitate this process, but use the original default.XBE as input, we would get several benefits :
- There's no need for a separate kernel DLL anymore (!)
- Our emulator becomes just one executable (containing GUI, kernel and code-patching all rolled into one)
- We could drop the whole XBE>EXE conversion code
- We could load XBE's straight from read-only media
- It becomes more easy to emulate the dashboard and games that load other XBE's
- We could even start thinking about adding ISO-support (!)

Sure, we need to tackle some problems :
- we must make sure the normal virtual-address range ($10000) stays available (which is quite simple : we just need to give our emulator a high-enough ImageBase)
- we have to do 100% correct relocation (including virtual page protection and stuff, but luckily the Wine codebase can be used as reference for this)
- we would need to slightly alter the current way of exchanging data between the emulator and the game (it will become easier actually, since all data will be in-process!)

I'm hoping to have the symbol-detection finished soon, for I'm eager to start experimenting with this idea!


PS: If anyone foresees any problems with this already, please tell!
 

·
Administrator
Joined
·
8,200 Posts
I wouldnt worry about the EXE not being properly linked to the kernal DLL. I'd just redo the the XBE to EXE conversion (which doesnt take too long) every time.
The XBE loader on the other hand sounds like a much better approach. My windows understanding at that level isn't too good but how would that be achieved? Sounds alot more complicated then a simple shellexecute :p
 

·
Premium Member
Joined
·
423 Posts
Discussion Starter #3
I wouldnt worry about the EXE not being properly linked to the kernal DLL. I'd just redo the the XBE to EXE conversion (which doesnt take too long) every time.
That's what I'm doing currently - all manually, like a 100 times a night. This bothers me to a great extend :rolleyes:

The XBE loader on the other hand sounds like a much better approach. My windows understanding at that level isn't too good but how would that be achieved? Sounds alot more complicated then a simple shellexecute :p
Yeah, it will be more complicated, but it's a process that's well understood, and as I was saying, there's lots of open-source code available to show us the way.

PS : It occurred to me only after this post that this is actually one step closer to becoming a 'real' emulator - throw in a CPU emulator and we're well underway :lol:
 

·
Administrator
Joined
·
8,200 Posts
PS : It occurred to me only after this post that this is actually one step closer to becoming a 'real' emulator - throw in a CPU emulator and we're well underway :lol:
Ahh yes indeed. For some reason, that's not what I was thinking of when I first read your post.

Aniway, keep it up!
 

·
Ya'ver drink Brazilian bold from fkn dunkn donuts!
Joined
·
7,828 Posts
It certainly sounds like an interesting and a novel approach to tackling the XBE's. Good luck with your code patrick, I'm very interested to see how it will work out.

(I love reading about how you and blueshogun tackle your projects)
 
1 - 5 of 5 Posts
Top