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

About [ZH2005-02SA] Insecure tmp file creation in Wine
by Giovanni Delvecchio March 24, 2005

March 24, 2005

hello list, i noted that the patch provided ( http://www.winehq.org/hypermail/wine-devel/2005/03/0624.html ) to fix that problem isn't secure yet, because a symlink attack could be possible if /tmp is a mounted NFS file system. Indeed: 1)The name of the file in /tmp is easly predictable , it uses getpid(); 2)O_EXCL when used with O_CREAT, if the file already exists it is an error and the open will fail. O_EXCL is broken on NFS file systems, programs which rely on it for performing locking tasks will contain a race condition. Possible fix using tempnam() function to generate a psued-random string for tmp file name: _______________________________________________________________ --- misc/registry.c Thu Mar 24 13:36:43 2005 +++ misc/registry.c Thu Mar 24 13:46:46 2005 @@ -1222,12 +1222,11 @@ static LPSTR _get_tmp_fn(FILE **f) { LPSTR ret; - int tmp_fd,count; + int tmp_fd; - ret = _xmalloc(50); - for (count = 0;;) { - sprintf(ret,"/tmp/reg%lx%04x.tmp",(long)getpid(),count++); - if ((tmp_fd = open(ret,O_CREAT | O_EXCL | O_WRONLY,0666)) != -1) break; + for (;;) { + ret = tempnam("/tmp", "reg"); + if ((tmp_fd = open(ret,O_CREAT | O_EXCL | O_WRONLY,0600)) != -1) break; if (errno != EEXIST) { ERR("Unexpected error while open() call: %s\n",strerror(errno)); free(ret); _______________________________________________________________ Best regard, Giovanni Delvecchio -- ______________________________________________ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze

1 0

Re: Treeview plus/minus
by Jon Griffiths March 24, 2005

March 24, 2005

Hi George, >If I change the size to 18 the plus is drawn correctly >Does anybody knows anything about this ? The native controls draw a different kind of cross for large items, which looks a lot nicer. I added this but the initial threshold for deciding when to draw the large cross was too small, as reported by Ge Van Geldorp from the ReactOS crew - The thread starts here: http://www.winehq.com/hypermail/wine-devel/2004/10/0445.html The size was changed to 18 which seems to work (as you found yourself). I don't know what size or algorithm MS uses to determine when to switch the drawn style, but noone has reported an issue with this since then. You should maybe consider working with a more up to date Wine version, since that patch was committed over 2 months ago. Hope that helps, Jon "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

1 0

Re: [OLE #84] Don't use IsBadStringPtr on NULL pointers
by Alexandre Julliard March 24, 2005

March 24, 2005

Mike Hearn <mike(a)navi.cx> writes: > Don't use IsBadStringPtr on NULL pointers If the goal is to avoid exceptions, then it would be better to do that check directly in the IsBad* functions. -- Alexandre Julliard julliard(a)winehq.org

1 0

Treeview plus/minus
by George Ginden March 24, 2005

March 24, 2005

Talking about the plus / minus symbols in the treeview control... Why with a size of 16 the plus symbol looks more like a small circle than a cross ? If I change the size to 18 the plus is drawn correctly Does anybody knows anything about this ? Regards. @@ -2329,7 +2330,7 @@ SelectObject(hdc, hOldPen); DeleteObject(hNewPen); - if (height < 16 || width < 16) + if (height < 18 || width < 18) {

1 0

[RFC] Pager: why do we implement WM_NCPAINT instead of WM_PAINT?
by Dimitrie O. Paun March 24, 2005

March 24, 2005

Hi folks, Does anyone know why the Pager common control (dlls/comctl32/pager.c) implements WM_NCPAINT instead of WM_PAINT? It is the only exception to the rule, all other controls implement WM_PAINT. -- Dimi.

2 1

World of Warcraft
by cyrix12＠cox.net March 24, 2005

March 24, 2005

Sorry to keep bugging you guys about this, but a recent patch broke the opengl mode of World of Warcraft again. It simply fails to start, similar to the d3d mode (except for the fact that I know why d3d mode doesn't work as of now). I was scanning through the traces and saw no errors though. Seemed odd to me, but I'm not a wine programmer so I'm not exactly sure what to look for anyway. If anyone wants me to send a any sort of debug log (if, for instance, you don't have copy of WoW to test on), let me know (include what you'd want to see as well, if you don't mind). Thanks in advance, Darckness

3 7

Segfault in X11DRV_DIB_BuildColorTable (DIB_PAL_COLORS)
by Jesse D Zbikowski March 23, 2005

March 23, 2005

I am experiencing a crash during startup of an application (The Rosetta Stone 2.0.7a) under Wine. I reported this earlier on wine-users and after some debugging was advised to move to this list. The line causing a problem is dlls/x11drv/dib.c:425 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); 418 PALETTEENTRY pal_ents[256]; 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); 420 421 GetPaletteEntries(hpal, 0, 256, pal_ents); 422 423 for(i = 0; i < colors; i++, index++) 424 { =>425 colorTable[i].rgbRed = pal_ents[*index].peRed; 426 colorTable[i].rgbGreen = pal_ents[*index].peGreen; 427 colorTable[i].rgbBlue = pal_ents[*index].peBlue; 428 colorTable[i].rgbReserved = 0; 429 } This happens when X11DRV_DIB_BuildColorTable() is called with coloruse==DIB_PAL_COLORS, meaning we use an 8-bit palette. It seems to me that (LPBYTE)info must be corrupt and is giving a corrupt value to (WORD)index. Wine-dbg>p i 0 Wine-dbg>p colorTable[i] {rgbBlue=0, rgbGreen=0, rgbRed=0, rgbReserved=0} Wine-dbg>p pal_ents {{peRed=0, peGreen=0, peBlue=0, peFlags=0}, ... } Wine-dbg>p pal_ents[0] {peRed=, peGreen= Exception c0000005 Wine-dbg>p index 0x77aaec20 Wine-dbg>p *index No type or type mismatch Wine-dbg>p info fixme:winedbg:print_value ---error Here is the backtrace. fixme:font:GetKerningPairsW (0x1a28,0,(nil)): almost empty stub! First chance exception: page fault on read access to 0x77ab71cc in 32-bit code (0x7fea1e53). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7fea1e53 ESP:77aae66c EBP:77aaea98 EFLAGS:00010287( - 00 RISP1C) EAX:000022d0 EBX:7fef22c4 ECX:7786aee0 EDX:00000000 ESI:7e042900 EDI:77aaec20 Stack dump: 0x77aae66c: 00000044 00000000 00000100 77aae68c 0x77aae67c: 00000400 00000000 00000100 00000001 0x77aae68c: 00000000 00000080 00008000 00008080 0x77aae69c: 00800000 00800080 00808000 00c0c0c0 0x77aae6ac: 00c0dcc0 00f0caa6 00f0fbff 00a4a0a0 0x77aae6bc: 00808080 000000ff 0000ff00 0000ffff Backtrace: =>1 0x7fea1e53 X11DRV_DIB_BuildColorTable+0x173(physDev=0x7e042408, coloruse=0x1, depth=0x8, info=0x77aaebf8) [/home/jesse/wine/dlls/x11drv/dib.c:425] in x11drv (0x77aaea98) 2 0x7feaa20b X11DRV_DIB_CreateDIBSection+0x22b(physDev=0x7e042408, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0, ovr_pitch=0x0) [/home/jesse/wine/dlls/x11drv/dib.c:4749] in x11drv (0x77aaeb5c) 3 0x77824ab3 DIB_CreateDIBSection+0xa3(hdc=0x5b5c, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0, ovr_pitch=0x0) [/home/jesse/wine/dlls/gdi/dib.c:1107] in gdi32 (0x77aaeb90) 4 0x77824b28 CreateDIBSection+0x48(hdc=0x5b5c, bmi=0x77aaebf8, usage=0x1, bits=0x7d7703ec, section=0x0, offset=0x0) [/home/jesse/wine/dlls/gdi/dib.c:1125] in gdi32 (0x77aaebb8) 5 0x690323bb 1680 in iml32 (0x7b1c7b8c) 6 0x00000264 (0x00000010) 7 0x00000000 (0x00000000) 0x7fea1e53 X11DRV_DIB_BuildColorTable+0x173 [/home/jesse/wine/dlls/x11drv/dib.c:425] in x11drv: movzbl 0xfffffbf4(%ebp,%eax,4),%eax 425 colorTable[i].rgbRed = pal_ents[*index].peRed; I can add a breakpoint before we get here and try to step through, although the flow seems to skip around a bit. Wine-dbg>b X11DRV_DIB_BuildColorTable Breakpoint 1 at 0x7fea1d04 X11DRV_DIB_BuildColorTable+0x24 [/home/jesse/wine/dlls/x11drv/dib.c:377] in x11drv Wine-dbg>cond 1 (coloruse == 1) 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); Wine-dbg>n 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); Wine-dbg>n 417 HPALETTE hpal = GetCurrentObject(physDev->hdc, OBJ_PAL); Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 419 WORD *index = (WORD*) ((LPBYTE) info + (WORD) info->bmiHeader.biSize); Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 423 for(i = 0; i < colors; i++, index++) Wine-dbg>n 421 GetPaletteEntries(hpal, 0, 256, pal_ents); Wine-dbg>n 423 for(i = 0; i < colors; i++, index++) Wine-dbg>n 425 colorTable[i].rgbRed = pal_ents[*index].peRed; Wine-dbg>s 868 switch(rec->ExceptionCode) Wine-dbg>s 867 { Wine-dbg>s 868 switch(rec->ExceptionCode) Wine-dbg>s 873 if (!(rec->ExceptionCode = VIRTUAL_HandleFault( (void *)rec->ExceptionInformation[1] ))) Wine-dbg>s 1125 DWORD ret = EXCEPTION_ACCESS_VIOLATION; I am using the latest Wine I built from CVS, after first encountering this problem in the 20050111 and 20050310 Gentoo ebuilds. I have a Linux 2.6.11 system with glibc 2.3.4 20040808 (including nptl), Xorg-x11 6.8.2-rc2 (Trident Cyberblade/i1 "trident_drv.o") @1024x768 16bpp. Also tried kernels 2.6.9 & 2.6.10 and 800x600 24bpp mode. Would appreciate any advice on how to proceed. http://www.winehq.org/hypermail/wine-users/2005/03/0293.html http://www.winehq.org/hypermail/wine-users/2005/03/0296.html http://appdb.winehq.org/appview.php?appId=1867 Thanks, Jesse Z.

2 2

[AppDB] Application queue: Getting ahead of me.
by Tony Lambregts March 23, 2005

March 23, 2005

I will be unable to tend to the application queue for the next week and as a matter of fact I am already behind maintaining it. (sorry). If one of you good souls (with administrative rights) could take could take care of it for the next week I would really appreciate it. Thanks. -- Tony Lambregts

1 0

World of Warcraft
by cyrix12＠cox.net March 23, 2005

March 23, 2005

What I meant to say in the previous message was something along the lines of "Here's an opengl trace; let me know if you need any others." Unfortunately, it seemed to come out in some other language which I am not familiar in. So here's the opengl trace. Darckness

1 0

Re: DDRAW: Surface locking patch, take 2
by Tony Lambregts March 23, 2005

March 23, 2005

Matthew Mastracci wrote: > This patch (correctly) fixes the locking problems in SimCity 3000. We > now check to see if the blit src and dest are the same surface and, if > so, we make sure to lock the surface only once and, in the case of > BltFast, re-adjust the surface pointers. This patch also makes sure the > surfaces are correctly unlocked if a bad rectangle is passed. > > ChangeLog > Correctly lock and unlock surface for a single-surface Blt() and > BltFast() call. > Is there anything wrong with this patch. http://www.winehq.org/hypermail/wine-patches/2005/03/0113.html It works fine for me (and SimCity). and I was wondering why it was not applied. -- Tony Lambregts

1 0

Riched20: regression "beta" not shown; tab-wish
by Tobias Burnus March 23, 2005

March 23, 2005

Hello, first I'd really like to thank the riched20 workers, notably Krzysztof Foltman and Phil Krylov. For the application Diamond it made a big difference: Instead of "[[Aring]]" etc. one sees the proper symbol and it looks much nicer. But the biggest advantage is that one can now copy or save the text; before the app was simply crashing! Regression: One of the later riched20 patches, possibly http://cvs.winehq.org/patch.py?id=16672, caused a regression with the richedit control in Diamond. Before it showed a beta character from the Symbol font, now it only shows a box ("[]"). If one saves the output (rtf export) one sees ------------------- {\rtf1\ansi\ansicpg1252\uc1\deff0\deflang1031\deflangfe1031{\fonttbl{\f0 Times New Roman;} {\f1\fcharset0 System;} {\f2\fcharset2 Symbol;} }{\*\generator Wine Riched20 2.0.????;}\pard\li0\fi0\ri0{\b\fs18\ul Bibliographic data} \par\pard\li0\fi0\ri0 [...] \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 b}{\fs18 = 5.8312(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\i\fs18 c}{\fs18 = 7.9564(2) \'c5} \par\pard\li0\fi0\ri0{\fs18 }{\fs18\f2 \u61538?}{\fs18 = 100.77(0) \u176?} ------------------- In the last line, after the \f2 (Symbol font), there should be a beta ("b" + Symbol font). Trace (starting from the "b = 5.8312(2)"): ------------ trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 177), counted = 177, len = 1, txt = "L"b"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 178), counted = 178, len = 14, txt = "L" = 5.8312(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 192), counted = 192, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 193, counted = 193 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 193), counted = 193, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 194), counted = 194, len = 1, txt = "L"c"", flags=00000000, fx&mask = 44000002 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 195), counted = 195, len = 14, txt = "L" = 7.9564(2) \00c5"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 209), counted = 209, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets para, real ofsp = 210, counted = 210 trace:richedit:ME_CheckCharOffsets run, real ofs = 0 (+ofsp = 210), counted = 210, len = 1, txt = "L"\t"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 1 (+ofsp = 211), counted = 211, len = 1, txt = "L"\f062"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 2 (+ofsp = 212), counted = 212, len = 14, txt = "L" = 100.77(0) \00b0"", flags=00000000, fx&mask = 44000000 trace:richedit:ME_CheckCharOffsets run, real ofs = 16 (+ofsp = 226), counted = 226, len = 1, txt = "L"\00b6"", flags=00100000, fx&mask = 44000000 ------------ * * * * One feature request: Currently, tabs are shown as box ("[]"), how about replacing them with a simple space - that would increase the readability a lot. Compare: WINE-CVS: http://www.physik.fu-berlin.de/~tburnus/wine/diamond3.png Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_list.png Tobias

1 0

Re: Native stack overlapping system heap base address on some systems
by Steven Edwards March 23, 2005

March 23, 2005

Hi, --- Alexandre Julliard <julliard(a)winehq.org> wrote: > > Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x80000000 This looks like what I have seen on some users systems running Suse 9.2. Some users see errors like this err:virtual:NtMapViewOfSection map_file_into_view 0x80000000 1000000 000000000 failed err:heap:HEAP_CreateSystemHeap system heap base address 0x80000000 not available > No it doesn't overlap, a 20K mapping at 7fffb000 ends at > 7fffffff. Most likely that kernel is configured for a 2Gb virtual > address space. I will recompile a kernel with 2GB and see what happens. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: lostwages/templates/en contributing.template j ...
by Jakob Eriksson March 23, 2005

March 23, 2005

I submitted a patch for all casts I could find with that little grep: find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" Jeremy Newman wrote: >ChangeSet ID: 16817 >CVSROOT: /opt/cvs-commit >Module name: lostwages >Changes by: jnewman(a)wine.codeweavers.com 2005/03/23 08:56:08 > >Modified files: > templates/en : contributing.template janitorial.template > resources.template sending_patches.template > status.template > >Log message: > Mike McCormack <mike(a)codeweavers.com> > * suggest janitoral project > * other updates and W3 fixes > >Patch: http://cvs.winehq.org/patch.py?id=16817 > >Old revision New revision Changes Path > 1.24 1.25 +3 -3 lostwages/templates/en/contributing.template > 1.73 1.74 +17 -7 lostwages/templates/en/janitorial.template > 1.11 1.12 +1 -1 lostwages/templates/en/resources.template > 1.11 1.12 +2 -0 lostwages/templates/en/sending_patches.template > 1.33 1.34 +1 -1 lostwages/templates/en/status.template > > >

1 0

Native stack overlapping system heap base address on some systems
by Mike Hearn March 23, 2005

March 23, 2005

Hi, Bug #2741 comes from a user who was able to grab a dump of the VM mappings when the following error occurred: HEAP_CreateSystemHeap system heap base address 0x80000000 not available I know people have been seeing this intermittently for a while now, we have a few CodeWeavers support tickets with this problem too. The issue seems to be that the Linux native (main thread) stack was allocated here: 7fffb000 20K rwx-- [ stack ] Surprise surprise, 0x7fffb000 + (1024 * 20) == 0x80000000 Unfortunately I lack enough knowledge about the kernels VM algorithms to say why it's being allocated here. For comparison on my Fedora Core 3 machine: fef0d000 16K rwx-- [ stack ] One other thing I don't understand. It seems the stack and the system heap overlap by exactly 1 byte, otherwise the mmap would not fail. But, this area is (theoretically) being protected by the preloader: so how can this be? There is something I'm missing here, I suspect an off-by-one error in my arithmetic. thanks -mike

2 1

Re: Warn users who attempt to use native DirectDraw
by Andreas Mohr March 23, 2005

March 23, 2005

Hi, On Tue, Mar 22, 2005 at 02:26:43PM +0000, Mike Hearn wrote: > + MESSAGE("**********************************************************************"); > + MESSAGE("* Native DirectDraw is not supported, please remove it and try again *"); > + MESSAGE("**********************************************************************"); For such a big message it's still rather unclear/misleading. What about something similar to: *************** Native DirectDraw is not supported by Wine! *************** ****** Please disable loading of any native DDraw DLLs and try again ****** Andreas Mohr

6 7

Re: fix wrc to parse some Borland dialog resources
by Michael Lin March 23, 2005

March 23, 2005

Robert Shearman wrote: >Filip Navara wrote: > >> Michael Lin wrote: >> >>> * change wrc to parse '&' and '~' when specifying style >> >> >> I believe the attached patch would be better solution...you can use >> arbitrary expressions in the style definitions with Microsoft Resource >> Compiler... >In that case, "style '|' style" and "tNOT xpr" are already handled by >the xpr rules so this can be made a lot simpler. Hi all, Just want to bring up this topic again. From what Robert suggested, the style rule can be reduced to the following: style : xpr { $$ = new_style($1, 0); } ; However, this will render the style->and_mask useless as it is never used. In style expression, '~' and tNOT are treated differently. '~' is applied as it is parsed, ie from left to right like normal expressions. However, tNOT is applied at the very end, after all other or_mask are combined and I believe this is why there are or_mask and and_mask in style. xpr won't work here as it treats tNOT and '~' the same. So adding '&' and '~' might be a better solution here. Michael

1 0

Re: registry TODO
by Steven Edwards March 23, 2005

March 23, 2005

Hi, --- Boaz Harrosh <boaz(a)hishome.net> wrote: > How is ReactOS's current (future) system? I think ReactOS's registry is binary compatible with NT4. It and the windows 2000 format was documented/reversed for samba and the linux ntchpwd bootdisk projects. If I remeber right Eirc Kohl offered to release some of his work to Wine for the binary format so you might want to ping him about the implementation details. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: dlls/user/button.c - fix AUTO3STATE with BS_OWNERDRAW (Resend)
by Alexandre Julliard March 23, 2005

March 23, 2005

Michael Lin <mlin(a)corvu.com.au> writes: > inline static UINT get_button_type( LONG window_style ) > { > - return (window_style & 0x0f); > + if ((window_style & BS_OWNERDRAW) == BS_OWNERDRAW) > + return BS_OWNERDRAW; > + else > + return (window_style & 0x0f); BS_OWNERDRAW is not a bit mask, this won't work right. What is the problem you are trying to fix? -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: Warn users who attempt to use native DirectDraw
by Vincent Béron March 22, 2005

March 22, 2005

Le mar 22/03/2005 à 09:26, Mike Hearn a écrit : [snip] > Index: dlls/gdi/gdi_main.c > =================================================================== > RCS file: /home/wine/wine/dlls/gdi/gdi_main.c,v > retrieving revision 1.17 > diff -u -p -d -r1.17 gdi_main.c > --- dlls/gdi/gdi_main.c 15 Jan 2004 00:35:40 -0000 1.17 > +++ dlls/gdi/gdi_main.c 22 Mar 2005 14:15:33 -0000 > @@ -24,9 +24,12 @@ > #include "winbase.h" > #include "wingdi.h" > #include "wine/winbase16.h" > +#include <wine/debug.h> Please use "" instead of <> here. Vincent

1 0

msi.spec different parameter count of exported functions
by Stefan Leichter March 22, 2005

March 22, 2005

Hello, when played with native msi.dll i found three functions with have a different parameter count between msi.spec of wine and the native dll. Here are the snoop logs of the native dll and wine: 0009:RET msi.MsiDatabaseImportA(00000000,00000000,00000000) retval=00000006 ret=004013fc 0009:RET msi.MsiDatabaseImportW(00000000,00000000,00000000) retval=00000006 ret=004013fc 0009:RET msi.MsiCreateAndVerifyInstallerDirectory(00000000) retval=00000000 ret=004013fc I have used the msi.dll version 2.6.2600.11833 for testing. The question now is: Can we trust the +snoop logging? Bye Stefan

2 2

Re: msi: WriteRegistryData advoid NULL data
by Alexandre Julliard March 22, 2005

March 22, 2005

Aric Stewart <aric(a)codeweavers.com> writes: > Win9x RegSetValueExW does not deal with NULL data. so make the data an > empty string instead of null The value is freed later on so this will cause trouble. A better fix is probably to not specify REG_SZ if you are not passing a valid string. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Another one from last night: fix for dlls/kernel/tests/time.c on Windows 98
by Alexandre Julliard March 22, 2005

March 22, 2005

Jakob Eriksson <jakov(a)vmlinux.org> writes: > + /* Windows 98 is a bit broken around these parts, it doesn't return FALSE as it should. */ > + /* If the resulting time is about 10000 AD, I consider the result invalid. */ > + ret = DosDateTimeToFileTime(0,0,&ft); > + years = ((unsigned)ft.dwHighDateTime * 120) / 24 / 365; That formula doesn't seem right to me. Could you please explain what you are doing here? -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: More trace info - dlls/shlwapi/tests/shreg.c
by Paul Vriens March 22, 2005

March 22, 2005

On Tue, 2005-03-22 at 17:16, Jakob Eriksson wrote: > http://test.winehq.org/data/200503181000/nt4/shlwapi:shreg.txt > > What's going on? > > > regards, > Jakob > > > ______________________________________________________________________ > Index: dlls/shlwapi/tests/shreg.c > =================================================================== > RCS file: /home/wine/wine/dlls/shlwapi/tests/shreg.c,v > retrieving revision 1.25 > diff -u -r1.25 shreg.c > --- dlls/shlwapi/tests/shreg.c 3 Feb 2005 19:38:58 -0000 1.25 > +++ dlls/shlwapi/tests/shreg.c 22 Mar 2005 16:15:56 -0000 > @@ -248,7 +248,7 @@ > todo_wine > { > ok( (0 == strcmp("", buf)) | (0 == strcmp(sEnvvar2, buf)), > - "Expected empty or first part of the string (win98), got (%s)\n", buf); > + "Expected empty or first part of the string \"%s\", got \"%s\"\n", sEnvvar2, buf); > } > > ok( dwSize >= nUsedBuffer2, "Buffer size (%lu) should be >= (%lu)\n", dwSize, nUsedBuffer2); Hi, one of the things that's strange about this system was reported by me on wine-devel a few days ago: http://www.winehq.org/hypermail/wine-devel/2005/03/0889.html any idea? Paul.

1 0

Broken winetest compilation
by Paul Millar March 22, 2005

March 22, 2005

Hi, Building winetests is broken again (see errors at end of email). Is this the usual mingw missing functions again? Cheers, Paul. PS, actually there's another problem to do with a RAID system dying. I'll relocate the webpages to somewhere a bit better. i686-mingw32msvc-gcc db.o record.o suminfo.o testlist.o -o msi_test.exe -lmsi -lkernel32 suminfo.o(.text+0x405): In function `func_suminfo': /home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:111: undefinedreference to `MsiSummaryInfoSetPropertyA(a)24' suminfo.o(.text+0x473):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:114: undefined reference to `MsiSummaryInfoSetPropertyA(a)24' suminfo.o(.text+0x4dc):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:117: undefined reference to `MsiSummaryInfoSetPropertyA(a)24' suminfo.o(.text+0x545):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:120: undefined reference to `MsiSummaryInfoSetPropertyA(a)24' suminfo.o(.text+0x637):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:130: undefined reference to `MsiSummaryInfoSetPropertyA(a)24' suminfo.o(.text+0x69f):/home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:133: more undefined references to `MsiSummaryInfoSetPropertyA(a)24' follow suminfo.o(.text+0xea6): In function `func_suminfo': /home/paul/Production/wine-cross-source/dlls/msi/tests/suminfo.c:197: undefinedreference to `MsiSummaryInfoPersist(a)4' distcc[17612] ERROR: compile on localhost failed make: *** [msi_test.exe] Error 1

2 2

Re: Fix Win95 advapi crypt test - dlls/advapi32/tests/crypt.c
by Alexandre Julliard March 22, 2005

March 22, 2005

Jakob Eriksson <jakov(a)vmlinux.org> writes: > --- dlls/advapi32/tests/crypt.c 15 Mar 2005 19:32:38 -0000 1.19 > +++ dlls/advapi32/tests/crypt.c 22 Mar 2005 15:31:55 -0000 > @@ -138,7 +138,10 @@ > hProv = 0; > SetLastError(0xdeadbeef); > result = pCryptAcquireContextA(&hProv, szKeySet, szRsaBaseProv, PROV_RSA_FULL, 0); > - ok(result && (GetLastError() == ERROR_ENVVAR_NOT_FOUND || GetLastError() == ERROR_SUCCESS || GetLastError() == ERROR_RING2_STACK_IN_USE || GetLastError() == NTE_FAIL), "%d/%ld\n", result, GetLastError()); > + ok(result && (GetLastError() == ERROR_ENVVAR_NOT_FOUND || GetLastError() == ERROR_SUCCESS || > + GetLastError() == ERROR_RING2_STACK_IN_USE || GetLastError() == NTE_FAIL || > + GetLastError() == ERROR_NOT_LOGGED_ON), > + "%d/%ld\n", result, GetLastError()); When there are more than 2 or 3 possible last error returns, we should simply get rid of the test. It's very unlikely that any app would rely on the value if it's different on every Windows install. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: KERNEL: PeekNamedPipe must check for zero-length buffer as well as for NULL buffer
by Jakob Eriksson March 22, 2005

March 22, 2005

Alex Villacis Lasso wrote: > > Changelog: > * PeekNamedPipe now checks both for a NULL buffer and a zero-length > buffer before trying to recv() from the pipe Could you write a regression test? regards, Jakob

1 0

Re: NTDLL: teach wine about Mingw32 (RESUBMIT)
by Steven Edwards March 22, 2005

March 22, 2005

Hi, --- "C. Scott Ananian" <cscott(a)cscott.net> wrote: > This patch seems to have gotten lost: it was sent last Thursday but hasn't > yet been applied or rejected (as far as I can tell). It's even got a > testimonial from a wine developer: Andreas Mohr says, "Nice patch." =) I don't understand why Mingw does not report the same value as the Windows compiler here. Do you know lcc or and other free compiler based application need this? If not maybe it should be fixed in mingw. Thanks Steven __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

2 1

Re: registry TODO
by Filip Navara March 22, 2005

March 22, 2005

Boaz Harrosh wrote: > Thomas Weidenmueller wrote: > >>> How is ReactOS's current (future) system? >> >> See above > > I was Just asking what ReactOS is doing, not that they need change. > ReactOS is different in this respect, I agree. > Is ReactOS's format the same as Windows. or do you have your own > Binary format? We use the a Windows registry format, but since some field haven't been reversed yet it is not 100% compatible... ;-) The registry files are mapped as sections in memory along with some other control data stored in non-paged pool. - Filip

1 0

Re: registry TODO
by Jonathan Wilson March 22, 2005

March 22, 2005

> Is ReactOS's format the same as Windows. or do you have your own Binary The answer to "is the reactos registry format the same as windows" depends on which version of windows you are comparing it to. Windows 95/98/ME used system.dat and user.dat to store the registry. NT kernels (NT4, 2000, XP etc) use "registry hives" (IIRC ReactOS uses hives too, no idea if they are the same format as NT/2K/XP or not)

1 0

Re: [WINEALSA] direct sound fallback patch
by Robert Reif March 22, 2005

March 22, 2005

Robert Reif wrote: > Don't fail when opening a device in direct sound mode. > Rather, try alternate formats first before failing. > > With the wave api, requesting a format that the > hardware can't do should fail so the wave mapper can > fix it up. However, the direct sound api does not > expect a failure (within reason) if the format isn't > supported in hardware but expects the closest > format that the hardware does support. > > This gets the direct sound regression tests working > better with the ALSA "hw" device and my lame Intel > builtin sound card. Use this patch instead. Fixes a format bug. Index: dlls/winmm/winealsa/audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v retrieving revision 1.71 diff -u -p -r1.71 audio.c --- dlls/winmm/winealsa/audio.c 21 Mar 2005 12:32:48 -0000 1.71 +++ dlls/winmm/winealsa/audio.c 21 Mar 2005 18:02:05 -0000 @@ -315,6 +315,22 @@ static const char * getMessage(UINT msg) return unknown; } +static const char * getFormat(WORD wFormatTag) +{ + static char unknown[32]; +#define FMT_TO_STR(x) case x: return #x + switch(wFormatTag) { + FMT_TO_STR(WAVE_FORMAT_PCM); + FMT_TO_STR(WAVE_FORMAT_EXTENSIBLE); + FMT_TO_STR(WAVE_FORMAT_MULAW); + FMT_TO_STR(WAVE_FORMAT_ALAW); + FMT_TO_STR(WAVE_FORMAT_ADPCM); + } +#undef FMT_TO_STR + sprintf(unknown, "UNKNOWN(0x%04x)", wFormatTag); + return unknown; +} + static DWORD bytes_to_mmtime(LPMMTIME lpTime, DWORD position, WAVEFORMATPCMEX* format) { @@ -1758,6 +1774,12 @@ static DWORD wodOpen(WORD wDevID, LPWAVE memcpy(&wwo->waveDesc, lpDesc, sizeof(WAVEOPENDESC)); copy_format(lpDesc->lpFormat, &wwo->format); + TRACE("Requested this format: %ldx%dx%d %s\n", + wwo->format.Format.nSamplesPerSec, + wwo->format.Format.wBitsPerSample, + wwo->format.Format.nChannels, + getFormat(wwo->format.Format.wFormatTag)); + if (wwo->format.Format.wBitsPerSample == 0) { WARN("Resetting zeroed wBitsPerSample\n"); wwo->format.Format.wBitsPerSample = 8 * @@ -1789,7 +1811,19 @@ static DWORD wodOpen(WORD wDevID, LPWAVE else wwo->write = snd_pcm_mmap_writei; - EXIT_ON_ERROR( snd_pcm_hw_params_set_channels(pcm, hw_params, wwo->format.Format.nChannels), MMSYSERR_INVALPARAM, "unable to set required channels"); + if ((err = snd_pcm_hw_params_set_channels(pcm, hw_params, wwo->format.Format.nChannels)) < 0) { + WARN("unable to set required channels: %d\n", wwo->format.Format.nChannels); + if (dwFlags & WAVE_DIRECTSOUND) { + if (wwo->format.Format.nChannels > 2) + wwo->format.Format.nChannels = 2; + else if (wwo->format.Format.nChannels == 2) + wwo->format.Format.nChannels = 1; + else if (wwo->format.Format.nChannels == 1) + wwo->format.Format.nChannels = 2; + WARN("changed number of channels from %d to %d\n", lpDesc->lpFormat->nChannels, wwo->format.Format.nChannels); + } + EXIT_ON_ERROR( snd_pcm_hw_params_set_channels(pcm, hw_params, wwo->format.Format.nChannels ), MMSYSERR_INVALPARAM, "unable to set required channels" ); + } if ((wwo->format.Format.wFormatTag == WAVE_FORMAT_PCM) || ((wwo->format.Format.wFormatTag == WAVE_FORMAT_EXTENSIBLE) && @@ -1819,7 +1853,24 @@ static DWORD wodOpen(WORD wDevID, LPWAVE return WAVERR_BADFORMAT; } - EXIT_ON_ERROR( snd_pcm_hw_params_set_format(pcm, hw_params, format), MMSYSERR_INVALPARAM, "unable to set required format"); + if ((err = snd_pcm_hw_params_set_format(pcm, hw_params, format)) < 0) { + WARN("unable to set required format: %s\n", snd_pcm_format_name(format)); + if (dwFlags & WAVE_DIRECTSOUND) { + if ((wwo->format.Format.wFormatTag == WAVE_FORMAT_PCM) || + ((wwo->format.Format.wFormatTag == WAVE_FORMAT_EXTENSIBLE) && + IsEqualGUID(&wwo->format.SubFormat, &KSDATAFORMAT_SUBTYPE_PCM))) { + if (wwo->format.Format.wBitsPerSample != 16) { + wwo->format.Format.wBitsPerSample = 16; + format = SND_PCM_FORMAT_S16_LE; + } else { + wwo->format.Format.wBitsPerSample = 8; + format = SND_PCM_FORMAT_U8; + } + WARN("changed bits per sample from %d to %d\n", lpDesc->lpFormat->wBitsPerSample, wwo->format.Format.wBitsPerSample); + } + } + EXIT_ON_ERROR( snd_pcm_hw_params_set_format(pcm, hw_params, format), MMSYSERR_INVALPARAM, "unable to set required format" ); + } rate = wwo->format.Format.nSamplesPerSec; dir=0; @@ -1830,9 +1881,14 @@ static DWORD wodOpen(WORD wDevID, LPWAVE return WAVERR_BADFORMAT; } if (rate != wwo->format.Format.nSamplesPerSec) { - ERR("Rate doesn't match (requested %ld Hz, got %d Hz)\n", wwo->format.Format.nSamplesPerSec, rate); - snd_pcm_close(pcm); - return WAVERR_BADFORMAT; + if (dwFlags & WAVE_DIRECTSOUND) { + WARN("changed sample rate from %ld Hz to %d Hz\n", wwo->format.Format.nSamplesPerSec, rate); + wwo->format.Format.nSamplesPerSec = rate; + } else { + ERR("Rate doesn't match (requested %ld Hz, got %d Hz)\n", wwo->format.Format.nSamplesPerSec, rate); + snd_pcm_close(pcm); + return WAVERR_BADFORMAT; + } } dir=0; EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params, &buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time");

1 2

Re: msde on wine
by Dan Kegel March 22, 2005

March 22, 2005

Damiano Venturin wrote: > I'm interested in running msde on wine. I'm just looking around to see > if someone reached the goal. I saw you mail at > http://www.winehq.com/hypermail/wine-devel/2003/02/0583.html > > I just want to know if u was able to run it. I haven't tried since then. In the two years since then, MSI support on Wine has come a long ways, perhaps it will install now. Give it a try and report your experiences to the wine-devel mailing list, perhaps someone there can help you past the inevitable problems. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

1 0

registry TODO
by James Hawkins March 22, 2005

March 22, 2005

Alexandre, Recently you removed the loading of the Windows registry on startup and stated that > Nobody's working on it, so it won't be supported until someone cares > enough to do it. I encouraged a few people to start working on it but > nobody did, so taking out the existing support is a way to provide > more encouragement. If that's not enough then the feature simply won't > be supported anymore. What needs to be done concerning this TODO? Looking through Bugzilla I found bug #422: "Currently Wine loads the complete registry into memory at startup. This is relatively ok when the registry is small such as in fake_windows configurations, but when importing the registry fro a Windows partition this can result in the wineserver allocating more than 30MB. This slows down startup times very significantly and wastes memory even if most of it is going to be swapped out. One of the reasons why Wine puts all the registry into memory on startup is that the current registry file format does not lend itself well to random accesses (especially writes). But there is no fundamental reason why Wine needs to read all the registry on startup. Hence this proposal to: * change the registry file format so that Wine can easily make random accesses. A 'database' format may be appropriate here, maybe based on the Berkeley database Library (libdb2/libdb3) or the GNU dbm library (libgbm1, but check license issues). * put in place a mechanism to update these files from the Windows registry files when appropriate (it seems impractical to access the Windows files directly) * modify the registry routines to retrieve only the data required by the application and cache it in memory" Is this a valid description of what needs to be done? -- James Hawkins

3 2

Regression in file tests
by Jakob Eriksson March 22, 2005

March 22, 2005

Between http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/file.c#rev1.46 http://test.winehq.org/data/200502231000/ and http://test.winehq.org/data/200503041000/ http://cvs.winehq.org/cvsweb/wine/dlls/kernel/tests/file.c#rev1.48 we have more about 50 more failed test results. What happened? regards, Jakob

1 1

Re: Eliminate casts of the return value of HeapAlloc
by Francois Gouget March 22, 2005

March 22, 2005

On Mon, 21 Mar 2005, Alexandre Julliard wrote: [...] > Log message: > Mike McCormack <mike(a)codeweavers.com> > Eliminate casts of the return value of HeapAlloc. This could be turned into a pretty easy janitorial the starting point of which would be the output of this command: find . -name "*.[ch]" | xargs egrep "\) *Heap(Re)?Alloc" (344 lines) There are a couple of places where the output of HeapAlloc is being cast to a DWORD but except for those it seems pretty straightforward. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ La terre est une b\xEAta...

3 2

Status and (nearby) future of wined3d
by Paul Vriens March 21, 2005

March 21, 2005

Hi, what will happen to the wined3d stuff, now Oliver has some 'problems' staying on-line? There were at least 4 patches or so he send which were not applied (yet). If the sole reason for that is that it couldn't be merged/applied to CVS I could give it a try. But that's about the only thing I can do regarding wined3d stuff. Cheers, Paul.

1 0

Preview-window works in Virtualdub,Paltalk etc.
by luis lenders March 21, 2005

March 21, 2005

Hi, don't know if it's of much use for anyone, but i can now view the images from my webcam in the preview window in programs like Virtualdub, Paltalk and WebCamnow. Basically the attached "patch" reads a RGB-image from my video4linux device and "turns" this into a bitmap, which is then displayed. The device must be able to "read RGB's". In case you would like to try, replace dlls/avicap32 with the attached one, and replace include/vfw.h with the attached vfw.h. I'm skilled enough to turn this into a real patch, maybe someone with more programming capabilities could give it try. Regards Luis Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

[shlwapi/tests/shreg.c] Question about ExpandEnvironmentStringsA
by Paul Vriens March 21, 2005

March 21, 2005

Hi, while going through some results on test.winehq.org I've noticed something regarding ExpandEnvironmentStringsA. One of the NT4 tests (I think it's one from Ivan Leo Puoti?) comes back with: shreg.c:97:sExplen1 = (24) shreg.c:99:sExplen2 = (86) while all others (i.e. win98/nt4/w2k/winxp) I've seen so far return: shreg.c:97:sExplen1 = (12) shreg.c:99:sExplen2 = (43) Why is/could the length be doubled in his case? Cheers, Paul.

2 2

Re: RICHEDIT: RTF reader i18n (now with font charset support)
by Phil Krylov March 21, 2005

March 21, 2005

On Mon, 21 Mar 2005 14:40:38 +0300 Vitaly Lipatov <lav(a)etersoft.ru> wrote: > > > Will we do this code in locale independent manner? Why we have > > > ansiCodePage=1252 by default? > > > > It is locale independent. 1252 is the default value used if RTF does not > > specify another codepage (which almost never happens). If I used > > GetACP() here, the same RTF document would be differently imported > > depending on user locale. RTF is not supposed to act like this. If RTF > If I try open RTF where codepage is not specified, guessed codepage must be > the same as ACP. For instance if I get such file here in Russia, I suppose it > in cp1251 codepage. > > > does not specify any codepage it means that it uses CP1252. > I recommend use GetACP, otherwise in will some disadvantage for non cp1252 > users. > > > How do you find this code is locale dependent? IMHO it's _in_dependent of > > locale. > I worry only about default codepage. OK, I've made some tests using the original M$ richedit, and they show the following: \ansicpg keyword in the RTF header does not affect the used encoding when importing RTF. The encoding used for import is determined by \fcharset setting for the "current" font. If it specifies \fcharset1 (DEFAULT_CHARSET) or is omitted, GetACP() is used. If it specifies \fcharset0 (ANSI_CHARSET), CP1252 is used regardless of current locale. For other charsets, their respective codepages are used. I'll commit the required changes to the RTF reader soon. -- Ph.

1 0

Re: [ntdll] NtCreateFile update
by Jonathan Wilson March 21, 2005

March 21, 2005

Does anyone have any links to these "documented only because Microsoft have to" type functions (like NtCreateFile etc)?

3 3

Re: Four questions to dll/iphlpapi/* wrt lstrcpyA.
by Juan Lang March 21, 2005

March 21, 2005

Hi Peter, there's nothing magical in here, your understanding is correct. I'll answer each question individually though. > 1) I am wondering, why sizeof(ptr->Adaptername) is used instead of > MAX_ADAPTER_NAME_LENGTH+1? That's just a style thing. I prefer sizeof(thing being copied) to MAGIC_CONSTANT in case the structure being used changes. That's unlikely in this case since the structure is defined in a public header. Since it's a style thing there's no code-behavior reason to keep it this way. > 2) Is 2a supposed to be saying 15 Yes, that's just a stupid bug apparently. Why I didn't use sizeof is beyond me. > 3) Why suddenly the change to use memcpy? and not some strcpy > function as the code above it? I wrote this on a different day :) --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: DDRAW: Surface locking patch, take 2
by Christian Costa March 20, 2005

March 20, 2005

Hi Matthew, This seems fine. There are some comments though, see below. >Index: dlls/ddraw/dsurface/dib.c >=================================================================== >RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v >retrieving revision 1.46 >diff -u -r1.46 dib.c >--- dlls/ddraw/dsurface/dib.c 10 Mar 2005 11:13:11 -0000 1.46 >+++ dlls/ddraw/dsurface/dib.c 20 Mar 2005 16:49:40 -0000 >@@ -528,9 +528,15 @@ > DD_STRUCT_INIT(&sdesc); > > sdesc.dwSize = sizeof(sdesc); >- if (src) IDirectDrawSurface7_Lock(src, NULL, &sdesc, DDLOCK_READONLY, 0); > ddesc.dwSize = sizeof(ddesc); >- IDirectDrawSurface7_Lock(iface,NULL,&ddesc,DDLOCK_WRITEONLY,0); >+ >+ if (src == iface) { >+ IDirectDrawSurface7_Lock(iface, NULL, &ddesc, 0, 0); >+ DD_STRUCT_COPY_BYSIZE(&sdesc, &ddesc); >+ } else { >+ if (src) IDirectDrawSurface7_Lock(src, NULL, &sdesc, DDLOCK_READONLY, 0); >+ IDirectDrawSurface7_Lock(iface,NULL,&ddesc,DDLOCK_WRITEONLY,0); >+ } > > if ((sdesc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && > (ddesc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC)) { >@@ -581,7 +587,8 @@ > (xsrc.right > sdesc.dwWidth) || (xsrc.right < 0) || > (xsrc.right < xsrc.left) || (xsrc.bottom < xsrc.top))) { > WARN("Application gave us bad source rectangle for Blt.\n"); >- return DDERR_INVALIDRECT; >+ ret = DDERR_INVALIDRECT; >+ goto release; > } > /* For the Destination rect, it can be out of bounds on the condition that a clipper > is set for the given surface. >@@ -593,7 +600,8 @@ > (xdst.right > ddesc.dwWidth) || (xdst.right < 0) || > (xdst.right < xdst.left) || (xdst.bottom < xdst.top))) { > WARN("Application gave us bad destination rectangle for Blt without a clipper set.\n"); >- return DDERR_INVALIDRECT; >+ ret = DDERR_INVALIDRECT; >+ goto release; > } > > /* Now handle negative values in the rectangles. Warning: only supported for now >@@ -958,7 +966,7 @@ > > release: > IDirectDrawSurface7_Unlock(iface,NULL); >- if (src) IDirectDrawSurface7_Unlock(src,NULL); >+ if (src && src != iface) IDirectDrawSurface7_Unlock(src,NULL); > return DD_OK; > } > >@@ -975,7 +983,7 @@ > HRESULT ret = DD_OK; > LPBYTE sbuf, dbuf; > RECT rsrc2; >- RECT lock_src, lock_dst; >+ RECT lock_src, lock_dst, lock_union; > > if (TRACE_ON(ddraw)) { > TRACE("(%p)->(%ld,%ld,%p,%p,%08lx)\n", >@@ -1043,11 +1051,28 @@ > lock_dst.right = dstx + w; > lock_dst.bottom = dsty + h; > >+ bpp = GET_BPP(This->surface_desc); >+ > /* We need to lock the surfaces, or we won't get refreshes when done. */ >- sdesc.dwSize = sizeof(sdesc); >- IDirectDrawSurface7_Lock(src, &lock_src, &sdesc, DDLOCK_READONLY, 0); >- ddesc.dwSize = sizeof(ddesc); >- IDirectDrawSurface7_Lock(iface, &lock_dst, &ddesc, DDLOCK_WRITEONLY, 0); >+ if (src == iface) { >+ int pitch; >+ >+ UnionRect(&lock_union, &lock_src, &lock_dst); >+ >+ /* Lock the union of the two rectangles */ >+ IDirectDrawSurface7_Lock(iface, &lock_union, &ddesc, 0, 0); >+ >+ pitch = This->surface_desc.u1.lPitch; >+ > ddesc has not been properly initialized. you should also copy sdesc from ddesc. >+ /* Since sdesc was originally copied from this surface's description, we can just reuse it */ >+ sdesc.lpSurface = (BYTE *)This->surface_desc.lpSurface + lock_src.top * pitch + lock_src.left * bpp; >+ ddesc.lpSurface = (BYTE *)This->surface_desc.lpSurface + lock_dst.top * pitch + lock_dst.left * bpp; >+ } else { >+ sdesc.dwSize = sizeof(sdesc); >+ IDirectDrawSurface7_Lock(src, &lock_src, &sdesc, DDLOCK_READONLY, 0); >+ ddesc.dwSize = sizeof(ddesc); >+ IDirectDrawSurface7_Lock(iface, &lock_dst, &ddesc, DDLOCK_WRITEONLY, 0); >+ } > > /* Handle first the FOURCC surfaces... */ > if ((sdesc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC) && (ddesc.u4.ddpfPixelFormat.dwFlags & DDPF_FOURCC)) { >@@ -1069,7 +1094,6 @@ > goto error; > } > >- bpp = GET_BPP(This->surface_desc); > sbuf = (BYTE *) sdesc.lpSurface; > dbuf = (BYTE *) ddesc.lpSurface; > >@@ -1141,8 +1165,13 @@ > } > > error: >- IDirectDrawSurface7_Unlock(iface, &lock_dst); >- IDirectDrawSurface7_Unlock(src, &lock_src); >+ if (src == iface) { >+ IDirectDrawSurface7_Unlock(iface, &lock_union); >+ } else { >+ IDirectDrawSurface7_Unlock(iface, &lock_dst); >+ IDirectDrawSurface7_Unlock(src, &lock_src); > You should check if src != NULL before trying to unlocking it. >+ } >+ > return ret; > } > > >

2 2

Re: [WINEALSA] fix direct sound capabilities to match HW
by Robert Reif March 20, 2005

March 20, 2005

Robert Reif wrote: > Fix direct sound capabilities to match hardware. > > Should fix problems related to trying to do 8 bit and mono on > 16 bit stereo only hardware when using ALSA hw device and > direct sound hardware acceleration. > > > This one should work. Index: dlls/winmm/winealsa/audio.c =================================================================== RCS file: /home/wine/wine/dlls/winmm/winealsa/audio.c,v retrieving revision 1.67 diff -u -p -r1.67 audio.c --- dlls/winmm/winealsa/audio.c 19 Mar 2005 17:11:02 -0000 1.67 +++ dlls/winmm/winealsa/audio.c 20 Mar 2005 20:51:41 -0000 @@ -189,6 +189,7 @@ typedef struct { /* DirectSound stuff */ DSDRIVERDESC ds_desc; + DSDRIVERCAPS ds_caps; } WINE_WAVEOUT; typedef struct { @@ -231,6 +232,7 @@ typedef struct { /* DirectSound stuff */ DSDRIVERDESC ds_desc; + DSCDRIVERCAPS ds_caps; } WINE_WAVEIN; static WINE_WAVEOUT WOutDev [MAX_WAVEOUTDRV]; @@ -817,6 +819,38 @@ LONG ALSA_WaveInit(void) wwo->caps.dwSupport |= WAVECAPS_LRVOLUME; } + if (wwo->caps.dwFormats & (WAVE_FORMAT_1M08 | WAVE_FORMAT_2M08 | + WAVE_FORMAT_4M08 | WAVE_FORMAT_48M08 | + WAVE_FORMAT_96M08 | WAVE_FORMAT_1M16 | + WAVE_FORMAT_2M16 | WAVE_FORMAT_4M16 | + WAVE_FORMAT_48M16 | WAVE_FORMAT_96M16) ) + wwo->ds_caps.dwFlags |= DSCAPS_PRIMARYMONO; + + if (wwo->caps.dwFormats & (WAVE_FORMAT_1S08 | WAVE_FORMAT_2S08 | + WAVE_FORMAT_4S08 | WAVE_FORMAT_48S08 | + WAVE_FORMAT_96S08 | WAVE_FORMAT_1S16 | + WAVE_FORMAT_2S16 | WAVE_FORMAT_4S16 | + WAVE_FORMAT_48S16 | WAVE_FORMAT_96S16) ) + wwo->ds_caps.dwFlags |= DSCAPS_PRIMARYSTEREO; + + if (wwo->caps.dwFormats & (WAVE_FORMAT_1M08 | WAVE_FORMAT_2M08 | + WAVE_FORMAT_4M08 | WAVE_FORMAT_48M08 | + WAVE_FORMAT_96M08 | WAVE_FORMAT_1S08 | + WAVE_FORMAT_2S08 | WAVE_FORMAT_4S08 | + WAVE_FORMAT_48S08 | WAVE_FORMAT_96S08) ) + wwo->ds_caps.dwFlags |= DSCAPS_PRIMARY8BIT; + + if (wwo->caps.dwFormats & (WAVE_FORMAT_1M16 | WAVE_FORMAT_2M16 | + WAVE_FORMAT_4M16 | WAVE_FORMAT_48M16 | + WAVE_FORMAT_96M16 | WAVE_FORMAT_1S16 | + WAVE_FORMAT_2S16 | WAVE_FORMAT_4S16 | + WAVE_FORMAT_48S16 | WAVE_FORMAT_96S16) ) + wwo->ds_caps.dwFlags |= DSCAPS_PRIMARY16BIT; + + wwo->ds_caps.dwMinSecondarySampleRate = DSBFREQUENCY_MIN; + wwo->ds_caps.dwMaxSecondarySampleRate = DSBFREQUENCY_MAX; + wwo->ds_caps.dwPrimaryBuffers = 1; + ALSA_WodNumDevs++; } @@ -933,7 +967,7 @@ LONG ALSA_WaveInit(void) ALSA_WidNumDevs++; } - + return 0; } @@ -2013,7 +2047,7 @@ static DWORD wodGetVolume(WORD wDevID, L if (!wwo->ctl) return MMSYSERR_NOTSUPPORTED; - + count = snd_ctl_elem_info_get_count(wwo->playback_einfo); min = snd_ctl_elem_info_get_min(wwo->playback_einfo); max = snd_ctl_elem_info_get_max(wwo->playback_einfo); @@ -2612,25 +2646,7 @@ static HRESULT WINAPI IDsDriverImpl_GetC { IDsDriverImpl *This = (IDsDriverImpl *)iface; TRACE("(%p,%p)\n",iface,pCaps); - memset(pCaps, 0, sizeof(*pCaps)); - - pCaps->dwFlags = DSCAPS_PRIMARYMONO; - if ( WOutDev[This->wDevID].caps.wChannels == 2 ) - pCaps->dwFlags |= DSCAPS_PRIMARYSTEREO; - - if ( WOutDev[This->wDevID].caps.dwFormats & (WAVE_FORMAT_1S08 | WAVE_FORMAT_2S08 | WAVE_FORMAT_4S08 ) ) - pCaps->dwFlags |= DSCAPS_PRIMARY8BIT; - - if ( WOutDev[This->wDevID].caps.dwFormats & (WAVE_FORMAT_1S16 | WAVE_FORMAT_2S16 | WAVE_FORMAT_4S16)) - pCaps->dwFlags |= DSCAPS_PRIMARY16BIT; - - pCaps->dwPrimaryBuffers = 1; - TRACE("caps=0x%X\n",(unsigned int)pCaps->dwFlags); - pCaps->dwMinSecondarySampleRate = DSBFREQUENCY_MIN; - pCaps->dwMaxSecondarySampleRate = DSBFREQUENCY_MAX; - - /* the other fields only apply to secondary buffers, which we don't support - * (unless we want to mess with wavetable synthesizers and MIDI) */ + memcpy(pCaps, &(WOutDev[This->wDevID].ds_caps), sizeof(DSDRIVERCAPS)); return DS_OK; }

1 0

Re: ddraw correctness fixes patch
by Christian Costa March 20, 2005

March 20, 2005

> Message du 18/03/05 13:49 > De : "Christian Costa" > A : "Tom Wickline" , "wine-devel" > Copie à : > Objet : Re: ddraw correctness fixes patch > > > > Message du 18/03/05 06:44 > > De : "Tom Wickline" > > A : "wine-devel" > > Copie à : > > Objet : ddraw correctness fixes patch > > > > anyone know why this patch hasn't been accepted? > > > > http://www.winehq.org/hypermail/wine-patches/2005/03/0328.html > > > > Tom > > > > Hi Tom, > > Sorry I missed the patch on wine-patches but I do remember an old version sent to wine-devel. > > So let's review it. :-) > > The new locking mechanism is wrong. > DDLOCK_xxx are just used for optimization. > > The thing to do during the blit should be something like that : > > sdesc.dwSize = sizeof(sdesc); > ddesc.dwSize = sizeof(ddesc); > if (src == NULL) > IDirectDrawSurface7_Lock(iface, &lock_dst, &ddesc, DDLOCK_WRITEONLY, 0); > else if (src == iface) { > RECT lock_union = < rect that just contains lock_dst and lock_src >; > IDirectDrawSurface7_Lock(iface, &lock_union, &ddesc, 0, 0); > sdesc = ddesc; I think here that sdesc and ddesc surface pointers should be remapped according to lock_src and lock_dest. > } else { > IDirectDrawSurface7_Lock(src, &lock_src, &sdesc, DDLOCK_READONLY, 0); > IDirectDrawSurface7_Lock(iface, &lock_dst, &ddesc, DDLOCK_WRITEONLY, 0); > } > > and the previous locking code should be used. > > The added DD_STRUCT_INIT are useless. > > Hope that helps. > > Bye, > Christian > > > > > >

3 4

ntdll / kernel32: #53
by Eric Pouech March 20, 2005

March 20, 2005

This patch starts looking at providing full overlapped I/O support to named pipes. We're not here yet. It basically starts making the wineserver side of the named pipe code: - use NT values instead of kernel32 - make use of asynchronous I/O The rest of the patch is mainly cleanup. It should be a no op change. A+ -- Eric Pouech

1 0

Re: winmm patch
by Dimitrie O. Paun March 20, 2005

March 20, 2005

On Sat, Mar 19, 2005 at 07:46:01PM -0600, Royce Mitchell III wrote: > Royce Mitchell III <royce3(a)ev1.net> > - fix warning that is really a bug - from looking at the code, wDevID > should be a UINT, not a UINT_16 ( perhaps these should be renamed? ) Please: 1. Send a diff -u (http://winehq.org/site/sending_patches) 2. Don't compress your submissions. -- Dimi.

1 0

Re: Correct calling conventions
by Marcus Meissner March 20, 2005

March 20, 2005

On Sat, Mar 19, 2005 at 08:30:44PM -0500, Vincent Béron wrote: > Changelog: > Use the correct calling convention in various places. The problem here is too, that these functions do not have prototypes in the correct headers, otherwise gcc would have already warned about them. Ciao, Marcus

2 1

winmm problems
by Robert Lunnon March 20, 2005

March 20, 2005

I am having some problems with the latest wine under Solaris and a small test game I use, (Little Fighter 2) , if I enable audio support the application seems to deadlock but without audio it runs OK. It doesn't matter what audio driver I select (libaudioio or arts). Since February, what changes have been made to the audio framework that might cause this behaviour? Bob

1 0

Four questions to dll/iphlpapi/* wrt lstrcpyA.
by Peter Berg Larsen March 20, 2005

March 20, 2005

Hi, I was looking at the Janitorial project of replacing strncpy with lstrcpyn{A,W}. I found the following code in iphlpapi a little strange. (Well, only question number 2, but then could as well ask about the 2 others.) I have marked where in the code the question belongs to with the question numbers. 1) I am wondering, why sizeof(ptr->Adaptername) is used instead of MAX_ADAPTER_NAME_LENGTH+1? Is there something special coded in the 3 last bytes, since they are hidden by the = '\0' the line below? if not then this be replaced with lstrcpyn(... , MAX_ADAPTER_NAME_LENGTH+1)? 2) Is 2a supposed to be saying 15 or is there someting about IpMask and Context that must be zero, when setting IpAddress, and IpMask? 3) Why suddenly the change to use memcpy? and not some strcpy function as the code above it? Peter typedef struct { char String[4 * 4]; } IP_ADDRESS_STRING, IP_MASK_STRING, ...; typedef struct _IP_ADDR_STRING { struct _IP_ADDR_STRING* Next; IP_ADDRESS_STRING IpAddress; IP_MASK_STRING IpMask; DWORD Context; } IP_ADDR_STRING, *PIP_ADDR_STRING; typedef struct _IP_ADAPTER_INFO { ... char AdapterName[MAX_ADAPTER_NAME_LENGTH + 4]; char Description[MAX_ADAPTER_DESCRIPTION_LENGTH + 4]; BYTE Address[MAX_ADAPTER_ADDRESS_LENGTH]; IP_ADDR_STRING IpAddressList; ... IP_ADDR_STRING PrimaryWinsServer; IP_ADDR_STRING SecondaryWinsServer; } IP_ADAPTER_INFO, *PIP_ADAPTER_INFO; ipenum.c: 936 char *toIPAddressString(unsigned int addr, char string[16]) { if (string) { struct in_addr iAddr; iAddr.s_addr = addr; /* extra-anal, just to make auditors happy */ strncpy(string, inet_ntoa(iAddr), 16); string[16] = '\0'; **** 2a **** } return string; } iphlpapi_main.c: 584 DWORD WINAPI GetAdaptersInfo(PIP_ADAPTER_INFO pAdapterInfo, PULONG pOutBufLen) { ... PIP_ADAPTER_INFO ptr = &pAdapterInfo[ndx]; ... 1) /* on Win98 this is left empty, but whatever */ strncpy(ptr->AdapterName, getInterfaceNameByIndex(table->indexes[ndx]), sizeof(ptr->AdapterName)); ptr->AdapterName[MAX_ADAPTER_NAME_LENGTH] = '\0'; ... 2) toIPAddressString(getInterfaceIPAddrByIndex(table->indexes[ndx]), ptr->IpAddressList.IpAddress.String); toIPAddressString(getInterfaceMaskByIndex(table->indexes[ndx]), ptr->IpAddressList.IpMask.String); ... 3) memcpy(ptr->PrimaryWinsServer.IpAddress.String, primaryWINS.String, sizeof(primaryWINS.String)); memcpy(ptr->SecondaryWinsServer.IpAddress.String, secondaryWINS.String, sizeof(secondaryWINS.String)); ... }

1 0

kde plugin
by Oliver Stieber March 20, 2005

March 20, 2005

Hi, I've got a plugin for KDE that displays icons and thumbnails for windows applications and dlls in Konqueror. I was intending to extend it to meta info and maybe a full kioslave for browsing windows PE files, but never got that far. At the moment it's a bit of a licensing nightmare, but I can package it up in a format that's ok for QT and Wine if anyone's interested. Oliver. Send instant messages to your online friends http://uk.messenger.yahoo.com

2 3

Re: Theming for Wine via the registry
by Oliver Stieber March 20, 2005

March 20, 2005

--- Mike Hearn <mike(a)navi.cx> wrote: > On Sat, 2005-03-12 at 21:00 +0000, Oliver Stieber > wrote: > > > > > > Ah, that's different. That'd actually require > using > > > Gtk/Qt which we cannot > > > do, the best we can get is to look like them. > > > > > What's the problem, licensing, integration or > > thread-safety (I know QT isn't thread safe) > > Well all those *could* be problems, but the real > problem is that the > Windows widget toolkit and GTK/Qt are too different, > you can't map > between them. The only problem I can see would be drawing the widgets, I haven't looked deeply enough into QT or GTK to know if it's more on the 'impossible' side of difficult or not. Wrapping the event loop and passing events should be relatively easy. > > I may have a look at that too, it would be useful > if > > QT/GTK could use some of the existing Windows > > accessibility software. > > No, that's not what I meant. Implementing OLE > accessibility would mean > that Win32 apps on Wine appear to in native tools > like at-poke. It > wouldn't mean you could use win32 accessibility > software to access > native apps. > That doesn't sound too hard, I don't know how well defined Gnome and QT's accessibility interfaces are but I think QT's coming along quite well it would be nice is everything got Dbused though. Send instant messages to your online friends http://uk.messenger.yahoo.com

4 3