winapi - ShellExecute print verb undlader at udskrive fra 32 bit app på 64 bit windows

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har et 32-bit program, der er installeret af en kunde på 64 bit windows.


Der ser ud til at være et problem med at bruge ShellExecute og udskriftsverdenen i den konfiguration. Først mit testprogram.


// printme.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include "objbase.h"
#include <windows.h>

#include <shellapi.h>

int main(int argc, char* argv[])
{
    if (argc != 2)
    {
        printf("Usage: \%s file\_to\_print", argv[0]);
        return 0;
    }

    CoInitializeEx(NULL, COINIT\_APARTMENTTHREADED) ; //| COINIT\_DISABLE\_OLE1DDE);

    HINSTANCE retVal = ::ShellExecute(NULL, "print", argv[1], NULL, NULL, 0);   // don't ask, as the user can always cancel...
    printf("RetVal = \%08x
", retVal);
    printf("LastError = \%08x
", GetLastError());
    return 0;
}


Dette program fungerer korrekt på 32 bit Windows-version op til Windows 7. Programmet kører blot tryksværdien på det første argument, der passeres på kommandolinjen.


printme Side1.htm


På det pågældende system oprettes registreringsdatabasen som følger:


shell \ print \ command HKEY\_CLASSES\_ROOT \ htmlfile \
indeholder en standardværdi af typen REG\_EXPAND\_SZ indeholdende
rundll32.exe\% windir\% \ system32 \ mshtml.dll, PrintHTML '\% 1'


Hvis jeg kører følgende kommando
rundll32 c: \ windows \ system32 \ mshtml.dll, PrintHTML 'Side1.htm'
Udskrivningsdialogen vises med succes.


Men kører mit program blinker, men udskrivningsdialogen vises aldrig og en stallet kopi af
C: \ Windows \ sysWow64 \ rundll32.exe er procesadministrator, som aldrig afsluttes.


Er der en løsning, eller er ShellExecute permanent brudt til fælles verb på almindelige filtyper fra 32 bit programmer på 64 bit windows?

Bedste reference


Det viser sig, at problemet er den sidste parameter for ShellExecute. Mens 0 har arbejdet i årevis, kræver det nu, at SW\_SHOW fungerer korrekt til printverden i dette tilfælde. Måske ændrede en nyere Windows-opdatering adfærden?