Date: Tue, 21 Sep 2010 02:42:22 +0200 From: "C. P. Ghost" <cpghost@cordula.ws> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: freebsd-questions@freebsd.org Subject: Re: The nightmarish problem of installing a printer Message-ID: <AANLkTi=VBb=_9_=HkhN61tbbS=3EYBVf3QNiML-cWM=o@mail.gmail.com> In-Reply-To: <201009201716.o8KHGpxf013791@mail.r-bonomi.com> References: <201009201716.o8KHGpxf013791@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi <bonomi@mail.r-bonomi.com> w= rote: > "Adapting" =A0MS-Windows print drivers is not 'practical' either. =A0A wi= ndows > print driver is embedd in the O/S KERNEL, =A0with _system_ calls_ (not > mere 'library' routines) that implement the 'device-dependant' rendering > of layout/formating directions. =A0One 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 t= o 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 botto= m 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 =3Dits=3Down=3Dmeans=3D 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. --=20 Cordula's Web. http://www.cordula.ws/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=VBb=_9_=HkhN61tbbS=3EYBVf3QNiML-cWM=o>