Seite 2 von 3
Verfasst: 09.03.2007 00:22
von jear
Danke für die Anleitungen, konte ich gerade gut gebrauchen.
Nach Einbinden der mit porc.exe compilierten XP.res per Import : EndImport finde ich allerdings in einem Dump der Exe die Inhalte der originalen XP.res und der von mir eingebundenen XP.res.
Kann das schaden? Wie könnte ich es unterbinden?
Verfasst: 09.03.2007 10:09
von jpd
Hallo TS-soft,
dass ist Super!
funktioniert einwandfrei.
so wie ich verstehe funktioniert es auch folgendermasen.
mache aus der res-datei die manifest.xml
die datei test.rc generieren
Code: Alles auswählen
#define MANIFEST 24
1 MANIFEST "D:/CODE/test/manifest.xml"
dann diese über Menu
Compilers | Compiler Options | Resources
die test.rc anbinden
in diese fall ist auch das generieren oder importieren der res datei nicht
notwendig.
Danke
jpd
Verfasst: 09.03.2007 12:04
von dysti
.....wenn ich das richtig verstehe,
wird die XP.RES eingebunden, läuft mein PRG mit Admin-Rechten.
Oder ist das falsch was ich denke?
Gibt es sowas auch für WIN2000?
Verfasst: 09.03.2007 12:14
von jear
@jpd
in diesem Fall ist auch das Generieren oder Importieren der res-Datei nicht notwendig.
Das hatte ich gestern auch probiert und heute wiederholt: danach finde ich aber im Dump der Exe keinerlei Hinweis auf das einebundene Manifest. Nur der Inhalte der originalen XP.res ist zu sehen!
Wo bleibt das Manifest denn bei der Methode?
Verfasst: 09.03.2007 13:58
von jpd
Hallo jear,
da ich mich mit diese sache zum erstenmal beschäftige,
habe ich die ganze prozedur wiederholt,
und kann dier bestätigen dass es funktioniert.
Allerdings habe ich den eindruck das es nicht so sauber ist weil:
ich verwende diese manifest.xml
Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="admin.exe"
type="win32"
/>
<description>launcher description</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
<ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
<ms_asmv2:security>
<ms_asmv2:requestedPrivileges>
<ms_asmv2:requestedExecutionLevel level="highestAvailable">
</ms_asmv2:requestedExecutionLevel>
</ms_asmv2:requestedPrivileges>
</ms_asmv2:security>
</ms_asmv2:trustInfo>
</assembly>
wenn ich den name unter "assemblyIdentity"
ändere wird die exe datei generiert und bei starten wird eine fehlermeldung generiert ...
Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren.
also wie soll ich es sagen ... es ist als ob man den vorgaugelt das es sich um eine andere anwendung handelt und das gefällt mir überhaupt nicht!
währe schön wenn jemand das erklären würde.
Grüsse
jpd
Verfasst: 09.03.2007 14:24
von jear
@jpd
hier der originale Code aus der im PB-Verzeichnis Compilers zu findenden XP.RES.
Code: Alles auswählen
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="CompanyName.ProductName.YourApp"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="X86"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
Denke daher, dass ein Eintrag wie
Code: Alles auswählen
name="admin.exe"
statt :
name="CompanyName.ProductName.YourApp"
irreführend ist. Hier werden offenbar Namen gebraucht und keine Dateibezeichnungen. Möglicherweise liegt es daran.
Habe hier gar kein Vista laufen. Daher kann ich nur vom Hörensagen berichten.
Ein mit einem (nach der in diesem Thread empfohlenen Methode erstellten) Manifest versehener Setup-Installer läuft offenbar unter Vista. Die installierte Applikation aber nicht, denn sie hat noch kein Manifest.
Neuland halt, auf dem wir uns bewegen.
Daher meine Frage an die Könner, das ich es noch nicht ausprobieren kann:
Dass ein Setup-Installer Admin-Rechte braucht, das ist einsichtig. Er erzeugt Registry-Einträge, legt Desktop-Symbole an und assoziiert Dateiendungen mit Anwendungen.
Welche Rechte muss denn eine normale Anwendung haben, wenn sie nur bestehende Registry-Werte verändert oder Werte zu einem Key hinzufügt?
Verfasst: 09.03.2007 15:23
von jpd
Hallo jear,
eigentlich müsste es so sein das ein benutzer nur in mache bereiche schreiben kann z.b HKCU in alle andere bereiche müsste er nur lesend zugreifen können es sei dem die zugriffberächtigung in der registry verändert wurden sind.
Grüsse
jpd
Verfasst: 09.03.2007 17:50
von ts-soft
jear hat geschrieben:
Kann das schaden? Wie könnte ich es unterbinden?
In den Compileroptionen den XP-Style abschalten!
jpd hat geschrieben:
die test.rc anbinden
in diese fall ist auch das generieren oder importieren der res datei nicht
notwendig.
Danke
jpd
Du benötigst aber absolute Pfade und es ist so nicht weitergebbar. In jaPBe gehts aber auch
ohne fixe Pfade. Ich finde das Importieren besser.
Verfasst: 09.03.2007 20:14
von jear
In den Compileroptionen den XP-Style abschalten!
Will das Kind nicht mit dem Bade ausschütten sondern lediglich das Einbinden des Standard-Manifestes vermeiden.
Verfasst: 19.03.2007 01:22
von jear
Das Einbinden des kombinierten XP- und Vista-Manifests per Import scheint gut zu klappen.
Hier in meiner Entwicklungsumgebung gibt es aber ein Problem, möglicherweise eines, das man dem jaPBe zuordnen kann.
Bild
Diese Fehlermeldung verhindert das Erstellen einer Exe:
- wenn eine der Include-Dateien aktiv ist fast immer,
- wenn die Hauptdatei aktiv ist relativ selten.
Im ersten Fall aktiviere ich die Hauptdatei. Dann wird die Exe meist erstellt. Im zweiten Fall muss ich jaPBe beenden und neu starten. Dann läuft es wieder einige Zeit.
