Win32 running on 64-bit/SysWOW64 might be like running a guest VM on a hypervisor - the Win32 "guest" may not be allowed any direct 64-bit access to the SysWOW64 "host".

My guess is that Win32 has been kept pure 32-bit to run properly on that architecture and it includes no 64-bit calls, thunked or otherwise. No "guest extensions" or paravirtualization within Win32 running on 64-bit.

This seems to have been a long-running topic on StackOverflow, no-one seems to have a better idea than shelling out, which you're already doing e.g. https://stackoverflow.com/questions/2003573/how-to-start-a-64-bit-process-from-a-32-bit-process .

>Guten Morgen Thomas!
>
>Thanks for the response.
>That's not the problem
>git might exist in parallel on a comp as:
>- 32bit installed as admin in "C:\Program Files (x86)"
>- 32bit installed as user in User folder
>- 64bit installed as admin in "C:\Program Files"
>- 64bit installed as user in User folder
>
>I found it common several installations with at least two of them, since the git installer simply does not check if the other version exists.
>This is no problem, I know how to figure out the path of each of those installations, and I search 32bit first.
>This raises with Bin2Text of VFPX, where I do not know what a user might have installed. If it was for me, it would be easy to solve, wouldn't it?
>
>The problem is, 64bit seems inhibited, as VFP is not allowed to run it.
>
>Lutz
>
>>Dunno if there is a clear winner, not even certain if Git is 64 or 32 bit only on a given machine - some programs can live in 64 and 32 bit versions on same machine.
>>
>>Searching registry on each call seems bad, esp. as I am not certain same search is possible in every Win version. Simple way would be to try running hard coded path of Program Files or Program Files (86) and offer a simple way to specialize without touching sources downloaded - either via ini file with entries or a subclass (if called as prg) with properties for 64 and 32 bit install paths plus switch of which to use, adding special handling if calling those fail, as some might install elsewhere.
>>
>>Another option might be to add a test and patch routine - I think the *32 in process explorer is stable after Win7, might be better than depending on scripts to search all programs in directory or all exe on all disks...
>>
>>>The call via cmd /c works. A bat file is just a different wrapper. I've done that before I switched to cmd /c . What I like to do is running without the wrapper at all.
>>>
>>>>There could be much better answers -- and the first thought that comes to mind is running a .bat file to which you pass parameters.
>>>>
>>>>Hank
>>>>
>>>>>Hi.
>>>>>
>>>>>Any idea how to tell VFP to run a 64bit program?
>>>>>
>>>>>I use API_AppRun to run a git with several parameters - this is for Bin2Text on VFPX
>>>>>
>>>>>The problem is git (if somebody like to test)
>>>>>It could be installed as 64bit or 32bit
>>>>>
>>>>>So if it is a 32bit installation, I can run, for example git log -1>temp.txt via APPRun.
>>>>>This fails if installed as 64bit. I can call cmd calling git, like cmd /c git log -1>temp.txt but that's so awkward.
>>>>>
>>>>>So what do I need to do that VFP can call the 64bit program?
>>>>>
>>>>>Lutz