DLL exports... HELP?! (wine based win32 printer drivers for openprinting)

[Detlef Riekenberg]

On Sa, 2008-03-29 at 15:51 +0000, Hin-Tak Leung wrote:
> > - The ddiwrapper-hack works only with a very small amount
> > of self-contained drivers
> 
> Yes, but say, a GSOC project for distinguishing which are
> self-contained and which are not?
Only Usermode Printer Drivers (w2k and above) can work
(NT4 use Kernelmode Printer Drivers, which depends on "win32k.sys")

- use cabextract or unzip to get all files from the driver-installer
- use "wine expand.exe", when needed
- use winedump to get the imports for the driver
- Find the needed exports from gdi32.dll:
  $ grep " Eng"
  $ grep " [A-Z]*OBJ_"

- use winedump to get the exports
- to find the main driver dll and the driverui dll for later use:
  $ grep " Drv" 
  => DrvQueryDriverInfo is required for usermode Printer Drivers

> I haven't got round to look at ddiwrapper yet, but it is in my hard
> disc now. 

> > - Most Drivers today are plugins for the unidrv or the
> > pscipt5 Driver
> >   (you can install pscript5 from Adobe since ~ 1/2 Year)
> > - Drivers expect dlls, that are not present in wine-2005*
> >   (They will not load)
> > - Rendering with full Drivers (Raster-Mode) need most Eng*
> > Functions
> >   and Friends (This is the DIB-Engine).
> > - Rendering with full Drivers (Postscript) need some Eng*
> > Functions
> >   and Friends.
> >   Nothing in this Area is implemented / exported in current
> > Wine:
> >   Driver will not load
> 
> The time frame - GSOC work being a little after wine 1.0 (and the
> merge of the other work) - should be interesting and useful?

The implementation must be acceptable by Julliard.
My suggested way for an implementation:
1 Support "winspool" as Drivername in gdi32
  (gdi32 must use winspool.drv and winspool.drv must load and use
  the correct DriverUI)
  (Manage DEVMODEW and DeviceCapabilities. Use Dialogs)
2 The Dialogs for native Drivers would be nice at this stage, but this
  needs compstui.dll and printui.dll. The amount of work here is enough
  for a seperate SoC Project
3 Load and Initialize the native driver dll (ask winspool.drv for the
  real name) and expand the DC_FUNCTIONS array to store the results of
  DrvEnableDriver
4 Prefer the DDI-Functions over the current used API in all related
  gdi32 - Functions.
5 Pick one or more Windows Portscript-Driver and implement the needed
  Engine-Functions in gdi32.dll
6 Pick stupid Windows Raster-Drivers and implement the needed
  Engine-Functions in gdi32.dll
7 Pick other Windows Raster-Drivers and implement the needed
  Engine-Functions in gdi32.dll

The SoC 2007 Project of Marcel did #6 for a Canon Driver. 
Code is available, but the correct location is gdi32.dll

What is "Engine-Functions in gdi32.dll" ?
The famous DIB-Engine

> > - Sending the rendered Data to the Printer need sometimes a
> > vendor-
> >   specific Portmonitor / Languagemonitor
> >   (Not supported in current Wine)
> 
> Yes, I think the epson epl windows driver does that...

- grep "Initialize.*Monitor" exports_extracted_with_winedump.txt
  : InitializePrintMonitor2
  : InitializePrintMonitor
  : InitializeMonitorEx
  : InitializeMonitor
  => A Driver with a Portmonitor / Langemonitor does not work yet

  : InitializePrintMonitorUI
  => The Portmonitor User Interface works with a native printui.dll
  ( rundll32.exe printui.dll,PrintUIEntry /s /t 1 )
  (I use redmon 1.7 for testing)


> A personal question: would be like to be involved if a student comes
> along, or in general in this area? (I looked it up, you were the
> mentor for the 2007 wine project for the printerproxy).

In general in this Area, Please.


-- 
 
By by ... Detlef