Why We Built a True XPSDrv v4 Windows Driver — And Not Another Virtual Port

If you have ever tried to print a label from Microsoft Word, you know the experience. The Windows print dialog opens. You scroll through a list of printers. There's "Microsoft Print to PDF" and "Microsoft XPS Document Writer" and your old Zebra GK420d that "the IT team got working in 2017." You pick the Zebra. You click Print. The dialog freezes. Twelve seconds later a label comes out, somewhere between half the size you wanted and rotated 90 degrees the wrong way.

This experience is not Word's fault. It is the consequence of every thermal-label-printing application in the last twenty years choosing the easy implementation path: a virtual port. A virtual port is software pretending to be a printer; whatever data arrives on that port gets handed to the real label-printing application, which is supposed to figure out what to do with it. Word doesn't know it's not a real printer. Word just sends XPS pages at standard letter size. The label-printing application tries to scale, rotate, and clip — and produces what it produces.

LabelInn took the harder path. We built a true Microsoft XPSDrv v4 print driver. It registers as a v4 driver, not a v3 Unidrv. It implements a render filter that intercepts the XPS spool stream at the right point in the Windows printing pipeline. It publishes a dynamic media library so the user's actual label sizes appear in the Windows print dialog. It supports printer extensions so the print preferences UI is a real native dialog, not a popup from our application. And it routes to multiple physical printers from a single driver instance.

This post is the developer-targeted explanation of why those decisions matter, what they enable, and what they cost.

The two ways to inject a label printer into Windows

Option A — the virtual port (everyone else's choice)

A virtual port is a software shim that registers as a printer in Windows but is actually a named pipe or a TCP listener pointed at the label-printing application. The application has to take whatever Windows sends — typically a stream of XPS pages or a GDI rasterisation — and figure out what label to produce. The application has zero metadata about what the user actually wanted: which template, which printer, which roll of stock.

The user-visible failure mode: every label produced this way is a guess.

Option B — a true v4 driver (the LabelInn choice)

A v4 driver is a first-class component of the Windows print stack. It has structured metadata, the print preferences UI, dynamic media support, render filters, port monitors, and printer-extension applications. It works correctly with every application Windows knows how to print from, because it speaks the protocol the print system was designed for.

The user-visible behaviour: in Word, the LabelInn driver appears as a printer. The print dialog lists the user's actual configured label sizes. The user picks a label size. They click Print. The driver intercepts the XPS spool stream, transforms it into thermal printer commands, and routes those commands to the physical printer they configured. No guessing, no clipping, no rotation surprise.

The four moving pieces

1. The render filter

The render filter is a native (C++) component that sits in the Windows print pipeline between the spooler and the port monitor. It receives XPS pages and produces output for the next stage. Ours produces a structured payload encoding the page contents, the user's print preferences, and the target printer identity, and hands that payload off via a named pipe to the LabelInn application running in the user's session.

The render filter is the load-bearing piece. It is the only place in the system where Windows lets you intercept XPS at the right semantic level — too early and you see the raw application-side rendering; too late and you've lost the typeset content. The filter has to be performant, has to be robust to malformed XPS, and has to fail gracefully when the LabelInn application isn't running.

2. The dynamic media library

v4 drivers can publish a dynamic media list — the print dialog's "paper size" dropdown is populated from this list. We populate it from the user's configured label sizes. When the user adds a new label size in the LabelInn application, it appears in Word's print dialog the next time Word opens. No driver reinstall, no INF edits, no admin intervention.

This is the single biggest user-experience improvement over virtual-port designs. The user's mental model — "I have a 4×6 inch shipping label and a 2×1 inch product label" — is reflected in every Windows application's print dialog. They pick the size they want; the label comes out at that size.

3. The printer-extension application

When the user clicks "Print Preferences" on the LabelInn printer in Windows Settings, Windows launches our printer-extension application. This is a separate Flutter window that opens in about a second, lets the user pick the target physical printer, the print quality, the orientation, the density, and any printer-specific options, and persists the preferences back into the driver's PrintTicket store.

This matters for two reasons. First, the preferences UI feels native to Windows; it's not a weird popup from our application. Second, the LabelInn main application doesn't need to be open for the user to configure preferences. The preferences live in the driver, which is part of the operating system.

4. Multi-printer routing

One LabelInn driver installation can route prints to many physical printers. The driver itself is registered once. The PrintTicket carries the target printer identity. When a print arrives, the render filter looks at the PrintTicket, picks the right physical target, and routes the resulting thermal commands accordingly.

For an office with five Zebras on five different operators, this means one driver install, five printer-extension configurations, and zero confusion about which icon represents which physical device.

Offline spool fallback — when the app isn't running

The render filter writes the structured payload into a named pipe. If the LabelInn application is running, it reads the payload and prints. If the application is not running — closed, crashed, mid-update — the payload is instead persisted to %ProgramData%\LabelInn\spool\ with a structured filename and a timestamp. The next time the application starts, it drains the spool and prints the queued jobs in order.

This solves a real failure mode: the user prints from Word at 4:55 PM, doesn't notice the application crashed at 4:50 PM, walks out the door, and comes back the next morning to find the label has already printed because the application started up overnight from a recovery handler. The XPS payload is durable across application restarts.

The cost of doing this right

Building a v4 driver is not a weekend project. The Windows Driver Kit has its own toolchain, its own debugging story, and its own deployment story. The driver must be signed; for production release, that means an Extended Validation code-signing certificate, which is a multi-week procurement exercise on its own. For Windows Update distribution, the driver needs WHQL attestation, which is a separate submission to Microsoft Hardware Dev Center.

For the engineering team, this is months of work and tens of thousands of dollars in tooling and certificates. For LabelInn customers, the cost is zero — they install the LabelInn application, the driver registers itself, and the integration is done.

The reason we did it is the same reason every native Windows engineer would, if their product team gave them the budget: the experience on the user side, in Word, in Excel, in SAP, in QuickBooks, in any Windows application, is the experience of a real printer. Every label is the right size. Every print goes to the right device. The user does not have to learn what "virtual port" means.

What this means for customers running legacy label software

If you've been living with a virtual-port label printer — one of those "install our software, then we'll add a virtual printer" experiences — the LabelInn driver is the migration target. Word documents that used to come out half-sized come out the right size. Excel mail-merges that used to require a separate label-design import work directly. SAP one-off prints route to the right printer without a script.

If you're an IT administrator evaluating label-printing platforms, the question to ask in the demo is simple: "Show me printing a 4×6 label from Microsoft Word directly to your printer, with the right size, no clipping, no rotation surprise." If the demo skips Word and goes straight to the vendor's own designer, you know what they built.

Status

The v4 driver is shipped in current LabelInn builds for Windows. It is currently dev-signed for staging environments and being prepared for EV-cert signing + WHQL submission for general availability. Customers in the early-access program are running it in production today.