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.