Date: Tue, 21 Sep 2010 07:37:22 -0400 From: Jerry <freebsd.user@seibercom.net> To: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: The nightmarish problem of installing a printer Message-ID: <20100921073722.49d49e98@scorpio> In-Reply-To: <AANLkTi=VBb=_9_=HkhN61tbbS=3EYBVf3QNiML-cWM=o@mail.gmail.com> References: <201009201716.o8KHGpxf013791@mail.r-bonomi.com> <AANLkTi=VBb=_9_=HkhN61tbbS=3EYBVf3QNiML-cWM=o@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 21 Sep 2010 02:42:22 +0200 C. P. Ghost <cpghost@cordula.ws> articulated: > On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi > <bonomi@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@seibercom.net Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100921073722.49d49e98>