OS Version Windows 10 ermitteln.

[Gerd01]

Bis Windows 8.1 habe ich das Operating System über Win32Platform und dann über die Win32MajorVersion und Win32MinorVersion ermittelt (Bitte keine Frage Warum man die Windows-Version benötigt). Mit Windows Version 10 geht das so nicht mehr.
Ich habe mir deshab folgende "Krücke" durch das Auslesen der Registry gebaut:

Code:

Type
  TWinOSType = ( win_UnknownPlatform,
                 win32_95, win32_98, win32_ME,
                 win32_NT, win32_2000, win32_XP,
                 win_Vista, win_Win7, win_Win8, win_Win10 );

function Windows10FromRegistry: Boolean;
var
  s: string;
begin
  Result := false;
  with TRegistry.Create(KEY_EXECUTE) do
  try
    RootKey := HKEY_LOCAL_MACHINE;
    if OpenKeyReadOnly('SOFTWARE\Microsoft\Windows NT\CurrentVersion') then
    try
      if ValueExists('CurrentVersion')
        then s := Readstring('CurrentVersion');
      if s = '6.3' then
        if ValueExists('CurrentBuildNumber')
          then s := Readstring('CurrentBuildNumber');
      Result := StrToIntDef(s,0) >= 10240;
    except
    end;
    CloseKey;
  finally
    Free;
  end;
end;

function GetWinOSType: TWinOSType;
begin
  Result := win_UnknownPlatform;
 case Win32Platform of
    VER_PLATFORM_WIN32_WINDOWS:// 1=9x-Reihe
      If Win32MajorVersion=4 Then
      Begin
        Case Win32MinorVersion of
          0 : result := win32_95;
          10: result:= win32_98;
          90: result:= win32_ME;
        end;
      end;
    VER_PLATFORM_WIN32_NT: // 2=NT-Reihe
     Case Win32MajorVersion of
         3:IF Win32MinorVersion=51 then
              result:= win32_NT;//'Windows NT 3.51';
         4:If Win32MinorVersion=0 then
             result:=  win32_NT; //'Windows NT 4';
         5:Case Win32MinorVersion of
              0: result:= win32_2000;
              1: result:= win32_xp; //'Windows XP';
              2: result:= win32_xp; //'Windows .NET Server';
           end;
         6:case Win32MinorVersion of
              0: result := win_Vista;
              1: Result := win_Win7;
//              2: Result := Result := win_Win8;
              2:Begin
                 Result := win_Win8;
                 if Windows10FromRegistry then
                   Result := win_Win10;
                End;
           end;
     End;
  end;
end;

Hat jemand eine Idee, wie man das eleganter "sicherer" darstellen kann? Für Eure Hilfe wäre ich dankbar.

Gruß Gerd

[jaenicke]

Es kann dir passieren, dass in Zukunft auch das nicht mehr funktioniert. Der Grund ist, dass Microsoft die Praxis ausmerzen möchte, dass auf die Windowsversion statt auf das benötigte Feature geprüft wird.
(Dass das sinnvoll ist, sehe ich im Übrigen genauso nachdem in der Vergangenheit oft Software nicht mehr funktioniert hat, weil nur die Windowsversion geprüft wurde...)

Das Auslesen der Windowsversion sollte aber auch klappen, wenn du per Manifest erklärst, dass deine Software Windowsversion 10 unterstützt. Denn Windows liefert nur bei neueren Windowsversionen als die unterstützte eine falsche Version zurück. Wenn deine Software die Version unterstützt, müsstest du auch die richtige bekommen.
Getestet habe ich das allerdings nicht, weil ich sauber auf die Features teste, die ich benötige...

[mm1256]

Hallo,

das ganze Plattform-Gedöns und die Winapi sind wertlos, wenn MS mit einer der nächsten Windows-Versionen wieder was Neues erfindet. Meine alten Programme die noch darauf setzen laufen z.B. bis heute munter weiter. Das ist gelinde gesagt Bockmi...

Da kann ich den Versions-Check gleich weglassen, oder als Alternative - weil die Infos in der Registry wohl so schnell nicht aussterben werden - die Info's gleich aus der Registry ziehen, und somit auch kompatibel zu jeder neuen Windows-Version sein.

@Gerd01 Darum würde ich einfach aus der Registry "ProductName" und "CurrentBuild" auswerten, und sonst nichts. Ich werde es jedenfalls meinen alten Code in Kürze in die Tonne treten und es so machen. Wir könnten ja hier mal eine Aktion starten, was bei "ProductName" so alles drin steht.

[Bernhard Geyer]

Die Lösung Major/Minor-Version geht immer noch. Du musst nur die verwendete Manifestdatei akualisieren und um einen kompatiblitätseintag für Win10 ergänzen. Ansonst läuft deine App im Win8 Kompatiblitätsmodus

[jus]

Zitat:

Zitat von jaenicke (Beitrag 1311466)

..Getestet habe ich das allerdings nicht, weil ich sauber auf die Features teste, die ich benötige...

Hallo jaenicke. Mich würde ernsthaft interessieren wie man auf die Features testet. Kannst du da mal ein Beispiel bringen?

Lg,
jus

[jaenicke]

Ein Beispiel:
Wenn ich die API Funktion GetServiceTimes verwende, benötigt man für das Programm mindestens XP mit SP3. Statt deshalb eine Prüfung einzubauen, ob es sich mindestens um XP mit SP3 handelt, prüfe ich einfach ob die benötigte Funktion da ist. Ist sie es nicht, fehlt sie mir, ergo zeige ich einen Fehler an, dass das System nicht unterstützt wird.

Das hat dann den Vorteil, dass es unter allen WindowsVersionen klappt, und zwar auch dann, wenn die Funktion später einmal entfernt würde...
Wenn man auf die Windowsversion prüft, bekommt man das nicht mit.

Auf diese Weise kann man auch, wenn möglich, nur bestimmte Module der Anwendung deaktivieren, wenn nur Teile der Anwendung das Feature brauchen.

[mm1256]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1311476)

Die Lösung Major/Minor-Version geht immer noch. Du musst nur die verwendete Manifestdatei akualisieren und um einen kompatiblitätseintag für Win10 ergänzen. Ansonst läuft deine App im Win8 Kompatiblitätsmodus

Um den Kompatibilitätsmodus geht es mir doch gar nicht. Klar, dass ich bei aktuellen Apps auch ein aktuelles Manifest brauche.

Du hast das ursächliche Problem auf das ich hinaus wollte nicht verstanden. Ich kann doch auf einer z.B. 5 Jahre alten und beim Kunden installierten Software nicht im Nachhinein das Manifest aktualisieren, nur um festzustellen, ob meine SW das laufende OS unterstützt. Das geht praktisch gar nicht. Demzufolge funktioniert die Versionsprüfung bei diesen Programmen nicht mehr, d.h. Win 8.1 wird nicht erkannt, denn ab dwMajorVersion = 6 und dwMinorVersion = 2 gibt's über GetVersionEx() keine aktuelle Build-Nummer mehr.

Eine Windows-Versions-Prüfung macht aber - aus meiner Sicht und für meine Zwecke - nur Sinn, wenn sie jetzt schon auch mit zukünftigen, also heute noch gar nicht auf dem Markt befindlichen Windows-Versionen klar kommt. Denn, wer weiß, was sich MS mit Win 11 wieder neu einfallen lässt? Und da ist der gemeinsame Nenner die Registry. Und wenn dann in ein paar Jahren meine jetzt aktuelle, zu dem Zeitpunkt aber schon wieder "veraltete" SW "ProductName=Windows 11" nicht kennt, dann ist das genau das, was ich brauche und erreichen will.

[Sir Rufo]

@mm1256

Dann weißt du aber nur, auf welchem OS deine Anwendung läuft, was dir wobei hilft? :gruebel:

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1311483)

Um den Kompatibilitätsmodus geht es mir doch gar nicht.

Doch. Geht es. Wenn eine Anwendung keinen Manifesteintrag hat läuft es zwangsweise im Kompatiblitätsmodus. Ist seit Vista so.

Zitat:

Zitat von mm1256 (Beitrag 1311483)

Du hast das ursächliche Problem auf das ich hinaus wollte nicht verstanden. Ich kann doch auf einer z.B. 5 Jahre alten und beim Kunden installierten Software nicht im Nachhinein das Manifest aktualisieren, nur um festzustellen, ob meine SW das laufende OS unterstützt.

Wieso nicht? CVS auf den entsprechenden Release-Tag stellen, auschecken, manifest erweitern, Compilieren (und signieren...).
oder einfach in der Exe per Ressourcenhacker das Manifest ergänzen.

Zitat:

Zitat von mm1256 (Beitrag 1311483)

Das geht praktisch gar nicht. Demzufolge funktioniert die Versionsprüfung bei diesen Programmen nicht mehr, d.h. Win 8.1 wird nicht erkannt, denn ab dwMajorVersion = 6 und dwMinorVersion = 2 gibt's über GetVersionEx() keine aktuelle Build-Nummer mehr.

Doch! Macht es. Wenn das manifest passt liefert GetVersionEx auch die Windows10-Versionsinfo. Steht auch genauso in der MSDN beschrieben.

Zitat:

Zitat von mm1256 (Beitrag 1311483)

Eine Windows-Versions-Prüfung macht aber - aus meiner Sicht und für meine Zwecke - nur Sinn, wenn sie jetzt schon auch mit zukünftigen, also heute noch gar nicht auf dem Markt befindlichen Windows-Versionen klar kommt. Denn, wer weiß, was sich MS mit Win 11 wieder neu einfallen lässt?

Dann macht eine Versionsprüfung keinen Sinn. Denn eine vorausschauende Prüfung funktioniert einfach nicht.

Zitat:

Zitat von mm1256 (Beitrag 1311483)

Und da ist der gemeinsame Nenner die Registry. Und wenn dann in ein paar Jahren meine jetzt aktuelle, zu dem Zeitpunkt aber schon wieder "veraltete" SW "ProductName=Windows 11" nicht kennt, dann ist das genau das, was ich brauche und erreichen will.

Wer sagt das MS (wie schon beim IE) hier nicht einfach auch nur bis Win10 den Wert reinschreibt? Dann bekommst du über diesen "gemeinsamen Nenner" auch nur eine Kompatiblitätsangabe.

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1311480)

Ein Beispiel:
Wenn ich die API Funktion GetServiceTimes verwende, benötigt man für das Programm mindestens XP mit SP3. Statt deshalb eine Prüfung einzubauen, ob es sich mindestens um XP mit SP3 handelt, prüfe ich einfach ob die benötigte Funktion da ist. Ist sie es nicht, fehlt sie mir, ergo zeige ich einen Fehler an, dass das System nicht unterstützt wird.

Wenn man das konsequent durchzieht besteht der Quellcode am Ende zu 90% aus Versionsprüfungen. Ob das ein vernünftiges Ziel ist?
Ich gehe bei MS davon aus das nur neue Funktionen dazukommen und abgekündigte Funktionen noch einige Zeit existieren. Seit dem wir nicht mehr Win9x existieren sind gefühlt 90% der Versionsprüfungen aus dem Quellcode rausgeflogen.
Bei Apple würde m.E. diese Prüfung auch nichts bringen da dann die Anwendung vermutlich gar nicht zugelassen würde. Da muss dann der Code ganz raus.

[mm1256]

Hallo Sir Rufo,

es kommt eben darauf an, was man mit der Versionsprüfung erreichen möchte. Wenn man wissen will, welche API-Aufrufe funzen oder auch nicht, was mir persönlich sowas von egal ist, weil wenn ich eine Version für ein OS freigegeben habe, dann hab ich das auch getestet, dann gibt es wie Sebastian schon angemerkt hat andere gute Möglichkeiten.

Mir geht es letztendlich darum, dass meine Software nicht auf Betriebssystemen laufen darf, mit denen ich meine SW nicht getestet und freigegeben habe. Das hat zwar auch technische Gründe, aber in erster Linie geht es um kommerzielle. Wenn eine SW von mir vor Baujahr 2004 (seitdem implementiere ich Versionskontrolle) heute noch auf Win 8.1 oder sogar auf Win 10 läuft, dann habe ich die zwar damals offensichtlich nicht schlecht programmiert, aber dafür kann ich mir nichts kaufen.

Genauso ärgerlich ist es jetzt, wenn meine SW damals von der Versionsprüfung für Win 8.0 ausgelegt, heute auf Win 8.1 und Win 10 problemlos läuft, weil eben immer die selbe Build dabei raus kommt. Und das ist - für mich - Mist.

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1311487)

Mir geht es letztendlich darum, dass meine Software nicht auf Betriebssystemen laufen darf, mit denen ich meine SW nicht getestet und freigegeben habe. Das hat zwar auch technische Gründe, aber in erster Linie geht es um kommerzielle. Wenn eine SW von mir vor Baujahr 2004 (seitdem implementiere ich Versionskontrolle) heute noch auf Win 8.1 oder sogar auf Win 10 läuft, dann habe ich die zwar damals offensichtlich nicht schlecht programmiert, aber dafür kann ich mir nichts kaufen.

Genauso ärgerlich ist es jetzt, wenn meine SW damals von der Versionsprüfung für Win 8.0 ausgelegt, heute auf Win 8.1 und Win 10 problemlos läuft, weil eben immer die selbe Build dabei raus kommt. Und das ist - für mich - Mist.

Also es geht dir darum das bei einem neuen PC beim Kunden du nochmal die Hand aufhalten willst um Geld zu kassieren - um es überspitzt zu formulieren.
WOW. Solche Beschränkungen kenne ich von Ingres (der Datenbank). Diese ist mittlerweile Geschichte. Vermutlich auch wegen zu kundenunfreundlicher Lizenzbedingungen. Willst du den gleichen Weg gehen?

Du willst erreichen das du über die Jahre auch für schon mal verkaufte SW Geld verlangst.
Üblicherweise macht man das mit Wartungsverträgen und Weiterentwicklung der SW. Viele Firmen (nicht nur seit man bei Adobe und Co. SW nur noch mieten und nicht mehr kaufen kann) machen damit einen erheblichen Teil ihres Umsatzes. Kunde zahlt pro Jahr 10-30% des Kaufpreises bekommt aber immer die neuesten Versionen mit Anpassungen an die neuesten Windows-/Office-/...-Versionen.
Eine übliche technische Vorkehrung um zu verhindern das der Kunde neue SW-Versionen sich "besorgt" ohne Wartung zu haben sind Lizenzserver und HW-Prüfungen. Sicherlich kann man alles umgehen wird aber je nach Kundenumfeld selten gemacht (wer will schon eine "Crack for XY" installieren, bei dem er zwar die SW umsonst bekommt, dafür aber andere "AddOns" bekommt die im Endeffekt viel teurer sind.

[Gerd01]

Zitat:

Zitat von Sir Rufo (Beitrag 1311484)

@mm1256

Dann weißt du aber nur, auf welchem OS deine Anwendung läuft, was dir wobei hilft? :gruebel:

Diese Bemerkung habe ich von dir an anderer Stelle auch gelesen. Lies dir doch wenigstens die Beiträge durch, dann weisst "was dir wobei hilft". Offengestanden gehen mir diese Typen auf den Senkel, die ihren Senf ohne Bezug zum Thema abgeben. So jetzt ist nun gut, voelleicht besserst du dich ja und trägst nun was Interessantes zum Thema bei.

Hallo Bernhard Geyer,
bitte rede doch nicht anderen Dein Geschäftsmodell ein. Im Übrigen trägt dein Beitrag nichts zum Thema bei und ist hier an dieser Stelle überflüssig.

P.S. Ich habe im Thread-Start schon geschrieben, das diese Frage bitte unterbleibt.

[Daniel]

Moin Gerd01,

Du kannst mit der Info natürlich machen, was Dir beliebt. Doch die Frage, WAS Du damit machst, sei gestattet. Es zwingt Dich ja niemand, sie zu beantworten, wenn Du es nicht möchtest.

[Willie1]

Hallo,
bin gerade auf Windows 10 umgestiegen. Um die Windows-Version aus einem eigenen Programm zu ermitteln, geht mit cmd.exe ver >ver.txt. Das liefert bei XP,Vista,7,8,8.1,10 das korrekte Ergebnis. Poershell kennt ver allerdings nicht. Wird es in Zukunft cmd noch geben?

Gruß Willie.

[mm1256]

Hallo Gerd01,

was hat dich den gebissen? Ich habe mit diesem Thema nicht angefangen, sondern lediglich auf die Frage von Sir Rufo geantwortet. Also überhaupt kein Grund, so zu reagieren. Oder mir zu unterstellen, dass ich die Beiträge nicht gelesen habe. Wenn also bei jemandem Verbesserungspotential vorhanden sein sollte, dann wohl eher bei dir. Ein Umgangston ist das manchmal hier :stupid:

[Daniel]

@mm1256:
Lies den Beitrag von Gerd nochmal genau, schaue, wer da zitiert wurde und um wen es in der zitierten Passage ging.
Dann beantworte die Frage, ob Gerd tatsächlich DIR unterstellt, nicht lesen zu können.
:roll:

[Gerd01]

Zitat:

Zitat von mm1256 (Beitrag 1311494)

Hallo Gerd01,

was hat dich den gebissen? Ich habe mit diesem Thema nicht angefangen, sondern lediglich auf die Frage von Sir Rufo geantwortet. Also überhaupt kein Grund, so zu reagieren. Oder mir zu unterstellen, dass ich die Beiträge nicht gelesen habe. Wenn also bei jemandem Verbesserungspotential vorhanden sein sollte, dann wohl eher bei dir. Ein Umgangston ist das manchmal hier :stupid:

Upps wieso fühlst du dich auf den Schlips getreten? Ich habe doch garnichts zu deinen Beiträgen gesagt, die sid doch beim Thema.

Ich habe mir lange überlegt, ob ich darauf Hinweise, das hier wieder Beiträge am Thema vorbei sind. Ich denke, nun ist deer Thread eh "tot", da man nun nichts mehr zum Thema liest.

Aber vielleicht versuche ich nochmal neu anzufangen. Ich habe ein Upgrade von Widows 8.1 Pro auf Windows 10 Pro. In meine Registry-Eintrag steht unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion

Zitat:

"SystemRoot"="C:\\WINDOWS"
"BuildBranch"="th1"
"CurrentBuild"="10240"
"CurrentMajorVersionNumber"=dword:0000000a
"CurrentMinorVersionNumber"=dword:00000000
"CurrentType"="Multiprocessor Free"
"CurrentVersion"="6.3"
"EditionID"="Professional"
"InstallationType"="Client"
"InstallDate"=dword:55c2702f
"ProductName"="Windows 10 Pro"
"RegisteredOrganization"=""
"SoftwareType"="System"
"UBR"=dword:0000401d
"PathName"="C:\\WINDOWS"
"ProductId"="00330-80000-00000-AA401"
"CurrentBuildNumber"="10240"
"BuildLab"="10240.th1.150729-1800"
"BuildLabEx"="10240.16412.amd64fre.th1.150729-1800"
"BuildGUID"="ffffffff-ffff-ffff-ffff-ffffffffffff"
"InstallTime"=hex(b):fb,0c,58,40,bc,cf,d0,01
"Customizations"="ModernApps"
"RegisteredOwner"="Gerd"

[Luckie]

Gibt es da nicht eine Funktion von Microsoft, mit der man testen kann, ob alle verwendeten Funktionen unterstützt werden? Wegen mir auch ein externes Tool, was die Funktionsaufrufe prüft. Weil sonst müsste ich ja jede API Funktion dynamisch versuchen zu laden. Das könnte recht aufwendig werden und ich kann mir nicht vorstellen, dass das die Lösung ist. Ich meine jedenfalls, dass ich mal so was gehört hätte. Ansonsten steht ja auch in der Doku ab welchem OS die Funktion unterstützt wird.

[Bernhard Geyer]

Zitat:

Zitat von Gerd01 (Beitrag 1311489)

Hallo Bernhard Geyer,
bitte rede doch nicht anderen Dein Geschäftsmodell ein. Im Übrigen trägt dein Beitrag nichts zum Thema bei und ist hier an dieser Stelle überflüssig.

Überflüssig? Na ja? Evtl. mal einen Schritt zurückgehen ob man das was du machst die Beste Lösung ist oder andere Lösungen (hier keine Benutzergängelung wegen OS-Update) besser wäre.
Aber das war nur ein Hinweis am Rande das man sich überlegen sollte ob es sinnvoll ist seine Kunde über solche "Features" zur Kasse zu bringen. Wenn das dein ist dann lassen wir diesen Aspekt einfach bleiben.

Zitat:

Zitat von Gerd01 (Beitrag 1311489)

P.S. Ich habe im Thread-Start schon geschrieben, das diese Frage bitte unterbleibt.

Du hast am Anfang geschrieben das deine Versionsprüfung nicht geht. Ich habe dir geschrieben wo der Fehler liegt und das deine Lösung eigentlich nicht sinnvoll ist.
Wenn das in Zukunft unterbleiben soll können wir Foren wie die DP Schließen. Da reicht ein Googeln um seine Lösung (Die im Ansatz nicht unbedingt die Beste ist) zu verbessern.
Das der Ansatz problematisch ist (Hinweis IE 11 der in der Registry immer noch eine 9.x-er Version ist) würdest du aber über Google nicht finden.

[Gerd01]

Also den Aufwand, die API zu testen, ob die Funktion noch existiert oder noch gültig ist wird niemand durchführen. Im Übrigen gibt es ja unter Windows 10 zum Beispiel die Function GetVersionEx noch. Sie liefert aber falsche Ergebnisse.

[mm1256]

@Gerd01 @Daniel ooops...jetzt, nach nochmaligem lesen...du hast wohl Sir Rufo gemeint und nicht mich. Bitte vielmals um Entschuldigung.

Kann es sein, dass meine mangelnde Konzentration an der Hitze liegt? Ich hab hier schon 34 Grad. :oops:

EDIT: Vielleicht nochmals zum eigentlichen Thema: Es ist zu erwarten, dass MS die Build-Nummern mit Win 10 jetzt in ziemlich kurzen Abständen hoch zählt. Ist das nicht ein weiterer guter Grund, zumindest die Registry-Einträge mit zu verwenden?

[Daniel]

Man muss natürlich aufpassen, dass man sich in der ganzen Prüferei nicht verliert.
Aber: Ich kann mir schon vorstellen, vom Betriebssystem eine Dienstleistung in Anspruch nehmen zu wollen und prüfe dann, ob die dafür benötigten Funktionen zu Verfügung stehen - oder eben nicht. Der Fokus läge dann auf dem Vorhandensein einer Funktionalität und nicht auf der Versionsnummer des Betriebssystems. Es wäre irrelevant, ob es Windows 95, 10, 8 oder 42 mit Servicepack 4 wäre.
Das kann in einigen Fällen flexibler sein - ich denke da an Windows Vista, welches nachträglich noch mal einen Satz an Funktionen via ServicePack erhalten hat.

[Bernhard Geyer]

Zitat:

Zitat von Gerd01 (Beitrag 1311501)

Im Übrigen gibt es ja unter Windows 10 zum Beispiel die Function GetVersionEx noch. Sie liefert aber falsche Ergebnisse.

Wie schon gesagt liefert GetVersionEx nicht die Falsche Info wenn man den passenden Manifesteintrag hat.
Was es mit diesen Eintrag auf sich hat wird hier erklärt: http://blogs.msdn.com/b/chuckw/archi...t-madness.aspx

Ohne Eintrag läuft deine App halt im Kompatiblitätsmodus. Das Verhalten ist schon seit Windows Vista so (Oder auch XP da ja dort das Manifest erstmal eingeführt wurde).

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1311502)

Es ist zu erwarten, dass MS die Build-Nummern mit Win 10 jetzt in ziemlich kurzen Abständen hoch zählt. Ist das nicht ein weiterer guter Grund, zumindest die Registry-Einträge mit zu verwenden?

Die Buildnummern sind nochmal ein eigener Eintrag. Diese hat früher nicht gestört und wird auch in Zukunft nicht stören.
Aber evtl. braucht man diese in Zukunft mehr wen MS die Aussage "Windows 10 wird die letzte Windows(Major)Version werden" und "Neue Features gibts nur bei Installation aller Updates" das man dann das Vorhandensein (und die funktionsfähigkeit) von Features über die Buildnummer bestimmen muss.
Aber lassen wir uns beim ersten Feature-Update überraschen was MS sich ausgedacht hat. Evtl. steht ja schon in den MSDN-Untiefen schon etwas beschrieben wie man das dann SW-Technisch unterscheidet.

[mm1256]

Zitat:

Zitat von Daniel (Beitrag 1311503)

Man muss natürlich aufpassen, dass man sich in der ganzen Prüferei nicht verliert.

YUPP - es kommt eben wie schon gesagt auf den Zweck an. Da ich ja heute zufällig an diesem Thema arbeite, anbei mal mein aktueller Stand. Nicht mehr als eine kleine kompakte Unit, so ähnlich stelle ich mir das vor, und vielleicht ist auch für Gerd eine Anregung dabei. Ist noch Beta-Status!! Wer mag, kann bei den noch offenen Strings gerne ergänzen.

[Sir Rufo]

Man bekommt im Übrigen die Versionsnummer auch heraus, wenn man die Versionsnummer der kernel32.dll ausliest. Die sollte eigentlich immer mit der Version konform gehen und auch immer vorhanden sein.

Nur für den Fall, das jemand eine Versionsnummer benötigt und sich nicht auf die Registry verlassen möchte und sich auch nicht von

Delphi-Quellcode:

GetVersionEx

täuschen lassen möchte (die im Übrigen in genau dieser kernel32.dll ihre Heimat hat).

Nachtrag

Eine kurze Recherche auf den MS-Seiten bringt dann Folgendes zu Tage:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms724429%28v=vs.85%29.aspx

To obtain the full version number for the operating system, call the GetFileVersionInfo function on one of the system DLLs, such as Kernel32.dll, then call VerQueryValue to obtain the \\StringFileInfo\\<lang><codepage>\\ProductVersion subblock of the file version information.

;)

[mm1256]

Gut recherchiert Sir Rufo ! :thumb:

Auf den Trichter bin ich früher übrigens auch schon mal gekommen, aber die OS-Version bekommt man hierüber auch wieder nur über den Key "ProductVersion" und über die Umwege des Zerlegens und Auswertens der ProductVersion (MajorVersion.MinorVersion.Build).

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1311524)

Man bekommt im Übrigen die Versionsnummer auch heraus, wenn man die Versionsnummer der kernel32.dll ausliest. Die sollte eigentlich immer mit der Version konform gehen und auch immer vorhanden sein.

Nur für den Fall, das jemand eine Versionsnummer benötigt und sich nicht auf die Registry verlassen möchte und sich auch nicht von

Delphi-Quellcode:

GetVersionEx

täuschen lassen möchte (die im Übrigen in genau dieser kernel32.dll ihre Heimat hat).

Das ist aber auch nur der aktuelle Stand. Wenn in 5 Jahren MS die kernel32.dll aufgibt und diese in eine andere DLL verlagert klappt es damit auch wieder nicht.
Und falls jemand als Gegenargument liefert: Aber in den Delphi-Sourcen steht doch das die Funktion in kernel32 liegt. Windows kann den Ladeprozess bei benötigten DLLs umbiegen. In der Exe steht "kernel32.dll wird benötigt", Windows lädt dann aber "superduper32.dll".

Die Wahrscheinlichkeit ist zwar gering das das passiert, aber ausgeschlossen ist das nicht.

[bepe]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1311530)

Das ist aber auch nur der aktuelle Stand. Wenn in 5 Jahren MS die kernel32.dll aufgibt und diese in eine andere DLL verlagert klappt es damit auch wieder nicht.
Und falls jemand als Gegenargument liefert: Aber in den Delphi-Sourcen steht doch das die Funktion in kernel32 liegt. Windows kann den Ladeprozess bei benötigten DLLs umbiegen. In der Exe steht "kernel32.dll wird benötigt", Windows lädt dann aber "superduper32.dll".

Die Wahrscheinlichkeit ist zwar gering das das passiert, aber ausgeschlossen ist das nicht.

:-D Ist das dein Ernst? Mal abgesehen davon, dass wir von Windows reden, das ist immerhin bis in die Steinzeit abwärtskompatibel, dürfte ich mit dem "Argument" gar keine Software mehr schreiben. Immerhin könnten sich alle dokumentierten Funktionen mal ändern.

Benutz ja nicht die Bremse! In autonomen Fahrzeugen wird es vielleicht keine geben. Also gewöhn dich nicht daran.

(Sorry, aber das absurd breite Grinsen hat mich zu diesem Post gezwungen.)

[Sir Rufo]

Und was machen wir, wenn morgen ein Klavier auf den Rechner fällt? Wie kommen wir dann an diese Information? Oder was machen wir, wenn der Rechner geklaut wurde?

Irgendwo muss man mal den Zopf abschneiden und ein Ei drauf schlagen.

Dass die Informationen nicht mehr in der Registry stehen oder

Delphi-Quellcode:

GetVersionEx

gefakte Informationen herausgibt (so ist es ja) ist wesentlich wahrscheinlicher, als dass ein Zugriff auf die kernel32.dll nicht mehr funktioniert.

Und wenn das so sein sollte, dann funktioniert nicht nur die eigene Anwendung nicht mehr, sondern 99% der anderen auch nicht mehr. Man ist also nicht alleine ;)

[jaenicke]

Zitat:

Zitat von Sir Rufo (Beitrag 1311534)

Und wenn das so sein sollte, dann funktioniert nicht nur die eigene Anwendung nicht mehr, sondern 99% der anderen auch nicht mehr. Man ist also nicht alleine ;)

Im Gegenteil, es funktioniert nur die Software nicht mehr, die sich auf irgendwelchen komischen Wegen eine unbedingt korrekte Versionsnummer holt und damit absichtlich neue Windowsversionen nicht unterstützt.
Das ist noch einmal die verschärfte Variante davon, die vor einigen Jahren vor Gericht gelandet ist, bei der die Versionsprüfung der Software aus Versehen neue Windowsversionen ausgeschlossen hat. Selbst da wurde der Hersteller dazu verurteilt diesen Fehler zu beheben... leider finde ich das entsprechende Urteil bzw. die Berichte dazu grad nicht. Ist schon ein paar Jahre her.

[Bernhard Geyer]

Zitat:

Zitat von bepe (Beitrag 1311533)

:-D Ist das dein Ernst? Mal abgesehen davon, dass wir von Windows reden, das ist immerhin bis in die Steinzeit abwärtskompatibel, dürfte ich mit dem "Argument" gar keine Software mehr schreiben. Immerhin könnten sich alle dokumentierten Funktionen mal ändern.

Borland ist mit Delphi genau in diese Falle gelaufen. Siehe http://entwickler-forum.de/showthrea...ll-geladen-ist

[mensch72]

Den Weg über VerionInfoResourcen von User32.dll und Kernel32.dll sowie ein paar weiterer für mich wichtiger MS-Dateien verwende ich auch, und sogar wenn möglich "hart", also mit einer eigenen Routine zum direktem Auslesen der Resource mit den Versionsinfos.

Auch wenn hier viele es aus funktionaler Anwendersicht sehen, auch ich definiere in meinen Verträgen als "Leistungsgarantie" nur die Funktion in der zum Zeitpunkt der Übergabe aktuellen Systemumgebung.
(Es gab da mal vor laaanger Zeit ein NT4 Update/ServicePack, was "nebenbei" gar manche TCPIP Kommunikation gestört oder beeinflusst hat oder danach noch ein paar Updates für ADO/OLEDB Datenbankzeug... SageKHK ist da auch gern abundzu betroffen)

Im Banken/Finanz & Industrieumfeld ist es also durchaus üblich, Software "fix" für eine definierte Softwareumgebung zu verkaufen, und die Programmausführung nach/für Systemupdates erst auf Anforderung und eigener Testfreigabe (und gegen Entgeld) zu erlauben. Speziell im Netzwerkbereich wurde MS immer besser. Aber wenn ich meine alte Software im Millisekundenbereich mit viel Mühe damals genau darauf optimiert habe, nützt mit in Win10 eine nun selbst optimal funktionierende Lösung für den gleichen API Call garnix, wenn Win10 per VersionInfoApi mir sagen würde, es ist noch ein Win7.

Klar kann man mit NEUEN Manifestdateien Win10 dazu bewegen, sich auch per API sauber zu melden, das nützt alten Programmen aber gar nix. Und genau da soll ja wenigstens eine Warnung möglich sein, das der Anwender nun das System nun voll auf eigenes Risiko ohne die nur für die alte OS-Version geltenden (und NUR dafür bezahlten) Support Ansprüche betreibt.
Ich verhindere bis jetzt da absichtlich nicht die (Weiter)Nutzung, nur lasse ich mir bei Problemen dann jegliche Analyse und den Support auch separat bezahlen.

[Luckie]

Alte Programme, die geschrieben worden bevor es Windows XYZ gab, erkennen die neuen Windows Versionen doch eh nicht. Also sollte die Ausgabe "Unbekannte Windows Version" sein. Und wenn das der Fall ist, kannst du sagen: "OK, Benutzung auf eigenes Risiko. Für diese Windows Version ist das Programm nicht getestet."

[mm1256]

Zitat:

Zitat von Luckie (Beitrag 1311544)

... "OK, Benutzung auf eigenes Risiko. Für diese Windows Version ist das Programm nicht getestet."

Das hatten wir auch schon. Da hat der Kunde seinen Hardwarelieferanten - der gleichzeitig auch einer meiner Vertriebspartner ist - beauftragt meine Software zu installieren, die aber damals nicht für XP freigegeben war. Dann wurde Monate später festgestellt, dass eine Datei der Datenbank defekt ist. Das Problem bzw. die Ursache war die Datenbank. Dummerweise musste daraufhin eine komplette Inventur neu gemacht werden und einiges mehr. Schaden über 30.000 Euro. Und wer hat das dann bezahlt? Ich, bzw. meine Versicherung, weil der Richter der Meinung war, ein einfacher Hinweis reicht für den Anwender nicht aus, die Tragweite der möglichen Folgen erkennen zu können.

Wie in einem vorherigen Beitrag schon angemerkt, man muss die Versionsprüfung und den Umgang damit immer im Zusammenhang mit der Branche sehen, und mit dem Einsatzzweck. Wenn ein Telefonbuch eine falsche Telefonnummer anzeigt, dann wählt der User halt mal eine falsche Nummer. Was solls. Aber wenn eine Finanzsoftware Fehler verursacht dann ist das einfach eine andere Liga, die entsprechend mit anderen Maßstäben beurteilt werden muss.

[Gerd01]

Ich habe den Gedanken von Sir Rufos, die Productversion von kernel32.dll zu prüfen, mal aufgegriffen und eine Abfrage meiner kernerl32.dll gemacht.

Code:

C:\Windows\System32\kernel32.dll
FFI: Product Version: 10.0.10240.16384
FFI: File Version: 6.2.10240.16384
Number of Translations: 1
Translation: 040704B0
  Comments = ""
  CompanyName = "Microsoft Corporation"
  FileDescription = "Client-DLL für Windows NT-Basis-API"
  FileVersion = "10.0.10240.16384 (th1.150709-1700)"
  InternalName = "kernel32"
  LegalCopyright = "© Microsoft Corporation. Alle Rechte vorbehalten."
  LegalTrademarks = ""
  OriginalFilename = "kernel32"
  PrivateBuild = ""
  ProductName = "Betriebssystem Microsoft® Windows®"
  ProductVersion = "10.0.10240.16384"
  SpecialBuild = ""

Also in der Productversion kann man Major,Minor und Build auslesen. Nur die Frage ist, wie sicher ist das für andere Versionen? Ich werde mal weiter recherchieren.

[Sir Rufo]

Beitrag #27 -> Nachtrag

[Bernhard Geyer]

Zitat:

Zitat von mm1256 (Beitrag 1311545)

Zitat:

Zitat von Luckie (Beitrag 1311544)

... "OK, Benutzung auf eigenes Risiko. Für diese Windows Version ist das Programm nicht getestet."

Das hatten wir auch schon. Da hat der Kunde seinen Hardwarelieferanten - der gleichzeitig auch einer meiner Vertriebspartner ist - beauftragt meine Software zu installieren, die aber damals nicht für XP freigegeben war. Dann wurde Monate später festgestellt, dass eine Datei der Datenbank defekt ist. Das Problem bzw. die Ursache war die Datenbank. Dummerweise musste daraufhin eine komplette Inventur neu gemacht werden und einiges mehr. Schaden über 30.000 Euro. Und wer hat das dann bezahlt? Ich, bzw. meine Versicherung, weil der Richter der Meinung war, ein einfacher Hinweis reicht für den Anwender nicht aus, die Tragweite der möglichen Folgen erkennen zu können.

Bei solchen Hintergrund ist es klar das du hier natürlich versuchst eine harte Bremse einzuziehen. Hat den der Kunde den auch Wartung oder ähnliche? Oder hatte er es vor Jahren gekauft und du solltest jetzt über allgemein Produkthaftung dafür gerade stehen (auch wenn du entsprechende Klauseln im Lizenzvertrag hattest)?
Das Urteil ist damit aber sehr ungewöhnlich. Du hast ja damals gar nicht wissen können wie sich Jahre später neuere Windows-Versionen verhalten.
Die Details der Urteilsbegründung wären hier sehr interessant.

[markus5766h]

Zitat:

Zitat von Willie1 (Beitrag 1311493)

Hallo,
bin gerade auf Windows 10 umgestiegen. Um die Windows-Version aus einem eigenen Programm zu ermitteln, geht mit cmd.exe ver >ver.txt. Das liefert bei XP,Vista,7,8,8.1,10 das korrekte Ergebnis. Poershell kennt ver allerdings nicht. Wird es in Zukunft cmd noch geben?

Gruß Willie.

Hallo,
unter PowerShell ist es winver