wine-devel November 2007

wine-devel@winehq.org

117 participants
275 discussions

#winehq admin troubles
by Luke Bratch 05 Nov '07

05 Nov '07

Chris Morgan wrote: > 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. I don't often hang out in #winehq, but I do follow Bugzilla religiously, and I used to think bad things about Vitamin too, because of the way he would reply to various people (generally newcomers). However as time goes on I can now see that he is quite right in how he deals with people - it is good to be strict with people, as it will hopefully give them a kick up the backside in the right direction. If I blundered into a new online community and didn't behave in a constructive or useful manor, people shouting at me would certainly make me get my act sorted out, whereas people acting normally might make me carry on in the same way. After seeing Vitamin deal with people for a long time now, I can say I totally agree with how he does things. Luke ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

1 0

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

Jump to page:

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 November 2007