My application doesn’t seem to launch
There are a couple of causes for this:
- 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!!
- 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
-nostdlibstops 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
PEDUMPutility 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.exeall 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
- 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
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.
- 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'