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

Mandrake packages
by Mike Hearn 04 Jan '05

04 Jan '05

Hi, The downloads page advertises support for 10.1, 10.0 and 9.2 Mandrake packages but it seems only 10.1 RPMs are provided. Should the download page be updated to say only 10.1 is available? I'd rather actually it was built on an older Mandrake and then fixed to work on later versions too if that was necessary, as I suspect the only real difference is glibc symvers. thanks -mike

2 1

Re: Change some d3d9 RACE( "stub ") into FIXME ("stub")
by Lionel Ulmer 04 Jan '05

04 Jan '05

On Tue, Jan 04, 2005 at 05:21:41PM +0000, Mike Hearn wrote: > One thing to be aware of when doing this is that some of these calls may > be used very frequently, and the cost of outputting a fixme for each one > is high. Because TRACEs are not output by default making a stub a TRACE is > often used in this situation. Not to mention the users who will generate bug reports saying 'look it does not work because of this FIXME' whereas this FIXME is just for an obscure function which does not do anything important and can be let as a stub for ages. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Re: Native unix style paths in wine common dialogs
by Mike Hearn 04 Jan '05

04 Jan '05

On Tue, 04 Jan 2005 11:22:00 -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. Fantastic! What would rule even more is if this was not a conditional compilation flag, but something that could be toggled at runtime. That way you can have a single Wine installation that has both half-native winelib apps and regular win32 binaries run at once. As it is, this patch is only really useful for when you are distributing your own app-specific copy of Wine, no? > Btw, if anyone is interested we also have another module which > can be used to convert the windows-style drive letters returned > by the common dialogs into unix-style paths (if you want to use > these paths will "normal" file i/o functions such as C++ stream i/o). Isn't that what wine_get_unix_file_name does? thanks -mike

2 1

Re: keybd_event patch and default combobox height patch
by tony_lambregts＠telusplanet.net 04 Jan '05

04 Jan '05

Peter Hercek wrote: > server/queue.c > Fixes an error in keybd_event function. This function sends events even > between different processes on win32. This was not handled in wine. > > dlls/user/combo.c > The default size for comboxes was 2 pixels bigger in wine at the > standard dpi. > > The patches are against wine 20041019. > > Index: server/queue.c > =================================================================== > --- server/queue.c (revision 29655) > +++ server/queue.c (working copy) > @@ -1073,6 +1073,8 @@ > *msg_code = msg->msg; > if (is_keyboard_msg( msg )) > { > + if (!input || !(input->focus) || !(input->active)) > + input = foreground_input; > if (input && !(win = input->focus)) > { > win = input->active; > Index: dlls/user/combo.c > =================================================================== > --- dlls/user/combo.c (revision 29655) > +++ dlls/user/combo.c (working copy) > @@ -207,8 +207,10 @@ > * The height of the text area is set in two ways. > * It can be set explicitly through a combobox message or through a > * WM_MEASUREITEM callback. > - * If this is not the case, the height is set to 13 dialog units. > - * This height was determined through experimentation. > + * If this is not the case, the height is set to 12 dialog units. > + * This height was determined through experimentation. It was > + * set to 13 originally but this led to higher comboboxes than > + * in windows. > */ > static INT CBGetTextAreaHeight( > HWND hwnd, > @@ -239,7 +241,7 @@ > > ReleaseDC(hwnd, hDC); > > - iTextItemHeight = ((13 * baseUnitY) / 8); > + iTextItemHeight = ((12 * baseUnitY) / 8); > > /* > * This "formula" calculates the height of the complete control. > > These should have been sent as two separate patches. since they address two different issues. -- Tony Lambregts

1 0

Changed files to use interlocked functions
by Paul Vriens 04 Jan '05

04 Jan '05

Hi, the Janitorial page shows that the "Use Interlocked functions in AddRef and Release methods" project is finished. There are however several files (at least 135) that still use the non-interlocked method. Especially ddraw, d3*, dm*, avifil32 and some ole/oleaut32. Do they still need to be changed ? Cheers, Paul.

4 5

Re: gdi/tests/metafile.c NT 4 fix
by Dmitry Timoshkov 04 Jan '05

04 Jan '05

"Jakob Eriksson" <jakov(a)vmlinux.org> wrote: > --- dlls/gdi/tests/metafile.c 27 Dec 2004 17:46:36 -0000 1.4 > +++ dlls/gdi/tests/metafile.c 3 Jan 2005 14:27:55 -0000 > @@ -185,8 +185,6 @@ > ret = EnumEnhMetaFile(hdcDisplay, hMetafile, emf_enum_proc, dx, &rc); > ok( ret, "EnumEnhMetaFile error %ld\n", GetLastError()); > > - ok(emr_processed, "EnumEnhMetaFile couldn't find EMR_EXTTEXTOUTA or EMR_EXTTEXTOUTW record\n"); > - This defeats the whole purpose of the test, could you investigate what is going on? -- Dmitry.

2 1

Re: [LOSTWAGES] Add a short blurb about what Wine is on the About page
by Tom 04 Jan '05

04 Jan '05

Mike McCormack wrote: > > Index: templates/en/about.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/about.template,v > retrieving revision 1.15 > diff -u -r1.15 about.template > --- templates/en/about.template 1 Dec 2004 22:15:11 -0000 1.15 > +++ templates/en/about.template 4 Jan 2005 07:32:05 -0000 > @@ -4,6 +4,12 @@ > > <h1>About Wine</h1> > > +<p>Wine is a translation layer (a program loader) capable of running > +Windows applications on Linux and other POSIX compatible operating > +systems. Windows programs running in Wine act as native programs would, > +running without the performance or memory usage penalties of an emulator, > +with a similar look and feel as other your desktop.</p> What about: with a similar look and feel as other applications on your desktop. Tom

1 0

Re: build problem on current cvs [fixed]
by Dan Kegel 04 Jan '05

04 Jan '05

Jack wrote in http://www.winehq.org/hypermail/wine-devel/2004/12/0720.html : >>Program received signal SIGSEGV, Segmentation fault. >>0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >>(gdb) bt >>#0 0x4009e05a in _int_malloc () from /lib/i686/libc.so.6 >>#1 0x4009d06c in malloc () from /lib/i686/libc.so.6 >>#2 0x080525a0 in pp_xmalloc (size=11) at ../../../wine/libs/wpp/preproc.c:80 >>#3 0x0805264a in pp_xstrdup (str=0xbfffec68 "\"11:25:54\"") >> at ../../../wine/libs/wpp/preproc.c:108 >> >> > It is probably caused by overwritting the allocated memory. The last > changes of widl look well so I think it is > some old hidden problem. Lookng at code I found a potential bug, but I'm > not sure if it a bug. In parsers, > both widl's and wpp's, strings are not duplicated whie adding to > structures. If it helps, I'll see if it is correct at all. > This is included in diffs: wppppy.diff and widl.diff. Could you try it? > I also found another small bug in wpp, but > it's not what we're looking for. I included it with some code cleanup in > wpppreproc.diff. I swear I found this same error several months ago, but never submitted a patch (and can't find my old patch now). Your three patches solved the widl crash in current cvs for me. Alexandre, can you review / apply them? Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

Should we get rid of the wine-license list?
by Scott Ritchie 03 Jan '05

03 Jan '05

Looking at the archives it appears that wine-license has had very little traffic, to the point where a lot of it is probably not being read when it comes up, since people like me are not subscribed to that list. It seems like a lot of the stuff being sent there should instead go to wine-devel. Thoughts? Scott Ritchie

7 7

Hyperthreading and SMP
by Kenneth Porter 03 Jan '05

03 Jan '05

Does WINE have any problem with either Hyperthreading or SMP? I've found that locking the Tribes Vengeance dedicated server to a single logical CPU seems to give me better performance as the server fills with players. CPU usage seems significantly lower (45% versus 65%). Is this likely to be a WINE issue or a TV issue? (TV is based on the Unreal Tournament engine, with the Havok physics engine integrated to handle vehicle. Alas, unlike UT2004, there's no native Linux server for TV.) More here: <http://lists.matureasskickers.net/pipermail/tvservers/2004-December/000186.…> I want to try disabling HT or setting affinity on my co-admin's Win2003 server to see if he sees the same boost.

2 4