# OpenXDK FAQ

## My application doesn't seem to launch

There are usually three causes for this:

1. You are running with an xecuter bios. For some reason, OpenXDK applications will not run using this BIOS. I personally use Evox, but there are a number of others that work (click here to see some info about which bios's are supported). I am trying desperately to work out why this is happening!!
2. Your XBE file is not able to be loaded by the kernel due to import issues. An example of this is if you try to dynamially link to code that is provided by Cygwin. Usually, the linker flag `-nostdlib` stops this from happening, but if you omit this flag, or link to a dynamic library explicitly, you will end up with imports in your resulting executable. To check if this is the case, use the `PEDUMP` utility on the EXE that is generated by the compile process (note that you need to do this against the EXE, not the XBE). An example of a broken EXE is shown below:

       Imports Table:
         KERNEL32.dll
         OrigFirstThunk:  0000F0C4 (Unbound IAT)
         TimeDateStamp:   00000000 -> Thu Jan 01 11:00:00 1970
         ForwarderChain:  00000000
         First thunk RVA: 0000F128
         Ordn  Name
             1  AddAtomA
          175  FindAtomA
          220  GetAtomNameA

         xboxkrnl.exe
         OrigFirstThunk:  0000F0D8 (Unbound IAT)
         TimeDateStamp:   00000000 -> Thu Jan 01 11:00:00 1970
         ForwarderChain:  00000000
         First thunk RVA: 0000F13C
         Ordn  Name
           49
          156
          184

   Notice how there are imports from the `KERNEL32.dll`? This is bad. The only entry you should see is the one from `xboxkrnl.exe`. In addition, the entries in `xboxkrnl.exe` all have to be imported via ordinal, not by name. If you see a name, then that is bad also (you have most likely used a function that hasn't yet been defined in the xboxkrnl. See extending the OpenXDK for more details

3. There has been a runtime error in the execution of your code. This is usually a bugger to track down! Things to look for are dereferencing NULL pointers, array index out of bounds, etc (the same sort of things that normally cause a core dump). The only way I have found to fix this is to redirect stdout/stderr and start adding trace statements in your code. Good luck!

## Where does output from printf go?

I tossed up whether I should output stdout/stderr to the screen, but in a graphical environment such as an XBOX, there are usually many frames getting rendered per second, which would mean that it would get overridden very, very quickly. As a result, at the moment, it just quietly gets swallowed. You can fix this easily, however by using the following code somewhere near the start of your program:

    freopen ("c:/stdout.txt", "w", stdout);
    freopen ("c:/stderr.txt", "w", stderr);

Back to Home Page