15/07/2012
I Microsofts komplekse og stadigt udviklende økosystem er det afgørende for både udviklere og IT-professionelle at have de rette værktøjer og den korrekte viden. To centrale områder, der ofte skaber spørgsmål, er valget af det rigtige udviklerabonnement, såsom MSDN Platforms, og den korrekte måde at identificere og interagere med forskellige versioner af Windows-operativsystemet. At navigere korrekt i disse emner kan være forskellen mellem en applikation, der kører problemfrit på tværs af systemer, og en, der fejler uventet. Denne artikel vil guide dig gennem, hvad MSDN Platforms tilbyder, og hvem det er for, samt dykke ned i de bedste praksisser for at arbejde med Windows-versioner, hvor fokus ligger på robust funktionsdetektion frem for simpel versionskontrol.

Hvad er MSDN Platforms, og hvem er det for?
Før man investerer i et værktøj, er det vigtigt at forstå, om det passer til ens behov. MSDN Platforms er et specialiseret abonnement fra Microsoft, der er designet til en bestemt gruppe af tekniske fagfolk. Det er ikke en alt-i-en-løsning for alle, men snarere et målrettet tilbud.
Men er MSDN Platforms det rigtige valg for dig? Svaret er ja, hvis du tilhører en af følgende grupper:
- Udviklere på tværs af platforme: Hvis du primært arbejder med Java, iOS eller macOS og udvikler applikationer til web, skyen eller Windows, men ikke har brug for det fulde Visual Studio IDE (Integrated Development Environment), så er MSDN Platforms skræddersyet til dig. Det giver dig den nødvendige adgang til Microsofts software uden at binde dig til Visual Studio.
- IT-professionelle: Har du brug for at oprette, administrere og teste udviklings- og testmiljøer? MSDN Platforms tilbyder en omkostningseffektiv og omfattende adgang til et bredt udvalg af Microsoft-software og -tjenester, hvilket gør det muligt at simulere produktionsmiljøer og sikre kompatibilitet.
- Forretnings- og driftsroller: Personer i forretningsroller, der har brug for at gennemgå, tilgå og deltage i applikationsudviklingsprocessen, kan også drage fordel af dette abonnement. Det giver dem adgang til de nødvendige ressourcer for at kunne evaluere og teste applikationer uden at skulle have en fuld udviklerlicens.
Det er vigtigt at bemærke, at MSDN Platforms udelukkende er tilgængeligt via Microsofts volumenlicensprogrammer. For at få oplysninger om priser og købsmuligheder skal du kontakte din Microsoft-kontorepræsentant, en Microsoft Partner eller en autoriseret forhandler af volumenlicenser.
Forståelse af Windows Operativsystemversioner
At kende den specifikke version af det Windows-operativsystem, en applikation kører på, kan virke som en simpel opgave. Men virkeligheden er mere nuanceret. Microsoft bruger et internt versionsnummer til at identificere hver udgivelse. At forstå disse numre er det første skridt, men som vi vil se senere, er det sjældent den bedste metode til at sikre applikationskompatibilitet.
Nedenfor er en tabel, der opsummerer de seneste operativsystemers versionsnumre. Disse numre hentes typisk via Version API Helper-funktionerne i Windows.
Tabel over Windows Versionsnumre
| Operativsystem | Versionsnummer |
|---|---|
| Windows 11 | 10.0* |
| Windows 10 | 10.0* |
| Windows Server 2022 | 10.0* |
| Windows Server 2019 | 10.0* |
| Windows Server 2016 | 10.0* |
| Windows 8.1 | 6.3* |
| Windows Server 2012 R2 | 6.3* |
| Windows 8 | 6.2 |
| Windows Server 2012 | 6.2 |
| Windows 7 | 6.1 |
* En vigtig note: For applikationer, der ikke er specifikt "manifesteret" for Windows 8.1 eller Windows 10, vil operativsystemet returnere Windows 8-versionen (6.2) for at opretholde bagudkompatibilitet. For at få det korrekte versionsnummer skal din applikation indeholde et manifest, der angiver kompatibilitet med de nyere versioner.
Den Bedste Praksis: Feature-detektion frem for Versionskontrol
Selvom tabellen ovenfor er informativ, er det generelt en dårlig idé at basere din applikations logik på operativsystemets versionsnummer. Hvorfor? Fordi nye funktioner kan blive tilføjet til et operativsystem via redistribuerbare DLL-filer (Dynamic Link Libraries) eller service packs. En ældre version af Windows kan derfor have en funktion, som du fejlagtigt antager kun findes i nyere versioner. Den mest robuste og fremtidssikre metode er at teste direkte for tilstedeværelsen af den specifikke funktion, din applikation har brug for.

Her er nogle af de mest almindelige teknikker til funktionsdetektion:
1. Dynamisk indlæsning af funktioner
Den mest direkte metode er at tjekke, om en bestemt funktion eksisterer i en system-DLL. Dette gøres typisk i to trin:
- Brug funktionen
LoadLibrarytil at indlæse den relevante system-DLL i din applikations hukommelse. - Brug derefter funktionen
GetProcAddresstil at hente adressen på den funktion, du vil kalde. HvisGetProcAddressreturnerer en gyldig pointer, eksisterer funktionen, og du kan kalde den. Hvis den returnerer NULL, findes funktionen ikke på systemet, og din applikation kan håndtere dette elegant (f.eks. ved at deaktivere en bestemt funktionalitet).
Vær opmærksom på, at selvom en funktion er til stede, kan den være en "stub", der blot returnerer en fejlkode som ERROR_CALL_NOT_IMPLEMENTED. God fejlkontrol efter kaldet er derfor stadig vigtigt.
2. Systemmålinger med GetSystemMetrics
For visse systemdækkende egenskaber kan du bruge funktionen GetSystemMetrics. Denne funktion kan give information om alt fra skærmopløsning til systemkonfigurationer. For eksempel kan du tjekke, om systemet har flere skærme ved at kalde GetSystemMetrics(SM_CMONITORS). Dette er en langt mere pålidelig metode end at gætte baseret på OS-versionen.
3. Versionering af Shell og Common Controls
Mange af de visuelle elementer i Windows, såsom knapper, menuer og fil-dialogbokse, styres af redistribuerbare DLL'er. For at afgøre, hvilke specifikke UI-funktioner der er tilgængelige, er det nødvendigt at tjekke versionen af disse specifikke biblioteker, f.eks. ComCtl32.dll, i stedet for hele operativsystemet.
Fremtidssikring af Din Applikation
Når du udvikler software, er det afgørende at tænke langsigtet. At låse din applikation til en specifik OS-version er en opskrift på problemer i fremtiden.
- Sigt efter en minimumsversion: Hvis du absolut er nødt til at kræve et bestemt operativsystem, så specificer det som den lavest understøttede version, ikke den eneste. På den måde vil din detektionskode fortsat fungere korrekt på fremtidige versioner af Windows.
- Håndtering af 32-bit vs. 64-bit: For en 32-bit applikation, der kører på et 64-bit Windows-system (via WOW64-emuleringslaget), kan du bruge funktionen
IsWow64Processtil at afgøre dette. Dette kan være vigtigt, f.eks. når du interagerer med filsystemet eller registreringsdatabasen. For yderligere information om processoren kan du kaldeGetNativeSystemInfo.
Ofte Stillede Spørgsmål (OSS)
- Spørgsmål: Hvorfor returnerer min app Windows 8-versionen (6.2), selvom den kører på Windows 11?
- Svar: Dette sker sandsynligvis, fordi din applikation ikke har et manifest, der erklærer kompatibilitet med Windows 10 eller 11. Uden dette manifest kører Windows din app i en kompatibilitetstilstand, der rapporterer version 6.2 for at undgå at ødelægge ældre software, der udfører ukorrekte versionskontroller.
- Spørgsmål: Er MSDN Platforms det rigtige for mig, hvis jeg bruger Visual Studio dagligt?
- Svar: Nej, sandsynligvis ikke. MSDN Platforms er specifikt designet til dem, der ikke har brug for det fulde Visual Studio IDE. Hvis du er en Visual Studio-udvikler, vil et standard Visual Studio-abonnement (tidligere også kendt som MSDN-abonnementer) være et bedre og mere omfattende valg for dig, da det inkluderer IDE'et.
- Spørgsmål: Hvad er den absolut sikreste måde at tjekke for en funktion?
- Svar: Den sikreste og mest anbefalede metode er at undgå versionskontrol helt og i stedet teste direkte for den funktion, du har brug for. Brug en kombination af
LoadLibraryogGetProcAddressfor at se, om en funktion kan kaldes. Dette gør din kode robust, fremtidssikret og uafhængig af specifikke OS-udgivelser.
Hvis du vil læse andre artikler, der ligner MSDN og Windows Versioner: En Teknisk Guide, kan du besøge kategorien Teknologi.
