64-битная PoweShell, вызывающая 32-битную DLL - PullRequest
Новая
       48

64-битная PoweShell, вызывающая 32-битную DLL

0 голосов
/ 31 мая 2019

На компьютере с Windows 10 я вызываю QuickBooks из базы данных 4-го измерения (4D), используя скрипт PowerShell.Сценарий вызывает QBXMLRP2.dll, 32-битный COM-объект, для связи с QuickBooks 2019. Как я понимаю PowwerShell, вызов 32-битной библиотеки DLL с использованием 64-битной версии PowerShell не удастся, и наоборот.Однако я получаю разные результаты в зависимости от того, использую ли я 32-битную или 64-битную версию 4D.Это не имеет смысла для меня.Вот мои результаты испытаний ... 

OS  4D  PowerShell  DLL   Result
64  32  32          32    OK
64  32  64          32    OK //According to my research this should not work!

64  64  32          32    OK
64  64  64          32     X //According to my research this is the expected behavior

Есть мысли о том, почему 64-битная версия PowerShell / 32-битная DLL работает с 32-битной версией 4D?Я действительно хочу, чтобы он работал с 64-битными версиями 4D и PowerShell.

В ответ на вопросы ... Вот что я делаю.Сначала 4D создает файл сценария ps и сохраняет его на диск, а затем запускает PowerShell во внешнем процессе.Например, это приведет к запуску 64-разрядной PowerShell (windows10), а PowerShell выполнит ранее сохраненный сценарий. 

"C:\\Windows\\system32\\WindowsPowerShell\\v1.0\\powershell.exe -file \""+$ScriptPath+"\""

Сценарий PowerShell выглядит следующим образом. 

[String]$requestXML = '<?xml version="1.0" ?>
<?qbxml version="2.0"?><QBXML>
<QBXMLMsgsRq onError="stopOnError">
<CompanyQueryRq requestID="1">
</CompanyQueryRq>
</QBXMLMsgsRq>
</QBXML>'
$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

Так что, как я понимаю, 4Dпосле запуска PowerShell отсутствует.4D не взаимодействует с dll.Это все PowerShell / DLL (COM) /QuickBooks.

1 Ответ

0 голосов
/ 06 июня 2019

С помощью этого форума и небольшого исследования я теперь понимаю, что в 64-битной операционной системе Windows, если ОС обнаруживает, что 32-битное приложение выполняет вызов в каталог System32, она автоматически перенаправляет вызов на каталог SysWow64. Таким образом, в моем сценарии 32-битная PowerShell всегда будет работать при вызове из 32-битного 4D. Обратите внимание, что это перенаправление доступно только в том случае, если вызывающее приложение является 32-разрядным на 64-разрядном компьютере. Поэтому, если 64-битное приложение (4D) вызывает 64-битную PowerShell в каталоге System32, перенаправление не произойдет. В этом случае, если PowerShell вызывает 32-битную DLL-библиотеку, произойдет сбой. PowerShell / dll должен соответствовать разрядности.

Если кто-то хочет принудительно запустить 64-битную версию в каталоге System32 из 32-битного приложения, вместо каталога System32 можно использовать специальный каталог «Sysnative». Обратите внимание, что это виртуальный каталог. Вы не найдете его в файловой системе. Опять же, если вы принудительно используете 64-битную версию Powershell, а PowerShell пытается вызвать 32-битную DLL, это не удастся.

Следующая статья очень хорошо читается ...

https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector

Вот моя исправленная таблица тестирования ... 

OS  4D  PowerShell  DLL   Result
64  32  32          32    OK
64  32  64-OS->32   32    OK //OS redirected to 32bit PS. Expected behavior!

64  64  32          32    OK
64  64  64          32     X //No redirect. Expected behaviour
...