I should have mentioned, the WIP is in the 'win64-2' branch:
https://github.com/gittup/tup/tree/win64-2

On Sat, Nov 1, 2014 at 11:25 AM, Mike Shal <[email protected]> wrote:

> Hi Robert, thanks so much for working on this! I think we are fairly close.
>
> I've tried to incorporate this patch and produce both the
> tup-dllinject.dll (64-bit) and tup-dllinject32.dll from the same tree. To
> build binaries from Linux, you'll need both a CONFIG_TUP_MINGW and
> CONFIG_TUP_MINGW32 in tup.config:
>
> CONFIG_TUP_MINGW=x86_64-w64-mingw32
> CONFIG_TUP_MINGW32=i686-w64-mingw32
>
> I have a few questions so far, all pretty inter-related:
>
> 1) Why did you want to force have_shell=1 in windepfile.c? That causes
> many of the tests to fail, so if it is truly necessary I'll have to find a
> way to fix those tests (there are many). Or if there is some particular
> case that doesn't work without it, I'll want to add a test to check for it
> (and possibly fix it a different way)
>
> 2) Should it be possible to inject the 64-bit DLL into a 64-bit process
> from a 32-bit process? For example, if I run "sh -c './64-test.exe'", then
> sh (a 32-bit process) gets injected with a 32-bit dll, but 64-test.exe (a
> 64-bit process) doesn't get injected. (Whereas if I just run 64-test.exe
> directly, it gets injected fine since tup.exe is 64-bit). Is this why you
> added have_shell=1 above?
>
> 3) Am I compiling the dllinjection code correctly? I left in the
> @(TUP_32_BIT) code that you had commented out. (To be honest I'm not sure
> what it's used for - I can't find the email thread or issue that talks
> about it). Specifically, do I need to use both x86_64-w64-mingw32 and
> i686-w64-mingw32? Or is there some way with -m64 / -m32 / -somethingelse
> that we can just use x86_64-w64-mingw32?
>
> 4) The 64-bit DLL injection code won't compile with the 32-bit compiler,
> since the CONTEXT structure no longer has the .Rip field. I put an #ifdef
> around it, but I hit the "Error: Shouldn't be hooking here for the 32-bit
> dll" message (something I added to your patch) when using sh -c
> './64-test.exe' from question 2). Is there a better way to handle that?
>
> Hopefully we can get these sorted out & in the master branch soon.
>
> Thanks again,
> -Mike
>
>
> On Wed, Aug 6, 2014 at 5:40 AM, Robert Pettersen <[email protected]> wrote:
>
>> Hi,
>>
>> Really sorry about not posting any updates, been swamped with work and
>> just got back from vacation. I don't have time to setup a git repo and
>> commit the code, means I'll actually have to clean-up and comment the code.
>> But I have attached a diff between the current origin/HEAD and the changes
>> I made to get it working on 64bit host windows. Haven't made any changes
>> since the initial work, since it has been stable for our use. Be warned
>> tho, I have not tested this on a 32bit host system, it will however execute
>> 32bit binaries on a 64bit host system.
>>
>> ~/tup64$ cat tup.config
>>
>> CONFIG_TUP_MINGW=x86_64-w64-mingw32
>>
>>
>> I can probably answer some questions about the code and help out some
>> here on the forum, but I can't guarantee their timelyness. Really swamped
>> with work.
>>
>> Again, really sorry for not posting responses here sooner!
>>
>> On Monday, March 17, 2014 8:46:22 PM UTC+1, [email protected] wrote:
>>
>>> On Mon, Mar 17, 2014 at 8:51 AM, Tristan Rybak <[email protected]>
>>> wrote:
>>>
>>>> Hi Mike, Robert,
>>>> Any news on a patch for 64bit windows?
>>>> I am using the executable attached to first post and it's working great
>>>> (very big thanks for that Robert!)
>>>> but I'd like to have new features and bugfixes introduced later too
>>>> please.
>>>> Maybe I could help with integrating the fix into repository somehow?
>>>> Regards,
>>>> Tristan
>>>>
>>>
>>> Hi Tristan,
>>>
>>> I don't think I've seen the patch from Robert yet, though maybe I've
>>> missed it. I'd be happy to get it included if he's interested in getting it
>>> upstream.
>>>
>>> Thanks,
>>> -Mike
>>>
>>  --
>> --
>> 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.
>>
>
>

-- 
-- 
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