> On May 30, 2019, at 9:40 PM, Epperlein, Lutz (agendo)
> <[email protected]> wrote:
>
> we use Powershell a lot, even in conjunction with 4D. But we never divide
> between 32bit and 46bit-Powershell. Since you use the Powershell via LAUNCH
> EXTERNEL PROCESS (LEP) the architecture (bitness) of the Powershell binary
> shouldn't matter.
I am not sure I understand your statement here. LEP is launching either
the 32bit or 64bit version of Powershell which in turn calls the dll. Is not
LEP out of the picture at this point, thus the bitness must match between
PowerShell and the dll or PowerShell is going to throw a "80040154 Class not
registered” error.
> And a question: Regarding your script how do you determine the variables
> '32bit PowerShell' and '64bit PowerShell'?
> I'm in doubt that you call the 64bit-Powershell using the 32bit-4D-Client.
> Are
> you really sure?
This process/code has been in place for many years. Up until now I
insured that I was always using the 32bit version of PowerShell like this…
If (Test path name("C:\\Windows\\sysWoW64")=Is a folder)
//This is a 64bit machine so I must use the 32bit version of PowrShell
$PS_Call:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe -file
\""+$ScriptPath+"\""
Else
//This is a 32bit machine and there is only 1 version of Powershell
$PS_Call:="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -file
\""+$ScriptPath+"\""
End if
LAUNCH EXTERNAL PROCESS($PS_Call)
Now that I am moving everything 4D to 64bit on a Windows 10 machine,
and before I understood that you could not mix PowerShell and DLL bitness, I
simply falsed out the test…
If (False) //(Test path name("C:\\Windows\\sysWoW64")=Is a folder) //I know
I am on Windows 10 a 64bit machine and I do not want to use the 32 bit version
for this test
$PS_Call:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe -file
\""+$ScriptPath+"\""
Else
//Windows 10 is a 64 bit machine and my intention is to use the 64bit
version of Powershell
Trace
$PS_Call:="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -file
\""+$ScriptPath+"\""
End if
I have done this test many times, but just to make sure I reran the
test with the R3 Client just now with a break before calling the 64bit version
of PowerShell as above. QBXMLRP2 is a 32 bit dll so knowing what I know now,
this should NOT work, but it does. Using the 64bit version of 4D Client it
fails as I would expect.
> And I'm quite sure the cause of problem is the class '
> QBXMLRP2.RequestProcessor'. It seems to exist as 32bit on your system, so you
> can use the 32bit-Powershell only. The dependency is between Powershell and
> Quickbooks, not between 4D and Powershell regarding the bitness.
Exactly! So why does calling 64bit PowerSehll work using 32bit R3
client?
Going forward I will just have to continue using 32bit PowerShell. I
guess if Windows ever drops 32bit support, the ball will be in Intuit’s court
to provide a 64bit version of the QBXMLRP2.dll. It’s just that I would like to
really understand whey using differing architectures of 4D would make a
difference in R3.
Thanks
John
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:[email protected]
**********************************************************************
