March 2008 - Wine-Devel - list.winehq.org

wine based win32 printer drivers

by Detlef Riekenberg

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

March 30, 2008

Direct3D shader compiler infrastructure

by Stefan Dösinger

Hello, So, I am getting serious about a shader compiler and related things now, and I've made a design proposal. First of all, let us collect a few things we want regarding shader handling: -> D3DXCompileShader & Friends -> D3DXAssembleShader & Friends -> D3DXDisassembleShader & Friends -> A way to deal with d3d9 and d3d10 shader language differences All these items are related in some way, so I am proposing the following design of a shader library: The core part of the library is a wine internal shader language representing D3D assembler shaders. Shaders in this language can be created from D3D Bytecode("SlDisassembleShader"), D3D ASM("SlAssembleShader") and from HLSL("SlCompileShader"). From the intermediate language, D3D bytecode can be generated in various versions(SlGenBytecode), as well as D3D Text asm(SlGenAsm). Unlike regular D3D asm languages, this language does not have a version token, it is a superset of all asm language versions. It does have a pixel / vertex / geometry shader flag though. The motivation behind an intermediate language is to avoid writing many different code generators, which is a big part of the HLSL compiler. We also need a WineD3D intermediate language to share our shader generator between d3d9 and d3d10, and use it for both kinds of shaders. The requirements for both intermediate asm languages are the same. This motivates making the language the same to reuse code. With those functions, the D3DX functions are pretty streightforward: D3DXAssembleShader: bytecode = SlGenBytecode(SlAssembleShader(char *asm_text)); D3DXCompileShader: bytecode = SlGenBytecode(SlCompileShader(char *hlsl_text)); D3DXDisassembleShader asm_text = SlGenAsm(SlDisassembleShader(DWORD *bytecode)); WineD3D can be changed to use this shader language as shader input. In this case, d3d8, d3d9 and d3d10 run their shader bytecode through SlDisassembleShader, and pass the returned pointer to WineD3D. This in turn calls SlCopyShader to make a copy it owns, and d3d8/9/10 free their copy using SlDestroyShader. With WineD3D working on the same language, we have to share the language definition between the shader library and WineD3D, or put the shader compiler into WineD3D as well. I do not like the 2nd way, as it puts things together that don't have to be in one lib, and wastes runtime memory. A 3rd way I have to consider was a SlReadShader() function with callbacks which takes over the current role of shader_generate_main() in WineD3D. I am not quite convinced by this either. Attached are a few files for reference: shaderlib.gif: A diagram explaining the roles of the languages(No, it is not UML 2.0) uses.gif: Illustrating various uses of the shader library shader-lang: A very early pseudocode definition of the language The intermediate asm language follows the same principles as D3D bytecode. A shader contains any number of instructions, each instruction has one destination register and any number of source registers. The instructions have an opcode, writemask, modifiers. A register has a type, an index, information about relative addressing, source modifiers, and a swizzle. Appart of the instructions, the shader contains a header with informations about the shader. Declarations, input/output semantics, special registers used, etc. This replaces the shader_get_registers_used() pass in WineD3D. It is done by the shader library, and it also generates the declarations for 1.x pixel shaders. (We still have to find out which texture type to read from in wined3d). Thanks, Stefan

March 30, 2008

Re: user32: Implement BroadcastSystemMessage, try 5.1

by Maarten Lankhorst

Hello Alexandre, 2008/3/30, Alexandre Julliard <julliard(a)winehq.org>: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > > > > Or wine is doing something wrong. After some more digging I found that > > SetLastError() was set to 0 by TlsGetValue when called from X11DRV's > > MsgWaitForMultipleObjectsEx. After I tried fixing this so that > > SetLastError is only set when NULL is returned, one of the other tests > > miraculously started working inside a todo block too (cursoricon). > > I'll work on some testcases to verify that tlsgetvalue only calls > > SetLastError(0) when succesfully returning null. > > > In most cases it's the test that is doing something wrong by being too > strict. We don't care whether last error is modified or not on success, > and there's no reason to test for it, unless it's one of the very few > functions that do something special on success, or unless there is a > real app that depends on it. Well, EnumWindows encourages applications to use setlasterror to set an error message to pass a return value. Suppose if I took this approach, and then called SendMessageTimeout from my enumeration function, the last error would be useless because it's overwritten. Adding a few lines to SendMessageTimeout confirms this behavior: Windows doesn't overwrite the last error by default. I tracked where it does timeout to that tlsgetvalue call in MsgWaitForMultipleObjectsEx, which doesn't currently have last error tests. I assume it doesn't change last error unless it returns null and has success. This would fix SendMessageTimeout to act more like windows and my BroadcastSystemMessage implementation. And regarding 'there is no real life app that depends on it', too often I find obscure problems with applications because wine does something slightly different then windows does... Cheers, Maarten.

March 30, 2008

Re: user32: Implement BroadcastSystemMessage, try 5.1

by Vitaliy Margolen

Alexandre Julliard wrote: > "Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > >> Or wine is doing something wrong. After some more digging I found that >> SetLastError() was set to 0 by TlsGetValue when called from X11DRV's >> MsgWaitForMultipleObjectsEx. After I tried fixing this so that >> SetLastError is only set when NULL is returned, one of the other tests >> miraculously started working inside a todo block too (cursoricon). >> I'll work on some testcases to verify that tlsgetvalue only calls >> SetLastError(0) when succesfully returning null. > > In most cases it's the test that is doing something wrong by being too > strict. We don't care whether last error is modified or not on success, > and there's no reason to test for it, unless it's one of the very few > functions that do something special on success, or unless there is a > real app that depends on it. > I remember sending the patch for this exact thing a while back, which you of course refused under the same pretense - showing a real life app that depends on it. So if tests are not a real life app that shows a difference between Wine and windows - then why do we bother with Wine at all? At least should change the moto to "might run some apps with loads of problems and never be 100% compatible". One for sure will find an app that in one way or another depends on undocumented windows behavior. So if a test can be written to show a difference between Wine and windows. Then this difference should be fixed in Wine. Vitaliy.

March 30, 2008

Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)

by Detlef Riekenberg

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

March 30, 2008

Re: Wine 1.0 status: T minus 68 days. 73 open bugs.

by Vitaliy Margolen

Reece Dunn wrote: > On 30/03/2008, Michael Stefaniuc <mstefani(a)redhat.com> wrote: >> Dan Kegel wrote: >> > 40 days to code freeze. >> > >>> 12097 -unknown 2 Wine 1.0 should not ship out-of-sync resource translations >> This bug can be closed only after Wine 1.0 ships. There are a lot of >> changes/cleanups at the moment that constantly break the translations. > > There should also be a resource freeze, during which only translators > can modify the resources (i.e. no En.rc changes) to give them a chance > to translate them. > > Should this be done before the code freeze, or is the time during code > freeze enough for the translations? > Code freeze should be enough. IMHO 1 week to sync translations will be enough. So imposing an extra freeze is totally unnecessary. Vitaliy.

March 30, 2008

Re: Proposal: versioning .wine directory

by Dan Kegel

On Sun, Mar 30, 2008 at 3:08 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > > Can I bring the discussion back to my proposal, > > which was to have wine-1.0 notice old, unsupported .wine > > directories, and do something sensible? > > If we're going to force users to remake ~/.wine, it would be ideal if we > only did that once. Then we could provide some sort of upgrade path if > wineprefix changed again for some reason. Agreed. > I'm wondering if the case-insensitive FUSE project could be finished in > time - this would allow us to both get a stable wineprefix and a > case-insensitive .wine folder. This would save us the hassle of having > to worry about converting case-sensitive but proper-prefixed .wine folders. Not likely. I don't even think it's a very good idea. - Dan

March 30, 2008

Re: Proposal: versioning .wine directory

by Scott Ritchie

Dan Kegel wrote: > On Sun, Mar 30, 2008 at 2:17 PM, James Hawkins <truiken(a)gmail.com> wrote: >> If we have a stable wine prefix in 1.0, I don't see what could >> possibly be added in 1.2 that would break that. The idea is that, >> even if you add a new dll that needs to be registered in, say, 1.0.5, >> you still don't need to remove your wine prefix or reinstall any apps. > > Can I bring the discussion back to my proposal, > which was to have wine-1.0 notice old, unsupported .wine > directories, and do something sensible? > > If we're going to force users to remake ~/.wine, it would be ideal if we only did that once. Then we could provide some sort of upgrade path if wineprefix changed again for some reason. I'm wondering if the case-insensitive FUSE project could be finished in time - this would allow us to both get a stable wineprefix and a case-insensitive .wine folder. This would save us the hassle of having to worry about converting case-sensitive but proper-prefixed .wine folders. Thanks, Scott Ritchie

March 30, 2008

Re: bugfix #12296

by Stefan Dösinger

Am Sonntag, 30. März 2008 20:33:22 schrieb Gregor Münch: > As discussed with stefand on irc: > | feel free to send a patch adding that, it is needed > - * Copyright 2006-2007 Stefan Dösinger for CodeWeavers > + * Copyright 2006-2007 Stefan Dï¿½singer for CodeWeavers Watch out with the encoding... I think the general consent is to leave that character as it is until we have decided on a preferred Wine source file encoding. The background story is that we throw away the sysmem copy of the surface, so we have to remove SFLAG_INSYSMEM. This might drop the last remaining location. Since we do not backup any contents of primaries and depth stencil, we can label the DRAWABLE as most up to date, this prevents needless loading attempts on the next draw. So the patch is correct and should be applied, appart of the change to my name...

March 30, 2008

Re: Proposal: versioning .wine directory

by Dan Kegel

On Sun, Mar 30, 2008 at 2:17 PM, James Hawkins <truiken(a)gmail.com> wrote: > If we have a stable wine prefix in 1.0, I don't see what could > possibly be added in 1.2 that would break that. The idea is that, > even if you add a new dll that needs to be registered in, say, 1.0.5, > you still don't need to remove your wine prefix or reinstall any apps. Can I bring the discussion back to my proposal, which was to have wine-1.0 notice old, unsupported .wine directories, and do something sensible?

March 30, 2008