July 2006 - Wine-devel - list.winehq.org

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Hans Leidekker 30 Jul '06

30 Jul '06

On Sunday 30 July 2006 09:30, Jeff L wrote: > + Script_string_analysis *pScript_str_analysis; > + void *pAnalysis_ptrstr; Uniscribe is about scripts, so why not leave off these 'Script' prefixes? Furthermore, I think encoding the type in the variable name is redundant, you get that information from reading the declaration. Also, the void pointer variable is not needed, you can cast *pssa straight away. So, what about something like this instead?: string_analysis *analysis; -Hans

1 0

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Vitaliy Margolen 30 Jul '06

30 Jul '06

Saturday, July 29, 2006, 8:34:31 PM, Jeff L wrote: > A resend with after a shortening of the variable names, fixing the > handelling of multiple scripts and a slight rework to remove tests > before HeapFree calls and > meanigful variables. You need to make few more changes: > - lstrcpyW(lf.lfFaceName, (WCHAR *) "Courier"); > + lstrcpyW(lf.lfFaceName, (WCHAR *) L"Courier"); This is not portable and should be something like: const WCHAR courierW[] = {'C','o','u','r','i','e','r',0}; lstrcpyW(lf.lfFaceName, courierW); > - WCHAR teststr[6] = {'T', 'e', 's', 't', 'a', '\0'}; > + WCHAR teststr[6] = {'T', 'e', 's', 't', 'b', '\0'}; Drop the lenght: WCHAR teststr[] = {'T', 'e', 's', 't', 'b', '\0'}; > + hr = ScriptStringAnalyse( NULL, (void*)pString, cString, cGlyphs, iCharset, dwFlags, I don't think you need to cast a pointer into (void *) they all already are. > -/* Commented code it pending new code in ScriptStringAnalysis */ > -/* ok(hr == S_OK, "ScriptStringAnalyse Stub should return S_OK not %08x\n", (unsigned int) hr);*/ > -/* ok(pssa != NULL, "ScriptStringAnalyse pssa should not be NULL\n");*/ Does it crash that you commented it? If it doesn't crash but just doesn't work do this instead: todo_wine { ok(failing_test); ok(failing_test); } > + ok(hr == S_OK, "ScriptStringAnalyse Stub should return S_OK not %08x\n", (unsigned int) hr); That's not correct. Don't cast hr, use proper format instead: ok(hr == S_OK, "ScriptStringAnalyse Stub should return S_OK not %08lx\n", hr); > +typedef struct script_string_analysis_ptrs > +{ > + int cGlyphs; > + SCRIPT_VISATTR *psva; Please use the same format as the rest of the file / recommended Wine format - in this case 4 space indent. > + if (1 > cString || NULL == pString) { > + TRACE("cString %d, pString(%p)\n", cString, pString); > + return E_INVALIDARG; > + } Can you use something that every other person would understand? if (cString < 1 || !pString) { Please use WARN if you want to indicate app's errors: WARN("cString %d, pString(%p)\n", cString, pString); But in particular case, I don't see a need for this. You already have all dumping TRACE right at the beginning of the function. It will log any errors as well. Vitaliy Margolen

2 1

Re: [AppDB] Avoid sending a bad bug link e-mail
by Chris Morgan 30 Jul '06

30 Jul '06

This doesn't look right, we aren't setting any $sMsg or $sSubject in this case. Chris On Saturday 29 July 2006 8:09 pm, Alexander Nicolaysen Sørnes wrote: > If a user deletes a bug link he has submitted, don't send him an e-mail > telling him it has been rejected. > > > Regards, > > Alexander N. Sørnes

1 0

Audio stuttering issue
by Chris 29 Jul '06

29 Jul '06

I know there's been discussions on this before, and the only concensus reached was "use kernel 2.6.17", which apparently helps with processes that wait on pipes. There was this patch (which I tested and did have a very noticeable positive effect): http://wiki.winehq.org/Implement_SetThreadPriority that uses sched_setscheduler to change the scheduling policy and priority of the thread, but was rejected because it always ran privileged and allowed apps to deadlock the system if it ran a real-time thread without yielding. However, when looking at my man pages, I found this: Since Linux 2.6.12, the RLIMIT_RTPRIO resource limit defines a ceiling on an unprivileged process's priority for the SCHED_RR and SCHED_FIFO policies. If an unprivileged process has a non-zero RLIMIT_RTPRIO soft limit, then it can change its scheduling policy and priority, subject to the restriction that the priority cannot be set to a value higher than the RLIMIT_RTPRIO soft limit. If the RLIMIT_RTPRIO soft limit is 0, then the only permitted change is to lower the priority. Subject to the same rules, another unprivileged process can also make these changes, as long as the effective user ID of the process making the change matches the real or effective user ID of the target process. See getrlimit(2) for further information on RLIMIT_RTPRIO. Privileged (CAP_SYS_NICE) processes ignore this limit; as with older older kernels, they can make arbitrary changes to scheduling policy and priority. Meaning, if a user has their system set so that a user (or specific user(s)) have a non-zero RLIMIT_RTPRIO rlimit, normal unprivileged apps can change their scheduling policy and increase their priority up to that value; exactly what that patch does, but without needing special privileges. What would you think about implementing that patch so that it runs unprivileged, but allows the user to set their system so Wine can set time-critical thread scheduling? In this way, it would be completely up to the user if they wanted to run an app that can set real-time scheduling for cleaner audio, or not and have potential stuttering. Or if you still don't want something like that merged in, I'd like to alert the author of that patch that it doesn't require root privs to work. It just needs a non-0 value for RLIMIT_RTPRIO (ulimit -r).

2 4

Re: Win64 patch 2/2 (winedbg)
by Alexandre Julliard 29 Jul '06

29 Jul '06

Ge van Geldorp <ge(a)gse.nl> writes: > case AddrModeFlat: > - dbg_printf("0x%08lx", addr->Offset); > + dbg_printf("0x%08llx", addr->Offset); %ll formats are not portable, please avoid them. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: usp10: Implement digit substitution functions and add stubs
by Hans Leidekker 29 Jul '06

29 Jul '06

On Saturday 29 July 2006 12:33, Albert Lee wrote: > This adds implementations for ScriptRecordDigitSubstitution and > ScriptApplyDigitSubstitution that should be correct. Thanks for your patch Albert. I noticed that the changes to the spec file are missing. It would also be nice if you could integrate your test in Wine's testing framework and send that as a separate patch. Ask me if you need help doing so. -Hans

1 0

Idear for OpenGL overdraw child windows Bug
by Florian Köberle 29 Jul '06

29 Jul '06

When OpenGL draws, child windows get overdrawn. The suggestions to solve these problem where all based on the idear of clipping that what OpenGL render so that OpenGL doesn't overdraw them. What do you think of the idear of letting OpenGL overdrawing the child windows, but then after this we redraw all the child windows? There are two things who have to be done: 1.) find out when OpenGL finished his drawing 2.) find a way to draw the child windows. possible solutions for 2.) The easiest (but slowest) way of doing this could be a broadcast of the window message WM_PAINT to all child windows. A fast version could save the drawn child windows in a buffer with a additional 1 bit alpha channel. The alpha channel remember where the child windows are. This is done only when the child windows change. Every time OpenGL finished his drawing, the buffer content is drawn over the OpenGL output. idears for 1.) When doublebuffering is used (which is usually the case), every drawing is finished with a swapbuffer call wich takes as argument a DC. A test if the pixelformat of the DC is supporting OpenGL may avoid side effects. Have a look at the attached source code of a OpenGL program with a grey child window in the top middle(not visible in wine because of the bug). There you can see a how a pixelformat with OpenGL support is choosen for the DC. Old OpenGL programs without doublebuffer support call glFlush to make sure that all drawings are done and not unfinished. So we simply have to change glFlush that it redraw the child windows when no doublebuffering is used. What do you think about that idear? Bug Report about that topic: http://bugs.winehq.org/show_bug.cgi?id=2398

2 2

Re: wine-ShowCursor-D3D-over-GDI.patch
by H. Verbeet 29 Jul '06

29 Jul '06

On 29/07/06, Andrew Riedi <andrewriedi(a)gmail.com> wrote: > Well, here is my first patch, feel free to tell me what all is wrong with > it. I noticed a problem in WoW d3d, so I tracked it down and checked out > msdn. It seems that implementing ShowCursor() over GDI is acceptable, at > least according to msdn, and it seems to work great. Anyhow, this patch > fixes the two mouse cursor problem in WoW, and makes wined3d more compatible > with windows, at least msdn. Here goes nothing. > > -- > Andrew Riedi That's not quite what MSDN says. It says that the Direct3D cursor can be implemented either by using user32 cursors to draw the cursor, or by doing the drawing itself. We currently do the latter, so I don't think we should touch the user32 cursor in IWineD3DDeviceImpl_ShowCursor(). Also see MSDN on IDirect3DDevice9::SetCursorProperties(). You'll probably want to check if the application calls SetCursor(NULL) anywhere, I don't think that works properly at the moment in wine, if no cursor has been explicitly set before. (It checks if the cursor has changed in SetCursor(), but initially thread_info->cursor seems to be NULL, rather than the default cursor.) Note that you'll have to add your own TRACEs to do that though, as the TRACE in SetCursor() won't catch it. Also, please try to use the same style for patches as the rest of the file. ie, spaces rather than tabs, braces, etc.

1 0

winspool: use printmonitors to manage the Ports
by Detlef Riekenberg 28 Jul '06

28 Jul '06

Hi. Printing in wine use gdi32.dll, gdi.exe, winspool.drv and wineps.drv as Printer-Driver with CUPS/LPR as backend. Many things are not correct (See: http://wiki.winehq.org/Printing ). After some Patches, Wine is able to manage Printmonitors. With the current work, a framework is added and wine start to use the Printmonitors to manage the Printerports. (Patch for wine-0.9.18, should also work for current HEAD) I used various monitors for testing: 1: redmonnt.dll from RedMon 1.7 2: pdfcmnnt.dll from PDFCreator 0.9.2 3: localspl.dll from w2ksp4 4: a partial portmonitor for local Ports, added to winspool.drv You can use a native printui.dll and play with the "Ports"-Page wine rundll32.exe printui.dll,PrintUIEntry /s Some notes about the Patch. - FAR is used in "ddk/winsplp.h", but this does not work with wine. I removed that Keyword, but it is still present in the w2k3ddk An alternative would be "#define FAR" and "#undef FAR" around '#include "ddk/winsplp.h"' in "dlls/winspool.drv/info.c". Another Idea? - The Spooler-Configuration was still using the Path from the old config - File. (Software\Wine\Wine\Config\Spooler\<Portname>) Do we still need this? (A clean way is a seperate Portmonitor) - native localspl.dll need a vailid Section [Ports] in "win.ini" to load. (I used "FILE:=" and "LPT1:=" as entries) - Only Portmonitors, that use "InitializePrintMonitor" are supported. "InitializePrintMonitorUI" requires a "InitializePrintMonitor2" to be implemented, but this is a later step. - AddPort/ConfigurePort/DeletePort in localspl.dll need support for "InitializePrintMonitor2" and all around XcvData. - AddPort/ConfigurePort/DeletePort in the internal Portmonitor is not complete. (As Example, I simple reuse the "Save to File" - Dialog) - The codebase for winspool.drv is really large (>240k) and I want to split the source. The correct way is creating "localspl.dll" for the local Portmonitor (as w2k and above) and another dll for the CUPS/LPR - Handling (and maybe Software\Wine\Wine\Config\Spooler\<Portname>). A different fast hack is simple a new sourcefile for "winspool.drv" for a CUPS/LPR-Monitor and a local Portmonitor. - the internal Portmonitor uses the Registry, where the Ports - Section from "win.ini" is redirected by "IniFileMapping" on windows. - The Ports for the used CUPS/LPR - Printers is a later issue, when wine starts to use the managed Ports. Please try this Patch and point your Ideas and Hints here, so I can split the code into a set of Patches that can go clean into the Tree. Thanks to all for your Help -- By By ... ... Detlef

1 0

Re: wined3d: More shader fixes / new instructions
by H. Verbeet 28 Jul '06

28 Jul '06

On 28/07/06, Jason Green <jave27(a)gmail.com> wrote: > - GLSL: Translate oC0-oC3 output registers (multiple render targets) > to gl_FragData[] register. We don't support draw buffers yet, but > this allows shader programs that use those registers to compile (such > as Settlers 2) If you do that, you should use gl_FragData[] for *all* render targets, including the first one. gl_FragColor will write to all render targets.

2 1