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

Re: [3/5] gdiplus: Implement GdipGetPropertyIdList.

by Nikolay Sivov

On 6/25/2012 14:30, Dmitry Timoshkov wrote: > + > + return hr == S_OK ? Ok : hresult_to_status(hr); > } > No need for special case for S_OK here.

June 25, 2012

Re: [PATCH 2/2] opengl32: Check for valid context in wglGetProcAddress

by Chris Robinson

On Sunday, June 24, 2012 10:42:11 PM Roderick Colenbrander wrote: > @@ -797,7 +797,7 @@ static void test_getprocaddress(HDC hdc) > /* Temporarily disable the context, so we can see that we can't > retrieve functions now. */ wglMakeCurrent(hdc, NULL); > func = wglGetProcAddress("glActiveTextureARB"); > - todo_wine ok(func == NULL, "Function lookup without a context passed, > expected a failure; last error %#x\n", GetLastError()); > + ok(func == NULL, "Function lookup without a context passed, expected a > failure; last error %#x\n", GetLastError()); > wglMakeCurrent(hdc, ctx); > } Does this apply to all functions, or just the ones MS's DLL doesn't implement? I could imagine wlgGetProcAddress still returning functions that are in opengl32.dll without worrying about the driver.

June 25, 2012

Re: change wording of ok()-messages in winspool-tests?

by Alexandre Julliard

Julian Rüger <jr98(a)gmx.net> writes: > Hi Francois and list, > > [/nitpick-mode on] > I'm preparing a patch to fix typos/spelling/grammar in > dlls/winspool.drv/tests/info.c, where I stumbled across repeated > messages like > > ok( !retval, "function result wrong! False expected\n"); > or > ok( size == exact, "Parameter size wrong! %d expected got %d\n", > exact, size); > > > Do you think it's worth changing these? > (I think "Wrong function result: 'false' expected\n", and "Wrong > parameter size: expected %d, got %d\n" would be better) > > Do we have guidelines for strings like these? > For example: start with a captial letter, no punctuation at the end... > > What tests have "good" style I can use as reference? > > Best regards, > Julian > > PS: Am I bike shedding here? Does anyone care about stuff like this? Test failure messages are not supposed to be seen, if they are seen it's a bug. So it's not worth spending effort making them look nice or consistent. -- Alexandre Julliard julliard(a)winehq.org

June 25, 2012

Re: [3/3] d3drm: Implement IDirect3DRMMeshBuilderX_GetClassName

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19493 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 24, 2012

Re: [2/3] d3drm: Implement IDirect3DRMLight_GetClassName

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=19492 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 24, 2012

Re: [2/2] msxml3: Support xmlns[:*] attribute nodes intelligently.

by Ulrik Dickow

Hello again Nikolay and others, I'm back online. The first attachment is try 2 of the second patch, i.e. the one discussed in this thread. I hope it meets all of your concerns. I adjusted my plan slightly at this point: Den 12-06-2012 13:55, Ulrik Dickow skrev: > Den 12-06-2012 13:21, Nikolay Sivov skrev: >> On 6/12/2012 11:55, Ulrik Dickow wrote: >>> Patch 2 of 2 from http://bugs.winehq.org/show_bug.cgi?id=26226 . >>> [...] >>> + /* Emit appropriate fixme or warning in case of unsupported or invalid namespace. >>> [...] >> The question is more like what libxml2 thinks about that. If it follows >> w3c here which is likely the question will be - won't it break somewhere >> internally in libxml2 code if we hack it that way? > [...] > But maybe you are right that it is safer to return E_INVALIDARG, as I > did in an earlier version, to guard against future increased > intelligence in libxml2. Both of the applications in bug 26226 use the > correct W3C namespace, so they don't care. I'll change it back. The new patch returns E_NOTIMPL instead. That seems more appropriate to me, knowing that native msxml3 returns S_OK (like the first version of my patch) and that we will have to change it back if it turns out to break a real-life application. Evil apps that try to break us intentionally don't count :). The new patch gives exactly the same output for the tst-msxml_make_soap.c program as the old one. Consistent with this test, it also still succesfully fixes bug 26226 for BridgeCentral: BridgeCentral's SOAP requests again succeed perfectly. The new patch changes the output of the tst-msxml_xmlns_simple.c program. The new E_NOTIMPL behaviour actually made the original program crash because I failed to do proper error checking (see second attachment if you like, patch relative to the C attached to bugzilla). The new output of the fixed tst-msxml_xmlns_simple.c is in the third attachment. The differences to the old wine patch are in test 03 (only the FIXME text changed) and in test 04 (FAILures instead of ok, and now quite detailed FIXME texts instead of more general, invisible warnings). Of course, only the first attachment will be sent to wine-patches, and only if no objections appear here to prevent it. - Ulrik

June 24, 2012

change wording of ok()-messages in winspool-tests?

by Julian Rüger

Hi Francois and list, [/nitpick-mode on] I'm preparing a patch to fix typos/spelling/grammar in dlls/winspool.drv/tests/info.c, where I stumbled across repeated messages like ok( !retval, "function result wrong! False expected\n"); or ok( size == exact, "Parameter size wrong! %d expected got %d\n", exact, size); Do you think it's worth changing these? (I think "Wrong function result: 'false' expected\n", and "Wrong parameter size: expected %d, got %d\n" would be better) Do we have guidelines for strings like these? For example: start with a captial letter, no punctuation at the end... What tests have "good" style I can use as reference? Best regards, Julian PS: Am I bike shedding here? Does anyone care about stuff like this? Sorry for wasting your time ;)

June 24, 2012

Re: Incompatibility in Kernel32

by Ben Peddell

On 22/06/2012 7:23 PM, robert.van.herk(a)serioustoys.com wrote: >>> Is there any reason that you call DeleteFile() on a still being opened file? >> >> That's the whole point of this test. The observed behavior is that you can pass a >> filename to MsiRecordSetStream, successfully delete the file, and keep on using the >> stream. > > I think DeleteFile on a opened file is officially allowed in Windows. Although the MS documentation is vague: > > <QUOTE> > The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file. > > The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed. Subsequent calls to CreateFile to open the file fail with ERROR_ACCESS_DENIED. > </QUOTE> The first statement is true under the DOS-based Windows systems - DeleteFile fails with ERROR_ACCESS_DENIED when that file has one or more open file handles. The second statement is true under the NT Windows systems - DeleteFile will fail with ERROR_SHARING_VIOLATION if at least one handle to it isn't opened with FILE_SHARE_DELETE, and ERROR_ACCESS_DENIED if it has a memory mapping. Results from the attached test under Windows 7 x64: Testing with no sharing, same process and no file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, same process and no file mapping DeleteFile: OK Done Testing with no sharing, separate process and no file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, separate process and no file mapping DeleteFile: OK Done Testing with no sharing, same process and file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, same process and file mapping DeleteFile: Failed : 00000005 Done Testing with no sharing, separate process and file mapping DeleteFile: Failed : 00000020 Done Testing with FILE_SHARE_DELETE, separate process and file mapping DeleteFile: Failed : 00000005 Done Results from the attached test under Windows 98 SE: Testing with no sharing, same process and no file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, same process and no file mapping CreateFile failed : 00000057 DeleteFile: OK Done Testing with no sharing, separate process and no file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, separate process and no file mapping CreateFile failed : 00000057 DeleteFile: OK Done Testing with no sharing, same process and file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, same process and file mapping CreateFile failed : 00000057 DeleteFile: OK Done Testing with no sharing, separate process and file mapping DeleteFile: Failed : 00000005 Done Testing with FILE_SHARE_DELETE, separate process and file mapping CreateFile failed : 00000057 DeleteFile: OK Done -- Ben Peddell IT Support Bowen, Collinsville and Proserpine Catholic schools http://klightspeed.killerwolves.net/

June 23, 2012

Re: MSVCP60.dll

by Bruno Jesus

On Fri, Jun 22, 2012 at 5:27 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: > On 22 Jun 2012, at 20:17, Bruno Jesus wrote: >>> ... >>> BACKTRACE FOLLOWS:- >>> Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). >> >> This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109 >> > > Thanks Bruno, > > The problem seems to have been around for a very long time. Is it proving difficult to track down or something? I don't know, maybe someone else can answer that. What I know is that Piotr Caban is the one behind most of msvcp* bug resolutions. Bruno

June 22, 2012

Re: MSVCP60.dll

by John Emmas

On 22 Jun 2012, at 20:17, Bruno Jesus wrote: > On Fri, Jun 22, 2012 at 3:38 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: >> ... >> BACKTRACE FOLLOWS:- >> Unhandled exception: unimplemented function msvcp60.dll.??0Init(a)ios_base@std@@QAE(a)XZ called in 32-bit code (0x7b83aed2). > > This problem is already reported in http://bugs.winehq.org/show_bug.cgi?id=27109 > Thanks Bruno, The problem seems to have been around for a very long time. Is it proving difficult to track down or something? John

June 22, 2012