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