Re: [PATCH] winegcc - do not create .exe.so
On 03/20/2011 05:14 AM, Pali Rohár wrote:
Can anybody review my patch?
Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system. As for the patch: - Do not use tab characters - Please no unneeded white space changes - Use git to create your patch. At the very minimum it have to have full path to the source file in the header - patch should be generated from the top of the source tree. Vitaliy.
On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote:
On 03/20/2011 05:14 AM, Pali Rohár wrote:
Can anybody review my patch?
Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system.
Wine installs wrapper scripts which call wine with the appropriate .exe.so DSO. The .exe.so file can't be run directly. As far as I can tell, the patch makes it so the .exe.so file can be run directly, by adding a _start section that automatically execs wine with all the same arguments passed on the command line. As a result, it removes the .so extension so you can, for example, just run the 'winecfg.exe' executable itself, with no 'winecfg' wrapper script needed. This stuff isn't an area I'm familiar with, so I can't really comment on the patch itself.
On 03/20/2011 06:54 PM, Chris Robinson wrote:
As far as I can tell, the patch makes it so the .exe.so file can be run directly, by adding a _start section that automatically execs wine with all the same arguments passed on the command line. As a result, it removes the .so extension so you can, for example, just run the 'winecfg.exe' executable itself, with no 'winecfg' wrapper script needed. This is what I understood as well.
My problems with the patch are: - This should be platform independent and working everywhere Wine works - It should be optional at very minimum. It's not possible to run shared libraries for a reason. - Calling something .exe doesn't magically make it a PE-executable. You can't call ELF shared library a windows executable. File can stay .exe.so and still be executable as they are now Vitaliy.
On 3/20/11 6:54 PM, Chris Robinson wrote:
On Sunday, March 20, 2011 4:37:07 PM Vitaliy Margolen wrote:
On 03/20/2011 05:14 AM, Pali Rohár wrote:
Can anybody review my patch?
Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system.
Wine installs wrapper scripts which call wine with the appropriate .exe.so DSO. The .exe.so file can't be run directly.
As far as I can tell, the patch makes it so the .exe.so file can be run directly, by adding a _start section that automatically execs wine with all the same arguments passed on the command line. As a result, it removes the .so extension so you can, for example, just run the 'winecfg.exe' executable itself, with no 'winecfg' wrapper script needed. It's not enough to have a 'start' symbol. The binary has to be of the right type, too. On Mac OS, for example, the binary has to be of the MH_EXECUTE type (instead of MH_BUNDLE, which it would be right now), or you won't be able to execve(2) it. With ELF, the binary type has to be ET_EXEC (instead of ET_DYN).
Also, I don't know if Mac OS, Linux, or any other platform allows you to dlopen(3) something that isn't a DSO (MH_DYLIB and MH_BUNDLE on Mac OS, ET_DYN on ELF platforms). In that case, the right answer might just be to leave this alone. Another solution might be to re-implement the Wine loader logic in the executable itself, but I'm not sure if that's a good idea. 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. Chip
On 21 March 2011 12:26, Charles Davis <cdavis(a)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?
On 3/20/11 9:31 PM, Ben Klein wrote:
On 21 March 2011 12:26, Charles Davis <cdavis(a)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. Chip
On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
On 3/20/11 9:31 PM, Ben Klein wrote:
On 21 March 2011 12:26, Charles Davis <cdavis(a)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?
On 3/20/11 10:28 PM, Ben Klein wrote:
On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
On 3/20/11 9:31 PM, Ben Klein wrote:
On 21 March 2011 12:26, Charles Davis <cdavis(a)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!).
Chip
On 21 March 2011 15:47, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
On 3/20/11 10:28 PM, Ben Klein wrote:
On 21 March 2011 15:10, Charles Davis <cdavis(a)mymail.mines.edu> wrote:
On 3/20/11 9:31 PM, Ben Klein wrote:
On 21 March 2011 12:26, Charles Davis <cdavis(a)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.
participants (4)
-
Ben Klein -
Charles Davis -
Chris Robinson -
Vitaliy Margolen