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

Kernel32 profile/INI mappings to registry

by Silver Blade

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/

March 2, 2009

kernel32/tests: Mark debugger test broken for Win9x and WinME behavior

by Drew Ronneberg

March 2, 2009

Re: CreateThread timing behaviour (Bug 15323 affecting Warhammer Online)

by Paul TBBle Hampson

On Mon, Mar 02, 2009 at 06:51:06AM +0200, Pauli Nieminen wrote: > There seems to be at least partial synchronization for dll loading but > threading part doesn't include this lock. It seems like wine doesn't > need it so maybe it is enough to just simulate windows with following > small patch. > disclaimer: I didn't test this so might not be complete solution. If > it isn't enough then you could try add lock calls to create thread and > exit thread paths too. [patch] This just caused all the threads and processes to fail to start, locking on the main process or something. I'll play with this further if I have time, barring further comment on this thread, see if I can confirm that the behaviour I'm seeing is due to the code I'm looking at being somehow inside the dll attach code. -- ----------------------------------------------------------- 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/ -----------------------------------------------------------

March 2, 2009

Re: storing the registry key class name to make PDFXChange-Viewer happy

by Patrick

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

March 2, 2009

Re: sock_init: ERROR in sock_check_pollhup()

by Francois Gouget

Austin English a écrit : > 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: [...] > Is it anything to worry about? Or safe to ignore? I have also seen it occasionally but I have not had an opportunity to investigate it. Still I'd be interested if someone has any insight into this. -- Francois Gouget fgouget(a)codeweavers.com

March 2, 2009

Re: appdb issue: can't search for apps platinum on 1.0.x!

by Ben Klein

2009/3/2 Pauli Nieminen <suokkos(a)gmail.com>: > On Sat, Feb 28, 2009 at 10:47 AM, Alexandre Julliard > <julliard(a)winehq.org> wrote: > Time based stable releases that are coming about once in a year could > be good idea. Making stable release should be a lot easier with > passing and improving test suit. If that is considered too invasive > branching could happen when the candidate for stable branch goes to > RC. Time-based stable releases aren't suitable for Wine. We need bug targets for stable to be meaningful > Another way to make everyone happy with "unstable" would be mark every > 12th wine release as stable and just branching it for bug fixing. Then > bug fix release could be 1.1.12.X. 12 wine releases is 6 months. This would mean 2 stable releases each year and a LOT of extra work, especially considering the release candidate stages and code freeze. Re the automagic sources.list file: > Why not just make separate package for installing the source file. It > could be named as wine-installer. Then post-install hook can download > and install the real wine package. This sort of thing has been suggested already, and I would prefer to go this way IF we were to do it at all, but other people have objected to another package.

March 2, 2009

Re: appdb issue: can't search for apps platinum on 1.0.x!

by Pauli Nieminen

On Sat, Feb 28, 2009 at 10:47 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Ben Klein <shacklein(a)gmail.com> writes: > >> Now as this is *your* project, AJ, what do you think? Should stable >> branch be supported better by AppDB/bugzilla etc? At the moment, 1.0.1 >> is considered "too old" in some cases. > > There's no point in making stable releases if we decide that they are > useless after 6 months (and no, the answer is not to make more frequent > stable releases; even if we did one every 3 months we'd still have to > support the old ones). > Time based stable releases that are coming about once in a year could be good idea. Making stable release should be a lot easier with passing and improving test suit. If that is considered too invasive branching could happen when the candidate for stable branch goes to RC. Another way to make everyone happy with "unstable" would be mark every 12th wine release as stable and just branching it for bug fixing. Then bug fix release could be 1.1.12.X. 2009/2/28 Remco <remco47(a)gmail.com>: >On Sat, Feb 28, 2009 at 12:11 AM, Ben Klein <shacklein(a)gmail.com> wrote: >> 2009/2/28 Remco <remco47(a)gmail.com>: >>> Oh, I see. You mean that the package manager prefers the local >>> repository if all else is equal. That's solvable by bumping the >>> version number of the package that you download from the site. So, in >>> 'pseudo-versions', the repository would have these: >>> >>> wine 1.15-0 >>> wine 1.16-0 >>> wine 1.17-0 >>> >>> While the site would provide these for download: >>> >>> wine 1.15-1 >>> wine 1.16-1 >>> wine 1.17-1 >> >> This would fix the problem, but would also mean twice as much space is >> required to store the packages. If we're willing to deal with that, go >> for it! >> > >Well, I don't know if any package manager really does prefer a locally >installed version, to the point that it actually replaces the package >with exactly the same one. It would seem like a rather pointless >feature. Why not just make separate package for installing the source file. It could be named as wine-installer. Then post-install hook can download and install the real wine package. Pauli

March 2, 2009

sock_init: ERROR in sock_check_pollhup()

by Austin English

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

March 2, 2009

Re: fusion/tests: Fix tests for .NET 1.x

by Paul Vriens

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.

March 2, 2009

Re: CreateThread timing behaviour (Bug 15323 affecting Warhammer Online)

by Pauli Nieminen

On Mon, Mar 2, 2009 at 5:28 AM, Paul TBBle Hampson <Paul.Hampson(a)pobox.com> wrote: > On Mon, Mar 02, 2009 at 12:29:14AM +0200, Pauli Nieminen wrote: >> Msdn sayes: >> "The ExitProcess, ExitThread, CreateThread, CreateRemoteThread >> functions, and a process that is starting (as the result of a call by >> CreateProcess) are serialized between each other within a process. >> Only one of these events can happen in an address space at a time. >> This means that the following restrictions hold: > >> * During process startup and DLL initialization routines, new >> threads can be created, but they do not begin execution until DLL >> initialization is done for the process. >> * Only one thread in a process can be in a DLL initialization or >> detach routine at a time. >> * ExitProcess does not complete until there are no threads in >> their DLL initialization or detach routines." > >> So maybe this hidden synchronization is causing also newly created >> thread not to run until CreateThread has exited. > > How would I know if one of these was the case? 'cause if that's what's > going on, it'd explain the problem quite neatly. > > I should mention that the actual code being run here is inside a dll > file (libpatchui.dll) not the main warpatch.bin. > There seems to be at least partial synchronization for dll loading but threading part doesn't include this lock. It seems like wine doesn't need it so maybe it is enough to just simulate windows with following small patch. For me above restriction just sounds like performance bottleneck for future CPUs with x cores where X>100 cores :) Pauli disclaimer: I didn't test this so might not be complete solution. If it isn't enough then you could try add lock calls to create thread and exit thread paths too. diff --git a/dlls/ntdll/thread.c b/dlls/ntdll/thread.c index 87b9d57..88acc3e 100644 --- a/dlls/ntdll/thread.c +++ b/dlls/ntdll/thread.c @@ -466,7 +466,9 @@ static void start_thread( struct startup_info *info ) PRTL_THREAD_START_ROUTINE func = info->entry_point; void *arg = info->entry_arg; struct debug_info debug_info; - + ULONG magic; + + LdrLockLoaderLock(0, NULL, &magic); debug_info.str_pos = debug_info.strings; debug_info.out_pos = debug_info.output; thread_data->debug_info = &debug_info; @@ -480,6 +482,7 @@ static void start_thread( struct startup_info *info ) InsertHeadList( &tls_links, &teb->TlsLinks ); RtlReleasePebLock(); + LdrUnlockLoaderLock(0, &magic); /* NOTE: Windows does not have an exception handler around the call to * the thread attach. We do for ease of debugging */ if (unhandled_exception_filter)

March 2, 2009