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

Re: sorry guys... slow on uptake today :)
by James Mckenzie June 25, 2010

June 25, 2010

Misha Koshelev <misha680(a)gmail.com> wrote: > >So I've been working on bug 13891, but got sidetracked by what I thought >was a race condition as dlls/shell32/tests/shlexec.c was hanging. > >Spent several hours tracing it to line 464 in dlls/ntdll/directory.c > > if (stat( entry->mnt_dir, &st ) == -1) continue; > >(read from /etc/mtab) > >Turned out it was my curlftpfs file system, which tends to disconnect >randomly and not unmount (doh!). > >Anyway I hope to have perhaps some tests for this bug before I leave to >Russia (on Sat morning), but unfortunately I might not be able to get >this bug fixed until post-code freeze. Sorry :( > If the fix is large and ugly, it will not be looked at until after the code freeze is lifted anyway. Have a safe travel. James Mckenzie

2 1

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed
by Alexandre Julliard June 25, 2010

June 25, 2010

Mikko Rasa <tdb(a)tdb.fi> writes: > + /* check that the buffer is large enough to hold the indices, > + * reallocate if necessary. > + */ > + hr = IWineD3DBuffer_GetDesc(This->indexbuffer, &desc); > + if(desc.Size < IndexCount * sizeof(WORD)) > + { > + UINT size = desc.Size; > + IWineD3DBuffer *buffer; > + IUnknown *parent; > + > + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + /* We keep adding zero bits to the right, so an overflow > + * will eventually result in all zeroes. Detect this to > + * avoid infinite loop. > + */ > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + LeaveCriticalSection(&ddraw_cs); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } A simple "size = max(desc.Size*2,IndexCount*sizeof(WORD))" would do just as well. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Silence a noisy fixme.
by Henri Verbeet June 25, 2010

June 25, 2010

I don't think so. That FIXME should have been an ERR, and if you're seeing it that's a bug.

1 0

sorry guys... slow on uptake today :)
by Misha Koshelev June 25, 2010

June 25, 2010

So I've been working on bug 13891, but got sidetracked by what I thought was a race condition as dlls/shell32/tests/shlexec.c was hanging. Spent several hours tracing it to line 464 in dlls/ntdll/directory.c if (stat( entry->mnt_dir, &st ) == -1) continue; (read from /etc/mtab) Turned out it was my curlftpfs file system, which tends to disconnect randomly and not unmount (doh!). Anyway I hope to have perhaps some tests for this bug before I leave to Russia (on Sat morning), but unfortunately I might not be able to get this bug fixed until post-code freeze. Sorry :( Misha

1 0

Re: comctl32/tests: remove noisy trace
by testbot＠testbot.winehq.org June 24, 2010

June 24, 2010

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=2910 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

1 0

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by James Mckenzie June 24, 2010

June 24, 2010

Henri Verbeet <hverbeet(a)gmail.com wrote: > >On 24 June 2010 18:11, Misha Koshelev <misha680(a)gmail.com> wrote: >> Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I >>will just go down the list of 1.2 milestone bugs for now and see if I can help. >> >Yeah, milestone bugs should generally be ok, as well as any open regressions. > Some of the regression bugs are pre-Wine 1.0. Sad, but if you can fix those, it would greatly help bring Wine code up-to-date. James McKenzie

2 1

Re: [PATCH] [try 4] ddraw: Grow indexbuffer as needed
by Stefan Dösinger June 24, 2010

June 24, 2010

> + while(size < IndexCount * sizeof(WORD)) > + { > + size <<= 1; > + } Thinking about it, is there a reason for growing the buffer in power of two sizes, and not simply set it to the size required for the draw call? E.g. if the app passes index data with a size somewhere between 2^31 and 2^32-1(which still still fits in the UINT variable) the power of two growing will try to create a 2^32 byte buffer which overflows and fails. So you're cutting the possible index buffer size in half. (Of course if an app actually tries to create a >2GB index buffer we have bigger problems than the UINT, especially in a 32 bit process)

2 2

Re: Porting WIne to D
by James Mckenzie June 24, 2010

June 24, 2010

Gert van den Berg <wine-devel(a)mohag.net> wrote: >Like the D website says: >Who D is Not For > * Realistically, nobody is going to convert million line C or C++ >programs into D. Since D does not compile unmodified C/C++ source >code, *D is not for legacy apps*. (However, D supports legacy C API's >very well. D can connect directly to any code that exposes a C >interface.) That should rule out moving Wine to D for a long time. 9 Million + lines of code would make this a lengthy, but not impossible, task. > >D also specifically drops 16-bit support, which might cause problems >for the Win16 / DOS parts of Wine... Another show-stopper for those folks using Wine to run Windows 2.x/3.x programs. James McKenzie

2 1

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by Misha Koshelev June 24, 2010

June 24, 2010

> > On 24 June 2010 05:18, Misha Koshelev <misha680 at gmail.com> wrote: > > Dan suggested tests ok during code freeze so blame Dan for my patches ;) > Certainly will. wine-devel is an open mailing list, and posting is > easy. You'll probably want to check with something like "git shortlog > -s -n" if the advice you're getting is actually worth taking. The way > I see it, you have more experience with getting patches accepted > yourself. More to the point, if you look at > http://source.winehq.org/patches/, you'll see 62909 is marked as > "Deferred", so resending in a slightly different form isn't going to > help much. Ah I see thank you. I take it this means deferred until post-code freeze (please correct me if incorrect). > > > As for the patch itself, I'm not convinced there's value in having a > separate file for "Shape Drawing Functions", these are clearly mesh > constructors. I thought the original patch was mostly ok in that > regard, although there are (very) minor issues like using %d for > unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 > over simply "IDirect3DDevice9 *". > Ok thank you. Since we are in code freeze and I'd like to help wine, perhaps then I will just go down the list of 1.2 milestone bugs for now and see if I can help. Post code freeze, I can then start on the d3dx9 stuff as I am really not akin to having my own private repo as of yet and I think that going from a private repo to getting patches into Wine itself might be a little more difficult than I'd like - rather than doing it all at once... So thus for now work on 1.2 milestones. Then D3DX9. Off to work... Misha

2 1

Re: kernel32: Update Gaelic resource
by Michael Stefaniuc June 24, 2010

June 24, 2010

Hello Ken, Ken Sharp wrote: > From: Ken Sharp <kennybobs(a)o2.co.uk> > Date: Tue, 15 Jun 2010 09:42:05 +0100 > Subject: kernel32: Update Gaelic resource the patch changes the file encoding to UTF-8 without changing the "#pragma code_page" too. Though Alexandre already rejected codepage changes to the NLS files during the 1.2 freeze as too risky changes; NLS files are more than just translations. The best thing is to resend the changes without the codepage change. thanks bye michael

1 0

Re: kernel32: Update Gaelic resource
by Dmitry Timoshkov June 24, 2010

June 24, 2010

Ken Sharp <kennybobs(a)o2.co.uk> wrote: > diff --git a/dlls/kernel32/nls/gae.nls b/dlls/kernel32/nls/gae.nls > index 6e19ff4..a005be3 100644 > --- a/dlls/kernel32/nls/gae.nls > +++ b/dlls/kernel32/nls/gae.nls Looks like you are using UTF-8 while the file is in code page 1252. -- Dmitry.

1 0

Porting WIne to D
by Christopher Selph June 24, 2010

June 24, 2010

Hi everyone, new here. I have been fooling around with the idea of porting WIne to the D programming language. What do you think would be the chances of sucess? D has the speed of C, but is a garbage collected language and OOP. D: http://www.digitalmars.com/d Chris

5 4

Re: [PATCH] ddraw: Grow indexbuffer as needed (now with overflow check)
by Stefan Dösinger June 24, 2010

June 24, 2010

Am 24.06.2010 um 11:30 schrieb Mikko Rasa: > On 24.06.2010 12:07, Stefan Dösinger wrote: >> >> Am 23.06.2010 um 21:57 schrieb Mikko Rasa: >>> + if(!size) >>> + { >>> + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); >>> + return D3DERR_TOOMANYPRIMITIVES; >>> + } >>> + } >> You have to release the ddraw lock before returning from the function(LeaveCriticalSection(&ddraw_cs)) > > Doh. Fixed that; anything else that should be rectified before I resubmit? Nothing I can spot so far

1 0

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by Henri Verbeet June 24, 2010

June 24, 2010

On 24 June 2010 05:18, Misha Koshelev <misha680(a)gmail.com> wrote: > Dan suggested tests ok during code freeze so blame Dan for my patches ;) Certainly will. wine-devel is an open mailing list, and posting is easy. You'll probably want to check with something like "git shortlog -s -n" if the advice you're getting is actually worth taking. The way I see it, you have more experience with getting patches accepted yourself. More to the point, if you look at http://source.winehq.org/patches/, you'll see 62909 is marked as "Deferred", so resending in a slightly different form isn't going to help much. As for the patch itself, I'm not convinced there's value in having a separate file for "Shape Drawing Functions", these are clearly mesh constructors. I thought the original patch was mostly ok in that regard, although there are (very) minor issues like using %d for unsigned arguments and using imo ugly typedefs like LPDIRECT3DDEVICE9 over simply "IDirect3DDevice9 *".

1 0

Re: [PATCH 2/7] d3dx9: Add IUnknown method calls to ID3DXMesh.
by Henri Verbeet June 24, 2010

June 24, 2010

On 24 June 2010 05:18, Misha Koshelev <misha680(a)gmail.com> wrote: > +#if !defined(__cplusplus) || defined(CINTERFACE) > +/*** IUnknown methods ***/ > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->lpVtbl->QueryInterface(p,a,b) > +#define ID3DXMesh_AddRef(p) (p)->lpVtbl->AddRef(p) > +#define ID3DXMesh_Release(p) (p)->lpVtbl->Release(p) > +#else > +/*** IUnknown methods ***/ > +#define ID3DXMesh_QueryInterface(p,a,b) (p)->QueryInterface(a,b) > +#define ID3DXMesh_AddRef(p) (p)->AddRef() > +#define ID3DXMesh_Release(p) (p)->Release() > +#endif > + Which version of the DX SDK do these match?

1 0

Re: [PATCH] ddraw: Grow indexbuffer as needed (now with overflow check)
by Stefan Dösinger June 24, 2010

June 24, 2010

Am 23.06.2010 um 21:57 schrieb Mikko Rasa: > + if(!size) > + { > + ERR("UINT overflow while trying to grow indexbuffer to hold %u indices\n", IndexCount); > + return D3DERR_TOOMANYPRIMITIVES; > + } > + } You have to release the ddraw lock before returning from the function(LeaveCriticalSection(&ddraw_cs))

1 0

Question about video capture and rendering and encoding in wine
by shenyue June 24, 2010

June 24, 2010

Hi everyone, Previously I post this question on wine-user forum, seems nobody answered/interested, so I post it here. Hope somebody give me a hand :) I have some questions about wine video capture andrendering. I'm a newbie to wine, and am working on QQ or any other messengers in wine. My environment is : ubuntu 10.04, installed wine 1.1.42 (later when I modify code, wine-1.1.42's source instead), QQ2009. And during my debugging, I also check some source code from latest wine 1.2-rc4. Although QQ's level is "garbage", but fortunately it works almost fine under wine, including login, text chat, ..... But the video call can only partially work.I can see my friend's(he's under windows of course) video, while I can't see my preview video, and he cannot see mine video too. And no audio at all. (Audio is another issue, I haven't deal with it now.) As a comparison, I run GraphEdt to check what's wrong with video capture and rendering, my filter graph=video capture + video render. when I 'use clock', the same thing happens, no video rendering at all, but when I DONOT 'use clock', video rendering works fine. Then I read the source code and find out one problem(maybe right, maybe wrong), when wine/dlls/qcap/v4l.c send media samples to downstream filters, it do not set any timestamp on it. Thus if I use VideoRenderer as I did in GraphEdt, the video render got wrong start and stop reference time for media sample, and then the synchronisation result will be very strange. So I modify the v4l.c and set proper timestamp on media sample. Good result, even when I 'use clock', the capture+render graph works find in GraphEdt. But when I turn to QQ, my video capture+preview+encoding graph still seems don't work. Then I checked msdn for these things, according to msdn: "Video frames from a preview pin (as opposed to a capture pin) are not time stamped. Because of graph latency, a video frame that is stamped with the capture time will always arrive late at the video renderer. This may cause the renderer to drop frames, in an attempt at quality control." "Quality control is a mechanism for adjusting the rate of data flow through the filter graph in response to run-time performance. If a renderer filter is receiving too much data or too little data, it can send a quality message. The quality message requests an adjustment in the data rate. By default, quality messages travel upstream from the renderer until they reach a filter that can respond (if any)." I've cheked winedbg log, QQ's filter graph looks like: vfw capture filter + QQ's own video render filter + ... + ddraw/d3d7 rendering. QQ did not use smarttee, preview pin, standard VideoRender or VideoRenderDefault or VideoMixingRender9 (because QQ never query their id). Instead, I guess QQ write a video render filter by itself, and in QQ's render filter, it directly use ddraw/d3d7 surface to render, and maybe it does something similar to smarttee, to output to preview and encoding at the same time. Since QQ did not use preview pin directly, at first I guess maybe 'not time stamped' is not correct, so I add some timestamp to capture's output video frame, still no preview occurs, but result in continuous IQualityControl interface query, but even latest wine-1.2-rc4 has not implemented IQualityControl, so I guess, still something wrong in timestamp synchronisation, and QQ's video render want to use IQualityControl to fix it which wine doesn't support, so maybe every frame is dropped, this result in my black preview video window. I read from wine docs/wiki, once before windows messenger (8.1?) worked fine in wine, I guess since you have written qcap/vfwcapture, of course somebody has used wine for camera+preview+maybe encoding before, why it succeeded by then, but fail now? Is there anything wrong for me? Btw1: there's a bug in wine-1.1.42's dlls/quartz/memallocator.c, MediaSample's GetTime() return value is wrong, I've fixed that bug according to latest wine, but still no video preview, and my friend cannot see my video. Btw2: since qcap only works for v4l1, I ran flashcam to convert v4l2 to v4l1. But I still wondering, since Maarteen original code supports v4l2, why it result in only support v4l1 (but not both v4l1 and v4l2)? Thank you very much in advance. Best regards, Karma 搬迁通知： 2010年1月18日起，上海奇码数字信息有限公司迁至新址办公。新地址为：上海张江祖冲之路887弄88号502室。 ==========================================================

2 2

re: [PATCH 7/7] d3dx9: Test raw vertex data for D3DXCreateSphere.
by Dan Kegel June 24, 2010

June 24, 2010

Misha wrote: + /* comparisons of 0.0f with -0.0f do not quite seem to work correctly */ Boy, that's for sure. + todo_wine ok( vertex_data[i].x==test_vertex_data[i].x || (fabsf(vertex_data[i].x) < 0.0001f && fabsf(test_vertex_data[i].x) < 0.0001f), "Got result %f, expected %f\n",vertex_data[i].x,test_vertex_data[i].x); You probably want to define an AlmostEqual() function and use that rather than repeating the logic. See http://code.google.com/p/googletest/wiki/GoogleTestAdvancedGuide#Floating-P… and the paper it points to, http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm - Dan

1 0

something I hacked up for git - maybe will help
by Misha Koshelev June 24, 2010

June 24, 2010

I like to reapply my patches a lot - so this gets rid of trailing whitespace and applies the patch. Just thought I'd send out. I know there's tools to avoid trailing whitespace in emacs (http://github.com/glasserc/ethan-wspace works well), but this is my simple solution ;) Misha

1 0

Re: [PATCH 7/7] d3dx9: Test raw vertex data for D3DXCreateSphere.
by testbot＠testbot.winehq.org June 24, 2010

June 24, 2010

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=2889 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 6/7] d3dx9: Add tests for D3DXCreateSphere vertex buffer description.
by testbot＠testbot.winehq.org June 24, 2010

June 24, 2010

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=2888 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 5/7] d3dx9: Test number of vertices for D3DXCreateSphere.
by testbot＠testbot.winehq.org June 24, 2010

June 24, 2010

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=2887 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 3/7] d3dx9: Add framework for a more sophisticated D3DXCreateSphere test.
by testbot＠testbot.winehq.org June 24, 2010

June 24, 2010

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=2886 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: [PATCH 1/7] d3dx9: Shape functions in own file, add stub and basic tests for D3DXCreateSphere.
by testbot＠testbot.winehq.org June 24, 2010

June 24, 2010

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=2885 Your paranoid android. === WINEBUILD (build) === Make failed

1 0

Re: Porting WIne to D
by Christopher Selph June 24, 2010

June 24, 2010

>Porting a codebase the size > >of Wine will probably take years... > > Actually I'm working on a program to convert C code to D code. You can > find/replace most instances of code, like unsigned int (C) with uint (D). > The import/include files might take some work though. > > > On Wed, Jun 23, 2010 at 2:46 PM, Gert van den Berg <wine-devel(a)mohag.net>wrote: > >> On Wed, Jun 23, 2010 at 20:48, Stephen Eilert <spedrosa(a)gmail.com> wrote: >> > On Wed, Jun 23, 2010 at 3:06 PM, Christopher Selph <cds.wine(a)gmail.com> >> wrote: >> >> Well, being a garbage collected language, it would help with the memory >> >> leaks in Wine. Being OOP it could extend the design of the code to make >> it >> >> cleaner and reusable. >> > >> > The assertions above are opinions, not facts. Also, it requires a full >> rewrite. >> > >> You can mix D code and C code... >> >> A more modern language can result in more readable code, but it is a >> lot of effort for a small benefit... (And D is a very new language, >> possibly to the degree that portability might be impacted due to a >> lack of compilers on some of the more obscure platforms / >> architectures). >> >> Certain parts of Wine might benefit from the latest (draft) version of >> C++ and the size of the codebase can probably be reduced in size >> slightly, but a bad port to another language doesn't help anyone... >> (The C++ standard library is huge and might getrid of some POSIX >> dependancies) It might require quite an extensive rewrite to get it to >> a proper C++ program, rather than a C program containing a bit of C++ >> and compiled with a C++ compiler... >> >> Fixing the current problems with Wine should be a much higher priority >> than porting it to a different language... Porting a codebase the size >> of Wine will probably take years... C can do anything that other >> languages can, the amount of effort might differ a bit, bit the >> difference is probably minor compared to familiarizing yourself with a >> new language, new libraries, etc.... >> >> (I like D - it have most features from languages like Java and C#, >> with the option to switch off things like garbage collection and it >> compiles to native code... Experimenting with it for new project might >> make sense) >> >> (IMHO: Allowing other languages than C for some of Wine's bundled >> applications (notepad, winecfg, winemine, etc) might make sense, as >> long as the QC for committing patches doesn't suffer. The mixing of >> languages within components (single application / DLL) will probably >> cause confusion and ugly code though... Getting proper QC would >> probably mostly involve sticking to things that AJ is familiar with.) >> >> Gert >> >> >> >

3 3