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

Re: Wine broken in feisty/git

by Lei Zhang

On Tue, Apr 1, 2008 at 10:56 AM, Austin English <austinenglish(a)gmail.com> wrote: > Building today's git worked fine, until trying to run ~/wine-git/wine > notepad, which results in a segmentation fault. Wine 0.9.58 from the > reps works fine, as did rebuilding wine 0.9.58 in git. I'm starting > the bisect now, but am about to leave this machine and won't be able > to complete it until tomorrow. Anyone else seeing this? > > > No crashes here...

April 1, 2008

Wine broken in feisty/git

by Austin English

Building today's git worked fine, until trying to run ~/wine-git/wine notepad, which results in a segmentation fault. Wine 0.9.58 from the reps works fine, as did rebuilding wine 0.9.58 in git. I'm starting the bisect now, but am about to leave this machine and won't be able to complete it until tomorrow. Anyone else seeing this?

April 1, 2008

re: Wine Release Plan

by Dan Kegel

Paul V. wrote: >Just noticed that the dates attached to the versions on >http://wiki.winehq.org/WineReleasePlan are not correct. >0.9.58 came out on March 21st. >Does this mean we still stick to May 9th or do we stick to 0.9.61 as >being 1.0.0.rc1? Whoops, sorry 'bout that. Whatever Alexandre wants, as long as the release is in 2008 :-) I've updated the page to show correct dates. I inserted one more rc to keep the release in June, but I'm certainly open to other options if folks object. - Dan

April 1, 2008

Re: [2/2] cabinet.dll -> FDICopy: Bug fixed

by James Hawkins

2008/4/1 Vitaly Perov <vitperov(a)etersoft.ru>: > This is a bug fix for the FDICopy() function of cabinet.dll. > When you pass an empty cabinet file (It's correct cab-file, but it has no > files and folders inside) as a parameter, Wine detects that the file is > invalid. > In this case Windows return TRUE, but WINE return FALSE. So the installation > of certain software finishes with an error in WINE. > > Changelog: > - Added a bug fix for cabinet.dll FDICopy function. Now it works correctly > with an empty cab-files. > + if (!num_folders) + WARN("weird cabinet detect failure: This is an empty cabinet file \n"); + /* if num_folders is 0, it's correct cab, but empty */ If there's a test for this case, and it is a valid case, then why did you leave the WARN? -- James Hawkins

April 1, 2008

Re: [1/2] cabinet.dll -> FDICopy: Test added [Try 2]

by James Hawkins

2008/4/1 Vitaly Perov <vitperov(a)etersoft.ru>: > This test checks if function FDICopy() of cabinet.dll correctly works with an > empty cabinet file (It's correct cab-file, but it has no files and folders > inside). > In this case Windows return TRUE, but WINE return FALSE. So the installation > of certain software finishes with an error in WINE > > Changelog: > - Test added for cabinet.dll FDICopy function. This test checks if it > works correctly with an empty cab-files > @@ -593,9 +594,67 @@ static void test_FDIIsCabinet(void) delete_test_files(); } + +static void CreateEmptyCab(void) +{ + static const unsigned char file_array [] = { 0x4d, 0x53, 0x43, 0x46, + 0x00, 0x00, 0x00, 0x00, 0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, + 0x00, 0x24, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x01, + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}; + HANDLE hFile; + DWORD written; + BOOL result; + + hFile = CreateFile("test1.cab", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_TEMPORARY, NULL); + assert(hFile != INVALID_HANDLE_VALUE); + result=WriteFile(hFile, file_array, sizeof(file_array), &written, NULL); + CloseHandle( hFile ); + assert(result); /*can't write to file*/ +} + You need to use the FCI api to create this cabinet. +static void delEmptyCab(void) +{ + assert(DeleteFile("test1.cab")); +} + This is a very pointless function, just call DeleteFile("test...") in its place. Also, this isn't something that needs an assert. +INT_PTR __cdecl CopyProgress (FDINOTIFICATIONTYPE fdint, PFDINOTIFICATION pfdin) +{ + return FALSE; +} + Inconsistent style (space before opening parenthesis). +static void test_FDICopy(void) +{ + HFDI hfdi; + ERF erf; + BOOL ret; + char name[] = "test1.cab"; + char path[] = ""; /*native crashes if path=NULL*/ + The pszCabPath parameter of FDICopy should be the current directory. If you want to test using a relative cabinet path, do it in another test. + /* native crashes if hfdi is NULL or invalid*/ These comments don't really apply to the test you've added. You're only testing one thing (thus, unit test): how FDICopy responds to an empty cabinet. + hfdi = FDICreate(fdi_alloc, fdi_free, fdi_open, fdi_read, + fdi_write, fdi_close, fdi_seek, + cpuUNKNOWN, &erf); + ok(hfdi, "Expected non-NULL context\n"); + + /* TESTING FDICopy() */ Pointless comment, please remove it. + CreateEmptyCab(); + ret=FDICopy(hfdi,name,path,0,CopyProgress,NULL,0); + delEmptyCab(); Please move this (actually, a call to DeleteFile, see above) to the end of the function where cleanup happens. It gets in the way of the results of the test. + todo_wine + { + ok(ret, "Expected TRUE, got %d\n", ret); + } + If you're expecting TRUE, check for TRUE like the rest of the tests in this file. + /* successfully destroy hfdi*/ + ret = FDIDestroy(hfdi); + ok(ret, "Expected TRUE, got %d\n", ret); +} -- James Hawkins

April 1, 2008

ddiwrapper/Gsoc Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting)

by Hin-Tak Leung

So far only one person has signed up with gsoc to do the win32 print driver under linux... I found out why I couldn't build ddiwrapper earlier - it builds against latest wine now; the reason was that I was ripping from opensuse/suse src rpm, and I did not look at any of the bundled patch, and there is a bundled patch which does that. The authoritative site for ddiwrapper seems to be: ftp://ftp.suse.com/people/uli/ddiwrapper/ Although it is quite difficult to find, since most search engine gives various publibc part of suse/novell. I think the src.rpm bundled patch needs to go in properly as a new release, really. (uli(a)suse.de is the author of ddiwrapper). --- On Sun, 30/3/08, Detlef Riekenberg <wine.dev(a)web.de> wrote: > From: Detlef Riekenberg <wine.dev(a)web.de> > Subject: Re: DLL exports... HELP?! (wine based win32 printer drivers for openprinting) > To: "Hin-Tak Leung" <hintak_leung(a)yahoo.co.uk> > Cc: "Till Kamppeter" <till.kamppeter(a)gmail.com> > Date: Sunday, 30 March, 2008, 10:16 PM > On Sa, 2008-03-29 at 15:51 +0000, Hin-Tak Leung wrote: > > A personal question: would be like to be involved if a > student comes > > along, or in general in this area? (I looked it up, > you were the > > mentor for the 2007 wine project for the > printerproxy). > > > In general in this Area, Please. > > A applied as Mentor today to Help with the Applications > (winspool #at# googlemail.com) > > > You can reach me on irc (freenode.net) in #winehackers > My nick is "winspool" > > > -- > > By by ... Detlef __________________________________________________________ Sent from Yahoo! Mail. A Smarter Inbox http://uk.docs.yahoo.com/nowyoucan.html

April 1, 2008

Re: Hey all, introducing myself and my GSoC idea...

by James Hawkins

On Tue, Apr 1, 2008 at 3:58 AM, Robert Shearman <rob(a)codeweavers.com> wrote: > James Hawkins wrote: > > On Mon, Mar 31, 2008 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > > > > >> Personally, I've thought that playing around with the > >> native LPC API might be interesting. I'm sure there are other areas > >> of the native API that are sparsely documented, and for which some > >> test cases might prove useful. > >> > > > > But is the API in question useful for the Wine project as far as > > fixing apps? I don't think we should devote SOC resources to a > > project that doesn't progress Wine beyond just implementing more APIs. > > It is useful for getting native rpcrt4 to work, which in turn is useful > for getting other COM DLLs to work, and so is potentially useful for bug > triage and identifying the source of bugs in builtin COM DLLs. > LPC, yes, but the student just said the Native API. -- James Hawkins

April 1, 2008

Re: Greek translation patch correction

by Austin English

On Tue, Apr 1, 2008 at 7:11 AM, Dj Apal [GR] <djapal(a)gmail.com> wrote: > So should I resend the patches in individual mails or it's ok for now and > for the next time I create new patches, I can send them as you wish? > > 2008/4/1, James Hawkins <truiken(a)gmail.com>: > > > 2008/3/31 Dj Apal [GR] <djapal(a)gmail.com>: > > > > > Here are the separate patches as requested by James Hawkins > > > > > > > > > One patch per email. I see that's not on the sending_patches > > page...man our documentation is in such bad shape (and scattered all > > over the place). > > > > -- > > > > James Hawkins > > > > > > -- > Apostolos Alexiadis > > > > > Please resend each individual patch in a separate e-mail.

April 1, 2008

SOC suggestion - Vista Game Explorer APIs (needed for d3d10)

by Roderick Colenbrander

Hi, As the SOC deadline has been extended here another SOC project which I added to the wiki close to the previous deadline namely the Vista Game Explorer dll. Lots of users find Direct3D related projects cool. Part of the post-Wine-1.0 work will likely focus on D3D10. Just adding a full implementation of this dll won't get most games working as they use the Vista Game Explorer API for various purposes like storing game settings and profiles. Since this API is bundled with Windows we can't legally use Microsoft their dlls (if possible at all) and we need to add these APIs to Wine. This project would work on adding this dll. Regards, Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

April 1, 2008

Re: SOC Direct3D - Implement missing D3D9_xx DLLs?

by Stefan Dösinger

Am Dienstag, 1. April 2008 16:01:34 schrieb Jeroen Janssen: > Would it be worth mentioning this on the wine SOC 2008 page? > > Also, is there some info on what is left to do? > ( I found the code Andras wrote at > http://code.google.com/p/google-summer-of-code-2007-wine/downloads/list > ) Ya, might be worth mentioning. But since the last year's soc project didn't get too far I am a bit afraid of "infrastructure" projects. I think it is easier for a student to add something new if there is an existing framework where he can hook in. For one part because the coding is easier, and also from a motivation standpoint because you see early results. Of course if someone steps up and says he wants to go and write D3D10 tests I am willing to mentor such a problem.

April 1, 2008