On 21 March 2011 15:47, Charles Davis <cda...@mymail.mines.edu> wrote: > On 3/20/11 10:28 PM, Ben Klein wrote: >> On 21 March 2011 15:10, Charles Davis <cda...@mymail.mines.edu> wrote: >>> On 3/20/11 9:31 PM, Ben Klein wrote: >>>> On 21 March 2011 12:26, Charles Davis <cda...@mymail.mines.edu> wrote: >>>>> Also, as near as I can tell, this will only work on x86 Linux. It won't >>>>> work anywhere else (e.g. Mac OS X, FreeBSD, Solaris, etc.). This is >>>>> because the 'start' code invokes execve(2) using the interrupt 80h >>>>> interface. Even if other systems use int 80h for their syscall vector >>>>> (Mac OS does, at least for Unix syscalls), the syscall numbers usually >>>>> aren't the same across different platforms. >>>> >>>> Does this also mean it will fail to work on amd64/ia64 systems? >>> For 32-bit (x86) code running on an x86-64/IA64 system, it will work. >>> For 64-bit code, no, it won't work. In fact, x86-64 and IA64 kernels >>> keep the old int 80h interface around solely for the benefit of old >>> 32-bit programs (like old versions of Wine, before Maarten Lankhorst and >>> AJ fixed it) that expect it to be there. >>> >>> In fact, even if 64-bit code supported the int 80h interface, it still >>> wouldn't work, because even across different architectures on Linux, the >>> syscall numbers are different. >> >> Thanks for explaining it. >> >> Something else I noticed in this patch though; what happens to the >> environment variables handled by the loader script? > Nothing. He even hard-coded the path to the 'wine' binary (as a series > of DWORDs, no less!).
I suspected that's what was going on. Basically, this patch makes absolutely no logical sense at all.