January 2005 - Wine-devel - list.winehq.org

Re: USER32: result of ScrollBar functions review (4th try)
by Alexandre Julliard 09 Jan '05

09 Jan '05

Vitaly Lipatov <lav(a)etersoft.ru> writes: > @@ -1728,12 +1821,15 @@ > SCROLLINFO info; > > TRACE("hwnd=%p nBar=%d min=%d max=%d, bRedraw=%d\n", hwnd, nBar, minVal, maxVal, bRedraw); > - > + > info.cbSize = sizeof(info); > info.fMask = SIF_RANGE; > info.nMin = minVal; > info.nMax = maxVal; > SetScrollInfo( hwnd, nBar, &info, bRedraw ); > + if (nBar == SB_CTL) > + FIXME("needs to send SMB_SETRANGE when SB_CTL\n"); > + //return SendMessageW(hwnd, SBM_SETRANGE, (WPARAM)0, (LPARAM)0); > return TRUE; There's no reason to add a FIXME, calling SetScrollInfo is perfectly fine and it's what Windows does too, we even have a test for it. Also please send separate changes as separate patches, especially when you are renaming functions which causes a lot of changes all over and makes it hard to see what else is changing. -- Alexandre Julliard julliard(a)winehq.org

2 2

Wine(server) priority inversion on CK kernel mailing list
by Andreas Mohr 09 Jan '05

09 Jan '05

Hi, I'm following CK kernel development, and the mailing list had the following posting: ---------- Message: 19 Date: Fri, 07 Jan 2005 23:16:14 +1100 From: Con Kolivas <kernel(a)kolivas.org> Subject: Re: [ck] wine is bloody slow with 2.6.10-ck2 To: Michal ?erav?k <michalz(a)olomouc.com> Cc: CK Kernel <ck(a)vds.kolivas.org> Message-ID: <41DE7D8E.8090102(a)kolivas.org> Content-Type: text/plain; charset="iso-8859-2" Michal ?erav?k wrote: > Hi, > > I have been running photoshop under wine > with 2.6.8.1-ck9 and 2.6.9 and it was good. > Is there any workaround for 2.6.10-ckx and wine > to get normal speed? > It's the same with prelink and without. Nice your wineserver +19. If that's not enough, just run wine at +19. Wineserver gets into a silly priority inversion scenario with the main wine threads. Cheers, Con ---------- Note that Con indicated several times that Wine is a very "special" piece of software, it has wildly differing gaming behaviour (threading behaviour) than native Linux games. For those of you who don't know what priority inversion is (I'll try to explain it, but I'm sure my explanation sucks ;): one (high priority) thread is waiting on a lock, and in order to keep this high priority, another thread owning that lock gets more CPU to get that lock released. Problem is that that thread should have a lower priority, but since the high priority thread always has to wait on the lock, the low priority thread effectively has a much higher priority. These could just be the usual known slow wineserver communication effects at work here, but I wanted to make sure you know about these issues on the CK list. Andreas Mohr

3 3

Re: [winegcc] Include .so files when calling winebuild
by Alexandre Julliard 09 Jan '05

09 Jan '05

Peter Berg Larsen <pebl(a)math.ku.dk> writes: > Changelog: > Currently when compiling a program, winegcc calls winebuild > to solve .def references. But winegcc drops .so files, > so any new .def symbols in a .so causes a unresolved symbol at > link time. This patch adds .so files to the files to winebuild. I'm not sure I follow you, if your .so files have been built correctly they shouldn't contain undefined references to Windows APIs. Could you please show an example of the situation that causes a problem? -- Alexandre Julliard julliard(a)winehq.org

2 1

another build problem on current cvs
by Joris Huizer 09 Jan '05

09 Jan '05

Hello, For the past week or so, building from cvs on a debian/stable system w/ alsa installed (using a custom kernel Linux debian 2.4.18.041216) breaks on alsa-specific code in wine; I attached the log; note that I did a `cvs update -dPA` and `make distclean` so this can't be any problem with the source I have Any ideas? Maybe you can point me to a place where I can read how to fix this properly (I never worked on alsa-specific code before...) or something like that regards, Joris

4 7

Directx 9
by Ann and Jason Edmeades 08 Jan '05

08 Jan '05

Hiya, FYI I've spent the last couple of months putting together a directx 8 level support into wined3d and calling it from d3d9 such that I can also change d3d8 easily to use the new code. This is mostly complete other than the texture support and the shader support plus moving some functions / stubs into the common code. If you have any directx 8/9 questions feel free to email me directly, put questions on wine-devel or perhaps even the wined3d (very, very quiet - http://www.bbrox.org/mailman/listinfo/wine-d3d) mailing list (Lionel's). You really are welcome, and I'll try to answer any questions I can. I wouldn't spent too much time trying to move existing functionality between d3d8 to wined3d unless you really want to as I am trying to get this move completed asap. I really don't want to discourage any d3d assistance, its just I know where I am and what I have left to do. I have generally been doing a patch and getting it committed both due to lack to time, but also to avoid potential rework of multiple patches. I really hope to get most of the non-shader support done quite quickly once the 20 patch goes in (Christmas and FarCry got in the way, and I had some teething problems with the render target support which delayed it!). Next will be the texture support and that should be quick as it is relatively trivial to move across. >As soon as I'm happy with how wine's and directX work >I can stop duplicating what you've done and start >moving onto a more co-operative development... Sounds good - one thing wine has suffered from is a lack of people doing the directx support! Note that Raphael (copied on this note) has some outstanding patches he has put off while I do the move to support hardware vertex buffers so the drawstridedslow case is driven less frequently, but that's the only outstanding work I know about. > or moving DirectX8 over to using WineD3d. I have a version locally where I have changed d3d8 up to about patch 13. I can send it to you if it helps - Unfortunately I think the swap to wined3d will have to be one big patch, I don't think there is a way to move d3d8 over slowly, as you have to move the state block code in one go, the resource8 subclasses in one go etc... >I've merged all the creation surface code into a >single createSurface function that is called with >different parameters/flags to create a backbuffer, >PlainOffscreenSurface or rendertarget etc... Sounds fine - The problem I had with the latest patch was purely being able to add the support for getfrontbuffer etc which needed to return d3d8 or d3d9 objects, but the initial crates being done in the wined3d layer. A single callback sounds useful, as I know I'll have to do something similar for stencildepth surfaces (nothing else is created purely from the wined3d layer, so I don't think others need the same). FWIW I do the same, ie find demos on the web with source code, and then try to get them working. That's how most of the d3d8 support came about as it's a lot easier making a demo work than finding why there's a small amount of corruption for a particular game. I wouldn't claim to be a directx nor opengl expert - its all been a learning experience as I go! Maybe we should collect some useful test program links! If there's any d3d8/9 programmers out there, there's definitely a fun project to do to produce test programs for wine. They cant be automated (I think!) but it would be useful to be able to visually see the effect differences of all the render states, the texture states, prove the shader support works in both hw and sw vertex and pixel code etc etc. Jason

1 0

Re: [LostWages] Resurrection of the AddRef and Release code cleanup.
by James Hawkins 08 Jan '05

08 Jan '05

On Sat, 08 Jan 2005 16:00:38 +0100, Paul Vriens <Paul.Vriens(a)xs4all.nl> wrote: > Hi, > > this Project was apparently not finished. > > Changelog: > make the AddRef and Release code cleanup active again. > > Cheers, > > Paul Vriens > It would be nice to add back in the two other workers (me and Joris). -- James Hawkins

1 0

Re: [dx9-20] RenderTarget support
by Oliver Stieber 08 Jan '05

08 Jan '05

--- Ann and Jason Edmeades <us(a)the-edmeades.demon.co.uk> wrote: > This clears out the next blocking part of the d3d9 / > wined3d support and has > been a real pain to implement. I think I've got it > right now, and it adds > support for render targets but more importantly the > beginnings of a front > and back buffer which lots of the code relied upon. > > Unfortunately I couldn't get this next step any > smaller than the patch > attached.... > > Major areas still to go - textures and pixel / > vertex shader support. I'm > moving onto the textures next... > > Changelog > > Add render target support, and ensure there is a > front and back buffer > created during device creation > > Jason > > Hi, I've just done more-or-less exactly the same this weekend with a couple of differences. I've merged all the creation surface code into a single createSurface function that is called with different parameters/flags to create a backbuffer, PlainOffscreenSurface or rendertarget etc... This should mean that you only require one call-back function for CreateDevice in WineD3D. I'll merge your patch with what I've got and see how it goes. As soon as I'm happy with how wine's and directX work I can stop duplicating what you've done and start moving onto a more co-operative development, or moving DirectX8 over to using WineD3d. So far I can run Pirates! and a few of the demos from http://www.codesampler.com/dx9src.htm, but without textures. Pirates uses DirectX 9c but doesn't do anything too fancy and runs without crashing so it seems good for testing. Many of the demos at http://www.codesampler.com/dx9src.htm have OpenGL versions and since I don't know OpenGL or DirectX (but can hack a good Dos demo) it seemed a good place to start. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

directX 9.
by Oliver Stieber 08 Jan '05

08 Jan '05

Hi, I've been having a look at DirectX 9 over the weekend as a bit of a learning excersize. So far I've managed to get enough implemented in d3d9 to run Pirates! [without textured polygons] and have stated moving everything over to wined3d so that the textures will work. Unfortunatly I've become stuck assigning a DirectX 9 parent to a surface created in wined3d. Can anybody help? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

1 0

Re: Native unix style paths in wine common dialogs
by Dimitrie O. Paun 08 Jan '05

08 Jan '05

On Tue, Jan 04, 2005 at 11:22:00AM -0500, Dan Notestein wrote: > This patch allows winelib to be conditionally compiled with > USE_NATIVE_UNIX_PATHS macro. Enabling this will cause > the common dialogs to display using unix paths instead of drive > letters. This would be much better as a registry setting, not a compile time option. -- Dimi.

3 5

Re: windows/clipboard.c: Get rid of W->A calls
by Dmitry Timoshkov 08 Jan '05

08 Jan '05

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > @@ -310,15 +335,24 @@ static void intern_atoms(void) > names = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*names) ); > atoms = HeapAlloc( GetProcessHeap(), 0, count * sizeof(*atoms) ); > > - for (format = ClipFormats, i = 0; format; format = format->NextFormat) > - if (!format->drvData) names[i++] = format->Name; > + for (format = ClipFormats, i = 0; format; format = format->NextFormat) { > + if (!format->drvData) { > + len = WideCharToMultiByte(CP_ACP, 0, format->Name, -1, NULL, -1, 0, 0); > + names[i] = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); > + WideCharToMultiByte(CP_ACP, 0, format->Name, -1, names[i++], len, 0, 0); You have to use CP_UNIXCP to convert unicode strings in order to pass them to the X11/unix system (here and everywhere else). -- Dmitry.

1 0