October 2005 - Wine-Devel - list.winehq.org

Wine regression testing: PIT_
by Molle Bestefich Oct. 30, 2005

Oct. 30, 2005

Regression testing with Wine is a pain in the butthole. For very bad reasons: Stuff that is simple to fix, but haven't been. I'd like to help improve that situation. Example: ======== I want to find which patch ruins an application. The application, according to one note, worked in 2003. I decide to try and see how it really runs with the 2003 version of Wine mentioned in the note. I then spend several days pulling various releases, just trying to compile them. They all fail miserably, because some fix required to compile correctly with newer Linux versions is /missing/. For example, - any Wine before 2004-01-02 won't work because it won't compile against newer ALSA versions. - any Wine before 2003-12-01 needs patches to the build system before 'make depend' will even run. I've been at it for a week and I've managed to fix the above two. _They're really simple things, but they take a lot of time to figure out._ Currently I'm working with two other problems: - Wine fails to correctly invoke the debugger. Winedbg shows 'Usage: blah blah'. Seems 'wine' calls it with incorrect parameters. - Wine fails to start any application, complaining about 'kthreads' something or the other. I imagine that if I spend a few more weeks on the above problems, I can find patches in Wine CVS that fixes the exact problems I'm seeing. I've already wasted a week of my time on problems that someone else already fixed. Spending two or more weeks doing this is not exactly on my fun-things-to-do-before-I-die list. I'd like to see a general solution to this entire problem. What can be done to alleviate? ============================== Once I find a patch which makes an earlier version actually compile, I'd like to propose that for a backport. If approved/applied, the next person that checks out the release would check out a version containing the backported patches. That would fix the problem and allow people to do proper regression testing, so developers and QA people can spend their time doing development and QA instead of redoing already done effort trying to get an older version to run. I'm not sure how this would work with CVS. I'm from an SVN world where tagging is a 0-cost tree-copy operation, and any patches can be applied to the tag with history and all showing that the tag's been modified. If it can't work with CVS, perhaps the tags can be created in Troy's SVN repo and patches applied there? Not sure. Suggestions, please, people.

7 12

Compile error: dlls/kernel/time.c
by Ivan Gyurdiev Oct. 30, 2005

Oct. 30, 2005

I suspect a recent change in glibc (features.h) broke it... but according to time.h, CLK_TCK is obsolete, and CLOCKS_PER_SEC is to be used instead. gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_KERNEL32_ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -g -O2 -o time.o time.c time.c: In function ‘TIME_ClockTimeToFileTime’: time.c:522: error: ‘CLK_TCK’ undeclared (first use in this function) time.c:522: error: (Each undeclared identifier is reported only once time.c:522: error: for each function it appears in.) make[2]: *** [time.o] Error 1 make[2]: Leaving directory `/home/phantom/src/wine/dlls/kernel' make[1]: *** [kernel] Error 2 make[1]: Leaving directory `/home/phantom/src/wine/dlls' make: *** [dlls] Error 2

3 2

Re: Shell32 File Property Dialog
by Mike McCormack Oct. 29, 2005

Oct. 29, 2005

This version looks alot better than the first one. > * SH_FileTimerProc [Internal] > * > * is invoked every 100ms to check if the property sheet should be closed > * A timer is required because the property sheet pages are per default > * modeless and the property sheetpage does not have a window procedure This doesn't seem right to me. The property sheet should destroy all its pages when it is closed. Also, instead of attaching the new file, you can do: diff -u /dev/null dlls/shell32/fprop.c >> fp-051029.diff so that everything is in one diff. Mike

1 0

Restoring resolution when exiting: some questions
by julien Oct. 29, 2005

Oct. 29, 2005

Hello! Different games do not restore resolution when exiting. I tried to modify wine a bit and came to several problems: - I used destroy_whole_window api as a point to restore resolution. However I am not sure it is not the best place and it does not help in some cases (e.g., if Wine is crashing). So what could be the most relevant point (TerminateProcess?) to restore resolution? - I am restoring the resolution using default values to X11DRV_ChangeDisplaySettingsEx. How to manage the case with several applications having different resolutions? Thanks for any help on this! Julien

2 1

[Need a review]: New directory object for wineserver
by Vitaliy Margolen Oct. 29, 2005

Oct. 29, 2005

I've been working on a new directory object as a replacement for the server's named space. Attached is the working patch with directory, symlink and device objects. I would really appreciate your review of it. Some things still need a cleanup. But my main concern is the name_lookup function. To speed things up I used static buffer (something like registry routines do). PS: Sorry, had to gzip it so it will go through. -- Best regards, Vitaliy

1 0

Re: crash in shlwapi path tests
by Saulius Krasuckas Oct. 29, 2005

Oct. 29, 2005

* On Sat, 29 Oct 2005, Stefan Leichter wrote: > > when looking into the shlwapi test results you will see sometimes the > word crash. But the tests do not crash. The reason is that the winetest > executable cuts down the result file to 1M byte before sending it to > winehq. On some systems the PathIsValidCharW fails always (~65600 > tests). Therefore you get a result file that is more than 6M bytes big. Yeah, that happens because of a looped ok-tests. > ChangeLog > stop PathIsValidCharW tests after 100 failing tests I think better this should be fixed globally, for example by making ok() use static variable and remember last line which has failed. I was thinking about only 3 lines, but 100 failures on the same line is a nice threshold, Stefan.

1 0

Re: MS Office 97: so close...
by Dan Kegel Oct. 29, 2005

Oct. 29, 2005

On 10/29/05, Hans Leidekker <hans(a)it.vu.nl> wrote: > > If you shoot me a copy I can verify it solves my problems. > > (http://winehq.com/pipermail/wine-patches/2005-October/021484.html seems > > to already be applied, so you must be talking about something more...) > > Yes, it's incremental to that one. Here goes. Bada bing bada boom! Yep, applying your patch to a clean wine tree from cvs builds a wine that seems to no longer need an override for odbccp32 when installing Office 97. (The install still fails later with "Accwiz.dll was unable to register itself in the system registry", but you expected that.) Thanks! - Dan

1 0

MS Office 97: so close...
by Dan Kegel Oct. 29, 2005

Oct. 29, 2005

I tried again to install Office 97 on today's vanilla wine from cvs. Here's what I did, from the start: sudo mount -o loop -t iso9660 mso97.iso /mnt rm -rm .wine winecfg # choose WinME emulation # Override odbccp32 # quit wine \\mnt\\setup.exe It worked great, right up to the end, where it failed with the dialog box "Accwiz.dll was unable to register itself in the system registry". Here are the unique fixme's from the log: fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:CreateScalableFontResourceA (0,"c:\\windows\\offsetup.for","c:\\windows\\offsetup.ttf",(null)): stub fixme:ole:MkParseDisplayName (0x7eb38788, L"stdole32.tlb", 0x7b93ed34, 0x110): stub. fixme:ole:MkParseDisplayName (0x7eb38908, L"stdole32.tlb", 0x7b93ec60, 0x110): stub. fixme:ole:MkParseDisplayName (0x7eb38908, L"STDOLE32.TLB", 0x7b93ee88, 0x7eb3ab04): stub. I've filed this as http://bugs.winehq.org/show_bug.cgi?id=3689 along with a +ole,+dialog log. (+relay took waaaay too long to run.) Having Office '97 running on plain Wine would make my life easier- my wife would no longer object so much to having Linux on all our computers :-) So are those fixme's important, or just a distraction?

3 3

Migrate website documentation to the Wiki
by Jonathan Ernst Oct. 29, 2005

Oct. 29, 2005

Hi everyone, I'm willing to move every simple textual (static content) page from the website to the Wiki and link from the website to the corresponding pages. The advantages are obvious: - makes it easy to keep these pages up-to-date - makes it easy for non-dev. contributors to keep these pages up-to-date The problems are: - when clicking on a link from winehq to the wiki the left menu will change which can be confusing I notice that this has already been made for the janitorial page. The pages I'd like to move are about: http://cvs.winehq.org/cvsweb/lostwages/templates/en/* What do you think ?

9 20

tools/wine.inf (was: wine/programs/winecfg)
by Detlef Riekenberg Oct. 29, 2005

Oct. 29, 2005

Am Freitag, den 28.10.2005, 04:38 -0500 schrieb Alexandre Julliard: > ChangeSet ID: 20901 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)winehq.org 2005/10/28 04:38:11 > > Modified files: > programs/winecfg: appdefaults.c > > Log message: > Vitaliy Margolen <wine-patch(a)kievinfo.com> > Define OS environment variable on WinNT versions. The Patch requires, that I start winecfg and touch the OS-Version. When I do not start winecfg or do not touch/change the Default "win2000", then "OS" is not correct. Changing wine.inf can fix that for the Default Situation, but there are still 2 unusual but possible Race-Conditions left: - reinstall "wine.inf" while the OS-Version is <"NT" - change the Default OS-Version with Regedit -- By By ... ... Detlef

2 2