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 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.
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
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 CPlApplet(a)16 @1 "
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. -- <div id="signature"> "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 </div>
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 <mpartap(a)gmx.net> wrote:
From: Marcel Partap <mpartap(a)gmx.net> Subject: Re: DLL exports... HELP?! To: pure_evil(a)mail.bg Cc: wine-devel(a)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.
-- <div id="signature"> "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 </div>
___________________________________________________________ Rise to the challenge for Sport Relief with Yahoo! For Good http://uk.promotions.yahoo.com/forgood/
On Mi, 2008-03-26 at 14:47 +0000, 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
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 <wine.dev(a)web.de> wrote: <snipped>
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
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. -- <div id="signature"> "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 </div>
On So, 2008-03-30 at 06:03 +0200, Marcel Partap wrote:
Anyways, I am working on getting something merged..
Great!
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. A Postscript Driver has no raster renderer... A Postscript Driver has a Postscript Engine.
Just started by making AddPrinter correctly get a default devmode out of the driver, patch is attached,
DRIVER_EVENT_INITIALIZE, 3, "3" is wrong here. See: myAddPrinterDriverEx(DWORD level, ...
Since there are much more Events, we need the DriverUI in more Places later. I suggest a simple struct, which can be extended later (The struct must include the Results from GetProcAddress) The changes for winspool.drv must go in a seperate Patch. WINSPOOL_CallDrvDocumentProperties is the wrong name, when you call DrvDocumentPropertySheets. You should collect all API in winspool.drv, that need the driverui (some are not implemented) and design a simple struct with helper functions (Use monitor_t as example). Not all Drivers Export DrvDocumentPropertySheets. You must prepare to use a Fallback to get the default devmode (DrvConvertDevMode) See winspool.drv/monitor_load as Example: - InitializePrintMonitor2 is suggested my MSDN, but not needed yet - InitializePrintMonitor implemented - InitializeMonitorEx and InitializeMonitor as Fallback. The current Code is a crosscall from DocumentPropertiesW to DocumentPropertiesA. The DDI-API is unicode and should be the prefered way. When wineps.drv is updated, the old code with the crosscall can be removed, since we do not support ANSI Drivers (Windows 9x). You can even use the same struct and helper functions in localspl.dll and winspool.drv -- By by ... Detlef
A Postscript Driver has no raster renderer... A Postscript Driver has a Postscript Engine. ... ^ ^
DRIVER_EVENT_INITIALIZE, 3, "3" is wrong here. See: myAddPrinterDriverEx(DWORD level, ... It seemed suspicious to me anyway.. How do those integer shifts creep into my retyped header files again and again? mmmmhhh ... *g
Since there are much more Events, we need the DriverUI in more Places later. I suggest a simple struct, which can be extended later (The struct must include the Results from GetProcAddress) a struct.. that contains what? the function pointers and results? i had thought about adding a macro.. for hooking driver exports..
The changes for winspool.drv must go in a seperate Patch. yeah it jsut was a quick and dirty preview patch ;)
WINSPOOL_CallDrvDocumentProperties is the wrong name, when you call DrvDocumentPropertySheets. statement totally makes sense.
You should collect all API in winspool.drv, that need the driverui (some are not implemented) and design a simple struct with helper functions (Use monitor_t as example). I dont really grok it... like the DDI_FUNCS array in the patch i sent you or rather somethign stuct { LPWSTR name; LPWSTR driverdll; HMODULE hdriver; LPWSTR interfacedll; HMODULE hinterface, DWORD refcount; } printertriver_t; ?
Not all Drivers Export DrvDocumentPropertySheets. You must prepare to use a Fallback to get the default devmode (DrvConvertDevMode) ok just need to transplant my old code
See winspool.drv/monitor_load as Example: l8r :)
The current Code is a crosscall from DocumentPropertiesW to DocumentPropertiesA. The DDI-API is unicode and should be the prefered way. so shall i put the ddi call before that deprecated stuff? and does it need to be called from docpropsA? oh and I reodne the EnumForms patch (now less monsterous ;). Now here's only the part that provides the builtin forms, but very easy to expand, once its ready to be &/ comimtted i'll do the addforms delforms stuff.. and oh sh1t gotta write my soc application today last day heh.. this time i'm opting for drupal/php code though C/win32api is just too hellish *g n8
-- <div id="signature"> "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 </div>
I am looking at ddiwrapper lately and having a lot of fun with it. Is Marcel's on-going not-merged work anywhere on line that I can have a peek before its merge into wine? Hin-Tak --- On Mon, 31/3/08, Detlef Riekenberg <wine.dev(a)web.de> wrote:
From: Detlef Riekenberg <wine.dev(a)web.de> Subject: wine based win32 printer drivers To: "Marcel Partap" <mpartap(a)gmx.net> Cc: wine-devel(a)winehq.org Date: Monday, 31 March, 2008, 12:12 AM On So, 2008-03-30 at 06:03 +0200, Marcel Partap wrote:
Anyways, I am working on getting something merged..
Great!
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. A Postscript Driver has no raster renderer... A Postscript Driver has a Postscript Engine.
Just started by making AddPrinter correctly get a default devmode out of the driver, patch is attached,
DRIVER_EVENT_INITIALIZE, 3, "3" is wrong here. See: myAddPrinterDriverEx(DWORD level, ...
Since there are much more Events, we need the DriverUI in more Places later. I suggest a simple struct, which can be extended later (The struct must include the Results from GetProcAddress)
The changes for winspool.drv must go in a seperate Patch. WINSPOOL_CallDrvDocumentProperties is the wrong name, when you call DrvDocumentPropertySheets.
You should collect all API in winspool.drv, that need the driverui (some are not implemented) and design a simple struct with helper functions (Use monitor_t as example). Not all Drivers Export DrvDocumentPropertySheets. You must prepare to use a Fallback to get the default devmode (DrvConvertDevMode) See winspool.drv/monitor_load as Example: - InitializePrintMonitor2 is suggested my MSDN, but not needed yet - InitializePrintMonitor implemented - InitializeMonitorEx and InitializeMonitor as Fallback.
The current Code is a crosscall from DocumentPropertiesW to DocumentPropertiesA. The DDI-API is unicode and should be the prefered way. When wineps.drv is updated, the old code with the crosscall can be removed, since we do not support ANSI Drivers (Windows 9x).
You can even use the same struct and helper functions in localspl.dll and winspool.drv
--
By by ... Detlef
___________________________________________________________ Yahoo! For Good helps you make a difference http://uk.promotions.yahoo.com/forgood/
I am looking at ddiwrapper lately and having a lot of fun with it. Well I didn't have much fun with it because for me first it did not build properly, then segfaulted. Anyways. Is Marcel's on-going not-merged work anywhere on line that I can have a peek before its merge into wine? ot online but attached is the work done last year. This year's work is still in the pipeline, not much time for it lately but its on the agenda. regards.
Hin-Tak
--- On Mon, 31/3/08, Detlef Riekenberg <wine.dev(a)web.de> wrote:
From: Detlef Riekenberg <wine.dev(a)web.de> Subject: wine based win32 printer drivers To: "Marcel Partap" <mpartap(a)gmx.net> Cc: wine-devel(a)winehq.org Date: Monday, 31 March, 2008, 12:12 AM On So, 2008-03-30 at 06:03 +0200, Marcel Partap wrote:
Anyways, I am working on getting something merged.. Great!
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. A Postscript Driver has no raster renderer... A Postscript Driver has a Postscript Engine.
Just started by making AddPrinter correctly get a default devmode out of the driver, patch is
attached,
DRIVER_EVENT_INITIALIZE, 3, "3" is wrong here. See: myAddPrinterDriverEx(DWORD level, ...
Since there are much more Events, we need the DriverUI in more Places later. I suggest a simple struct, which can be extended later (The struct must include the Results from GetProcAddress)
The changes for winspool.drv must go in a seperate Patch. WINSPOOL_CallDrvDocumentProperties is the wrong name, when you call DrvDocumentPropertySheets.
You should collect all API in winspool.drv, that need the driverui (some are not implemented) and design a simple struct with helper functions (Use monitor_t as example). Not all Drivers Export DrvDocumentPropertySheets. You must prepare to use a Fallback to get the default devmode (DrvConvertDevMode) See winspool.drv/monitor_load as Example: - InitializePrintMonitor2 is suggested my MSDN, but not needed yet - InitializePrintMonitor implemented - InitializeMonitorEx and InitializeMonitor as Fallback.
The current Code is a crosscall from DocumentPropertiesW to DocumentPropertiesA. The DDI-API is unicode and should be the prefered way. When wineps.drv is updated, the old code with the crosscall can be removed, since we do not support ANSI Drivers (Windows 9x).
You can even use the same struct and helper functions in localspl.dll and winspool.drv
--
By by ... Detlef
___________________________________________________________ Yahoo! For Good helps you make a difference
-- <div id="signature"> "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 </div>
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
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 <mpartap(a)gmx.net> wrote:
From: Marcel Partap <mpartap(a)gmx.net> Subject: Re: DLL exports... HELP?! To: pure_evil(a)mail.bg Cc: wine-devel(a)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.
-- <div id="signature"> "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 </div>
__________________________________________________________ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html
participants (5)
-
Detlef Riekenberg -
Hin-Tak Leung -
Marcel Partap -
pure_evil＠mail.bg -
Roderick Colenbrander