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

Slackware packager?

by Jeremy White

So Adam Schreiber reports that he's no longer doing the Slackware packages. Is there an active Packager currently? If so, can you submit a patch to remove Adam's name and insert yours? If not, I guess I'll submit a patch to remove that column for Slackware... Cheers, Jeremy

Dec. 1, 2009

Re: [PATCH 2/2] jscript: Added lastIndex tests.

by Paul Vriens

On 11/30/2009 09:12 PM, Jacek Caban wrote: > --- > dlls/jscript/tests/regexp.js | 66 > ++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 66 insertions(+), 0 deletions(-) > > Hi Jacek, This one introduces test failures on Vista+ : http://test.winehq.org/data/tests/jscript:run.html Could you have a look? -- Cheers, Paul.

Dec. 1, 2009

Re: work underway: Dependency on openal incoming

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > You can. The "proper" way to do this is to use the CFBundle API. First > you need to find the framework. Typically, it's in > /System/Library/Frameworks, but the user might have a custom OpenAL in > /Library/Frameworks or in $HOME/Library/Frameworks. Then we tack on the > name of the framework we want, and create a CFURL object with the > finished path. We can pass this to CFBundleCreate() to get a bundle > object back. Then, we can use CFBundleLoadExecutable() to load the > bundle into memory. You can use CFBundleGetFunctionPointerForName() and > CFBundleGetFunctionPointersForNames() to extract function pointers from > the bundle, and when you're done with it, you can use > CFBundleUnloadExecutable(), followed by a CFRelease(), to close the bundle. > > The other way to do this is to use wine_dlopen() on the framework > executable, which is typically a file with the same name as the > framework in the framework directory (so, for OpenAL, it would be a file > named "OpenAL" in the "OpenAL.framework" directory). Then we can just > use wine_dlsym() to extract function pointers like any other dynamic > library. You still have to find the framework, though, which again is > usually in one of the standard directories. > > If you want, I can write you some functions that will do all this for you. The point is to be able to use the same code on all platforms. If we have to replicate the loader implementation by hand then we don't gain anything, it will still be a mess of MacOS-specific ifdefs. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2009

Re: [3/5] imagehlp: Implement ImageAddCertificate

by Alexandre Julliard

Owen Rudge <orudge(a)codeweavers.com> writes: > + sd = &nt_hdr.OptionalHeader.DataDirectory[IMAGE_FILE_SECURITY_DIRECTORY]; > + > + sd->Size = dwSize; > + sd->VirtualAddress = dwOfs; > + > + TRACE("size = %x addr = %x\n", sd->Size, sd->VirtualAddress); > + > + /* write the header back again */ > + count = SetFilePointer(handle, dos_hdr.e_lfanew, NULL, FILE_BEGIN); > + > + if (count == INVALID_SET_FILE_POINTER) > + return FALSE; > + > + count = 0; > + > + r = WriteFile(handle, &nt_hdr, sizeof nt_hdr, &count, NULL); The virtual address is not necessarily the same as the disk offset. Also you should check the various header sizes and magic numbers. The existing code is broken in that respect too, but as long as it was only reading it wasn't a big problem. Once we start modifying the file it needs to be much more robust. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2009

Re: work underway: Dependency on openal incoming

by Charles Davis

Alexandre Julliard wrote: > Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > >> Hello Alexandre, >> >> Alexandre Julliard schreef: >>> Openal missing at compile time or at runtime should be handled the same >>> way, i.e. by reporting no sound devices. It doesn't make sense to have >>> two different failure modes. >>> >> Mac OSX can only link directly to openal with -framework OpenAL, so >> dynamic linking is impossible. As a result dsound will fail to load if >> libopenal is missing. I don't think there is a better way to handle >> this without ugliness, I'm confident that all distributions are >> shipping a version of openal these days, even the 64-bits ones. > > I don't see why you couldn't dynamically load a framework, You can. The "proper" way to do this is to use the CFBundle API. First you need to find the framework. Typically, it's in /System/Library/Frameworks, but the user might have a custom OpenAL in /Library/Frameworks or in $HOME/Library/Frameworks. Then we tack on the name of the framework we want, and create a CFURL object with the finished path. We can pass this to CFBundleCreate() to get a bundle object back. Then, we can use CFBundleLoadExecutable() to load the bundle into memory. You can use CFBundleGetFunctionPointerForName() and CFBundleGetFunctionPointersForNames() to extract function pointers from the bundle, and when you're done with it, you can use CFBundleUnloadExecutable(), followed by a CFRelease(), to close the bundle. The other way to do this is to use wine_dlopen() on the framework executable, which is typically a file with the same name as the framework in the framework directory (so, for OpenAL, it would be a file named "OpenAL" in the "OpenAL.framework" directory). Then we can just use wine_dlsym() to extract function pointers like any other dynamic library. You still have to find the framework, though, which again is usually in one of the standard directories. If you want, I can write you some functions that will do all this for you. Chip

Dec. 1, 2009

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Alexandre Hardy

Thanks Paul, Right! Tried to implement it too fast! Other parts of the test code dereference the function pointer and I took my lead from there without checking properly. As far as the length goes, I don't really know much about UNC pathnames, so I'm not sure what exactly the result should be. I will need to read up to find an example that I can guarantee the length of. Kind regards Alexandre On Tue, Dec 1, 2009 at 12:52 PM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 12/01/2009 08:44 AM, Alexandre Hardy wrote: >> >> + length = (*pGetLongPathNameW)(unc_path,NULL,0); > > Why the brackets around *pGetLongPathNameW? > >> + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname >> (length=%d)\n",length); > > You called the W-function so the ok text needs to be adjusted. You also know > the length so why not check explicitly? > > -- > Cheers, > > Paul. > -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net -- -------------------------------------------------- Alexandre Hardy http://www.ahardy.za.net

Dec. 1, 2009

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Paul Vriens

On 12/01/2009 11:52 AM, Paul Vriens wrote: > On 12/01/2009 08:44 AM, Alexandre Hardy wrote: >> + length = (*pGetLongPathNameW)(unc_path,NULL,0); > > Why the brackets around *pGetLongPathNameW? > >> + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname >> (length=%d)\n",length); > > You called the W-function so the ok text needs to be adjusted. You also > know the length so why not check explicitly? > Hi Alexandre, Another thing is that your test doesn't proof that what you are changing is correct. You probably need a pre-filled buffer that you check after the call to see if that buffer indeed wasn't touched when the buffersize was too small. -- Cheers, Paul.

Dec. 1, 2009

Re: dlls/kernel32/path.c: Fix return values for UNC pathnames in GetLongPathNameW

by Paul Vriens

On 12/01/2009 08:44 AM, Alexandre Hardy wrote: > + length = (*pGetLongPathNameW)(unc_path,NULL,0); Why the brackets around *pGetLongPathNameW? > + ok(length>0,"GetLongPathNameA: Failed on UNC Pathname (length=%d)\n",length); You called the W-function so the ok text needs to be adjusted. You also know the length so why not check explicitly? -- Cheers, Paul.

Dec. 1, 2009

Re: work underway: Dependency on openal incoming

by Alexandre Julliard

Maarten Lankhorst <m.b.lankhorst(a)gmail.com> writes: > Hello Alexandre, > > Alexandre Julliard schreef: >> Openal missing at compile time or at runtime should be handled the same >> way, i.e. by reporting no sound devices. It doesn't make sense to have >> two different failure modes. >> > Mac OSX can only link directly to openal with -framework OpenAL, so > dynamic linking is impossible. As a result dsound will fail to load if > libopenal is missing. I don't think there is a better way to handle > this without ugliness, I'm confident that all distributions are > shipping a version of openal these days, even the 64-bits ones. I don't see why you couldn't dynamically load a framework, but in any case my point still stands, the failure mode should be the same for compile time vs. run time. Failing to load completely on Mac OS would be acceptable if there's no alternative, but we can do better on other platforms. -- Alexandre Julliard julliard(a)winehq.org

Dec. 1, 2009

RE: Introducing WineTestBot

by Greg Geldorp

> From: Austin English [mailto:austinenglish(a)gmail.com] > > On a slightly related note, would it be possible to add a > 16-bit display VM? I finally got around to testing wine on a 16-bit > display again, and several things have regressed. It would be good to > test the testsuite on windows in that configuration to see what > happens. I've added a VM that shows up on test.winehq.org as wtb-wxpprodpy16. Ge.

Dec. 1, 2009