June 2008 - Wine-devel - list.winehq.org

Time to revert bad commits?
by Vitaliy Margolen 04 Jun '08

04 Jun '08

I'm afraid we are out of time to fix bugs that introduces major d3d regressions. I've yet to see a single patch that addressed those issues. It's time to start reverting bad commits and testing the results. The bugs I'm talking about: Bug 10580 Bug 11584 Bug 12794 Bug 13101 Vitaliy.

6 9

Re: mmio: Do not zero current file position whenever mmioSetBuffer is called
by Christoph Frick 04 Jun '08

04 Jun '08

On Tue, Jun 03, 2008 at 07:57:00PM -0700, Matthew D'Asaro wrote: > Instead I set wm->info.lBufOffset to wm->info.lDiskOffset because the > buffer is flushed at the beginning of a call to mmioSetBuffer so > wm->info.lDiskOffset is synchronized with wm->info.lBufOffset and so > wm->info.lDiskOffset contains the correct current file position. The > test for mmio still passes with this patch. wouldn't that indicate, that the current patch does not cover that case? can you add a test for it? -- cu

1 0

Re: urlmon: Fix a test that fails on all platforms
by Dmitry Timoshkov 04 Jun '08

04 Jun '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > - ok(IBindCtx_Release(bctx) == 0, "bctx should be destroyed here\n"); > + > + if(bindf & BINDF_ASYNCHRONOUS) { > + ok(IBindCtx_Release(bctx) == 1, "bctx should not be destroyed here\n"); > + IBindCtx_Release(bctx); /* actually destroy it */ > + } > + else > + ok(IBindCtx_Release(bctx) == 0, "bctx should be destroyed here\n"); Wouldn't it be better to change it this way: if(bindf & BINDF_ASYNCHRONOUS) ok(IBindCtx_Release(bctx) == 1, "bctx should not be destroyed here\n"); ok(IBindCtx_Release(bctx) == 0, "bctx should be destroyed here\n"); -- Dmitry.

2 1

Re: advpack: fix a test failure on 9x
by James Hawkins 04 Jun '08

04 Jun '08

On Tue, Jun 3, 2008 at 7:17 PM, Austin English <austinenglish(a)gmail.com> wrote: > This isn't the right fix. The RegisterOCX command doesn't work in win9x, so it needs to be changed to another command. -- James Hawkins

1 0

Re: kernel32: avoid thread-unsafe function gmtime()
by Dmitry Timoshkov 04 Jun '08

04 Jun '08

"Dan Kegel" <dank(a)kegel.com> wrote: > Using gmtime() in a multithreaded program could > result in invalid results. So use the safer alternative > gmtime_r() if it's available. Most likely gmtime_r() should be used without #ifdefs and a replacement put in libs/port. -- Dmitry.

1 0

Re: [programs/winetest] Put up a warning message before running
by James Hawkins 04 Jun '08

04 Jun '08

On Tue, Jun 3, 2008 at 8:27 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > Hi, > > Due to the fact that we have several ordinary users trying out winetest I > think > it makes sense to put up this message. > > The message will not be shown in quiet mode and not in expert mode (new one > '-x'). > > Changelog > Put up a warning message before running > No this is a bad idea, mostly because winetest is not particularly intended to be run by 'ordinary users', and anyone that does run winetest should be well aware of the supposed 'dangers' of running it. On top of this, running winetest should not be dangerous in the first place, and more effort should be put into fixing tests that crash the tests or the system. -- James Hawkins

3 3

Valgrind note
by Dan Kegel 03 Jun '08

03 Jun '08

For those of you using valgrind with --track-origins, make sure you're using a tree with vex rev >= 1854; Julian Seward says there was a problem that could cause segfaults. If in doubt, grab a fresh valgrind tree from svn.

1 0

Re: msi:MsiSourceListEnumMediaDisksW: free original string, not substring
by Steven Edwards 03 Jun '08

03 Jun '08

On Tue, Jun 3, 2008 at 9:29 AM, Dan Kegel <dank(a)kegel.com> wrote: > Found via valgrind: > > Invalid free() / delete / delete[] > by msi_free (msipriv.h:965) > by MsiSourceListEnumMediaDisksW (source.c:324) > Address 0x7f01b2ac is 12 bytes inside a block of size 54 alloc'd > by msi_alloc (msipriv.h:945) > by MsiSourceListEnumMediaDisksW (source.c:273) > > 'data' is freed later, so don't touch it. I think I know of one application that might be affected by this. With the Project 2003 installer it reports an error I believe in this function. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0

userenv: tests/userenv.c: fix buffer overrun
by Dan Kegel 03 Jun '08

03 Jun '08

Found via valgrind. Fixes Use of uninitialised value of size 4 at wine_cp_mbstowcs (mbtowc.c:79) by MultiByteToWideChar (locale.c:1846) by CompareStringA (locale.c:2722) by get_env (userenv.c:140) by func_userenv (userenv.c:218) Uninitialised value was created by a stack allocation at get_env (userenv.c:128)

1 0

Trip & Conference Report Linux Tag 2008
by Marcus Meissner 03 Jun '08

03 Jun '08

Hi, I was at LinuxTag 2008, which is the largest Linux User fair in Germany. The fair was from Wednesday to Saturday, however I was only there Saturday. Saturday was openSUSE day and we (openSUSE) had a conference track over the whole day. One of those talks in this track was my talk on "Wine - applications and games on Linux". My talk was well received, the lecture hall was about 80% full with around 180-200 people. My german slides are at: http://files.opensuse.org/opensuse/en/0/08/Lt2008-wine.pdf http://files.opensuse.org/opensuse/en/6/66/Lt2008-wine.odp 2 smaller german online journals commented on it, mostly regarding the 1.0 release part: http://www.golem.de/0806/60100.html http://www.oszine.de/node/9141 (There might even be a Video recording later on.) I received totally unexpected applause on announcing that after 15 years we finally come to 1.0 release (after over 200 alphas, and 60 betas). After the talk I had 10 people around me asking questions, and one specific problem with Adobe InDesign FileOpen Dialog on a laptop brought to the openSUSE booth. Interesting Wine related points: - Kai Tietz of mingw64 told me that they have a GCC patch ready for gcc 4.4 which will support the Win64 calling convention attribute just like __attribute__(stdcall). Was committed to GCC TRUNK: http://gcc.gnu.org/viewcvs?view=rev&sortby=date&revision=136311 __attribute__(ms_abi) If we have more GCC requirements for Win64, he is willing to help. In general he would like to have Wine as a testbed for mingw64 development (and we could use it as testbed the other way round). http://mingw-w64.sf.net/ - Avira (Antivirus vendor) They use Wine in house to at least get some info on Windows DLLs, using version.dll.GetFileVersionInformation. While this works for Win32 DLLs, it stopped working/currently does not work for Win64 DLLs. - scan.coverity.com Talked to Coverity folks, and also to David Maxell. The application will receive an update from Coverity 2.9 to 3.2 in the next days/weeks. Not sure if it brings new features. Also process issue: We have a large backlog of UNINSPECTED features. They suggested that in those cases we could just say "lets not look at this old cruft" and mark them somehow "PENDING" or similar. Not sure it helps us, but at least we could use "PENDING" for partially inspected issues. - Booth or no Booth (We had no booth this year.) Since the question will likelay appear again, I thought about whether to have a Wine booth itself next year... Well, if we dont have at least 2 people there over the whole 4 days it does not make sense and finding those 2+ people likely is difficult. I might be able to spare the time, but this year it was not possible due to overlapping schedule. Perhaps its also easier to have a demo-point on another larger booth (could ask openSUSE if they would have Wine there). At least the Saturday visitors got their knowledge on Wine increased by my talk at least. I got the feeling that people are still quite unsure what works and what not and expect clear and definitive statements from us. I pointed to the AppDB several times in those cases and tried not to make overly positive statements. People are expectant on 1.0 and I think they are willing to be suprised. Ciao, Marcus

2 1