RE: V17R3 vs PowerShell
Hi John > That is the only thing that makes sense to me. Do you know this for certain? Yes. Please see https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector > I had hoped that by having LEP display the console, I could tell which > version of PowerShell was run To tell if a running application is 32-bit or 64-bit, open Windows Task Manager (Processes tab). 32-bit applications have a *32 to the right of the executable name. >. It’s interesting to me that the OS is making the decision based on the >architecture of the requesting application not the architecture of the dll At the point you launch PowerShell, it has no idea what you’re going to do with it. You may access external 32-bit (or 64-bit) DLLs/COM objects or you may not. Quite simply, the OS knows the 32-bit application is trying to access “system32” and so translates that to SysWow64. This is transparent to the 32-bit application. > When PowerShell is launched I do not think that the OS knows which or even if > a dll is going to be addressed. Exactly, it doesn’t. It does however know that a 32-bit application is trying to access the system32 folder. > Does that mean a 32bit 4D will not launch 64 bit PowerShell ever? If you need to force a 32-bit application to launch 64-bit stuff from system32, you can use a special virtual directory “Sysnative”. Note that this virtual directory is only for 32-bit applications. This is detailed at the end of the article I’ve sent. Hope this helps. Best regards Keith White Synergist Express Ltd, UK. 4697775 ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: V17R3 vs PowerShell
Aloha Keith, > The reason that you think the 64-bit PowerShell is working is because > actually the 32-bit PowerShell is still being used. > > When a 32-bit application (in this case 4D) accesses the system32 directory, > those accesses are automatically redirected to the SysWow64 directory. > > So when you use LEP to launch PowerShell and you think you've specified the > 64-bit version in system32, the OS is just launching the one from SysWow64. That is the only thing that makes sense to me. Do you know this for certain. I was suspecting that this was the case but could not find anything that documents this behavior. I had hoped that by having LEP display the console, I could tell which version of PowerShell was run. But the console only displays a path above an empty command window. When the 64bit version of PowerShell is launched by 32bit 4D the path displayed in the console is in fact to PowerShell in the System32 folder not SysWow. But I think that path only reflects the requested path from LEP, not which version of PowerShell is actually running. If LEP launches the 32bit version the path is to PowersShell in the SysWow folder, otherwise the consoles looks exactly the same. Thanks for your input. I think your spot on. It’s interesting to me that the OS is making the decision based on the architecture of the requesting application not the architecture of the dll. How does the OS otherwise know which to launch? Does that mean a 32bit 4D will not launch 64 bit PowerShell ever? When PowerShell is launched I do not think that the OS knows which or even if a dll is going to be addressed. Enough already. I think I am beating a dead horse here. I am moving on, but really do appreciate your input and all who have tried to straighten out this far too curious old fart’s brain. 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:4d_tech-unsubscr...@lists.4d.com **
Re: V17R3 vs PowerShell
Aloha John The reason that you think the 64-bit PowerShell is working is because actually the 32-bit PowerShell is still being used. When a 32-bit application (in this case 4D) accesses the system32 directory, those accesses are automatically redirected to the SysWow64 directory. So when you use LEP to launch PowerShell and you think you've specified the 64-bit version in system32, the OS is just launching the one from SysWow64. On the other hand, when running a 64-bit application this redirection doesn't happen, so you can launch either 32-bit or 64-bit PowerShell as needed. As your QB SDK is 32-bit only, you'll always have to launch the 32-bit PowerShell. Hope this helps. Best regards Keith White Synergist Express Ltd, UK. 4697775 ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: V17R3 vs PowerShell
> On May 30, 2019, at 10:13 PM, Keisuke Miyako via 4D_Tech > <4d_tech@lists.4d.com> wrote: > >> QBXMLRP2.RequestProcessor > > > is the QB SDK based on COM / OLE ? Yes. > but it does sound like the SDK is not installed in the client having a > problem. > perhaps OLEVIEW.EXE could tell you if the class is available. No the class is available as it works fine using 32bit PowerShell. I am just asking why, when using 32bit R3. does LEP calling the 64bit version of Powershell to execute a ps script that invokes a 32bit COM object work, when it shouldn’t. 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:4d_tech-unsubscr...@lists.4d.com **
Re: V17R3 vs PowerShell
> On May 30, 2019, at 9:40 PM, Epperlein, Lutz (agendo)
> 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:4d_tech-unsubscr...@lists.4d.com
**
Re: V17R3 vs PowerShell
> QBXMLRP2.RequestProcessor is the QB SDK based on COM / OLE ? if yes, it shouldn't be a huge problem that information specific to 4D+PowerShell+QB is rather hard to find, because COM /OLE is a common technology on Windows. PowerShell is just one of the ways to invoke it. in theory, generic information about any COM /OLE would be applicable. --- we recently worked on a COM / OLE project, where the vendor documentation was written for .NET and VB "only", but that didn't prevent us from writing a 4D plugin in C. --- but it does sound like the SDK is not installed in the client having a problem. perhaps OLEVIEW.EXE could tell you if the class is available. ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
RE: V17R3 vs PowerShell
Hi, 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. 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? 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. HTH Regards Lutz Epperlein ** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **
Re: V17R3 vs PowerShell
Not sure anyone is interested, but after a lot of research on line it appears
that 64bit version of Powershell cannot call a 32bit dl and vice versa. This
does not match the results I am getting with v17R3.
In my previous post I left out that . 4D client is running on a 64bit Windows
10 install, so in all my tests the system contained both a SysWow64 folder
containing the 32bit version of PowerShell and a System32 folder containing the
64bit version of PowerShell.
The following is more descriptive of my testing….
4D OSServer & Client 4DServer 4DClient
PowerShell DLL Result
v17R364 64
32 3232OK
v17R3. 64 64
32 6432OK. //According to
my research this should not work!
V17R3 6464
64 32 32 OK
V17R3 6464
64 64 32X
//According to my research this is the expected behavior
Why is the 32 bit 4D client working when it uses 64bit PowerShell?
Hard to find answers for this. There is no forum that has folks that are expert
in 4D, PowerShell, and Quickbooks.I am going to post my question on Stack
Exchange, Intuit SDK forum, and the Powershell forum and see what I get.
If you got this far, thanks for reading. If I get an answer I will post it here.
John
> On May 29, 2019, at 7:12 PM, JOHN BAUGHMAN wrote:
>
> Anyone using PowerShell on Windows 10 out there? Maybe you can help me figure
> this out.
>
> I am upgrading an old v13 database to v17. My ultimate goal is to have
> everything run-in 64bit.
>
> The database talks to QuickBooks on a Windows 10 machine using an XML stream
> in a Powershell script file executed with PowerShell by LEP.
>
> I have successfully upgraded all of 4D to run successfully 64 bit, but have
> am unable to get v17R3 or R4 64bit client to work successfully with 64bit
> PowerShell…
>
>
> 4DServer Client PowerShell
> Result
> v17R364 32 32
> OK
> v17R3. 64 32 64
> OK
>
> V17R36464 32
> OK
> V17R36464 64
> X
>
> I am pretty sure that the PowerShell script is not being executed because
> QuickBooks is not receiving a call. What changes with 64Bit 4d client that
> could possibly be preventing the PowerShell Script from executing?
>
> I have posted the applicable code and ps script below.
>
> Thanks,
>
> John
>
>
> Here is what the LEP call looks like…
>
> ScriptPath:=$1
> $4D_Folder:=Get 4D folder(Active 4D Folder)
> $FileID:=String(Milliseconds)+"-"+String(Random)
>
> Case of
> : (32bit). //pseudo code
>
> $FilePath:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe
> -file \""+$ScriptPath+"\”"
>
> : (32bit)
>
> $FilePath:="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe
> -file \""+$ScriptPath+"\""
>
> End Case
>
> $OutputStream:=$3
> $ErrorStream:=$4
> $XMLOutBlobPtr:=$5
> //set the environmentals and launch the external process
> SET ENVIRONMENT VARIABLE("_4D_OPTION_HIDE_CONSOLE";"true")
> SET ENVIRONMENT VARIABLE("_4D_OPTION_BLOCKING_EXTERNAL_PROCESS";"false")
> SET ENVIRONMENT VARIABLE("_4D_OPTION_CURRENT_DIRECTORY";$4D_Folder)
> //SET ENVIRONMENT VARIABLE("_4D_OPTION_INPUT_STREAM";"I"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_OUTPUT_STREAM";"O"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_ERROR_STREAM";"E"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_STOP_TOKEN";$FileID)
> LAUNCH EXTERNAL PROCESS($FilePath)
> —
>
> ———
> The PowerSrcipt script looks like this…
>
> [String]$requestXML = '
>
>
>
>
>
> '
> $myQBXMLRP = New-Object -com QBXMLRP2.RequestProcessor
> $myQBXMLRP.OpenConnection2("qb4D","CCFolioPro",1)
> $ticket = $myQBXMLRP.BeginSession("C:\Company Files\Cadinha & Co.,
> LLC.QBW",$myQBXMLRP.qbFileOpenDoNotCare)
> $myQBXMLRP.ProcessRequest($ticket, $requestXML) >
> $env:_4D_OPTION_OUTPUT_STREAM
> $myQBXMLRP.EndSession($ticket)
> $myQBXMLRP.CloseConnection()
> "Stop" > $env:_4D_OPTION_STOP_TOKEN
>
> ---
>
>
> John Baughman
> Kailua, Hawaii
> (808) 262-0328
> john...@hawaii.rr.com
>
**
4D Internet Users Group (4D iNUG)
Archive:
Re: V17R3 vs PowerShell
Oooops. Just noticed an error in the code I posted. The case statement should
have read
On May 29, 2019, at 7:12 PM, JOHN BAUGHMAN wrote:
Case of
: (32bit PowerShell). //pseudo code.
$FilePath:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe
-file \""+$ScriptPath+"\”"
: (64bit PowerShell) //pseudo code
$FilePath:="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe
-file \""+$ScriptPath+"\""
End Case
> On May 29, 2019, at 7:12 PM, JOHN BAUGHMAN wrote:
>
> Anyone using PowerShell on Windows 10 out there? Maybe you can help me figure
> this out.
>
> I am upgrading an old v13 database to v17. My ultimate goal is to have
> everything run-in 64bit.
>
> The database talks to QuickBooks on a Windows 10 machine using an XML stream
> in a Powershell script file executed with PowerShell by LEP.
>
> I have successfully upgraded all of 4D to run successfully 64 bit, but have
> am unable to get v17R3 or R4 64bit client to work successfully with 64bit
> PowerShell…
>
>
> 4DServer Client PowerShell
> Result
> v17R364 32 32
> OK
> v17R3. 64 32 64
> OK
>
> V17R36464 32
> OK
> V17R36464 64
> X
>
> I am pretty sure that the PowerShell script is not being executed because
> QuickBooks is not receiving a call. What changes with 64Bit 4d client that
> could possibly be preventing the PowerShell Script from executing?
>
> I have posted the applicable code and ps script below.
>
> Thanks,
>
> John
>
>
> Here is what the LEP call looks like…
>
> ScriptPath:=$1
> $4D_Folder:=Get 4D folder(Active 4D Folder)
> $FileID:=String(Milliseconds)+"-"+String(Random)
>
> Case of
> : (32bit). //pseudo code
>
> $FilePath:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe
> -file \""+$ScriptPath+"\”"
>
> : (32bit)
>
> $FilePath:="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe
> -file \""+$ScriptPath+"\""
>
> End Case
>
> $OutputStream:=$3
> $ErrorStream:=$4
> $XMLOutBlobPtr:=$5
> //set the environmentals and launch the external process
> SET ENVIRONMENT VARIABLE("_4D_OPTION_HIDE_CONSOLE";"true")
> SET ENVIRONMENT VARIABLE("_4D_OPTION_BLOCKING_EXTERNAL_PROCESS";"false")
> SET ENVIRONMENT VARIABLE("_4D_OPTION_CURRENT_DIRECTORY";$4D_Folder)
> //SET ENVIRONMENT VARIABLE("_4D_OPTION_INPUT_STREAM";"I"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_OUTPUT_STREAM";"O"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_ERROR_STREAM";"E"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_STOP_TOKEN";$FileID)
> LAUNCH EXTERNAL PROCESS($FilePath)
> —
>
> ———
> The PowerSrcipt script looks like this…
>
> [String]$requestXML = '
>
>
>
>
>
> '
> $myQBXMLRP = New-Object -com QBXMLRP2.RequestProcessor
> $myQBXMLRP.OpenConnection2("qb4D","CCFolioPro",1)
> $ticket = $myQBXMLRP.BeginSession("C:\Company Files\Cadinha & Co.,
> LLC.QBW",$myQBXMLRP.qbFileOpenDoNotCare)
> $myQBXMLRP.ProcessRequest($ticket, $requestXML) >
> $env:_4D_OPTION_OUTPUT_STREAM
> $myQBXMLRP.EndSession($ticket)
> $myQBXMLRP.CloseConnection()
> "Stop" > $env:_4D_OPTION_STOP_TOKEN
>
> ---
>
>
> John Baughman
> Kailua, Hawaii
> (808) 262-0328
> john...@hawaii.rr.com
>
**
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**
Re: V17R3 vs PowerShell
I ran the PS scrip in the 64bit PowerShell ISE and I am getting the error…
80040154 Class not registered
Googling this tells me that this is the result of 64bit PowerShell balking at
calling a 32bit COM object. I wonder, however, why when run from a 32 bit 4D
Client the same script calling the same COM object works with the 64bit version
of PowerShell. What does 4D have to do with the execution of the PowerShell
Script? Perhaps LEP functions differently in 64bit than it does in 32bit?
John
> On May 29, 2019, at 7:12 PM, JOHN BAUGHMAN wrote:
>
> Anyone using PowerShell on Windows 10 out there? Maybe you can help me figure
> this out.
>
> I am upgrading an old v13 database to v17. My ultimate goal is to have
> everything run-in 64bit.
>
> The database talks to QuickBooks on a Windows 10 machine using an XML stream
> in a Powershell script file executed with PowerShell by LEP.
>
> I have successfully upgraded all of 4D to run successfully 64 bit, but have
> am unable to get v17R3 or R4 64bit client to work successfully with 64bit
> PowerShell…
>
>
> 4DServer Client PowerShell
> Result
> v17R364 32 32
> OK
> v17R3. 64 32 64
> OK
>
> V17R36464 32
> OK
> V17R36464 64
> X
>
> I am pretty sure that the PowerShell script is not being executed because
> QuickBooks is not receiving a call. What changes with 64Bit 4d client that
> could possibly be preventing the PowerShell Script from executing?
>
> I have posted the applicable code and ps script below.
>
> Thanks,
>
> John
>
>
> Here is what the LEP call looks like…
>
> ScriptPath:=$1
> $4D_Folder:=Get 4D folder(Active 4D Folder)
> $FileID:=String(Milliseconds)+"-"+String(Random)
>
> Case of
> : (32bit). //pseudo code
>
> $FilePath:="C:\\Windows\\sysWoW64\\WindowsPowerShell\\v1.0\\powershell.exe
> -file \""+$ScriptPath+"\”"
>
> : (32bit)
>
> $FilePath:="C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe
> -file \""+$ScriptPath+"\""
>
> End Case
>
> $OutputStream:=$3
> $ErrorStream:=$4
> $XMLOutBlobPtr:=$5
> //set the environmentals and launch the external process
> SET ENVIRONMENT VARIABLE("_4D_OPTION_HIDE_CONSOLE";"true")
> SET ENVIRONMENT VARIABLE("_4D_OPTION_BLOCKING_EXTERNAL_PROCESS";"false")
> SET ENVIRONMENT VARIABLE("_4D_OPTION_CURRENT_DIRECTORY";$4D_Folder)
> //SET ENVIRONMENT VARIABLE("_4D_OPTION_INPUT_STREAM";"I"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_OUTPUT_STREAM";"O"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_ERROR_STREAM";"E"+$FileID)
> SET ENVIRONMENT VARIABLE("_4D_OPTION_STOP_TOKEN";$FileID)
> LAUNCH EXTERNAL PROCESS($FilePath)
> —
>
> ———
> The PowerSrcipt script looks like this…
>
> [String]$requestXML = '
>
>
>
>
>
> '
> $myQBXMLRP = New-Object -com QBXMLRP2.RequestProcessor
> $myQBXMLRP.OpenConnection2("qb4D","CCFolioPro",1)
> $ticket = $myQBXMLRP.BeginSession("C:\Company Files\Cadinha & Co.,
> LLC.QBW",$myQBXMLRP.qbFileOpenDoNotCare)
> $myQBXMLRP.ProcessRequest($ticket, $requestXML) >
> $env:_4D_OPTION_OUTPUT_STREAM
> $myQBXMLRP.EndSession($ticket)
> $myQBXMLRP.CloseConnection()
> "Stop" > $env:_4D_OPTION_STOP_TOKEN
>
> ---
>
>
> John Baughman
> Kailua, Hawaii
> (808) 262-0328
> john...@hawaii.rr.com
>
**
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**
