February 2008 - Wine-Devel - list.winehq.org

Re: wine.inf: Create fake dll entry for dosx.exe

by Steven Edwards

On Fri, Feb 29, 2008 at 2:16 PM, Justin Chevrier <jchevrier(a)nexicom.net> wrote: > Anything wrong with this one liner? I think you should create a stub version of dosx in wine/programs as well. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has cdosome." - Victor Hugo

Feb. 29, 2008

Re: Conformance tests for LoadStringW and LoadStringA

by Christopher

wine-devel-request(a)winehq.org wrote: > Message: 3 > Date: Fri, 29 Feb 2008 12:50:53 +0100 > From: Alexandre Julliard <julliard(a)winehq.org> > Subject: Re: Conformance tests for LoadStringW and LoadStringA > To: Christopher <raccoonone(a)procyongames.com> > Cc: wine-devel(a)winehq.org > Message-ID: <87y794yo9u.fsf(a)wine.dyndns.org> > Content-Type: text/plain; charset=us-ascii > > Christopher <raccoonone(a)procyongames.com> writes: > > >> > + ok(!memcmp(copiedstring, returnedstring, (length2 + 1)*sizeof(WCHAR)), >> > + "LoadStringW returned a string that does not match the string pointed to by the pointer it returned. \ >> > + returnedstring = %ls, copiedstring = %ls", (wchar_t *)returnedstring, (wchar_t *)copiedstring); >> > > You cannot cast a WCHAR* to a wchar_t*. > > -- Alexandre Julliard julliard(a)winehq.org Thanks, I assumed they were the same since under Windows WCHAR is typedef'ed as wchar_t. Is the proper way to handle this to use WideCharToMultiByte() on returnedstring and copiedstring, and then pass the converted (multibyte) strings to ok()? Christopher Berner

Feb. 29, 2008

Re: kernel32: Forward fiber local storage APIs to thread local storage equivalents.

by Paul Chitescu

Actually a lot of programs fail to start since the addition of these stubs. In particular anything that uses MSVCRT80. This is a major regression. Most applications seem to live a happy life without fiber local storage - is there one that would benefit from it? On Fri, 29 Feb 2008, Hans Leidekker wrote: > > Photoshop CS2 fails to start after the Fls* stubs were added. This patch > makes it start again but I'm not enough of an expert on this matter to say > if this is the right thing to do. > > -Hans > > Changelog > Forward fiber local storage APIs to thread local storage equivalents.

Feb. 29, 2008

Re: wine.inf: Create fake dll entry for dosx.exe

by Justin Chevrier

> Changelog: > > Create a fake dll entry for dosx.exe Anything wrong with this one liner? Justin Chevrier

Feb. 29, 2008

Re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

by James Hawkins

On Fri, Feb 29, 2008 at 11:06 AM, Robert Shearman <rob(a)codeweavers.com> wrote: > Adam Strzelecki wrote: > > During playing with installing Visual Studio 2005 with WINE I found > > out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac > > OS X process sampler I checked that actually 60-70% of CompareStringW > > is wine_compare_string, rest is rest of function body, which is in > > case 2 strlenW calls (inline). > > I believe this isn't necessary, moreover most of compares in MSI are > > non-matching on first few characters, however with current > > implementation we go trough all strings with strlenW regardless of > > anything, which is waste in CPU cucles. > > I modified both CompareStringW and wine_compare_string so they work > > with -1 strings without strlenW checking before. > > This saves in my testing about 20-30% of CPU cycles. > > You introduce a lot of complexity into the low-level helper routines. We > don't want to put Win32 quirks, like -1 meaning "until the null > terminator" being put into the low-level functions unless we have to. In > this case, if this is the sole cause of the slowdown then you would be > better off caching the length at the MSI level since the strings are > bound to be accessed more than once. > > However, I think you'll find that this is an algorithm problem in MSI > rather than a performance issue in the functions you mention. By that, I > mean it is likely that one MSI query is being performed again and again > and that the results should be cached. > This is not the case at all. If you use native MSI, you'll see almost exactly the same number of string comparisons (give or take). I've rarely seen the same SQL query used multiple times with the exact same parameters. Caching would add too much complexity, and in normal cases, more processing time than time saved. > > > Note also that WINE's strlenW and lstrcmpW functions are far from > > perfect. Normal msvcrt or glibc string functions are far more > > optimized at machine code level. This makes strong impact on WINE > > parts strongly relaying on string manipulation which is in this case MSI. > > How do you know that the compiler isn't generating the same assembly for > the functions as that used by msvcrt / glibc? Theories like these need > numbers to back them up. > -- James Hawkins

Feb. 29, 2008

Re: msi: ACTION_RegisterProduct store all InstallProperties

by James Hawkins

On Fri, Feb 29, 2008 at 9:13 AM, Adam Strzelecki <ono(a)java.pl> wrote: > Hi, > > WINE is writing properties such as Language or VersionMajor only to > Uninstall key in ACTION_RegisterProduct, while MSI_GetProductInfo is > trying to read those from InstallProperties key. > > So this patch duplicates all properties written into MSI product > Uninstall key, also to InstallProperies. > This is normal behavior I can see in Windows XP's MSI, as properties > are duplicated in both Uninstall and InstallProperties. > Please do not accept this patch. I'm trying to clean up the publishing code, and without tests to prove this case, it should not go in. The tests that do exist show that the properties are written into the Uninstall key on RegisterProduct, but not the product key. -- James Hawkins

Feb. 29, 2008

Re: kernel32: Fix for WritePrivateProfileString Sharing Problem [2/2]

by Erich Hoover

On Fri, Feb 29, 2008 at 1:18 AM, James Hawkins <truiken(a)gmail.com> wrote: > > On Fri, Feb 29, 2008 at 1:17 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > > > On Thu, Feb 28, 2008 at 11:44 PM, James Hawkins <truiken(a)gmail.com> wrote: > > > > > > On Fri, Feb 29, 2008 at 12:29 AM, Erich Hoover <ehoover(a)mines.edu> wrote: > > > > Patch Originally From: > > > > Louis Lenders > > > > Description: > > > > This patch adds conformance tests for WritePrivateProfileString sharing > > > > problems. The patch was created by Louis Lenders and extensively tested, > > > > but never submitted (see Bug #5024). Please note that a couple of the tests > > > > now fail because cached profile information is returned, resolving that > > > > problem is outside the scope of these patches. > > > > Changelog: > > > > kernel32: Test for WritePrivateProfileString Sharing Permissions > > > > > > > > > > If a test fails, it has to be wrapped in todo_wine, else make test will fail. > > > > > > -- > > > James Hawkins > > > > > > > I would argue that make test should fail for regressions, though I > > don't know when exactly this particular problem surfaced. Re-ording > > the tests can actually mask the problem as well as inserting > > todo_wine, which would be preferred? > > > > Um make test does fail for regressions. make test fails if an ok call > fails and is not covered by todo_wine, and it also fails when a test > in a todo_wine block succeeds. That's how we keep track of the tests. > If reordering the tests masks the problem, what's the point of the > tests? > > -- > James Hawkins > The tests are for checking the sharing permissions problem, which causes WritePrivateProfileString to fail when the profile file is opened by CreateFile before WritePrivateProfileString is called. The tests failing now is a result of a problem with wine caching the profile information from when the call previously succeeded (the cache is not updated properly when the file is deleted). What I'm trying to say is that the tests are currently exposing a separate issue, so a separate set of tests would probably be appropriate - problems with caching are outside the scope of the patches I submitted. Erich Hoover ehoover(a)mines.edu

Feb. 29, 2008

Re: kernel32 & winelib: Don't test string size in CompareStringW for null terminated strings

by Robert Shearman

Adam Strzelecki wrote: > During playing with installing Visual Studio 2005 with WINE I found > out that WINE's MSI is spending lot of time inside lstrcmpW. With Mac > OS X process sampler I checked that actually 60-70% of CompareStringW > is wine_compare_string, rest is rest of function body, which is in > case 2 strlenW calls (inline). > I believe this isn't necessary, moreover most of compares in MSI are > non-matching on first few characters, however with current > implementation we go trough all strings with strlenW regardless of > anything, which is waste in CPU cucles. > I modified both CompareStringW and wine_compare_string so they work > with -1 strings without strlenW checking before. > This saves in my testing about 20-30% of CPU cycles. You introduce a lot of complexity into the low-level helper routines. We don't want to put Win32 quirks, like -1 meaning "until the null terminator" being put into the low-level functions unless we have to. In this case, if this is the sole cause of the slowdown then you would be better off caching the length at the MSI level since the strings are bound to be accessed more than once. However, I think you'll find that this is an algorithm problem in MSI rather than a performance issue in the functions you mention. By that, I mean it is likely that one MSI query is being performed again and again and that the results should be cached. > Note also that WINE's strlenW and lstrcmpW functions are far from > perfect. Normal msvcrt or glibc string functions are far more > optimized at machine code level. This makes strong impact on WINE > parts strongly relaying on string manipulation which is in this case MSI. How do you know that the compiler isn't generating the same assembly for the functions as that used by msvcrt / glibc? Theories like these need numbers to back them up. -- Rob Shearman

Feb. 29, 2008

Re: kernel32 & winex11: WaitForMultipleObjectsEx should ignore NULL handles

by Robert Shearman

Adam Strzelecki wrote: > Hi, > > In MSI dialog.c: msi_dialog_check_messages function it often happens > that is sends: > MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, QS_ALLINPUT ); > Where handle = NULL. I'm not sure if it is correct behavior. But > tracing it down I found out that kernel32 and winex11 sync functions > are not checking at all if the passes handles are not NULLs. > > So I'm not sure whether this patch is right or not, but I believe we > shouldn't bother wineserver with NULL handles!? > Yet maybe I don't understand clearly the way interserver communication > works, and sending "WaitFor" with NULL handle makes sense. Does it? No, but this is the wrong fix. You're assuming that because MSI code does action A and that causes bad effect when it does action B that the correct action is to fix B so that it doesn't have a bad effect. However, the bug could also be that action A shouldn't be done. In this case, MSI should not be calling MsgWaitForMultipleObjects with an invalid handle and in fact that barring memory corruption, this can't happen: > while (1) > { > msi_process_pending_messages( NULL ); > > if( !handle ) > break; > > /* > * block here until somebody creates a new dialog or > * the handle we're waiting on becomes ready > */ > r = MsgWaitForMultipleObjects( 1, &handle, 0, INFINITE, > QS_ALLINPUT ); > if( r == WAIT_OBJECT_0 ) > break; > } -- Rob Shearman

Feb. 29, 2008

Visual Studio 2005 installation finally works with WINE

by Adam Strzelecki

Hi, Hmm.. I think my last mail didn't manage to get into the list because of too big image attachements, sorry. If it does, I'm sorry for dupes. I just want to mention that I've managed to install Visual Studio 2005 completely with WINE. 1) installed "vcrun6" (with winetricks) 2) applied 1 patch from http://bugs.winehq.org/show_bug.cgi?id=8439#c3 (Required for overall installation) 3) applied patched from http://appdb.winehq.org/appview.php?iVersionId=3754 (Required for .NET 2.0 installation) 4) applied "msi: ACTION_RegisterProduct store all InstallProperties" patch from wine-patches I've sent recently (Without this patch Visual Studio 2005 will think that MS XML 6.0 and some others is still uninstalled!) Installation goes without problem, however running "devenv.exe" causes several problems with .NET 2.0 packages and crashes a lot :( too bad. Most crashes and errors are because of few missing WINE API functions, and incomplete .NET 2.0 support. Still I think WINE's close to run Visual Studio! which will be great news for multi-platform developers. See attached screenshots from my MacBook Pro running OSX 10.5.2 at: http://bugs.winehq.org/show_bug.cgi?id=8439 Cheers, -- Adam Strzelecki |: nanoant.com :|

Feb. 29, 2008