Subscribe via feed.


Here we attempt o answer the most common questions. Please click on a question to view the answer.

What is Dxbx?

Dxbx is an Xbox1 emulator, written in the Delphi programming language.

What’s the current status of Dxbx?

At the current time of writing we cannot (let me emphasize this: we CANNOT) run anything yet. (It’s hard work, you know.) Of course, we’ll be keeping you up-to-date of our progress in the ngemu forums.

So Dxbx does nothing right now?

Well, actually it does run Turok Evolution [PAL], although you’ll have to use another Xbox1 kernel DLL (see below, on Cxbx). Also our controller code is not yet complete, so apart from a few opening screens and an intro-movie, you won’t be seeing much.

Where can I download Dxbx?

We’re hosting the development on sourceforge, where you can also download the latest releases. Apart from that, Shadow_tj has set up a website for Dxbx with some more information that might interest you.

I heard you need official Xbox1 SDK’s (Software Development Kits) from Microsoft to be able to work on Dxbx, is this true?

No. Actually, we don’t use a single file from these SDK’s (or XDK’s as they are frequently called). We do use function-patterns derived from them however, see below.

Is this legal?

As we’re not using any classified information or restricted files, we believe we’re not violating any copyright or other law. If you feel there’s still a risk (or other problem) in the way we do things, please tell us.

Can Dxbx emulate an Xbox 360?

No. We’re building an Xbox 1 emulator.

Can’t you start on an Xbox 360 emulator instead?

Yes, we could. But we won’t – you could try it yourself though 😉

Are there any other Xbox 1 emulators?

Yes, there’s Xeon – the first emulator to run the Xbox 1 game ‘Halo’ (that’s about the only thing it did however, and the project is dead since). Other projects that we know of are Xenoborg, XProject and IronBabel. And then there’s Cxbx: The only working open-source Xbox 1 emulator available. As a matter of fact, Cxbx is our main source of inspiration, are we’re translating it’s C sources to Delphi!

Yeah, so what is Cxbx?

Read more about it on the Cxbx forum and Caustik’s website.

What requirements does Dxbx have?

For now, Dxbx requires 32 bit Windows XP (Vista and Windows 7 are not tested, and might give problems). 64 Bit windows is not supported (WOW64 is not tested, but likely won’t work anyway). On the hardware side, we’re not completely sure yet but a decent system (2 Ghz CPU, 1+ GB memory and a DirectX8 compatible video card) should suffice.

Why are you translating Cxbx to Delphi?

It’s fun! We can learn a lot from a project like this, and we like the change of subject from our day-jobs. Plus, it’s a nice showcase for what you can accomplish with the Delphi language.

How does the emulator work?

Same as Cxbx: We are building a High-Level Emulator (as opposed to a Low-Level Emulator). You could start by reading up on the various resources available on Cxbx progress page.

I will, but what can you tell me about the differences between HLE and LLE in a nutshell?

In LLE the actual hardware is (almost) completely simulated in software. Given enough processor power this would potentially result in a (very) good level of compatibility with the actual hardware. The problem however is, that every component of the actual Xbox1 must be emulated – that’s a HUGE undertaking, even when you could start with an existing code-base like VirtualBox. HLE works by running Xbox1 software natively on Windows, by impersonating to the application it’s running on an Xbox1. This requires a few tricks, and won’t be able to run everything, but it’s enough to emulate a few (and hopefully more than a few) games. Also, HLE is regarded as being a faster way of emulation than LLE.

How do you impersonate an Xbox1 while running on Windows XP?

This involves a few steps:

1) Dxbx converts the XBE (the Xbox1 executable format) to a windows EXE
2) This EXE is statically linked to our Xbox1 kernel-replacement DLL.
3) Our kernel DLL bootstraps the game by setting up a kernel thunk table and patching some library code contained in the executable with patches that solve the differences between Xbox1 and Windows.
4) Once the environment is set up, we call the original entry-point of the executable, effectively launching the game.

Now, hopefully we’ve done enough patching to make this work!

What are you hoping to achieve with Dxbx?

First, we are striving to achieve the same level of game-compatibility as Cxbx has (click here or here for details). Once that milestone is reached, we have all intentions to improve upon it.

What improvements are you planning for Dxbx?

Well, for starters Cxbx is branched into 4 different versions already, and no-one seems willing to fold it all back into one do-it-all version. So one of our targets will be translating all the Cxbx branches into one Delphi version. Other area’s of improvement are: a more complete implementation of the Xbox kernel and more generic API detection.

Are you really implementing the whole Xbox1 kernel again?!

Yes and no – Yes, eventually we’ll have to implement each and every API available in the Xbox1 kernel. But no, an actual implementation in the spirit of Wine or ReactOS is normally not necessary – lots of the API’s can be routed on to the Windows XP kernel – that’s the whole idea of HLE! But still, there are 379 unique API indexes in the Xbox1 kernel, so it’s still quite a bit of work.

What do you mean with ‘generic API detection’?

Just like Cxbx, we have to do a bit of a trick to get software written for the Xbox1 to run on Windows. The main part is patching all functions that cannot run without the actual hardware present (think of the DirectX API’s for example). To patch functions, we first have to locate them. Cxbx contains an ingenious hand-crafted data-structure for this, but it requires an insane amount of (debugging) work to achieve good results. So in Dxbx we took another approach, and generate the needed data-structure automatically, using so-called pattern-files. This way, we get much more detailed information on the various functions linked into the game – and rather effortlessly too! Also, because we can detect the presence of named variables too, we don’t need any hard-coded logic to find them (like Cxbx has). Last but not least, having a fairly detailed map of the executable gives us the ability to produce stack-traces when something goes wrong (which is quite helpfull when debugging a crash).

What can you tell me about those pattern-files?

Patterns (or rather: function patterns) are files that can be generated with a tool called IDA Pro. Pattern files contain enough information for us to detect tens of thousands of symbols (functions and variables) reliably. If you have access to IDA Pro and an XDK version we don’t have patterns for yet, than please: send them to us! (Again: not the XDK – it’s just the patterns we need.)

Will function-patterns enable Dxbx to ultimately emulate every game?

Sadly, no. Some games are using link-time optimization, which means that the library functions in-use do appear in the executable, but altered. This makes it very hard for us to pin-point them. Most likely Dxbx will fail placing most of the patches that should be in-place. The effect will be undeterminable, but most likely your game will crash.

How can I run games that use this problematic link-time optimization (LTCG)?

We know of only one way around this: use a feature-complete LLE. None exists yet, though, so you’re out of luck. Might we suggest you use an actual Xbox1? 😉

LTCG stands for “Link Time Code Generation” – a technique that optimized an executable during the linking phase. A nasty sideeffect (for us) is that the resulting executable doesn’t contain the exact binary code, as was present in the original libraries.

This fact hinders our pattern scanning engine to such a degree, that we probably won’t find enough symbols that should be patched in order to run the game.

Sure, you could reverse engineer each of those titles and manually add symbol locations (like _SF_ did in Xeon to run Halo), but chances are that even then our patches don’t work anymore because of differences in argument-passing and whatnot.

So for now, we state officially that Dxbx won’t support LTCG generated titles. This paints a clear picture to the general public and gives us more focus on other areas. I’m sure you’ll understand this reasoning.

What about (homebrew) software using OpenXDK – can that be emulated too?

Quite possibly, yes. But apart from a few patterns for OpenXDK, we’ve written not a single patch for it, because right now our main priority is emulating XDK linked software. Once OpenXDK emulation becomes a reality, it would enable the testing Xbox1 homebrew on Windows, which is certainly a nice-to-have feature (in due time).

I’m trying game XYZ, but it doesn’t work! What now?

First, check the Dxbx status (see the second Question above). If we ever reach a state where we start running games, you might continue checking if your game uses link-time optimization (this information can be gleaned from an XBE dump – see below). If that’s not the case, maybe your could be made to run when we add a few patches – we’ll be needing your Dxbx log files to analyze exactly which patches are necessary.

Can I help Dxbx?

Sure you can! Dxbx is an open-source project, so if you’re a Delphi programmer: Just grab our sources from sourceforge and start browsing our code. There’s lots of open issues to address, so you’ll surely find something nice to work on. And even when you’re not a developer you could help us out by supplying us with XBE dumps we don’t have yet.

What’s the use of those XBE dumps?

The information contained in an XBE dump mainly tells us which games use what XDK version. This gives an indication of the feasibility of actually supporting this game. Especially when it uses an XDK version that we have patterns for, there’s a good chance we could provide compatibility for it some day. On the other hand: XBE dumps will also show us if a game is linked to link-time optimized libraries – we’ve already stated that Dxbx won’t be able to emulate these.

How do I contribute an XBE dump?

You can use one of these methods, all will produce compareable output:


(Dxbx) Open Xbe (Dxbx) Dump Xbe Info

(Click on image to enlarge)


(Cxbx) Open Xbe (Cxbx) Dump Xbe Info

(Click on image to enlarge)

Now you have dumped your XBE, send the resulting file to us and we’ll add it to our growing archive.

Where are you guys getting your information from?

Lots of information can be gleaned from the Cxbx sources. Google helps a lot too. Also, various people contribute all forms of input to us: XBE dumps, documentation of Xbox internals, pattern files, etc.

I have another question that’s not on this list, what can I do?

First, try searching the Dxbx forum – there’s a good chance someone already talked about your topic. If that doesn’t help, post your question in a new topic, or send a private message or mail to one of the Dxbx developers (see the CONTACT US page).