OpenXDK FAQ

My application doesn't seem to launch

There are a couple of 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. Sometime the above problem is caused by not including the <xboxkrnl/xboxkrnl.h> file in your code (if you are calling kernel functions such as NtClose() or MmAllocateVirtualMemory(). If you do not include the header, the compiler assumes default linkage, which is not correct. Easily fixed by adding the include statement at the top of your file.

  4. 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);

Undefined reference to __imp__XXX

There were some changes checked into Cygwin's winbase.h in August 2004 that caused the OpenXDK build process to fail. They have subsequently been backed out (or more correctly, modified), but not before they made it into production Cygwin builds. Version 0.06 of OpenXDK has a fix to handle all cases of the following error: 
/usr/local/openxdk/i386-pc-xbox/lib/libc.a(mallocr.o)(.text+0x1b): In function makeGmListElement':
/usr/local/OpenXDK/src/newlib-1.12.0/i386-pc-xbox/newlib/libc/stdlib/../../../../newlib/libc/stdlib/mallocr.c:1112: undefined reference to 
`__imp__LocalAlloc@8'

Back to Home Page