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

Re: setupapi: Make sure machine name is non-empty before failing

by Juan Lang

> What's wrong with 'if (MachineName && *MachineName)' ? Nothing, it's my brain that's lacking. Thanks. --Juan

June 9, 2011

Re: setupapi: Make sure machine name is non-empty before failing

by Dmitry Timoshkov

Juan Lang <juan.lang(a)gmail.com> wrote: > +static const WCHAR emptyW[] = { 0 }; ... > - if (MachineName != NULL) > + if (MachineName != NULL && strcmpW(MachineName, emptyW)) What's wrong with 'if (MachineName && *MachineName)' ? -- Dmitry.

June 9, 2011

re: TaskDialog implementation

by Dan Kegel

Patrick wrote: > I'd like to port my re-implementation of task dialogs > (http://www.korosoft.net/projects/tdemu/) to WINE Awesome! > I would like to have some guidance ... [Why was my patch from > yesterday not accepted?] An iota of guidance was provided at http://source.winehq.org/patches/ Scroll down to your patch, you can see it's in "Pending" state. Scroll down further, you'll see that "Pending" means "The patch is not obviously correct at first glance. Making a more convincing argument, preferably in the form of a test case, may help." See also http://wiki.winehq.org/SubmittingPatches for a generic checklist. Your patch seemed to do three things: - moving old stub into new file - adding a TaskDialog function - adding ordinals Those three things could all be separate patches, and some of them could have tests. I'd suggest sending just one of the three first (probably not the one that moves code to a new file), and including a test with the first patch. - Dan

June 9, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Michael Mc Donnell

On Thu, Jun 9, 2011 at 1:56 PM, Ricardo Filipe <ricardojdfilipe(a)gmail.com> wrote: > 2011/6/9 Henri Verbeet <hverbeet(a)gmail.com> >> On 9 June 2011 13:01, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >> > On a side note, failing to get a device means that the d3dx tests are >> > always skipped on the testbot? >> > >> The ones that need a device, yes. The testbot machines are all VMs, so >> they don't have real display hardware. For a realistic setup with real >> hardware we'd probably need at least 2 different Windows versions (e.g >> Win 7 and XP), and at least the current and the previous generation of >> both AMD and NVIDIA display hardware. We could probably manage the >> hardware costs for that, but I imagine that the setup and admin >> overhead would be significant compared to the VMs. Yeah I haven't seen any good way of virtualizing graphics hardware, and it sounds like it would be difficult to setup real machines, as they would need to be able to roll back automatically after each test run. > you can usually find someone on irc (like me) with a windows setup where you > can test these patches, until there is some proper testing platform. Thanks for the offer, but I already own a Windows machine. It's just a hassle to switch between Linux and Windows, and it would be nice to have automated testing for regression purposes.

June 9, 2011

Re: TaskDialog implementation

by Vincent Povirk

+ if (pnButton) *pnButton = IDYES; + if (pnRadioButton) *pnRadioButton = pTaskConfig->nDefaultButton; + if (pfVerificationFlagChecked) *pfVerificationFlagChecked = TRUE; + return S_OK; I don't think it's appropriate to make selections for the user like this. If you can't present all of the choices to the user, you should probably return E_NOTIMPL. Writing tests first would also help. > I'm going to take my code and clean it to WINE's source code standards, > however I do not see how I could split it in many patches as everything > is dependant on everything else. I think Lats' advice here is sound. You might start with a dialog with only an OK button (that only displays if the dialog offers no choices to the user), then add features one at a time. > As this is quite a big amount of work, I would like to have some > guidance (what must I do to be sure it is accepted) so that I do not end > up doing all that for nothing - starting by knowing why my patch from > yesterday was not accepted (what did I do wrong). Well, you shouldn't write it all at once anyway, as you'd likely have to change all of your later work.

June 9, 2011

Re: TaskDialog implementation

by Juan Lang

Hi Patrick, > As this is quite a big amount of work, I would like to have some > guidance (what must I do to be sure it is accepted) so that I do not end > up doing all that for nothing - starting by knowing why my patch from > yesterday was not accepted (what did I do wrong). The patch was marked as "Pending." That usually means Alexandre's waiting for something, e.g. for you to fix something obvious, or to see what else you're planning to do. Since you say the patch is preparatory work, it doesn't make much sense to go in unless the remaining patches are also to go in, so I'd suggest sending at least another patch to show where you're going with it. Regarding splitting, sometimes it's useful to introduce code that will only be removed later. I know this isn't the usual advice, but if you introduce a new implementation of something, sometimes a stub implementation can appear first. E.g., if it's an interface you're implementing, introduce an implementation that does nothing but return E_NOTIMPL from each method. Then one by one introduce implementation for each function. Hope that helps, --Juan

June 9, 2011

Re: TaskDialog implementation

by Lats

I have been looking at this and my advice is start simple and establish the basic framework ie. display a frame with a title. Then add functions and text items or buttons types one by one. Add complexity to the functions after the basic form is accepted. On 09/06/11 17:00, Patrick Gauthier wrote: > Hello everyone, > > I'd like to port my re-implementation of task dialogs > (http://www.korosoft.net/projects/tdemu/) to WINE, actually I have > posted a small patch yesterday (merely rearranges some source around, > preparatory work) which sadly did not seem to get accepted. > > I'm going to take my code and clean it to WINE's source code standards, > however I do not see how I could split it in many patches as everything > is dependant on everything else. > > As this is quite a big amount of work, I would like to have some > guidance (what must I do to be sure it is accepted) so that I do not end > up doing all that for nothing - starting by knowing why my patch from > yesterday was not accepted (what did I do wrong). > > Thanks for your time and help. > > >

June 9, 2011

Re: [PATCH 2/2] urlmon: Added empty file binding test

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=11581 Your paranoid android. === WVISTAADM (32 bit protocol) === Failure running script in VM: The specified guest user must be logged in interactively to perform this operation

June 9, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Stefan Dösinger

On Thursday 09 June 2011 13:22:27 Henri Verbeet wrote: > The ones that need a device, yes. The testbot machines are all VMs, so > they don't have real display hardware. Maybe we can set up the refrast? It has some problems, and not all our tests will pass(intentionally), but it would allow to run most of the tests, and probably help d3dx9 a lot. The refrast will slow down testbot a lot though, at least when we run the d3d9:visual tests. The last time I tested them in qemu it took about 10 minutes to run them. That was about 2 years ago.

June 9, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Stefan Dösinger

On Thursday 09 June 2011 13:01:17 Michael Mc Donnell wrote: > Change it to brackets on new lines? I actually copied the style from > the method above mine. Is this better?: > > + struct > + { > ... > + } vertices[] = > + { Yes, although I'd also move the vertices[] in a separate line. The other tests in this file aren't entirely consistent, but I've seen at least one that used your old style and one that uses the new style. In wined3d and related dlls we use the new style.

June 9, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Ricardo Filipe

2011/6/9 Henri Verbeet <hverbeet(a)gmail.com> > On 9 June 2011 13:01, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > > On a side note, failing to get a device means that the d3dx tests are > > always skipped on the testbot? > > > The ones that need a device, yes. The testbot machines are all VMs, so > they don't have real display hardware. For a realistic setup with real > hardware we'd probably need at least 2 different Windows versions (e.g > Win 7 and XP), and at least the current and the previous generation of > both AMD and NVIDIA display hardware. We could probably manage the > hardware costs for that, but I imagine that the setup and admin > overhead would be significant compared to the VMs. > you can usually find someone on irc (like me) with a windows setup where you can test these patches, until there is some proper testing platform.

June 9, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Henri Verbeet

On 9 June 2011 13:01, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On a side note, failing to get a device means that the d3dx tests are > always skipped on the testbot? > The ones that need a device, yes. The testbot machines are all VMs, so they don't have real display hardware. For a realistic setup with real hardware we'd probably need at least 2 different Windows versions (e.g Win 7 and XP), and at least the current and the previous generation of both AMD and NVIDIA display hardware. We could probably manage the hardware costs for that, but I imagine that the setup and admin overhead would be significant compared to the VMs.

June 9, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Michael Mc Donnell

On Wed, Jun 8, 2011 at 8:32 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > On Wednesday 08 June 2011 18:51:41 Michael Mc Donnell wrote: >> unsigned int faces[] = {0, 1, 2}; >> unsigned int num_faces = sizeof(faces) / 3; > Does this do what you want? As far as I can see you want ARRAY_SIZE(faces) / > 3. You're right that was a bug > >> + struct { >> + D3DXVECTOR3 position0; >> + D3DXVECTOR3 position1; >> + D3DXVECTOR3 normal; >> + DWORD color; >> + } vertices[] = { >> ... > Another style nitpick: Bracket placing. Change it to brackets on new lines? I actually copied the style from the method above mine. Is this better?: + struct + { + D3DXVECTOR3 position0; + D3DXVECTOR3 position1; + D3DXVECTOR3 normal; + DWORD color; + } vertices[] = + { + { { 0.0f, 1.0f, 0.f}, { 1.0f, 0.0f, 0.f}, {0.0f, 0.0f, 1.0f}, 0xffff0000 }, + { { 1.0f, -1.0f, 0.f}, {-1.0f, -1.0f, 0.f}, {0.0f, 0.0f, 1.0f}, 0xff00ff00 }, + { {-1.0f, -1.0f, 0.f}, {-1.0f, 1.0f, 0.f}, {0.0f, 0.0f, 1.0f}, 0xff0000ff }, + }; > >> + /* Two null pointers. Setting only the mesh to null will result in an >> + * exception on Windows. >> + */ >> + hr = mesh->lpVtbl->UpdateSemantics(NULL, NULL); > I think setting the instance pointer to NULL when invoking a method doesn't > need a test, it will give you odd results. What you show here is that native > checks the only method parameter before it accesses the object instance. > Remember, usually apps will invoke this via C++: > > mesh->UpdateSemantics(declaration); > > Similarly it isn't necessary to check iface or This against NULL in the > implementations. Ok, I've removed that check. That wasn't what was causing the exception though. The problem was that it failed to get a device on the testbot. I had forgotten to set the mesh to NULL, so in the cleanup part it tried to release a random pointer, which caused an exception. On a side note, failing to get a device means that the d3dx tests are always skipped on the testbot? > Otherwise this looks OK Ok, I'll try again later.

June 9, 2011

Re: [PATCH 1/4] shell32/tests: basic tests of IKnownFolderManager

by Mariusz Pluciński

Thank you for suggestions. I fixed the problems. W dniu 05.06.2011 22:26, Vincent Povirk pisze: > + /* try to set new path */ > + hr = IKnownFolder_SetPath(folder, 0, sTempDir); > + todo_wine > + ok(hr == S_OK, "setting path failed: 0x%08x\n", hr); > > I'd suggest making up + registering your own known folder to test this > feature, rather than using a standard one. I worry someone could end > up with a broken Windows install if we fail to put it back somehow Testing of registering custom folders is implemented in patch I did not submit yet. I think I will simply move test of setting path to (or after) that patch. -- Best regards Mariusz Pluciński

June 9, 2011

TaskDialog implementation

by Patrick Gauthier

Hello everyone, I'd like to port my re-implementation of task dialogs (http://www.korosoft.net/projects/tdemu/) to WINE, actually I have posted a small patch yesterday (merely rearranges some source around, preparatory work) which sadly did not seem to get accepted. I'm going to take my code and clean it to WINE's source code standards, however I do not see how I could split it in many patches as everything is dependant on everything else. As this is quite a big amount of work, I would like to have some guidance (what must I do to be sure it is accepted) so that I do not end up doing all that for nothing - starting by knowing why my patch from yesterday was not accepted (what did I do wrong). Thanks for your time and help.

June 9, 2011

Re: [2/2] d3dx9: Implement UpdateSemantics mesh method.

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=11567 Your paranoid android. === WXPPROSP3 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W2K3R2SESP2 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === WVISTAADM (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W2K8SE (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W7PRO (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W7PROX64 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EA43 === W7PROX64 (64 bit mesh) === Timeout

June 8, 2011

Re: Simple Windows Diaglogue App

by Stefan Dösinger

On Wednesday 08 June 2011 14:31:57 Lewis McLean wrote: > LinuxPort.cpp:34: error: cast from 'CHAR*' to 'WORD' loses precision Is this a Win16 app? I don't see how casting a pointer to a WORD is supposed to work otherwise.

June 8, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

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=11566 Your paranoid android. === WXPPROSP3 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W2K3R2SESP2 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === WVISTAADM (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W2K8SE (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W7PRO (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W7PROX64 (32 bit mesh) === mesh: unhandled exception c0000005 at 0042EB8D === W7PROX64 (64 bit mesh) === Timeout

June 8, 2011

Re: [1/2] d3dx9/test: Add UpdateSemantics test.

by Stefan Dösinger

On Wednesday 08 June 2011 18:51:41 Michael Mc Donnell wrote: > unsigned int faces[] = {0, 1, 2}; > unsigned int num_faces = sizeof(faces) / 3; Does this do what you want? As far as I can see you want ARRAY_SIZE(faces) / 3. > + struct { > + D3DXVECTOR3 position0; > + D3DXVECTOR3 position1; > + D3DXVECTOR3 normal; > + DWORD color; > + } vertices[] = { > ... Another style nitpick: Bracket placing. > + /* Two null pointers. Setting only the mesh to null will result in an > + * exception on Windows. > + */ > + hr = mesh->lpVtbl->UpdateSemantics(NULL, NULL); I think setting the instance pointer to NULL when invoking a method doesn't need a test, it will give you odd results. What you show here is that native checks the only method parameter before it accesses the object instance. Remember, usually apps will invoke this via C++: mesh->UpdateSemantics(declaration); Similarly it isn't necessary to check iface or This against NULL in the implementations. Otherwise this looks OK

June 8, 2011

re: Simple Windows Diaglogue App

by Dan Kegel

Lewis wrote: > I'm trying to compile a simple windows dialogue app over to run on *nix > with winelib. I'm looking at it as proof of concept for porting a larger > application over. First off, why winelib rather than plain wine? Are you planning on targeting non-x86 computers? > LinuxPort.cpp:34: error: cast from 'CHAR*' to 'WORD' loses precision It might help to see your source code. - Dan

June 8, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Wed, Jun 8, 2011 at 12:59 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 8 June 2011 11:33, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: >> Henri, do you have any comments about my UpdateSemantics patches >> before I send them off to wine-patches? >> > Looks fine to me. Good :-) > On the subject of style though, two things: > - I really dislike things like LPDWORD and LPD3DXMESH. For one, > there's the issue that "const LPDWORD" doesn't do what you want, so > you'd need something like "LPCDWORD", which doesn't exist. The other > issue is that unless typedefs are used for some kind of abstraction, > like e.g. uint32_t, they're just obfuscation. I.e., "typedef type > *LPTYPE;" just hides that "LPTYPE" is a pointer, and "typedef > enum/struct x x;" just hides that "x" is a struct or enum. Thank you for the explanation. I've changed those. > - "There’s a standard naming scheme for C, and it’s all lower case > with underscores as separators." Ah yes, I've been writing too much C++ and C# lately :-) I've changed that too. I've also moved the declaration of a vertex struct inside the test function, as it was not needed outside of the test function. Thank you for your comments.

June 8, 2011

Simple Windows Diaglogue App

by Lewis McLean

Hi, I'm trying to compile a simple windows dialogue app over to run on *nix with winelib. I'm looking at it as proof of concept for porting a larger application over. I've been getting errors from gcc to do with vc++ casting, where it loses precision. LinuxPort.cpp: In function 'int WinMain(HINSTANCE__*, HINSTANCE__*, CHAR*, int)': LinuxPort.cpp:34: error: cast from 'CHAR*' to 'WORD' loses precision LinuxPort.cpp:39: error: cast from 'CHAR*' to 'WORD' loses precision winegcc: i486-linux-gnu-g++ failed Ive tried to use static_cast<> and also c-style casting using () but can't seem to get it working. Any ideas? Thanks, Lewis

June 8, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Henri Verbeet

On 8 June 2011 11:33, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > Henri, do you have any comments about my UpdateSemantics patches > before I send them off to wine-patches? > Looks fine to me. On the subject of style though, two things: - I really dislike things like LPDWORD and LPD3DXMESH. For one, there's the issue that "const LPDWORD" doesn't do what you want, so you'd need something like "LPCDWORD", which doesn't exist. The other issue is that unless typedefs are used for some kind of abstraction, like e.g. uint32_t, they're just obfuscation. I.e., "typedef type *LPTYPE;" just hides that "LPTYPE" is a pointer, and "typedef enum/struct x x;" just hides that "x" is a struct or enum. - "There’s a standard naming scheme for C, and it’s all lower case with underscores as separators."

June 8, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Tue, May 31, 2011 at 2:30 PM, Michael Mc Donnell <michael(a)mcdonnell.dk> wrote: > On Tue, May 31, 2011 at 12:51 PM, Michael Mc Donnell > <michael(a)mcdonnell.dk> wrote: >> On Mon, May 30, 2011 at 10:09 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>> 2011/5/30 Michael Mc Donnell <michael(a)mcdonnell.dk>: >>>> Thanks for the comments Matteo! I have a few questions below. >>>> >>>> On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: >>>>> 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >>>>>> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >>>>>> <stefandoesinger(a)gmx.at> wrote: >>>>>>> On Saturday 28 May 2011 19:55:55 you wrote: >>>>>>> >>>>>>>> It was implemented by setting the vertex declaration to null when the >>>>>>>> declaration is invalid. That seems to match what happens on Windows, >>>>>>>> because if a program has set an invalid declaration and then calls >>>>>>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>>>>>> Should Wine also fail with an access violation or should it be >>>>>>>> slightly more graceful and return E_FAIL instead (which my new patch >>>>>>>> does)? >>>>>>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>>>>>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>>>>>> be shown by default(unlike a FIXME), it is used when the app does something >>>>>>> fishy but you think you handled it correctly. >>>>>>> >>>>>>>> + if (FAILED(hr)) >>>>>>>> + new_vertex_declaration = NULL; >>>>>>>> + >>>>>>>> + /* Free old vertex declaration */ >>>>>>>> + if (This->vertex_declaration) >>>>>>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>>>>>> In this situation you can just release the old decl before calling >>>>>>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>>>>>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>>>>>> NULL in case of an error though >>>>>> >>>>>> Ok I've simplified the code. I've also inserted three WARNs. I've >>>>>> skipped a WARN when freeing the mesh because that works fine on >>>>>> Windows with an invalid declaration. >>>>>> >>>>>>>> + /* Set the position type to color instead of float3 (invalid >>>>>>> declaration) */ >>>>>>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>>>>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>>>>>> + "got %#x expected D3D_OK\n", hr); >>>>>>> Is this really invalid? I don't know it on top of my head, but in general >>>>>>> types and usage are independent, especially with shaders. I don't see a check >>>>>>> in d3d9 or wined3d for this case. >>>>>> >>>>>> You're right it isn't invalid. It doesn't crash, it just doesn't draw >>>>>> anything. I've change that comment and re-ordered the tests. >>>>>> >>>>>>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>>>>>> devel one more time and then next week to wine-patches. Henri is on Vacation >>>>>>> this week, and he's usually more picky than I am. I also hope some of the >>>>>>> people who regularly contribute to d3dx9 will have a look and comment. >>>>>> >>>>>> Ok, I've attached the newest version. I'll let the patches sit here >>>>>> for a week, and start working on the other functions in the mean time. >>>>>> >>>>> >>>>> The patches are OK with me, just some nitpicking: >>>> >>>> That sounds great :-) >>>> >>>>> + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); >>>>> >>>>> We usually use something like HeapAlloc(GetProcessHeap(), 0, >>>>> sizeof(*testContext)); instead. >>>> >>>> Ok, I guess that's better in case the type of the variable changes at >>>> some point? >>>> >>> >>> Yes, that's a reason. The other one is simply consistency. >> >> Ok, I've changed that. >> >>>>> I think you can remove some obvious comments (like /* Create the test >>>>> mesh */). Also, check your whitespaces. >>>> >>>> Is it too much or too little whitespace? Could you give me an example? >>> >>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics for bigger vertex size, " >>> >>> + "got %#x expected D3D_OK\n", hr); >>> >>> Here you put 4 spaces on the line continuation, which is neither the >>> "align to be below the '(' + 1 space" used in most of the file, nor >>> the 8 spaces used in wined3d. The d3dx9_36 sources aren't known for a >>> nice and consistent coding style (I'm sure you noticed that), so >>> that's mostly trying to not mix even more style variants... >> >> Ok I've changed it to the "align to be below the '(' + 1 space" convention. >> >>> There was also something wrong with spaces in a comment that caught my >>> eye, I think. >> >> The only thing that stood out to me was that I had extra newlines in >> my multi-line comments. I've removed those. >> >>> I told you I was nitpicking... :) >> >> That's ok, I prefer consistency too :-) > > Oops the patches I sent earlier had a tab character and some > superfluous whitespace. Henri, do you have any comments about my UpdateSemantics patches before I send them off to wine-patches? Thanks

June 8, 2011

mmdevapi event driven (aka. pull) mode

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, >What behavior do you think Wine is going to do wrong Matthew van Eerde's web log has a sample silence playing application using EVENTCALLBACK mode. http://blogs.msdn.com/b/matthew_van_eerde/archive/2008/12/10/sample-playing… Running it in Wine shows that Wine violates the assumption/invariant/guarantee IMHO Event signaled => there's room in the buffer -- much like winmm's MOM_DONE signals that a buffer is free. I don't know when the first event is signaled nor at what rate they are signaled. (Perhaps one is signaled every time one of the mixer's 10ms chunks is processed?). The app immediately complains and exits. Wine's mmdevapi current unconditional and periodic SetEvent does not match the above program's expectations (nor would it match exclusive mode behaviour: event => complete buffer free for writing). A periodic 10ms event may be fine when playing goes smooth, but that's not the case right at the beginning, esp. when filling the buffer before calling Start. I should turn that into a distinct bug report. Regards, Jörg Höhle

June 8, 2011