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