Hi all, I'm looking for subject for my Master's thesis. It might be interesting to do something useful for Wine. On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress. I think it is doable because Windows 2000 and later printer drivers are work in user-space. In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS.
Or maybe you have other ideas?
Best regards, Maciej Kowalczyk
I think it is doable because Windows 2000 and later printer drivers are work in user-space.
That might be interesting work, although if it's limited to Windows apps, it would probably be less useful than ddiwrapper is supposed to be.
In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS.
And if you look at ddiwrapper, you'll notice that it's based on Wine.
That said, we can certainly use the help! Pretty much anywhere you look, you'll be bound to turn up something. --Juan
On Di, 2007-09-04 at 08:17 +0200, Maciej Kowalczyk wrote:
I'm looking for subject for my Master's thesis. It might be interesting to do something useful for Wine.
Welcome to wine.
On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress.
It works, but the code is not ready for the wine-tree yet. The final solution must work with CreateDC("winspool",....) and need the complete DIB-Engine. Marcel is still working to improve his code and will start sending patches.
I think it is doable because Windows 2000 and later printer drivers are work in user-space.
Yes, that's exactly what will be supported.
In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS.
ddiwrapper use ghostscript to convert Postscript to a Bitmap and the Windows Printer Driver in a modified wine ("gdi32.dll" and "winspool.drv" where replaced) to print the Bitmap.
Or maybe you have other ideas?
There are a lot of things in wine, that are missing and need a lot of work. The new Printing-Dialog (File/Print in Internet Explorer) for example is called as PrintDlgExA/W in "comdlg32.dll", but the "General" Propertysheet is located in "printui.dll" and the Application and the Driver can add / change Propertysheets. The Propertysheets need many Features (Functions / Resources / Custom controls) from "compstui.dll". In wine we have: -comdlg32.dll: PrintDlgEx is a stub -printui.dll: Only commandline-parsing for a different part of printui -compstui.dll: Empty stub
I have no Idea what is needed / expected for the Master's thesis (complexity, amount of work).
On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress.
I am the guy responsible for not providing information about the progress - during SoC time I was most busy with actual coding and so did not even update my project blog.. sorry bout that :)
The final solution must work with CreateDC("winspool",....) and need the complete DIB-Engine.
Exactly, the gdi engines drawing engine functions (EngBitBlt, EngTextOut...) need support for raster operations, which should best be implemented in dib.c .. Right now the driver initialisation and
Marcel is still working to improve his code and will start sending patches.
Yeees I aam.. ;) But I am visiting my family for a few days ... you can have a look though at the current code under http://synth-worldz.de/wine-ddi/ddi.c ... too many stubs and unimplemented functions though, even if a few drivers already start feeling comfortable with it.
In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS.
Of course that code was a great source of inspiration (thank you Uli Hecht) for the current implementation of printbitmap.exe which you can have a look at at http://synth-worldz.de/wine-ddi/printbitmap.c..
ddiwrapper use ghostscript to convert Postscript to a Bitmap and the
That is an unsolved problem up to now, how to get a drawing operation to the driver? there's two options for that:
variant 1: application: sends drawing calls -> wineps.drv: renders a postscript -> ghostscript(win version preferably): renders to bitmap -> printbitmap.exe: loads native driver and simply blts the bitmap onto device surface and prints
variant2: GDI32/DDI: CreateDC("WINSPOOL"...): normal driver loading like on native: hook drawing functions from driver -> native driver: draw stuff on device surface, punt unhandled calls back to GDI -> GDI32/DDI+DIB: Eng* functions wrap around the specific DIB functions which do the actual raster operations
Right now variant 1 is kinda 'working' although it needs some more glue and love. Variant 2 is the next step, I'll start on this in a week or two after submitting the patches.. By the way who did work on CreateDC? Any ideas how to handle a printer device context? I have not yet looked into the details of the current implementation because I was instantly scared away by it ;)
There are a lot of things in wine, that are missing and need a lot of work.
Wow definite :) All the printer property sheets will require another major amount of care.. Anyways many regards, marcel
On 9/9/07, Marcel Partap mpartap@gmx.net wrote:
On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress.
I am the guy responsible for not providing information about the progress - during SoC time I was most busy with actual coding and so did not even update my project blog.. sorry bout that :)
The final solution must work with CreateDC("winspool",....) and need the complete DIB-Engine.
Exactly, the gdi engines drawing engine functions (EngBitBlt, EngTextOut...) need support for raster operations, which should best be implemented in dib.c .. Right now the driver initialisation and
Marcel is still working to improve his code and will start sending patches.
Yeees I aam.. ;) But I am visiting my family for a few days ... you can have a look though at the current code under http://synth-worldz.de/wine-ddi/ddi.c ... too many stubs and unimplemented functions though, even if a few drivers already start feeling comfortable with it.
What about the Drv* functions? If these get implemented, it would make forwarding from the dib engine back to the graphics driver a whole lot easier.
Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing. It should be done...
Jesse
On Mo, 2007-09-10 at 10:06 -0600, Jesse Allen wrote:
What about the Drv* functions?
Drv* are implemented by the Driver, while Eng* and Friends are the Graphic Rendering Engine (on windows in win32k.sys). The Exports in GDI are parts of the GRE for Usermode Printer Drivers.
Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing
The main Problem with the Rendering-API in Wine (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) is more like win3x and far away from DDI (Device Driver Interface).
On 9/23/07, Detlef Riekenberg wine.dev@web.de wrote:
On Mo, 2007-09-10 at 10:06 -0600, Jesse Allen wrote:
What about the Drv* functions?
Drv* are implemented by the Driver, while Eng* and Friends are the Graphic Rendering Engine (on windows in win32k.sys). The Exports in GDI are parts of the GRE for Usermode Printer Drivers.
Correct but we don't have it in Wine. If we added the Drv functions, while I have the parts of the DIB engine unimplemented, I could forward back to the driver alot easier. There is maybe another way, but having Drv functions make sense in my mind.
Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing
The main Problem with the Rendering-API in Wine (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) is more like win3x and far away from DDI (Device Driver Interface).
Do the Eng functions have to be based on DDI? Or can we use it with my DIB engine?
Jesse
On So, 2007-09-23 at 17:15 -0600, Jesse Allen wrote:
Correct but we don't have it in Wine. If we added the Drv functions, while I have the parts of the DIB engine unimplemented, I could forward back to the driver alot easier. There is maybe another way, but having Drv functions make sense in my mind.
That would be perfect (IMHO), when our Drivers (winex11, wineps) use DDI as API. I dont know our Driver-Code in this Area good enough, but I expect that this big change need a lot of testing.
Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing
The main Problem with the Rendering-API in Wine (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) is more like win3x and far away from DDI (Device Driver Interface).
Do the Eng functions have to be based on DDI? Or can we use it with my DIB engine?
The DIB-Engine on Windows are the main Part behind Eng* and Friends and MS defined DDI as API for that. I had no time yet to look in your DIB-Engine.
Correct but we don't have it in Wine. If we added the Drv functions, while I have the parts of the DIB engine unimplemented, I could forward back to the driver alot easier. There is maybe another way, but having Drv functions make sense in my mind.
That would be perfect (IMHO), when our Drivers (winex11, wineps) use DDI as API. I dont know our Driver-Code in this Area good enough, but I expect that this big change need a lot of testing.
Also, I wonder how your Eng* functions would integrate with the dib engine I'm writing
The main Problem with the Rendering-API in Wine (between GDI and our Drivers: winex11, wineps, mfdrv, enhmfdrv) is more like win3x and far away from DDI (Device Driver Interface).
Do the Eng functions have to be based on DDI? Or can we use it with my DIB engine?
The DIB-Engine on Windows are the main Part behind Eng* and Friends and MS defined DDI as API for that. I had no time yet to look in your DIB-Engine.
Moving to DDI could mean huge changes. The DDI is documented (for a part on msdn) but for the rest I think in driver docs. Transgaming for instance also used the DDI for their DirectX support but at some stage they didn't continue with it because of changes in licensing. So I would watch out with it.
Second if you are interested in this area, I would say skip DDI and start doing things the Vista-way. I'm not sure how DDI works there but in the end everything is layered on top of directx. (of course not the standard ddraw/d3d functions) I would check how Vista is doing things.
Roderick
-
Detlef Riekenberg -
Jesse Allen -
Juan Lang -
Maciej Kowalczyk -
Marcel Partap -
Roderick Colenbrander