The nightmarish problem of installing a printer

[C. P. Ghost]

On Tue, Sep 21, 2010 at 5:43 PM, Polytropon <freebsd at edvax.de> wrote:
> On Tue, 21 Sep 2010 02:42:22 +0200, "C. P. Ghost" <cpghost at cordula.ws> wrote:
>> On Mon, Sep 20, 2010 at 7:16 PM, Robert Bonomi <bonomi at mail.r-bonomi.com> wrote:
>> 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.
>
> One big problem is that "Windows" doesn't equal "Windows". I had
> customers who intendedly bought some printer, then needed to switch
> to another "Windows", and then found their printer useless as there
> was no specific driver available anymore. Creating compatibility
> layers for printer drivers that do not care about compatibility at
> all is like shooting a moving target. As I am not a "Windows" person,
> I could only imagine that this would be much more difficult than
> printer manufacturers (who sit "at the source") agreeing to simply
> use an existing and documented standard.

So I assume that the binary blobs of those winprinters are different
for different versions of Windows. So there would be two (or three?)
set of interfaces to emulate instead of just one.

>> 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.
>
> I really doubt about a "stable interface", or situations as described
> above wouldn't have happened.

The stable interface is likely tied to one specific Windows release:
say, one for XP and one for Windows 7. Since most winprinters are
supposed to (still) run on XP, they come with an XP windriver blob,
and that's all what matters w.r.t. interface stability.

>> 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.
>
> Keep in mind there are stupid things in the world as patents,
> intelellectual property, licensing fees and copyrighted secret
> codes.

Yes, that's indeed the real problem. A legal, not a technical one.

> At the moment there was a program (or any other kind of
> facility) that makes Winprinters accessible by *ANY* OS (not
> only FreeBSD, but maybe all BSDs and Linusi and Solaris and
> who knows what else), MICROS~1 would start violently screaming
> as someone is eating from their cake. Keep in mind that Winprinters
> are an important target platform for home users who PAY for
> "Windows" and PAY for a "compatible" printer. They pay once
> every two years or so. MICROS~1 and the printer manufacturers
> can't stand it if one uses their products too long, as long-term
> use does imply NO FURTHER SALES. And now imagine that a user
> can fully use all features of a formerly-Winprinter all-in-one
> ink pee copier scanner fax machine - where would be his need to
> buy a "Windows" to do that as he can now use FreeBSD for free?

As far as I understand this, Microsoft doesn't manufacture those
winprinters, so why would they screem if those printers were able
to run on other platform too?

You can even see it the other way: for every winprinter manufactured
(or, more precisely, for every windriver sold), Microsoft may get a
fixed share due to patent royalties from the manufacturer. So, suppose
a manufacturer sells more of his winprinters to BSD/Linux/Solaris/...
folks because we had this shim, it would translate to more patent
royalties to Microsoft too. So it is in Microsoft's interest not only NOT
to kick and scream, but actually to encourage those winprinters
by publishing the needed interfaces. It can only increase sales, and
they will get more kickbacks from those additional sales.

> Of course, this consideration is very far away from any technical
> understanding - as typical for lawpersons who make money from
> bullshit. :-)

That's for sure. ;-)

>> 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 that case, I would ask myself: Why hasn't it been done already?
> If your assumption was right, it would already work. As it currently
> does not work, I would check your assumption. :-)

I don't know why it hasn't been done up to now. After all, this is nothing
but an exercise in mapping one set of interfaces onto another set of
interfaces. We've done this kind of interface matching with with the
Linuxulator, NDIS is another good example, and the Wine guys are
doing a great job too. I fail to see a compelling TECHNICAL reason
why Windows drivers in general (and windrivers in particular) couldn't
be docked to Unix systems. Of course, legal reasons are a different
matter.

> Polytropon
> Magdeburg, Germany
> Happy FreeBSD user since 4.0
> Andra moi ennepe, Mousa, ...

Regards,
-cpghost.

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