Leder du efter dokumentation på 'rigtig' måde at installere apps på Windows 7

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg arbejder med nogle gamle programmer (10-15 år) og forsøger at finde vejledning på 'rigtig' måde at installere og køre dem (og enhver brugerapplikation) på Windows 7 uden at kræve fuld administratorrettigheder.


Med andre ord, hvor eksekverbare/skrivebeskyttede skal filer gå, hvor brugerdata/læs-skrive skal filer gå, hvor registreringsdatabasen skal gå for at undgå problemer med UAC og Windows 7-filen/registreringsdatabase virtualisering under både installation og ved run-time.


Jeg synes for mange år siden at huske et hvidbogen fra Microsoft om dette emne, men kan ikke finde nogen relevant information nu. Jeg har fundet oplysninger om brugerens side (hvordan man får gamle programmer til at køre på Windows 7 via kompatibilitets tweaks), men ingen på udvikler siden (hvordan man opretter/installerer programmer for at spille pænt på Windows 7 indbygget).


Enhver vejledning til sådanne oplysninger ville være mest værdsat. Tak.


Marc

Bedste reference


Du tænker på Windows Logo Krav. [3]



  

      
  1. Installer til de korrekte mapper som standard

  2.   

  
  Brugere skal have en konsekvent og
  sikker oplevelse med standardværdien
  installationsplacering af filer, mens
  opretholdelse af muligheden for at installere en
  ansøgning til stedet de
  vælge. Det er også nødvendigt at opbevare
  ansøgningsdata i den korrekte
  placering til at tillade flere mennesker til
  brug den samme computer uden
  ødelægge eller overskrive hinandens data og indstillinger.

  
  Windows giver
  bestemte steder i filsystemet
  at gemme programmer og software
  komponenter, delte applikationsdata,
  og applikationsdata, der er specifikke for a
  bruger:

  
  

      
  • Programmer skal installeres som standard i mappen Programfiler [[16]]. Brugerdata eller applikationsdata må aldrig gemmes på denne placering på grund af sikkerhedsrettighederne konfigureret til denne mappe

  •   

  
  [[16]] \% Programfiler\% til native 32-bit og 64-bit applikationer, og \% Programfiler (x86)\% til 32-bit applikationer, der kører på henholdsvis x64

  
  

      
  • Alle applikationsdata, som skal deles mellem brugere på computeren, skal gemmes i ProgramData

  •   
  • Alle applikationsdata eksklusive til en bestemt bruger og ikke deles med andre brugere af computeren skal gemmes i Brugere \\ AppData

  •   
  • Skriv aldrig direkte til 'Windows' -mappen og/eller underkatalogerne. Brug de rigtige metoder til installation af filer, f.eks. Skrifttyper eller drivere

  •   
  • I 'per-machine' -installationer skal brugerdata skrives ved første gang og ikke under installationen. Dette skyldes, at der ikke er nogen korrekt brugerplads til at gemme data på tidspunktet for installationen. Forsøg på en applikation til ændring af standard associationsadfærd på maskinniveau efter installationen mislykkes. I stedet skal standardværdier påberåbes på et niveau pr. Bruger, hvilket forhindrer flere brugere i at overskrive hinandens standardindstillinger.

  •   



Det næste er, at du ikke skal skrive til et sted, der kræver administrative tilladelser.



   Bemærk: Du kan teste alt dette på en Windows 2000 eller Windows XP ved blot at (som Windows 2000-logoets krav kræves) kører som en standardbruger.



Da de fleste applikationer ignorerede logoets krav og ville mislykkes, når de kører med standardbrugerrettigheder, inkluderede Windows Vista evnen til at holde disse buggy-applikationer hængende sammen ved at virtualisere skriver til beskyttede steder - i stedet for at få dem til at mislykkes.


Du kan fravælge denne kompatible hack ved at manifestere din ansøgning til RunAs Invoker :


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- Disable file and registry virtualization -->
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
        <security>
            <requestedPrivileges>
                <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
            </requestedPrivileges>
        </security>
    </trustInfo>
    ...
</assembly>


Logo-retningslinjerne tales om UAC og virtualisering af skrivninger til bestemte steder:



  

      
  1. Følg retningslinjer for brugerkontokontrol (UAC)

  2.   

  
  Nogle Windows-programmer kører i
  sikkerhedskontekst for en administrator
  konto, og mange kræver overdreven
  brugerrettigheder og Windows-privilegier.
  Kontrol af adgang til ressourcer
  gør det muligt for brugerne at være i kontrol med
  deres systemer mod uønsket 20
  ændringer. Den vigtigste regel for
  at kontrollere adgangen til ressourcer er at
  give mindst adgang
  'Standard bruger kontekst' kræves for a
  bruger til at udføre hans eller hendes nødvendige
  opgaver. Følgende UAC retningslinjer
  giver applikationer med
  nødvendige tilladelser når det er nødvendigt
  uden at forlade systemet konstant
  udsat for sikkerhedsrisici.

  
  De fleste applikationer kræver ikke
  administratorrettigheder på kørselstidspunktet,
  og det skal bare være fint at løbe som en
  standard-bruger. Windows applikationer
  skal have et manifest 21 (indlejret eller
  ekstern 22) der definerer deres
  udførelsesniveauer og fortæller OS hvad
  privilegier, som ansøgningen kræver i
  for at løbe.

  
  

      
  • For eksempel,

  •   
  • Programmets hovedproces skal køres som en standardbruger
      (AsInvoker). Enhver administrativ
      funktioner skal flyttes til en separat
      proces, der kører med administrative
      privilegier.

  •   
  • En afkald er påkrævet for applikationer, der kører deres vigtigste
      behandle 23 med forhøjede privilegier
      (krævesAdministrator eller
      highestAvailable)

  •   

  
  Fritagelser vil blive overvejet for
  følgende scenarier:

  
  

      
  • Administrativ eller systemværktøjer med eksekveringsniveau er sat til
      højst tilgængelig, og eller
      kræveAdministrator

  •   

  
  Eller

  
  

      
  • Kun tilgængelighed eller UI-automationsrammeprogram, der indstiller
       uiAccess 24 flag til sandt at omgå brugergrænsefladens privilegium isolering
      (UIPI)

  •   



Så var der høj dpi. Windows-logoets krav i et årti har krævet, at applikationer svarer korrekt til høje (dvs. ikke-96dpi) skærme. Da de fleste applikationer bryder forfærdeligt, hvis brugeren bruger 'Large Fonts', gav Microsoft op, og virtualiseringen af ​​filsystemet virtualiserer også dpi-indstillingen. Medmindre en applikation vælger ud af kompatibilitets hack: Windows vil lyve for dig og fortælle dig at du er 96dpi.


Først når du har skrevet din app korrekt, skal du tilføje en post til din applikations manifest for at deaktivere høj dpi-skalering:


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
    ...
    <!-- We are high-dpi aware on Windows Vista -->
    <asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
            <dpiAware>true</dpiAware>
        </asmv3:windowsSettings>
    </asmv3:application>
    ...
</assembly>


Anyway, det er alt der, Windows 7 Client Software Logo Program. [4]





Bemærk: Hvis du skrev et Windows-program for 15 år siden (1995), har jeg antaget , at du skrev til:



  • Windows 3.1 eller

  • Windows 95



hellere end:



  • Windows NT 3.1

  • Windows NT 3.5

  • Windows NT 4

  • Windows 2000

  • Windows XP



Det er vigtigt at bemærke, at Windows NT er designet som et sikkert operativsystem. Du må ikke med vilje gøre alt, hvad du vil. Dette er en grundlæggende forskel fra:



  • Windows 1

  • Windows 2

  • Windows 3

  • Windows 3.1

  • Windows 95

  • Windows 98

  • Windows Me



som ikke havde nogen sikkerhed.


Skriver til mappen Windows og Programfiler kræver administratorrettigheder. Dette skyldes, at normalt kun administratorer skal installere applikationer. Men det regelmæssige brugere kan ikke ændre eller beskadige installerede programmer - eller installationen af ​​Windows selv, f.eks .:



  • Sletning af System32 er dårlig

  • sletning af WinSxS er dårlig


Andre referencer 1


Windows 7 Training Kit har et stort afsnit om applikationskompatibilitet, herunder at spille pænt med UAC, installere til de rigtige mapper osv. [5] [6]


http://www.microsoft.com/downloads/en/details.aspx?familyid=1C333F06-FADB-4D93-9C80-402621C600E7u0026amp;displaylang=en[7]


Hvis du også søger at bruge de nye funktioner i Windows 7 og ikke bare får din app kompatibel, er der meget i det kit, der kan hjælpe.