Drivere de imprimantă V4: ghid complet pentru noul model de imprimare

Driverele de imprimantă versiunea 4 au schimbat complet modul în care Windows gestionează imprimarea , atât pe computerele client, cât și pe serverele de imprimare. Acest nou model, care a înlocuit treptat versiunea 3 clasică, afectează nu numai modul în care sunt instalate driverele, ci și întreținerea, compatibilitatea, securitatea și experiența utilizatorului, în special în mediile cu multe imprimante sau imprimante partajate de pe un server.

Dacă lucrați cu sistemele de operare moderne Windows 8, Windows 10, Windows 11 sau Windows Server , driverele V4 fac deja parte din rutina zilnică, deși sunt adesea utilizate fără o înțelegere completă a implicațiilor lor. Mai jos veți găsi o explicație detaliată și clară a ceea ce sunt driverele V4, cum diferă de driverele V3, avantajele și limitările lor, cum funcționează în mediile de domeniu și server de imprimare și ce ar trebui să aibă în vedere administratorii și dezvoltatorii.

Care este modelul driverului de imprimantă V4?

Modelul de driver de imprimare V4 este o evoluție directă a modelului clasic V3, existent încă din era Windows 2000. Microsoft l-a introdus începând cu Windows 8 și Windows Server 2012, cu un obiectiv clar: simplificarea dezvoltării driverelor, reducerea costurilor de administrare IT și pregătirea imprimării pentru noi scenarii de securitate și aplicații moderne.

Deși modelul V4 este nou din punct de vedere al arhitecturii și filozofiei , acesta menține compatibilitatea cu multe tehnologii familiare: fișiere XPSDrv, GPD și PPD, configurare automată, comunicare bidirecțională (BID) și alte componente deja familiare producătorilor și administratorilor. Principala diferență este că o mare parte din inteligența driverului se bazează acum pe fișiere de date și JavaScript, în timp ce Microsoft oferă aproape toate componentele funcționale ale stivei de imprimare.

În arhitectura de nivel înalt a unui driver V4 , elementele care anterior erau specifice furnizorului (cum ar fi multe DLL-uri private) sunt reduse la minimum. Microsoft implementează majoritatea componentelor cheie și lasă producătorilor anumite puncte de extensibilitate (reprezentate în mod tradițional cu verde în documentație) pentru randarea filtrelor și a aplicațiilor personalizate de interfață cu utilizatorul.

Această abordare reduce drastic riscul conflictelor de fișiere, al problemelor de actualizare și al erorilor între arhitecturi (x86, x64, ARM), deoarece driverul V4 rulează direct din Driver Store și este conceput pentru a fi mult mai izolat și modular decât driverele V3 tradiționale.

Scenarii pentru care a fost optimizat controlerul V4

Modelul V4 nu a fost conceput pur și simplu ca o „repetiție” a versiunii V3 , ci având în vedere câteva scenarii care au devenit critice în timp : aplicații UWP, imprimare partajată de pe server, complexitate redusă a driverelor și asistență tehnică îmbunătățită în medii mari.

În Windows 8 și versiunile ulterioare, aplicațiile din platforma universală Windows (UWP) introduc noi restricții de interfață și securitate. Aceste aplicații necesită o modalitate sigură și controlată de afișare a preferințelor de imprimare personalizate sau a notificărilor legate de imprimantă. Modelul V4 este singura modalitate oficială prin care producătorii pot integra experiențe de imprimare personalizate în aplicațiile UWP, respectând în același timp modelul modern de securitate Windows.

În partajarea imprimantelor de pe un server , unul dintre punctele forte ale Windows Server, versiunea 4 simplifică considerabil lucrurile. Scopul este de a elimina necesitatea de a menține colecții masive de drivere V3 pentru fiecare arhitectură de procesor și de a împiedica serverul să „trimită” DLL-uri potențial problematice către toți clienții. V4 permite clientului să obțină propriul driver din Windows Update sau din propriul depozit local, ghidat de identificatorul PrinterDriverID.

Pentru dezvoltatorii de drivere, V4 reprezintă, de asemenea, o simplificare considerabilă . Modelul se bazează pe investițiile anterioare în XPSDrv și modelul V3, dar driverele V4 sunt mai ușor de creat și testat, în special folosind șabloanele Visual Studio și Windows Driver Kit (WDK). Volumul de lucru tipic pentru desktop-uri C++ și instrumentele încorporate de generare GUID facilitează mult asamblarea unui pachet V4 de la zero.

Pe scurt, V4 este conceput pentru a reduce haosul din baza de date a driverelor acumulat de-a lungul anilor , unde lista de drivere la instalarea unei imprimante prin Windows Update putea dura câteva minute și conținea numeroase modele învechite. Scopul: reducerea rămășițelor istorice și menținerea doar a driverelor mai universale și ușor de actualizat.

Diferențe cheie între driverele de imprimare V3 și V4

Vechiul model V3 se baza pe crearea de către fiecare producător a propriului driver pentru practic fiecare model , rezultând seturi mari de DLL-uri specifice și în mare parte inutilizabile. Ani de zile, această filozofie abia s-a schimbat și, deși au apărut drivere „universale”, acestea conțineau în continuare fișiere proprietare ale furnizorului.

Consecința acestei abordări a fost o bază de date gigantică, în continuă creștere, cu drivere, care a complicat atât instalarea, cât și administrarea. Instalarea unui driver prin Windows Update implica descărcarea unor liste enorme de drivere, multe dintre ele pentru dispozitive care nu mai existau pe piața actuală a mașinilor.

Cu V4, Microsoft optează pentru drivere de clasă incluse în sistemul de operare în sine și pentru drivere V4 specifice producătorului, dar cu o arhitectură mai curată. Driverele de clasă acoperă un limbaj de imprimare specific (de exemplu, PCL, PostScript, XPS) și sunt utilizate generic pentru diverse modele din aceeași familie.

Dezavantajul inerent al acestor drivere de clasă este că oferă doar funcții de bază : selecție color sau alb-negru, dimensiuni standard de hârtie, imprimare față-verso sau față-verso etc. Dacă trebuie să utilizați funcții multifuncționale avansate (finisare, capsare, tăvi speciale, scanare integrată etc.), este de obicei necesar să utilizați driverul V4 specific producătorului.

De aceea, mulți producători, precum Epson, Xerox, Konica Minolta și alții, lansează propriile versiuni V4 , care pot fi descărcate din Windows Update sau direct de pe site-urile lor oficiale. În acest fel, încearcă să combine avantajele modelului modern cu propria interfață utilizator și toate opțiunile specifice dispozitivului.

Imprimare bazată pe XPS: cum funcționează driverele V4

O altă caracteristică cheie a modelului V4 este dependența sa de calea de imprimare XPS (XML Paper Specification) . Imprimantele care înțeleg nativ XPS pot primi direct lucrări de imprimare fără filtre intermediare, în timp ce altele necesită ca lucrarea de imprimare să fie convertită din XPS în limbajul pe care îl înțeleg (PCL, PostScript etc.).

Această abordare are avantaje clare în ceea ce privește consecvența rezultatului și procesul de randare , dar are și un dezavantaj semnificativ: lucrarea XPS trebuie finalizată complet înainte de a fi trimisă la imprimare. Pentru tiraje foarte mari sau documente complexe, acest lucru poate duce la o așteptare semnificativă, imprimanta aparent inactivă o perioadă.

Pentru cei care lucrează la dezvoltarea de filtre XPSDrv sau module de randare personalizate , modelul V4 oferă puncte de extensie clare și șabloane în Visual Studio care simplifică crearea DLL-ului filtrului și a fișierului de configurare a canalului (PipelineConfig.xml). Aceste componente se integrează cu driverul principal pentru a transforma sau manipula fluxul XPS înainte ca acesta să ajungă la imprimantă.

Documentația oficială a Microsoft descrie în detaliu modulul de randare XPSDrv și modul de asamblare a filtrelor de randare pentru a adăuga suport pentru anumite PDL-uri, a aplica transformări sau a implementa funcții avansate care nu se găsesc în controlerul de clasă de bază.

Distribuția driverelor și Point and Print în V4

Din punct de vedere istoric, una dintre cele mai mari probleme legate de driverele V3 era distribuția lor de pe serverele de imprimare partajate . Cu funcția Point and Print, clientul descărca automat driverul de pe server la conectarea la o coadă partajată, ceea ce înseamnă că orice DLL-uri defecte sau vulnerabile ar afecta toți utilizatorii de pe server sau din mediul desktop la distanță.

În plus, vulnerabilitățile din subsistemul de imprimare (faimosul „PrintNightmare”) au determinat Microsoft să recomande dezactivarea descărcărilor automate de drivere și restricționarea obiectelor de politică de grup (GPO) pentru Point and Print. Acest lucru a complicat și mai mult lucrurile pentru administratori, deoarece erau necesare permisiuni suplimentare pentru instalarea driverelor atunci când clienții se conectau la imprimantele de pe server.

Cu driverele din clasa V4, Microsoft a reproiectat modelul de distribuție . Când un utilizator se conectează la o coadă partajată V4, clientul caută mai întâi în Depozitul local de drivere un driver potrivit folosind PrinterDriverID; dacă găsește unul, îl folosește, iar dacă nu este disponibil, încearcă să îl descarce din Windows Update, fără ca serverul să fie nevoit să „injecteze” fișiere DLL în computerul client.

Dacă un driver V4 adecvat nu este încă disponibil, intră în joc „Microsoft Enhanced Point and Print Driver” , care oferă o interfață standard, dar cu funcții limitate. Pentru clienții cu sisteme de operare mai vechi care se conectează la cozile V4, există și un „Microsoft Enhanced Point and Print Compatibility Driver” care permite imprimarea continuă, deși cu unele limitări.

Un punct important de reținut este că un driver de imprimantă de tip 4 nu se poate conecta la monitoare de porturi terțe . Acest lucru afectează soluțiile care se bazează pe porturi speciale (de exemplu, unele programe software de contabilizare a imprimărilor sau de imprimare prin interogare). În aceste cazuri, arhitectura trebuie revizuită înainte de a migra totul la V4.

Probleme comune în Active Directory și servere: cazul funcțiilor limitate

În mediile Active Directory clasice cu un server de imprimare și un GPO , este destul de frecvent să întâlnești situații de acest gen: un driver V3 de la un producător este retras (de exemplu, Konica Minolta nu mai actualizează un anumit V3), driverul „universal” V4 este instalat pe server, driverul din coadă este schimbat... și dintr-o dată utilizatorii au opțiuni de imprimare foarte limitate.

Ceea ce se întâmplă de obicei în aceste cazuri este că serverul partajează doar o coadă care utilizează un driver V4 , dar computerele client nu au instalat local driverul V4 complet de la producător. Drept urmare, se utilizează un set standard de opțiuni, fără meniurile avansate pentru finisare, tăvi, culori avansate etc., care apar atunci când instalați driverul V4 direct pe PC-ul utilizatorului.

Din punct de vedere administrativ, instalarea directă impusă pe fiecare computer poate fi plictisitoare , mai ales în organizațiile mari. Mulți administratori se așteaptă ca acest comportament să fie similar cu cel din V3 (clientul îl descarcă de pe server), dar cu V4, modelul este conceput astfel încât driverul să provină de la clientul însuși sau din Windows Update, ghidat de PrinterDriverID și nu doar de numele driverului.

Fără a recurge la soluții terțe de gestionare a imprimării în cloud , modalitatea obișnuită de a gestiona această problemă în mediile AD tradiționale este de a combina practicile bune de implementare a driverelor (de exemplu, utilizarea instrumentelor de gestionare a software-ului, a scripturilor sau a obiectelor GPO de instalare) cu configurarea corectă a PrinterDriverID și a cozilor de imprimare, astfel încât clientul să poată asocia corect driverul V4 local cu imprimanta partajată.

Unii producători și soluții specifice, cum ar fi ThinPrint în sectorul întreprinderilor , oferă niveluri suplimentare de gestionare a imprimării pentru a acoperi scenarii de disponibilitate ridicată, imprimare pull, alocarea automată a cozilor sau suport avansat V4. Nu sunt esențiale, dar pot ușura viața atunci când se lucrează cu o combinație de modele, site-uri și sisteme de operare client.

Identificatori cheie: CompatibleIDs, PrinterDriverID și GUID

Modelul V4 se bazează în mare măsură pe identificatori bine definiți pentru a lega imprimantele și driverele . Două dintre cele mai importante sunt CompatibleIDs (pentru driverele de clasă) și PrinterDriverID (pentru relațiile dintre drivere și cozile partajate).

ID-urile CompatibleID sunt esențiale pentru ca un driver de clasă să suporte dispozitive lansate după versiunea de Windows în care a fost inclus. În loc să utilizeze un HardwareID complet specific, dispozitivul publică un identificator compatibil mai generic, care permite sistemului să îl asocieze cu un driver de clasă existent, cu condiția ca acestea să vorbească același limbaj de imprimare.

Pe imprimante paralele sau USBAceste CompatibleID-uri sunt de obicei incluse în șirul 1284ID.Formatul recomandat de Microsoft pentru dispozitivele noi este similar cu: 1284_CID_fabricante_PDL_familiade exemplu 1284_CID_FA_PCL5e_LaserDacă ID-urile CompatibleID au fost deja implementate, acestea sunt menținute pentru a evita încălcarea compatibilității.

Pentru dispozitivele TCP/IP bazate pe porturi standard, ID-urile CompatibleID nu sunt relevante în timpul instalării . În aceste cazuri, utilizatorii aleg de obicei driverul exclusiv pe baza numelui său, așa că producătorii sunt sfătuiți să publice liste clare de compatibilitate pentru fiecare clasă de drivere pe site-urile lor web.

Microsoft definește, de asemenea, un set de CompatibleID-uri standard pentru diverse PDL-uri , legate de drivere de clasă independente de furnizor. De exemplu, există ID-uri standard pentru XPS, OpenXPS (ECMA-388), PCL6 și PostScript. Aceste drivere standard oferă doar un subset mic de funcții (dimensiuni de hârtie Letter și A4, rezoluții de 300 și 600 dpi, tip de hârtie simplă, unele opțiuni N-up), așa că producătorii care le utilizează trebuie să suplimenteze funcționalitatea prin configurare îmbunătățită și BIDI.

Celălalt identificator crucial este PrinterDriverID . Acest ID este utilizat pentru a determina compatibilitatea driverelor atunci când imprimantele sunt partajate și, de asemenea, pentru a lega driverele și extensiile de imprimantă (de exemplu, aplicații de configurare avansată). Când o imprimantă partajată de pe server specifică un PrinterDriverID în manifestul său, clienții caută în depozitul local de imprimante și în Windows Update un driver care are același PrinterDriverID în fișierul său INF, indiferent de numele comercial al driverului.

Pentru ca două drivere să aibă același PrinterDriverID, acestea trebuie să fie cu adevărat compatibile : să utilizeze același PDL, același tip de fișier de configurare (GPD sau PPD), să poată reprezenta cu acuratețe caracteristicile descrise în fișierele de configurare ale serverului și să suporte aceleași extensii de imprimantă. Spooler-ul nu validează aceste condiții; se bazează exclusiv pe PrinterDriverID, așadar producătorii sunt responsabili pentru actualizarea ID-ului dacă oricare dintre aceste elemente se modifică.

Extensiile de imprimantă (cum ar fi panourile de setări avansate din interfața cu utilizatorul) sunt, de asemenea, asociate cu driverele care utilizează PrinterDriverID. Ultima extensie instalată care indică un anumit PrinterDriverID se aplică tuturor dispozitivelor care o partajează, așadar toate driverele cu acel ID trebuie să fie compatibile cu aceeași aplicație de extensie.

Pentru a gestiona toți acești identificatori, V4 utilizează extensiv GUID-urile (identificatori unici la nivel global). Acestea sunt utilizate în PrinterDriverID, PrinterExtensionID, EventID, ModelID etc. Microsoft recomandă insistent generarea lor întotdeauna cu instrumente precum Visual Studio sau SDK-ul, evitând soluțiile alternative de tip copiere și lipire care ar putea cauza conflicte.

Comportamentul de configurare: cozi, nume și noduri de dezvoltare

Modul în care imprimantele sunt denumite și grupate se schimbă și el odată cu modelul V4 . Windows creează noduri de dispozitiv software (devnodes) pentru toate cozile, fie că sunt imprimante fizice Plug and Play, imprimante virtuale sau conexiuni de dispozitive de rețea, permițând gestionarea uniformă a acestora în „Dispozitive și imprimante”.

În driverele V3, numele cozii depindea în mare măsură de numele driverului și de datele introduse de utilizator . Cu driverele V4 și cele bazate pe clase, numele respectiv oferă mai puține informații utilizatorului, așa că Windows încearcă să fie mai inteligent și interoghează dispozitivul prin cod QR pentru a obține un nume mai ușor de utilizat.

Procesul tipic este acesta : mai întâi, numele driverului este atribuit cozii. Dacă driverul este V4, Windows interoghează dispozitivul pentru \\Printer.DeviceInfo:FriendlyName; dacă este disponibil, îl adoptă ca nume al cozii. Dacă nu, încearcă să combine \\Printer.DeviceInfo:Manufacturer și \\Printer.DeviceInfo:ModelName. Dacă comunicarea BIDI eșuează, sistemul revine la șirul de ID IEEE 1284, utilizând DESCRIPTION/DES sau, în caz contrar, combinații de MANUFACTURER/MFG și MODEL/MDL.

Gruparea dispozitivelor multifuncționale sub o singură pictogramă se bazează pe partajarea aceluiași identificator de container. Când portul unei cozi este modificat (de exemplu, de la WSD la TCP/IP sau un port proprietar), containerul asociat cu devnode-ul cozii se modifică și el, iar această grupare, împreună cu celelalte funcții PnP ale dispozitivului, se poate pierde.

În scenariile de administrare IT, un administrator ar putea descoperi o imprimantă folosind WS-Discovery , apoi să modifice portul la TCP/IP prin preferințele de administrare, doar pentru a găsi două „dispozitive” listate în folderul Dispozitive și imprimante. Soluția implică eliminarea nodului devnode PnP original sau ajustarea identificatorilor containerului pentru a menține o singură pictogramă.

În instalările de la furnizori care includ monitoare de porturi personalizate (permise doar cu V3) , se poate întâmpla ceva similar: expertul de instalare schimbă portul cozii cu unul personalizat. Programul trebuie apoi să decidă dacă să păstreze devnode-ul PnP, ajustând identificatorul containerului sau să elimine dispozitivul fizic inițial, astfel încât să rămână doar coada asociată cu portul personalizat.

Articol asociat:

Cum se instalează Windows Server din linia de comandă: Un ghid complet

Isaac

Scriitor pasionat despre lumea octeților și a tehnologiei în general. Îmi place să îmi împărtășesc cunoștințele prin scriere și asta voi face în acest blog, să vă arăt toate cele mai interesante lucruri despre gadgeturi, software, hardware, tendințe tehnologice și multe altele. Scopul meu este să vă ajut să navigați în lumea digitală într-un mod simplu și distractiv.