Arkiv: Certifieringskrav för Windows Desktop Apps v1.2
Dokumentversion: 1.2
Dokumentdatum: 31 maj 2012
Det här dokumentet innehåller de tekniska krav och behörighetskrav som en skrivbordsapp måste uppfylla för att kunna delta i Certifieringsprogrammet för Windows 8 Desktop-appar. För Windows 7 kallades det här programmet för Windows Software Logo Program.
Välkommen!
Windows-plattformen stöder ett brett ekosystem av produkter och partner. Att visa Windows-logotypen på din produkt representerar en relation och ett delat engagemang för kvalitet mellan Microsoft och ditt företag. Kunderna litar på Windows-varumärket på din produkt eftersom det säkerställer att det uppfyller kompatibilitetsstandarder och fungerar bra på Windows-plattformen. Genom att skicka Windows App Certification kan din app visas i Windows Compatibility Center och det är också ett nödvändigt steg för att visa en referens för skrivbordsappen i Windows Store.
Certifieringsprogrammet för Windows-appar består av program och tekniska krav för att säkerställa att appar från tredje part som kör Windows-varumärket både är enkla att installera och tillförlitliga på datorer som kör Windows. Kunderna värdesätter stabilitet, kompatibilitet, tillförlitlighet, prestanda och kvalitet i de system de köper. Microsoft fokuserar sina investeringar för att uppfylla dessa krav för programappar som är utformade för att köras på Windows-plattformen för datorer. Dessa ansträngningar omfattar kompatibilitetstester för konsekvens i upplevelsen, bättre prestanda och förbättrad säkerhet på datorer som kör Windows-programvara. Microsofts kompatibilitetstester har utformats i samarbete med branschpartner och förbättras kontinuerligt som svar på branschutvecklingen och konsumenternas efterfrågan.
Certifieringspaketet för Windows-appar används för att verifiera efterlevnaden av dessa krav och ersätter den WSLK som används för validering i Windows 7 Software Logo-programmet. Certifieringspaketet för Windows-appar är en av komponenterna som ingår i Windows Software Development Kit (SDK).
Appberättigande
För att en app ska kvalificera sig för Windows 8 Desktop App Certification måste den uppfylla följande kriterier och alla tekniska krav som anges i det här dokumentet.
- Det måste vara en fristående app
- Den måste köras på en lokal Windows 8.1-dator
- Det kan vara en klientkomponent i en certifierad Windows Server-app
- Det måste vara kod och funktion slutfört
1. Appar är kompatibla och motståndskraftiga
De tider då en app kraschar eller slutar svara orsakar mycket användar frustration. Appar förväntas vara motståndskraftiga och stabila och eliminera sådana fel bidrar till att säkerställa att programvaran är mer förutsägbar, underhållsbar, högpresterande och tillförlitlig.
- 1.1 Appen får inte vara beroende av Windows-kompatibilitetslägen, AppHelp-meddelande och eller andra kompatibilitetskorrigeringar
1.2 Appen får inte vara beroende av VB6-körningen
1.3 Appen får inte läsa in godtyckliga DLL:er för att avlyssna Win32 API-anrop med HKLM\Software\Microsoft\Windows NT\CurrentVersion\Windows AppInit_dlls.
2. Appar måste följa bästa praxis för Windows-säkerhet
Med hjälp av metodtips för Windows-säkerhet kan du undvika att skapa exponering för Windows-attackytor. Attackytor är startpunkterna som en angripare kan använda för att utnyttja operativsystemet genom att dra nytta av sårbarheter i målprogramvaran. En av de värsta säkerhetsriskerna är utökade privilegier.
- 2.1 Appen måste använda starka och lämpliga ACL:er för att skydda körbara filer 2.2 Appen måste använda starka och lämpliga ACL:er för att skydda kataloger 2.3 Appen måste använda starka och lämpliga CL:er för att skydda registernycklar 2.4 Appen måste använda starka och lämpliga ACL:er för att skydda kataloger som innehåller objekt 2.5 Appen måste minska icke-administratörsåtkomsten till tjänster som är sårbara för manipulering 2.6 Din app måste förhindra att tjänster med snabba omstarter startar om mer än två gånger var 24:e timme
Certifieringsprogrammet för Windows-appar kontrollerar att Windows-attackytor inte exponeras genom att verifiera att ACL:er och tjänster implementeras på ett sätt som inte utsätter Windows-systemet för risk.
3. Appar stöder Windows-säkerhetsfunktioner
Windows-operativsystemet har många funktioner som stöder systemsäkerhet och sekretess. Appar måste ha stöd för dessa funktioner för att upprätthålla operativsystemets integritet. Felaktigt kompilerade appar kan orsaka buffertöverskridanden som i sin tur kan orsaka överbelastning eller tillåta körning av skadlig kod.
- 3.1 Din app får inte använda AllowPartiallyTrustedCallersAttribute (APTCA) för att säkerställa säker åtkomst till starkt namngivna sammansättningar
3.2 Din app måste kompileras med flaggan /SafeSEH för att säkerställa säker undantagshantering
3.3 Appen måste kompileras med flaggan /NXCOMPAT för att förhindra datakörning
3.4 Appen måste kompileras med hjälp av /DYNAMICBASE-flaggan för slumpmässig adressutrymmeslayout (ASLR)
3.5 Appen får inte läsa/skriva de delade PE-avsnitten
4. Appar måste följa systemomstartshanterarens meddelanden
När användare initierar avstängning har de vanligtvis en stark önskan om att avstängningen ska lyckas. de kan ha bråttom att lämna kontoret och bara vill att deras datorer ska stänga av. Appar måste respektera denna önskan genom att inte blockera avstängning. I de flesta fall kanske en avstängning inte är kritisk, men appar måste vara förberedda för risken för en kritisk avstängning.
- 4.1 Din app måste hantera kritiska avstängningar på lämpligt sätt
- Vid en kritisk avstängning skickas appar som returnerar FALSE till WM_QUERYENDSESSION WM_ENDSESSION och stängs, medan de som överskrider tidsgränsen som svar på WM_QUERYENDSESSION avslutas.
- WM\_QUERYENDSESSION med LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Konsolappar kan anropa SetConsoleCtrlHandler för att ange den funktion som ska hantera avstängningsmeddelanden. Tjänstappar kan anropa RegisterServiceCtrlHandlerEx för att ange den funktion som ska ta emot avstängningsmeddelanden.
- WM\_ENDSESSION med LPARAM = ENDSESSION\_CLOSEAPP(0x1).
Appen bör åtminstone förberedas genom att spara användardata och ange den information som behövs efter en omstart.
5. Appar måste ha stöd för en ren och reversibel installation
Med en ren, reversibel installation kan användarna hantera (distribuera och ta bort) appar på sina system.
- 5.1 Appen måste implementera en ren och reversibel installation på rätt sätt
- DisplayName
- InstallLocation
- Förläggare
- UninstallString
- VersionMajor eller MajorVersion
- VersionMinor eller MinorVersion
- Om installationen misslyckas bör appen kunna återställa den och återställa datorn till sitt tidigare tillstånd.
- Omstart av datorn bör aldrig vara det enda alternativet i slutet av en installation eller uppdatering. Användare bör ha möjlighet att starta om senare.
- Windows inventeringsverktyg och telemetriverktyg kräver fullständig information om installerade appar. Om du använder ett MSI-baserat installationsprogram skapar MSI automatiskt registerposterna nedan. Om du inte använder ett MSI-installationsprogram måste installationsmodulen skapa följande registerposter under installationen:
6. Appar måste signera filer och drivrutiner digitalt
Med en digital Authenticode-signatur kan användarna vara säkra på att programvaran är äkta. Det gör också att man kan identifiera om en fil har manipulerats, till exempel om den har smittats av ett virus. Kodsignering i kernelläge är en Windows-funktion som kallas kodintegritet (CI), vilket förbättrar säkerheten i operativsystemet genom att verifiera integriteten för en fil varje gång avbildningen av filen läses in i minnet. CI identifierar om skadlig kod har ändrat en binär systemfil. Genererar också en diagnostik- och systemgranskningslogghändelse när signaturen för en kernelmodul inte kan verifieras korrekt.
- 6.1 Alla körbara filer (.exe, .dll, .ocx, .sys, .cpl, .drv, .scr) måste signeras med ett Authenticode-certifikat
6.2 Alla drivrutiner i kernelläge som installeras av appen måste ha en Microsoft-signatur som hämtas via Windows maskinvarucertifieringsprogram. Alla filterdrivrutiner för filsystemet måste signeras av Microsoft.
6.3 Undantag och undantag
- Undantag kommer endast att övervägas för osignerade omdistribuerbara objekt från tredje part, exklusive drivrutiner. Ett meddelandebevis som begär en signerad version av de omdistribuerbara omdistribueringsbara objekten krävs för att detta undantag ska beviljas.
7. Appar blockerar inte installation eller appstart baserat på en versionskontroll av operativsystemet
Det är viktigt att kunderna inte blockeras artificiellt från att installera eller köra sin app när det inte finns några tekniska begränsningar. Om appar i allmänhet har skrivits för Windows Vista eller senare versioner av Windows bör de inte behöva kontrollera operativsystemversionen.
- 7.1 Appen får inte utföra versionskontroller för likhet
- Appar som levereras som ett paket som också körs på Windows XP, Windows Vista och Windows 7, och som behöver kontrollera operativsystemversionen för att avgöra vilka komponenter som ska installeras på ett visst operativsystem.
- Appar som endast kontrollerar den lägsta versionen av operativsystemet (endast under installation, inte vid körning) med hjälp av endast godkända API-anrop och som korrekt anger minimikravet för version i appmanifestet.
- Säkerhetsappar (antivirus, brandvägg osv.), systemverktyg (till exempel defrag, säkerhetskopior och diagnostikverktyg) som kontrollerar operativsystemversionen med hjälp av endast godkända API-anrop.
- Om du behöver en specifik funktion kontrollerar du om själva funktionen är tillgänglig. Om du behöver Windows XP söker du efter Windows XP eller senare (>= 5.1). På så sätt fortsätter identifieringskoden att fungera i framtida versioner av Windows. Drivrutinsinstallationer och avinstallationsmoduler bör aldrig kontrollera operativsystemversionen.
8. Appar läser inte in tjänster eller drivrutiner i felsäkert läge
Med felsäkert läge kan användare diagnostisera och felsöka Windows. Drivrutiner och tjänster får inte vara inställda på att läsas in i felsäkert läge om de inte behövs för grundläggande systemåtgärder, till exempel drivrutiner för lagringsenheter eller för diagnostik- och återställningsändamål, till exempel antivirusskannrar. När Windows är i felsäkert läge startar det som standard bara de drivrutiner och tjänster som förinstallerades med Windows.
- 8.1 Undantag och undantag
- Drivrutiner och tjänster som måste startas i felsäkert läge kräver ett undantag. Begäran om undantag måste innehålla varje tillämplig drivrutin eller tjänst som skriver till SafeBoot-registernycklarna och beskriva de tekniska orsakerna till att appen eller tjänsten måste köras i felsäkert läge. Appinstallationsprogrammet måste registrera alla sådana drivrutiner och tjänster med hjälp av dessa registernycklar:
Obs! Du måste testa dessa drivrutiner och tjänster för att säkerställa att de fungerar i felsäkert läge utan fel.
9. Appar måste följa riktlinjerna för användarkontokontroll
Vissa Windows-appar körs i säkerhetskontexten för ett administratörskonto, och appar begär ofta överdrivna användarrättigheter och Windows-privilegier. Genom att kontrollera åtkomsten till resurser kan användarna ha kontroll över sina system och skydda dem mot oönskade ändringar. En oönskad ändring kan vara skadlig, till exempel en rootkit som tar kontroll över datorn eller är resultatet av en åtgärd som utförs av personer som har begränsade privilegier.. Den viktigaste regeln för att kontrollera åtkomsten till resurser är att tillhandahålla den minsta mängd åtkomststandardanvändarkontext som krävs för att en användare ska kunna utföra sina nödvändiga uppgifter. Genom att följa UAC-riktlinjerna (user account control) får appen nödvändiga behörigheter när de behövs av appen, utan att systemet ständigt exponeras för säkerhetsrisker. De flesta appar kräver inte administratörsbehörighet vid körning och bör vara helt okej att köra som standardanvändare.
- 9.1 Appen måste ha ett manifest som definierar körningsnivåer och talar om för operativsystemet vilka privilegier appen behöver för att kunna köras
- Administrativa verktyg eller systemverktyg med körningsnivå inställd på highestAvailable och/eller requireAdministrator
- Endast ramverksappen för hjälpmedels- eller användargränssnittsautomatisering anger flaggan uiAccess till true för att kringgå UIPI (User Interface Privilege Isolation). Om du vill starta appanvändningen korrekt måste den här flaggan vara Authenticode-signerad och finnas på en skyddad plats i filsystemet, nämligen ProgramFiler.
- Appmanifestmarkeringen gäller endast för EXE:er, inte DLL:er. Det beror på att UAC inte inspekterar DLL:er när processen skapas. Det är också värt att notera att UAC-regler inte gäller för Windows-tjänster. Manifestet kan antingen vara inbäddat eller externt.
Skapa ett manifest genom att skapa en fil med namnet <app_name>.exe.manifest och lagra den i samma katalog som EXE. Observera att alla externa manifest ignoreras om appen har ett internt manifest. Till exempel:
<requestedExecutionLevel level=""asInvoker | highestAvailable | requireAdministrator"" uiAccess="true|false"/>
- Alla administrativa funktioner måste flyttas till en separat process som körs med administratörsbehörighet. Användarinriktade appar, till exempel de som är tillgängliga via programgruppen på Start-menyn, och krav på utökade privilegier måste vara Authenticode-signerade.
- Ett undantag krävs för appar som kör sin huvudprocess med förhöjd behörighet (kräverAdministrator eller highestAvailable). Huvudprocessen identifieras som användarens startpunkt för appen. Undantag kommer att övervägas för följande scenarier:
10. Appar måste installeras på rätt mappar som standard
Användarna bör ha en konsekvent och säker upplevelse med standardinstallationsplatsen för filer, samtidigt som alternativet att installera en app på valfri plats bibehålls. Det är också nödvändigt att lagra appdata på rätt plats så att flera personer kan använda samma dator utan att skada eller skriva över varandras data och inställningar. Windows tillhandahåller specifika platser i filsystemet för att lagra program och programvarukomponenter, delade appdata och appdata som är specifika för en användare
- 10.1 Appen måste vara installerad i mappen Programfiler som standard
- Registerkörningsnycklar HKLM och eller HKCU under Software\Microsoft\Windows\CurrentVersion
- Registerkörningsnycklar HKLM och eller HKCU under Software\Wow6432Node\Microsoft\windows\CurrentVersion
- Start-menyn Allaprogram > START
- För interna 32-bitars- och 64-bitarsappar i %ProgramFiles%och %ProgramFiles(x86)% för 32-bitarsappar som körs på x64. Användardata eller appdata får aldrig lagras på den här platsen på grund av de säkerhetsbehörigheter som konfigurerats för den här mappen.
- Din app bör till exempel inte ange något av följande;
- Använd rätt metoder för att installera filer, till exempel teckensnitt eller drivrutiner.
- När appen har installerats finns det ingen korrekt användarplats där data ska lagras. Försök av en app att ändra standardassociationens beteenden på datornivå efter installationen misslyckas. I stället måste standardvärden begäras på användarnivå, vilket hindrar flera användare från att skriva över varandras standardvärden.
- Ett undantag krävs för appar som skriver till den globala sammansättningscachen (GAC) .NET-appar bör hålla sammansättningsberoenden privata och lagra dem i appkatalogen om inte delning av en sammansättning uttryckligen krävs.
11. Appar måste ha stöd för sessioner med flera användare
Windows-användare bör kunna köra samtidiga sessioner utan konflikter eller avbrott.
- 11.1 Din app måste se till att appens normala funktioner inte påverkas negativt när den körs i flera sessioner, antingen lokalt eller via fjärranslutning,
11.2 Appens inställningar och datafiler får inte sparas mellan användare
11.3 Användarens sekretess och inställningar måste isoleras till användarens session
11.4 Appens instanser måste isoleras från varandra
- Det innebär att användardata från en instans inte är synliga för en annan instans av appen. Ljud i en inaktiv användarsession ska inte höras i en aktiv användarsession. Om flera appinstanser använder delade resurser måste appen se till att det inte finns någon konflikt.
- Se UAC-kraven.
12. Appar måste ha stöd för x64-versioner av Windows
När 64-bitars maskinvara blir vanligare förväntar sig användarna att apputvecklare drar nytta av fördelarna med 64-bitarsarkitektur genom att migrera sina appar till 64-bitars eller att 32-bitarsversioner av appen körs bra under 64-bitarsversioner av Windows.
- 12.1 Din app måste ha inbyggt stöd för 64-bitars eller minst 32-bitars Windows-baserade appar måste köras sömlöst på 64-bitarssystem för att upprätthålla kompatibilitet med 64-bitarsversioner av Windows
12.2 Din app och dess installationsprogram får inte innehålla någon 16-bitarskod eller förlita sig på någon 16-bitarskomponent
12.3 Appens installation måste identifiera och installera rätt drivrutiner och komponenter för 64-bitarsarkitekturen
12.4 Alla shell-plugin-program måste köras på 64-bitarsversioner av Windows
12.5 App som körs under WoW64-emulatorn bör inte försöka att subvertera eller kringgå Wow64-virtualiseringsmekanismer
- Om det finns specifika scenarier där appar behöver identifiera om de körs under WoW64-emulatorn bör de göra det genom att anropa IsWow64Process.
Sammanfattning av de tester som utförs på Skrivbordsappar
| Testnamn | Möjliga testresultat |
|---|---|
| Följ systemomstartshanterarens meddelanden | Pass/Fail |
| Rensa reversibel installation | Pass/Fail/Warning |
| Kompatibilitetstest & återhämtning | Pass/Fail/Warning |
| Digitalt signerat filtest | Pass/Fail/Warning |
| Installera till rätt mapptest | Varning |
| Multiuser-sessionstest | Varning |
| Test av versionskontroll av operativsystem | Pass/Fail |
| Test av felsäkert läge | Pass/Fail |
| Stöd för x64 Windows-test | Pass/Fail |
| Testa ändringar i Windows-säkerhetsfunktioner (Attack Surface Analyzer) | Pass/Fail/Warning |
| Testa ändringar i Windows-säkerhetsfunktioner (BinScope Binary Analyzer) | Varning |
| UAC-test (User Account Control) | Pass/Fail/Warning |
Slutsats
När dessa krav utvecklas noterar vi ändringarna i revisionshistoriken nedan. Stabila krav är avgörande för att göra ditt bästa arbete, så vi strävar efter att säkerställa att de ändringar vi gör är hållbara och fortsätter att skydda och förbättra dina appar.
Tack igen för att du deltar i vårt åtagande att leverera fantastiska kundupplevelser.
Versionshistorik
| Datum | Version | Revisionsbeskrivning | Länka till dokument |
|---|---|---|---|
| 20 dec 2011 | 1.0 | Första utkast av dokument för förhandsversion. | |
| den 26 januari 2012 | 1.1 | Uppdatera till avsnitt 2. | 1.1 |
| Den 31 maj 2012 | 1.2 | Sammanfattningstestresultat har lagts till Slutligt dokument |
1.2 |
Läs mer om certifiering av skrivbordsappar
| Krav | Beskrivning | Mer information |
|---|---|---|
| Kompatibilitet och återhämtning | Krascher & låser sig är ett stort avbrott för användare och orsakar frustration. Appar förväntas vara motståndskraftiga och stabila, vilket eliminerar sådana fel för att säkerställa att programvaran är mer förutsägbar, underhållsbar, högpresterande och tillförlitlig. |
Operativsystemen Windows Vista, Windows 7 och Windows 8 programverifierare AppInit DLL:er |
| Följ metodtips för Windows-säkerhet | Med hjälp av metodtips för Windows-säkerhet kan du undvika att skapa exponering för Windows-attackytor. Attackytor är startpunkterna som en angripare kan använda för att utnyttja operativsystemet genom att dra nytta av sårbarheter i målprogramvaran. En av de värsta säkerhetsriskerna är utökade privilegier. |
Attack Surface Analyzer åtkomstkontrollistor |
| Stöd för Windows-säkerhetsfunktioner | Windows-operativsystemet har implementerat många åtgärder för att stödja systemsäkerhet och sekretess. Program måste ha stöd för dessa åtgärder för att upprätthålla operativsystemets integritet. Felaktigt kompilerade program kan orsaka buffertöverskridanden som i sin tur kan orsaka överbelastning eller få skadlig kod att köras. |
BinScope-verktygsreferens |
| Följ systemomstartshanterarens meddelanden | När användarna initierar avstängning har de i de allra flesta fall en stark önskan om att avstängningen ska lyckas. de kan ha bråttom att lämna kontoret och "bara vill" sina datorer att stänga av. Appar måste respektera denna önskan genom att inte blockera avstängning. I de flesta fall kanske en avstängning inte är kritisk, men appar måste vara förberedda för risken för en kritisk avstängning. |
Ändringar av programavstängning i Windows Vista Restart Manager Development |
| Rensa reversibel installation | Med en ren, reversibel installation kan användarna hantera (distribuera och ta bort) appar på sina system. |
Så här installerar du krav med ett ClickOnce-program programinstallation på 64-bitarssystem |
| Signera filer och drivrutiner digitalt | Med en digital Authenticode-signatur kan användarna vara säkra på att programvaran är äkta. Det gör också att man kan identifiera om en fil har manipulerats, till exempel om den har smittats av ett virus. Kodsignering i kernelläge är en Windows-funktion som kallas kodintegritet (CI), vilket förbättrar säkerheten i operativsystemet genom att verifiera integriteten för en fil varje gång avbildningen av filen läses in i minnet. CI identifierar om skadlig kod har ändrat en binär systemfil. Genererar också en diagnostik- och systemgranskningslogghändelse när signaturen för en kernelmodul inte kan verifieras korrekt. |
digitala signaturer för kernelmoduler i Windows |
| Blockera inte installation eller appstart baserat på versionskontroll av operativsystem | Det är viktigt att kunderna inte blockeras artificiellt från att installera eller köra sin app när det inte finns några tekniska begränsningar. Om appar i allmänhet har skrivits för Windows Vista eller senare versioner bör de inte ha någon anledning att kontrollera operativsystemversionen. |
versionshantering för operativsystem |
| Läs inte in tjänster och drivrutiner i felsäkert läge | Med felsäkert läge kan användare diagnostisera och felsöka Windows. Om det inte behövs för grundläggande åtgärder i systemet (till exempel drivrutiner för lagringsenheter) eller för diagnostik- och återställningsändamål (till exempel antivirusskannrar) får drivrutiner och tjänster inte ställas in för att läsas in i felsäkert läge. Som standard startar inte felsäkert läge de flesta drivrutiner och tjänster som inte har förinstallerats med Windows. De bör förbli inaktiverade såvida inte systemet kräver dem för grundläggande åtgärder eller i diagnostik- och återställningssyfte. |
avgöra om operativsystemet körs i felsäkert läge |
| Följ UAC-riktlinjer (User Account Control) | Vissa Windows-appar körs i säkerhetskontexten för ett administratörskonto och många kräver för höga användarrättigheter och Windows-behörigheter. Genom att kontrollera åtkomsten till resurser kan användarna ha kontroll över sina system mot oönskade ändringar (En oönskad ändring kan vara skadlig, till exempel ett rootkit som i smyg tar över datorn eller en åtgärd från personer som har begränsad behörighet, till exempel en anställd som installerar förbjuden programvara på en arbetsdator). Den viktigaste regeln för att kontrollera åtkomsten till resurser är att tillhandahålla den minsta mängd åtkomststandardanvändarkontext som krävs för att en användare ska kunna utföra sina nödvändiga uppgifter. Följande UAC-riktlinjer ger appen nödvändiga behörigheter när det behövs, utan att systemet ständigt exponeras för säkerhetsrisker. |
Användarkontokontroll UAC: Riktlinjer för programuppdatering |
| Installera till rätt mappar som standard | Användare bör ha en konsekvent och säker upplevelse med standardinstallationsplatsen för filer, samtidigt som alternativet att installera en app på den plats de väljer bibehålls. Det är också nödvändigt att lagra appdata på rätt plats så att flera personer kan använda samma dator utan att skada eller skriva över varandras data och inställningar. |
sammanfattning av installations-/avinstallationskrav |
| Stöd för sessioner för flera användare | Windows-användare bör kunna köra samtidiga sessioner utan konflikter eller avbrott. | programmeringsriktlinjer för fjärrskrivbordstjänster |
| Stöd för x64-versioner av Windows | När 64-bitars maskinvara blir vanligare förväntar sig användarna att apputvecklare drar nytta av fördelarna med 64-bitarsarkitektur genom att migrera sina appar till 64-bitars eller att 32-bitarsversioner av appen körs bra under 64-bitarsversioner av Windows. |
programkompatibilitet: Windows Vista 64-bitars |