- wine-devel - winehq.org

Re: mshtml #3: Store HTMLDocument pointer in BSCallback object.
by Alexandre Julliard 05 Nov '07

05 Nov '07

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/mshtml/mshtml_private.h | 5 ++++- > dlls/mshtml/navigate.c | 27 ++++++++++++++++++++++++--- > dlls/mshtml/persist.c | 2 +- > dlls/mshtml/task.c | 7 ++++--- > 4 files changed, 33 insertions(+), 8 deletions(-) That one is broken here: ../../../tools/runtest -q -P wine -M mshtml.dll -T ../../.. -p mshtml_test.exe.so dom.c && touch dom.ok wine: Unhandled page fault on write access to 0x006d005d at address 0x61dfd127 (thread 0009), starting debugger... WineDbg starting on pid 0008 Unhandled exception: page fault on write access to 0x006d005d in 32-bit code (0x61dfd127). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:61dfd127 ESP:0033fc30 EBP:0033fc48 EFLAGS:00010206( - 00 - RIP1) EAX:00129c78 EBX:61e34074 ECX:006d0065 EDX:00129c78 ESI:006d0025 EDI:00129cf4 Stack dump: 0x0033fc30: 00ee0314 00f84550 00000000 00000000 0x0033fc40: 804b0000 00129c78 0033fda8 61e123ea 0x0033fc50: 00129c78 00f96da8 00000000 00000000 0x0033fc60: 00000000 00000000 0033fc88 7bc4125e 0x0033fc70: 00129c78 61e2de2a 00ee0000 7bc3283f 0x0033fc80: 00000000 00f84538 0033fd38 00f96da8 Backtrace: =>1 0x61dfd127 set_document_bscallback+0x57(doc=0x129c78, callback=0xf96da8) [/home/julliard/wine/wine/dlls/mshtml/navigate.c:855] in mshtml (0x0033fc48) 2 0x61e123ea set_moniker+0x69a(This=0x129c78, mon=0xf84538, pibc=0x0, bind_complete=0x0) [/home/julliard/wine/wine/dlls/mshtml/persist.c:327] in mshtml (0x0033fda8) 3 0x61e12a26 PersistStreamInit_Load+0x66(iface=0x129cbc, pStm=0xf84510) [/home/julliard/wine/wine/dlls/mshtml/persist.c:676] in mshtml (0x0033fde8) 4 0x60512eb1 run_domtest+0x131(str=0x605284c0, test=0x605142b0) [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:1161] in mshtml_test (0x0033fe58) 5 0x6051326c func_dom+0x3c() [/home/julliard/wine/wine/dlls/mshtml/tests/dom.c:1254] in mshtml_test (0x0033fe68) 6 0x6052713a run_test+0x14a(name=0x1103e7) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:389] in mshtml_test (0x0033fea8) 7 0x6052779a main+0x15a(argc=<register ECX not in topmost frame>, argv=0x1103c8) [/home/julliard/wine/wine/dlls/mshtml/tests/../../../include/wine/test.h:437] in mshtml_test (0x0033fed8) 8 0x6052786b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in mshtml_test (0x0033ff08) 9 0x7b873dae start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8) 10 0x600288a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x61dfd127 set_document_bscallback+0x57 [/home/julliard/wine/wine/dlls/mshtml/navigate.c:855] in mshtml: movl $0x0,0x38(%esi) 855 iter->doc = NULL; -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: libs/wine: Avoid compiler warnings about unused parameter(-W)
by Alexandre Julliard 05 Nov '07

05 Nov '07

Detlef Riekenberg <wine.dev(a)web.de> writes: > Changelog: > libs/wine: Avoid compiler warnings about unused parameter(-W) > > The code-sequence is optimized away. > Another option would be "__attribute__((unused__))" > or removing the function. The best option is to not enable the warning. There are plenty of cases where it's legitimate to not use a parameter, that warning is not useful. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: USER32: win16 applications should not see long filenames returned from dialog control (try 2)
by Dmitry Timoshkov 05 Nov '07

05 Nov '07

"Alex Villacís Lasso" <a_villacis(a)palosanto.com> wrote: > BOOL16 WINAPI DlgDirSelectEx16( HWND16 hwnd, LPSTR str, INT16 len, INT16 id ) > { > - return DlgDirSelectExA( WIN_Handle32(hwnd), str, len, id ); > + BOOL16 ret = DlgDirSelectExA( WIN_Handle32(hwnd), str, len, id ); > + GetShortPathNameA(str, str, len); > + return ret; > } > BOOL16 WINAPI DlgDirSelectComboBoxEx16( HWND16 hwnd, LPSTR str, INT16 len, > INT16 id ) > { > - return DlgDirSelectComboBoxExA( WIN_Handle32(hwnd), str, len, id ); > + BOOL16 ret = DlgDirSelectComboBoxExA( WIN_Handle32(hwnd), str, len, id ); > + GetShortPathNameA(str, str, len); > + return ret; > } You are passing garbage to GetShortPathNameA in the case of failure. -- Dmitry.

2 1

'kernel32_test loader' causes BSOD on XP SP1
by Francois Gouget 05 Nov '07

05 Nov '07

So I'm running tests in an XP SP1 VM and yet, you can see no such results on http://test.winehq.org/data/. The reason for is that the 'kernel32_test loader' causes XP SP1 to crash, so that winetest.exe never has an opportunity to send the results. So I investigated this and the specific test that causes the crash is this one: { &dos_header, sizeof(dos_header), 1, sizeof(IMAGE_OPTIONAL_HEADER), 0x200, 0x200, sizeof(dos_header) + sizeof(nt_header) + sizeof(IMAGE_SECTION_HEADER) + 0x1000, sizeof(dos_header) + sizeof(nt_header) + sizeof(IMAGE_SECTION_HEADER), ERROR_SUCCESS }, I noticed the 0x1000. Shouldn't this be a 0x200? Or is that the whole point of this test? In any case, changing it to 0x200 avoids crashing SP1. Another weird way to avoid the crash is to introduce a Sleep(1000) just before the LoadLibrary(). I've summed up both ways to avoid the crash in the patch below. Hopefully someone more familiar with the loader than me can have a look into this and suggest a proper fix. diff --git a/dlls/kernel32/tests/loader.c b/dlls/kernel32/tests/loader.c index 49af819..f9f9e0b 100644 --- a/dlls/kernel32/tests/loader.c +++ b/dlls/kernel32/tests/loader.c @@ -139,7 +139,7 @@ START_TEST(loader) }, { &dos_header, sizeof(dos_header), 1, sizeof(IMAGE_OPTIONAL_HEADER), 0x200, 0x200, - sizeof(dos_header) + sizeof(nt_header) + sizeof(IMAGE_SECTION_HEADER) + 0x1000, + sizeof(dos_header) + sizeof(nt_header) + sizeof(IMAGE_SECTION_HEADER) + 0xf00, sizeof(dos_header) + sizeof(nt_header) + sizeof(IMAGE_SECTION_HEADER), ERROR_SUCCESS }, @@ -321,6 +322,11 @@ START_TEST(loader) file_size = GetFileSize(hfile, NULL); CloseHandle(hfile); + if (0 && i == 4) + { + /* Required to avoid a crash on Windows XP SP1 */ + Sleep(1000); + } SetLastError(0xdeadbeef); hlib = LoadLibrary(dll_name); if (td[i].error == ERROR_SUCCESS) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

2 2

Re: #winehq admin troubles
by darckness 05 Nov '07

05 Nov '07

>> I agree that this isn't something that should continue. Kicking >> should be reserved for people being disruptive. There is no reason >> to be anything other than polite to users asking for help. >> >> Allowing this kind of behavior to continue reflects poorly on us as a >> community. I'd like to suggest that this be the last time we hear >> about issues like this. If it happens again I'd like to propose a >> graduated scale of irc channel bans, starting at one month, for >> Vitamin. >> >> Chris > >I hope this is a joke! There is absolutely nothing wrong with they way >Vitamin handles himself in #winehq. When these people come crying to >wine-devel they leave out about 98% of the facts, 100% of the time. > >Tom I don't write in to wine-devel often, nor am I a developer, but I completely agree with Tom on this one. The amount of bad information given out by users to other users in #winehq is positively staggering, and I cannot fault Vitamin at all for the way he acts. The fact that he stays in that channel to try and help people after all the crap he has to deal with is incredible. If you come to #winehq with a question and a helpful attitude, Vitamin will usually do his best to try and troubleshoot the issue, and he is quite cordial while doing it. If, however, you come in with a know-it-all attitude and try arguing with him or giving out tips which are known to be erroneous, you do not belong in #winehq until you can control yourself. I've seen this happen countless times, and people who get kicked never seem to understand that they fit this negative, unhelpful mold all too well. -darckness

1 0

Re: libs/wine: Avoid compiler warnings about unused parameter(-W)
by Michael Stefaniuc 05 Nov '07

05 Nov '07

Detlef Riekenberg wrote: > Changelog: > libs/wine: Avoid compiler warnings about unused parameter(-W) > > > The code-sequence is optimized away. > Another option would be "__attribute__((unused__))" > or removing the function. > > ------------------------------------------------------------------------ > > From b865b71aff3b8b9c43dffe93f8f0de874cccab53 Mon Sep 17 00:00:00 2001 > From: Detlef Riekenberg <wine.dev(a)web.de> > Date: Sun, 4 Nov 2007 12:58:39 +0100 > Subject: [PATCH] libs/wine: Avoid compiler warnings about unused parameter(-W) > --- > libs/wine/debug.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/libs/wine/debug.c b/libs/wine/debug.c > index 67cc172..5fc56e7 100644 > --- a/libs/wine/debug.c > +++ b/libs/wine/debug.c > @@ -261,6 +261,8 @@ static char *get_temp_buffer( size_t siz > static void release_temp_buffer( char *buffer, size_t size ) > { > /* don't bother doing anything */ > + buffer = buffer; > + size = size; That's just ugly. If removing the function is not an option leaving the function as is is the best approach. -W is the old name for the gcc argument; the new name for it is -Wextra which describes the warnings better: extra warnings; might be legit but can be bogus. > } bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: libs/wpp: Avoid compiler warnings (-W)
by Dan Hipschman 04 Nov '07

04 Nov '07

On Sun, Nov 04, 2007 at 01:04:02PM +0100, Detlef Riekenberg wrote: > > Why is the code only used, when "WANT_NEAR_INDICATION" is defined? > Should we remove the code or enable it always? > > @@ -591,18 +592,17 @@ static void generic_msg(const char *s, c > fprintf(stderr, "%s:%d:%d: %s: ", pp_status.input ? pp_status.input : "stdin", > pp_status.line_number, pp_status.char_number, t); > vfprintf(stderr, s, ap); > -#ifdef WANT_NEAR_INDICATION > + if(n) > { > +#ifdef WANT_NEAR_INDICATION > char *cpy, *p; > - if(n) > - { > - cpy = pp_xstrdup(n); > - for (p = cpy; *p; p++) if(!isprint(*p)) *p = ' '; > - fprintf(stderr, " near '%s'", cpy); > - free(cpy); > - } > - } > + > + cpy = pp_xstrdup(n); > + for (p = cpy; *p; p++) if(!isprint(*p)) *p = ' '; > + fprintf(stderr, " near '%s'", cpy); > + free(cpy); > #endif > + } > fprintf(stderr, "\n"); > } > Related, although not really a great solution: http://www.winehq.org/pipermail/wine-cvs/2006-September/026094.html I forget, are the extra "near" messages actually helpful, or misleading? In any case, whatever ends up happening here should probably also happen in widl, since it uses wpp and consistent warning/error messages are nice.

1 0

Wine 1.0 bugs, release criteria
by Dan Kegel 04 Nov '07

04 Nov '07

At Wineconf 2007, I was appointed to be the guy who decides (with Alexandre's approval) what bugs are 1.0 bugs and what aren't. So I've started adjusting the "Target Release" fields on a few bugs in Bugzilla. Over the next month or so, I'd like Wine developers to nominate important bugs for 1.0 by setting their "target release" field to 1.0. Later on we'll clean up and freeze the list somehow. Also, I've put together a draft wiki page with our 1.0 release criteria; it's at http://wiki.winehq.org/WineReleaseCriteria Comments? - Dan

9 13

shdocvw question
by Allan Tong 04 Nov '07

04 Nov '07

The attached patch should fix the crash in bug #6120, but I'm afraid I don't understand enough to know if the patch is correct or not. The code that the patch removes was setting the client site pointer to NULL. A later dereference on that pointer causes the crash. I guess I don't understand why the client site pointer is being explicitly set to NULL. Shouldn't Release handle that when the reference count reaches zero? - Allan

2 1

re: dlls/msi/streams.c -- simplify and constify
by Dan Kegel 03 Nov '07

03 Nov '07

James wrote: > This change is wrong. If you'd actually read what the code intended > to do instead of just fixing warnings, you'd see that > add_streams_to_table returns -1 on error. Yeah, Gerald, I was getting the feeling reading your patches that you were being too glib about rewriting code based simply on looking at signedness issues. Please be more careful. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: [PATCH 1/7] advapi32: Implement CredWriteW.
by Detlef Riekenberg 03 Nov '07

03 Nov '07

On Di, 2007-10-30 at 12:36 +0000, Robert Shearman wrote: > +static DWORD open_cred_mgr_key(HKEY *hkey, BOOL open_for_write) > +{ > + return RegCreateKeyExW(HKEY_CURRENT_USER, > wszCredentialManagerKey, 0, > + NULL, REG_OPTION_NON_VOLATILE, > + KEY_READ | KEY_WRITE, NULL, hkey, NULL); > +} > + What's the reason of the Parameter "BOOL open_for_write" ? open_cred_mgr_key is called with (..., TRUE) and (..., FALSE), but you always use "KEY_READ | KEY_WRITE". On the other hand, gcc does not warn about that unused Parameter. My first Idea was the optimizer in gcc, but removing "-O2" does not give us a warning. With "-pedantic", we lost (but still no warning for "open_for_write"). -- By by ... Detlef

2 2

Re: msxml - Fix Memory Leak
by Vitaliy Margolen 03 Nov '07

03 Nov '07

Not really. Now it's an attachment of "application/octet-stream" type. Not plain/text. Try renaming the file to *.patch.txt. Vitaliy. Alistair Leslie-Hughes wrote: > Hi Vitaliy, > > Thanks for the information, I though I had fixed my News client. > > Does this work better? Ill forward to the patch list if this works. > > Best Regards > Alistair > > > > > 00 > > From: wine-devel(a)kievinfo.com > > To: wine-devel(a)winehq.org > > CC: leslie_alistair(a)hotmail.com > > Subject: Re: msxml - Fix Memory Leak > > > > Alistair Leslie-Hughes wrote: > > > Hi, > > > > > > Changelog: > > > Fixed memory leak > > > > > > > > > Regards > > > Alistair Leslie-Hughes > > > > > > > > > begin 666 xmlelem.diff > > > > Please attach patches as a plain text. This patch is not an > attachment and > > is unreadable. > > > > Vitaliy. > >

1 0

re: USER32: win16 applications should not see long filenames returned from dialog control
by Dan Kegel 02 Nov '07

02 Nov '07

Alex wrote: > Legacy Win16 applications display file/directory selection listboxes and > expect to receive a short name from the control.... >The attached patch attempts to fix this >by converting the about-to-be-returned name to a short name if the expected >windows version is not at least Win95 How about converting to a short name in the win16 wrapper code instead?

1 0

Re: mshtml: Set IE version when installing wine gecko
by Jacek Caban 02 Nov '07

02 Nov '07

Hi Chris, This patch is already committed, but, I'm afraid, it's wrong. Setting these registries has nothing to do with installing Gecko. Setting them in Gecko installer will only make supporting it harder. We don't want to tell user to "run iexplore about:blank" to get an app working. I will send a better patch that always sets them. Last time Alexandre didn't accept such a patch, because of apps that need native IE and install it only when this key is not found. It looks like it's time for such change. Thanks, Jacek

4 8

Generic text printer driver
by Juan Luis Ramos 02 Nov '07

02 Nov '07

Hi all, is there anybody working in the generic text printer driver o raw printer driver? I've a problem with a compatible Epson POS printer so, I've modified the text.c code inside wineps.drv to send the text to the printer without postscript processing. The function that send the data is PSDRV_ExtTextOut, but the LPCWSTR parameter passed (str) doesn't contain the ESCAPE codes sent to the printer. I don't find when does the program call the PSDRV_ExtTextOut function. Can anybody help me? Thanks.

2 1

Re: [PATCH 07/18] inetcomm: Add an implementation of an SMTP transport.
by Juan Lang 02 Nov '07

02 Nov '07

Hi Rob, + const char szHostName[] = "roblaptop"; /* FIXME */ Did you mean to leave that in? --Juan

3 2

Re: Fix type of loop variable in alloc_device().
by Vitaliy Margolen 02 Nov '07

02 Nov '07

Gerald Pfeifer wrote: > We iterate between 0 and and the value of an usigned variable, so we > should adjust the loop variable accordingly (not the list to silence > GCC). > - int i; > + unsigned i; If there is nothing wrong about it, then why do you change it? If even gcc does not complain about it. Vitaliy.

2 1

Re: [Bug 10266] Numpad keyboard handling is strange, Del key produces two events
by Peter Åstrand 02 Nov '07

02 Nov '07

Perhaps we need to gather more input from other developers: > http://bugs.winehq.org/show_bug.cgi?id=10266 > > --- Comment #4 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2007-11-01 08:32:46 --- > > But in that case, you will find all of your X11 applications on your desktop, > > including Firefox etc, confusing as well? > > Yes, and this behaviour is very annoying and not consistent IMO. Let's break down this statement into two: 1) "Not consistent" It might be interesting to compare with CapsLock. Shift can cancel CapsLock, but also substitute it. This is true on both Windows and Linux. Additionally, on Linux, NumLock works the same, ie Shift works in both directions. On Windows, however, Shift can only cancel NumLock, not substitute it. Regardless of whether users actually finds this useful or not, I think it's hard to argue for that this is "logical" or "consistent". 2) "Annoying" Can it be that you have a Windows background and are therefore used to the Windows behaviour? I haven't actually asked any users yet, but my general opinion is that all applications on the same desktop should behave the same, if possible. We are decorating the Windows windows with the normal window manager decorations etc so I think it's reasonable that the keyboard should behave according to the native system model. Another thing to keep in mind is that most users actually never use the numpad keys in conjunction with Shift. I know this from several years of experience of keyboard hacking - there have been plenty of bugs in many softwares in this area but very few actual bug reports. > Besides, I just tested with Wine's notepad and don't see the problem you > are reporting. Which keyboard layout are you using? On my system, Wine selects the Swedish keyboard layout. Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

2 5

Re: [PATCH 04/18] inetcomm: Add self-registration code.
by Paul Vriens 02 Nov '07

02 Nov '07

Robert Shearman wrote: > --- +static LONG recursive_delete_key(HKEY key); +static LONG recursive_delete_keyA(HKEY base, char const *name); +static LONG recursive_delete_keyW(HKEY base, WCHAR const *name); We just got rid of all the self build recursive delete ones. Can you use RegDeleteTree[AW] (or is there a specific reason not to)? -- Cheers, Paul.

3 2

Re: msxml - Fix Memory Leak
by Vitaliy Margolen 02 Nov '07

02 Nov '07

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > Fixed memory leak > > > Regards > Alistair Leslie-Hughes > > > begin 666 xmlelem.diff Please attach patches as a plain text. This patch is not an attachment and is unreadable. Vitaliy.

1 0

Re: shell32: Use SHStrDupW in IShellFolder2::GetDetailsOf to allocate returned string
by Vitaliy Margolen 02 Nov '07

02 Nov '07

Thomas Weidenmueller wrote: > Use SHStrDupW in IShellFolder2::GetDetailsOf to allocate the returned > string. pOleStr in the STRRET structure has to be allocated using > CoTaskMemAlloc(). SHStrDupW uses CoTaskMemAlloc() whereas StrDupW uses > LocalAlloc(). > > - Thomas > ------------------------------------------------------------------------ > > Index: recyclebin.c > =================================================================== > RCS file: /home/wine/wine/dlls/shell32/recyclebin.c,v > retrieving revision 1.5 > diff -u -r1.5 recyclebin.c > --- recyclebin.c 11 Jun 2007 13:47:57 -0000 1.5 > +++ recyclebin.c 1 Nov 2007 21:58:30 -0000 Please diff it from the top of the source tree. The above should say dlls/shell32/recyclebin.c Vitaliy.

1 0

Re: [PATCH 02/18] inetcomm: Add a framework for connecting to a server and sending/receiving data asynchronously with callbacks being called in the context of the original thread, using window messages.
by Alexandre Julliard 02 Nov '07

02 Nov '07

Robert Shearman <rob(a)codeweavers.com> writes: > +#include "winsock2.h" > +#include "winuser.h" > + > +#undef GetProp > +#undef SendMessage > +#undef SetProp > + > +#include "objbase.h" > +#include "imnxport.h" You forgot to submit the new imnxport.idl. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: setupapi: Add stub for SetupInstallServicesFromInfSectionW
by Robert Shearman 02 Nov '07

02 Nov '07

Chris Robinson wrote: > @ stdcall SetupInstallFromInfSectionA(long long str long long str long ptr ptr long ptr) > @ stdcall SetupInstallFromInfSectionW(long long wstr long long wstr long ptr ptr long ptr) > @ stdcall SetupInstallServicesFromInfSectionA(long str long) > +@ stdcall SetupInstallServicesFromInfSectionW(long wstr long) > @ stub SetupInstallServicesFromInfSectionExA > @ stub SetupInstallServicesFromInfSectionExW > -@ stub SetupInstallServicesFromInfSectionW > @ stdcall SetupIterateCabinetA(str long ptr ptr) > @ stdcall SetupIterateCabinetW(wstr long ptr ptr) > @ stub SetupLogErrorA > There's no need to move the entry for SetupInstallServicesFromInfSectionW. The list was sorted alphabetically, but now it isn't. -- Rob Shearman

3 2

Valgrind and structs with holes
by Dan Kegel 02 Nov '07

02 Nov '07

Valgrind is a great tool, but if there's a struct with a hole in it, and we write that struct to a socket (say, to send it to the server), valgrind will likely complain that the hole is uninitialized. For instance, the warning ==3415== Syscall param writev(vector[1]) points to uninitialised byte(s) ==3415== at 0x40007F2: (within /lib/ld-2.6.1.so) ==3415== by 0x4412E24: wine_server_call (server.c:244) ==3415== by 0x43EBA73: server_ioctl_file (file.c:1010) ==3415== by 0x43EC570: NtFsControlFile (file.c:1223) ==3415== by 0x45394C1: WaitNamedPipeW (sync.c:1298) ==3415== by 0x453963B: WaitNamedPipeA (sync.c:1225) ==3415== by 0x46490B5: test_CreateNamedPipe (pipe.c:97) in kernel32/tests/sync.c can be silenced either by appeasing Valgrind with a patch like --- a/dlls/kernel32/sync.c +++ b/dlls/kernel32/sync.c @@ -1285,6 +1285,12 @@ BOOL WINAPI WaitNamedPipeW (LPCWSTR name, DWORD nTimeOut) return FALSE; } + /* FILE_PIPE_WAIT_FOR_BUFFER has a hole after boolean TimeoutSpecified. + * Clear the hole so valgrind doesn't get upset about uninitialized bytes. + * No need to zero Name[1...], which is initialized ok later. + */ + memset(pipe_wait, 0, sizeof(FILE_PIPE_WAIT_FOR_BUFFER)); or by using a suppression like { wine_struct_hole_FILE_PIPE_WAIT_FOR_BUFFER Memcheck:Param writev(vector[1]) obj:* fun:wine_server_call fun:server_ioctl_file fun:NtFsControlFile fun:WaitNamedPipeW } Alexandre, which approach would you prefer? If you say #1, I'll eat my hat. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Exception but not when running with +relay
by Paul Vriens 02 Nov '07

02 Nov '07

Hi, I just tried the latest PE Explorer (http://www.heaventools.com/download-pe-explorer.htm). When I stopped the application I ran into an exception within NtSetInformationThread. If I however do a +relay I don't get into this exception. What does such a difference point to? -- Cheers, Paul.

1 0

valgrind results online
by Dan Kegel 02 Nov '07

02 Nov '07

I've posted results from running the entire conformance test suit under Valgrind at http://kegel.com/wine/valgrind/20071001/ There are 100 files there; one for each test that had warnings. (And one more file with everything concatenated together, http://kegel.com/wine/valgrind/20071001/vg-all.txt) A lot of the warnings are probably just problems in our conformance tests, not in Wine, and several of the warnings might be problems in Valgrind. But I wouldn't be surprised if there were several dozen real problems in Wine, so please take a look. (Juan has already submitted a bunch of cleanups for crypt32. I'll probably run these tests daily for a while and upload the results to a new directory for each day.) I've also updated the instructions on how to run tests under Valgrind, http://wiki.winehq.org/Wine_and_Valgrind and updated the Wine patch there to include a bunch more suppressions. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Dead code in dlls/ntdll/tape.c
by Gerald Pfeifer 01 Nov '07

01 Nov '07

We currently have the following code in tape.c: if (data->Offset.u.LowPart >= 0) { cmd.mt_op = MTFSF; cmd.mt_count = data->Offset.u.LowPart; } else { cmd.mt_op = MTBSF; cmd.mt_count = -data->Offset.u.LowPart; } data is of type TAPE_SET_POSITION*, which in turn is defined as typedef struct _TAPE_SET_POSITION { ULONG Method; ULONG Partition; LARGE_INTEGER Offset; BOOLEAN Immediate; } TAPE_SET_POSITION, *PTAPE_SET_POSITION; Offset is of type LARGE_INTEGER which is defined as struct { DWORD LowPart; LONG HighPart; } u; Note how LowPart is unsigned (DWORD) here, so indeed the comparisons for >= 0 is always going to evaluate to true. Hans, I believe you originally wrote that code. Do you remember what you where trying to do here? The patch below removes this dead code and is equivalent to what we currently have. I am not sure it is the desired way to fix what I describe above, though. Gerald Index: dlls/ntdll/tape.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/tape.c,v retrieving revision 1.16 diff -u -3 -p -r1.16 tape.c --- dlls/ntdll/tape.c 26 Jun 2007 12:14:34 -0000 1.16 +++ dlls/ntdll/tape.c 1 Nov 2007 16:32:29 -0000 @@ -427,25 +427,13 @@ static NTSTATUS TAPE_SetPosition( int fd break; #endif case TAPE_SPACE_FILEMARKS: - if (data->Offset.u.LowPart >= 0) { - cmd.mt_op = MTFSF; - cmd.mt_count = data->Offset.u.LowPart; - } - else { - cmd.mt_op = MTBSF; - cmd.mt_count = -data->Offset.u.LowPart; - } + cmd.mt_op = MTFSF; + cmd.mt_count = data->Offset.u.LowPart; break; #if defined(MTFSS) && defined(MTBSS) case TAPE_SPACE_SETMARKS: - if (data->Offset.u.LowPart >= 0) { - cmd.mt_op = MTFSS; - cmd.mt_count = data->Offset.u.LowPart; - } - else { - cmd.mt_op = MTBSS; - cmd.mt_count = -data->Offset.u.LowPart; - } + cmd.mt_op = MTFSS; + cmd.mt_count = data->Offset.u.LowPart; break; #endif case TAPE_LOGICAL_BLOCK:

3 2

Wine Gecko packaging
by Jacek Caban 01 Nov '07

01 Nov '07

Hello, As you probably have noticed, downloading Gecko on first use confuses users. Now, with last week patches, there is an other way to do it, transparent for users. MSHTML code looks for cab file in $data_dir/gecko (that is usually /usr/share/wine/gecko). Alternatively, if you run Wine from build dir, it looks for $build_dir/../gecko. Wine checks it both in wineprefixcreate and, if Gecko is not installed, on first usage. It means that if you download wine_gecko-0.1.0.cab from SourceForge and put it in the right place, you will no longer have to care about installing Gecko. Now, it's time to consider Linux packages to simplify its use. In Gentoo it may be a separate USE flag, but for other distributions that don't support such things, we'll need a separate package. Such package will need only one file placed in the right place, so it should be easy to do and maintain (I don't expect versions to change often). Are Wine packagers interested in creating Gecko packages? Thanks, Jacek

4 6

iexplore proxy server
by Luke Bratch 01 Nov '07

01 Nov '07

Hello Is there supposed to be a way to set a HTTP (or otherwise) proxy server in Wine's iexplore at the moment? I can't find any such documentation, but searching around has found a lot of people suggesting that setting these keys will help: [Software\\Microsoft\\Windows\\CurrentVersion\\Internet Settings] "ProxyEnable"=dword:00000001 "ProxyServer"="proxyserver:8080" Setting those didn't make any difference in iexplore, but the attached patch which edits a file that the Gecko installer creates, makes HTTP proxy support work perfectly. Is this the correct/only way to do this? Thanks Luke Bratch ___________________________________________________________ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/

2 1

Cleanup of riched20 tests - request for help on test_WM_PASTE
by Alex Villacís Lasso 01 Nov '07

01 Nov '07

I am currently trying to clean up the riched20 tests that are failing in WinXP. While doing this, I have encountered the following problem: on the function test_WM_PASTE() (at line 1959 of dlls/riched20/tests/editor.c in current git), the test is supposed to feed simulated keystrokes corresponding to Ctrl-C, Ctrl-V, and so on, supposedly to test copy and paste features via the keyboard. The problem is that the verification at line 1989 fails on WinXP, because the text on the control has not been modified - the control seems to disregard simulated WM_CHAR messages of the Ctrl-<keystroke> variety. The test at line 1977 succeeds accidentally, because the sequence of Ctrl-C, Ctrl-V, Ctrl-Z that is being tested is equivalent to not modifying the control text at all. A more through test would be to send WM_GETTEXT messages after each step to ensure that the text is actually being modified, but the bigger problem is how to make the control obey the keystrokes in the first place. If I place a message loop right before the DestroyWindow() call, I can send keystrokes manually and they work as expected. Only simulated WM_CHAR messages are being discarded. I have tried changing the SendMessage() calls into PostMessage() calls (since Visual Studio's Spy++ shows that WM_CHAR messages were posted, not sent), but to no avail. I have also tried placing message loops between messages, with no luck. I have even tried to simulate the WM_KEYDOWN and WM_KEYUP messages with parameters exactly as seen by Spy++, but this does not work either. So I am asking for help. What could be going wrong with this test? How can I feed the expected keystrokes so that the test works as expected? Has this test ever worked before? It fails in both WinXP (real machine) and inside a QEMU session running Win98. (All tests on WinXP were compiled with CygWin) -- perl -e '$x=2.4;print sprintf("%.0f + %.0f = %.0f\n",$x,$x,$x+$x);'

1 1

Re: Make test drill, next steps, call for help with Winetest
by Hans Leidekker 01 Nov '07

01 Nov '07

I have written attached script to facilitate automated winetest runs. It needs a VirtualBox virtual machine with either Windows or a Wine platform configured to run autorun.inf files. The script downloads the latest winetest binary and puts it in an iso image, along with an autorun file to trigger its execution when the image is 'inserted' into the virtual drive. A snapshot is used to revert the vm to its original state, so no need to worry about winetest screwing up your installation. -Hans #!/bin/bash if [ $# -lt 2 ]; then echo "Usage: $0 <vmname> <tag>" echo "" echo "vmname: Virtual machine to use (must be in suspended state). echo "tag: Tag built from [-.0-9a-zA-Z] to identify test report. exit 1 fi TMPDIR=/tmp/winetest$$ LOGFILE=$TMPDIR/log mkdir -p $TMPDIR/master echo "downloading winetest binary" wget -P $TMPDIR http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi mv $TMPDIR/winetest-latest.exe $TMPDIR/master/winetest.exe echo "creating autorun.inf" cat > $TMPDIR/master/autorun.inf <<_EOF_ [autorun] open=winetest.exe -q -t $2 _EOF_ echo "creating cd image" mkisofs -o $TMPDIR/winetest.iso $TMPDIR/master >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi echo "checking vm $1 state" VBoxManage showvminfo $1 | grep "^State:" | grep "saved" >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi echo "creating snapshot for vm $1" VBoxManage snapshot $1 take before-winetest >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi echo "starting vm $1" VBoxManage startvm $1 >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi echo "waiting until vm $1 is up and running" RUNNING="false" while [ $RUNNING != "true" ] do VBoxManage showvminfo $1 | grep "^State:" | grep "running" >> $LOGFILE 2>&1 if [ $? -eq 0 ]; then RUNNING="true" fi sleep 1 done echo "attaching cd image to vm $1" VBoxManage controlvm $1 dvdattach $TMPDIR/winetest.iso >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi echo "sleeping while vm $1 runs winetest" sleep 1800 # 30 minutes should be enough for winetest to finish echo "suspending vm $1" VBoxManage controlvm $1 savestate >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi echo "waiting until vm $1 is suspended" SAVED="false" while [ $SAVED != "true" ] do VBoxManage showvminfo $1 | grep "^State:" | grep "saved" >> $LOGFILE 2>&1 if [ $? -eq 0 ]; then SAVED="true" fi sleep 1 done echo "reverting vm $1 to previous state" VBoxManage snapshot $1 discardcurrent -all >> $LOGFILE 2>&1 if [ $? -ne 0 ]; then exit 1 fi rm -rf $TMPDIR exit 0

5 10

Bug in dlls/oleaut32/tests/vartype.c?
by Gerald Pfeifer 01 Nov '07

01 Nov '07

dlls/oleaut32/tests/vartype.c has the following snippet of code: + f = -1e-400; /* deliberately cause underflow */ + hres = pVarBstrFromR4(f, lcid, 0, &bstr); + ok(hres == S_OK, "got hres 0x%08lx\n", hres); + if (bstr) + { + todo_wine ok(memcmp(bstr, szZero, sizeof(szZero)) == 0, "negative zero (got %s)\n", wtoascii(bstr)); + } which was added in revision 1.27 Alex Villacís Lasso <a_villacis(a)palosanto.com> Test for behavior of negative underflow formatting. This doesn't seem to work as intended, because it is a floating point *constant* which current versions of GCC simply truncate to 0.0. Gerald -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 3

New DLL, Server and Service Documentation
by Roy Shea 01 Nov '07

01 Nov '07

Howdy All, This autumn I began learning both Wine and COM. A combination of limited documentation and trouble finding the right example code for my task at hand made this a difficult process. In an attempt to help other new Wine and COM developers I wrote a tutorial on COM development the Wine way. This tutorial describes: - A simple DLL providing a in-process COM object - A simple server providing a local COM object - A simple service that publishes a COM object and the corresponding proxy / stub required to use the service with instructions on Wine integration and, for Windows users or testers building for Windows, basic instructions on building and running these same applications in Windows. The tutorial is available at: http://ambleramble.org/wine/ I hope other developers enjoy this documentation. If you see mistakes, either minor typos or conceptual problems, please drop me an email and I'll clean up the docs. Peace, -Roy

2 1

Re: wined3d: Enable clip planes with GLSL shader backend
by Ivan Gyurdiev 01 Nov '07

01 Nov '07

> + if (use_vs(stateblock->wineD3DDevice) && stateblock->wineD3DDevice->vs_selected_mode == SHADER_ARB) GLSL specific logic should go in glsl_shader.c. Please try to get away from writing code in terms of flags and if statements - use the OOP model. Backend-specific logic should be removed from pixelshader and vertexshader too...

2 1

Re: wined3d: Enable clip planes with GLSL shader backend
by Stefan Dösinger 31 Oct '07

31 Oct '07

Am Mittwoch, 31. Oktober 2007 18:50:32 schrieb Fabian Bieler: > - glMatrixMode(GL_MODELVIEW); > - glPushMatrix(); > - glLoadMatrixf((float *) > &stateblock->transforms[WINED3DTS_VIEW].u.m[0][0]); + > if(!use_vs(stateblock->wineD3DDevice)) { > + /* Clip Plane settings are affected by the model view in OpenGL, > the View transform in direct3d */ + glMatrixMode(GL_MODELVIEW); > + glPushMatrix(); > + glLoadMatrixf((float *) > &stateblock->transforms[WINED3DTS_VIEW].u.m[0][0]); + } Isn't this going to cause problems with the glPopMatrix afterwards?

1 0

Tips needed for debugging Skype on Wine (Access violation)
by Paul Vriens 31 Oct '07

31 Oct '07

Hi, I'm trying to get Skype 3.5.0.39 running on Wine (latest Git). The app however throws an 'Access violation at address 00593AD1 in module "Skype.exe". Read of address FFFFFFFF'. I've set set the version to XP. I do find that when I apply this "patch": diff --git a/dlls/kernel32/process.c b/dlls/kernel32/process.c index a08235a..d4349d7 100644 --- a/dlls/kernel32/process.c +++ b/dlls/kernel32/process.c @@ -2819,7 +2819,7 @@ BOOL WINAPI IsWow64Process(HANDLE hProcess, PBOOL Wow64Process) { FIXME("(%p %p) stub!\n", hProcess, Wow64Process); *Wow64Process = FALSE; - return TRUE; + return FALSE; } the application has no issues starting up (several other issues remain). Is this an exception that Windows catches and we don't perhaps? The application runs fine on my Windows XP box. Tried to use several debugchannels but to no avail. -- Cheers, Paul.

3 5

Convincing Valgrind to give a stack dump?
by Dan Kegel 31 Oct '07

31 Oct '07

Looking at the app in bug 10125, using warn+heap, I saw a few of those scary-but-sometimes-harmless warnings, so I thought I'd give it a shot under Valgrind. After applying enough suppressions, I did find three interesting valgrind warnings: 10 errors in context 5 of 9: Conditional jump or move depends on uninitialised value(s) at 0x477F7F6: RedrawWindow (painting.c:612) 29 errors in context 7 of 9: Conditional jump or move depends on uninitialised value(s) at 0x43E4E6D: HEAP_ValidateInUseArena (heap.c:917) 184 errors in context 9 of 9: Conditional jump or move depends on uninitialised value(s) at 0x61F3CD0: XcursorImageHash (in /usr/lib/libXcursor.so.1.0.2) The commandline I used was WINEDEBUG=+process valgrind -v --error-limit=no --trace-children=yes --suppressions=$HOME/suppressions ~/wine-git/wine Olb.exe (+process was used to show that the errors in question did indeed come from olb.exe and not something it launched.) But I couldn't coax Valgrind into giving stack dumps for those errors; it acted as if it had seen a few too many errors first, and only showed the one line. Grr. Anyone know how to coax valgrind into always giving a good stack dump? - Dan

2 2

Re: cabinet: fully initialize structs in FCICreate() and FCIAddFile()
by Alexandre Julliard 31 Oct '07

31 Oct '07

"Dan Kegel" <dank(a)kegel.com> writes: > Rather than hunt it down precisely, I applied > the old "memset the struct to zero when allocating" > meme, which in some circles is considered the "right" > way to avoid this kind of problem. (I halfway expect > Alexandre to say "don't be so lazy", but it's worth a try.) Don't be so lazy. ;-) -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Changes default socket behavior for WSASendTo function from overlapped to non-overlapped
by Alexandre Julliard 31 Oct '07

31 Oct '07

yurtk(a)mail15.com writes: > diff --git a/dlls/ws2_32/socket.c b/dlls/ws2_32/socket.c > index 24a4a76..3697746 100644 > --- a/dlls/ws2_32/socket.c > +++ b/dlls/ws2_32/socket.c > @@ -2662,7 +2662,8 @@ INT WINAPI WSASendTo( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, > goto error; > } > > - if ((lpOverlapped || lpCompletionRoutine) && > + /* If no options specified, the socket assumed to be non-overlapped*/ > + if (options && (lpOverlapped || lpCompletionRoutine) && > !(options & (FILE_SYNCHRONOUS_IO_ALERT | FILE_SYNCHRONOUS_IO_NONALERT))) > { This is wrong, it will make all sockets non-overlapped. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11drv: Initialize real default mode in xrandr and xvidmode backends
by Chris Robinson 31 Oct '07

31 Oct '07

On Tuesday 30 October 2007 10:47:34 pm Dmitry Timoshkov wrote: > - X11DRV_Settings_SetDefaultMode(0); > + > + default_mode = X11DRV_XRandR_GetCurrentMode(); > + TRACE("default mode: %d\n", default_mode); > + X11DRV_Settings_SetDefaultMode(default_mode); This has been brought up on IRC before, and I believe the concensus was you can't rely on the current mode when starting the app because there's no way to tell if the current mode is the default or something another app set. As far as XRandR is concerned, mode 0 is always the default, but the desktop manager can set a different mode per user on login. The way to fix this would be to get some way to query the desktop manager for the default mode, or to extend XRandR to be able to change and report different defaults. Neither of which is possible right now.

2 1

advapi32: fix buffer overrun in tests/registry.c:wine_debugstr_wn(), try 2
by Dan Kegel 31 Oct '07

31 Oct '07

OK, my last try was ugly and deserved to be dropped. This one is a one-bit change, and easier to understand. Fixes an off-by-one buffer overflow in wine_debugstr_wn() in which the wchar after the end of the buffer was read.

1 0

Compile error with current git
by Paul Vriens 30 Oct '07

30 Oct '07

Hi, Compiling gives (for me): [paul@penguin wine-git]$ cd /wine/wine-git/dlls/ntdll/ [paul@penguin ntdll]$ make depend && make ../../tools/makedep -C. -S../.. -T../.. actctx.c atom.c cdrom.c critsection.c debugbuffer.c debugtools.c directory.c env.c error.c exception.c file.c handletable.c heap.c large_int.c loader.c loadorder.c misc.c nt.c om.c path.c process.c reg.c relay.c resource.c rtl.c rtlbitmap.c rtlstr.c sec.c serial.c server.c signal_i386.c signal_powerpc.c signal_sparc.c signal_x86_64.c string.c sync.c tape.c thread.c threadpool.c time.c version.c virtual.c wcstring.c version.rc gcc -m32 -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_NTSYSTEM_ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -Wcast-qual -o file.o file.c file.c: In function ‘NtCreateFile’: file.c:199: error: ‘struct object_attributes’ has no member named ‘name_len’ make: *** [file.o] Error 1 This is after commit 5f5df83281a48df7746ff263b5047cffe4c3c1fa I guess. -- Cheers, Paul.

1 1

re: tools/widl/typegen.c pointer initialization
by Dan Kegel 30 Oct '07

30 Oct '07

Dan H. wrote: > If you tell me what options you build with and I can reproduce the > warning then I'll be more than happy to try to fix it. I build widl > with -W -Wall and get two warnings. To get uninitialized warnings, you have to also specify optimization (-O2). Without -O, gcc doesn't do the analysis that can detect uninitialized variables. - Dan

3 2

New Wine help and discussion forum
by Tom Wickline 30 Oct '07

30 Oct '07

Hello, There is a new Wine help and discussion forum at http://www.wine-forum.org/index.php that is meant to be a meeting place for anyone interested in Wine usage or development. In the past there there has never been a single forum dedicated solely to Wine. The lack of a single forum has left people to post Wine related help and discussions in other forums. At the moment most users turn to their Linux distribution forum where Wine is often a sub-forum at most and questions often go unanswered. My goal is to provide a forum to bring Wine users together into a single meeting place to discuss anything relevant to the daily happenings surrounding Wine. There are multiple categories/subforums to cover all aspects of using Wine (Applications, Games, 3rd Party Wine Utilities, Commercial Offerings, etc.). Cheers, Tom Wickline

8 9

Re: ntdll: RtlCreateAcl: initialize all the bytes passed by the user
by Alexandre Julliard 30 Oct '07

30 Oct '07

"Dan Kegel" <dank(a)kegel.com> writes: > Without this patch, NtAccessCheck() references uninitialized > memory (it seems to send the entire ACL with the user's > length to the server, not just sizeof(ACL)). This showed up as > valgrind errors when running "make test" in advapi32. > I suppose the right fix might be to send just sizeof(ACL) bytes > to the server, but I wouldn't know, and initializing all > the bytes given by the caller seems innocuous enough. It isn't innocuous, if Windows doesn't do it then it's quite likely that apps will pass a too large size, we've had that kind of problem in some other places already. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [Resubmit]: Added wrapper dll for ct-api(CardTerminal API)
by Alexandre Julliard 30 Oct '07

30 Oct '07

"Christian Eggers" <ceggers(a)gmx.de> writes: > + /* Try to get name of low level library from registry */ > + /* UNICODE functions are not used here, because the final string is needed as ANSI */ Actually the final string should be in the Unix codepage, so you have to load it using Unicode and then convert to CP_UNIXCP. > + result = RegOpenKeyExA(HKEY_CURRENT_USER, "Software\\Wine\\DllWrappers", 0, KEY_READ, &key_handle); The key should go under Software\\Wine\\ctapi32, I don't think there's a need to add a generic mechanism here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Missing region invalidation in edit control
by Peter Åstrand 30 Oct '07

30 Oct '07

It seems like there's a missing region invalidation in the edit control somewhere; the background is not correctly updated, unless the window is moved or exposed to X11 exposes. See screenshot at http://www.cendio.com/~astrand/wine/46-textedit-color/nopaint.png. In this case, xclock has been dragged over the edit control area, which is then correctly painted white. Any ideas? Regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

1 1

Re: widl: Add a --local-stubs option.
by Robert Shearman 30 Oct '07

30 Oct '07

Dan Hipschman wrote: > + write_type_decl_left(fp, mdef->type); > + fprintf(fp, " CALLBACK %s_", iface->name); > + write_name(fp, mdef); > + fprintf(fp, "_Proxy(\n"); > + write_args(fp, m->args, iface->name, 1, TRUE); > + fprintf(fp, ")"); > + if (body) { > + type_t *rt = mdef->type; > + fprintf(fp, "\n{\n"); > + fprintf(fp, " %s\n", comment); > + if (rt->name && strcmp(rt->name, "HRESULT") == 0) > + fprintf(fp, " return E_FAIL;\n"); > > It would be better to make the default implementation of the stubs return E_NOTIMPL instead of E_FAIL, since the former is a lot more specific and makes identifying the source of misbehaviour of an application easier. -- Rob Shearman

1 0

Re: oleaut32 [3/10]: Add a proxy for objidl.
by Robert Shearman 30 Oct '07

30 Oct '07

Dan Hipschman wrote: > This adds the objidl proxy to oleaut32. It also updates DllGetClassObject > to fall back on OLEAUTPS_DllGetClassObject. This is basically what would > happen if we had a dlldata.c file for oleaut32, but that's impossible > since oleaut32 is too special a case. > > --- > .gitignore | 2 ++ > dlls/oleaut32/Makefile.in | 3 ++- > dlls/oleaut32/oleaut.c | 3 +-- > dlls/oleaut32/oleaut32_objidl.idl | 25 +++++++++++++++++++++++++ > dlls/oleaut32/usrmarshal.c | 2 ++ > 5 files changed, 32 insertions(+), 3 deletions(-) > create mode 100644 dlls/oleaut32/oleaut32_objidl.idl > This should be implemented in ole32.dll, not oleaut32.dll, as should unknwn.idl and oleidl.idl. -- Rob Shearman

1 0

Re: New Wine help and discussion forum
by Dan Kegel 30 Oct '07

30 Oct '07

[Hmm, I thought you wanted to take the discussion offlist, but I see you forwarded to the list. Here's a catchup message.] On 10/29/07, Dan Kegel <dank06(a)kegel.com> wrote: > On 10/29/07, Tom Wickline <twickline(a)gmail.com> wrote: > > > My stated goal is to not increase the number of > > > discussion forums / mailing lists, yet still appeal > > > to the "I hate email" generation. I think the > > > google groups front end for the existing mailing > > > list comes pretty close to that... > > > > So your goal is to have a single point for discussion? > > No, my goal is simply to not make the situation worse. [There were more messages after that. Here's the key bit:] Tom wrote: > Whats so bad about both Google groups and a forum? If you try to pull > as many people as you can toward the groups and I do the same for the > forum. then if we get 90% of the discussion on two groups its better > then what the situation was yesterday... do you agree with that? I replied: Having one more forum dilutes the community. ... > If you try to pull > as many people as you can toward the groups and I do the same for the > forum. then if we get 90% of the discussion on two groups its better > then what the situation was yesterday... do you agree with that? Not really. That said, I can see your vision, and I agree there is some small chance it might succeed and improve the situation. The real issues are mixed up with a culture war (email vs. forum), which makes the discussion a bit murky. C'est la vie. - Dan

1 0

Trying to submit my first patch
by crwulff＠rochester.rr.com 29 Oct '07

29 Oct '07

So I tried to submit a patch (to the patch mailing list) a few days ago and got no response (or acceptance), so I'm guessing I need to do something different. It is just a few simple stubs for functions needed to get RO2 (a game) running. The original email is attached. If anyone could tell me what I did wrong it would be appreciated. I'm guessing either because (a) I actually changed the Changelog file and included that in the patch instead of putting it in the email body or (b) nobody is interested in just stubs and I should work on coding them up more (even though it isn't necessary to get the game running.) -- Chris Wulff

2 2

opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
by Alex Romosan 29 Oct '07

29 Oct '07

somewhere between release 0.9.46 and 0.9.47 of wine i started having problems with applications that use opengl. using git-bisect i found that commit 00633e37bcc8da1032f34ea2d87814739de07db4 (winex11: Use an offscreen redirected window for child OpenGL rendering.) was the first bad commit. in particular i am trying to run tracked part of racer 0.5.0 final (http://racer.nl/dl_win32.htm). doing a git-checkout 00633e37bcc8da1032f34ea2d87814739de07db4 and running tracked i get the following crash when i try to import a track: wine: Unhandled page fault on read access to 0x00000014 at address 0x7e542141 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000014 in 32-bit code (0x7e542141). fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:7e542141 ESP:0033fdb4 EBP:0033fdec EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:7e578714 ECX:0000494c EDX:00000000 ESI:00000001 EDI:0014da98 Stack dump: 0x0033fdb4: 00000000 00000000 000000aa 0000001e 0x0033fdc4: 0041fa7d 00000049 00000000 00000000 0x0033fdd4: 0014da98 0042567c 004256b5 7ed1f980 0x0033fde4: 00000001 0014da98 0033fe0c 7ed072db 0x0033fdf4: 0033fe60 00443457 ffffffff 00408fa0 0x0033fe04: 7ed07299 00000000 0033ff08 0041b192 Backtrace: =>1 0x7e542141 X11DRV_wglFlush+0x31() [/home/romosan/cvs/wine/dlls/winex11.drv/opengl.c:1952] in winex11 (0x0033fdec) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) 2 0x7ed072db wine_glFlush+0x4b() [/home/romosan/cvs/wine/dlls/opengl32/wgl.c:584] in opengl32 (0x0033fe0c) 3 0x0041b192 in tracked (+0x1b192) (0x0033ff08) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) 4 0x7ee5809e start_process+0xee(arg=0x0) [/home/romosan/cvs/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8) 5 0xb7e7f867 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x7e542141 X11DRV_wglFlush+0x31 [/home/romosan/cvs/wine/dlls/winex11.drv/opengl.c:1952] in winex11: movl 0x14(%eax),%edi 1952 update_drawable(((Wine_GLContext*)NtCurrentTeb()->glContext)->physDev); Modules: Module Address Debug info Name (77 modules) PE 400000- 457000 Export tracked PE 10000000-1007d000 Deferred fmod PE 65f00000-65fc2000 Deferred ole32 ELF 7aaf3000-7ab3c000 Deferred dsound<elf> \-PE 7ab00000-7ab3c000 \ dsound ELF 7b95a000-7ba20000 Deferred libasound.so.2 ELF 7bf00000-7bf03000 Deferred <wine-loader> ELF 7bf43000-7bf58000 Deferred midimap<elf> \-PE 7bf50000-7bf58000 \ midimap ELF 7bf58000-7bf70000 Deferred msacm32<elf> \-PE 7bf60000-7bf70000 \ msacm32 ELF 7bf70000-7bfa6000 Deferred winealsa<elf> \-PE 7bf80000-7bfa6000 \ winealsa ELF 7bfa6000-7bfab000 Deferred libtxc_dxtn.so ELF 7bfba000-7bfc3000 Deferred libxcursor.so.1 ELF 7bfc3000-7bfcb000 Deferred libxrender.so.1 ELF 7bfcb000-7bfe8000 Deferred imm32<elf> \-PE 7bfd0000-7bfe8000 \ imm32 ELF 7bfe8000-7bfeb000 Deferred libxinerama.so.1 ELF 7c080000-7c083000 Deferred libxcomposite.so.1 ELF 7e294000-7e4ef000 Deferred r200_dri.so ELF 7e4ef000-7e580000 Dwarf winex11<elf> \-PE 7e500000-7e580000 \ winex11 ELF 7e5cc000-7e5ec000 Deferred libexpat.so.1 ELF 7e5ec000-7e615000 Deferred libfontconfig.so.1 ELF 7e615000-7e62a000 Deferred libz.so.1 ELF 7e62a000-7e699000 Deferred libfreetype.so.6 ELF 7e699000-7e701000 Deferred msvcrt<elf> \-PE 7e6b0000-7e701000 \ msvcrt ELF 7e701000-7e78f000 Deferred winmm<elf> \-PE 7e710000-7e78f000 \ winmm ELF 7e78f000-7e7b5000 Deferred msacm32<elf> \-PE 7e7a0000-7e7b5000 \ msacm32 ELF 7e7b5000-7e7cb000 Deferred glu32<elf> \-PE 7e7c0000-7e7cb000 \ glu32 ELF 7e7cb000-7e865000 Deferred gdi32<elf> \-PE 7e7e0000-7e865000 \ gdi32 ELF 7e865000-7e9a3000 Deferred user32<elf> \-PE 7e880000-7e9a3000 \ user32 ELF 7e9a3000-7e9ae000 Deferred libgcc_s.so.1 ELF 7ea99000-7eaa2000 Deferred libdrm.so.2 ELF 7eaa2000-7eaa7000 Deferred libxfixes.so.3 ELF 7eaa7000-7eaaa000 Deferred libxdamage.so.1 ELF 7eaaa000-7eaaf000 Deferred libxdmcp.so.6 ELF 7eaaf000-7eab2000 Deferred libxau.so.6 ELF 7eab2000-7eb2b000 Deferred libglu.so.1 ELF 7eb2b000-7eb8b000 Deferred libgl.so.1 ELF 7eb8b000-7ec77000 Deferred libx11.so.6 ELF 7ec77000-7ec85000 Deferred libxext.so.6 ELF 7ec85000-7ec9c000 Deferred libice.so.6 ELF 7ec9c000-7eca4000 Deferred libsm.so.6 ELF 7eca4000-7ed25000 Dwarf opengl32<elf> \-PE 7ecc0000-7ed25000 \ opengl32 ELF 7ed25000-7ed6d000 Deferred advapi32<elf> \-PE 7ed30000-7ed6d000 \ advapi32 ELF 7ed6d000-7ed80000 Deferred libresolv.so.2 ELF 7ed80000-7ed9e000 Deferred iphlpapi<elf> \-PE 7ed90000-7ed9e000 \ iphlpapi ELF 7ed9e000-7edca000 Deferred ws2_32<elf> \-PE 7edb0000-7edca000 \ ws2_32 ELF 7edca000-7ede4000 Deferred wsock32<elf> \-PE 7edd0000-7ede4000 \ wsock32 ELF 7ede4000-7ef0c000 Dwarf kernel32<elf> \-PE 7ee00000-7ef0c000 \ kernel32 ELF 7ef0c000-7ef17000 Deferred libnss_files.so.2 ELF 7ef17000-7ef21000 Deferred libnss_nis.so.2 ELF 7ef21000-7ef39000 Deferred libnsl.so.1 ELF 7ef39000-7ef5f000 Deferred libm.so.6 ELF 7ef5f000-7f000000 Deferred ntdll<elf> \-PE 7ef70000-7f000000 \ ntdll ELF b7cf0000-b7cf5000 Deferred libxxf86vm.so.1 ELF b7cf5000-b7cfe000 Deferred libnss_compat.so.2 ELF b7cff000-b7d03000 Deferred libdl.so.2 ELF b7d03000-b7e4b000 Deferred libc.so.6 ELF b7e4c000-b7e63000 Deferred libpthread.so.0 ELF b7e78000-b7f8c000 Dwarf libwine.so.1 ELF b7f8e000-b7fac000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 0000000a 0000000b 0 00000008 (D) C:\SIMS\RACER\tracked.exe 0000000e 2 0000000d 15 0000000c 15 00000009 0 <== also the application window shows a copy of some other window i have opened on the screen before it crashes instead of starting with a black window and then drawing the imported track objects. going to the commit just before this one gets tracked working (although the opengl window is drawn in the wrong place) but the application works in general. i tried to undo various parts of the patch but i wasn't able figure out anything. maybe somebody has some ideas. let me know if you need more information. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |

3 9

Problems with TAB_GetCurFocus
by Luiz Angelo Daros de Luca 29 Oct '07

29 Oct '07

Hello, I'm having problems with the result of the message TCM_GETCURFOCUS. In Windows, it returns "0" while in wine I got -1 (0xFFFFFFFF). This results in a Segfault for a 3rd party proprietary application (no source). 0009:Ret KERNEL32.TlsGetValue() retval=001445f8 ret=00501fc1 0009:Call user32.CallWindowProcA(ffff001b,00010056,0000132f,00000000,00000000) ret=004ebf11 0009:Call window proc 0x7e88f0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) 0009:Call user32.GetWindowLongW(00010056,00000000) ret=7e88f103 0009:Ret user32.GetWindowLongW() retval=0014e928 ret=7e88f103 0009:Ret window proc 0x7e88f0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=ffffffff 0009:Ret user32.CallWindowProcA() retval=ffffffff ret=004ebf11 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=ffffffff 0009:Ret user32.SendMessageA() retval=ffffffff ret=00416cad 0009:Call KERNEL32.GetLastError() ret=004d3ff9 (...) 0009:Call KERNEL32.UnhandledExceptionFilter(00338b9c) ret=004d8a7d Sometime in the past, wine 0.9.24 (suse 10.2), this app worked flawless. I filtered just TAB/TCM messages for version 0.9.24 and current. For current wine (0.9.48), I got: # WINEDEBUG=+relay wine VirtFone.exe 2>&1 | egrep '(TCM|TAB)' 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000000 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=0033908c) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=0033908c) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=0033908c) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=0033908c) retval=00000000 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=0033908c) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=0033908c) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=0033908c) retval=00000001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=0033908c) retval=00000001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000002 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000002 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=0033908c) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=0033908c) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=0033908c) retval=00000002 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=0033908c) retval=00000002 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=003390b4) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=003390b4) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=003390b4) retval=00000001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=003390b4) retval=00000001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) retval=00000000 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=ffffffff 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=ffffffff 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=ffffffff 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=ffffffff 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETIMAGELIST,wp=00000000,lp=00000000) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_SETIMAGELIST,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_SETIMAGELIST,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETIMAGELIST,wp=00000000,lp=00000000) retval=00000000 And for 0.9.24, #WINEDEBUG=+relay wine VirtFone.exe 2>&1 | egrep '(TCM|TAB)' 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000000 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=00338e6c) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=00338e6c) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=00338e6c) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000000,lp=00338e6c) retval=00000000 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=00338e6c) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=00338e6c) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=00338e6c) retval=00000001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000001,lp=00338e6c) retval=00000001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000002 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=00000000,lp=00000000) retval=00000002 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=00338e6c) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=00338e6c) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=00338e6c) retval=00000002 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=00000002,lp=00338e6c) retval=00000002 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=00338e94) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=00338e94) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=00338e94) retval=00000001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=00000000,lp=00338e94) retval=00000001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=00000000,lp=00000000) retval=00000000 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) 0009:Call window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) fixme:tab:TAB_GetCurFocus we have not to return negative value 0009:Ret window proc 0x7e6ddac0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=00000000 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=00000000,lp=00000000) retval=00000000 The line: fixme:tab:TAB_GetCurFocus we have not to return negative value In 0.9.24 log migth be intersting... I guess the message TCM_GETCURFOCUS should never returns negative values. BTW, the test file test/tab.c expects -1. /* Testing CurFocus with largest appropriate value */ SendMessage(hTab, TCM_SETCURFOCUS, nTabs-1, 0); focusIndex = SendMessage(hTab, TCM_GETCURFOCUS, 0, 0); expect(nTabs-1, focusIndex); /* Testing CurFocus with negative value */ SendMessage(hTab, TCM_SETCURFOCUS, -10, 0); focusIndex = SendMessage(hTab, TCM_GETCURFOCUS, 0, 0); expect(-1, focusIndex); /* Testing CurFocus with value larger than number of tabs */ focusIndex = SendMessage(hTab, TCM_SETCURSEL, 1, 0); todo_wine{ expect(-1, focusIndex); } Thanks in advance, -- Luiz Angelo Daros de Luca luizluca(a)gmail.com ICQ: 19290419 I Know, "Where you wanted to go today", but I decided to stop here instead! MS Windows

1 2

Fwd: New Wine help and discussion forum
by Tom Wickline 29 Oct '07

29 Oct '07

---------- Forwarded message ---------- From: Tom Wickline <twickline(a)gmail.com> Date: Oct 29, 2007 5:16 PM Subject: Re: New Wine help and discussion forum To: Dan Kegel <dank(a)kegel.com> On 10/29/07, Dan Kegel <dank(a)kegel.com> wrote: > On 10/29/07, Tom Wickline <twickline(a)gmail.com> wrote: > > Well, a single forum and a mailing list is a vast improvement over > > multiple forums and a mailing list. If you get your way it will be a > > forum and Google groups, and then you and Google will be the one who > > kills the Wine user mailing list, not me. > > ? We seem to be on different planets. Yea we are, because you are the one who ranted about killing the user mailing list in the first place. and now your spinning it to where I want to close down everything. I only want people to have the opportunity to post in a Wine centric forum. and not a Ubuntu or Gentoo or Fedora etc..etc..etc.. forum about Wine! > > There are quite a few forums where wine problems > are discussed. You might need to shut down > all of these to achieve your stated goal. Here are a few: > > http://www.linuxforums.org/forum/wine/ > http://www.playonlinux.com/forums/ > http://www.frankscorner.org/yabb/YaBB.pl > http://www.tatanka.com.br/ies4linux/forum/ > http://www.reactos.org/forum/ Thanks, ill send each of them a mail and ask them to cease operation. > > My stated goal is to not increase the number of > discussion forums / mailing lists, yet still appeal > to the "I hate email" generation. I think the > google groups front end for the existing mailing > list comes pretty close to that... So your goal is to have a single point for discussion? never mind ill let you send out the cease and desist mails. :D Tom > - Dan >

1 0

Extracting rules from comments in wine source code...?
by Dan Kegel 29 Oct '07

29 Oct '07

Hmm. Anyone in Illinois feel like going? Supposedly her tool finds bugs in source trees by looking for rules in comments and then checking the software against those rules. Her paper says she found one bug in wine this way... http://webtools.uiuc.edu/calendar/Calendar?calId=504&eventId=75432&ACTION=V… http://www.sosp2007.org/papers/sosp054-tan.pdf

2 2

re: New Wine help and discussion forum
by Dan Kegel 29 Oct '07

29 Oct '07

Steven wrote: > I can't speak for Tom on this issue, though I was the one to > suggest that he start the forum after the Wineconf discussions > regarding the mailing list and newsgroup disconnection. So you're the guilty party! Next time you decide to shake up the wine community like that, please consider discussing the move with the developer community first. > I think long term we might want to see about just killing the > users mailing list if the forum proves to be much more popular. > The idea is to have ONE central place for all user discussions. The mailing list can in fact be the central place, even in the era of web-based interfaces. Killing it would greatly annoy a large population of people, including especially the developers who sometimes help users on the list. The thing to kill, if anything, is the usenet group; sadly, usenet does seem to be decaying pretty badly. As an experiment, I've set up a google groups front end for wine-users. It's at http://groups.google.com/group/wine-users/ For this to become real, we'd have to switch the mailman user list over. Do folks think we should try that? Or do people really think we should kill the mailing list and go to a forum? - Dan

4 6

Re: Yet another wine frontend: PlayOnLinux
by Remco 29 Oct '07

29 Oct '07

Dan Kegel wrote: > This one seems new to me: > http://www.playonlinux.com > It's hooked up in the wine wiki already: > http://wiki.winehq.org/ThirdPartyApplications > http://wiki.winehq.org/PlayOnLinux > > Anyone tried it? > - Dan Whatever happened to winefix by the way? You mentioned it earlier, but it's not on the wiki. Unlike those temporary hacks to get specific applications working, winefix sounds like it has a few things Wine could really use in the desktop integration department. Remco (just a user/wine-devel-lurker) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

What's wrong with ...
by Christian Eggers 29 Oct '07

29 Oct '07

Hello, I've submitted a patch to wine-patches 5 days ago which has not been added yet: "Added wrapper dll for ct-api(CardTerminal API)" http://www.winehq.org/pipermail/wine-patches/2007-October/045716.html I think that most of the code has already been reviewed: The 1st version has already been submitted May 06 2007: - http://www.winehq.org/pipermail/wine-patches/2007-May/038908.html Steven Edwards pointed out some obvious mistakes... - http://www.winehq.org/pipermail/wine-patches/2007-May/038922.html - http://www.winehq.org/pipermail/wine-patches/2007-May/038923.html ... which were fixed on July 3: - http://www.winehq.org/pipermail/wine-devel/2007-July/057847.html - http://www.winehq.org/pipermail/wine-patches/2007-July/041206.html On July 11 Alexandre Julliard requested some additional changes: - http://www.winehq.org/pipermail/wine-devel/2007-July/058003.html I hope that everything is correct now. If not, please let me know. Thanks Christian

1 0

Yet another wine frontend: PlayOnLinux
by Dan Kegel 29 Oct '07

29 Oct '07

This one seems new to me: http://www.playonlinux.com It's hooked up in the wine wiki already: http://wiki.winehq.org/ThirdPartyApplications http://wiki.winehq.org/PlayOnLinux Anyone tried it? - Dan

2 1

ATI fglrx 8.42 Driver issues
by Brian Dunne 29 Oct '07

29 Oct '07

Hello wine crew, Not sure how many of you are ATI card users, but they released a new version of their binary driver a few days ago. It provides some great performance increases in native apps like Enemy Territory: Quake Wars, but I encountered a pretty serious problem when trying to wine World of Warcraft in OpenGL mode. In short, it won't draw models - it seems to draw environments and effect animations fine, but characters and objects like benches and mailboxes are invisible. It seems the majority of the focus is on testing at this point, but if there is any additional information I can provide which would help you graphics guys (available OpenGL extensions, etc.) please let me know. It's about time I contributed something to the project. =) Thanks, Brian Dunne

3 2

Lots of 'make test' failures on Windows
by Francois Gouget 29 Oct '07

29 Oct '07

Looking at yesterday's test results is depressing: http://test.winehq.org/data/200710241000/ Just looking at the pretty colors may not make this very obvious, but the state of the tests is APPALLING. Successes | Failures | Failure rate | Not Run WinXP-1 | 260 | 53 | 17% | 0 WinXP-2 | 252 | 62 | 20% | 0 Win2003-1 | 264 | 49 | 16% | 0 Win2003-2 | 241 | 72 | 23% | 0 Win98 | 113 | 115 | 50% | 45 So depending on the test run and the platform we have a failure rate that is between 16% and over 50%, really 53% as the gdi32 tests should really run on Win98. This is important because if you try to fix Wine to make these tests pass you may actually end up breaking Wine. So until these tests are fixed and pass on Windows they are of no use to us. So yeah, we don't have an http://test.winehq.org/ home page, and http://test.winehq.org/data/ should be made nicer too, but even so I'm hoping a few motivated developers will find their way to the test results and start a push to make things better. Btw, shouldn't it be a Wine 1.0 goal to have our conformance test suite pass cleanly on Windows? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

8 12

Re: [1/3] comctl32: Do not call parent of tool window for tip text
by Ann & Jason Edmeades 29 Oct '07

29 Oct '07

> Sending message to parent in tooltip code > probably simply works around toolbar's broken behavior. In this case I think > I've identified a line in toolbar.c that fails to properly detect empty string > causing not appearing tooltips in Radmin. I'll try to submit another patch with > this fix shortly. Thanks for checking this out - If your new patch makes tooltips work, I should probably be quiet... But.. I was looking through my notes of when I was working on this bug, looking at SPY++ logs from windows and comparing them with +spy,+message,+msg etc logs from wine. My notes indicated I was seeing the following sequence (I have hwnds or whatever spy logs written down): Tooltip sends toolbar needtextW Sends to base class tbn_GetInfoTipA which didn't return anything Sends tbn_GetInfoTipA to its parent which didn't return anything Tooltip sends baseclass ttn NeedTextA Which forwards to parent as ttn NeedTextA My notes and investigations could be wrong, does this tie up with what you were seing? Jason

2 1

Misplaced Property Sheet buttons
by Peter Åstrand 29 Oct '07

29 Oct '07

I'm debugging a problem where the standard buttons on a property sheet are misplaced. The application is Magna Cura. The screenshot http://www.cendio.com/~astrand/wine/62-tab-size/unpatched.png demonstrates the problem: The buttons are only partially visible. It turns out that the parent window for the Buttons changes size several times. The height is: 228 95 466 436 450 The PROPSHEET_AdjustButtons function, however, is only called in WM_INITDIALOG, so the buttons are positioned based on the height 466, and never repositioned. What's the proper fix for this? I've tried this patch: --- propsheet.c (revision 13243) +++ propsheet.c (arbetskopia) @@ -3828,6 +3828,13 @@ return TRUE; } + case WM_WINDOWPOSCHANGED: + { + PropSheetInfo* psInfo = (PropSheetInfo*) lParam; + PROPSHEET_AdjustButtons(hwnd, psInfo); + return FALSE; + } + default: return FALSE; } This solves the position problem, but instead the Help button disappears. See screenshot http://www.cendio.com/~astrand/wine/62-tab-size/patched.png. Any ideas? Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

2 2

Re: [1/3] comctl32: Do not call parent of tool window for tip text
by Ann & Jason Edmeades 29 Oct '07

29 Oct '07

Hi Alexander, > In the process of debugging I > also determined that Windows doesn't seem to send this message to > parent at all (tested on win98-Qemu, winXP SP2-Qemu and winXP SP1 > normal installation). So I'm deleting this second call altogether and > a conformance test for this situation will be included in the next > patch. > Under some circumstances, it must - see bug 9233 (and my patch at url below) http://www.winehq.org/pipermail/wine-patches/2007-August/042660.html http://www.winehq.org/pipermail/wine-cvs/2007-August/035236.html I debugged this through to the point where the parent was definitely retrieving the information (I watched spy logs of the application in question) and I believe reversing this patch will break radmin again... It's a free download, can you please test you havent regressed that application with the patch Jason

2 1

re: RICHED20: fix test crash on WinXP-SP2
by Dan Kegel 29 Oct '07

29 Oct '07

Alex Lasso wrote: > First of several patches to make riched20 tests actually pass on Windows. Without your patch, "make test" crashes for me on Wine. Your patch fixes the crash. So this isn't just a problem on Windows, thanks for fixing it! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: tools/widl/typegen.c pointer initialization
by Dan Hipschman 29 Oct '07

29 Oct '07

On Sun, Oct 28, 2007 at 01:51:34PM +0100, Gerald Pfeifer wrote: > In tools/widl/typegen.c we have the following snippet > > static void write_user_tfs(FILE *file, type_t *type, unsigned int *tafsoff) > { > unsigned int start, absoff, flags; > unsigned int align = 0, ualign = 0; > const char *name; > type_t *utype = get_user_type(type, &name); > > which passes name to get_user_type without initializing it. get_user_type > in return has the following piece of code: > > static type_t *get_user_type(const type_t *t, const char **pname) > { > for (;;) > { > type_t *ut = get_attrp(t->attrs, ATTR_WIREMARSHAL); > if (ut) > { > if (pname) > *pname = t->name; > return ut; > } > > It is unclear to this reader (and various versions of GCC I tested), > whether we don't really use *name (*pname) uninitialized here. Now > it is possible that through some of the, hmm, tricky logic in these > two functions combined with some environmental guarantees it happens > that we don't, but it seems better to be proactive here. The logic is as follows: We wouldn't be in write_user_tfs if the predicate is_user_type wasn't true for that type, which means *pname (name) will always be initialized since it gets set precisely when get_user_type returns non-NULL (which is the is_user_type test). I don't think initializing it to NULL is helpful since it would crash just the same as if it weren't initialized. name *must* have a valid (non-NULL) value. This may silence a warning, but it's making the logic of the code more confusing by setting the variable to a value that doesn't make any sense in that context. get_user_type is the initialization. Better than this would be to put "assert(is_user_type(type));" above the initializations to convince the programmer at least that name will get initialized correctly in get_user_type. If that doesn't convince the compiler then I don't think it's worth it to try to placate it since we're supposed to be wrting code for humans, not computers. Some projects use a macro like "name IF_LINT(= NULL);" to quiet warnings while informing the reader that the initialization is not necessary. I suppose that's slightly better as well. I think the real problem is that the code is just not clear enough. I've been meaning to add asserts. Where asserts are impractical: comments.

2 2

Re: [PATCH] Currently the serial code interprets
by Juan Lang 29 Oct '07

29 Oct '07

Hi Tom, > Content-Type: text/x-patch; name=0001-XONXOFF-reversion.patch > Content-Transfer-Encoding: base64 Apparently gmail's encoding .patch files as base64. It should be text/plain. Please try renaming it to, e.g., 0001-XONXOFF-reversion.diff and try again. --Juan

1 0

Pegasus Mail: program closes when sub-program closes
by Joel Barnett 28 Oct '07

28 Oct '07

Sent to bugzilla, and to this email addy, as per winehq instructions: http://www.pmail.com/downloads_maine_t.htm Version to look at is 4.41, a free download. This email app does a normal shutdown whenever the editor is closed, e.g., after a new email is sent. This is not normal behaviour. In Windows the app stays open, so that one can continue sending, receiving, reading, writing email, etc. In old versions of wine, this error doesn't happen, (ver. 20050830). The regression error occurs as early as 0.9.20. Based on posts to the wine appdb for this app, it is likely that the regression error ocurred >=0.9.14. The editor in Pmail was not written by the developer and maintainer, David Harris, but rather licensed by him. Recent wine code seems to interpret an ordinary call to close the editor as a call to close the program itself. When Pmail starts, a 0 byte file, mailbox.lck is created in the mail box of the user. When the user closes the program normally, this file is deleted. Since the shutdown regression error deletes the lock file, I conclude the call to close the editor is being misinterpreted by wine as a call to shutdown Pmail. Joel Barnett New super maintainer for Pegasus Mail p.s. - I'm new at this, please forgive me if my report is funky. I did check bugzilla and didn't find anything relevant.

1 0

Re: ddraw: allow explicit backbuffer
by Stefan Dösinger 28 Oct '07

28 Oct '07

Am Sonntag, 28. Oktober 2007 01:18:53 schrieb EA Durbin: > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game > combat pillows to launch There is a test in the ddraw tests that shows that this is not allowed. This test will break I guess. However, maybe it is a version differece. The test tests IDirectDraw7 I think, maybe the game uses an older version.

2 1

Re: ddraw: allow explicit backbuffer
by Marcus Meissner 28 Oct '07

28 Oct '07

On Sat, Oct 27, 2007 at 06:18:53PM -0500, EA Durbin wrote: > > based on patch by Jaroslav Reznik, this fixes bug 9008 and allows the game combat pillows to launch > > _________________________________________________________________ > Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. > http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct > From d6c94c504f555f773c2c90d7fcbd4bf3500fe490 Mon Sep 17 00:00:00 2001 > From: EA Durbin <ead1234(a)hotmail.com> > Date: Sat, 27 Oct 2007 18:16:27 -0500 > Subject: ddraw: allow explicit backbuffer, based on a patch by Jaroslav Reznik > > --- > dlls/ddraw/ddraw.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/ddraw/ddraw.c b/dlls/ddraw/ddraw.c > index 7785624..a84fc36 100644 > --- a/dlls/ddraw/ddraw.c > +++ b/dlls/ddraw/ddraw.c > @@ -2283,7 +2283,7 @@ IDirectDrawImpl_CreateSurface(IDirectDraw7 *iface, > return DDERR_NOEXCLUSIVEMODE; > } > > - if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER | DDSCAPS_BACKBUFFER)) { > + if(DDSD->ddsCaps.dwCaps & (DDSCAPS_FRONTBUFFER || DDSCAPS_BACKBUFFER)) { This is wrong. You changed a logical OR into a boolean OR and the bitmask will no longer work... Something else needs to be changed, like removing either the DDSCAPS_BACKBUFFER part or the FRONTBUFFER part of the |. Ciao, Marcus

1 0

Re: implement FatalExitHook()
by Maarten Lankhorst 28 Oct '07

28 Oct '07

Hi EA, I can find absolutely no info on FatalExitHook, are you sure it's supposed to exit the process, rather then making the argument be called in case of exit? Cheers, Maarten.

2 2

SHChangeNotify()
by Francois Gouget 28 Oct '07

28 Oct '07

shlwapi.spec exports SHChangeNotify. However I see no implementation of this function in shlwapi. There is an SHChangeNotifyWrap() function however. Weirder still, SHChangeNotifyWrap() does not seem to be called anywhere, is not exported by shlwapi.spec, and calls SHChangeNotify(). So I'm confused as to how this is supposed to work. Could you clarify things for me? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

1 0

ddraw:d3d tests failing consistently
by Reece Dunn 27 Oct '07

27 Oct '07

Hi, Looking at the ddraw:d3d tests, they are failing consistently on many Windows platforms: d3d.c:1039: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1050: Test failed: Vertex 2 differs. Got 129.000000 127.000000 1.000000 1.000000, expexted 133.000000 123.000000 1.000000 1.000000 d3d.c:1050: Test failed: Vertex 3 differs. Got 127.000000 129.000000 -1.000000 1.000000, expexted 123.000000 133.000000 -1.000000 1.000000 d3d.c:1050: Test failed: Vertex 4 differs. Got 128.500000 127.500000 0.500000 1.000000, expexted 130.500000 125.500000 0.500000 1.000000 d3d.c:1050: Test failed: Vertex 5 differs. Got 127.500000 128.500000 -0.500000 1.000000, expexted 125.500000 130.500000 -0.500000 1.000000 d3d.c:1050: Test failed: Vertex 6 differs. Got 127.500000 128.500000 0.000000 1.000000, expexted 125.500000 130.500000 0.000000 1.000000 d3d.c:1060: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1071: Test failed: Vertex 1 differs. Got 128.000000 128.000000 0.000000 1.000000, expexted 138.000000 148.000000 0.000000 1.000000 d3d.c:1071: Test failed: Vertex 2 differs. Got 129.000000 127.000000 1.000000 1.000000, expexted 143.000000 143.000000 1.000000 1.000000 d3d.c:1071: Test failed: Vertex 3 differs. Got 127.000000 129.000000 -1.000000 1.000000, expexted 133.000000 153.000000 -1.000000 1.000000 d3d.c:1071: Test failed: Vertex 4 differs. Got 128.500000 127.500000 0.500000 1.000000, expexted 140.500000 145.500000 0.500000 1.000000 d3d.c:1071: Test failed: Vertex 5 differs. Got 127.500000 128.500000 -0.500000 1.000000, expexted 135.500000 150.500000 -0.500000 1.000000 d3d.c:1071: Test failed: Vertex 6 differs. Got 127.500000 128.500000 0.000000 1.000000, expexted 135.500000 150.500000 0.000000 1.000000 d3d.c:1134: Test failed: Cliptest 3 differs. Got 00000020 expexted 00000026 d3d.c:1134: Test failed: Cliptest 4 differs. Got 00000010 expexted 00000019 d3d.c:1143: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1157: Test failed: Cliptest 1 differs. Got 00000000 expexted 00000002 d3d.c:1157: Test failed: Cliptest 2 differs. Got 00000000 expexted 00000001 d3d.c:1157: Test failed: Cliptest 3 differs. Got 00000020 expexted 00000022 d3d.c:1157: Test failed: Cliptest 4 differs. Got 00000010 expexted 00000011 d3d.c:1166: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1195: Test failed: IDirect3DViewport_SetViewport returned 80070057 d3d.c:1206: Test failed: Offscreen is 0 d3d.c:1217: Test failed: Offscreen is 0 d3d.c:1231: Test failed: Offscreen is 2 Does anyone know if this is a change in ddraw:d3d behaviour on Windows between versions/graphics drivers or has this test always failed? - Reece

5 17

MENU_TrackMenu trouble
by nicholai＠t-online.de 27 Oct '07

27 Oct '07

Hello, I'm struggling to make recent Chessbase applications such as Fritz 9 and 10 work with wine. A free download which shows the same symptoms described below is available here: http://fritzserver.org/download/CBLightEnglishSetup.exe I have tried to look into this and this is what I've found: The application uses TrackPopupMenuEx() (user32/menu.c) which in wine is just a call to TrackPopupMenu(). The latter function calls MENU_TrackMenu() and that's where things seem to go wrong. In the loop going through the message queue the application will crash (see output below) whenever the following message is sent: SendMessageW( mt.hOwnerWnd, WM_ENTERIDLE, MSGF_MENU, (LPARAM)win ); If I uncomment that line, the application will stay alive but I will obviously experience weird menu behaviour. I'm stuck trying to find out what the problem is and would really appreciate any help on how to proceed with this Thanks and best regards, Nicholai ------------------------------------------------------------------------------------------------------------------------------- wine: Unhandled page fault on read access to 0x00000020 at address 0x15a60c5 (thread 03da), starting debugger... Unhandled exception: page fault on read access to 0x00000020 in 32-bit code (0x015a60c5). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:015a60c5 ESP:0034ea64 EBP:0034eb10 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:0272e930 EDX:782ba9e0 ESI:015a60c0 EDI:0272e930 Stack dump: 0x0034ea64: 015a60c0 782021cb 00000002 00000000 0x0034ea74: 62a7f85f 00000121 0272e930 00138218 0x0034ea84: 00000000 00000000 015cfe20 782bafa4 0x0034ea94: 7fffffff 7bc3f3de 00000000 00000000 0x0034eaa4: 00000090 7bc326a1 00000000 00000010 0x0034eab4: 0034eb04 7bc40bff 00110014 7bc8443c Backtrace: =>1 0x015a60c5 in sviewnet (+0x760c5) (0x0034eb10) 2 0x78201ca1 in mfc80 (+0x31ca1) (0x0034eb30) 3 0x78200a43 in mfc80 (+0x30a43) (0x0034eb98) 4 0x78200c53 in mfc80 (+0x30c53) (0x0034ebbc) 5 0x781fedad in mfc80 (+0x2edad) (0x0034ec04) 6 0x7ed63b8a WINPROC_wrapper+0x1a() in user32 (0x0034ec34) 7 0x7ed6429e in user32 (+0xa429e) (0x0034ec74) 8 0x7ed685db in user32 (+0xa85db) (0x0034f144) 9 0x7ed69a0b WINPROC_call_window+0x15b() in user32 (0x0034f184) 10 0x7ed3036c in user32 (+0x7036c) (0x0034f1f4) 11 0x7ed340a2 in user32 (+0x740a2) (0x0034f254) 12 0x7ed3451a SendMessageW+0x4a() in user32 (0x0034f294) 13 0x7ed2d327 in user32 (+0x6d327) (0x0034f354) 14 0x7ed2e0af TrackPopupMenu+0x11f() in user32 (0x0034f394) 15 0x7ed2e14e TrackPopupMenuEx+0x5e() in user32 (0x0034f3c4) 16 0x015a757a in sviewnet (+0x7757a) (0x000005f0) 17 0x00000000 (0x00000000)

1 0

wine tests question?
by Vijay Kiran Kamuju 27 Oct '07

27 Oct '07

Hi, I have been looking into http://test.winehq.org/data/. And I have got a question, when i saw the test data. Why do some tests do not return the data about tests they haven't run/skipped. They spew messages something like below: mapi32:prop start dlls/mapi32/tests/prop.c 1.20 mapi32:prop done (-1073741819) mapi32:util start dlls/mapi32/tests/util.c 1.9 mapi32:util done (-1073741819) I am trying to figure out a reason so that i can fix this. can you guys help me out? thanks, VJ

2 2

What if heap errors caused 'make test' to fail?
by Dan Kegel 27 Oct '07

27 Oct '07

Let's just say, for grins, that we applied a patch that made heap corruption fatal under WINEDEBUG=warn+heap, e.g. --- a/dlls/ntdll/heap.c +++ b/dlls/ntdll/heap.c @@ -909,6 +909,7 @@ static BOOL HEAP_ValidateInUseArena( con WARN( "Heap %p: unaligned arena pointer %p\n", subheap->heap, pArena ); if ( TRACE_ON(heap) ) HEAP_Dump( subheap->heap ); + assert( FALSE ); } return FALSE; } @@ -924,6 +925,7 @@ static BOOL HEAP_ValidateInUseArena( con WARN("Heap %p: invalid in-use arena magic for %p\n", subheap->heap, pArena ); if (TRACE_ON(heap)) HEAP_Dump( subheap->heap ); + assert( FALSE ); } return FALSE; } How many tests would that break? Any guesses? Scroll down for the answer: 25! Here's the output of WINEDEBUG=warn+heap make -k test piped through grep make.*Error: make[2]: *** [alloc.ok] Error 134 make[2]: *** [pipe.ok] Error 1 make[2]: *** [systray.ok] Error 6 make[2]: *** [thread.ok] Error 9 make[2]: *** [security.ok] Error 1 make[1]: *** [advapi32/tests/__test__] Error 2 make[2]: *** [info.ok] Error 134 make[1]: *** [ntdll/tests/__test__] Error 2 make[2]: *** [heap.ok] Error 134 make[2]: *** [change.ok] Error 2 make[2]: *** [heap.ok] Error 5 make[2]: *** [util.ok] Error 134 make[1]: *** [msvcrt/tests/__test__] Error 2 make[1]: *** [snmpapi/tests/__test__] Error 2 make[2]: *** [apibuf.ok] Error 134 make[1]: *** [netapi32/tests/__test__] Error 2 make[2]: *** [device.ok] Error 4 make[1]: *** [d3d9/tests/__test__] Error 2 make[2]: *** [moniker.ok] Error 134 make[2]: *** [toolhelp.ok] Error 8 make[2]: *** [webbrowser.ok] Error 134 make[1]: *** [shdocvw/tests/__test__] Error 2 make[2]: *** [input.ok] Error 64 make[2]: *** [editor.ok] Error 5 make[1]: *** [riched20/tests/__test__] Error 2 make[2]: *** [mixer.ok] Error 10 make[2]: *** [msg.ok] Error 18 make[2]: *** [shellpath.ok] Error 3 make[2]: *** [class.ok] Error 2 make[2]: *** [comm.ok] Error 3 make[2]: *** [vartype.ok] Error 134 make[1]: *** [oleaut32/tests/__test__] Error 2 make[2]: *** [parser.ok] Error 134 make[1]: *** [setupapi/tests/__test__] Error 2 make[2]: *** [win.ok] Error 8 make[2]: *** [capture.ok] Error 134 make[1]: *** [dsound/tests/__test__] Error 2 make[2]: *** [htmldoc.ok] Error 134 make[2]: *** [timer.ok] Error 1 make[2]: *** [mci.ok] Error 134 make[1]: *** [mshtml/tests/__test__] Error 2 make[2]: *** [font.ok] Error 26 make[1]: *** [gdi32/tests/__test__] Error 2 make[1]: *** [kernel32/tests/__test__] Error 2 make[2]: *** [wave.ok] Error 8 make[1]: *** [winmm/tests/__test__] Error 2 make[2]: *** [server.ok] Error 4 make[1]: *** [rpcrt4/tests/__test__] Error 2 make[2]: *** [dde.ok] Error 5 make[1]: *** [user32/tests/__test__] Error 2 make[2]: *** [shlexec.ok] Error 35 make[1]: *** [shell32/tests/__test__] Error 2 make[1]: *** [ole32/tests/__test__] Error 2 I wonder if some of these tests are themselves buggy such that they pass on Wine by accident (without this patch) but fail on Windows? - Dan

4 5

wine needs a relatively new version of fontforge?
by Lei Zhang 27 Oct '07

27 Oct '07

Hi, Dan K. and I both ran into bug 10103 [1] because the fontforge on our systems is too old. I noticed some of the font tests failed on my system for the same reason. So what is the minimum version of fontforge that will generate correct fonts? Should we add a check for it? - Lei [1] http://bugs.winehq.org/show_bug.cgi?id=10103

1 0

Re: makefiles: add a notest target
by Maarten Lankhorst 26 Oct '07

26 Oct '07

Hi Lei, Lei Zhang schreef: > Hi, > > This patch adds a notest target to build everything but the dll unit > tests and winetest. This cuts down build time by 25%. > Julliard will never accept such patch. In the hacks.git tree there is a patch I did that has a configuration time option for it. It would be cleaner if you used something like 'make SKIPTESTS=1'. I doubt that alexandre would ever accept any patch that would disable building tests, though. Cheers, Maarten.

3 2

Re: user32: Fix a test that now passes in Windows
by Reece Dunn 26 Oct '07

26 Oct '07

On 25/10/2007, James Hawkins wrote: > Hi, > > Changelog: > * Fix a test that now passes in Windows. Looking at the code, it looks as if they are now passing in Wine :). > dlls/user32/tests/dde.c | 13 ++++++++++--- > 1 files changed, 10 insertions(+), 3 deletions(-) > + str = (LPSTR)DdeAccessData(hdata, &size); > + ok(!lstrcmpA(str, "requested data\r\n"), "Expected 'requested data\\r\\n', got %s\n", str); Shouldn't there be quote marks around the %s (i.e. '%s', to match the expected value)? > + ok(size == 19, "Expected 19, got %d\n", size); > + > + ret = DdeUnaccessData(hdata); > + ok(ret == TRUE, "Expected TRUE, got %d\n", ret); These are new test cases. Since these are not fixes to existing test cases, they should really be in a separate patch. - Reece

3 3

my first patch
by viny 26 Oct '07

26 Oct '07

Can someone tell me if this patch is correct for submitting to wine-patches. I have generated this patch with "git format-patch -o out origin" (related bug : http://bugs.winehq.org/show_bug.cgi?id=9805) >From c5eab13b67e6f24b3518dd77840f260dc101520e Mon Sep 17 00:00:00 2001 From: Vincent Hardy <vincent.hardy.be(a)gmail.com> Date: Fri, 26 Oct 2007 13:37:39 +0200 Subject: [PATCH] Add TypeLib version for W2K, WXP, and Vista --- dlls/oleaut32/typelib16.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/dlls/oleaut32/typelib16.c b/dlls/oleaut32/typelib16.c index a010f7d..31bbf93 100644 --- a/dlls/oleaut32/typelib16.c +++ b/dlls/oleaut32/typelib16.c @@ -153,6 +153,9 @@ HRESULT WINAPI LoadTypeLib16( *| OLE 2.1 NT 1993-95 ?? ??? *| OLE 2.3.1 W95 23 700 *| OLE2 4.0 NT4SP6 1993-98 40 4277 + *| OLE 2.1 W2K 2000 10 3029 + *| OLE 2.1 WXP 2002 10 3029 + *| OLE 2.1 Vista 2007 10 3029 */ DWORD WINAPI OaBuildVersion16(void) { @@ -171,6 +174,12 @@ DWORD WINAPI OaBuildVersion16(void) return MAKELONG(3024, 10); /* W98 SE */ case 0x00000004: /* NT4 */ return MAKELONG(4277, 40); /* NT4 SP6 */ + case 0x00000005: /* W2K */ + return MAKELONG(3029, 10); /* W2K SP4 */ + case 0x00000105: /* WXP */ + return MAKELONG(3029, 10); /* WXP SP2 */ + case 0x00000006: /* Vista */ + return MAKELONG(3029, 10); /* Vista */ default: FIXME("Version value not known yet. Please investigate it!\n"); return 0; -- 1.5.2.5

3 2

Improving http://tests.winehq.org/data/
by Francois Gouget 26 Oct '07

26 Oct '07

Here are some things I noticed while using this site. Let me know if I it would help to make bug reports for these: * Some result entries are red with a dash in them and a blue border. See the Windows 98 results for http://test.winehq.org/data/200710241000/ I assume these means that the test did not load. However we should distinguish two cases there: - if it did not run because the tested dll did not exist at all, then it's not a test failure and thus the background should be green. A typical case would be the crypt32 tests on Windows 98. - if the dll was there but the test still did not run, typically because the dll is missing an export, then that's a bug in the test: it should dynamically load that function so the other checks it performs can be run. A typical case is the gdi32 tests on Windows 98. Ideally we'd even have a log showing the missing API but that's probably too tricky to do on Windows. * Downloading the log file for a given test run gives me a file that's called 'report'. It would be nice if it was called something like 'vmware-win98-report' instead so that saving a couple of them in a directory leads to fewer collisions. * It would be nice if the /data page looked more like a calendar with the most current date easily accessible, and a less like the directory listing it currently is. Then a / page would be nice too. I'm pretty unlikely to fix these, but at least here is a starting if someone is inclined to do so: you will find the source for the test.winehq.org website in the tools.git repository: http://source.winehq.org/git/tools.git/?a=tree;f=winetest To get hold of the sources, see the instructions there: http://www.winehq.org/site/git#modules -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

6 9

Anything wrong with my patch from 16.10. about w32x86 and win40 creation?
by Markus Gömmel 26 Oct '07

26 Oct '07

I think it's not a big deal but would help making on of our EmTec products more compatible... Markus

5 13

Re: [1/5] (resend) WineD3D: Enable the draw buffers extension only when used
by Stefan Dösinger 26 Oct '07

26 Oct '07

Please ignore this patch. I just saw that macos advertises 4 draw buffers, but only one was used inside wined3d because we weren't using fbo offscreen rendering. Now macos supports the extension, 4 draw buffers but still complains... oh well > Am Freitag, 26. Oktober 2007 12:45:57 schrieb Stefan Dösinger: > > In a last discussion with Henri on IRC I fixed a concern he had about the > > old patch(dropped extension check). As for the general concern about > > driver issue fixups, we didn't come to a final conclusion and decided to > > ask Alexandre for his opinion. Just to sum up the pros/cons: > > > > -) Makes the code more complex to work around another's issues > > -) Will most likely never be removed should the driver be fixed > > > > +) Compiling the shader without warnings makes real issues more visible > > and important > > +) Avoids confusing mac users and developers with the false warnings > > +) MacOS Tiger Driver will propably never get fixed > > Use the attached patch instead, it follows a suggestion by Chris and is > less intrusive.

1 0

Re: d3dx8 math implementation + tests: use more "," instead of ";".
by Alexandre Julliard 26 Oct '07

26 Oct '07

Lionel Debroux <lionel_debroux(a)yahoo.fr> writes: > I noticed several "," in the implementation and tests of D3DX8 math > functions. I added more, since this may help the auto-vectorizer of > some compilers noticing that x86 SIMD could be used. I don't see any reason why that would make the slightest difference, what makes you think this is needed? -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Improving http://tests.winehq.org/data/
by Dan Kegel 26 Oct '07

26 Oct '07

James wrote: >Looking at the test data, all of the msi:install tests timeout. I >just ran the install tests in XP running under vmware on a 3ghz >machine. The tests took 9m41s. That completely blows away the 2min >timeout. There's nothing wrong with the tests, they just take a long >time. I don't think we should extend the timeout, because it's very >subjective and more tests will be added, meaning we'll have to change >the timeout eventually. I do think we should have a flag or variable >that allows the timeout to be ignored for certain tests. Any >opinions? I'd like a way to specify the expected runtime, for use on tests that we observe take a long time. It would be used in two ways: 1) runtest could take an option --skip-long-tests which would skip all tests that had that option set, and 2) by default runtest would only abort those tests if they took one minute over their expected time (say). That would give us both a quick interactive make test and a more reliable slow-but-complete make test. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

4 4

Re: Word crash
by Kai Blin 26 Oct '07

26 Oct '07

On Friday 26 October 2007 09:28:09 Marco Stornelli wrote: > Hi all, > > I'm using wine 0.9.44-15 for openSuse 10.3 and office 2000. Excel > works fine, powerpnt doesn't start and wine doesn't print nothing in > console about it, and about word, wine prints this: Please don't send emails to wine-bugs. Open a bugreport on http://bugs.winehq.org/ instead. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Beer apps under Wine :-)
by Dan Kegel 26 Oct '07

26 Oct '07

Seems that most beer apps run ok on wine, judging by this thread: http://www.tastybrew.com/forum/thread/120190

1 0

Re: crypt32: Remove a test because of a Windows 2003 SP1 bug
by Reece Dunn 25 Oct '07

25 Oct '07

Juan Lang wrote: > - /* Now check just the time */ > - flags = CERT_STORE_TIME_VALIDITY_FLAG; > - parent = CertGetIssuerCertificateFromStore(store, child, NULL, &flags); > - ok(parent != NULL, "CertGetIssuerCertificateFromStore failed: %08x\n", > - GetLastError()); > - /* Oops: the child is not expired, so the time validity check actually > - * succeeds, even though the signing cert is expired. > + /* Checking time validity is not productive, because while most Windows > + * versions return 0 (time valid) because the child is not expired, > + * Windows 2003 SP1 returns that it is expired. Thus the range of > + * possibilities is covered, and a test verifies nothing. > */ The test being removed is correct and valid. Removing it could lead to a regression in Wine as this case is not being covered when this patch is applied. While a 100% pass rate is ideal, on Windows 2003 SP1 that test *is* failing due to a bug. However, this is the correct behaviour, and the bug is detected by this test. - Reece

2 4

How long should 'make test' take?
by Dan Kegel 25 Oct '07

25 Oct '07

Here are all the tests that take more than five seconds: 5.407s advapi32_test.exe.so service.c 6.010s kernel32_test.exe.so console.c 6.252s user32_test.exe.so msg.c 9.657s kernel32_test.exe.so process.c 12.053s winmm_test.exe.so timer.c 14.080s shell32_test.exe.so shlexec.c 17.760s msi_test.exe.so install.c 24.018s winmm_test.exe.so wave.c 648.722s wininet_test.exe.so ftp.c Other than wininet's ftp test and maybe winmm's wave test, the overall time seems reasonable. IMHO we should disable the ftp test until its runtime can be brought down below 20 seconds. It's just too slow, and too dependent on stuff not under Wine's control (e.g. one's internet connection). And I have a really fast internet connection... it's just that my ping time to winehq is 80ms. I bet the ftp test runs fast in Minneapolis... - Dan

4 5

Re: Start: Convert start to Unicode.
by Dmitry Timoshkov 25 Oct '07

25 Oct '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > -/** > +WINE_DEFAULT_DEBUG_CHANNEL(start); > + > +/* All these changes /** -> /* make the diff larger, and are not really necessary. > Output given message to stdout without formatting. > */ > -static void output(const char *message) > +static void output(const WCHAR *message) > { > DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + DWORD res; > + int wlen = strlenW(message); Once you change your editor settings to use natural 8 spaces for a tab you will see how ugly the formatting in your new code is. > -static void fatal_error(const char *msg, DWORD error_code) > +static void fatal_error(const WCHAR *msg, DWORD error_code) fatal_error() is not called with strings outside of ASCII charset, so there is no much point in converting it to unicode. It only makes your patch full of controversial changes. IMHO fatal_error() should be removed altogether, and replaced by proper error handling instead. -- Dmitry.

3 5

Re: winmm: fix uninitialized variable that caused near-infinite loop
by Alexandre Julliard 25 Oct '07

25 Oct '07

"Dan Kegel" <dank(a)kegel.com> writes: > Without this patch, winmm/tests/mixer.c appears to hang on one of my machines. > > I think the problem was capsA was uninitialized in: > for (d=0;d<capsA.cDestinations;d++) { That's just hiding the bug. If mixerGetDevCapsA failed we shouldn't go on to use the data that it hasn't returned, we should abort the test. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shlwapi: Update exported API entries according to the info published by Geoff Chappell
by Alexandre Julliard 25 Oct '07

25 Oct '07

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -1,18 +1,18 @@ > -1 stdcall -noname ParseURLA(str ptr) > -2 stdcall -noname ParseURLW(wstr ptr) > +1 stdcall ParseURLA(str ptr) > +2 stdcall ParseURLW(wstr ptr) That doesn't look right, why are you removing -noname on these and many other functions? AFAICT they are not exported by name in most shlwapi versions. -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: shlwapi: Update exported API entries according to the info published by Geoff Chappell
by Robert Shearman 25 Oct '07

25 Oct '07

Dmitry Timoshkov wrote: > +1 stdcall ParseURLA(str ptr) > +2 stdcall ParseURLW(wstr ptr) > +12 stdcall SHCreateMemStream(ptr long) > +168 stdcall ConnectToConnectionPoint(ptr ptr long ptr ptr ptr) > +169 stdcall IUnknown_AtomicRelease(long) > +172 stdcall IUnknown_GetWindow(ptr ptr) > +174 stdcall IUnknown_SetSite(ptr ptr) > +176 stdcall IUnknown_QueryService(ptr ptr ptr ptr) > +184 stdcall IStream_Read(ptr ptr long) SHIStream_Read > +185 stdcall SHMessageBoxCheckA(ptr str str long long str) > +191 stdcall SHMessageBoxCheckW(ptr wstr wstr long long wstr) > > +199 stdcall IUnknown_Set(ptr ptr) > +203 stdcall SHStripMneumonicA(str) > +204 stdcall SHIsChildOrSelf(long long) > +212 stdcall IStream_Write(ptr ptr long) SHIStream_Write > +213 stdcall IStream_Reset(ptr) > +214 stdcall IStream_Size(ptr ptr) > +215 stdcall SHAnsiToUnicode(str ptr long) > +217 stdcall SHUnicodeToAnsi(wstr ptr ptr) > +219 stdcall QISearch(long long long long) > +225 stdcall SHStripMneumonicW(wstr) > +256 stdcall IUnknown_GetSite(ptr ptr ptr) > +276 stdcall WhichPlatform() > +280 stdcall SHRegGetIntW(ptr wstr long) > +345 stdcall SHAnsiToAnsi(str ptr long) > +346 stdcall SHUnicodeToUnicode(wstr ptr long) > +353 stub SHFormatDateTimeA > +354 stub SHFormatDateTimeW > +388 varargs ShellMessageBoxW(long long wstr wstr long) ShellMessageBoxWrapW > +418 stdcall MLFreeLibrary(long) > +432 stub SHSendMessageBroadcastA > +433 stub SHSendMessageBroadcastW > +437 stdcall IsOS(long) > +462 stub UrlFixupW > +467 stub SHRunIndirectRegClientCommand > +512 stub IStream_ReadPidl > +513 stub IStream_WritePidl > These are all exported by ordinal only up to Windows 2003 SP1 (w/ IE 6.0). +196 stub -noname SHVerbExistsNA #stdcall @(ptr ptr ptr ptr) dnsapi.DnsRecordSetCompare You need to fix the name of the function in the comment here. -- Rob Shearman

2 1

Re: winex11.drv: Support HWND_TOPMOST/HWND_BOTTOM windows using NETWM states.
by Alexandre Julliard 25 Oct '07

25 Oct '07

Robert Shearman <rob(a)codeweavers.com> writes: > */ > -static void update_wm_states( Display *display, struct x11drv_win_data *data, BOOL force ) > +static void update_wm_states( Display *display, struct x11drv_win_data *data, > + BOOL force, BOOL set_zorder, HWND insert_after ) > { > static const unsigned int state_atoms[NB_WM_STATES] = > { > XATOM__NET_WM_STATE_FULLSCREEN, > XATOM__NET_WM_STATE_SKIP_PAGER, > - XATOM__NET_WM_STATE_SKIP_TASKBAR > + XATOM__NET_WM_STATE_SKIP_TASKBAR, > + XATOM__NET_WM_STATE_ABOVE, > + XATOM__NET_WM_STATE_BELOW, It's not that easy, there's a lot more to HWND_TOPMOST than simply setting window manager hints, it needs to enforce proper ordering in the server, and set/clear the WS_EX_TOPMOST style as needed. I have that on my todo list... -- Alexandre Julliard julliard(a)winehq.org

1 0

start:start.c Display messages in the console encoding.
by Kirill K. Smirnov 25 Oct '07

25 Oct '07

> static void output(const char *message) > { >- DWORD count; >- WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), >&count, NULL); >+ DWORD count = 0; >+ WCHAR *mesW = NULL; >+ char *mes = NULL; >+ int wlen = 0; >+ int len = 0; >+ >+ wlen = MultiByteToWideChar( CP_ACP, 0, message, -1, NULL, 0 ); >+ mesW = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(WCHAR) ); >+ mes = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(char) ); >+ >+ MultiByteToWideChar( CP_ACP, 0, message, -1, mesW, wlen ); >+ len = WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, NULL, 0, >NULL, NULL ); >+ WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, mes, len, NULL, >NULL ); >+ >+ WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), mes, len, &count, NULL); >+ if( !count && len ) >+ SetLastError( ERROR_FUNCTION_FAILED ); >+ >+ HeapFree(GetProcessHeap(), 0, mesW); >+ HeapFree(GetProcessHeap(), 0, mes); > } WriteFile does not output unicode characters to console screen buffer, so if ConsoleOutputCP is smth like 65001, this will fail. The page http://msdn2.microsoft.com/en-us/library/ms687401.aspx contains remedy by Microsoft how to deal with problem: 1) If device handle is console, then output wide chars using WriteConsoleW 2) If device handle is not console, then convert wide chars to ConsoleOutputCP and output using WriteFileA. This way is already implemented in cmd (See WCMD_output_asis_len function). And it may be much better to convert start utility to unicode. -- Kirill P.S. all this manipulations is supposed to be done by msvcrt printf function family, but wine lacks this functionality :-(

2 1

any clues as to what's wrong with patches (system palette entries)?
by Alexander Dorofeyev 25 Oct '07

25 Oct '07

Hello. I've sent a patch that changes X11DRV_GetSystemPaletteEntries behavior and a test something like a week ago. I guess they fell into that so called not obviously correct category (or maybe not correct at all one). I'll appreciate any comments or suggestions on possible improvements. Thanks. > On Windows, GetSystemPaletteEntries() call in non-palettized graphics > modes returns back reserved colors from the default palette. This patch > modifies winex11.drv's X11DRV_GetSystemPaletteEntries() function to > imitate this behavior instead of just returning 0. This partially solves > bug #201 (helps igowin.exe transparency problem, untested with another app).

1 0

Git Page on website
by Alistair Leslie-Hughes 24 Oct '07

24 Oct '07

Hi, On the git web page, the commands to run to perform "Cleaning up your existing tree" and "Staying Up-To-Date" have been merge to one line. Best Regards Alistair Leslie-Hughes

1 0

AppDB: login
by speedator＠gmx.de 24 Oct '07

24 Oct '07

Hi, would be great to have a longer period to stay logged in. A setting under preference for the period seems a good solution, Btw: What is the status of appdb/bugzilla(wiki?)-account-fusion? Bye, Julian

2 1

PulseAudio as a sound output?
by King InuYasha 24 Oct '07

24 Oct '07

I would like to suggest that eventually Wine would support PulseAudio as a sound output natively. I am already aware of Wine supporting ESD, which PulseAudio can use, but supporting PulseAudio natively I think would be much better.

13 20

Anything wrong with my patch from 16.10. about w32x86 and win40 creation?
by Pat 24 Oct '07

24 Oct '07

I usually use the archives for viewing patches, sometimes the patches are archived separately to the email. Markus' patch is here: http://www.winehq.org/pipermail/wine-patches/2007-October/045288.html

3 3

Re: iphlpapi: Intel Mac do not implement /proc filesystem so return Unimplemented for the functions trying to read from there.
by Juan Lang 24 Oct '07

24 Oct '07

Hi Aric, @@ -104,6 +104,9 @@ DWORD getInterfaceStatsByName(const char { FILE *fp; +#ifdef __APPLE__ + return ERROR_NOT_SUPPORTED; +#endif This is ugly. Why not just change the case when fp is NULL? You've already got: fp = fopen("/proc/net/dev", "r"); if (fp) { ... } else ERR ("unimplemented!\n"); You could change this to set the return value, rather than using all these #ifdefs. Same thing throughout the patch. --Juan

2 1

Re: "typos" on some include files
by Dmitry Timoshkov 24 Oct '07

24 Oct '07

"Marcos Gutiérrez Batz" <sacrom(a)gmail.com> wrote: > $ diff -up liboleaut32.def /usr/lib/wine/liboleaut32.def > --- liboleaut32.def 2007-08-23 16:15:48.000000000 +0200 > +++ /usr/lib/wine/liboleaut32.def 2007-10-15 00:48:35.000000000 +0200 > @@ -366,7 +366,6 @@ EXPORTS > OleCreatePictureIndirect@16 @419 > OleCreateFontIndirect@12 @420 > OleTranslateColor@12 @421 > - OleLoadPictureFile@12 @422 > OleLoadPicturePath@24 @424 > VarUI4FromI8@12 @425 > VarUI4FromUI8@12 @426 Also you can't just add an entry to the .def file, it's auto generated. You have to add a stub to the source file, and change the 'stub' entry in the .spec file. -- Dmitry.

2 4

Re: "typos" on some include files
by Dmitry Timoshkov 24 Oct '07

24 Oct '07

"Marcos Gutiérrez Batz" <sacrom(a)gmail.com> wrote: > Attached is the "patch" file (diff -up) regarding the bug: > > http://bugs.winehq.org/show_bug.cgi?format=multiple&id=10156 The patch is reversed, please change the source/dest, rediff and resend. -- Dmitry.

2 1

Re: dlls/rpcrt4/rpc_server.c initiale variable
by Robert Shearman 24 Oct '07

24 Oct '07

Gerald Pfeifer wrote: > It seems there are some code paths (in the error case?) which may > leave this unitialized. At least the compiler thinks so, and I > could not convince myself otherwise reading this code for a while. > It's a false positive, probably coming from the compiler not picking up that it is set when the exception variable is false and that when exception is true it is set earlier in the function. > - RpcPktHdr *response; > + RpcPktHdr *response = 0; > > If you're going to change the code at all, then at least keep to the coding convention used in the rest of the function and use NULL here. -- Rob Shearman

2 1

Re: oleaut32 [2/2]: Use widl to generate oaidl_p.c
by Alexandre Julliard 24 Oct '07

24 Oct '07

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This patch sets up the oleaut32 Makefile and shuffles some files > around so we can use widl to generate oaidl_p.c. The patch is *very* > large since it contains a diff for all of oaidl_p.c (which was > removed), and also two for oaidl.idl (which was moved). That's ugly, we need to make this work without having to rename the public headers. -- Alexandre Julliard julliard(a)winehq.org

1 0

windows on solaris
by S E 24 Oct '07

24 Oct '07

Hi , I have an executable that resides and compiled on windows 2003 server, I want to approach from my UNIX Solaris machine and run the executable. If anyone knows how to do that, or what can I use to run that I will be very happy. Thanks, SE

1 0

wineconf photos
by Steven Edwards 24 Oct '07

24 Oct '07

Hi, I was not lucky enough to have my digital camara with me during Wineconf, so if you've got photos uploaded somewhere please post urls or better yet add them to the Wiki. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

Re: start:start.c Display messages in the console encoding.
by Dmitry Timoshkov 24 Oct '07

24 Oct '07

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > static void output(const char *message) > { > - DWORD count; > - WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), message, strlen(message), &count, NULL); > + DWORD count = 0; > + WCHAR *mesW = NULL; > + char *mes = NULL; > + int wlen = 0; > + int len = 0; There is no need to initialize variables to 0 since you are going to explicitly initialize them later anyway. > + wlen = MultiByteToWideChar( CP_ACP, 0, message, -1, NULL, 0 ); > + mesW = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(WCHAR) ); > + mes = HeapAlloc( GetProcessHeap(), 0, wlen * sizeof(char) ); Allocating wlen chars for 'mes' won't work correctly on a multibyte locale. > + MultiByteToWideChar( CP_ACP, 0, message, -1, mesW, wlen ); > + len = WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, NULL, 0, NULL, NULL ); Just move the call to allocate 'len' bytes for 'mes' here. > + WideCharToMultiByte( GetConsoleOutputCP(), 0, mesW, wlen, mes, len, NULL, NULL ); -- Dmitry.

1 0

rpc: (resend) Add missing headers
by Roy Shea 24 Oct '07

24 Oct '07

Hello, Attached is a corrected version of this patch. I thank Mikolaj who brought to my attention the fact that rpcproxy.h is the incorrect location to include the files I added in the earlier patch. This revised patch adds the includes directly to rpc.h. The Windows version of rpc.h accesses these includes throuh windows.h. Peace, -Roy On Tue, Oct 23, 2007 at 09:50:25AM -0700, Roy Shea wrote: > Howdy, > > The REGISTER_PROXY_DLL_ROUTINES macro defined in rpcproxy.h calls > DisableThreadLibraryCalls. This patch adds two header files needed > for calls to DisableThreadLibraryCalls. > > Peace, > -Roy >

1 0

Re: [PATCH 3/3] configure: Use 0 instead of NULL because NULL isn't defined.
by Stefan Dösinger 23 Oct '07

23 Oct '07

Am Freitag, 19. Oktober 2007 23:18:51 schrieb Ken Thomases: > This makes the test test the proper thing on Mac OS X. It still fails, but > for a good reason. > --- > configure.ac | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > - char *name=NULL; > + char *name=0; Shouldn't that be (void *) 0 or (char *) 0?

6 7

Re: widl [3/4]: Remove printf format strings that aren't really format strings.
by Michael Stefaniuc 23 Oct '07

23 Oct '07

Dan Hipschman wrote: > This is just a minor cleanup patch. Even if we're definitely sure a > string doesn't contain any % signs, it's still better not to use it as a > printf format string. fputs() would be a faster alternative to that. Though i doubt that matters in this case. bye michael > --- > tools/widl/typegen.c | 4 ++-- > tools/widl/widl.c | 6 +++--- > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/tools/widl/typegen.c b/tools/widl/typegen.c > index bf24d3f..53ec78c 100644 > --- a/tools/widl/typegen.c > +++ b/tools/widl/typegen.c > @@ -2501,7 +2501,7 @@ void print_phase_basetype(FILE *file, int indent, enum remoting_phase phase, > fprintf(file, " *)_StubMsg.Buffer = *"); > else > fprintf(file, " *)_StubMsg.Buffer = "); > - fprintf(file, varname); > + fprintf(file, "%s", varname); > fprintf(file, ";\n"); > } > else if (phase == PHASE_UNMARSHAL) > @@ -2510,7 +2510,7 @@ void print_phase_basetype(FILE *file, int indent, enum remoting_phase phase, > print_file(file, indent, ""); > else > print_file(file, indent, "*"); > - fprintf(file, varname); > + fprintf(file, "%s", varname); > if (pass == PASS_IN && is_ptr(type)) > fprintf(file, " = ("); > else > diff --git a/tools/widl/widl.c b/tools/widl/widl.c > index 53c9e29..37f1a5e 100644 > --- a/tools/widl/widl.c > +++ b/tools/widl/widl.c > @@ -422,13 +422,13 @@ int main(int argc,char *argv[]) > idfile_name = xstrdup(optarg); > break; > case 'V': > - printf(version_string); > + printf("%s", version_string); > return 0; > case 'W': > pedantic = 1; > break; > default: > - fprintf(stderr, usage); > + fprintf(stderr, "%s", usage); > return 1; > } > } > @@ -458,7 +458,7 @@ int main(int argc,char *argv[]) > input_name = xstrdup(argv[optind]); > } > else { > - fprintf(stderr, usage); > + fprintf(stderr, "%s", usage); > return 1; > } > > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

3 3

Re: wininet: ftp test hangs behind firewall, so turn it off by default
by Alexandre Julliard 23 Oct '07

23 Oct '07

"Dan Kegel" <dank(a)kegel.com> writes: > This gets rid of one more place I have to do 'wineserver -k' to > make tests complete. I don't think it really hangs, it just takes a long time to complete. > It would be better to embed a little ftp server into the test, > and connect to that instead of a public one, but that would > be a pain. No, we clearly want to run the test against a real ftp server. Running it against different types of servers would be even better. What we should probably do is try to connect to a server on localhost first, this way people can install the server of their choice to provide more test coverage. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: msi: Propogate errors from events all the way up to the parent dialog
by Alexandre Julliard 23 Oct '07

23 Oct '07

"James Hawkins" <truiken(a)gmail.com> writes: > Fixes bug 10107. http://bugs.winehq.org/show_bug.cgi?id=10107 > > Changelog: > * Propogate errors from events all the way up to the parent dialog. This one fails for me: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so package.c && touch package.ok package.c:587: Test failed: wrong return val make: *** [package.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gdi32 (2/2): fix unchecked NULL ptr in BIDI_Reorder
by Alexandre Julliard 23 Oct '07

23 Oct '07

Alexander Dorofeyev <alexd14(a)hushmail.com> writes: > 3rd try. In this version I don't create a temp buffer, instead pass the original > string to subroutines; in BidiLines an additional parameter had to be added, to > indicate that the original string has been passed and in-place modifications it > normally does on the buffer must be skipped. You should pass separate in and out pointers, since the input pointer is const you can't use it in place of the output one. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] updated authors
by Dmitry Timoshkov 23 Oct '07

23 Oct '07

"Marcus Meissner" <meissner(a)suse.de> wrote: > --- > AUTHORS | 138 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 136 insertions(+), 2 deletions(-) I've found more duplicates, sorry for the trouble. > +Veksler Michael This is a duplicate due to the reversed last/first names. > Zoltan Nagy > +Zoly Nagy The two names above look similar enough, but changelog doesn't provide enough information to distinguish them. > +Brouard Nicolas Again a duplicate due to the reversed last/first names. > +Tom Spear Not sure if have him already under an old name (can't remember which one). -- Dmitry.

3 2

Re: pdh: Remove or fix tests that fail on Windows.
by Hans Leidekker 23 Oct '07

23 Oct '07

On Monday 22 October 2007 14:43:59 Jeff Latimer wrote: > to test with and hence the delay. The current patch I submitted was > cleaning up the Null reference issue before moving on to sorting out the I don't see any crash on Wine or XP when running the test. You are trying to protect against a hypothetical case where an app specifies a size > 0 but no buffer. XP won't accept that anyway and it's unlikely any app will do that on non-XP systems. In fact your patch will break in another - also unlikely - situation where an app relies on non-XP behaviour, which is to accept a null buffer and size > 0 but less than the required size. So a crash is even desirable here, because it tells us immediately that the app is doing something peculiar. -Hans

2 1

iexplore text input
by Luke Bratch 23 Oct '07

23 Oct '07

Hi all As you probably know, text input in iexplore isn't working at the moment, and hasn't worked since this commmit: http://source.winehq.org/git/wine.git/?a=commit;h=92b3cab7916445d79d2559e4b… (Found by Simon in this bug: http://bugs.winehq.org/show_bug.cgi?id=9746) I've posted a patch in there: http://bugs.winehq.org/attachment.cgi?id=8647 That seems to make text input work be reversing part of that commit. As far as I can see that doesn't break anything else. Your thoughts? Thanks Luke ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

2 1

Re: [PATCH] updated AUTHORS according to "git log"
by Dmitry Timoshkov 23 Oct '07

23 Oct '07

"Marcus Meissner" <marcus(a)jet.franken.de> wrote: I briefly looked over the diff and found some duplicates, perhaps there are more of them: > Guy Albertelli > +Guy L. Albertelli This one is probably a duplicate. > +Turchanov Sergei And this one already exists as 'Sergey Turchanov'. > +NF Stevens > Norman Stevens According to the e-mail addresses the two above is a single person. > +Josh Thielen > Joshua Thielen And these two as well. > +Sergei Turchanov > Sergey Turchanov Again a duplicate. -- Dmitry.

1 0

urlmon: Fix the MIME type reported by the HTTP protocol when the Content-Type headers contains charset data too.
by Misha Koshelev 23 Oct '07

23 Oct '07

> Sorry to send this out after the patch has already been committed, but > this patch is wrong. If you just output the Content-Type in > test/protocol.c you'll see that the charset data is included in the > "MIME type" in both Windows XP and on wine with native urlmon (from > WinME or 98; I believe the XP one crashes wine or at least it used to). > That is why when I was fixing the original test I just changed it to a > memcmp from a strcmp. > Misha > Just checked on Win98, the behavior to keep the charset in the "MIME type" is correct on Win98 as well. Misha

1 0

urlmon: Fix the MIME type reported by the HTTP protocol when the Content-Type headers contains charset data too.
by Misha Koshelev 23 Oct '07

23 Oct '07

Sorry to send this out after the patch has already been committed, but this patch is wrong. If you just output the Content-Type in test/protocol.c you'll see that the charset data is included in the "MIME type" in both Windows XP and on wine with native urlmon (from WinME or 98; I believe the XP one crashes wine or at least it used to). That is why when I was fixing the original test I just changed it to a memcmp from a strcmp. Misha

1 0

Photoshop Elements 5 Tryout?
by Dan Kegel 22 Oct '07

22 Oct '07

Anyone have a URL for PSE 5 trial version? I'm updating http://wiki.winehq.org/AdobePhotoshop Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

7 15

Re: [4/5] WineD3D: Enable the draw buffers extension only when used
by H. Verbeet 22 Oct '07

22 Oct '07

On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > The shader works in the end, but the complaints pollute the logs and > make tracking real failures more difficult. I don't think this change makes things better there.

2 3

Re: gdi32 (1/2): fix unchecked NULL ptr in BIDI_Reorder
by Alexandre Julliard 22 Oct '07

22 Oct '07

Alexander Dorofeyev <alexd14(a)hushmail.com> writes: > >> One problem is that it wasn't assured lpOutString isn't NULL, and NULL > >> was getting passed to this routine by GetCharacterPlacementW. so it was > >> crashing in memcpy. This patch creates a temporary buffer when > >> lpOutString is NULL and it is used for in-place modifications instead in > >> such case. You shouldn't need to allocate a new buffer, the output modifications should be skipped when no output string is requested. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: urlmon: Add tests for BindToObject for URL monikers based on the existing tests for BindToStorage.
by Alexandre Julliard 22 Oct '07

22 Oct '07

Robert Shearman <rob(a)codeweavers.com> writes: > dlls/urlmon/tests/url.c | 201 > +++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 196 insertions(+), 5 deletions(-) Some of the todos are succeeding here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1293: Test succeeded inside todo block: expected QueryInterface_IServiceProvider url.c:1299: Test succeeded inside todo block: expected QueryInterface_IServiceProvider make[2]: *** [url.ok] Error 12 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/5] WineD3D: A point size fix
by H. Verbeet 22 Oct '07

22 Oct '07

On 22/10/2007, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > D3D's point size limit is the output point size, GLs the input. Modify > the scale parameters to deal with this. Shouldn't the caps be changed as well then?

2 1

Re: pdh: check for NULL pointer reference
by Hans Leidekker 22 Oct '07

22 Oct '07

On Monday 22 October 2007 11:30:10 Jeff Latimer wrote: > This function has specific XP behaviour which I have tested but I have > not been able to verify that Win2k etc works the same. Any comment welcome. I don't think we want to emulate the broken XP behaviour of requiring a buffer, even when querying the buffer size. Apps written to comply with this behaviour should work on the current implementation. And MSDN mentions only XP, which implies that it has been fixed in Win2k3 and up. -Hans

2 3

Phoronix: Ubuntu 7.10 + WINE vs. Windows XP
by speedator 22 Oct '07

22 Oct '07

Hello everybody, new benchmark-test at phoronix.com: http://www.phoronix.com/scan.php?page=article&item=882&num=1

8 15

re: ReplaceFileW (was: Phoronix: Ubuntu 7.10 + WINE vs. Windows XP)
by Dan Kegel 22 Oct '07

22 Oct '07

Reece Dunn wrote: > The patch was rejected by Alexandre because the patch was > implementing that command using Windows API calls, > when it should be implemented natively as POSIX/GNU calls. Really? Where did he say that? It'd be nice to link to that from http://bugs.winehq.org/show_bug.cgi?id=7544 - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 5

WOAFONT needed
by Uwe Bonnes 21 Oct '07

21 Oct '07

Hello, http://dmt.mhilfe.de/ is a tool to read out DSL-line parameters. The windows version knows about a lot of DSL Modems, while a linux rewrite only knows of a small amount of modems. Running as root, because of an ICMP call in the program to find the DSL modem in the network, the program runs fine. However the font is unreadable small. The author uses the app850.fon font, which seems to cause a lot of trouble in windows too. However the cures given in the webpage (put the font into windows/fonts and add [386enh] [woafont=app850.FON]) don't help for me. wine/dlls/gdi32/freetype.c also talks about the app850 font, however neither gives a hint usefull for me. Any ideas? -- 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

IntelMac compile error
by Steve Brown 21 Oct '07

21 Oct '07

Hi All, Trying to build Wine 0.9.47 on an Intel MacBook Pro (2.16GHz Core Duo).... compilation stops at: mach.c: In function 'get_thread_context': mach.c:166: error: 'x86_debug_state32_t' undeclared (first use in this function) mach.c:166: error: (Each undeclared identifier is reported only once mach.c:166: error: for each function it appears in.) mach.c:166: error: parse error before 'state' mach.c:167: error: 'state' undeclared (first use in this function) mach.c:182: error: 'x86_DEBUG_STATE32' undeclared (first use in this function) mach.c: In function 'set_thread_context': mach.c:210: error: 'x86_debug_state32_t' undeclared (first use in this function) mach.c:210: error: parse error before 'state' mach.c:211: error: 'state' undeclared (first use in this function) mach.c:245: error: 'x86_DEBUG_STATE32' undeclared (first use in this function) make[1]: *** [mach.o] Error 1 make: *** [server] Error 2 I stared briefly at the code, and didn't see anything obvious -- also a quick grep through the source directories and the XCode Headers didn't find a header file that included "x86_debug" (case insensitive grep). Ideas? Steve Brown sbrown7(a)umbc.edu

2 2

Re: [AppDB] Tell the user not to submit screenshots of installers, error messages etc.
by Vitaliy Margolen 21 Oct '07

21 Oct '07

Alexander Nicolaysen Sørnes wrote: > These don't really say much about how an application works. > > Why wouldn't you want to see game menu? I think that's a bit way too much. Then the next step would be to require movie of the actual game play? Installers - yeah it's a bit irrelevant. However even errors helpful. When errors are fixed people can see that. And image can be easily removed. So in short - you can add installers to the list of don'ts. But that's about it. Vitaliy.

1 0

[AppDB] Fix maintainer processing
by Alexander Nicolaysen Sørnes 21 Oct '07

21 Oct '07

Fix maintainer processing Alexander N. Sørnes

1 0

msi testing
by EA Durbin 20 Oct '07

20 Oct '07

I recently purchased the book "The Definitive Guide to Windows Installer". I haven't really started reading it yet, but the source code and sample files are available online so I starting testing the sample .msi files in wine and windows out of curiousity . These files are relatively small and are targeted to demonstrate specific .msi functionality. They might work nicely for testing installer functionality in wine without being obscured by large amounts of other application related debug output. http://www.apress.com/book/downloadfile/1645 _________________________________________________________________ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmail…

1 0

Re: gdi32: fix unchecked NULL ptr and off by one error in BIDI_Reorder
by Michael Stefaniuc 20 Oct '07

20 Oct '07

Hello Alexander! Alexander Dorofeyev wrote: > This patch fixes two problems that are causing crashes in Thanks for the patch. Could you please split the patch in two; one patch for each problem fixed. Please also do not use C++ style comments aka // > BIDI_Reorder. In particular, Skype 3.5.0 crashed every time I type > anything in the chat edit box. > > One problem is that it wasn't assured lpOutString isn't NULL, and NULL > was getting passed to this routine by GetCharacterPlacementW. so it was > crashing in memcpy. This patch creates a temporary buffer when > lpOutString is NULL and it is used for in-place modifications instead in > such case. > > Another is off by one error in setting lpOrder. > > --- > dlls/gdi32/bidi.c | 33 ++++++++++++++++++++++++++++----- > 1 files changed, 28 insertions(+), 5 deletions(-) > > > ------------------------------------------------------------------------ > > diff --git a/dlls/gdi32/bidi.c b/dlls/gdi32/bidi.c > index cac9453..2b1320e 100644 > --- a/dlls/gdi32/bidi.c > +++ b/dlls/gdi32/bidi.c > + > + if (!lpOutString) > + { > + //temporary buffer was created > + HeapFree(GetProcessHeap(), 0, lpReorderBuffer); > + } > + > return TRUE; > } thanks bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111

1 0

Solidworks 2007 Test with 0.9.47
by Stephan Rose 20 Oct '07

20 Oct '07

Major improvement with Solidworks 2007 on the latest version. Visually, everything actually looks perfect now. OpenGL windows are where they are supposed to be. Font is right. So from that end, everything appears to work very well. What's still broken: - Performance is extremely bad. Even on my Dual Core with 4 gigs of RAM. - Memory usage is extremely high still at around 2 gigs. - Extrude function, first thing I test as it's the most fundamental, still won't work. CPU will just go to full load on that core and just sit there forever. Infinite loop maybe? Definite improvement though, thanks everyone. =) Stephan

1 0

winmm test runs forever?
by Dan Kegel 19 Oct '07

19 Oct '07

Today I'm starting to see winmm_test spew an infinite series of failures on line 467 of mixer.c: ../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so mixer.c && touch mixer.ok ALSA lib seq_hw.c:456:(snd_seq_hw_open) open /dev/snd/seq failed: No such file or directory mixer.c:359: Test failed: mixerGetDevCapsA: MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID mixer.c:364: Test failed: mixerGetDevCapsA: MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID mixer.c:408: Test failed: mixerGetLineInfoA(MIXER_GETLINEINFOF_DESTINATION): MMSYSERR_INVALPARAM or MIXERR_INVALLINE expected, got MMSYSERR_BADDEVICEID mixer.c:433: Test failed: mixerGetLineInfoA(MIXER_GETLINEINFOF_DESTINATION): MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID mixer.c:467: Test failed: mixerGetLineInfoA(MIXER_GETLINEINFOF_SOURCE): MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID mixer.c:467: Test failed: mixerGetLineInfoA(MIXER_GETLINEINFOF_SOURCE): MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID mixer.c:467: Test failed: mixerGetLineInfoA(MIXER_GETLINEINFOF_SOURCE): MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID mixer.c:467: Test failed: mixerGetLineInfoA(MIXER_GETLINEINFOF_SOURCE): MMSYSERR_NOERROR expected, got MMSYSERR_BADDEVICEID ... I have to do wineserver -k to make progress.

2 2

Make test drill, next steps, call for help with Winetest
by Jeremy White 19 Oct '07

19 Oct '07

Hi Folks, So I had plan to report on the status of make test, and sound a call to action. That is, one of the best and most fun things we did at Wineconf was to call bullshit on the failure of make test to work reliably. That is, it only runs cleanly on Alexandre's machine, and not even all the time then. So, we worked hard to make 'make test' work reliably on other folks systems at Wineconf. We made a lot of progress; cutting failures by half, I would say. The closest we got was with Michael; I think he was down to 3 at the end. However, we're still plagued with differences due to chipsets, locales, and other differences. But I think it is vital that we continue this work. The fact that 'make test' doesn't work anywhere, really, is bullshit. However, I'm enough of a weasel that I wanted to get out of collating all of this data myself. So I investigated (or tried to investigate) winetest to see if I could dump this work on a tool. And it looks like it would be great. Of course, with a few caveats :-/. In my opinion, it needs the following: 1. A Wiki page! I could not find *any* documentation on this utility. For example, I'm still not entirely clear on how to setup and/or register my build.id so that my results are available on the web site. (And the rather non intuitive requirement to 'know' the unpublished url http://test.winehq.org/data/ is harsh). 2. Headless operation From my experiments, there were a number of dialogs I had to dismiss, and some worrying complaints in unpacking msvcrtd and msvcrt tests. This second point is probably a bit less important than the first. However, it looked like if just a few little glitches could be ironed out, that it would be a fantastic tool for working on the make test problem. We'd be able to see the common failures, and work to resolve them and drive them to zero. Is there someone that could do the first part of this? Just document what is already there? Or point me to the page that exists that I just missed? Cheers, Jeremy

4 8

Re: D3DX8: [4/13]: implement D3DX__Add with a test
by Stefan Dösinger 19 Oct '07

19 Oct '07

Am Freitag, 19. Oktober 2007 10:13:39 schrieb David.Adam(a)math.cnrs.fr: > +#define expect_vec3(expectedvec,gotvec) ok((fabs(expectedvec.x-gotvec.x)<admitted_error)&&(fabs(expectedvec.y-gotvec.y)<admitted_error)&&(fabs(expectedvec.z-gotvec.z)<admitted_error),"Expected Vector= (%f, %f,%f)\n , Got Vector= (%f, %f, %f)\n", expectedvec.x, expectedvec.y, expectedvec.z, gotvec.x, gotvec.y, gotvec.z); Usually inline functions are prefered over macros. I don't know how well that works with ok though, since it might drop the line of the error and make debugging harder.

1 0

Re: D3DX8: [1/13] resent: implement D3Dx__Length with a test
by Stefan Dösinger 19 Oct '07

19 Oct '07

Am Freitag, 19. Oktober 2007 10:10:07 schrieb David.Adam(a)math.cnrs.fr: > ----- > Pièces jointes (Les liens expireront le May 1, 2008) > https://webmail.math.cnrs.fr/horde/imp/attachment.php?u=dadam%40math.cnrs.f >r&t=1192788607&f=0001-Implement-D3DX___Length-function-with-a-test.patch.pat >ch Did you forget to attachthe file?

1 0

Use warn+heap when running 'make test'
by Dan Kegel 19 Oct '07

19 Oct '07

As noted in http://bugs.winehq.org/show_bug.cgi?id=9916 using warn+heap poisons free memory, and finds a few more bugs. People who run 'make test' should consider running WINEDEBUG=warn+heap make test instead. (I don't know whether we should make that the default, though. Anyone have an opinion?)

2 1

Re: wined3d: Fix resource cleanup if CreateCubeTexture fails.
by Stefan Dösinger 19 Oct '07

19 Oct '07

Am Freitag, 19. Oktober 2007 07:14:17 schrieb Allan Tong: Looks good to me

1 0

notepad: Dangling pointer fix
by Andrew Talbot 18 Oct '07

18 Oct '07

Please ignore this patch. Thanks, -- Andy.

1 0

Re: [PATCH] wininet: Conformance test for InternetCrackUrlA (try 2)
by Detlef Riekenberg 18 Oct '07

18 Oct '07

On Mi, 2007-10-17 at 13:17 -0700, Nigel Liang wrote: > + urlCompa.dwStructSize = sizeof(urlCompa); > + bRet = InternetCrackUrlA(sUrl, 11, 0, &urlCompa); > + ZeroMemory(&urlCompa, sizeof(urlCompa)); > + ZeroMemory(&szBuf, sizeof(char)*1024); > + urlCompa.dwUserNameLength = 1024; It looks much better, when you avoid constant numbers. I suggest to use sizeof() instead. (but never use "sizeof()" in "ok()" or in "trace()".) Thanks for helping wine. -- By by ... Detlef

1 0

Re: widl [4/4]: Detect conformant arrays of user types correctly.
by Robert Shearman 18 Oct '07

18 Oct '07

Dan Hipschman wrote: > @@ -1859,6 +1859,7 @@ static int get_struct_type(var_list_t *fields) > case RPC_FC_OP: > case RPC_FC_CARRAY: > case RPC_FC_CVARRAY: > + case RPC_FC_BOGUS_ARRAY: > has_pointer = 1; > break; > > @@ -1897,15 +1898,9 @@ static int get_struct_type(var_list_t *fields) > /* fallthru - treat it as complex */ > > /* as soon as we see one of these these members, it's bogus... */ > - case RPC_FC_IP: > case RPC_FC_ENCAPSULATED_UNION: > case RPC_FC_NON_ENCAPSULATED_UNION: > - case RPC_FC_TRANSMIT_AS: > - case RPC_FC_REPRESENT_AS: > - case RPC_FC_PAD: > - case RPC_FC_EMBEDDED_COMPLEX: > case RPC_FC_BOGUS_STRUCT: > - case RPC_FC_BOGUS_ARRAY: > return RPC_FC_BOGUS_STRUCT; > } > } > Hi Dan, What's the reasoning behind this part of the patch? It seems to me like most of the cases that you removed from becoming a complex structure are actually valid. The hunk further up also confuses me - the presence of a complex array shouldn't just make the resulting structure into a pointer structure, it should make it into a complex structure, since it can't be marshalled solely by using memcpy. -- Rob Shearman

2 1

Priority/severity of test suite hangs
by Dan Kegel 18 Oct '07

18 Oct '07

I'm going to start filing bugs for anything that makes the test suite hang, and I'm going to lash out and give them unreasonably high priority and severity. There's just no excuse for a test suite that can't run to completion. -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 2

Re: [2/3] hlink: Undefine the GetObject macro when compiling the Wine source to avoid errors.
by Jacek Caban 18 Oct '07

18 Oct '07

Hi Francois, Francois Gouget wrote: > > +/* GetObject is defined in wingdi.h as WINELIB_NAME_AW(GetObject), > + * which resolves to a compilation failure if WINE_NO_UNICODE_MACROS is > + * defined, but GetObject is used as a valid method name below, so we have > + * to undefine it in that case */ > +cpp_quote("#ifdef WINE_NO_UNICODE_MACROS") > +cpp_quote("#undef GetObject") > +cpp_quote("#endif") > + > /***************************************************************************** > * IHlinkBrowseContext interface > */ > I've sent a patch for it yesterday and it's applied now: http://source.winehq.org/git/wine.git/?a=commitdiff;h=a41cab9b52893f472de6c… I've also sent a patch for mshtml.idl patch (but my version didn't include import shtypes.idl): http://source.winehq.org/git/wine.git/?a=commitdiff;h=62894b488d0b03a922b80… Thanks, Jacek

1 0

Re: inkobj: Implement IClassFactory
by Alexandre Julliard 18 Oct '07

18 Oct '07

"John Klehm" <xixsimplicityxix(a)gmail.com> writes: > This patch is largely based on the code found in mshtml. What I did > was separate it into its own file and restyle it to my liking. Restyling it wasn't such a good idea I'm afraid, the original code is better without these ugly casts, and the Release function was correct, unlike yours. Also please don't name your files inkobj_something, they are in the inkobj directory already, no need to repeat that in the file name. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] wininet: Substitute strchrW with memchrW in InternetCrackUrlW (try 2)
by Alexandre Julliard 18 Oct '07

18 Oct '07

Nigel Liang <ncliang(a)gmail.com> writes: > Previous patch had incorrect bounds for memchrW. There are other places in that function that assume that the string is null-terminated, please fix those too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mshtml: Added support for installing Gecko from build dir.
by Alexandre Julliard 18 Oct '07

18 Oct '07

Jacek Caban <jacek(a)codeweavers.com> writes: > - static const char gecko_dir[] = "/gecko/"; > - > - data_dir = wine_get_data_dir(); > - if(!data_dir) return FALSE; > + if((data_dir = wine_get_data_dir())) > + subdir = "/gecko/"; > + else if((data_dir = wine_get_build_dir())) > + subdir = "/dlls/mshtml/"; I don't think this file should be inside the build dir, it's not something that can be easily regenerated. Maybe we should look for it in $build_dir/.. ? -- Alexandre Julliard julliard(a)winehq.org

1 0

RE: msi: make the WriteEnvironmentStrings handling of [~] a bit better
by EA Durbin 18 Oct '07

18 Oct '07

The compiler complains at this line about lstrlenW being passed an incompatible pointer type + else if (lstrlenW(value) >= prefix_len) should it be lstrlenW(*value) ? _________________________________________________________________ Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct

2 1

Re: [PATCH] wininet: Close sockets open in http requests
by Misha Koshelev 18 Oct '07

18 Oct '07

> n 10/13/07, Nigel Liang <ncliang at gmail.com> wrote: > > Hi, > > > > Http requests open sockets and forget to close them. Left running over a long > > period, the socket file descriptor starts getting large. Once it exceeds > > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > > > -Nigel > > > > --- > > dlls/wininet/internet.c | 3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > > index 0edca74..8e3a98e 100644 > > --- a/dlls/wininet/internet.c > > +++ b/dlls/wininet/internet.c > > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > > return FALSE; > > } > > > > + if (lpwh->htype == WH_HHTTPREQ) > > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > > + > > WININET_Release( lpwh ); > > WININET_FreeHandle( hInternet ); > > > > -- > > 1.4.1 > > > > > > Hi, > > This patch was sent 4 days ago and it hasn't gone in yet. Could anyone > give me some comments on it? Dan filed bug 10032 which is related to > this. While we shouldn't be using select() on high FDs for networking, > this patch closes the sockets that were open by http requests to avoid > getting to high FDs... > > Thanks, > -Nigel Hi, well looking over this very quickly right off the bat it does not seem correct to me. WININET_Release will call the close_connection method of the handle if it is defined, and for WH_HHTTPREQ this is HTTP_CloseConnection, which does call NETCON_Close along with sending all the proper status notifications, etc. So if in fact NETCON_Close is _not_ being called for some reason, you need to track down where involving those functions either why the proper one is not getting called (if that is the case) or if that function somehow needs to call NETCON_Close when it doesn't. Misha

2 3

Re: [PATCH] wininet: Close sockets open in http requests
by Nigel Liang 17 Oct '07

17 Oct '07

On 10/13/07, Nigel Liang <ncliang(a)gmail.com> wrote: > Hi, > > Http requests open sockets and forget to close them. Left running over a long > period, the socket file descriptor starts getting large. Once it exceeds > FD_SETSIZE, the behavior becomes unpredictable and results in funcky crashes. > > -Nigel > > --- > dlls/wininet/internet.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/dlls/wininet/internet.c b/dlls/wininet/internet.c > index 0edca74..8e3a98e 100644 > --- a/dlls/wininet/internet.c > +++ b/dlls/wininet/internet.c > @@ -1014,6 +1014,9 @@ BOOL WINAPI InternetCloseHandle(HINTERNE > return FALSE; > } > > + if (lpwh->htype == WH_HHTTPREQ) > + NETCON_close(&((LPWININETHTTPREQW)lpwh)->netConnection); > + > WININET_Release( lpwh ); > WININET_FreeHandle( hInternet ); > > -- > 1.4.1 > > Hi, This patch was sent 4 days ago and it hasn't gone in yet. Could anyone give me some comments on it? Dan filed bug 10032 which is related to this. While we shouldn't be using select() on high FDs for networking, this patch closes the sockets that were open by http requests to avoid getting to high FDs... Thanks, -Nigel

1 0

wnaspi and DVD Burner
by Stefan Leichter 17 Oct '07

17 Oct '07

Hello, i tried to make some progress with Ahead Nero, but now i'm stuck. I found the NeroSDK-1.08.zip and inside the comand line tool NeroAPITest.exe. The source code of NeroAPITest.exe is in the archive too. This makes finding the problems easier. Executing the comand 'wine NeroAPITest.exe --listdrives' the open function in SCSI_OpenDevice fails first with ENOMEDIUM. Putting a disk into the drive the command fails with errno 30 (Read-only). Opening the drive read only works, but next is a write on the file descriptor that fails because it was opened readonly ... The scenario above fails only for my PATA DVD burner. My SCSI DVD reader and my SCSI CD reader are working well with the command sequence listed above. My OS is Debian etch (32bit) the burner is a Plextor PX-716A. Is the reason for this the difference between IDE and SCSI in the kernel? Is it a fault of the DVD burner device (firmware)? What might be a workaround for the problem? Thanks for your thought Stefan

1 0

Wine Stats Malfunctioning
by luis.busquets＠ilidium.com 17 Oct '07

17 Oct '07

Web page: http://www.winehq.org/site/winapi_stats on wine statistics does not work.

2 1

Re: [PATCH] wininet: Substitute strchrW with memchrW in InternetCrackUrlW.txt
by Frank Richter 17 Oct '07

17 Oct '07

On 17.10.2007 06:49, Nigel Liang wrote: > Hi, > > strchrW assumes a NULL-terminated string. May crash if terminating character is > not found. memchrW is better because you can specify the maximum number of > bytes to search. On the flipside, memchrW() doesn't stop at a NUL... -f.r.

2 1

Possible WIne regression with Warcraft
by Michael Lothian 17 Oct '07

17 Oct '07

Hi I've noticed a problem in wine recently. When I try and join a network game in Warcraft I can see the game but I'm unable to join it. These errors are printing out: fireburn@tau ~/.wine/drive_c/Program Files/Warcraft III $ wine Frozen\ Throne.exe ALSA lib conf.c:3949:(snd_config_expand) Unknown parameters 0 ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL default:0 err:ole:CoCreateInstance apartment not initialised fixme:advapi:SetSecurityInfo stub fixme:win:EnumDisplayDevicesW ((null),0,0x34f3d8,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x34f7b0,0x00000000), stub! fixme:win:EnumDisplayDevicesW ((null),0,0x34f3bc,0x00000000), stub! fireburn@tau ~/.wine/drive_c/Program Files/Warcraft III $ fixme:winsock:WSAIoctl unsupported WS_IOCTL cmd (9800000c) fixme:mswsock:AcceptEx (listen=8552, accept=8564, 0x31100e8, 0, 32, 32, 0x34f498, 0x31100b8), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8568, 0x3110170, 0, 32, 32, 0x34f498, 0x3110140), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8572, 0x31101f8, 0, 32, 32, 0x34f498, 0x31101c8), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8576, 0x3110280, 0, 32, 32, 0x34f498, 0x3110250), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8580, 0x3110308, 0, 32, 32, 0x34f498, 0x31102d8), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8584, 0x3110390, 0, 32, 32, 0x34f498, 0x3110360), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8588, 0x3110418, 0, 32, 32, 0x34f498, 0x31103e8), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8592, 0x31104a0, 0, 32, 32, 0x34f498, 0x3110470), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8596, 0x3110528, 0, 32, 32, 0x34f498, 0x31104f8), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8600, 0x31105b0, 0, 32, 32, 0x34f498, 0x3110580), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8604, 0x3110638, 0, 32, 32, 0x34f498, 0x3110608), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8608, 0x31106c0, 0, 32, 32, 0x34f498, 0x3110690), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8612, 0x3110748, 0, 32, 32, 0x34f498, 0x3110718), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8616, 0x31107d0, 0, 32, 32, 0x34f498, 0x31107a0), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8620, 0x3110858, 0, 32, 32, 0x34f498, 0x3110828), not implemented fixme:mswsock:AcceptEx (listen=8552, accept=8624, 0x31108e0, 0, 32, 32, 0x34f498, 0x31108b0), not implemented fixme:imm:ImmAssociateContextEx (0x30028, (nil), 16): stub I'm going to try rolling back to an old version of Wine, I currently use the latest git. I'll post back if it does work. Mike

4 7

Re: widl [1/2]: Improve file cleanup when errors occur
by Alexandre Julliard 17 Oct '07

17 Oct '07

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > @@ -446,10 +441,18 @@ static void rm_tempfile(void) > abort_import(); > if(temp_name) > unlink(temp_name); > - if (header_name) > - unlink(header_name); > - if (client_name) > - unlink(client_name); > - if (server_name) > - unlink(server_name); > + if (nerrors) { > + if (do_header) > + unlink(header_name); > + if (do_client) > + unlink(client_name); > + if (do_server) > + unlink(server_name); > + if (do_idfile) > + unlink(idfile_name); > + if (do_proxies) > + unlink(proxy_name); > + if (do_typelib) > + unlink(typelib_name); > + } This will break cleanup on signals. I think it's better to always remove the files instead of relying on the error count being set correctly. -- Alexandre Julliard julliard(a)winehq.org

1 0

"make test" failure in gdi32/bitmap.c
by Dan Kegel 17 Oct '07

17 Oct '07

"make test" fails for me with: bitmap.c:1113: Test failed: GetDIBits with 4 bpp DIB selected in DC: Invalid DIB bits bitmap.c:1113: Test failed: GetDIBits with 8 bpp DIB selected in DC: Invalid DIB bits err:x11drv:X11DRV_CreateBitmap Trying to make bitmap with planes=1, bpp=24 err:bitmap:DIB_GetBitmapInfo (39): unknown/wrong size for header err:bitmap:DIB_GetBitmapInfo (11): unknown/wrong size for header err:bitmap:DIB_GetBitmapInfo (13): unknown/wrong size for header err:bitmap:DIB_GetBitmapInfo (16): unknown/wrong size for header make[2]: *** [bitmap.ok] Error 2 make[2]: Leaving directory `/home/dank/wine-git/dlls/gdi32/tests' I think this is new since I last ran the tests (at wineconf)...?

3 2

Re: [PATCH] wininet: Conformance test for InternetCrackUrlA.txt
by Dmitry Timoshkov 17 Oct '07

17 Oct '07

"Nigel Liang" <ncliang(a)gmail.com> wrote: > + ok( GetLastError() == ERROR_INVALID_PARAMETER, "Last error wrong: %p\n", > + GetLastError()); GetLastError() returns not a pointer. -- Dmitry.

1 0

Wine 1.0 bugs, release criteria
by Denali Coldstar 16 Oct '07

16 Oct '07

Dan Kegel <dank <at> kegel.com> writes: >* *>* At Wineconf 2007, I was appointed to be the guy who decides *>* (with Alexandre's approval) what bugs are 1.0 bugs and what aren't. *>* So I've started adjusting the "Target Release" fields on a few *>* bugs in Bugzilla. *>* Over the next month or so, I'd like Wine developers to nominate important * >* Comments? *>* - Dan *>* *> === Good Afternoon, I believe Ventrilo meets the criteria set forth in http://wiki.winehq.org/WineReleaseCriteria. In the gaming community, when you use VOIP applications, it generally boils down to TeamSpeak and Ventrilo. While TeamSpeak has a Linux native client, Ventrilo doesn't. I can't necessarily say Vent holds 50% of the market, but I feel safe in saying it holds a significant share of it. This is mainly based on the fact several companies have sprung up over the years to offer hosting of Vent servers. The client can be freely downloaded from the Ventrilo website ( http://www.ventrilo.com/download.php), but I'm not sure if it can be grabbed with wget. Lastly, it does not have an autoupdate but it will pop up a notice if a new version is available. If it is found that Ventrilo would be a suitable program for consideration in the 1.0 release, the following issues would need to be addressed: http://bugs.winehq.org/show_bug.cgi?id=1348 http://bugs.winehq.org/show_bug.cgi?id=5178 http://bugs.winehq.org/show_bug.cgi?id=5924 http://bugs.winehq.org/show_bug.cgi?id=5978 Thank you for reading this post. Steve

2 1

Error compiling progman
by Daniel Nylander 16 Oct '07

16 Oct '07

I have some problems compiling progman. gcc -c -I. -I. -I../../include -I../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o string.o string.c ../../tools/wrc/wrc --nostdinc -I. -I. -I../../include -I../../include -forsrc.res rsrc.rc Xx.rc:23:8: Error: syntax error make: *** [rsrc.res] Error 1 Line 23 in Xx.rc looks like this: CONCAT(MENU_, LANGUAGE_ID) MENU What could be the problem? -- Daniel Nylander (CISSP, GCUX, GCFA) Stockholm, Sweden http://www.DanielNylander.se info(a)danielnylander.se yeager(a)ubuntu.com dnylande(a)gnome.org

2 1

Re: user32: Add more listbox message tests, make them pass under Wine
by Alexandre Julliard 16 Oct '07

16 Oct '07

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > @@ -533,8 +538,11 @@ static INT LISTBOX_GetItemFromPoint( LB_DESCR *descr, INT x, INT y ) > static void LISTBOX_PaintItem( LB_DESCR *descr, HDC hdc, const RECT *rect, > INT index, UINT action, BOOL ignoreFocus ) > { > - LB_ITEMDATA *item = NULL; > - if (index < descr->nb_items) item = &descr->items[index]; > + LB_ITEMDATA *item; > + > + if (index >= descr->nb_items) return; > + > + item = &descr->items[index]; This will break the painting of a focus rect for an empy listbox. We are supposed to show a focus rect on the first item when the listbox has focus, even if there are no items. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [SPAM] Re: USER32: fix EM_SETLIMITTEXT with zeroed args (with tests)
by Alexandre Julliard 16 Oct '07

16 Oct '07

Alex Villacís Lasso <a_villacis(a)palosanto.com> writes: > * Implement OS version-dependent behavior for EM_SETTEXTLIMIT There's no reason to make this OS-dependent, unless you really have an app that checks the version and breaks if the limit is too high. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wordpad: Refuse to load OLE compound storage files like Windows does
by Alexandre Julliard 16 Oct '07

16 Oct '07

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > + IStorage *stg; > + > + if (StgOpenStorage(szOpenFileName, NULL, STGM_SHARE_DENY_WRITE | STGM_READ, > + NULL, 0, &stg) == S_OK) > + { > + IStorage_Release(stg); > + MessageBoxW(hMainWnd, MAKEINTRESOURCEW(STRING_OLE_STORAGE_NOT_SUPPORTED), wszAppTitle, > + MB_OK | MB_ICONEXCLAMATION); > + return; > + } It would be more efficient to simply check the magic number, particularly since we already have support for doing that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ntdll: Fix NtAccessCheck for NULL, but present SACLs and DACLs.
by Juan Lang 15 Oct '07

15 Oct '07

Hi Rob, - sd.sacl_len = (present ? sacl->AclSize : 0); + sd.sacl_len = ((present && dacl) ? sacl->AclSize : 0); Shouldn't that be ((present && sacl) ? sacl->AclSize : 0); ? --Juan

2 1

re: Make test drill, next steps, call for help with Winetest
by Dan Kegel 15 Oct '07

15 Oct '07

>> There is a headless operation mode already, it detects >> if you run it as a service, and skips appropriate tests. > > Perhaps on Windows; I'm focused on Linux. How about wine net start winetest? <ducks> - Dan

1 0

Re: Have `make distclean` also remove .i and .s files
by Alexandre Julliard 15 Oct '07

15 Oct '07

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > After using GCC's -save-temps option to debug something, I noticed > that `make distclean` fails to actually remove .i and .s files. > > This patch fixes it. I hope it's the right place to make this change? It would be, but I don't think we want make clean to remove all possible output files from all possible tools. The current list is probably too much already, it should really be limited to files that are generated as part of the normal build process. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: First batch of Swedish translation patches
by James Hawkins 15 Oct '07

15 Oct '07

On 10/15/07, Daniel Nylander <po(a)danielnylander.se> wrote: > > Here is the first batch of Swedish translation patches. > One patch per email. -- James Hawkins

1 0

Re: Patch for adding Swedish localization
by Robert Shearman 15 Oct '07

15 Oct '07

Daniel Nylander wrote: > Here is the patch to add Swedish localization files to Wine. > Sorry, this is my first patch using git and I'm really unsure if I did > it correctly. > You need to use git-add to include the new files in the commit/patch you sent. -- Rob Shearman

3 6

make crosstest - a catastrophic saga
by Pedro Araújo 15 Oct '07

15 Oct '07

Hi all, I've been consistently failing to 'make crosstest'... I've already tried my distro's repositories, Hans Leidekker's patches, all to no avail. I wish I could use the test suite, but I need some custom local tests and therefore I need to be able to build win32 executables. However, I'm stuck getting this: > security.cross.o: In function `test_ConvertSecurityDescriptorToString':/home/foo/Wine/dlls/advapi32/tests/security.c:1996: undefined reference to `_CreateWellKnownSid@16' > :/home/foo/Wine/dlls/advapi32/tests/security.c:2006: undefined reference to `_CreateWellKnownSid@16' > collect2: ld returned 1 exit status > make[2]: *** [advapi32_crosstest.exe] Error 1 > make[2]: Leaving directory `/home/fooer/Wine/dlls/advapi32/tests' > make[1]: *** [advapi32/tests/__crosstest__] Error 2 > make[1]: Leaving directory `/home/fooer/Wine/dlls' > make: *** [dlls/__crosstest__] Error 2 or this, if I 'make crosstest -C dlls/gdi32/tests/': > bitmap.cross.o: In function `test_GdiAlphaBlend':/home/foo/Wine/dlls/gdi32/tests/bitmap.c:1870: undefined reference to `_GdiAlphaBlend@44' > :/home/foo/Wine/dlls/gdi32/tests/bitmap.c:1872: undefined reference to `_GdiAlphaBlend@44' > :/home/foo/Wine/dlls/gdi32/tests/bitmap.c:1874: undefined reference to `_GdiAlphaBlend@44' > :/home/foo/Wine/dlls/gdi32/tests/bitmap.c:1875: undefined reference to `_GdiAlphaBlend@44' > :/home/foo/Wine/dlls/gdi32/tests/bitmap.c:1876: undefined reference to `_GdiAlphaBlend@44' > bitmap.cross.o:/home/foo/Wine/dlls/gdi32/tests/bitmap.c:1877: more undefined references to `_GdiAlphaBlend@44' follow > collect2: ld returned 1 exit status > make: *** [gdi32_crosstest.exe] Error 1 > make: Leaving directory `/home/fooer/Wine/dlls/gdi32/tests' What am I doing wrong? - Pedro. -- "Compatibility means deliberately repeating other people's mistakes." (David J. Wheeler)

2 1

Re: RICHED20: EM_SETTEXTEX must support RTF strings too
by Daniel Remenak 15 Oct '07

15 Oct '07

When you fix bugs that are documented in comments, please fix the comments also. At the top of the file: EM_SETTEXTEX 3.0 (no rich text insertion handling, proper style?) And in the case itself /* FIXME: this should support RTF strings too, according to MSDN */ Thanks, Daniel Remenak On 10/13/07, a_villacis(a)palosanto.com <a_villacis(a)palosanto.com> wrote: > Another fix for Zoiper (www.zoiper.com). This app can display an About dialog > with a richedit control that displays program credits. The text is a RTF > string pasted with EM_SETTEXTEX, which should result in formatted text being > displayed, but instead results in raw display of RTF codes. The attached > patch fixes this. > > Changelog: > * EM_SETTEXTEX should also support RTF strings, just like WM_SETTEXT > > > >

1 0

re: Wine at Systems in Munich
by Dan Kegel 15 Oct '07

15 Oct '07

It would be great to have a booth there, hope somebody can go. It's kind of hard to do a good booth on short notice, though. Let's remember that this is coming up next year, and plan for it. Can you send me contact info for the organizers? Thanks, Dan

5 4

Re: Fix casts in dlls/crypt32/decode.c
by Robert Shearman 15 Oct '07

15 Oct '07

Gerald Pfeifer wrote: > } > if (!HIWORD(lpszStructType)) > { > - switch (LOWORD(lpszStructType)) > + switch ((DWORD)lpszStructType) > You're just passing the problem on to people doing 64-bit builds. You should use DWORD_PTR or use LOWORD everywhere, like you suggested. -- Rob Shearman

3 2

Re: widl: Generate dlldata files. [resend]
by Robert Shearman 15 Oct '07

15 Oct '07

Dan Hipschman wrote: > if (!parse_only && do_header) write_interface($$); > if (!parse_only && do_idfile) write_iid($$); > pointer_default = $1.old_pointer_default; > + if (!parse_only && !in_typelib && is_attr($$->attrs, ATTR_OBJECT)) > + have_object = TRUE; > } > /* MIDL is able to import the definition of a base class from inside the > * definition of a derived class, I'll try to support it with this rule */ > @@ -828,6 +830,8 @@ interfacedef: interfacehdr inherit > if (!parse_only && do_header) write_interface($$); > if (!parse_only && do_idfile) write_iid($$); > pointer_default = $1.old_pointer_default; > + if (!parse_only && !in_typelib && is_attr($$->attrs, ATTR_OBJECT)) > + have_object = TRUE; > } > | dispinterfacedef { $$ = $1; } > ; > This seems like a bit of a hack because you can find out whether the parsed IDL contains any definitions for objects by traversing the interface tree. -- Rob Shearman

1 0

Re: Swedish translations
by Robert Shearman 15 Oct '07

15 Oct '07

Daniel Nylander wrote: > I have translated a lot of programs and dlls to Swedish. > Would be great if someone could commit this to git. > > http://home.danielnylander.se/translations/wine/wine-sv.tar.gz > > > Please also add the following to the ./tools/wine.desktop > > Name[sv]=Windows-emulatorn Wine > > You need to submit a patch to wine-patches yourself for numerous reasons. You can find out information for doing so at http://www.winehq.org/site/git and http://www.winehq.org/site/sending_patches. -- Rob Shearman

1 0

Re: Swedish translations
by James Hawkins 15 Oct '07

15 Oct '07

On 10/15/07, Daniel Nylander <po(a)danielnylander.se> wrote: > > I have translated a lot of programs and dlls to Swedish. > Would be great if someone could commit this to git. > It's your responsibility to get your own patches accepted. > http://home.danielnylander.se/translations/wine/wine-sv.tar.gz > Please read [1] to figure out how to send patches for inclusion in Wine. [1] http://winehq.org/site/sending_patches -- James Hawkins

1 0

Re: Fix casts in dlls/crypt32/decode.c
by Dmitry Timoshkov 15 Oct '07

15 Oct '07

"Gerald Pfeifer" <gerald(a)pfeifer.com> wrote: > The patch below fixes the following diagnostics (rightfully) issued by > GCC 4.3 and later. If you prefer, we could use LOWORD everywhere, also > for the case labels, but my current patch seems to be more natural. > > decode.c:4365: warning: cast from pointer to integer of different size > --- decode.c 12 Oct 2007 10:24:15 -0000 1.87 > +++ decode.c 14 Oct 2007 14:17:58 -0000 > @@ -4360,103 +4360,103 @@ static CryptDecodeObjectExFunc CRYPT_Get > } > if (!HIWORD(lpszStructType)) > { > - switch (LOWORD(lpszStructType)) > + switch ((DWORD)lpszStructType) Your fix still won't work for a 64-bit target. You would need to use ULONG_PTR cast for that. 'if (!HIWORD(lpszStructType))' line also doesn't look right in the 64-bit case. dlls/crypt32/chain.c,CertVerifyCertificateChainPolicy() has the same problem. -- Dmitry.

1 0

Wiki looks much better
by Juan Lang 15 Oct '07

15 Oct '07

Hi Dimi, I just checked out the Wiki after your most recent checkin. It does, indeed, look much better. Thanks for taking the time to look at it. And, after reviewing the change, I have to agree: it would be hard to predict that the browsers would do what they did based on the old CSS. :-/ --Juan

3 3

CSS changes to the Wiki
by Kai Blin 15 Oct '07

15 Oct '07

Hi folks, I seem to remember that someone posted a patch to the wiki's CSS that will stop the lists from looking ugly. I can't find that patch, though. Can someone point me at it? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

5 8

Re: wined3d: Allow WINED3DFMT_R32F render targets
by H. Verbeet 14 Oct '07

14 Oct '07

On 14/10/2007, Chris Robinson <chris.kcat(a)gmail.com> wrote: > May need more work for this to be proper, but we currently allow R16F render > targets under the same circumstances. It's also enough to make UT3 (which > requires it) happy. > Unless the performance problems with R32F have been fixed, this will cause performance regressions in applications that actually try to use it. (C&C3 for example).

3 5

Re: tools/wineprefixcreate.in: create default w32x86 path under spool/drivers
by Detlef Riekenberg 14 Oct '07

14 Oct '07

On Mi, 2007-10-10 at 13:10 +0200, Markus Gömmel wrote: > + "$CROOT/windows/system32/spool/drivers/w32x86" \ The above Path is created, when we add a Printer Driver in wine. Please update your wine. When you do not start with a clean ~/wine, you need to remove the wine printers below "HKLM\System\CurrentControlSet\Control\Print\Printers" and the wine drivers below "HKLM\System\CurrentControlSet\Control\Print\Environments\*". A "wine notepad" does the rest. When an application try to access this path, I expect, that they fail later, because we have no fake files for "w32x86/3/wineps.drv" and "win40/0/wineps16.drv" yet. -- By by ... Detlef

2 2

Translations
by Daniel Nylander 14 Oct '07

14 Oct '07

I would like to contribute to the Wine project by submitting Swedish translations. I would really like to translate the graphical tools (such as winecfg) but as I can see it, it's not possible at the moment. Have you thought about implementing some sort of i18n/l10n framework? Regards, Daniel Nylander Stockholm, Sweden

2 4

Re: libs/wine/mmap.c: conditionally provide reserve_area()
by Vitaliy Margolen 14 Oct '07

14 Oct '07

Gerald Pfeifer wrote: > Noticed on FreeBSD; patch tested on FreeBSD 5.4 as well as SUSE Linux > 10.0. > > Gerald > > ChangeLog: > Only provide reserve_area() when we actually use it. > > Index: mmap.c > =================================================================== > RCS file: /home/wine/wine/libs/wine/mmap.c,v > retrieving revision 1.20 > diff -u -3 -p -r1.20 mmap.c > --- mmap.c 26 Jan 2007 13:48:42 -0000 1.20 > +++ mmap.c 14 Oct 2007 11:09:28 -0000 In this and all of your patches, please diff from the top of the tree. The above line should say "+++libs/wine/mmap.c". And it would be even better if you can use GIT instead of cvs. Vitaliy.

2 1

Re: USER32: fix EM_SETLIMITTEXT with zeroed args (with tests)
by Detlef Riekenberg 14 Oct '07

14 Oct '07

On Fr, 2007-10-12 at 19:42 -0500, a_villacis(a)palosanto.com wrote: You must use your real name to get a patch accepted. > + /* Maximum limits set by EM_SETLIMITTEXT vary by OS version */ > + osVersion = GetVersion(); > + if (osVersion < 0x80000000) { > + /* WinNT, Win2K, WinXP */ > + limitSingleLine = 2147483646UL; > + limitMultiLine = 4294967295UL; > + } else { > + /* Win9x, WinME */ > + limitSingleLine = 32766; > + limitMultiLine = 65535; > + } The tests should not depend on the OS-Version. Please handle both possible results in the ok() > + /* Test default limit for single-line control */ > + trace("EDIT: buffer limit for single-line\n"); > + hwEdit = create_editcontrol(ES_AUTOHSCROLL | ES_AUTOVSCROLL, 0); > + r = SendMessage(hwEdit, EM_GETLIMITTEXT, 0, 0); > + ok(r == 30000, "Incorrect default text limit, expected 30000 got > %u\n", r); > + SendMessage(hwEdit, EM_SETLIMITTEXT, 0, 0); > + r = SendMessage(hwEdit, EM_GETLIMITTEXT, 0, 0); /* Win9x+ME: 32766; WinNT: 2147483646UL */ ok( (r == 32766) || (r == 2147483646UL), "got limit %u (expected 32766 or 2147483646)\n", r); > + ok(r == limitSingleLine, "Incorrect default text limit, expected > %u got %u\n", limitSingleLine, r); Your looks like a copy&paste error ("default text limit" is wrong here). Change the multiline-test the same way. To allow an easy review, you can split your patch: one patch for the implementation and a second patch for the test. Thanks for helping wine -- By by ... Detlef

1 0

Re: [PATCH] wininet: NULL terminate url string passed to InternetCrackUrlW from InternetCrackUrlA.txt (try 3)
by Francois Gouget 14 Oct '07

14 Oct '07

On Sat, 13 Oct 2007, Nigel Liang wrote: > Hi, > > InternectCrackUrlW calls strchrW which assumes a NULL-terminated string. Will > crash without NULL termination if you upload/download for long period of time. The MSDN has this to say about InternetCrackUrlW(): dwUrlLength Size of the lpszUrl string, in TCHARs, or zero if lpszUrl is an ASCIIZ string. So if InternetCrackUrlW() assumes that lpwszUrl is zero-terminated then it is buggy. So the fix belong in InternetCrackUrlW(), not in InternetCrackUrlA(). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

1 0

Wine crashes while trying to use Lexmark Network Scanback utility
by King InuYasha 14 Oct '07

14 Oct '07

Ehh, well, I was trying to use the Lexmark Scanback Utility to operate my Lexmark OptraImage 322 and it crashed after clicking the button to setup a new profile.... Installed original MFC42.DLL in the Scanback program folder... Crash log: [InuTaisho@PIIMMX-GTWE4200 ScanBack]$ wine scanwiz.exe wine: Call from 0x40ee68 to unimplemented function MFC42.DLL.6905, aborting wine: Unimplemented function MFC42.DLL.6905 called at address 0x40ee68 (thread 0038), starting debugger... Unhandled exception: unimplemented function MFC42.DLL.6905 called in 32-bit code (0x602e4d4c). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:602e4d4c ESP:0034dbd4 EBP:0034dc38 EFLAGS:00000206( - 00 - -IP1) EAX:00001af9 EBX:6032fa78 ECX:0034e938 EDX:00030068 ESI:0034dbe0 EDI:0003006c Stack dump: 0x0034dbd4: 00000038 00030068 0100101b 80000100 0x0034dbe4: 00000001 00000000 0040ee68 00000002 0x0034dbf4: 0041cca6 00001af9 0034dc3c 6062e98e 0x0034dc04: 5f422d22 00030068 00000000 00000038 0x0034dc14: 00030068 00001036 00000000 00000020 0x0034dc24: 00000000 00000000 00000000 0034e8d8 Backtrace: =>1 0x602e4d4c in ntdll (+0x24d4c) (0x0034dc38) 2 0x0040ee68 in scanwiz (+0xee68) (0x0034e938) 3 0x00000001 (0x00419bc8) 4 0x0040fed0 in scanwiz (+0xfed0) (0x0041524c) 5 0x25ff0041 (0x837c25ff) 6 0x00000000 (0x00000000) 0x602e4d4c: subl $4,%esp Modules: Module Address Debug info Name (67 modules) PE 400000- 420000 Export scanwiz PE 10000000-10035000 Deferred scanwizg ELF 41d2d000-41d4a000 Deferred ld-linux.so.2 ELF 41d4c000-41d60000 Deferred libresolv.so.2 ELF 426fe000-42852000 Deferred libc.so.6 ELF 42854000-4287d000 Deferred libm.so.6 ELF 4287f000-42884000 Deferred libdl.so.2 ELF 4289b000-428b3000 Deferred libpthread.so.0 ELF 428b5000-428b8000 Deferred libxau.so.6 ELF 428ba000-428c0000 Deferred libxdmcp.so.6 ELF 428c2000-429c4000 Deferred libx11.so.6 ELF 429c6000-429d6000 Deferred libxext.so.6 ELF 429d8000-42a62000 Deferred libfreetype.so.6 ELF 42a64000-42a85000 Deferred libexpat.so.0 ELF 42aaf000-42ade000 Deferred libfontconfig.so.1 ELF 42ae0000-42ae9000 Deferred libxrender.so.1 ELF 42af5000-42aff000 Deferred libxcursor.so.1 ELF 42b01000-42b08000 Deferred libxrandr.so.2 ELF 42b0a000-42b0d000 Deferred libxinerama.so.1 ELF 42b0f000-42b14000 Deferred libxfixes.so.3 ELF 42bc5000-42bce000 Deferred libsm.so.6 ELF 42bd0000-42bea000 Deferred libice.so.6 ELF 4347a000-43485000 Deferred libdrm.so.2 ELF 43487000-434f7000 Deferred libgl.so.1 ELF 43fcb000-43fd0000 Deferred libxxf86vm.so.1 PE 5f400000-5f4ed000 Deferred mfc42 ELF 6001d000-60132000 Deferred libwine.so.1 ELF 602a3000-6034b000 Export ntdll<elf> \-PE 602c0000-6034b000 \ ntdll ELF 60374000-60380000 Deferred libnss_files.so.2 ELF 60380000-604b5000 Deferred kernel32<elf> \-PE 603a0000-604b5000 \ kernel32 ELF 604b5000-604cf000 Deferred version<elf> \-PE 604c0000-604cf000 \ version ELF 604cf000-604e3000 Deferred lz32<elf> \-PE 604e0000-604e3000 \ lz32 ELF 604e3000-6054f000 Deferred msvcrt<elf> \-PE 604f0000-6054f000 \ msvcrt ELF 6054f000-6059c000 Deferred advapi32<elf> \-PE 60560000-6059c000 \ advapi32 ELF 6059c000-606ea000 Deferred user32<elf> \-PE 605c0000-606ea000 \ user32 ELF 606ea000-607f6000 Deferred shell32<elf> \-PE 60700000-607f6000 \ shell32 ELF 607f6000-60853000 Deferred shlwapi<elf> \-PE 60800000-60853000 \ shlwapi ELF 60853000-6091a000 Deferred comctl32<elf> \-PE 60860000-6091a000 \ comctl32 ELF 6091a000-60978000 Deferred rpcrt4<elf> \-PE 60930000-60978000 \ rpcrt4 ELF 60978000-60997000 Deferred iphlpapi<elf> \-PE 60980000-60997000 \ iphlpapi ELF 609ab000-609d8000 Deferred ws2_32<elf> \-PE 609b0000-609d8000 \ ws2_32 ELF 60a28000-60abd000 Deferred winex11<elf> \-PE 60a40000-60abd000 \ winex11 ELF 60c8e000-60cac000 Deferred imm32<elf> \-PE 60ca0000-60cac000 \ imm32 ELF 60cbb000-60cef000 Deferred uxtheme<elf> \-PE 60cc0000-60cef000 \ uxtheme ELF 627d4000-62878000 Deferred gdi32<elf> \-PE 627f0000-62878000 \ gdi32 ELF 63167000-63213000 Deferred ole32<elf> \-PE 63180000-63213000 \ ole32 ELF 6875e000-68778000 Deferred wsock32<elf> \-PE 68760000-68778000 \ wsock32 ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000037 (D) C:\Program Files\Lexmark\ScanBack\scanwiz.exe 00000038 0 <== 00000013 00000015 0 00000014 0 0000000f 00000016 0 00000010 0 0000000a 0000000c 0 0000000b 0 wine: Call from 0x40ee68 to unimplemented function MFC42.DLL.6905, aborting wine: Call from 0x40ee68 to unimplemented function MFC42.DLL.6905, aborting

3 3

Re: RICHED20: EM_SETTEXTEX must support RTF strings too
by Dmitry Timoshkov 14 Oct '07

14 Oct '07

<a_villacis(a)palosanto.com> wrote: > Changelog: > * EM_SETTEXTEX should also support RTF strings, just like WM_SETTEXT It would be helpful to have a test case for this, as well as a unicode version of WM_SETTEXT/EM_SETTEXTEX. -- Dmitry.

1 0

Support GCOV for Wine 1.0?
by Detlef Riekenberg 13 Oct '07

13 Oct '07

Hi. A while ago (2004), there was some work about wine with gcov, with the focus on "Picassa 2": ( http://www.cs.hmc.edu/clinic/projects/2004/google/ ) Final Report: ( http://www.cs.hmc.edu/clinic/projects/2004/google/final_report/main.pdf ) It would be nice, when we can support gcov in current Wine "out of the box". That would help us a lot, when we write more tests for the suggested Wine 1.0 Applications. GCOV: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html -- By by ... Detlef

7 15

WineHQ for Wine 1.0
by Alex Waite 13 Oct '07

13 Oct '07

Awhile ago I sent a few patches in to cleanup some HTML and CSS on WineHQ. I didn't continue with writing more patches since it seemed like we didn't have a clear idea of what direction we wanted to pursue. I am more than happy to help with a rewrite or update of the site, but as long as we have an plan of what we want to accomplish and how to go about it. With the release of Wine 1.0 coming... sometime... in the future, it would make sense if we had an updated website to accompany that release. From my point of view, the following are some big problems with the current site: * Not pretty: while not awful, there are better color schemes and layouts in the world. We can also look at some usability improvements. If people are partial to it, we can still use the winish-red color, but I think we can use it in a more attractive way than we do now. * Table-hell: This is where I tout the joys of <div>'s and CSS. Tables are a pain to deal with and bloat the code quite a bit. Not to mention that they make pages pretty inaccessible. * Accessibility: Tables are the big culprit here, but there's also simple things like making the code valid. There's also some fairly straightforward ways of writing code which help a lot (precede lists with headers, nest headers correctly, etc). While accessibility doesn't have to be perfect, I think it promotes well written code and makes pages more accessible to more people. * Valid code: This is a principal to me. I think if code is to be written, it should be written correctly. Wine is known for not accepting hacks or improper fixes; I think our website should reflect that, especially since the spec is not hard to conform to. Let me know if you are interested in help. I hope everyone is having fun at WineConf. ---Alex

2 1

Re: Call of Dutty 4 works!!
by Mirek Slugeň 13 Oct '07

13 Oct '07

1 0

make test drill
by Jeremy White 13 Oct '07

13 Oct '07

So, in a radical break from tradition, we're trying to accomplish something useful at Wineconf. Specifically, we're making 'make test' work for everyone, not just Alexandre. Maarten Lankhorst is maintaining a tree of all of our test related patches. So, for those that want to play, the thing to do is to git fetch git://repo.or.cz/wine/testsucceed.git master:testsucceed git rebase testsucceed Then you can do a make test (with a clean .wine directory) and share your results. It's useful to use Dan's filter: egrep '__test|make.*ok|Backtrace' <your-log-file-here> Up through the end of day tomorrow, you can send me the results of that egrep and I'll tally and triage. If you have a patch, send it in, and CC Maarten so he can update it. The goal is to have the number of failures as close to 0 as possible, and for the non 0 cases, to at least understand each failure. Cheers, Jeremy

8 14

Re: USER32: fix EM_SETLIMITTEXT with zeroed args (with tests)
by Francois Gouget 13 Oct '07

13 Oct '07

On Fri, 12 Oct 2007, a_villacis(a)palosanto.com wrote: [...] > This patch implements the higher limits for EM_SETLIMITTEXT with > zeroed wParam and lParam, when the reported Windows version is WinNT, > Win2k and higher. It also implements a default maximum limit of 30000 > before receiving any EM_SETLIMITTEXT message. Tests are given for all > of this. I have not read the patch, but unless there is a Win9x application that depends on the lower limit, it would be better to simply always support the higher size, independently of the emulated Windows version. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

1 0

Call of Dutty 4 works!!
by Mirek Slugeň 12 Oct '07

12 Oct '07

Hi, I just tried Call of Dutty 4 Demo in latest wine, and it is working, there are some problems with graphic (gun or units are not visible), but it works, good work!!! Here are some screenshots: http://78.108.96.64/wine/ Mirek

1 0

stdout for win16 tests
by Dan Kegel 12 Oct '07

12 Oct '07

win16 doesn't have the notion of stdout/stderr, so 16 bit C compilers like watcom tend to simulate stdout by putting up a window. http://win16test.googlecode.com/svn/trunk/src/test.h (a port of the 32 bit test.h) uses freopen to open a log file to receive all the ok() and trace() output from the tests instead of letting it go to the fake stdout window. That's fine, but it means that crashes and wine output from wine itself don't get mixed in properly (since they go to linux stderr, not to win16 "stderr"). So I threw together a patch that uses the dos stdout that is shared by all win16 apps. Not sure if it's the right way to go, but it does let you use plain old redirection to capture the log messages, and it lets you redirect both test app traces and wine traces to the same file. I'm sending it to wine-devel mostly so Lei and anyone else working on the 16 bit tests can have a look. I haven't had a chance to pursue this further myself. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: imm32: Avoid spamming the debug output.
by EA Durbin 12 Oct '07

12 Oct '07

Imm is disabled by default on North American Windows installations. That's a behavior I think should be mimicked in wine. http://msdn2.microsoft.com/en-us/library/ms776161.aspx IMM is only enabled on East Asian (Chinese, Japanese, Korean) localized Windows operating systems. On these systems, the application calls GetSystemMetrics with SM_DBCSENABLED to determine if IMM is enabled. _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

1 0

Re: server: Use the security descriptor passed in when creating events.
by Alexandre Julliard 12 Oct '07

12 Oct '07

Robert Shearman <rob(a)codeweavers.com> writes: > Use a new object_attributes struct for passing the information about > whether a security descriptor is specified or not to the server. This breaks Photoshop CS2, we segfault while trying to access a security descriptor it gives us. -- Alexandre Julliard julliard(a)winehq.org

2 1

defining and revamping our bugzilla categories
by Jan Zerebecki 12 Oct '07

12 Oct '07

I agree the wine- prefix should be removed. Currently we have quite some categories where I don't really know how they are defined, so the description should be enhanced so there is no confusion over what goes in them. Currently we have some categories that exactly fit to one dll and some categories that include multiple dlls that are related. Also there is overlap between those two. (And perhaps some that fit in neither.) E.g. there is wine-quartz (one dll dlls/quartz/ ) and wine-directx-dshow (includes dlls/{quartz,msdmo,qcap}/ ). The best is probably to have no overlap and have multi-dll/path categories contain the shell-glob of path/files that it contains. I think in some cases multi-dll categories are preferable to single-dlls ones. A even better example for this than dshow is wine-directx-d3d, where before the bug is fixed it might not be easily known if it is in d3d9 or wined3d and a bug might exist in the same way in more than one d3d version. >From previous discussions on irc I know some people want to have a radical one category per dll approach, please speak up now. What do you guys think? Jan PS: Sorry for the previous empty mail.

8 15

1.0 Bugs - Microsoft Office 2003
by EA Durbin 12 Oct '07

12 Oct '07

I was able to get around bug 9023 with a patch applied to the appdb and I did some further testing in Office 2003 today. Initially I'm prompted to activate my copy of microsoft office 2003, and both means of activating the application are broken in wine due to bugs 9943 and 9944. Then I tried to open VBA inside of Office and was prompted with a dialog stating unable to open macro storage(bug 8795). The only real reason I use Microsoft Office over Open Office is the need for VBA integration. I think we should add these bugs to the 1.0 target 9943 9944 8795 _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

3 3

request for kernel32/toolhelp windows testrun
by Marcus Meissner 12 Oct '07

12 Oct '07

Hi, I have a game (Last Chaos USA by AeriaGames) which does not start up the main game due to a bug in its toolhelp snaphot handling. It does: h = CreateToolhelp32Snapshot(); Process32First(h, &x); while (Process32Next(h,&x)) { /* check x */ } So it discards the very first entry we return from the snapshot. However it is looking for itself here and in current Wine it is in the first entry, ... so failure. So I reorder the list to be backwards and it works better then. BUT I would like to test run it on windows first, so can someone please run following patch against a real Windows? Thanks & Ciao, Marcus diff --git a/dlls/kernel32/tests/toolhelp.c b/dlls/kernel32/tests/toolhelp.c index ca9c06c..f135abb 100644 --- a/dlls/kernel32/tests/toolhelp.c +++ b/dlls/kernel32/tests/toolhelp.c @@ -108,6 +108,7 @@ static void test_process(DWORD curr_pid, MODULEENTRY32 me; unsigned found = 0; int num = 0; + int pos1 = -1 , pos2 = -1; hSnapshot = pCreateToolhelp32Snapshot( TH32CS_SNAPPROCESS, 0 ); ok(hSnapshot != NULL, "Cannot create snapshot\n"); @@ -118,8 +119,8 @@ static void test_process(DWORD curr_pid, { do { - if (pe.th32ProcessID == curr_pid) found++; - if (pe.th32ProcessID == sub_pcs_pid) found++; + if (pe.th32ProcessID == curr_pid) { pos1 = num; found++; } + if (pe.th32ProcessID == sub_pcs_pid) { pos2 = num; found++; } trace("PID=%x %s\n", pe.th32ProcessID, pe.szExeFile); num++; } while (pProcess32Next( hSnapshot, &pe )); @@ -141,6 +142,9 @@ static void test_process(DWORD curr_pid, ok(found == 2, "couldn't find self and/or sub-process in process list\n"); ok(!num, "mismatch in counting\n"); + ok (pos2 == 1, "new process at position %d in snapshot, expected 1.\n", pos2); + ok (pos1 == 0, "this process at position %d in snapshot, expected 0.\n", pos1); + te.dwSize = sizeof(te); ok(!pThread32First( hSnapshot, &te ), "shouldn't return a thread\n");

3 4

Re: WineD3D: p8 improvements 2/2
by H. Verbeet 12 Oct '07

12 Oct '07

On 11/10/2007, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > + "MUL index.x, index.x, constants.x;\n" /* Scale the index by 255/256 */ > + "ADD index.x, index.x, constants.y;\n" /* Add a bias of '0.5' in order to sample in the middle */ Why not use a MAD there?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel