The nightmarish problem of installing a printer

[Jerry]

On Tue, 21 Sep 2010 02:42:22 +0200
C. P. Ghost <cpghost at cordula.ws> articulated:

> 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.

The bottom line is that installing and running a printer on a Window's
machine is usually far easier than on a *nix variation. Even sharing a
printer on a network in a Windows environment is simpler.

On a separate note, I have friends who claim that the Ubuntu printer
installation routine is similar to the Window's one and works quite well
for most mainstream printers. I read something a few months ago that
Ubuntu was working on using Window's printer drivers directly in Ubuntu.
I cannot confirm that; however, it would certainly be a worthwhile
avenue to explore.

-- 
Jerry ✌
FreeBSD.user at seibercom.net

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the Reply-To header.
__________________________________________________________________