15 Jahre und niemandem fiel es auf? (Console ohne Manifest)

[himitsu]

Jupp, es geht um die Codevorlage/Template, welche Delphi bei Neuerstellung verwendet.

Wir wissen ja, dass viele das natürlich vergessen / meistens nicht dran denken. (mich nicht ausgeschlossen)

Konsolenanwendungen werden wohl viel weniger erstellt, als VCL oder FMX, wobei es dort ja schon ewig standardmäßig aktiv ist.
Drum war ich auch noch nie auf die Idee gekommen, das zu prüfen, bis es jetzt mal knallte.

[MichaelT]

Danke für die Links. Auch ich denke nicht dran.

Manifeste unter Windows helfen beim Management von Abhängigkeiten und erlauben deren exakte Definition. Klassiker wären beim Betrieb von serverseitiger Software die präzise Definition von Abhängigkeiten von Dynamic Link Libraries.

Damit sind Konsolenanwendungen mit von der Partie. Es hilft sogar, das Manifest aus dem Executable auszulagern um Anpassungen nach intensivem Testen an neue DLL Versionen am Server zu 'implementieren' (jetzt nicht im Sinne von programmieren, sondern administrieren), um die geht es in dem Umfeld am Ende.

Unter UNIX/Linux kann/muss oder musste, keine Ahnung ob es schon bessere Lösungen dafür gibt, die Abhängigkeiten mittels Kommandozeilen Utility gegebenenfalls bügeln. Vor den Manifesten unter Windows war UNIX/Linux diesbezüglich eher im Vorteil. Lange blieb dieser Aspekt bezüglich Windows Server unter der Decke oder wurde ohne viel Getöse am Netz von Administratoren erfreut zur Kenntnis genommen.

Zitat von himitsu:

Jupp, es geht um die Codevorlage/Template, welche Delphi bei Neuerstellung verwendet.

Wir wissen ja, dass viele das natürlich vergessen / meistens nicht dran denken. (mich nicht ausgeschlossen)

Konsolenanwendungen werden wohl viel weniger erstellt, als VCL oder FMX, wobei es dort ja schon ewig standardmäßig aktiv ist.
Drum war ich auch noch nie auf die Idee gekommen, das zu prüfen, bis es jetzt mal knallte.

[gubbe]

Zitat von himitsu:

Konsolenanwendungen werden wohl viel weniger erstellt, als VCL oder FMX, wobei es dort ja schon ewig standardmäßig aktiv ist.
Drum war ich auch noch nie auf die Idee gekommen, das zu prüfen, bis es jetzt mal knallte.

Wo hat es denn geknallt?

Ich bin auch gerade in einer Anwendung darüber gestolpert, dass die Windows-Funktionen GetVersion und GetVersionEx eine veraltete Windows-Version zurückgeben (Windows 8), wenn man kein passendes Manifest eingebunden hat. Das kann sich dann natürlich auch auf eingebundene Bibliotheken auswirken, die dann keine neuen Features von moderneren Betriebsystemen nutzen. Das geht dann aber letztlich vom Programm aus und GetVersion und GetVersionEx sind als "deprecated" dokumentiert. Dass Windows von sich noch weitere Kompatibilitätsfunktionen freischaltet habe ich jetzt nicht gesehen, aber es würde mich sehr interessieren, ob es außer der falschen Versionsmeldung noch weitere Auswirkungen hat.

VirtualStore gibt es doch schon länger und wird aktiv, wenn man versucht in Verzeichnisse wie Windows oder das eigene Programmverzeichnis zu schreiben. Solange die Applikation nicht solchen Unfug macht, sollte sich das fehlende Manifest hier nicht auswirken.

[himitsu]

Noch besser, inzwischen gibt es auch einen VirtualStore in der Registry. (war 'nen Kollege vor Kurzem drüber gestolpert)

hab's grad nicht im Kopf.
waren zwei WinAPI-Funktionen ... die eine meinte Zugriff verweigert (sollte aber eigentlich heißen "gibt's hier nicht") und bei der anderen knallte es, weil die API scheinbar wie im Windows 2000 ausgeführt wurde, wo die Parameter noch bissl anders waren (nicht die Deklaration, sondern welche Werte man reingeben darf).

[gubbe]

Ok, danke. Ich meinem Fall war es keine Konsolenanwendung und keine Delphi-Software, aber wenn ich das so höre wird jetzt ein sehr ausführlicher Test fällig, was sich alles mit dem neuen korrekten Manifest geändert haben könnte.