Installing drivers through PnP

[Jeremy Allison]

On Fri, Oct 19, 2001 at 11:14:00AM -0400, Vopni, Jim wrote:
> Peter:
> 
> We have been struggling with this issue for a while here.  We have been 
> trying to determine the exact behaviour of a NT Server and trying to relate 
> this to behaviour missing in Samba. When running AddPrinter to a remote NT 
> Server and specifying a Print Driver there seems to be some side affects. 
> After the call to the remote NT server there exists entries in the registry.
> It seems the DLLs are loaded into the spooler on the server and default 
> values are created.  
> 
> This seems to be the reason why MS forces you to add a NT4.0 driver before 
> you can add a 9x one.
> 
> On Samba, when you go to the Properties window and save setting many of
> these 
> defaults will then show up.    Unfortunately for some drivers not all are 
> set.  The problematic one that is not set is the SPLUserModePrinterDriver
> entry.  
> Without this entry the drivers we are using send "garbage" prefixed to the 
> datastream. If we manually do a SetPrinterData call setting the 
> SPLUserModePrinterDriver then everything starts to work.
> This seems to be the only one that stops us from printing.

Yep. This is because this entry is set when the driver binary is run
as a Win32 program on the server which will be serving out the driver.

Yes, that's right, the MS driver model DEPENDS ON DRIVER CODE BEING EXECUTABLE
ON THE SERVER !!!!!

This was so braindamaged I found it hard to believe at first.

Currently, I don't think there's any way for Samba to fix drivers like these.
It's actually a bug in the drivers, that they expect to be able to run
on the server (all the world is x86 of course....).

This would break if an NT alpha box was trying to serve out x86 driver
binaries to Windows clients.

Oh yeah, I almost forgot - Windows doesn't *run* on anything but intel
x86 any more, problem solved :-(.

> I am not sure how this problem can be dealt with in Samba since the DLL code
> can not be run and we haven't seen any way to anticipate the required
> settings.It looks like it may need to handled by getting the driver authors 
> to stop relying on this initialization of the registry settings.

Absolutely. These are really driver bugs that are "permitted" on Windows
x86 systems.

Jeremy.