Re: [winspool 2/6] Move the dlopen of libcups to a separate function, allowing CUPS to be used prior to the full on loading of CUPS printers.

[Detlef Riekenberg]

Hi Jeremy

What is your reason for your work in winspool.drv?
What are your plans?

Even if the Patchset changes some things, it's not the correct location to do that.

winspool.drv must not do anything with the registry or the driver files.
winspool.drv must not use cups at all
wineps.drv must not use cups at all

That all belong to a print provider, together with a print monitor.
To make our live easy, the printprovider and printmonitor for CUPS and LPR will be integrated into localspl.dll 
(windows is using seperate provider/monitor: See inetpp.dll and lprmon.dll with friends)

I have a Patch here for moving AddPrinter to localspl, that address most of your changes,
but a small peace of code is only in my test app and not in the Patch yet (get default DEVMODEW from the Driver)
An important issue is, that we store DEVMODEA in the registry.
Code is there to handle that, bu it failed on julliards machine.

My localspl.dll has a cups.c, but that need more work(i can't continue before mid januar).

And IMHO, using wine_get_unix_file_name in High-level dlls is wrong by design.

W2k pro and XP pro have driver directories only for supported environments.
(Servers are different)
When you think, that you need the driver directories, they can be created with wine.inf

Please avoid ANSI strings in new code. (strdupWtoA should go away)


-- 
By by ... Detlef

___________________________________________________________
Preisknaller: WEB.DE DSL Flatrate für nur 16,99 Euro/mtl.! 
http://produkte.web.de/go/02/

[winspool 2/6] Move the dlopen of libcups to a separate function, allowing CUPS to be used prior to the full on loading of CUPS printers.

[Jeremy White]

Hi Detlef,

Detlef Riekenberg wrote:
> Hi Jeremy
>
> What is your reason for your work in winspool.drv?
> What are your plans?

I'm just trying to fix printing in Acrobat Reader 9.2 for
a client; this test shows the current failure:
  http://source.winehq.org/git/wine.git/?a=blob;f=dlls/winspool.drv/tests/info...
> Even if the Patchset changes some things, it's not the correct location to do that.
>
> winspool.drv must not do anything with the registry or the driver files.
> winspool.drv must not use cups at all
> wineps.drv must not use cups at all
>
> That all belong to a print provider, together with a print monitor.
> To make our live easy, the printprovider and printmonitor for CUPS and LPR will be integrated into localspl.dll 
> (windows is using seperate provider/monitor: See inetpp.dll and lprmon.dll with friends)
>
> I have a Patch here for moving AddPrinter to localspl, that address most of your changes,
> but a small peace of code is only in my test app and not in the Patch yet (get default DEVMODEW from the Driver)
> An important issue is, that we store DEVMODEA in the registry.
> Code is there to handle that, bu it failed on julliards machine.

Right; the more I worked on this, the less I knew <grin>.
And I do still feel that I'm a bit out of my depth here,
so I appreciate your advice very much.

My hope is that this patch set does not make things worse.
I mostly rearrange the handling of cups and registry code
within winspool.drv and wineps.drv.
> My localspl.dll has a cups.c, but that need more work(i can't continue before mid januar).
>
> And IMHO, using wine_get_unix_file_name in High-level dlls is wrong by design.

Well, I believe you will have to use it where ever you invoke CUPS, so that is really tied to
the location of our CUPS code more than anything.
> W2k pro and XP pro have driver directories only for supported environments.
> (Servers are different)
> When you think, that you need the driver directories, they can be created with wine.inf

Right; I first tried to change wine.inf.  But then I found that
the initial system printer loading was invoked prior to the inf file processing
(it happens at winspool.drv dll attach time).
Perhaps that is wrong and should be fixed.
> Please avoid ANSI strings in new code. (strdupWtoA should go away)

I initially implemented this with wide strings. That led to
cover functions WINSPOOL_GetPPDNameA and WINSPOOL_CopyPPDA
because the code it interfaces with was ANSI.  It struck
me as ugly and I imagined Alexandre telling me it was wrong.

Alexandre, was that the wrong choice?

----

Candidly, the fundamental issue seems to be whether or not trying to solve
this issue should be frozen until you can get your revamp in.

Would my patch set make your life substantially harder?  I think
your change is vital, and I really don't want to do that.

My hope is that my patch set would be at worst a minor nuisance,
and could thus go in.

Cheers,

Jeremy

[winspool 2/6] Move the dlopen of libcups to a separate function, allowing CUPS to be used prior to the full on loading of CUPS printers.

[Alexandre Julliard]

Jeremy White <jwhite(a)codeweavers.com> writes:
> I initially implemented this with wide strings. That led to
> cover functions WINSPOOL_GetPPDNameA and WINSPOOL_CopyPPDA
> because the code it interfaces with was ANSI.  It struck
> me as ugly and I imagined Alexandre telling me it was wrong.
>
> Alexandre, was that the wrong choice?

Using A functions seems to make it easier to handle Unix filenames, but
that's wrong, because Unix filenames are not in the Ansi codepage. If
you want to pass them to A functions you need to convert CP_UNIXCP ->
Unicode -> CP_ACP, so using W functions is actually easier.

-- 
Alexandre Julliard
julliard(a)winehq.org