2016-09-21 6 views
0

Ich entwickle eine Qt-Anwendung, die mit XML-Dateien arbeitet. Um die Leistung zu erhöhen, verwende ich den Parser von Pugixml anstelle von Qt's Parser. Nach dem Kompilieren werden meine Anwendung und alle Abhängigkeiten (DLL-Dateien, Hilfsprogramme) als Ressource einer winapi-Anwendung gepackt, um eine einzelne exe-Datei zu erstellen.Beschädigtes Winapi ausführbares Manifest

Alles funktionierte gut, bis ich QString::toStdString() durch QString::toStdWString() ersetzen musste. Der Grund dafür ist das Lesen von Dateien mit erweiterten Buchstaben in Namen (ąęśćłóźżń) in pugixml. Ich lasse pugixml::document::load_file() mit Daten laufen, die vorher durch eine Qt rekursive Verzeichnisschleife geladen wurden. QString s, die Dateinamen enthalten, werden in std::wstring und dann in const wchar_t* mit qstring.toStdWString().c_str() konvertiert.

Nach dem Ersetzen string s mit wstring s, funktionierte die entpackte ausführbare Datei gut. Doch nachdem er die endgültige EXE-Datei hat eine beschädigte manifest Verpackung, die wie folgt aussieht:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
    <security> 
     <requestedPrivileges> 
     <requestedExecutionLevel level="asInvoker"/> 
     </requestedPrivileges> 
    </security> 
    </trustInfo> 
    <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
    <application> 
     <!--The ID below indicates application support for Windows Vista --> 
     <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
     <!--The ID below indicates below indicates application support for Windows 
7 --> 
     <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> 
     <!--The ID below indicates application support for Windows 8 --> 
     <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> 
     <!--The ID below indicates application support for Windows 8.1 --> 
     <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> 
     <!--The ID below indicates application support for Windows 10 --> 
     <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> 
    </application> 
    </compatibili 

ich Windows 7 64bit verwenden, Kompilieren mit mingw -w64 Shell. Das Make-Datei von der Endverpackung sieht wie folgt aus:

all: final.exe 

final.exe: sad.o res.o 
    g++ -o final.exe -static-libgcc sad.o res.o resource.o -lcomctl32 -lshlwapi -mwindows 

sad.o: sad.cpp 
    g++ -c sad.cpp 

res.o: sad.rc resource.h resource.cpp 
    windres sad.rc res.o 
    g++ -c resource.cpp 

clean: 
    rm -f *o final.exe 

(res.o enthält das Programm und alle von windres gepackten Abhängigkeiten sad.cpp enthält das winapi Programm, das von der Ressourcen meine Anwendung ruft).

+0

Was ist das beschädigte Manifest? – andlabs

+0

Es ist in der Frage enthalten. XML stoppt nur, bevor alle Knoten geschlossen sind –

+1

Wir müssten dann den Code sehen, der die Manifest-Ressource erzeugt. – andlabs

Antwort

0

Nicht sicher, was das Problem verursacht, scheint wie Compilerfehler, jedoch kann es durch Erstellen von WinAPI-Ressource aus XML-Datei mit einem gültigen Manifest bearbeitet werden. Ich werde das Verfahren für zukünftige Referenz beschreiben.

Erstellen Sie eine neue manifest.rc-Datei, die wie folgt aussieht:

#include <windows.h> 
RT_MANIFEST BINARY MOVEABLE PURE "manifest.xml" 

Dann erstellen Sie eine Datei manifest.xml enthält eine gültige Manifest XML-Datei und fügen Sie Makefile:

manifest.o: manifest.rc 
    windres manifest.rc manifest.o 

Don Vergessen Sie nicht, manifest.o zum Programmhauptprogramm im Makefile hinzuzufügen:

final.exe: sad.o res.o manifest.o 
    g++ -o final.exe -static-libgcc sad.o res.o resource.o manifest.o -lcomctl32 -lshlwapi -mwindows