WIP: Porting Cxbx to Linux via Winelib

[Haxar]

I've done a port of shogun's Cxbx branch to Linux via Wine's compatibility layer for Windows applications.

So far, the Cxbx GUI is working.



What was done, generally:

• Generation of Makefiles from Visual Studio project files with winemaker,
• Wrapping MSVC specific code with the use of __GNUC__ and __WINE__ predefined preprocessor macros,
• Inline assembly syntax conversion from MSVC's Intel syntax to GCC's AT&T syntax,
• Made some code strict for compilation with GCC,
• Change file name and path syntax from Windows to Linux/Unix syntax (case sensitivity, directory separation).

Also included shogun's D3D9 modifications wrapped in the D3D9 preprocessor macro, leaving the D3D8 code.

Prerequisites for building:

• You probably need to compile Wine from source to get the Winelib compilation tools to build Cxbx unless your Linux distribution do carry them: winegcc, wineg++, winebuild, wrc
• prelink is required to set the base address of the Cxbx library.

With these prerequisites installed, you can do from the root of the source directory:

cd build/wine
make
./cxbx.sh

Current problems:

• Cannot emulate (obviously),
• I can call CxbxKrnlInit from dolphin.exe; the DolphinClassic example from XDK 4627. Unfortunately, Wine is doing some relocation where the dolphin.exe base address is 0x10000 but is relocated at 0x240000, thereby making CxbxKrnlInit's arguments invalid. I can't find a solution to this at the moment.

Source code location:

• GitHub: https://github.com/haxar/cxbx-shogun/tree/wine
• Commits: https://github.com/haxar/cxbx-shogun/commits/wine
• Git command: git clone -b wine git://github.com/haxar/cxbx-shogun.git

---

Last edited by Haxar; June 29th, 2012 at 06:21.. Reason: renamed cxbx shell wrapper script to cxbx.sh

[JayFoxRox]

Instead of generating new exe or elf files, you should write a loader with the Cxbx kernel which then mmaps the xbe to 0x10000.
You can move most of the linux allocations away by giving specific attributes to the linker to move the .text section etc. elsewhere.

If you don't want to make these changes you can still create non-flat segments (http://blog.oxff.net/#6kymkyx4h6gcivm4iknq) to do the "relocation" for you.

[Haxar]

Found it out. Wine was reserving 0x10000 as a DOS memory area with reserve_dos_area(). So for now, the address is remapped to the executable.

Yes, a loader would make sense. Windows executable generation on Linux doesn't.

The next issue is with the Local Descriptor Table. There is absolutely no documentation from Microsoft or anywhere regarding NtSetLdtEntries. Wine's NtSetLdtEntries subroutine is a stub.

EDIT: Replaced NtSetLdtEntries with wine_ldt_set_entry.

---

Last edited by Haxar; June 25th, 2012 at 12:40..

[Haxar]

Originally Posted by JayFoxRox

Instead of generating new exe or elf files, you should write a loader with the Cxbx kernel which then mmaps the xbe to 0x10000.

I finally did this. See commit:

https://github.com/haxar/cxbx-shogun...acecc73061a40f

Unfortunately for this, you will have to compile Wine from source for now.

A new requirement is to have a patched Wine source tree (with included .patch in this commit) to move all Wine specific allocations away from the 0x10000 virtual address space for mmaping an Xbox executable there.

This is a better approach than using the converted XBE to EXE. It also drops the prelink dependency.

[blueshogun96]

I'm asking since I'm not a UNIX expert (I still have lots to learn), but would this work on MacOS X? I'm curious to see what I can do with this Macbook besides write iOS apps on it.

__________________

Official Website of Shogun3D's RyuAwai!

Shogun3D Game Development Blog

Zengjük a Dalt: Manliest Song Ever!

[Haxar]

While Mac OS is UNIX-like, it should be possible to use Wine and run Windows applications. Most of the work will have to be from the command line.

http://wiki.winehq.org/MacOSX/

[blueshogun96]

^ Yes, but will the base address be an issue on MacOS X? I'm asking because I tried to get Cxbx working on MacOS X with WINE a few months ago and it failed every time (my assumption was due to the base address of the .exe files). I'm still too inexperienced with that OS and I'm still learning how it works behind the scenes of the slick GUI.

Also, keep in mind that Caustik and _SF_ never did manage to run a .xbe at a different base address as numerous things use an absolute address.

And thanks for sharing your progress.

__________________

Official Website of Shogun3D's RyuAwai!

Shogun3D Game Development Blog

Zengjük a Dalt: Manliest Song Ever!

[Haxar]

The base address issue seems to be Wine specific.

All I had to do was increase the value of address_space_start, from the Wine source tree, in dlls/ntdll/virtual.c, around line 123.

That should force Wine to allocate its heap, signal/thread stack, etc. away from the 0x10000 virtual address area.

With the patch, I can set the WINEADDRSPACESTART environment variable to 0x1000000 and that would leave me with available virtual space from 0x10000 though 0x1000000 (16777216-65536 bytes or <16MB). This should be set only for the loader (through the wrapper script loader.sh).

Here's the Wine patch for reference:

diff --git a/dlls/ntdll/virtual.c b/dlls/ntdll/virtual.c
index 806b7a9..52051e5 100644
--- a/dlls/ntdll/virtual.c
+++ b/dlls/ntdll/virtual.c
@@ -1411,7 +1411,7 @@ static int alloc_virtual_heap( void *base, size_t size, void *arg )
  */
 void virtual_init(void)
 {
-    const char *preload;
+    const char *env;
     void *heap_base;
     size_t size;
     struct file_view *heap_view;
@@ -1425,15 +1425,21 @@ void virtual_init(void)
     while ((1 << page_shift) != page_size) page_shift++;
     user_space_limit = working_set_limit = address_space_limit = (void *)~page_mask;
 #endif  /* page_mask */
-    if ((preload = getenv("WINEPRELOADRESERVE")))
+    if ((env = getenv("WINEPRELOADRESERVE")))
     {
         unsigned long start, end;
-        if (sscanf( preload, "%lx-%lx", &start, &end ) == 2)
+        if (sscanf( env, "%lx-%lx", &start, &end ) == 2)
         {
             preload_reserve_start = (void *)start;
             preload_reserve_end = (void *)end;
         }
     }
+    if ((env = getenv("WINEADDRSPACESTART")))
+    {
+        unsigned long start;
+        if (sscanf( env, "%lx", &start ) == 1 && (void *)start > address_space_start)
+            address_space_start = (void *)start;
+    }
 
     /* try to find space in a reserved area for the virtual heap */
     if (!wine_mmap_enum_reserved_areas( alloc_virtual_heap, &heap_base, 1 ))

You can apply this patch with git apply (from the command line) to a cloned Git Wine source tree. You'll have to compile Wine with the patch for this, obviously. I haven't considered submitting the patch upstream yet.

---

Last edited by Haxar; July 4th, 2012 at 21:48..