I've managed to rebase Robert's code against the latest version of Tup and 
created a pull request here:
https://github.com/gittup/tup/pull/283

So far, I've only tested it with simple Tupfiles, but I'll be porting one 
fairly complicated project from Linux soon. 

On Friday, November 8, 2013 at 5:54:03 PM UTC+2, Robert Pettersen wrote:
>
> Hi,
>
> I've gotten Tup to work on 64bit Windows, even loading 32 bit applications.
> It is not a very elegant solution, but it works. 
>
> The reason 64bit loading on 64bit windows and 32bit loading on 32bit 
> windows is straight forward is that Windows maps the kernel32.dll at the 
> same address for all processes (until next reboot). So Tup can check what 
> addresses the LoadLibraryA and GetProcAddress functions in that dll is and 
> know that it will be the same for newly created processes, construct a 
> small assembly stub and inject this into the new process forcing the new 
> process to load the Tup dll using those function addresses.
>
> This changes when loading 32 bits processes from a 64bit Tup. The way I 
> found the 32bit addresses from the 64bit version of Tup, was to have a 
> small program, compiled as 32bit, print them out. So when the 64bit tup 
> needs to start a 32bit program, it first starts the small 32bit program and 
> store the 32bit addresses to the functions in kernel32.dll. These are then 
> used to load the 32bit version of the Tup dll.
>
> Thus the 64bit version of Tup needs both the 32bit and 64bit version of 
> the DLL, if both types of programs are to be started from Tup.
>
> One caveat I haven't figured out yet is command chaining. (i.e. "cmd1 && 
> cmd2") Tup encapsulates command chanining on Windows in a cmd.exe wrapper. 
> But cmd.exe on 64bit Windows seems reluctant to injection, or would need 
> some special handling. I have noticed that the process version for cmd.exe 
> differs from the other 64bit applications, but according to documentation I 
> have read this should only pertain to an extra MSDOS header saying that 
> this application cannot run on ms-dos...
> I solved this by having a python script handing command chaining with 
> Popen for now.
>
> Binaries are compiled on Ubuntu using x86_64-w64-mingw32 as 64bit compiler 
> and i686-w64-mingw32 for the 32bit components.
>

-- 
-- 
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to