ddiwrapper/Gsoc Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)
So far only one person has signed up with gsoc to do the win32 print driver under linux... I found out why I couldn't build ddiwrapper earlier - it builds against latest wine now; the reason was that I was ripping from opensuse/suse src rpm, and I did not look at any of the bundled patch, and there is a bundled patch which does that. The authoritative site for ddiwrapper seems to be: ftp://ftp.suse.com/people/uli/ddiwrapper/ Although it is quite difficult to find, since most search engine gives various publibc part of suse/novell. I think the src.rpm bundled patch needs to go in properly as a new release, really. ([EMAIL PROTECTED] is the author of ddiwrapper). --- On Sun, 30/3/08, Detlef Riekenberg <[EMAIL PROTECTED]> wrote: > From: Detlef Riekenberg <[EMAIL PROTECTED]> > Subject: Re: DLL exports... HELP?! (wine based win32 printer drivers for > openprinting) > To: "Hin-Tak Leung" <[EMAIL PROTECTED]> > Cc: "Till Kamppeter" <[EMAIL PROTECTED]> > Date: Sunday, 30 March, 2008, 10:16 PM > On Sa, 2008-03-29 at 15:51 +, Hin-Tak Leung wrote: > > 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. > > A applied as Mentor today to Help with the Applications > (winspool #at# googlemail.com) > > > You can reach me on irc (freenode.net) in #winehackers > My nick is "winspool" > > > -- > > By by ... Detlef __ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)
On Sa, 2008-03-29 at 15:51 +, 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
Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)
Hi Hin-Tak,
no no misunderstanding ;) ...that printer proxy does exactly what the name says: it's only purpose
is to log the calls a printer driver receives from the windows spooler. And yes, somehow some
glitches creeped in ^ ^
The rest of my work - as Detlef has already stated - depends on a lot of stuff that has yet to be
implemented (huw is working on the DIB engine..). Anyways, I am working on getting something
merged.. For now the target is to get the Adobe pscript5 driver working which has its own raster
renderer and thus does not depend on the dib engine. Just started by making AddPrinter correctly get
a default devmode out of the driver, patch is attached, detlef please comment on it (and hope you
got to your family dinner in time...;)
regards marcel.
--
"Obstacles are those frightful things you see when you take your eyes off your
goal."
-- Henry Ford
(1863-1947)
Change the world! Vote revolution: http://hfopi.org/vote-future
>From 0f9a857c8527a782418b5aaa1706db26c0cb577e Mon Sep 17 00:00:00 2001
From: Marcel Partap <[EMAIL PROTECTED]>
Date: Sun, 30 Mar 2008 05:13:16 +0200
Subject: [PATCH] winspool & localspl native driver dll calls
---
dlls/localspl/localspl_main.c | 16 ++-
dlls/winspool.drv/info.c | 97 +++-
include/ddk/winddiui.h| 17 +++
3 files changed, 107 insertions(+), 23 deletions(-)
diff --git a/dlls/localspl/localspl_main.c b/dlls/localspl/localspl_main.c
index 77fb730..30628bd 100644
--- a/dlls/localspl/localspl_main.c
+++ b/dlls/localspl/localspl_main.c
@@ -29,6 +29,7 @@
#include "winreg.h"
#include "winspool.h"
#include "ddk/winsplp.h"
+#include "ddk/winddiui.h"
#include "winuser.h"
#include "wine/debug.h"
@@ -62,6 +63,7 @@ HINSTANCE LOCALSPL_hInstance = NULL;
static const PRINTPROVIDOR * pp = NULL;
+static PFN_DrvDriverEvent pDrvDriverEvent = NULL;
static const WCHAR backslashW[] = {'\\',0};
static const WCHAR configuration_fileW[] = {'C','o','n','f','i','g','u','r','a','t','i','o','n',' ','F','i','l','e',0};
@@ -408,6 +410,7 @@ static BOOL WINAPI myAddPrinterDriverEx(DWORD level, LPBYTE pDriverInfo, DWORD d
DWORD disposition;
DWORD len;
LONGlres;
+HINSTANCE hcfgdll;
/* we need to set all entries in the Registry, independent from the Level of
DRIVER_INFO, that the caller supplied */
@@ -525,7 +528,18 @@ static BOOL WINAPI myAddPrinterDriverEx(DWORD level, LPBYTE pDriverInfo, DWORD d
if (level > 5) TRACE("level %u for Driver %s is incomplete\n", level, debugstr_w(di.pName));
RegCloseKey(hdrv);
-TRACE("### DrvDriverEvent(...,DRIVEREVENT_INITIALIZE) not implemented yet\n");
+
+apd.dst[apd.dstlen] = '\0';
+lstrcatW(apd.dst, di.pConfigFile);
+hcfgdll = LoadLibraryW(apd.dst);
+if (hcfgdll) {
+pDrvDriverEvent = (void*)GetProcAddress(hcfgdll, "DrvDriverEvent");
+if (pDrvDriverEvent) {
+lres = pDrvDriverEvent(DRIVER_EVENT_INITIALIZE, 3, (LPBYTE)&di, (LPARAM)NULL);
+TRACE("DrvDriverEvent returned %d\n", lres);
+}
+FreeLibrary(hcfgdll);
+}
TRACE("=> TRUE with %u\n", GetLastError());
return TRUE;
diff --git a/dlls/winspool.drv/info.c b/dlls/winspool.drv/info.c
index dadc61f..6229d41 100644
--- a/dlls/winspool.drv/info.c
+++ b/dlls/winspool.drv/info.c
@@ -56,6 +56,7 @@
#include "wine/debug.h"
#include "wine/list.h"
#include "winnls.h"
+#include "ddk/winddiui.h"
#include "ddk/winsplp.h"
#include "wspool.h"
@@ -147,6 +148,7 @@ static INT (WINAPI *GDI_CallExtDeviceMode16)( HWND hwnd, LPDEVMODEA lpdmOutput,
LPSTR lpszDevice, LPSTR lpszPort,
LPDEVMODEA lpdmInput, LPSTR lpszProfile,
DWORD fwMode );
+static PFN_DrvDocumentPropertySheets pDrvDocumentPropertySheets = NULL;
static const WCHAR DriversW[] = { 'S','y','s','t','e','m','\\',
'C','u', 'r','r','e','n','t','C','o','n','t','r','o','l','S','e','t','\\',
@@ -2136,6 +2138,49 @@ LONG WINAPI DocumentPropertiesA(HWND hWnd,HANDLE hPrinter,
return ret;
}
+/*
+ * WINSPOOL_CallDrvDocumentProperties (internal)
+ * calls native driver's DrvDocumentProperties
+ */
+static LONG WINSPOOL_CallDrvDocumentProperties(HANDLE hPrinter, LPWSTR pDeviceName,
+ LPDEVMODEW pdmOut, LPDEVMODEW pdmIn,
+ DWORD fMode)
+{
+DRIVER_INFO_2W *di;
+DWORD needed;
+HINSTANCE hcfgdll;
+DOCUMENTPROPERTYHEADER dph;
+LONG lres;
+
+GetPrinterDriverW(hPrinter, NULL, 2, NULL, 0, &needed);
+di = HeapAlloc(GetProcessHeap(), 0, needed);
+if (!GetPrinterDriverW(hPrinter, NULL, 2, di, needed, &needed))
Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)
I had a better look at the wine 2007 GSOC work - works quite alright, found my CUPS spooler; I am surprised that it uses the registry. It builds alright with mingw cross compiler (I have it around for other stuff and reasonably familiar with it), but a little surprised that there are a few compiler warnings which should be fixed, for code base this small. --- On Fri, 28/3/08, Detlef Riekenberg <[EMAIL PROTECTED]> wrote: > I'm away for the weekend, but some quick notes: > > - 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? 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? > - 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... 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). __ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
Re: DLL exports... HELP?!
There are two comments about the tarball - it is a tbz2 file (not tar.gz as the name implied). and it does build alright with mingw, with a little editing. There is a header problem (which seems to be newly introduced compared to the older(?) GSOC submission), and a couple of compiler warnings which should be fixed. BTW, I am using mingw-cross gcc 4.2.1(?), probably shows a bit more warnings than 3.4.5. and I think cross-compiler built from the mingw camp tends to have i386-mingw-* rather than i586-mingw-*; some 3rd party distributes i586-mingw-*'s. In any case, i386-mingw-* is what I have. (I did build the cross-compiler myself, rather than a downloaded binary). --- On Wed, 26/3/08, Marcel Partap <[EMAIL PROTECTED]> wrote: > From: Marcel Partap <[EMAIL PROTECTED]> > Subject: Re: DLL exports... HELP?! > To: [EMAIL PROTECTED] > Cc: wine-devel@winehq.org > Date: Wednesday, 26 March, 2008, 11:51 AM > Hi Stefanov, > attached is the code of a standalone proxy DLL I developed > last year during SoC, have a look > especially at the makefile for cross-compilation... > regards marcel. > > -- > >"Obstacles are those frightful things you see when > you take your eyes off your goal." > >-- Henry Ford (1863-1947) >Change the world! Vote revolution: > http://hfopi.org/vote-future > __ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)
On Mi, 2008-03-26 at 14:47 +, Hin-Tak Leung wrote: > Wow :-). I have almost wanted to suggest such a native wine-based > printer driver > as a linux foundation/openprinting GOSC project (I am one of the > mentors under the > openprinting umbrella > https://www.linux-foundation.org/en/Google_Summer_of_Code). > I am glad I didn't :-). > I'm away for the weekend, but some quick notes: - The ddiwrapper-hack works only with a very small amount of self-contained drivers - 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 - Sending the rendered Data to the Printer need sometimes a vendor- specific Portmonitor / Languagemonitor (Not supported in current Wine) -- By by ... Detlef
Re: DLL exports... HELP?!
Wow :-). I have almost wanted to suggest such a native wine-based printer driver as a linux foundation/openprinting GOSC project (I am one of the mentors under the openprinting umbrella https://www.linux-foundation.org/en/Google_Summer_of_Code). I am glad I didn't :-). I suppose under the terms of the license you don't mind we do some work based on your work? I'll let "the other printing folks" know. --- On Wed, 26/3/08, Marcel Partap <[EMAIL PROTECTED]> wrote: > From: Marcel Partap <[EMAIL PROTECTED]> > Subject: Re: DLL exports... HELP?! > To: [EMAIL PROTECTED] > Cc: wine-devel@winehq.org > Date: Wednesday, 26 March, 2008, 11:51 AM > Hi Stefanov, > attached is the code of a standalone proxy DLL I developed > last year during SoC, have a look > especially at the makefile for cross-compilation... > regards marcel. > > -- > >"Obstacles are those frightful things you see when > you take your eyes off your goal." > >-- Henry Ford (1863-1947) >Change the world! Vote revolution: > http://hfopi.org/vote-future > ___ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
Re: DLL exports... HELP?!
Hi Stefanov, attached is the code of a standalone proxy DLL I developed last year during SoC, have a look especially at the makefile for cross-compilation... regards marcel. -- "Obstacles are those frightful things you see when you take your eyes off your goal." -- Henry Ford (1863-1947) Change the world! Vote revolution: http://hfopi.org/vote-future printerproxydriver.tar.gz Description: application/gzip
Re: DLL exports... HELP?!
On Wednesday 26 March 2008 12:39:39 pm you wrote: > If you build a wine dll inside the wine source tree we use gcc in > combination with some wine magic for compilation. Exporting of functions in > that case happens through a '.spec' file. > > When you want to work outside the wine tree (as it can be more convenient) > you could also use 'winegcc' for building a library. It will handle all the > magic for you. > > Roderick cplskeleton.spec: " 1 stdcall CPlApplet(long long long long) " " libcplskeleton.def ; File generated automatically from ./cplskeleton.spec; do not edit! LIBRARY cplskeleton.dll EXPORTS [EMAIL PROTECTED] @1 "
Re: DLL exports... HELP?!
If you build a wine dll inside the wine source tree we use gcc in combination with some wine magic for compilation. Exporting of functions in that case happens through a '.spec' file. When you want to work outside the wine tree (as it can be more convenient) you could also use 'winegcc' for building a library. It will handle all the magic for you. Roderick > > >Folks, I've been trying to make a bunch of control panel applets > for wine for some time now. > >a CPL is basically a DLL which (the most importnat part) exports a > function called "CPlApplet"; Without it, the cpl isn't worth a thing. > It is the presence of that export which basically identifies it as a > control panel applet. > >Indeed, opening a random .cpl with dllexp yields: > >Function: CPlApplet Address: 0x0041b604 Relative Address: > 0x0041b604 Ordinal 1 (0x1) Filename: intl.cpl > >This one is from the cpl I wrote some time ago in Delphi, and it's > the same with all other 'doze cpls. I'm working on porting it to C and > wine, but that export is really getting the best of me. > >However, dllexp doesn't detect _any_ DLL exports in wine's .dlls, > so I'm stuck without a template :( Am I missing something? (A simple > *hello world* dll source that compiles against wine's source and > exports ANY function would be greatly appreciated) > >Thanks in advance, > >Stefanov. > > - > > Вземи 2 безплатни месеца БТК ADSL! > Поръчай online дo 20 март 2008! > Надежден Високоскоростен Интернет! > http://www.btc.bg/bg/adsl_order.php?residential&action=order&view_pack=1 -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
