March 2009 - Wine-devel - list.winehq.org

re: wine shirts
by Dan Kegel 02 Mar '09

02 Mar '09

That's a nice, simple design, but something's missing. Oddly, the original drunken penguin shirts, or ripoffs thereof, seem to still be available at http://www.ixsoft.de/software/products/CWTSHIRTDP-L.html Original artwork is at ftp://wine.codeweavers.com/pub/wine/logos/ I would kind of like a shirt that had the penguin opening the bottle on the front (text: Support the Wine Project), and the drunken penguin on the back (text: I did my part, or something like that) but I'd have to think a bit more on the text. Other old links: Martin's design: http://cross-lfs.org/~mlankhorst/t-shirt.png Ismael Barros put some effort into this before: http://www.winehq.org/pipermail/wine-devel/2008-December/070894.html but nobody could think up good text. - Dan

2 1

storing the registry key class name to make PDFXChange-Viewer happy
by Patrick Pfeifer 02 Mar '09

02 Mar '09

Dear Developpers of Wine I like wine and I like Tracker Software's PDFXChange-Viewer as well. http://www.docu-track.com/home/prod_user/PDF-XChange_Tools/pdfx_viewer So, today I was not getting any rest until i found out why these two won't work together nicely. I mean they DO, actually. But I'm kind of touchy. I was wondering all the time, why most of the settings I changed were not restored as I exited and restarted the app. I then discovered that if wineserver was preserved ("-p" option) beween restarts they WERE restored. Further investigations unveiled that the problem is triggered by the fact that wineserver is not storing the registry key class name attributes. Something M$ must have come up with in XP but that is not very wideley used. PDFXChange-Viewer however seems to rely on it when parsing it's preferences from the registry on startup. Wineservers unicode string handling gave me a though time in implementing a solution to this but i finally managed. You can see that I went quiet straightforward: adding the class name next to the key name in the {system,user}.reg files. There are two different versions of the fix. I would prefer the second one because it preserves backwards compatibility: In case the key class attribute is set, it is put in brackets between the key name and modification time. Otherwise nothing changes. It would be really nice if this could be somehow integrated into wine. (Not only because I worked on it for a whole day, but also because i really miss the feature because i don't want to reconfigure PDFXChange-Viewer every time i start it and also because I would like to make that functionality available to all of my friends and all linux users as well. Greets Patrick [Software\\Tracker Software\\PDFViewer\\FullScreen\\MainView\\Bars\\0011;ParamItem] 1235760987 "Break"=dword:00000001 "ID"=dword:000081c9 "Name"="Properties" [Software\\Tracker Software\\PDFViewer\\FullScreen\\MainView\\Bars\\0011] [ParamItem] 1235761189 "Break"=dword:00000001 "ID"=dword:000081c9 "Name"="Properties" --- registry.c 2009-02-27 19:44:14.000000000 +0100 +++ registry.PP1.c 2009-02-27 19:49:03.000000000 +0100 @@ -176,7 +176,7 @@ dump_path( key->parent, base, f ); fprintf( f, "\\\\" ); } - dump_strW( key->name, key->namelen / sizeof(WCHAR), f, "[]" ); + dump_strW( key->name, key->namelen / sizeof(WCHAR), f, "[;" ); } /* dump a value to a text file */ @@ -245,6 +245,8 @@ { fprintf( f, "\n[" ); if (key != base) dump_path( key, base, f ); + fprintf( f, ";" ); + dump_strW( key->class, key->classlen / sizeof(WCHAR), f, "[]" ); fprintf( f, "] %ld\n", (long)key->modif ); for (i = 0; i <= key->last_value; i++) dump_value( &key->values[i], f ); } @@ -1108,20 +1110,22 @@ int prefix_len, struct file_load_info *info, int default_modif ) { - WCHAR *p; - struct unicode_str name; - int res, modif; - data_size_t len; + WCHAR *p, cls[256]; + struct unicode_str name, class; + int res, res2, modif; + data_size_t len, len2 = 256; if (!get_file_tmp_space( info, strlen(buffer) * sizeof(WCHAR) )) return NULL; len = info->tmplen; - if ((res = parse_strW( info->tmp, &len, buffer, ']' )) == -1) + if ((res = parse_strW( info->tmp, &len, buffer, ';' )) == -1 || + (res2 = parse_strW( cls, &len2, buffer+res, ']' ) == -1)) { file_read_error( "Malformed key", info ); return NULL; } - if (sscanf( buffer + res, " %d", &modif ) != 1) modif = default_modif; + + if (sscanf( buffer + res + res2, " %d", &modif ) != 1) modif = default_modif; p = info->tmp; while (prefix_len && *p) { if (*p++ == '\\') prefix_len--; } @@ -1138,7 +1142,10 @@ } name.str = p; name.len = len - (p - info->tmp + 1) * sizeof(WCHAR); - return create_key( base, &name, NULL, flags, modif, &res ); + class.str = cls; + class.len = len2 - sizeof(WCHAR); + + return create_key( base, &name, &class, flags, modif, &res ); } /* parse a comma-separated list of hex digits */ --- registry.c 2009-02-27 19:44:14.000000000 +0100 +++ registry.PP2.c 2009-02-27 19:59:28.000000000 +0100 @@ -245,6 +245,10 @@ { fprintf( f, "\n[" ); if (key != base) dump_path( key, base, f ); + if (key->class != NULL) { + fprintf( f, "] [" ); + dump_strW( key->class, key->classlen / sizeof(WCHAR), f, "[]" ); + } fprintf( f, "] %ld\n", (long)key->modif ); for (i = 0; i <= key->last_value; i++) dump_value( &key->values[i], f ); } @@ -1108,10 +1112,10 @@ int prefix_len, struct file_load_info *info, int default_modif ) { - WCHAR *p; - struct unicode_str name; - int res, modif; - data_size_t len; + WCHAR *p, *c; + struct unicode_str name, class; + int res, c_res, modif; + data_size_t len, c_len; if (!get_file_tmp_space( info, strlen(buffer) * sizeof(WCHAR) )) return NULL; @@ -1121,6 +1125,23 @@ file_read_error( "Malformed key", info ); return NULL; } + + c_len = info->tmplen - len; + if ((c_res = parse_strW( info->tmp + len / sizeof(WCHAR), &c_len, buffer + res, ']' )) == -1) + { + class.len = 0; + } + else + { + res += c_res; + + c = info->tmp + len / sizeof(WCHAR); + while (*c) { if (*c++ == '[') break; } + + class.str = c; + class.len = c_len - (c - (info->tmp + len / sizeof(WCHAR)) + 1) * sizeof(WCHAR); + } + if (sscanf( buffer + res, " %d", &modif ) != 1) modif = default_modif; p = info->tmp; @@ -1138,6 +1159,9 @@ } name.str = p; name.len = len - (p - info->tmp + 1) * sizeof(WCHAR); + + if (class.len > 0) + return create_key( base, &name, &class, flags, modif, &res ); return create_key( base, &name, NULL, flags, modif, &res ); }

2 1

Re: Fixed a number of buffer overflows with cmd, bug #13469
by Vincent Povirk 02 Mar '09

02 Mar '09

Send only one patch per mail, please. Vincent Povirk On Mon, Mar 2, 2009 at 8:41 AM, Diaa Sami <diaasami(a)gmail.com> wrote: > , > > > >

1 0

Kernel32 profile/INI mappings to registry
by Silver Blade 02 Mar '09

02 Mar '09

Hi guys, Whilst looking into some winmm.dll modifications for ReactOS, I found that the Drivers and Drivers32 registry keys (used for determining the wavemapper, midi devices etc.) effectively replace those entries found in SYSTEM.INI of previous Windows versions. Looking around in the registry reveals that Windows has a set of registry keys that effectively map INI file sections to other registry keys. This mapping is handled by the various "profile" APIs exported by kernel32, and is described on MSDN for the "GetPrivateProfileString" API: http://msdn.microsoft.com/en-us/library/ms724353(VS.85).aspx# Since ReactOS imports WINE's kernel32, I checked WINE's kernel32 source code and found that this mapping doesn't take place. This in itself doesn't pose a problem - INI files work, after all! However IMO it may be worth implementing this functionality, and this is something I would be interested in doing. It makes more sense (to me anyway) to implement this in WINE rather than directly in ReactOS. And it seems relatively trivial. Just thought I'd post here and gather any thoughts on this? Regards, Andrew Greenwood _________________________________________________________________ 25GB of FREE Online Storage – Find out more http://clk.atdmt.com/UKM/go/134665320/direct/01/

2 1

kernel32/tests: Mark debugger test broken for Win9x and WinME behavior
by Drew Ronneberg 02 Mar '09

02 Mar '09

3 4

CreateThread timing behaviour (Bug 15323 affecting Warhammer Online)
by Paul TBBle Hampson 02 Mar '09

02 Mar '09

I'm looking into Bug 15323, and it seems to come down to a particular undocumented behaviour of CreateThread on Windows, which is probably also a bug in the usage of it by warpatch.bin, the Warhammer Online patcher. Problem code outline: Main thread: flag = false; createThread( newThreadFun ) sleep until flag = false; newThreadFun: flag = true CreateHiddenWindowAndWaitForMessageFromMainThread; flag = false; return; On inspection, the only way this can work is if the main thread's "sleep until" test is done before newThreadFun gets started. And this is what we see. If the sleep is hit, the patcher never shows any windows or continues on. If the patcher works, we _never_ slept. I've attached a hack patch against kernel32's thread test suite which reduces it to a single test of this behaviour. Under Windows, the test always passes, at least in my limited testing. Under Wine, the test usually fails if wineserver is not already running, and usually passes if wineserver is already running. However, both cases can also give the opposite result every so often. This matches the observed problems starting the Warhammer Online patcher. So anyway, I guess the question is, am I right about this behaviour or have I overlooked something relevant? And the follow-up question, if this is a threading behaviour difference between Wine and MS Win32, should Wine replicate it? And then the follow-up to the follow-up... How would this be replicated? Maybe a new thread should start at a slightly lower priority than its parent thread? Or simply have ntdll/thread.c's start_thread call sched_yield(); before call_thread_func. I tried this last idea, and the test passed more often, but still failed frequently with no wineserver running. It also improved the chances of warpatch starting correctly (I only had one failure in about ten tries, rather than nine failures in ten tries). -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

3 6

Re: storing the registry key class name to make PDFXChange-Viewer happy
by Patrick 02 Mar '09

02 Mar '09

On Son, 2009-03-01 at 19:07 -0600, Austin English wrote: > On Sun, Mar 1, 2009 at 11:41 AM, Patrick <ragamuffin(a)datacomm.ch> wrote: > > On Sam, 2009-02-28 at 19:04 -0600, Austin English wrote: > >> On Sat, Feb 28, 2009 at 7:04 PM, Austin English <austinenglish(a)gmail.com> wrote: > >> > On Sat, Feb 28, 2009 at 12:37 AM, Patrick <ragamuffin(a)datacomm.ch> wrote: > >> >> Dear Developpers of Wine > >> >> > >> >> I like wine and I like Tracker Software's PDFXChange-Viewer as well. > >> >> http://www.docu-track.com/home/prod_user/PDF-XChange_Tools/pdfx_viewer > >> >> > >> >> So, today I was not getting any rest until i found out why these two > >> >> won't work together nicely. I mean they DO, actually. But I'm kind of > >> >> touchy. I was wondering all the time, why most of the settings I changed > >> >> were not restored as I exited and restarted the app. > >> >> > >> >> I then discovered that if wineserver was preserved ("-p" option) beween > >> >> restarts they WERE restored. Further investigations unveiled that the > >> >> problem is triggered by the fact that wineserver is not storing the > >> >> registry key class name attributes. Something M$ must have come up with > >> >> in XP but that is not very wideley used. PDFXChange-Viewer however seems > >> >> to rely on it when parsing it's preferences from the registry on > >> >> startup. > >> >> > >> >> Wineservers unicode string handling gave me a though time in > >> >> implementing a solution to this but i finally managed. You can see that > >> >> I went quiet straightforward: adding the class name next to the key name > >> >> in the {system,user}.reg files. There are two different versions of the > >> >> fix. I would prefer the second one because it preserves backwards > >> >> compatibility: In case the key class attribute is set, it is put in > >> >> brackets between the key name and modification time. Otherwise nothing > >> >> changes. > >> >> > >> >> It would be really nice if this could be somehow integrated into wine. > >> >> (Not only because I worked on it for a whole day, but also because i > >> >> really miss the feature because i don't want to reconfigure > >> >> PDFXChange-Viewer every time i start it and also because I would like to > >> >> make that functionality available to all of my friends and all linux > >> >> users as well. > >> >> > >> >> Greets > >> >> > >> >> Patrick > >> >> > >> >> > >> >> [Software\\Tracker Software\\PDFViewer\\FullScreen\\MainView\\Bars\\0011;ParamItem] 1235760987 > >> >> "Break"=dword:00000001 > >> >> "ID"=dword:000081c9 > >> >> "Name"="Properties" > >> >> > >> >> [Software\\Tracker Software\\PDFViewer\\FullScreen\\MainView\\Bars\\0011] [ParamItem] 1235761189 > >> >> "Break"=dword:00000001 > >> >> "ID"=dword:000081c9 > >> >> "Name"="Properties" > >> >> > >> >> --- registry.c 2009-02-27 19:44:14.000000000 +0100 > >> >> +++ registry.PP1.c 2009-02-27 19:49:03.000000000 +0100 > >> >> --- registry.c 2009-02-27 19:44:14.000000000 +0100 > >> >> +++ registry.PP2.c 2009-02-27 19:59:28.000000000 +0100 > >> >> > >> > > >> > Patches should be sent in git diff format to wine-patches(a)winehq.org. > >> > > >> > See http://wiki.winehq.org/Patching > >> > > >> > Thanks for helping Wine! > >> > > >> > -- > >> > -Austin > >> > > >> > >> Err, make that http://wiki.winehq.org/SubmittingPatches > >> > > > > Sorry, lenghty conformance tests & learning git would take me another > > day.... It's unlikely that I'll do that before Christmas 2010 or so... > > Thank you for the reply anyway! > > > > In case anybody wants to use the code - put it through the whole > > preocess - modify it or implement the idea in another way, he should > > feel free to do so. It's hereby set free from any license/copyright or > > other obstacles. You could even claim that you wrote it yourself ;-) I > > won't mind. Just get it into wine somehow. > > > > Patrick > > > > > > Is this supposed to apply to server/registry.c? It doesn't apply in latest git.. > Yes, server/registry.c I've improved V2 slightly and made it apply on latest git. And I tested it now - it builds and does what it's supposed to do. Which means PDFXChange-Viewer works, keeps its settings and there are no side effects. One line there class.len = c_len - (c - (info->tmp + len / sizeof(WCHAR)) + 1) * sizeof(WCHAR); looks "ugly" to my eyes as well, but it's correct, so... >From 8a7fd46edc1192461fa2f7ea48e2b40769352a44 Mon Sep 17 00:00:00 2001 From: Patrick <ragamuffin(a)datacomm.ch> Date: Mon, 2 Mar 2009 10:12:26 +0100 Subject: save/load registry key class names --- server/registry.c | 41 +++++++++++++++++++++++++++++++++++++---- 1 files changed, 37 insertions(+), 4 deletions(-) diff --git a/server/registry.c b/server/registry.c index d83486b..afe7771 100644 --- a/server/registry.c +++ b/server/registry.c @@ -246,6 +246,10 @@ static void save_subkeys( const struct key *key, const struct key *base, FILE *f { fprintf( f, "\n[" ); if (key != base) dump_path( key, base, f ); + if (key->class != NULL) { + fprintf( f, "] [" ); + dump_strW( key->class, key->classlen / sizeof(WCHAR), f, "[]" ); + } fprintf( f, "] %u\n", (unsigned int)((key->modif - ticks_1601_to_1970) / TICKS_PER_SEC) ); for (i = 0; i <= key->last_value; i++) dump_value( &key->values[i], f ); } @@ -1107,12 +1111,12 @@ static int get_data_type( const char *buffer, int *type, int *parse_type ) static struct key *load_key( struct key *base, const char *buffer, int flags, int prefix_len, struct file_load_info *info ) { - WCHAR *p; - struct unicode_str name; - int res; + WCHAR *p, *c; + struct unicode_str name, class; + int res, c_res; unsigned int mod; timeout_t modif = current_time; - data_size_t len; + data_size_t len, c_len; if (!get_file_tmp_space( info, strlen(buffer) * sizeof(WCHAR) )) return NULL; @@ -1122,6 +1126,32 @@ static struct key *load_key( struct key *base, const char *buffer, int flags, file_read_error( "Malformed key", info ); return NULL; } + + c_len = info->tmplen - len; + if ((c_res = parse_strW( info->tmp + len / sizeof(WCHAR), &c_len, buffer + res, ']' )) == -1) + { + /* no class name */ + class.len = 0; + } + else + { + res += c_res; + + c = info->tmp + len / sizeof(WCHAR); + while (*c) { if (*c++ == '[') break; } + + if (!*c) + { + /* malformed class name - ignore */ + class.len = 0; + } + else + { + class.str = c; + class.len = c_len - (c - (info->tmp + len / sizeof(WCHAR)) + 1) * sizeof(WCHAR); + } + } + if (sscanf( buffer + res, " %u", &mod ) == 1) modif = (timeout_t)mod * TICKS_PER_SEC + ticks_1601_to_1970; @@ -1140,6 +1170,9 @@ static struct key *load_key( struct key *base, const char *buffer, int flags, } name.str = p; name.len = len - (p - info->tmp + 1) * sizeof(WCHAR); + + if (class.len > 0) + return create_key( base, &name, &class, flags, modif, &res ); return create_key( base, &name, NULL, flags, modif, &res ); } -- 1.6.1.3

1 0

sock_init: ERROR in sock_check_pollhup()
by Austin English 02 Mar '09

02 Mar '09

I'm occasionally seeing this error when starting an application in OpenSolaris. Seems to be about 1/4 of the time. Looked for it in the source, found it in server/sock.c: void sock_init(void) { sock_shutdown_type = sock_check_pollhup(); switch ( sock_shutdown_type ) { case SOCK_SHUTDOWN_EOF: if (debug_level) fprintf( stderr, "sock_init: shutdown() causes EOF\n" ); break; case SOCK_SHUTDOWN_POLLHUP: if (debug_level) fprintf( stderr, "sock_init: shutdown() causes POLLHUP\n" ); break; default: fprintf( stderr, "sock_init: ERROR in sock_check_pollhup()\n" ); sock_shutdown_type = SOCK_SHUTDOWN_EOF; } } Is it anything to worry about? Or safe to ignore? -- -Austin

2 1

appdb issue: can't search for apps platinum on 1.0.x!
by Dan Kegel 02 Mar '09

02 Mar '09

Our currently released version is 1.0, but the appdb's browse feature acts as if that version no longer exists. This will seriously confuse newcomers who are using the 1.0.1 version (e.g. anybody who installs a fresh copy of Ubuntu!). To fix this, we should add 1.0 (or 1.0.1) back into the search box in http://appdb.winehq.org/objectManager.php?sClass=application

8 25

Re: fusion/tests: Fix tests for .NET 1.x
by Paul Vriens 02 Mar '09

02 Mar '09

Ge van Geldorp wrote: > Changelog: > fusion/tests: Fix tests for .NET 1.x > > --- > dlls/fusion/tests/asmname.c | 12 +++++++++--- > 1 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/dlls/fusion/tests/asmname.c b/dlls/fusion/tests/asmname.c > index 98004ea..0ea7aa8 100644 > --- a/dlls/fusion/tests/asmname.c > +++ b/dlls/fusion/tests/asmname.c > @@ -371,8 +371,12 @@ static void > test_assembly_name_props_line(IAssemblyName *name, > if (i == ASM_NAME_PUBLIC_KEY_TOKEN) > ok(!memcmp(vals[i].val, str, size), "Expected a correct > ASM_NAME_PUBLIC_KEY_TOKEN\n"); > else > - ok(!lstrcmpA(vals[i].val, val), "%d: prop %d: Expected > \"%s\", got \"%s\"\n", line, i, vals[i].val, val); > - ok(size == vals[i].size, "%d: prop %d: Expected %d, got > %d\n", line, i, vals[i].size, size); > + ok(!lstrcmpA(vals[i].val, val) || > + broken(i == ASM_NAME_OSINFO_ARRAY), /* .NET 1.x */ + > "%d: prop %d: Expected \"%s\", got \"%s\"\n", line, i, > vals[i].val, val); > + ok(size == vals[i].size || > + broken(i == ASM_NAME_PROCESSOR_ID_ARRAY || i == > ASM_NAME_OSINFO_ARRAY), /* .NET 1.x */ > + "%d: prop %d: Expected %d, got %d\n", line, i, > vals[i].size, size); > } > } > } > @@ -598,7 +602,9 @@ static void test_CreateAssemblyNameObject(void) > ok(hr == FUSION_E_INVALID_NAME || > broken(hr == S_OK), /* .NET 1.x */ > "Expected FUSION_E_INVALID_NAME, got %08x\n", hr); > - ok(hi == 0, "Expected 0, got %08x\n", hi); > + ok(hi == 0 || > + broken(hi == 0x00010005), /* .NET 1.x */ > + "Expected 0, got %08x\n", hi); > ok(lo == 0, "Expected 0, got %08x\n", lo); > > test_assembly_name_props(name, badvername); Hi, Already beat you to it: http://www.winehq.org/pipermail/wine-patches/2009-February/070044.html http://www.winehq.org/pipermail/wine-patches/2009-February/070045.html The main difference is that I skip 3 of the test_assembly_name_props tests altogether whereas you 'skip' these 2 properties for all the test_assembly_name_props tests. -- Cheers, Paul.

1 0