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

Re: Solution to msi/install test timeouts

by Adam Petaccia

On Fri, 2008-08-29 at 11:01 +0200, Paul Vriens wrote: > Hi, > > I've been experimenting on my XP and Vista boxes and the only way to make the > tests run fast is by stopping 'System Restore'. > > It makes sense that this has a huge impact on performance, especially with the > big number of installations we are doing in these tests. > > Could people that are currently seeing timeouts for their boxes on > test.winehq.org check if 'System Restore' is indeed activated? > Both of my machines have System Restore enabled.

Aug. 31, 2008

Re: ntdll/file.c: Allow to TRACE NtCreateFile return [repost]

by Michael Karcher

Am Samstag, den 30.08.2008, 11:41 -0600 schrieb Vitaliy Margolen: > Almost no programs are calling the Nt* functions directly. But kernel32 > functions. So the point about knowing the file handle in return from > NtCreateFile is moot. And kernel32's CreateFile() already prints that > information for you. This is not true anymore for kernel level device drivers wine starts to support now. ntoskrnl.exe:NtCreateFile is directly forwarded into ntdll. > This is why you are getting so much resistance - you trying to add something > redundant. I think this is not a valid point. First, most of the function entry traces also are "redundant", as a relay trace already prints the parameters. Relay tracing can be limited to certain dlls, for example ntdll. In that case, most of the traces in file.c are redundant. Second, kernel32:CreateFile logs to file, whereas ntdll:NtCreateFile logs to ntdll. So to make sense of these details in the ntdll trace, you have to turn on file. As this is dealing with files, it is not too ugly, but keeping information needed to follow code flow in one channel is a definite pro. Third, there is precedence in NtReadFile[Scatter] and NtWriteFile[Gather]. Would you suggenst to remove the result traces from there? Regards, Michael Karcher

Aug. 30, 2008

Re: Recent msi/package tests failures

by James Hawkins

On Sat, Aug 30, 2008 at 3:17 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > James Hawkins wrote: >> >> On Wed, Aug 27, 2008 at 2:18 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> >> wrote: >>> >>> James Hawkins wrote: >>>> >>>> On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia <adam(a)tpetaccia.com> >>>> wrote: >>>>> >>>>> On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I was looking into the recent test failures for the msi/package tests >>>>>> on >>>>>> my >>>>>> WinXP box. >>>>>> >>>>>> The reason for most of them was a stray MSITEST package that couldn't >>>>>> be >>>>>> removed >>>>>> via the 'Add/Remove Programs' (had to remove stuff from the registry). >>>>>> >>>>>> Any one else seeing this? (Adam Petaccia's XP box has the same issue I >>>>>> guess). >>>>>> >>>>> I can provide any details you need about the XP box, the first thing I >>>>> can think of is that the user running the tests is an administrator. >>>>> >>>> That's not why the tests are failing. The install tests are timing >>>> out, and if the winetest executable kills the child process that it >>>> believes is 'hung', then you're killing the installer process midway >>>> through an install and thus leaving the system in a broken state. >>>> >>> So were back to fixing the timeouts. >>> >>> I double checked again and can't see any logging enabled (checked the >>> registry keys your provided). >>> >> >> Of course; there are tons of tests. The timeout needs to be extended, >> at least for install.c. >> > Hi, > > I just sent a few patches that fix the problem with the timeout on my > machines. > > Do you think it's still worthwhile to disable logging by using > MsiEnableLogA? When I now look in my temp folder I have a few hundred MSI > log files. We could either disable logging or create 1 file ourselves and > append everything to there (removing it afterwards maybe). > Logging to one file takes just as long as any other type of logging. No logging should be happening. No I don't think it's worth using MsiEnableLog to disable loggin. Logging is not enabled by default, and to enable it you have to change some registry entries, which I doubt anyone is doing. -- James Hawkins

Aug. 30, 2008

Re: [msi/tests 3/3] Create a system restore point when needed

by James Hawkins

On Sat, Aug 30, 2008 at 3:14 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > The slowness on some machines for the install tests comes from the system > restore facility. When 'System Restore' is active you will find a great > number > of system restore points after these tests have run. Adding our own system > restore point circumvents this as Windows will now wait till we tell it that > the > system change has ended. Only 1 system restore point will be created now > and > this one is nicely removed afterwards. > > On my testboxes (XP and Vista) this makes sure that the tests run within the > limits of the timeout (2 minutes). Before this patch the tests would take > about > 8 minutes on my Vista box (now 1.something). > > Changelog > Create a system restore point when needed > Please factor all of this out into functions. + /* Create a system restore point. We need to do this on a system where 'System + * Restore' is active as we would otherwise timeout on these tests. + * By doing so we circumvent the multitude of restore points that would have been + * created by all the installation and removal tests. + * + * The restore point is removed afterwards. + * + * On systems where 'System Restore' is not active, this won't have any effect + * as the first call to SRSetRestorePointA will fail with a status of + * ERROR_SERVICE_DISABLED. + */ Does the comment really need to be that long? -- James Hawkins

Aug. 30, 2008

Re: Recent msi/package tests failures

by Paul Vriens

James Hawkins wrote: > On Wed, Aug 27, 2008 at 2:18 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: >> James Hawkins wrote: >>> On Wed, Aug 27, 2008 at 11:40 AM, Adam Petaccia <adam(a)tpetaccia.com> >>> wrote: >>>> On Wed, 2008-08-27 at 10:26 +0200, Paul Vriens wrote: >>>>> Hi, >>>>> >>>>> I was looking into the recent test failures for the msi/package tests on >>>>> my >>>>> WinXP box. >>>>> >>>>> The reason for most of them was a stray MSITEST package that couldn't be >>>>> removed >>>>> via the 'Add/Remove Programs' (had to remove stuff from the registry). >>>>> >>>>> Any one else seeing this? (Adam Petaccia's XP box has the same issue I >>>>> guess). >>>>> >>>> I can provide any details you need about the XP box, the first thing I >>>> can think of is that the user running the tests is an administrator. >>>> >>> That's not why the tests are failing. The install tests are timing >>> out, and if the winetest executable kills the child process that it >>> believes is 'hung', then you're killing the installer process midway >>> through an install and thus leaving the system in a broken state. >>> >> So were back to fixing the timeouts. >> >> I double checked again and can't see any logging enabled (checked the >> registry keys your provided). >> > > Of course; there are tons of tests. The timeout needs to be extended, > at least for install.c. > Hi, I just sent a few patches that fix the problem with the timeout on my machines. Do you think it's still worthwhile to disable logging by using MsiEnableLogA? When I now look in my temp folder I have a few hundred MSI log files. We could either disable logging or create 1 file ourselves and append everything to there (removing it afterwards maybe). -- Cheers, Paul.

Aug. 30, 2008

Re: Help for my first patch

by Roderick Colenbrander

Hi, Sorry to disappoint you but I have a feeling that this is most likely a bug in Xfce instead of Wine. Our window management code might use some legacy mechanisms here and there but it works on all window managers (except for this Xfce issue). A few years ago we had similar issues with Metacity and they fixed it in there. I think you can find info about it in the wine-devel archives. I don't know all the tech details of winex11.drv. Likely someone more qualified like Alexandre can tell you more. Regards, Roderick > Hi, > > > I'm using Wine with xUbuntu and you may be know, the menu and toolbar of > xfce are often visible. So I've looked at xfce forum and saw that wine > doesn't inform xfce that window is fullscreen... > > At http://standards.freedesktop.org/wm-spec/wm-spec-latest.html, I've > found a _NET_WM_STATE_FULLSCREEN flag. > > After digging in wine source, I've found in dlls/winex11.drv/window.c > the function create_whole_window (I think that this function is called > when a game want a resolution which isn't supported by X, wine used this > function to fake fullscreen ?, correct me I'm wrong) > > If in set_wm_hints, I force the window_type to _NET_WM_STATE_FULLSCREEN, > toolbar and menu of xfce disappears. (tested with Wizardry 8) > > My problem is how detect in this function that I came from > create_whole_window and not from others functions ? > > Do I have to test size of window to current resolution and use this flag ? > Or call XChangeProperty in create_whole_window ? > > > Thanks in advance, > Michael > -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf(a)gmx

Aug. 30, 2008

Re: [try4] d3d9: Set the initial scissorrect ...

by Rico Schüller

Rico Schüller schrieb: > Hi, > > this patch adds the initial scissorrect for d3d9. The improvement from > the last patch is, that it doesn't try to set it for d3d8 and ddraw > because both don't support scissorrects. > > Cheers > Rico > ------------------------------------------------------------------------ > > This patch is wrong!

Aug. 30, 2008

Help for my first patch

by Michael Bonfils

Hi, I'm using Wine with xUbuntu and you may be know, the menu and toolbar of xfce are often visible. So I've looked at xfce forum and saw that wine doesn't inform xfce that window is fullscreen... At http://standards.freedesktop.org/wm-spec/wm-spec-latest.html, I've found a _NET_WM_STATE_FULLSCREEN flag. After digging in wine source, I've found in dlls/winex11.drv/window.c the function create_whole_window (I think that this function is called when a game want a resolution which isn't supported by X, wine used this function to fake fullscreen ?, correct me I'm wrong) If in set_wm_hints, I force the window_type to _NET_WM_STATE_FULLSCREEN, toolbar and menu of xfce disappears. (tested with Wizardry 8) My problem is how detect in this function that I came from create_whole_window and not from others functions ? Do I have to test size of window to current resolution and use this flag ? Or call XChangeProperty in create_whole_window ? Thanks in advance, Michael

Aug. 30, 2008

Re: ntdll: add some tests for NtDeleteFile

by Vitaliy Margolen

Jeff Zaroyko wrote: > > > + static const WCHAR testdirW[] = {'n','t','d','e','l','e','t','e','f','i','l','e',0}; > + static const WCHAR subdirW[] = {'\\','s','u','b',0}; > + > + ret = CreateDirectoryW(testdirW, NULL); You need to create test files and directories in windows temp dir. > + pRtlDosPathNameToNtPathName_U(testdirW, &nameW, NULL, NULL); You are leaking unicode string nameW. You need to call this to free it: RtlFreeUnicodeString( &nameW ); > + ret = pNtDeleteFile(&attr); > + ok(ret == STATUS_SUCCESS, "expected NtDeleteFile to ret STATUS_SUCCESS on failure\n"); How do you know it's a failure? You should check if dir is still there. Vitaliy

Aug. 30, 2008

Re: ntdll/file.c: Allow to TRACE NtCreateFile return [repost]

by Vitaliy Margolen

Michael Karcher wrote: > [The original mail seemed to be stuck in the moderation queue or > got lost somewhere else. Reposting with correct "From:" this > time] > > Am Mittwoch, den 27.08.2008, 17:14 +0900 schrieb Dmitry Timoshkov: >> "Markus Hitter" <mah(a)jump-ing.de> wrote: >> >>> Providing the file handle allows to map >>> read/write requests to the corresponding file name. >> As pointed out by Alexander, you can use an appropriate debug >> channel for that, +relay or +server. There is no need to pollute >> the source with additional traces. > > I am sorry, but I don't get your point. The handle is returned in an > out-pointer. There is no way to get that info into +relay. Alexandre > said: > > | Module-specific traces like this one should try to print as > | little information as necessary to make sense of the trace > | In general a single trace at function entry is enough to understand > | the code flow. > I agree, but the handles returned *are* necessary to make sense of the > trace. Also, if I just want parameters at the function entry: This > information is provided by +relay. In the +file log, I don't care about > the address where the handle should be written to, yet it is logged by > our tracing conventions. It also doesn't help to understand code flow. > Now we are rejecting a patch that logs useful information instead, which > is vital to connect further file calls to the NtCreateCall, i.e. > understand the flow. I don't understand that. > > | If you want details like the exact error codes you can use +relay or > | +server. > I agree too, but the details about exact error codes have been removed > from the patch. > Almost no programs are calling the Nt* functions directly. But kernel32 functions. So the point about knowing the file handle in return from NtCreateFile is moot. And kernel32's CreateFile() already prints that information for you. This is why you are getting so much resistance - you trying to add something redundant.

Aug. 30, 2008