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

Time to revert bad commits?
by Vitaliy Margolen June 4, 2008

June 4, 2008

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 June 4, 2008

June 4, 2008

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 June 4, 2008

June 4, 2008

"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 June 4, 2008

June 4, 2008

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 June 4, 2008

June 4, 2008

"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 June 4, 2008

June 4, 2008

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 June 3, 2008

June 3, 2008

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 June 3, 2008

June 3, 2008

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 June 3, 2008

June 3, 2008

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 June 3, 2008

June 3, 2008

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

Re: ddraw: Don't release ddraw if a surface is still using it.
by Jens Albretsen June 3, 2008

June 3, 2008

> Am Samstag, 31. Mai 2008 17:03:13 schrieb Michael Karcher: >> > Anyway it makes wine stop crashing when programs tries to do something >> > crazy like this. Stefan DÃ¶singer asked me to put a HeapAlloc all >> memory >> > between the two Release's to check if the memory of ddraw object would >> be >> > corrupt in Windows. It really doesn't matter if programs live by >> chance >> > in windows, if we can implement it so it's not by chance anymore. >> >> I agree on that point. > Actually, that is dangerous. There may be situations in which this > make-something-work has an unintended side effect, e.g. failure to restore > the display mode because the ddraw object isn't destroyed(although it > maybe > should be - it's the test's job to find that out). You're right, if we expect every program to behave. I guess we need a hook for wined3d (if we not already have it) to restore the state back at process termination, if there is stuff not freed, changed video modes and such. I believe d3d does this natively, if you change video and there is a abnormal program termination it will restore the video mode and if you're running with debug libraries it will tell you what you forgot to free, at least in Windows XP. I actually ran wine without virtual desktop at one point where program crashed, had to hard reset because video wasn't restored, CTRL+ALT+BACKSPACE didn't work, so now i'm running everything in a virtual desktop, so I guess there isn't any hook and we expect all programs to behave. The hook could probably be put wined3d_main.c/DllMain() fdwReason == DLL_PROCESS_DETACH so it closes wined3d correctly, in the event of abnormal program execution. > Another possibility are apps that intend to cause an exception, like copy > protection systems. Anyway still need to know if the test fails or passes in Windows.

2 1

Failing tests: now what?
by Juan Lang June 3, 2008

June 3, 2008

Following through with Francois's suggestion, I extracted the user32 tests. They still fail for me: 81 failures in menu.c, all having to do with the expected width of menu items [1], which is precisely what I wanted to address. So I'm stymied how I'm going to convince Alexandre that my little menu patch [2] is correct. Vim is clearly broken without the patch, and looks correct with it. The user32 tests pass for me (in Wine) with and without the patch. None of the apps I've tried appear changed by the patch, though there's always the possibility. I can't verify it's correct in the usual way, by writing a test, because the existing tests fail for me in Windows. (Alexandre's never said he wants a test, but then again he hasn't said anything yet, either.) If anyone has any suggestions how I can get this accepted, I'm all ears. Thanks, --Juan [1] Typical failure: menu.c:432: Test failed: menu width wrong, got 109 expected 102 [2] http://www.winehq.org/pipermail/wine-patches/2008-May/055101.html

1 0

Re: Keep swapchain while its backbuffer is in use.
by Michael Karcher June 2, 2008

June 2, 2008

Am Montag, den 02.06.2008, 22:51 +0200 schrieb Michael Karcher: > This fixes the warn+heap errors/crashes of d3d9:stateblock, and should > close the bug about differences with warn+heap enabled. Thats #12246, one of the 1.0 targeted bugs. I was offline while writing the patch email, so I could not look up the number. Regards, Michael Karcher

1 0

Re: winedbg: Fix 'winedbg --auto' so it does just one backtrace.
by Alexandre Julliard June 2, 2008

June 2, 2008

Francois Gouget <fgouget(a)codeweavers.com> writes: > 'winedbg --auto' already prints a backtrace before the modules list. So > there is no need to print another one after everything else. Actually there are cases where it doesn't, which is why I added this. It's better to have two backtraces than none. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [2/2] wined3d: Set the surface location to SFLAG_INSYSMEM for depth stencils on Reset
by Stefan Dösinger June 2, 2008

June 2, 2008

Am Montag, 2. Juni 2008 21:12:54 schrieb H. Verbeet: > This fixes a rather major regression when using FBOs for offscreen > rendering. Since we destroy the GL texture associated with the > surface, and INDRAWABLE and INTEXTURE are the same for offscreen > targets when using FBO ORM, the texture would never get recreated for > the depth stencil. Depth stencils are special in this regard since > they can switch between being onscreen and offscreen, for the other > implicit surfaces this isn't an issue. This should also fix bug 12794. > (This bug does expose issues with the surface management code, but I > don't think those are fixable before 1.0) updateSurfaceDesc releases the allocated system memory, so setting INSYSMEM is dangerous as well since allocatedMemory = NULL. depth stencils are't lockable, so we may get away with that, but it is still dangerous I think

2 1

Re: [2/2] Wineshader: Hardcode local constants with glUniform4fvARB
by Stefan Dösinger June 2, 2008

June 2, 2008

Am Montag, 2. Juni 2008 21:45:07 schrieb Stefan Dösinger: Erm, the proper library is wined3d, not wineshader. "wineshader" is my current in-development HLSL compiler lib...

1 0

Invalid '...' in resources
by Francois Gouget June 2, 2008

June 2, 2008

The files below contain ' . . .' instead of '...'. This is invalid typographically in at least English, French and Russian. Could someone check if it is valid for the relevant languages: Danish Dutch Hungarian Korean Norwegian Turkish ./programs/winefile/No.rc ./programs/oleview/No.rc ./programs/clock/No.rc ./programs/cmd/Da.rc ./programs/cmd/No.rc ./programs/taskmgr/No.rc ./programs/notepad/No.rc ./programs/winhlp32/No.rc ./programs/progman/No.rc ./programs/cmdlgtst/No.rc ./programs/wordpad/Ko.rc ./programs/wordpad/No.rc ./programs/wordpad/Tr.rc ./programs/wordpad/Nl.rc ./programs/wordpad/Hu.rc ./programs/winecfg/No.rc ./programs/regedit/Ko.rc ./programs/regedit/Da.rc ./programs/regedit/No.rc ./programs/regedit/Nl.rc ./dlls/setupapi/No.rc ./dlls/mshtml/No.rc ./dlls/gphoto2.ds/gphoto2_No.rc ./dlls/shell32/shell32_No.rc ./dlls/sane.ds/sane_No.rc ./dlls/msvfw32/msvfw32_No.rc ./dlls/msvfw32/msvfw32_Da.rc ./dlls/oledlg/oledlg_No.rc ./dlls/msacm32/msacm_Da.rc ./dlls/msacm32/msacm_No.rc ./dlls/comdlg32/cdlg_No.rc ./dlls/browseui/rsrc_No.rc ./dlls/shdoclc/Da.rc ./dlls/shdoclc/No.rc ./dlls/user32/resources/user32_No.rc -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

3 2

How to handle lack of internet connection in conformance tests
by Austin English June 2, 2008

June 2, 2008

For curiousity's sake, I tested my work XP box today, first as usual, then after a reboot and disabling the network connection: http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/#group… http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/xp_aen… http://test.winehq.org/data/b4bf3553c4071a2a6979f1df08ae75aadde94b4b/xp_aen… Most of the tests came out the same, with some spurious failures in MSI/dinput/user32/etc. The interesting ones would be the urlmon/wininet. Some of these tests timeout (urlmon: protocol/url, wininet:http) , some failed (msxml3:domdoc), and some still passed(!) (wininet:ftp, wininet:generated, wininet:internet, wininet:url, wininet:urlcache, ws2_32:protocol, urlmon:misc). I haven't tested wine yet, as I can't bring down the network connection on any of the boxes I can currently test on, but I'll do so when I next get a chance. Either way, seems some of this behavior could be made more consistent (if network connection is down, either skip or timeout, but don't fail). I may try later with leaving the network connection up but removing the internet connection at the router... -Austin

1 0

Crash in test d3d9:stateblock with warn+heap is a wine bug
by Michael Karcher June 2, 2008

June 2, 2008

Hello developers (mostly direct3d hackers), the infamous crash in d3d9:stateblock [1] is caused by a call sequence that is forbidden according to the DirectX SDK documentation. The switch_rendertarget test makes a new swap chain, and sets its backbuffer as new rendering target, and then releases the swap chain. The backbuffer is obtained by GetBackBuffer on the new swapchain. The SDK tells states explicitly that you have to release all surfaces obtained by GetBackBuffer before you release the swapchain itself. [2] In Windows, this buggy behaviour seems to work nicely (no crash in the d3d9:stateblock test and no errors with maximum debugging settings in the debugging d3d9 runtime), whereas on wine, at releasing the backbuffer finally, some access to the state is made which has already been released with the swapchain. So, we have two options: - Consider using backbuffer of released chains buggy: Fix the test to not release the swapchain Upgrade the FIXMEs in dlls/wined3d/swapchain.c, lines 95 and 104 to ERR - Implement behaviour seemingly compatible to Windows: Have a hidden reference counter to the swap chain or for the contexts to prevent them from getting freed too early. Does anyone knows whether the test has this been written buggy on purpose (some app does this), or it is by accident? Regards, Michael Karcher [1]: Bugs 9916, 12246 [2]: http://msdn.microsoft.com/en-us/library/bb205902(VS.85).aspx

3 4

Winetest grrr...
by Juan Lang June 2, 2008

June 2, 2008

Since my tiny little menu patch didn't go in, I figured Alexandre wanted a test. So I tried to compile and run the existing one on Windows XP. It failed for me: lots of menu size tests failed. I checked the test.winehq.org data, and I don't see lots of failures on XP, so... I thought I'd run winetest.exe from Paul Millar's site, just in case the compilation environment had something to do with it. That locks up my laptop somewhere in the d3d/ddraw tests. I know some video drivers are so broken we don't want to run on them. I have an ATI Radeon Mobility 250. I thought this was a fairly common card. Is locking up the machine really acceptable here? How the ^$*@ am I supposed to produce a test when the existing ones fail/crash/burn for me? Grrr... --Juan

5 9

Re: winex11.drv: Add support for AlphaBlend with non-opaque SourceConstantAlpha values.
by Peter Urbanec June 2, 2008

June 2, 2008

Ángel Guzmán Maeso wrote: > A small change: > > +int x,y; > +for (x = 0; x < widthSrc; x++, tmpBits += 4) > + for(y=0;y<4;y++) > + tmpBits[y] = tmpBits[y] * blendfn.SourceConstantAlpha / 255; I'm not fussed one way or the other, but I can see at least two advantages in keeping the original code: 1) It's slightly more obvious that the data we are dealing with is four bytes of R, G, B and A - although a comment to that effect would be a better solution. 2) Compiler optimisers may do a slightly better job on the already unrolled loop. I'll leave it to Alexandre and co. to pick and choose which version makes it in.

1 0

Re: snmpapi: Stop tests from crashing on win98
by Paul Vriens June 2, 2008

June 2, 2008

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > snmpapi: Stop tests from crashing on win98 > > Best Regards > Alistair Leslie-Hughes > > > > > ------------------------------------------------------------------------ > > I still don't think they should be removed but that's my opinion. If not running is preferable shouldn't we just if(0) them and add some comments? -- Cheers, Paul.

2 1

Re: user32: Fix input tests failing on WinXP+ (resend)
by Vitaliy June 2, 2008

June 2, 2008

Vitaliy Margolen wrote: > --- > dlls/user32/tests/input.c | 29 +++++++++++++++++------------ > 1 files changed, 17 insertions(+), 12 deletions(-) >

1 0

Re: [PATCH] winealsa: Raise ALSA minimum period size to sane value
by John Klehm June 2, 2008

June 2, 2008

On Sun, Jun 1, 2008 at 6:58 PM, Zephiris <zephiris(a)gmail.com> wrote: > The ALSA period size can be set to rather odd values, and querying the > minimum period size isn't always guaranteed to be sane. Use a safety net > value. This fixes bug 13458. > > --- > > dlls/winealsa.drv/dsoutput.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > Please use your real name, Wine doesn't accept anonymous patches. --John

1 0

iexplore/gecko problems with recent builds
by Steven Edwards June 2, 2008

June 2, 2008

Hi, I did not find anything about this in bugzilla. Is anyone else having problems using builtin IE with gecko? I keep getting this error with the tip err:mshtml:before_async_open GetWineURL returned NULL -- 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 1

Re: Revert "wined3d: Put implicit surfaces into drawable on unload."
by H. Verbeet June 2, 2008

June 2, 2008

2008/6/2 Vitaliy Margolen <wine-patches(a)kievinfo.com>: > This reverts commit 0de167db9e2ef6c62ba48b050bc3d0ba2638467f. > Fixes bug 12794 and probably others related to the black screen with enabled > FBO. > --- > dlls/wined3d/surface.c | 11 ++--------- > 1 files changed, 2 insertions(+), 9 deletions(-) > I've actually got a more correct fix for this, which I'll send in later today.

1 0

Re: [try 4] user32: Use correct buffer header for cursor inCURSORICON_LoadFromFile
by Dmitry Timoshkov June 2, 2008

June 2, 2008

"Sergey Khodych" <khodych(a)gmail.com> wrote: > CreateIconFromResourceEx expects POINT16 at beginning of input buffer( > for cursors ). > Fixes bug #5031. Please follow the indentation/braces style of the file you are changing. -- Dmitry.

1 0

Re: [1/3] ddraw/tests: Detach surface if attaching worked by surprise (or refrast)
by James Hawkins June 2, 2008

June 2, 2008

On Sun, Jun 1, 2008 at 5:47 PM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > --- > dlls/ddraw/tests/dsurface.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > Patch already sent: http://winehq.org/pipermail/wine-patches/2008-May/055424.html -- James Hawkins

2 1

Re: [2/3] ddraw/tests: Add another refrast exception
by James Hawkins June 2, 2008

June 2, 2008

On Sun, Jun 1, 2008 at 5:48 PM, Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> wrote: > --- > dlls/ddraw/tests/dsurface.c | 5 ++++- > 1 files changed, 4 insertions(+), 1 deletions(-) > I've gone through all the latest test results, and this failure isn't happening anywhere that I've seen. Please link to where you're seeing this. -- James Hawkins

2 1

Re: advapi32: RegEnumKeyEx() should return "ERROR_INVALID_PARAMETER" if name_len is NULL
by James Hawkins June 1, 2008

June 1, 2008

On Sun, Jun 1, 2008 at 11:28 AM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > Like native. > > -- Andy. > --- > Changelog: > advapi32: RegEnumKeyEx() should return "ERROR_INVALID_PARAMETER" if name_len is NULL. > > diff --git a/dlls/advapi32/registry.c b/dlls/advapi32/registry.c > index 9ce3da0..41ef3bf 100644 > --- a/dlls/advapi32/registry.c > +++ b/dlls/advapi32/registry.c > @@ -473,7 +473,7 @@ LSTATUS WINAPI RegEnumKeyExW( HKEY hkey, DWORD index, LPWSTR name, LPDWORD name_ > TRACE( "(%p,%d,%p,%p(%d),%p,%p,%p,%p)\n", hkey, index, name, name_len, > name_len ? *name_len : -1, reserved, class, class_len, ft ); > > - if (reserved) return ERROR_INVALID_PARAMETER; > + if (!name_len || reserved) return ERROR_INVALID_PARAMETER; > if (!(hkey = get_special_root_hkey( hkey ))) return ERROR_INVALID_HANDLE; > > status = NtEnumerateKey( hkey, index, KeyNodeInformation, > @@ -537,7 +537,7 @@ LSTATUS WINAPI RegEnumKeyExA( HKEY hkey, DWORD index, LPSTR name, LPDWORD name_l > TRACE( "(%p,%d,%p,%p(%d),%p,%p,%p,%p)\n", hkey, index, name, name_len, > name_len ? *name_len : -1, reserved, class, class_len, ft ); > > - if (reserved) return ERROR_INVALID_PARAMETER; > + if (!name_len || reserved) return ERROR_INVALID_PARAMETER; > if (!(hkey = get_special_root_hkey( hkey ))) return ERROR_INVALID_HANDLE; > > status = NtEnumerateKey( hkey, index, KeyNodeInformation, > Please add a test. -- James Hawkins

1 0

Re: [2/2] ddraw: Rename IDirectDraw functions (try 2)
by Christian Costa June 1, 2008

June 1, 2008

Hi Michael, I think it would be better to fix function names in IDirectDraw7. Christian Michael Karcher a écrit : > The functions implementing IDirectDraw are called IDirectDrawImpl_Foo, > the ones implementing IDirectDraw7 are called alike. As they are > static functions in different files, the compiler has no problems > distinguishing them, but it confuses the reader of TRACE messages. > --- > dlls/ddraw/ddraw_thunks.c | 92 ++++++++++++++++++++++---------------------- > 1 files changed, 46 insertions(+), 46 deletions(-) > > ------------------------------------------------------------------------ > >

3 3

Two quick press mentions about Microsoft and Wine (the other one)
by Dan Kegel June 1, 2008

June 1, 2008

Microsoft Wine (Sept '07): http://www.sommelierindia.com/blog/2007/10/changing_the_world_with_a_micr.h… Microsoft bans searches for Wine in France (today): http://www.sbpost.ie/post/pages/p/story.aspx-qqqt=MEDIA+AND+MARKETING-qqqs=… Not sinister, just funny. And somewhat inconvenient...

1 0

Re: try 2: shell32: fix SHFileOperation copying to an empty file list
by James Hawkins June 1, 2008

June 1, 2008

On Sun, Jun 1, 2008 at 1:35 AM, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > This partially fixex bug 13394. > > Apparently there are two separate issues involved in that bug, one > with empty destination lists (which Windows seems to treat as a list > containing one 0-length string), and one involving long filenames. > This patch only addresses the empty lists. > This fix is wrong. We already handle empty file lists in parse_file list. If the list is empty, dwNumFiles is 0. Why did you add another variable for that? Also, you need to add a test case for multiple source files and an empty dest list for the FO_MOVE operation. You will not get ERROR_ACCESS_DENIED (the test will fail with your change). -- James Hawkins

1 0

Acid test: migrating the spouse
by Dan Kegel June 1, 2008

June 1, 2008

Been looking forward to trying this for a long time. What with Wine 1.0 nearly here, and a brand new computer to populate, I thought I'd try actually migrating my spouse to Linux / Wine, or at least see why it isn't yet practical. I'll record the process here: http://kegel.com/wine/migrating-user-1.html So far it's not quite clear it'll work, but it should be educational, and I'll at least get a bunch of good bug reports out of it. - Dan

2 1

Fwd: shell32: fix SHFileOperation copying to an empty file list
by Vincent Povirk June 1, 2008

June 1, 2008

Grr, forgot to copy list. ---------- Forwarded message ---------- From: Vincent Povirk <madewokherd+d41d(a)gmail.com> Date: Sat, May 31, 2008 at 9:46 PM Subject: Re: shell32: fix SHFileOperation copying to an empty file list To: James Hawkins <truiken(a)gmail.com> On Sat, May 31, 2008 at 9:42 PM, James Hawkins <truiken(a)gmail.com> wrote: > I'm not either. There's a very simple way to implement this. Also, > you need to add tests for the FO_MOVE action as well. Do tell, sir. None of the other operations actually succeed when the destination is an empty list (except delete of course). I can add tests for them to ensure they don't crash, but it seems unnecessary. > @@ -131,6 +132,7 @@ static void clean_after_shfo_tests(void) > DeleteFileA("test3.txt"); > DeleteFileA("test_5.txt"); > DeleteFileA("one.txt"); > + DeleteFileA("filename.tex"); > DeleteFileA("test4.txt\\test1.txt"); > DeleteFileA("test4.txt\\test2.txt"); > DeleteFileA("test4.txt\\test3.txt"); > > typo, and why didn't you stick with the convention used for all the > other test files (.txt, not .text)? This was intentional. It was to show that extensions are trimmed to three characters in this case. -- Vincent Povirk -- Vincent Povirk

2 3

Re: shell32: fix SHFileOperation copying to an empty file list
by James Hawkins June 1, 2008

June 1, 2008

On Sat, May 31, 2008 at 8:10 PM, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > On Windows, copying files to an empty file list copies each file to > the working directory, truncating each filename to 8.3 format. See bug > 13394. > > I'm not very happy about the way I implemented this (a special loop > just for the weird case), but it doesn't seem possible to use the > current copy_files loop. This is too different from what the function > does in every other possible situation. > I'm not either. There's a very simple way to implement this. Also, you need to add tests for the FO_MOVE action as well. @@ -131,6 +132,7 @@ static void clean_after_shfo_tests(void) DeleteFileA("test3.txt"); DeleteFileA("test_5.txt"); DeleteFileA("one.txt"); + DeleteFileA("filename.tex"); DeleteFileA("test4.txt\\test1.txt"); DeleteFileA("test4.txt\\test2.txt"); DeleteFileA("test4.txt\\test3.txt"); typo, and why didn't you stick with the convention used for all the other test files (.txt, not .text)? -- James Hawkins

1 0