The nightmarish problem of installing a printer

[C. P. Ghost]

On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
> "Adapting"  MS-Windows print drivers is not 'practical' either.  A windows
> print driver is embedd in the O/S KERNEL,  with _system_ calls_ (not
> mere 'library' routines) that implement the 'device-dependant' rendering
> of layout/formating directions.  One then takes the 'opaque object' so
> produced and sends it (via _another_ set of system calls) to the 'output'
> function of that same driver.

Is that really so? How about writing some emulation shim like ndis(4) for
winprinters? Please correct me if I'm wrong, as I'm not a Windows systems
programmer, but this is what I'm thinking about.

As far as I understand Windows printing, there are two aspects to resolve,
given a vendor supplied windriver binary blob:

1/ the windriver gets some (opaque) data from the GDI+ -- maybe
a bitmap, with some meta data.

2/ the windriver interprets this data however it sees fit, and then talks to
the NT kernel (maybe via DLL calls) to send electrical impulses to the
printer.

Now, the data formats of 1/ (GDI stuff) is probably well defined (and
therefore published) in gdiplus.dll or something similar and is the same
for all windriver blobs. The API/ABI needed to talk to the NT kernel is
probably defined in the Windows DDK (or whatever it is called nowadays).

So, in both cases, we have stable API/ABI interfaces on both sides
of the windriver binary blob: 1/, 2/ at the upper half, and 2/ at the bottom
half.

So, if we wanted to use those windriver blobs just like in the ndis(4)
case, all we need is an emulation shim for both interfaces. Maybe 1/ is
already covered by Wine (?) so we could borrow some code from there;
and 2/ is basically a matter of mapping the subset of NT calls needed
to read from and write to Windows ports to Unix calls to read and write
to our Unix devices.

Again, I'm no Windows programmer, and it is probably more involved
than this. But the basic idea remains: the interfaces on both sides of the
windriver binary blobs is pretty stable and (I think) not a secret at all.

> In the Unix world, printing is handled _externally_ to the kernel. The
> application must have =its=own=means= of deciding what formatting/layout
> commands to use -- it _can't_ query the O/S for this info; the O/S simply
> doesn't have it.

Well, it doesn't matter if the windriver shims run as userland daemon or
(partially) inside the kernel. The point here is that the windriver <-> NT,
and windriver <-> GDI+ interface are both stable and not difficult to
understand, so both can be emulated. At least theoretically. In practice,
it takes some time and effort to get it right, quite obviously.

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/