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.