March 2009 - Wine-Devel - list.winehq.org

Re: GetTempFileName should return 0 when the path isn't valid

by Paul Vriens

Oskar Eisemuth wrote: > Hello > >>> GetTempFileName should check the path and should return zero if it isn't a directory. >>> See Bug 17875 >>> >>> --- >>> dlls/kernel32/path.c | 10 ++++++++++ >>> 1 files changed, 10 insertions(+), 0 deletions(-) >> Can you add a testcase for this? > > That would need something like an non existent subpath or path? > > I guess it would be something like a copy of NONDIR_SHORT. > > sprintf(tmpstr,"%s%s",tmppath, NONDIR_SHORT); > ok((id=GetTempFileNameA(tempstr,"path",0,newdir)),"GetTempFileNameA failed\n"); > > -- > Oskar > > > Your patch tests 2 things, so the tests have to as well: 1. Non existing directory 2. Path is not a directory In both cases you set the return value and the last error, so the tests again have to check for both. -- Cheers, Paul.

March 30, 2009

Re: GetTempFileName should return 0 when the path isn't valid

by Vitaliy Margolen

Oskar Eisemuth wrote: > GetTempFileName should check the path and should return zero if it isn't a directory. > See Bug 17875 > Tests verifying the behavior will be nice. Shouldn't be too hard to add. Vitaliy.

March 30, 2009

Re: 16bit code generation

by Hin-Tak Leung

I wonder how bad is it to port some old version of djgpp forward? ( http://www.delorie.com/djgpp/history.html ) - it is a fork of gcc as far as I see and did support 16-bit code generation at one time?

March 30, 2009

Re: 16bit code generation

by King InuYasha

On Sun, Mar 29, 2009 at 6:12 PM, David Gerard <dgerard(a)gmail.com> wrote: > 2009/3/28 Austin English <austinenglish(a)gmail.com>: > > On Sun, Mar 22, 2009 at 5:34 PM, King InuYasha <ngompa13(a)gmail.com> > wrote: > > >> What is wrong with OpenWatcom? It is an open source development > toolchain, > >> with experimental linux binaries, yes, but they do work the last time I > >> checked (which was when 1.8 release came out). > > > It's not widely available, it's license is not open enough for many > > distros (ArchLinux has it available, and there's an initial Gentoo > > ebuild according to their wiki), but Fedora/Suse/Ubuntu don't have it > > available. > > > It fails DFSG (so I'm surprised it passed OSI, given OSI is based on > DFSG), with many important concerns raised: > > http://www.mail-archive.com/debian-legal(a)lists.debian.org/msg34684.html > > I emailed licensing(a)fsf.org to ask about it (since it isn't on their > list of licenses) and got back a quick reply saying an official > determination wasn't likely any time in the foreseeable future, but > it's definitely not GPL compatible and they couldn't actually tell at > a glance if it was FSF "free" or not. > > > - d. > > > Unfortunately, at the moment it really is the best we have. AFAIK, there isn't any other FOSS compiler that can build 16-bit DOS/Win16 applications. Unless someone was actually willing to figure out how to make GCC be able to target Win16 (not likely) or write a whole new compiler toolchain to target Win16/DOS, there really isn't anything else left to use.

March 29, 2009

Re: 16bit code generation

by David Gerard

2009/3/28 Austin English <austinenglish(a)gmail.com>: > On Sun, Mar 22, 2009 at 5:34 PM, King InuYasha <ngompa13(a)gmail.com> wrote: >> What is wrong with OpenWatcom? It is an open source development toolchain, >> with experimental linux binaries, yes, but they do work the last time I >> checked (which was when 1.8 release came out). > It's not widely available, it's license is not open enough for many > distros (ArchLinux has it available, and there's an initial Gentoo > ebuild according to their wiki), but Fedora/Suse/Ubuntu don't have it > available. It fails DFSG (so I'm surprised it passed OSI, given OSI is based on DFSG), with many important concerns raised: http://www.mail-archive.com/debian-legal(a)lists.debian.org/msg34684.html I emailed licensing(a)fsf.org to ask about it (since it isn't on their list of licenses) and got back a quick reply saying an official determination wasn't likely any time in the foreseeable future, but it's definitely not GPL compatible and they couldn't actually tell at a glance if it was FSF "free" or not. - d.

March 29, 2009

Re: urlmon ftp protocol failures on Windows

by Jacek Caban

Ge van Geldorp wrote: > Hi Jacek, > > I've been investigating the failures in the urlmon ftp protocol tests that > show up on quite a few WinXP and higher machines. It seems to me that there > is an inherent race condition in the test. > The main thread waits in line 1822 until IInternetProtocolSink_Switch has > been called. It will then call CHECK_CALLED(Switch) and SET_EXPECT(Switch). > However, nothing prevents a background thread from calling > IInternetProtocolSink_Switch again before SET_EXPECT(Switch) in the main > thread is complete. In fact, if I add a Sleep(100) between the > WaitForSingleObject() in line 1822 and the CHECK_CALLED() on the next line, > the failures that show up now and then on test.winehq.org become > reproducible every time. > I believe the attached patch fixes the problem, it breaks the current > assumption that there's a 1:1 relationship between > IInternetProtocolSinc_Switch() and IInternetProtocol_Read() calls. Before > shipping it off to wine-patches, I'd like your opinion, do you think this is > the correct solution? > Great investigation, thanks. I wonder why it doesn't happen for http tests, in which have the same assumption. Your fix looks good for me, please send it to wine-patches. Thanks, Jacek

March 29, 2009

Re: mciqtz32: Add basic play capability

by Christian Costa

Finally it is wma->pgraph which leaks not wma->pmctrl. Thanks for the review. Bye, Christian Detlef Riekenberg a écrit : > On Sa, 2009-03-28 at 16:36 +0100, Christian Costa wrote: > >> + hr = CoCreateInstance(&CLSID_FilterGraph, NULL, >> CLSCTX_INPROC_SERVER, &IID_IGraphBuilder, (LPVOID*)&wma->pgraph); >> + if (FAILED(hr)) { >> + TRACE("Cannot create filtergraph (hr = %x)\n", hr); >> + return MCIERR_INTERNAL; >> + } >> > > Again TABs in the Code. > > >> + >> + hr = IGraphBuilder_QueryInterface(wma->pgraph, >> &IID_IMediaControl, (LPVOID*)&wma->pmctrl); >> + if (FAILED(hr)) { >> + TRACE("Cannot get IMediaControl interface (hr = %x)\n", hr); >> + return MCIERR_INTERNAL; >> > > TAB again. > And while i read this quote: You leak wma->pmctrl here. > > >

March 29, 2009

Re: wined3d [try 4]: SetDepthStencilSurface is always called when AutoDepthStencil is enabled

by Henri Verbeet

2009/3/29 David Adam <david.adam.cnrs(a)gmail.com>: > - return WINED3DERR_INVALIDCALL; > + HRESULT hrc; You're still using 9 space indentation.

March 29, 2009

urlmon ftp protocol failures on Windows

by Ge van Geldorp

Hi Jacek, I've been investigating the failures in the urlmon ftp protocol tests that show up on quite a few WinXP and higher machines. It seems to me that there is an inherent race condition in the test. The main thread waits in line 1822 until IInternetProtocolSink_Switch has been called. It will then call CHECK_CALLED(Switch) and SET_EXPECT(Switch). However, nothing prevents a background thread from calling IInternetProtocolSink_Switch again before SET_EXPECT(Switch) in the main thread is complete. In fact, if I add a Sleep(100) between the WaitForSingleObject() in line 1822 and the CHECK_CALLED() on the next line, the failures that show up now and then on test.winehq.org become reproducible every time. I believe the attached patch fixes the problem, it breaks the current assumption that there's a 1:1 relationship between IInternetProtocolSinc_Switch() and IInternetProtocol_Read() calls. Before shipping it off to wine-patches, I'd like your opinion, do you think this is the correct solution? Thanks, Ge.

March 29, 2009

Re: WineD3D: Check for the presence of wglGetExtensionsStringARB

by Robert Millan

On Sun, Mar 29, 2009 at 10:11:19PM +0200, Roderick Colenbrander wrote: > Hi, > > Don't call wglGetExtensionsStringARB when it isn't around. After this patch > WineD3D can work unpatched on VirtualBox. Hi, I can confirm this works fine on VirtualBox. Thanks Roderick -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all."

March 29, 2009