- Wine-Devel - list.winehq.org

Re: x11drv: Remove some of the mouse lag in games
by Vitaliy Margolen Oct. 24, 2005

Oct. 24, 2005

Don't apply this patch. It doesn't really fix things yet. But the bug is somewhere there. Vitaliy Margolen Sunday, October 23, 2005, 5:42:57 PM, Vitaliy Margolen wrote: > This patch removes mouse lag for me in Half Life 1 in single player mode. > Apparently there are still a lag in multi player mode. > Vitaliy Margolen > changelog: > x11drv/mouse.c > - Use InterlockedExchange instead of x11_lock/unlock for internal pointer ops.

2 1

log_accum: add ability to include patch in notification (take 2)
by Dimi Paun Oct. 24, 2005

Oct. 24, 2005

Sorry, the previous version had the wrong default for do_patch. Which meant that you can't turn the embedded patch off. Mea culpa. This will help me keep all scripts in sync (such as the one from SF). ChangeLog Add ability to include patch in notification. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

1 0

Run ident on all wine source before 0.9?
by Uwe Bonnes Oct. 23, 2005

Oct. 23, 2005

Hello, just a provocing thought: Wouldn't the pending 0.9 release be a good chance to run ident with a consistant formating on all wine source files? At present, there a used a lot of different styles... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Oh, the pain! Script to install a VB app that uses MS SQL
by Dan Kegel Oct. 23, 2005

Oct. 23, 2005

I slogged through writing a shell script that works around all the problems I ran into which installing a VB app that uses MS SQL. Have a look, it's at: http://kegel.com/wine/initvbapp.sh.txt Oh, the pain, the pain! It had to download and install the MDAC runtime download and install the VB runtime download and build cabextract and unshield for the next step, download and manually unpack the ntwdblib.dll driver from MS SQL 7, work around Wine bug http://bugs.winehq.org/show_bug.cgi?id=3636, and work around a bug in the VB packaging wizard http://support.microsoft.com/kb/299645, and *then* run the app's installer. I haven't verified that the app runs once installed; I'm just so happy to have the installer complete with no errors finally. This is probably similar to what winetools does, but I haven't looked at winetools to see how much overlap there is. I certainly prefer a simple shell script like this to a menu-driven opaque program, at least when trying to understand root causes of problems. Hopefully this will help somebody else who's trying to get VB apps to install.

1 0

Re: fix for #3219
by Eric POUECH Oct. 23, 2005

Oct. 23, 2005

why not test for '?' and '.' which are the forms we know off, instead of letting the door ajar ? A+ > Message du 19/10/05 18:27 > De : "Vijay Kiran Kamuju" > A : "Hans Leidekker" , wine-devel(a)winehq.org > Copie à : > Objet : Re: fix for #3219 > > I have kept it there incase of regressions > We can just easily uncomment and test. > > Thanks, > Vijay > > On 10/19/05, Hans Leidekker wrote: > > On Wednesday 19 October 2005 09:19, Vijay Kiran Kamuju wrote: > > > > > - /* MS mangled names always begin with '?' */ > > > - if (*sym->current != '?') return FALSE; > > > + /* MS mangled names always begin with '?' > > > + if (*sym->current != '?') return FALSE; */ > > > > It's better to remove code then disabling it > > this way. We can always refer to CVS history. > > > > -Hans > > > > > > > > > >

2 2

Re: Shell32 File Property dialog
by Detlef Riekenberg Oct. 23, 2005

Oct. 23, 2005

Am Freitag, den 14.10.2005, 13:28 +0200 schrieb Johannes Anderwald: > I have a patch which adds file property dialogs to shell32 Welcome to wine. Your Idea is nice and many Thanks for your Wine-Support, but since wine is different from ReactOS, your Patch will not work here. I started half a year ago with similar Problems. Please read take a look in the "Wine Developer's Guide": http://www.winehq.com/site/docs/wine-devel/index And the Part about "Coding Practice" http://www.winehq.com/site/docs/wine-devel/codingpractice - Define a Unicode-String with L"text" does not work with gcc on unix. Please use the same Style as your Patch did for wProperties in "shlexec.c" (Array of WCHAR). - TCHAR is not used in wine. If there is a UNICODE and a ANSI implementation in Windows, implement the UNICODE-Version and let the ANSI-Version call the UNICODE-Version. - I don't knew, if DPRINT() works in wine. We use here: TRACE(), WARN(), ERR() and FIXME() with WINE_DEFAULT_DEBUG_CHANNEL() This messages go to the console. (There are more Macros for additional Debug-Channels as well) - You use numeric values very often (Dialog-Parameter, Buffer-Length) Are there really no defines for this Numbers? - K.I.S.S => Make your Patch as small as possible. An Idea would be to Start with one Page and add the other Pages later. There are some FIXME in the code (Example: Date/Time - Format). How much work is it to do it "the Windows-Way" ? The following Link is a useful collection of Coding Hints: http://wine-wiki.org/index.php/Coding_Hints (wine-wiki.org (private) started before the official wiki.winehq.org comes up.) Asking Steven Edwards how to Port from ReactOS to wine is IMHO another good idea. -- By By ... ... Detlef

1 0

Re: [LOSTWAGES] Correct comment about QT license
by H. Verbeet Oct. 23, 2005

Oct. 23, 2005

On 10/23/05, Dimi Paun <dimi(a)lattica.com> wrote: > ChangeLog > Correct comment about QT license, Win32 version is now GPLed. > Also, both Qt3 and Qt4 can be compiled with MinGW these days. http://www.trolltech.com/products/qt3/platforms/supported.html http://www.trolltech.com/developer/platforms/supported.html

1 0

Re: enhmfdrv: Return proper values from GDI APIs
by Phil Krylov Oct. 23, 2005

Oct. 23, 2005

Hi, Are there any problems to apply this patch before 0.9? On Mon, 17 Oct 2005 03:43:55 +0400 Phil Krylov <phil(a)newstar.rinet.ru> wrote: > Hi, > > This patch fixes EMF rendering in some programs that depend on the fact > that SetTextAlign(), SetBkMode(), SetROP2(), SetPolyFillMode(), and > SetStretchBltMode() return proper values when called on a EMF device > context. > > > ChangeLog: > > Fixed EMFDRV_SetTextAlign, EMFDRV_SetBkMode, EMFDRV_SetROP2, > EMFDRV_SetPolyFillMode, and EMFDRV_SetStretchBltMode to return proper > old values of modes that are being set. Added FIXMEs for other cases of > improper return values. > > -- Ph. -- Ph.

3 3

preload libGL
by Tomas Carnecky Oct. 23, 2005

Oct. 23, 2005

I need to preload my own library with a custom glXSwapBuffers(). But wine opengl libGL.so directly so there's no way to do it. I've ended up doing this: glXSwapBuffersType preload__glXSwapBuffers = (glXSwapBuffersType) wine_dlsym(RTLD_DEFAULT, "glXSwapBuffers", NULL, 0); preload__glXSwapBuffers(gdi_display, physDev->drawable); but that is not a nice solution. What about linking x11drv directly with libGL? tom

3 11

Caching for X11DRV_SetImageBits?
by Michael Carlson Oct. 23, 2005

Oct. 23, 2005

Let me start off with an introduction. I'm a veteran C programmer, but I'm unfamiliar with programming X11 and unfamiliar with wine, although I've been looking into both recently to correct a problem I'm having with wine. I posted about the same problem in August on the same mailing list, about making function parameters const. This was a simplistic solution, but I suggested it simply because I didn't feel I had the time to familiarize myself with all the inner-workings of wine. Now, I believe I do have the time. To repeat the situation, I found that in several of the games I like to run, the same problem is causing wine to be slow: using oprofile, I find that nearly all of wine's CPU usage lies in x11drv, and 98-99% of the cpu usage in x11drv is taken up by calls to some of the convert functions in dib_convert.c. For example, in Civilization 3, some 98% of the CPU usage in x11drv is taken up by two functions: convert_555_to_565_asis, and convert_565_to_555_asis. This summer I had a similar problem on my laptop, where fce ultra was using the function convert_888_to_0888_asis for most of its cpu. Essentially, it seems that most of the work wine is doing when running these programs is just for converting between one pixel format and back, and I hope to find a good solution to this speed problem, preferably through caching. I'm writing to this list in hope of other more experienced wine hackers giving their advice, telling me what is possible, and what the best solution is, before I go too far on my own with this. I'm looking at a group of related functions in wine, in dlls/x11drv/dib.c. It came to my attention that in X11DRV_SetDIBits and X11DRV_SetDIBitsToDevice, wine always seems to end up calling X11DRV_DIB_SetImageBits, which calls (in my case, probably because my desktop is 16-bit color) X11DRV_DIB_SetImageBits_16, which in every case calls a convert function of one type or another (all of which are CPU hogs). These are the core functions that seem to be related to the problem. Here is my early analysis of the problem: X11DRV_DIB_SetImageBits always creates and destroys an XImage during the life of the function, and calls X11DRV_DIB_SetImageBits_16 (or another bit depth), which ends up converting the bitmap to the proper color format / bit depth. It seems to me the best solution is to use some kind of caching to save the converted bitmap in its cached form, preferably as an XImage. Inside X_PHYSBITMAP the HBITMAP is stored, windows' unique handle for that particular bitmap. So, what if we stored the appropriate converted XImage per-HBITMAP, per-bpp, so that it doesn't need to be created, converted, and destroyed each time, and we could delete all cached XImages corresponding to the HBITMAP from the cache when DeleteObject() is called for that HBITMAP? I'm doing a lot of guesswork on the inner-workings of wine, X, and the windows GDI here. Please tell me, am I on the right track for eliminating these unnecessary conversions? If not, where should I be looking? Again I'm new to wine, X, and somewhat new to GDI programming - but I would like to learn. Please, GDI/X11 experts, give me some advice on the best solution to this problem!

2 1