When tracking down a crash in the kernel32 loader test, Dmitry found a bug in the Mac OS loader when Wine tried to load his dummy PE file. Upon further research I found that the Mac loader seems to have its own undocumented PE loader built in. I did some further testing with a windows binary and got some really interesting results....
#include <stdio.h> #include <dlfcn.h>
int main(int argc, char **argv) { void *handle; const char *error;
// handle = dlopen("./ldr330e.tmp", RTLD_NOW | RTLD_FIRST ); handle = dlopen("./procexp.exe", RTLD_NOW | RTLD_FIRST );
if (!handle) { fputs (dlerror(), stderr); printf("I guess it didn't load\n"); exit(1); }
printf("I guess it loaded\n"); dlclose(handle); }
Its trying to load the dlls. I get this output
steven-edwardss-imac:temp sedwards$ ./a.out dlopen(./procexp.exe, 258): Library not loaded: WS2_32.dll Referenced from: /Users/sedwards/Library/Application Support/CrossOver/Bottles/winetest/drive_c/windows/temp/procexp.exe Reason: image not foundI guess it didn't load steven-edwardss-imac:temp sedwards$ file procexp.exe procexp.exe: MS-DOS executable PE for MS Windows (GUI) Intel 80386 32-bit steven-edwardss-imac:temp sedwards$ open . steven-edwardss-imac:temp sedwards$ ./a.out dlopen(./procexp.exe, 258): Library not loaded: MPR.dll Referenced from: /Users/sedwards/Library/Application Support/CrossOver/Bottles/winetest/drive_c/windows/temp/procexp.exe Reason: image not foundI guess it didn't load steven-edwardss-imac:temp sedwards$ ./a.out dlopen(./procexp.exe, 258): Library not loaded: MPR.dll
So this leads to the question. Whats going on? Is this a hold over from EFI which is PE by default? Why would the OS need to load the EFI files? Maybe just for easy of development and testing? Or is something else going on? Is Apple going to be adding a win32 compatibility layer to OS X? Is having a native PE loader of any use to us?
Thanks Steven
Hi Again,
On Nov 29, 2007 5:37 AM, Steven Edwards winehacker@gmail.com wrote:
Is Apple going to be adding a win32 compatibility layer to OS X?
This is the most important question to me because of some information Ken found:
I don't know that this whole thing amounts to anything, but thought I'd add a few notes.
This is new to Leopard. On Tiger, dlopen rejects PE files as expected. The Wine testing that Steven was originally trying to do would probably not crash on Tiger. Wine needs a patch to somehow check that a file is actually a Mach-O object file before calling dlopen on it.
There really are PE-loading smarts somewhere within the Mac OS X dynamic loader (dyld). If you set DYLD_PRINT_SEGMENTS=1 before running Steven's sample program, you'll get something like this in the output:
dyld: Main executable mapped /private/tmp/a.out __PAGEZERO at 0x00000000->0x00001000 __TEXT at 0x00001000->0x00002000 __DATA at 0x00002000->0x00003000 __IMPORT at 0x00003000->0x00004000 __LINKEDIT at 0x00004000->0x00005000 [...] dyld: Mapping /private/tmp/procexp.exe .header at 0x400000->0x400fff with permissions rw. .text at 0x401000->0x47155b with permissions rw. .rdata at 0x472000->0x481933 with permissions rw. .data at 0x482000->0x4a3deb with permissions rw. .rsrc at 0x4a4000->0x7819df with permissions rw.
The diagnostics printed for the loading of a.out are typical of a Mach-O object. Those for procexp.exe are definitely not.
So, there you have it.
-Ken
PE Files were rejected on Tiger, which is interesting to me because I don't think that this is just a hold over from EFI support. I think it may be a sign of future addition of a Win32 subsystem to OS X.
On Nov 29, 2007 8:47 AM, Steven Edwards winehacker@gmail.com wrote:
PE Files were rejected on Tiger, which is interesting to me because I don't think that this is just a hold over from EFI support. I think it may be a sign of future addition of a Win32 subsystem to OS X.
More information
http://www.opensource.apple.com/darwinsource/10.5/dyld-95.3/src/strip.exp
which contains
# local symbols to suppress *PE* *Win*
The project file references ImageLoaderPE.cpp, but that isn't included in the source... all the other files are here, so yes it really looks like they are trying to hide support for PE. Why would they go to all this trouble to hide Windows Binary support?
-
Steven Edwards