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

AppDB:Nice URLs Question on integration / Request for testing
by John Klehm 01 Apr '08

01 Apr '08

Hello, So I have a working "nice urls" implementatino here: http://appdb.klehm.net/app/ Simply enter in anything after app/ (e.g. http://appdb.klehm.net/app/visual-basic) At this point its better to enter in too little of the desired app name rather than too much. (better to have visual-basic or visual than visual-basic-7) So test away and let me know how to improve it or whatnot. Also as you'll see if you try it out, relative urls are broken (lack of css, so its ugly =P) because well the page we return is now relative to the searched term. As I see it we can integrate this with appdb in 2 ways. Make all urls absolute or make functions of the main viewing pages and pass a url base into them. Any ideas or comments on the best way to get around this problem would be great. Regards, John Klehm

1 0

Wine broken in feisty/git
by Austin English 01 Apr '08

01 Apr '08

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?

4 6

msxml3 bug 10802
by viny 01 Apr '08

01 Apr '08

Hi, When creating an xml file, wine shouldn't create header automatically. Is that difficult to fix this bug (http://bugs.winehq.org/show_bug.cgi?id=10802) ? I've looked at domdoc.c but I'm not an expert...

2 1

Re: wininet: InternetReadFileExA should check INTERNET_FLAG_ASYNC.
by Hans Leidekker 01 Apr '08

01 Apr '08

On Thursday 27 March 2008 21:52:24 Dan Hipschman wrote: > incorrect. Here are a few Windows failures: > > http.c:584: Test failed: expected status 10 (INTERNET_STATUS_RESOLVING_NAME) 0 times, received 1 times > http.c:585: Test failed: expected status 11 (INTERNET_STATUS_NAME_RESOLVED) 0 times, received 1 times > http.c:587: Test failed: expected status 30 (INTERNET_STATUS_SENDING_REQUEST) 2 times, received 1 times > http.c:588: Test failed: expected status 31 (INTERNET_STATUS_REQUEST_SENT) 2 times, received 1 times > http.c:589: Test failed: expected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) 2 times, received 1 times > http.c:590: Test failed: expected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) 2 times, received 1 times > http.c:591: Test failed: expected status 110 (INTERNET_STATUS_REDIRECT) 1 times, received 0 times Some of these are also failing when you run them through a proxy server. I put in some debug printing which confirmed that they only fail when the async flag is set. So the test seems to be racy; the higher latency of the proxy connection and your script with built in delays nicely explain that. -Hans

1 0

crash on exit in hardy on intel graphics?
by Dan Kegel 01 Apr '08

01 Apr '08

Grumble. wineprefixcreate is showing a crash while running rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf No traceback is shown normally, but running that command under winedbg shows one on exit: Unhandled exception: page fault on read access to 0x00000200 in 32-bit code (0xb7f03bad). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:b7f03bad ESP:0034fa90 EBP:0034fab8 EFLAGS:00010292( - 00 -RISA1) EAX:b7f0bce0 EBX:b7f0bff4 ECX:b7efe5b9 EDX:b7c5e6ac ESI:00000000 EDI:00000000 Stack dump: 0x0034fa90: b7ef0eec b7f0bff4 0034fae0 7c017834 0x0034faa0: 0034fb14 b7efa059 0034fb5c b7c61ff4 0x0034fab0: 00000000 7c003188 0034fac8 b7c5fcb4 0x0034fac0: 00000000 b7f0bff4 0034fba8 b7efe5d6 0x0034fad0: 00000000 00000000 0034fb38 b7cce2d1 0x0034fae0: 7c003190 7c003198 7c003194 b7c5e6ac Backtrace: =>1 0xb7f03bad in ld-linux.so.2 (+0x12bad) (0x0034fab8) 2 0xb7c5fcb4 GLIBC_2+0xcb4() in libdl.so.2 (0x0034fac8) 3 0xb7efe5d6 in ld-linux.so.2 (+0xd5d6) (0x0034fba8) 4 0xb7c602bc in libdl.so.2 (+0x12bc) (0x0034fbc8) 5 0xb7c5fcea GLIBC_2+0xcea() in libdl.so.2 (0x0034fbd8) 6 0x7dda57bd in libgl.so.1 (+0x477bd) (0x0034fbf8) 7 0x7dd8584a in libgl.so.1 (+0x2784a) (0x0034fc18) 8 0x7dd87924 in libgl.so.1 (+0x29924) (0x0034fc48) 9 0x7dd80ba4 in libgl.so.1 (+0x22ba4) (0x0034fc58) 10 0x7ddc39bc glIsRenderbufferEXT+0x16c() in libgl.so.1 (0x0034fc68) 11 0xb7efefdf in ld-linux.so.2 (+0xdfdf) (0x0034fe18) 12 0xb7c90f74 exit+0xd4() in libc.so.6 (0x0034fe38) 13 0x7efacc80 RtlGetCurrentPeb() [/home/dank/wine-git/dlls/ntdll/process.c:70] in ntdll (0x0034fec8) 14 0x7ee7d62f ExitProcess+0x2f(status=0x0) [/home/dank/wine-git/dlls/kernel32/process.c:2046] in kernel32 (0x0034fee8) 15 0x7ecad3ba __wine_spec_exe_entry+0x6a(peb=0x7ffdf000) [/home/dank/wine-git/dlls/winecrt0/exe_entry.c:38] in rundll32 (0x0034ff08) 16 0x7ee7fd4e start_process+0xee(arg=0x0) [/home/dank/wine-git/dlls/kernel32/process.c:883] in kernel32 (0x0034ffe8) 17 0xb7de18f7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0xb7f03bad: testb $0x8,0x200(%edi) libgl.so is involved, so perhaps the is a graphics driver bug? The system is a thinkpad x60 with intel graphics. glxgears gets 960 fps. Anybody else seeing this? It seems kind of benign, and doesn't keep 'wine notepad' from working...

2 5

Re: user32: Implement BroadcastSystemMessage, try 6
by Paul Vriens 01 Apr '08

01 Apr '08

Maarten Lankhorst wrote: > Removed most LastError tests except where they are useful. > > > ------------------------------------------------------------------------ > > Hi Maarten, + if (!recipients) + recipients = &recips; + Will that work? Cheers, Paul

1 0

Re: SOC Direct3D - Implement missing D3D9_xx DLLs?
by tony.wasserka＠freenet.de 01 Apr '08

01 Apr '08

> Can someone confirm this to be already finished (and then remove this item from > the wiki?) If it isn't finished yet, what IS missing then? Nearly everything is missing. It's just the forwarding and some stubs that have been defined, yet, and the D3DXRenderToSurface implementation I submitted recently was coded with d3d9 traces, which was something AJ didn't like for reimplementing d3dx9. That means someone other needs to take care of that interface, but that's OT for this discussion. > D3D10_xx DLLs seem to be currently missing (I know we don't have any d3d 10 > implementation yet in wine) and it probably isn't a SOC project, but would > completely stubbed D3D10_xx DLLs (patches) be accepted if I submit them to the > patch mailinglist or not? I personally don't think it makes very much sense to stub a big library like d3dx10 without being able to really implement it (as we'd need d3d10 for this first). You could ask AJ for this on #winehackers, but I guess he'll be the same opinion. However, you can of course stub the d3dx10 dlls on your local tree and submit them when our d3d10 implementation is ready. > Ok, then the SOC text on the wiki for this item is slightly > "misleading" / outdated. I have updated the GSoC and D3DX wiki sites, so that one gets a very quick overview of how "far" we are with implementing it, yet. Best regards Tony

1 0

re: Wine Release Plan
by Dan Kegel 01 Apr '08

01 Apr '08

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

1 0

Re: [2/2] cabinet.dll -> FDICopy: Bug fixed
by James Hawkins 01 Apr '08

01 Apr '08

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

1 0

Re: [1/2] cabinet.dll -> FDICopy: Test added [Try 2]
by James Hawkins 01 Apr '08

01 Apr '08

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

1 0