Konfigurationskoncept för V4-drivrutin
Viktig
Den moderna utskriftsplattformen är Windows bästa sätt att kommunicera med skrivare. Vi rekommenderar att du använder Microsofts IPP-drivrutin för inkorgsklass tillsammans med Print Support Apps (PSA) för att anpassa utskriftsupplevelsen i Windows 10 och 11 för enhetsutveckling av skrivare.
Mer information finns i Modern print platform och Print support app design guide.
Modellen för v4-utskriftsdrivrutiner använder en ny konfigurationsmodell för att förbättra användarupplevelsen och minska supportkostnaderna.
V4-utskriftsdrivrutinen körs direkt från drivrutinsarkivet, vilket eliminerar risken för filkollisioner och förbättrar installationsprestandan. V4-konfigurationsmodellen fortsätter att använda INF-filer, men använder också en ny manifestfil för att avbilda skrivarspecifika installationsdirektiv.
Enhetsidentifierare
CompatibleIDS
Kompatibla ID:n är ett nyckelkoncept för utskriftsklassdrivrutiner eftersom de gör det möjligt för drivrutinerna att stödja enheter som släpps efter att den nya versionen av Windows har släppts, utan att drivrutinen behöver uppdateras. Detta är möjligt eftersom Kompatibla ID:er gör det möjligt för enheter att annonsera stöd för en mindre specifik utskriftsdrivrutin än vad ett HardwareID gör.
Om ett visst CompatibleID redan stöds av en utskriftsklassdrivrutin bör v4-utskriftsdrivrutiner inte ange det igen. Om datumet för en utskriftsdrivrutin är nyare än datumet för utskriftsklassdrivrutinen laddas utskriftsdrivrutinen ned automatiskt från Windows Update-webbplatsen.
Enheter bör innehålla CompatibleIDs i sin 1284ID-sträng. Om en befintlig utskriftsklassdrivrutin stöder enheten bör utskriftsdrivrutinen använda det CompatibleID, annars rekommenderar vi att du använder följande format.
1284_CID_<manufacturer identifier>_<PDL identifier>_device family identifier
Till exempel:
1284_CID_FA_PCL5e_Laser
Om Kompatibla ID:er redan har implementerats på befintliga enheter bör utskriftsdrivrutinen fortsätta att använda dessa CompatibleIDs.
Kompatibla ID:er används inte vid installation av TCP/IP-baserade utskriftsenheter. Därför måste användarna identifiera en lämplig drivrutin med endast drivrutinens namn. När det gäller drivrutiner för utskriftsklass rekommenderar vi att tillverkarna tillhandahåller kompatibilitetslistor på sina webbplatser för alla enheter som stöds av en utskriftsklassdrivrutin. Mer information om hur du implementerar Kompatibla ID:er i maskinvaran, inklusive en fullständig lista över regler och begränsningar finns i Implementera kompatibla ID:er i utskriftsenheter.
Microsoft har stöd för några standardkompatibla ID:er för att stödja flera drivrutiner för tillverkarneutrala utskriftsklasser (standard). Följande tabell visar dessa standardkompatibla ID:n och deras associerade PDL-filtyper.
| PDL-filtyp | Standardkompatibel ID |
|---|---|
| XPS | 1284_CID_MS_XPS |
| OpenXPS (ECMA-388) | 1284_CID_MS_OXPS |
| PCL6 | 1284_CID_MS_PCL6 |
| PS | 1284_CID_MS_PS |
Dessa standarddrivrutiner för skrivarklass stöder endast en liten uppsättning funktioner, så tillverkare som väljer att använda dessa drivrutiner bör implementera en förbättrad drivrutinskonfiguration med hjälp av Bidi för att lägga till mer specifika pappersstorlekar och konfiguration. I följande tabell visas de funktioner och tillhörande alternativ som stöds av standarddrivrutinerna för utskriftsklass.
| Funktion | Alternativ |
|---|---|
| Pappersstorlek | Brev, A4 |
| Resolution | 300dpi, 600dpi |
| Medietyp | Vanligt papper |
| N-up | 1, 2, 4, 6, 9, 16 |
Skrivarens Drivrutins-ID
PrinterDriverID är en ny identifierare som används för att fastställa kompatibiliteten mellan drivrutiner för skrivardelning, samt kompatibiliteten mellan drivrutiner och skrivartillägg. Om drivrutinen på servern till exempel anger ett PrinterDriverID i manifestfilen och drivrutinen sedan delas, söker klienter som ansluter till den här skrivaren i det lokala drivrutinsarkivet och Windows Update efter en drivrutin som anger samma PrinterDriverID i drivrutins-INF. Om en matchning hittas upprättas en anslutning med denna drivrutin. Klientdatorer filtrerar inte matchande resultat med drivrutinsnamnet.
PrinterDriverID måste anges för alla kompatibla drivrutiner på följande sätt:
Använda PrinterDriverID-direktivet i v4-manifestet.
Som ett HardwareID i v4-driverns INF.
För att två olika drivrutiner ska kunna dela samma PrinterDriverID måste de vara kompatibla för delning. För att anslutningen alltid ska lyckas måste de två programdrivrutinerna kunna göra följande:
Stöd samma PDL
Använd samma typ av konfigurationsfiler (GPD eller PPD)
Kunna återge alla funktioner eller alternativ som anges i serverdrivrutinens GPD-, PPD- och/eller villkors-JS-filer
Stöd för samma skrivartillägg
Spolaren validerar inte dessa begränsningar och förlitar sig enbart på PrinterDriverID för att ange om två drivrutiner är kompatibla för delning. Tillverkare måste se till att ändra PrinterDriverID för en drivrutin om ändringar görs i något av ovanstående objekt.
Skrivartillägg kan också associeras med drivrutiner via PrinterDriverIDs. Därför måste två drivrutiner som delar ett PrinterDriverID fungera med samma skrivartillägg. Det senaste installerade skrivartillägget skriver över alla tidigare skrivartillägg för alla enheter med hjälp av riktade PrinterDriverID:er, så de måste fungera korrekt med samma app.
Metodtips för att använda GUID:er
GUID används brett via modellen för v4-utskriftsdrivrutiner, framför allt i PrinterDriverID, och även i PrinterExtensionID, EventID och ModelID. Dessa används antingen för att unikt identifiera olika objekt i systemet eller för att identifiera dem som samma för service, delning osv.
När du skapar nya GUID använder du alltid en GUID-generator, till exempel den som ingår i Microsoft Visual Studio eller den som ingår i SDK:n. Manuellt utformade GUID:er och GUID:er som felaktigt har kopierats och klistrats in är utsatta för kollisioner.
Konfigurationsbeteenden
Skriva ut könamn
För v3-drivrutiner dikterades utskriftskönamnet först av drivrutinsnamnet och sedan av användaren. Med introduktionen av skrivarklassdrivrutiner är drivrutinsnamnet mycket mindre användbart för användarigenkänning av enheten. Windows byter automatiskt namn på kön för alla Plug and Play-enheter som är installerade för att köra en v4-utskriftsdrivrutin på följande sätt:
Ursprungligen anges namnet på utskriftsköen till drivrutinsnamnet.
Om drivrutinen är en v4-utskriftsdrivrutin, kommer Windows att fråga enheten med hjälp av Bidi.
Om \Printer.DeviceInfo:FriendlyName har angetts används det som det nya könamnet.
Annars förfrågar Windows \Printer.DeviceInfo:Manufacturer, \Printer.DeviceInfo:ModelName.
Om båda anges sammanfogar Windows dem till "Manufacturer ModelName".
Om endast en av dessa Bidi-frågor misslyckas använder Windows den lyckade returen från den andra frågan som könamn.
Om alla Bidi-frågor misslyckas använder Windows IEEE 1284ID för att fastställa tillverkarens och modellnamnen.
Om BESKRIVNING eller DES anges, används det som det nya köens namn.
Annars söker Windows efter MANUFACTURER eller MFG och MODEL eller MDL.
Om båda anges sammanfogar Windows dem till "MANUFACTURER MODEL".
Om bara en av dessa misslyckas använder Windows värdet från den andra nyckeln som könamn.
Guiden Lägg till skrivare
Drivrutinsnamnet fortsätter att vara den enda identifierare som är tillgänglig för användare som väljer en drivrutin i guiden Lägg till skrivare. TCP/IP-baserade enheter bör implementera Port Monitor MIB (PWG 5107.1-2005) för att stödja automatisk identifiering av TCP/IP. Befintliga enheter som läggs till i en utskriftsklassdrivrutin med hjälp av en maskinvaru-ID-mappning (HWID) kan dessutom använda ett enhetsspecifikt modellnamn.
Ändra portar och hantera skrivar-enhetsnoder
För att ge en konsekvent användargränssnittsupplevelse får alla utskriftsköer en nod för programvaruenheter (devnode). Det här är hur skrivare identifieras i användargränssnittet och gör att virtuella skrivare, anslutningar till delade skrivare och nätverksskrivare kan räknas upp och nås på samma sätt som Plug and Play-skrivare (PnP). Programvaru-devnodes för fysiska PnP-skrivare ärver egenskaper från PnP-devnode som ledde till att kön skapades.
Användargränssnittet grupperar devnodes i enhetscontainrar när två olika objekt är relaterade. Den här gruppering är det som gör att en multifunktionsskrivare (MFP) kan visas som en ikon i mappen Enheter och skrivare. Container-ID:t för alla funktioner i en MFP måste vara detsamma för att funktionerna ska visas under samma ikon. Detta görs automatiskt för PnP-enheter.
Om du ändrar porten som är associerad med en kö ändras det container-ID som är associerat med köns devnode. Detta gör att kön inte längre grupperas under samma enhetscontainer som resten av PnP-objekten för den fysiska enheten. Det finns inte tillräckligt med information i operativsystemet för att korrekt rensa situationer där kön och PnP-objektet separeras. I vissa fall är det användarens faktiska avsikt. Endast den användare eller det program som ändrar portnamnet vet vad det avsedda resultatet är och det är upp till användaren/programmet att rensa eventuella förvirrande tillstånd som lämnas kvar när en kös port har ändrats. Här är två exempelsituationer med instruktioner som visar hur du rensar på rätt sätt.
IT-administratören konfigurerar skrivare – En IT-administratör använder WS Discovery för att hitta en skrivare i nätverket och ändrar porten till TCP/IP eftersom de gillar TCP/IP-hanteringsprocessen.
Förväntan – Det finns bara en "enhet" i mappen enheter och skrivare.
Lösning – IT-administratören tar bort WSD PnP-devnode från mappen enheter och skrivare.
IHV-installationsprogram – IHV installerar en drivrutin tillsammans med en anpassad portövervakare (anpassade portövervakare tillåts inte i v4, men samma devnode-hantering gäller för v3-drivrutiner). IHV:n ändrar USB-porten för utskriftskö till en port som enhetstillverkaren skapar.
Förväntan – Det finns bara en "enhet" i mappen enheter och skrivare.
Lösning 1 – PnP devnode behövs fortfarande: Installationsprogrammet ändrar container-ID:t för kö-devnode så att det matchar PnP-objektet.
Lösning 2 – PnP devnode är överflödig: Installationsprogrammet tar bort den ursprungliga PnP-enheten.
Förarrankning
Introduktionen av v4-utskriftsdrivrutiner ändrar inte rangordningsbeteendet för Plug and Play. När en enhet är ansluten väljs den drivrutin som har högst poäng. Om den valda drivrutinen är en utskriftsklassdrivrutin och det finns en bättre rankad, matchande drivrutin på Windows Update-webbplatsen, ersätts den valda drivrutinen automatiskt nästa gång användaren laddar ned uppdateringar för Windows.
Mer information om drivrutinsrankning finns i Hur Windows rankar drivrutiner.
Metodtips för drivrutinskonfiguration
Emballage
V4-utskriftsdrivrutiner använder inte behöver och innehåller INF-fildirektiv eller grundläggande drivrutinstekniker för att hantera delade filer. Därför måste v4-utskriftsdrivrutiner vara fristående, med bara några få undantag.
V4-utskriftsdrivrutiner kan fortsätta att vara beroende av vanliga filer som Windows tillhandahåller. Dessa inkluderar filerna i NTPrint.INF eller NTPrint4.INF. Drivrutiner kan innehålla dessa filer genom att ange RequiredFiles-direktivet i v4-manifestfilen.
Om det finns befintliga utskriftsklassdrivrutiner som ger grundläggande återgivningsfunktioner för dina enheter eller PDL finns det också en mekanism för att ta ett beroende av klassdrivrutinen med hjälp av RequiredClass-direktivet. Det här direktivet gör att Windows skapar en drivrutin med hjälp av filerna från både v4-utskriftsdrivrutinen och den nödvändiga utskriftsklassdrivrutinen. GPD- och PPD-filer sammanfogas, där de mest specifika filerna har företräde framför mindre specifika filer. Följande diagram illustrerar logiken som används för att sammanfoga GPD/PPD-filerna och innehåller även förbättrade drivrutinskonfigurationsfiler som hämtats från Bidi. Andra drivrutinsfiler, till exempel JavaScript-begränsningar, sammanfogas inte i drivrutinspaketet.
Skrivarmodelllinjer
Plug and Play har en implicit rangordning av alla HardwareID:er och Kompatibla ID:er på en modelllinje. Därför rekommenderar Microsoft att partner använder följande metodtips för att undvika oförutsägbara beteenden när det gäller rangordning.
V4-utskriftsdrivrutin
INF:er för V4-utskriftsdrivrutiner måste definiera två olika typer av modelllinjer:
HardwareID-rader: "Drivrutinsnamn" = INSTALL_SECTION, busenumerator\HardwareID
PrinterDriverID-rader: "Drivrutinsnamn" = INSTALL_SECTION,{GUID}
INF:er för V4-utskriftsdrivrutiner måste definiera bussspecifika Maskinvaru-ID:er på enskilda rader:
"Drivrutinsnamn" = INSTALL_SECTION,WSDPRINT\HardwareID
"Drivrutinsnamn" = INSTALL_SECTION,USBPRINT\HardwareID
"Drivrutinsnamn" = INSTALL_SECTION,LPTENUM\HardwareID
Skriva ut klassdrivrutin
Inf:er för utskriftsklassdrivrutiner måste definiera tre olika typer av modelllinjer:
HardwareID-rader: "Drivrutinsnamn" = INSTALL_SECTION,HardwareID
PrinterDriverID-rader: "Drivrutinsnamn" = INSTALL_SECTION,{GUID}
CompatibleID-rader: "Print Class Driver name" = INSTALL_SECTION,,1284_CID_CompatID
Inf:er för utskriftsklassdrivrutiner får inte definiera några bussuppräknare (till exempel WSDPRINT)
Relaterade ämnen
Så här implementerar du kompatibla ID:n i utskriftsenheter