RE: V17R3 vs PowerShell

2019-06-03 Thread Keith White via 4D_Tech
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

Re: V17R3 vs PowerShell

2019-06-01 Thread JOHN BAUGHMAN via 4D_Tech
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. >

Re: V17R3 vs PowerShell

2019-06-01 Thread Keith White via 4D_Tech
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

Re: V17R3 vs PowerShell

2019-05-31 Thread JOHN BAUGHMAN via 4D_Tech
> 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

Re: V17R3 vs PowerShell

2019-05-31 Thread JOHN BAUGHMAN via 4D_Tech
> 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

Re: V17R3 vs PowerShell

2019-05-31 Thread Keisuke Miyako via 4D_Tech
> 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

RE: V17R3 vs PowerShell

2019-05-31 Thread Epperlein, Lutz (agendo) via 4D_Tech
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

Re: V17R3 vs PowerShell

2019-05-30 Thread JOHN BAUGHMAN via 4D_Tech
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

Re: V17R3 vs PowerShell

2019-05-30 Thread JOHN BAUGHMAN via 4D_Tech
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

Re: V17R3 vs PowerShell

2019-05-29 Thread JOHN BAUGHMAN via 4D_Tech
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