Dmitry Timoshkov dmitry@baikal.ru writes:
diff -up cvs/hq/wine/include/winnt.h wine/include/winnt.h --- cvs/hq/wine/include/winnt.h 2005-11-30 23:19:48.000000000 +0800 +++ wine/include/winnt.h 2006-01-02 15:08:41.000000000 +0800 @@ -1743,12 +1743,21 @@ typedef struct _IMAGE_DOS_HEADER { } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER; #include <poppack.h>
+#ifdef WORDS_BIGENDIAN +#define IMAGE_DOS_SIGNATURE 0x4D5A /* MZ */ +#define IMAGE_OS2_SIGNATURE 0x4E45 /* NE */ +#define IMAGE_OS2_SIGNATURE_LE 0x4C45 /* LE */ +#define IMAGE_OS2_SIGNATURE_LX 0x4C58 /* LX */ +#define IMAGE_VXD_SIGNATURE 0x4C45 /* LE */ +#define IMAGE_NT_SIGNATURE 0x50450000 /* PE00 */ +#else #define IMAGE_DOS_SIGNATURE 0x5A4D /* MZ */ #define IMAGE_OS2_SIGNATURE 0x454E /* NE */ #define IMAGE_OS2_SIGNATURE_LE 0x454C /* LE */ #define IMAGE_OS2_SIGNATURE_LX 0x584C /* LX */ #define IMAGE_VXD_SIGNATURE 0x454C /* LE */ #define IMAGE_NT_SIGNATURE 0x00004550 /* PE00 */ +#endif
I'm not sure what you are trying to achieve here. If you want to load little-endian files on big-endian machines, you need to swap everything; swapping only the signature is not going to do any good.
"Alexandre Julliard" julliard@winehq.org wrote:
I'm not sure what you are trying to achieve here. If you want to load little-endian files on big-endian machines, you need to swap everything; swapping only the signature is not going to do any good.
My aim is to make winebuild generate a proper PE header for builtin DLLs and allow kernel32 to properly detect PE executables. Btw, that's what PSDK headers have.
"Dmitry Timoshkov" dmitry@baikal.ru writes:
"Alexandre Julliard" julliard@winehq.org wrote:
I'm not sure what you are trying to achieve here. If you want to load little-endian files on big-endian machines, you need to swap everything; swapping only the signature is not going to do any good.
My aim is to make winebuild generate a proper PE header for builtin DLLs and allow kernel32 to properly detect PE executables. Btw, that's what PSDK headers have.
Well, I'm not sure what Microsoft is trying to achieve here either...
It doesn't seem a very good idea to put a standard PE signature on big-endian files, since they are not valid PE files. The current approach makes it possible at some point to support loading little-endian PE files on big-endian machines (which I suspect is what Microsoft is trying to do with that define). If you swap the signature in builtins then you will have no way of knowing whether you need to swap the rest of the header.
"Alexandre Julliard" julliard@winehq.org wrote:
Well, I'm not sure what Microsoft is trying to achieve here either...
It doesn't seem a very good idea to put a standard PE signature on big-endian files, since they are not valid PE files. The current approach makes it possible at some point to support loading little-endian PE files on big-endian machines (which I suspect is what Microsoft is trying to do with that define). If you swap the signature in builtins then you will have no way of knowing whether you need to swap the rest of the header.
Isn't Machine (IMAGE_FILE_MACHINE_xxx) field supposed to indicate that?
"Dmitry Timoshkov" dmitry@baikal.ru writes:
"Alexandre Julliard" julliard@winehq.org wrote:
Well, I'm not sure what Microsoft is trying to achieve here either... It doesn't seem a very good idea to put a standard PE signature on big-endian files, since they are not valid PE files. The current approach makes it possible at some point to support loading little-endian PE files on big-endian machines (which I suspect is what Microsoft is trying to do with that define). If you swap the signature in builtins then you will have no way of knowing whether you need to swap the rest of the header.
Isn't Machine (IMAGE_FILE_MACHINE_xxx) field supposed to indicate that?
Not really; there's an IMAGE_FILE_BYTES_REVERSED flag though, maybe we should be setting that for big-endian. But of course you can't get at the flag without knowing the byte order of the DOS header...