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

Re: Wine users with a CD-ROM drive, please test

by Erik Inge Bolsø

No failures on my winxp laptop. No mixed cd handy, so only audio cd tested. mcicda.c:270: CD length 73:35:54 mcicda.c:325: track #1 length 35694ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:25s:41frames mcicda.c:418: last track position: 69m:12s:13frames mcicda: 102 tests executed (0 marked as todo, 0 failures), 1 skipped. -- -erik http://useofwords.blogspot.com/

Aug. 6, 2010

Re: user32: Don't crash for unknown button styles

by Nikolay Sivov

On 8/6/2010 22:22, André Hentschel wrote: > got that case with an MFC application which had a 3state radiobutton with buttonstyle 15(decimal) > with this fix everything is fine as the painting of the button is handled elsewhere, without that fix it crashes as it reads bad data behind the array. > > --- > dlls/user32/button.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/dlls/user32/button.c b/dlls/user32/button.c > index 54d54dc..4f629f0 100644 > --- a/dlls/user32/button.c > +++ b/dlls/user32/button.c > @@ -197,7 +197,7 @@ static inline UINT get_button_type( LONG window_style ) > /* paint a button of any type */ > static inline void paint_button( HWND hwnd, LONG style, UINT action ) > { > - if (btnPaintFunc[style]&& IsWindowVisible(hwnd)) > + if (style<= MAX_BTN_TYPE&& btnPaintFunc[style]&& IsWindowVisible(hwnd)) > { > HDC hdc = GetDC( hwnd ); > btnPaintFunc[style]( hwnd, hdc, action ); This needs a test to see what happens visually for style 0xf, maybe we need just to duplicate an entry in paint function table; also while you're at it: static inline UINT get_button_type( LONG window_style ) { return (window_style & 0x0f); } here BS_TYPEMASK should be used instead of 0xf.

Aug. 6, 2010

Re: [PATCH 1/6] d3dx9_36/tests: Added HLSL test suite.

by Henri Verbeet

On 5 August 2010 00:05, Travis Athougies <iammisc(a)gmail.com> wrote: > +#define CINTERFACE Why do you need this? > +#include <d3d9.h> d3d9.h should be implied by d3dx9.h > +#include <assert.h> > +#include <stdio.h> I don't think you need these either. > +struct vertex > +{ > + float x, y, z; > + float tx, ty; > +}; > + > +const struct vertex quad_vertices[4] = { > + {-1, -1, 0, 0, 1}, > + {-1, 1, 0, 0, 0}, > + {1, -1, 0, 1, 1}, > + {1, 1, 0, 1, 0} > +}; Those aren't floating point values. Also, please use consistent formatting. > +const struct vertex quad_vertices[4] = { ... > +static IDirect3DVertexBuffer9 *quad_geometry; > +static IDirect3DVertexShader9 *vshader_passthru; > +static IDirect3DVertexDeclaration9 *vdeclaration; > +static IDirect3DDevice9 *device; Why is all of that global? > + hres = IDirect3D9_CreateDevice(d3d9_ptr, D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, NULL, D3DCREATE_HARDWARE_VERTEXPROCESSING, &present_parameters, &device_ptr); Please break long lines. I realize this particular one is probably somehow my fault because I added it back in 2005 with c26ad82e75e408c302c21228ef08c1af0482326c, and everyone has been (blindly) copying it since, but there are other examples like setup_device() as well. Use 120 as maximum line length, 100 to be safe. > + hres = IDirect3DVertexBuffer9_Lock(quad_geometry, 0, sizeof(quad_vertices), (void**)&temp_geometry_vertices, 0); You don't need that cast. > + hres = D3DXCompileShader(vshader_passthru_hlsl, strlen(vshader_passthru_hlsl), > + NULL, NULL, "vshader", "vs_1_1", 0, > + &compiled, &errors, 0); > + if(FAILED(hres)) > + { > + vshader_passthru = NULL; That doesn't make sense, vshader_passthru is already NULL at that point. > + hr = D3DXCompileShader(shader, strlen(shader), > + NULL, NULL, "test", profile, > + 0, &compiled, &errors, constants); > + ok (hr == D3D_OK, "Pixel shader %s compilation failed: %s\n", shader, (char*) (errors?ID3DXBuffer_GetBufferPointer(errors):"")); This casts away const. > diff --git a/include/d3dx9shader.h b/include/d3dx9shader.h > index c8380bc..c54d27c 100644 > --- a/include/d3dx9shader.h > +++ b/include/d3dx9shader.h > @@ -296,6 +296,17 @@ HRESULT WINAPI D3DXAssembleShader(LPCSTR data, > LPD3DXBUFFER* shader, > LPD3DXBUFFER* error_messages); > > +HRESULT WINAPI D3DXCompileShader(LPCSTR src_data, > + UINT data_len, > + const D3DXMACRO* defines, > + LPD3DXINCLUDE include, > + LPCSTR function_name, > + LPCSTR profile, > + DWORD flags, > + LPD3DXBUFFER* shader, > + LPD3DXBUFFER* error_messages, > + LPD3DXCONSTANTTABLE* constant_table); > + This should be in a separate patch. The patch has some more issues, they shouldn't be hard to spot.

Aug. 6, 2010

Re: [PATCH 2/5] gameux: Add stub of IGameStatisticsMgr implementation (try 2)

by Mariusz Pluciński

W dniu 04.08.2010 20:45, Jerome Leclanche pisze: > Just resend this one, it's easier that way. > > > J. Leclanche / Adys > > > > 2010/8/3 Mariusz Pluciński<vshader(a)gmail.com>: >> W dniu 03.08.2010 13:28, Nikolay Sivov pisze: >>> >>> On 8/3/2010 13:58, Mariusz Pluciński wrote: >>>> >>>> --- >>>> dlls/gameux/Makefile.in | 1 + >>>> dlls/gameux/factory.c | 5 ++ >>>> dlls/gameux/gamestatistics.c | 153 >>>> ++++++++++++++++++++++++++++++++++++++++++ >>>> dlls/gameux/gameux_private.h | 1 + >>>> dlls/gameux/regsvr.c | 9 +++ >>>> 5 files changed, 169 insertions(+), 0 deletions(-) >>>> create mode 100644 dlls/gameux/gamestatistics.c >>>> + TRACE("(%p, %s, 0x%x, %p, %p)\n", iface, debugstr_w(GDFBinaryPath), >>>> openType, pOpenResult, ppiStats); >>>> + FIXME("stub\n"); >>>> + return E_NOTIMPL; >>> >>> No need for duplicated traces, add one FIXME with full parameter output >>> in it. >>> >> I hope my patches are acceptable despite of this. But in the future I'll >> avoid it, thanks. >> >> >> > You may be right. I'll do it, thanks.

Aug. 6, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/06/2010 05:44 AM, Francois Gouget wrote: > On Thu, 5 Aug 2010, Max TenEyck Woodbury wrote: > [...] >>> Here's roughly what I have in mind: >>> >>> 1. Win32 API >>> 1. Overview >>> 2. acledit API >>> 1. Overview >>> 2. Functions >>> 1. Func1 >>> 2. Func2 >>> ... >>> 3. Interfaces >>> 1. Interface 1 >>> 1. Method1 >>> 2. Method2 >>> ... >>> 2. Interface 2 >>> 1. Method1 >>> 2. Method2 >>> ... >>> 4. Datastructures >>> 1. Struct1 >>> 2. Struct2 >>> 3. Enum1 >>> ... >>> 3. aclui API >>> ... >>> 2. Standard Windows tools >>> 1. attrib command line options >>> 2. cacls command line options >>> ... >>> 3. General platform-specific notes >>> 1. Windows 9x >>> Talks about interaction with DOS, etc. >>> 2. Windows 95 >>> More Win 9x specific general notes >>> 3. Windows NT and greater >>> Kernel stuff >>> 4. Wine >>> 1. Wine architecture documentation >>> 2. Wine-specific dlls >>> 3. Wine-specific tools like winebuild, winemenubuilder, etc) >>> 5. Mingw >>> Stuff about Mingw, etc. >>> 6. ReactOS >>> Stuff about ReactOS, etc. >>> >> Ah! That is where the misunderstanding is. You are thinking of this as >> a *document*, a single coherent document. > > I am not thinking of this as a single document. Each of the above line > would be a separate wiki page. > > [...] >> Those names are what the scripts maintain. > > I'm not sure what there is to maintain. > I think we are almost in agreement. The problem is the numbers. The numbers *will* change as things evolve. Hopefully, the basic reference *names* will be fairly stable. There will also be indexes from different points of view and the indexes will have sub-pages that redirect to the appropriate basic page. Maintenance will consist of keeping those redirects up-do-date. >> The pages will also contain sub-pages. Those sub-pages are where the >> user-editable content are stored. > > Do you mean that the documentation for an API like CreateFile() would be > a collection of pages? That seems counterproductive to me. > >> There is also technical content. Such things as the names of the entry >> points, the return type, the number of parameters and their types. >> That information really should not be subject to debate. It is >> determined by the implementation. > > Well, yes. That's what Func1, Func2 are above. And on their pages you > would get the signature, general documentation of the function, > description of what each parameter is for, links to the pages describing > the types of the parameters if they're complex, what the function > returns, finer points about how the function behaves in corner cases if > appropriate, and platform-specific details about how it behaves. > >> That might be something the scripts can maintain, however I will leave >> that maintenance until later. > > However while it would be easy for scripts to create a skeleton page, > once the page exists and has been editied they may have a hard time > changing stuff like correcting the type of an output parameter. > > But I guess that's why you want to have sub pages I guess. Though I > really would not want to have to go through multiple pages for each of > the documentation aspects I mentioned above. > I believe I understand your concern. From observation it is not going to actually be a problem. The sub-pages are 'transcluded' into the base page. The sub-pages will contain the section headings and when you edit the section, you in fact edit the sub-page. There is a problem that you end up on the sub-page when you finish editing. I'll add a link back to the main article page, and that should make the problem smaller. >> I suspect that the meta-information will in fact have to be duplicated. >> It can be different for the different projects. For example Wine is >> similar to the Microsoft stuff at the file level. They each have DLLs >> with corresponding names. On the other hand, WinGW consists of a single >> DLL, if I understand its structure correctly. > > My mingw-runtime package has a lot of separate 'dlls': libaclui.a, > libadvapi32.a, libgdi32.a, etc. Besides, how does that matter? > CreateFile() is a kernel32 fnuction, no matter what, and the > documentation should reflect that. > OK, but they are called 'aclui' in the Wine repository, not 'libaclui.a'. I think each project will want to maintain seperate meta-structure sub-pages so we do not change something about another project's meta structure when we update our own meta-structure. >> There is complication here no matter how it is done. There is simply >> too much stuff to keep it really simple. Category markers should be >> used extensively. Redirection links will be needed to provide views >> from different perspectives without having to actually replicate >> articles. > > That's one of the things I don't like in msdn. Want do know what's the > API provided by a given dll? Good luck with that because they seem bent > on hiding that kind of information. > > I think we should really have per-dll documentation and the general > articles about 'how to do sound', 'what COM is' should be in a separate > section. Otherwise your documentation of CoCreateInstance() is going to > keep moving from OLE to COM to DCOM and to whatever today's fashionable > marketing term is. > Yes, that is along the lines I planned on. The 'how to's would not be 'managed', but there would be indexes and redirects for each 'API' to the place where the documentation is. In particular, there should be a 'Category:API' sorted alphabetically with links to the correct page. If a 'how to' wants to link to a particular API, it would link to the sub-page of the API index and that would redirect to the actual page. This does require planning and I am glad it is being discussed now, before things become too embedded to change. - Max

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Matijn Woudt

Test results from Windows 7 x64: I tried with original audio CD, and a burned copy, mcicda_test.exe and mcicda_test64.exe, and they all give: mcicda.c:270: CD length 46:20:53 mcicda.c:325: track #1 length 118107ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:15s:37frames mcicda.c:418: last track position: 42m:07s:16frames mcicda.c:425: Test failed: SEEK to 0035162E position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. > David c/o paulo lesgaz wrote: >>mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE >>mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE > Same as Jeff, please see if one of you can identify which prior MCI command causes this. Do you have any instructions how I can identify this?

Aug. 6, 2010

Wine users with a CD-ROM drive, please test

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

Hi, David c/o paulo lesgaz wrote: >mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE >mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE Same as Jeff, please see if one of you can identify which prior MCI command causes this. >mcicda.c:275: Test failed: status position initially 00:02:33 >mcicda.c:280: Test failed: status position start 00:02:33 Interesting, thank you. Will change the tests. I once read there must be a 2 second gap but it seems it need not be exactly 2 seconds. Greg Geldorp wrote: >I can attach a .iso to each VM and run your tests. Would that help? AFAIK, a .iso contains a data CD only, not music tracks. If that's right, then it would not be very interesting, as data-only CDs are already skipped. >Keep in mind that almost none of the VMs have sound support. Thanks for reminding me to temporarily disable sound on a native system and see how that changes test results. From what I remember, disabling sound in the preferences (XP then wants to reboot) achieved the same results as sound-less machines in the MCI tests. Regards, Jörg Höhle

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Greg Geldorp

> From: <Joerg-Cyril.Hoehle(a)t-systems.com> > > this is my second call for participation, as only Jeff Zaroyko responded to the first one. > > I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). > Wine's testbot job #4330 at > https://testbot.winehq.org/JobDetails.pl?Key=4330 > contains both a patch and binary of what I'd initially want to test about mcida.dll, > solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. I can attach a .iso to each VM and run your tests. Would that help? Keep in mind that almost none of the VMs have sound support. Ge.

Aug. 6, 2010

Re : Wine users with a CD-ROM drive, please test

by paulo lesgaz

Here is my result on a real Vista box using the CD: Police -Greatest hits mcicda.c:270: CD length 67:55:74 mcicda.c:275: Test failed: status position initially 00:02:33 mcicda.c:280: Test failed: status position start 00:02:33 mcicda.c:314: Test failed: status position initially 2441ms mcicda.c:325: track #1 length 192667ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:12s:27frames mcicda.c:418: last track position: 63m:46s:05frames mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 5 failures), 2 skipped. David ________________________________ De : "Joerg-Cyril.Hoehle(a)t-systems.com" <Joerg-Cyril.Hoehle(a)t-systems.com> À : wine-devel(a)winehq.org Envoyé le : Ven 6 août 2010, 11h 24min 55s Objet : Wine users with a CD-ROM drive, please test Hi, this is my second call for participation, as only Jeff Zaroyko responded to the first one. I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). Wine's testbot job #4330 at https://testbot.winehq.org/JobDetails.pl?Key=4330 contains both a patch and binary of what I'd initially want to test about mcida.dll, solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. Please download the executable or compile the patch and execute it in MS-Windows: mcicda_test.exe mcicda mcicda.c:270: CD length 69:23:66 mcicda.c:325: track #1 length 989547ms mcicda.c:375: track #1 length: 16m:29s:41frames mcicda.c:410: last track length: 03m:28s:19frames mcicda.c:418: last track position: 65m:57s:47frames mcicda: 112 tests executed (0 marked as todo, 0 failures), 0 skipped. BTW, I wrote patches to make all these tests succeed in Wine. Before submission, I'd appreciate some more test data. Thank you for your participation, Jörg Höhle

Aug. 6, 2010

Wine users with a CD-ROM drive, please test

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

Jeff Zaroyko wrote: >Blank CD: >mcicda.c:252: Test failed: info upc: MCIERR_HARDWARE >mcicda.c:255: Test failed: info identity: MCIERR_HARDWARE >mcicda.c:263: Test failed: STATUS number of tracks: MCIERR_HARDWARE >mcicda.c:266: Test failed: number of tracks=0 I'll select an appropriate test based on Linux (and MacOS) results in Wine and add a skip. >mcicda.c:425: Test failed: SEEK to 003B0436 position last + length: MCIERR_HARDWARE >mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE I believe both errors have the same origin. Here you really need to find out what command in the testsuite causes the seek&play tests to fail with MCIERR_HARDWARE since you said you could play music using MCI commands typed into the shell. Why can't the testsuite? Luckily, almost all mciSendCommand can be converted to an equivalent string form. Sadly, I have no clue what command may influence this -- perhaps MCI_RESUME? >It's composed of two "sessions" That'll make for an interesting testcase once we get rid of the above MCIERR_HARDWARE issue. Thank you again, Jörg Höhle

Aug. 6, 2010

Re: Wine users with a CD-ROM drive, please test

by Jeff Zaroyko

On Fri, Aug 6, 2010 at 7:24 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > this is my second call for participation, as only Jeff Zaroyko responded to the first one. > > I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). > Wine's testbot job #4330 at > https://testbot.winehq.org/JobDetails.pl?Key=4330 > contains both a patch and binary of what I'd initially want to test about mcida.dll, > solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. > > Please download the executable or compile the patch and execute it in MS-Windows: Take #2. I had a look at the CD I claimed was data+audio with a CDBurnerXP. It's composed of two "sessions" one with audio tracks and the second session is composed of only a data track. C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:270: CD length 54:02:59 mcicda.c:325: track #1 length 76134ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:37s:09frames mcicda.c:418: last track position: 49m:27s:50frames mcicda.c:425: Test failed: SEEK to 003B0436 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. For comparison, I checked Jedi Knight: Dark Forces II CD1, it is shown to have one session with a data track followed by audio tracks: C:\Users\jeffz\Desktop>wintest.exe mcishell mci.c:178: Type your commands to the MCI, end with Ctrl-Z/^D open cdaudio alias c mci.c:188: command: open cdaudio alias c mci.c:193: Response: 1 status c type track 1 mci.c:188: command: status c type track 1 mci.c:193: Response: other status c type track 2 mci.c:188: command: status c type track 2 mci.c:193: Response: audio C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:270: CD length 69:42:40 mcicda.c:325: track #1 length 3022801ms mcicda.c:375: track #1 length: 50m:22s:60frames mcicda.c:410: last track length: 02m:10s:50frames mcicda.c:418: last track position: 67m:33s:65frames mcicda.c:425: Test failed: SEEK to 00282C45 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 8 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 8. mcicda: 74 tests executed (0 marked as todo, 2 failures), 1 skipped. And for the same cd as used earlier with only audio: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:270: CD length 24:53:74 mcicda.c:325: track #1 length 252067ms mcicda.c:392: Tests skipped: Got no mixed data+audio CD. mcicda.c:410: last track length: 04m:54s:52frames mcicda.c:418: last track position: 20m:01s:22frames mcicda.c:425: Test failed: SEEK to 004A3718 position last + length: MCIERR_HARDWARE mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:439: Tests skipped: Cannot manage to play track 1. mcicda: 64 tests executed (0 marked as todo, 2 failures), 2 skipped. Blank CD: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:252: Test failed: info upc: MCIERR_HARDWARE mcicda.c:255: Test failed: info identity: MCIERR_HARDWARE mcicda.c:263: Test failed: STATUS number of tracks: MCIERR_HARDWARE mcicda.c:266: Test failed: number of tracks=0 mcicda.c:269: Test failed: status length: MCIERR_HARDWARE mcicda.c:274: Test failed: status position: MCIERR_HARDWARE mcicda.c:279: Test failed: status position start: MCIERR_HARDWARE mcicda.c:288: Test failed: play 02 to 01: MCIERR_HARDWARE mcicda.c:295: Test failed: seek to noflag: MCIERR_HARDWARE mcicda.c:298: Test failed: seek to start+end: MCIERR_HARDWARE mcicda.c:302: Test failed: seek to start: MCIERR_HARDWARE mcicda.c:313: Test failed: status position start (ms): MCIERR_HARDWAR mcicda.c:323: Test failed: status length (ms): MCIERR_HARDWARE mcicda.c:339: Test failed: STATUS type track 1: MCIERR_HARDWARE mcicda.c:340: Test failed: unknown track type feedabad mcicda.c:397: Tests skipped: Found no audio track. mcicda: 53 tests executed (0 marked as todo, 15 failures), 1 skipped. A DVD: C:\Users\jeffz\Desktop>mcicda_test.exe mcicda.c:229: Tests skipped: CD-ROM mode not ready mcicda: 21 tests executed (0 marked as todo, 0 failures), 1 skipped Jeff

Aug. 6, 2010

Re: The WineAPI wiki.

by Francois Gouget

On Thu, 5 Aug 2010, Max TenEyck Woodbury wrote: [...] > > Here's roughly what I have in mind: > > > > 1. Win32 API > > 1. Overview > > 2. acledit API > > 1. Overview > > 2. Functions > > 1. Func1 > > 2. Func2 > > ... > > 3. Interfaces > > 1. Interface 1 > > 1. Method1 > > 2. Method2 > > ... > > 2. Interface 2 > > 1. Method1 > > 2. Method2 > > ... > > 4. Datastructures > > 1. Struct1 > > 2. Struct2 > > 3. Enum1 > > ... > > 3. aclui API > > ... > > 2. Standard Windows tools > > 1. attrib command line options > > 2. cacls command line options > > ... > > 3. General platform-specific notes > > 1. Windows 9x > > Talks about interaction with DOS, etc. > > 2. Windows 95 > > More Win 9x specific general notes > > 3. Windows NT and greater > > Kernel stuff > > 4. Wine > > 1. Wine architecture documentation > > 2. Wine-specific dlls > > 3. Wine-specific tools like winebuild, winemenubuilder, etc) > > 5. Mingw > > Stuff about Mingw, etc. > > 6. ReactOS > > Stuff about ReactOS, etc. > > > Ah! That is where the misunderstanding is. You are thinking of this as > a *document*, a single coherent document. I am not thinking of this as a single document. Each of the above line would be a separate wiki page. [...] > Those names are what the scripts maintain. I'm not sure what there is to maintain. > The pages will also contain sub-pages. Those sub-pages are where the > user-editable content are stored. Do you mean that the documentation for an API like CreateFile() would be a collection of pages? That seems counterproductive to me. > There is also technical content. Such things as the names of the entry > points, the return type, the number of parameters and their types. > That information really should not be subject to debate. It is > determined by the implementation. Well, yes. That's what Func1, Func2 are above. And on their pages you would get the signature, general documentation of the function, description of what each parameter is for, links to the pages describing the types of the parameters if they're complex, what the function returns, finer points about how the function behaves in corner cases if appropriate, and platform-specific details about how it behaves. > That might be something the scripts can maintain, however I will leave > that maintenance until later. However while it would be easy for scripts to create a skeleton page, once the page exists and has been editied they may have a hard time changing stuff like correcting the type of an output parameter. But I guess that's why you want to have sub pages I guess. Though I really would not want to have to go through multiple pages for each of the documentation aspects I mentioned above. > I suspect that the meta-information will in fact have to be duplicated. > It can be different for the different projects. For example Wine is > similar to the Microsoft stuff at the file level. They each have DLLs > with corresponding names. On the other hand, WinGW consists of a single > DLL, if I understand its structure correctly. My mingw-runtime package has a lot of separate 'dlls': libaclui.a, libadvapi32.a, libgdi32.a, etc. Besides, how does that matter? CreateFile() is a kernel32 fnuction, no matter what, and the documentation should reflect that. [...] > There is complication here no matter how it is done. There is simply > too much stuff to keep it really simple. Category markers should be > used extensively. Redirection links will be needed to provide views > from different perspectives without having to actually replicate > articles. That's one of the things I don't like in msdn. Want do know what's the API provided by a given dll? Good luck with that because they seem bent on hiding that kind of information. I think we should really have per-dll documentation and the general articles about 'how to do sound', 'what COM is' should be in a separate section. Otherwise your documentation of CoCreateInstance() is going to keep moving from OLE to COM to DCOM and to whatever today's fashionable marketing term is. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Aug. 6, 2010

Wine users with a CD-ROM drive, please test

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

Hi, this is my second call for participation, as only Jeff Zaroyko responded to the first one. I wrote a testsuite for mcicda (play music from CD-ROM using the MCI). Wine's testbot job #4330 at https://testbot.winehq.org/JobDetails.pl?Key=4330 contains both a patch and binary of what I'd initially want to test about mcida.dll, solely lacking compatibility fixes that testing on YOUR machine will show to be necessary. Please download the executable or compile the patch and execute it in MS-Windows: mcicda_test.exe mcicda mcicda.c:270: CD length 69:23:66 mcicda.c:325: track #1 length 989547ms mcicda.c:375: track #1 length: 16m:29s:41frames mcicda.c:410: last track length: 03m:28s:19frames mcicda.c:418: last track position: 65m:57s:47frames mcicda: 112 tests executed (0 marked as todo, 0 failures), 0 skipped. BTW, I wrote patches to make all these tests succeed in Wine. Before submission, I'd appreciate some more test data. Thank you for your participation, Jörg Höhle

Aug. 6, 2010

Re: wiki slightly broken still?

by Damjan Jovanovic

On Tue, Aug 3, 2010 at 4:18 PM, David Gerard <dgerard(a)gmail.com> wrote: > [to list as well] > > On 3 August 2010 15:07, Dimi Paun <dimi(a)lattica.com> wrote: >> On Tue, 2010-08-03 at 14:30 +0200, Alexandru Băluț wrote: > >>> How difficult would it be to use ReCaptcha? >>> http://www.google.com/recaptcha > >> Hm, don't know. We could hack our version to support recaptcha, >> but I'm not familiar with the code base, and I don't have the >> time right now. But I can take patches if someone is willing >> to do it. > > > The MoinMoin developers consider TextCHA inherently superior and so > have no interest in writing a reCaptcha interface: > > http://moinmo.in/FeatureRequests/ReCaptcha > > (Note also the problems people have had with TextCHA: it becomes too > much work to write the questions and to answer the questions.) > > If someone wants reCaptcha in MoinMoin, it appears they will need to > write it all themselves. > > > - d. > > > reCaptcha has essentially been cracked now (http://it.slashdot.org/story/10/08/05/2054247/ReCAPTCHAnet-Now-Vulnerable-t…) so I'm not sure it's worth using it in the wiki. Damjan Jovanovic

Aug. 6, 2010

Re: CD-ROM ioctl support on MacOS?

by Charles Davis

On 8/5/10 9:16 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > Hi, > > what's the state of CD-ROM support on the Mac? > ntdll/cdrom.c contains quite a few #ifdef apple. I was the last one to hack on that, so I'll bite. > > I'm asking because the mcicda currently uses these ioctl: > 1. READ_RAW That's implemented. I implemented it myself in 6368dbbd5939bf71b04f3c441dd3af8cd027b7fb. > 2. READ_TOC AJ implemented that in e6ce0da2f99cc8c249a453489b9b199bec1fe435. > 3. READ_Q -> POSITION That might never be implemented. Like I said earlier, the IOCDAudioControl user client was removed in Mac OS X 10.4. I might be able to implement this using a direct SCSI call, though. Come to think of it, I might also be able to extend my experimental BSD client to support this. > > MCICDA could be changed to avoid the third one entirely > -- when using the dsound output. Would that > be enough to use mcicda on MacOS to play music? That might work. > > Thanks for your help, No problem. Chip

Aug. 5, 2010

Re: The WineAPI wiki.

by Max TenEyck Woodbury

On 08/05/2010 03:56 AM, Francois Gouget wrote: > On Wed, 4 Aug 2010, Max TenEyck Woodbury wrote: > [...] >> There several things that have to be coordinated however: >> >> - This is not just the API documentation. It includes a great deal of >> information about the meta-structure of the Wine project. Easy access >> to that meta-information might be one of the more useful aspects of >> this sub-project. > > I suspect some of that information is already present in the Wine > Developer's Guide, in particular the section 'II. Wine Architecture': > > http://www.winehq.org/docs/winedev-guide/index > > So there is the issue of where to put this information: in the developer > guide, in the win32 api wiki or in a separate wiki. Even if it's in the > win32 api wiki I think it could be set slightly apart. > > Here's roughly what I have in mind: > > 1. Win32 API > 1. Overview > 2. acledit API > 1. Overview > 2. Functions > 1. Func1 > 2. Func2 > ... > 3. Interfaces > 1. Interface 1 > 1. Method1 > 2. Method2 > ... > 2. Interface 2 > 1. Method1 > 2. Method2 > ... > 4. Datastructures > 1. Struct1 > 2. Struct2 > 3. Enum1 > ... > 3. aclui API > ... > 2. Standard Windows tools > 1. attrib command line options > 2. cacls command line options > ... > 3. General platform-specific notes > 1. Windows 9x > Talks about interaction with DOS, etc. > 2. Windows 95 > More Win 9x specific general notes > 3. Windows NT and greater > Kernel stuff > 4. Wine > 1. Wine architecture documentation > 2. Wine-specific dlls > 3. Wine-specific tools like winebuild, winemenubuilder, etc) > 5. Mingw > Stuff about Mingw, etc. > 6. ReactOS > Stuff about ReactOS, etc. > Ah! That is where the misunderstanding is. You are thinking of this as a *document*, a single coherent document. That is not quite what this is. It is a collection of *pages*. Each page has a distinct name. Those names are what the scripts maintain. The pages will also contain sub-pages. Those sub-pages are where the user-editable content are stored. Once those sub-pages are created, the scripts will not touch them. (That answers the question in my original post by the way.) There is also technical content. Such things as the names of the entry points, the return type, the number of parameters and their types. That information really should not be subject to debate. It is determined by the implementation. That might be something the scripts can maintain, however I will leave that maintenance until later. >> - The detailed information is, at least initially, coming out of the >> Wine code. It is being generated using scripts. The scripts are very >> likely to be rerun when a file in the Wine repository changes. It may >> take a lot of effort to merge the new information with information >> from other sources. > > No matter what, if such a wiki is meant to be edited directly you won't > be able to merge in data through scripts very long. It will soon have to > stand on its own. > You had better be wrong on this particular point. If you are in fact correct, it will be impossible to keep the technical information and structural information intact. I believe the descriptive and technical information can be put on seperate pages and sub-pages. The project is still in the planning and experimental phase. The details are in the process of being worked out. >> - If the licenses are compatible, it should be possible to copy >> articles between projects. > > Yes, licensing is an important issue and one you must solve before > accepting outside contributions. > > To incorportate data from the Wine source it must be LGPL-compatible > (e.g. GPL). To incorporate data from the Mingw or ReactOS source it must > be compatible with their license (GPL?). > > Even if copying articles from one project to another is technically > legal, I think you cannot count on this as a means to avoid massive > duplication of effort: as soon as you have over a hundred articles (once > fully sutbbed out you should have way over 30000) the work involved for > watching changes on each side and merging duplicate documentation will > be overwhelming (and I suspect finding volunteers for it will be hard > too). > Whether the information comes out of the Wine code or other code, there could be problems. But that is not where most of the value of this project will lie. It will be in the descriptive information that does not come out of the code. It will be the material the individual contributers add. I suspect that the meta-information will in fact have to be duplicated. It can be different for the different projects. For example Wine is similar to the Microsoft stuff at the file level. They each have DLLs with corresponding names. On the other hand, WinGW consists of a single DLL, if I understand its structure correctly. But building up the meta-structure is much less difficult than creating the descriptions. I hope the descriptive information can be shared. >> Also, the page tree structure is based on >> the structure of the Wine repository. > > The wiki should have its own structure, independent from Wine and > anything else. I would also argue that the simpler it is, the less > likely it is to change. > There is complication here no matter how it is done. There is simply too much stuff to keep it really simple. Category markers should be used extensively. Redirection links will be needed to provide views from different perspectives without having to actually replicate articles. The one thing that should not be done is impose a single person's opinion of how it must be done on everybody else. On the other hand, someone has to start this thing. - Max

Aug. 5, 2010

Re: Please report mcicda (CDROM audio) test results

by Robert Kim Wireless Internet Advisor

Guys... I just started looking into developing for the ipad... am i going to have the same issues? I know, i know.. i'm a newbie with objective c. lemme know... On Thu, Aug 5, 2010 at 8:14 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Jeff, > >>if I: >>> resume c # yields MCIERR_HARDWARE >>nothing printed > This is not compatible with the test that does not report failure on your system: > + err = mciSendString("resume c", buf, sizeof(buf), hwnd); > + ok(err == MCIERR_HARDWARE, "resume without play: %s\n", dbg_mcierr(err)); /* not NONAPPLICABLE_FUNCTION */ > Does any of the previous commands provoke this difference? > >>> play from <1_or_last_track> notify > Oops > play c from 1 notify > play c from 1 to 2 > play c to 12 > play c from 12 > >>It stopped accepting input, any letters, return were all blocked - >>nothing except ^C. > Works for me. > >>Every track is listed as audio, meanwhile I see the drive with >>included programs etc is mapped in explorer. > This is behaviour unseen on the w95, w2k and wxp machines > that I had access to, with my mixed data+audio CD. > > Your machine's behaviour is mystery to me. Is mcicdda that unreliable??? > > Regards, > Jörg Höhle > > -- Robert Q Kim 2611 S Coast Highway San Diego, CA 92007 310 598 1606 My Latest Blog Post: http://sparkah.com/2010/07/29/experienced-iphone-app-developer-los-angeles-…

Aug. 5, 2010

CD-ROM ioctl support on MacOS?

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

Hi, what's the state of CD-ROM support on the Mac? ntdll/cdrom.c contains quite a few #ifdef apple. I'm asking because the mcicda currently uses these ioctl: 1. READ_RAW 2. READ_TOC 3. READ_Q -> POSITION MCICDA could be changed to avoid the third one entirely -- when using the dsound output. Would that be enough to use mcicda on MacOS to play music? Thanks for your help, Jörg Höhle

Aug. 5, 2010

Please report mcicda (CDROM audio) test results

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

Jeff, >if I: >> resume c # yields MCIERR_HARDWARE >nothing printed This is not compatible with the test that does not report failure on your system: + err = mciSendString("resume c", buf, sizeof(buf), hwnd); + ok(err == MCIERR_HARDWARE, "resume without play: %s\n", dbg_mcierr(err)); /* not NONAPPLICABLE_FUNCTION */ Does any of the previous commands provoke this difference? >> play from <1_or_last_track> notify Oops play c from 1 notify play c from 1 to 2 play c to 12 play c from 12 >It stopped accepting input, any letters, return were all blocked - >nothing except ^C. Works for me. >Every track is listed as audio, meanwhile I see the drive with >included programs etc is mapped in explorer. This is behaviour unseen on the w95, w2k and wxp machines that I had access to, with my mixed data+audio CD. Your machine's behaviour is mystery to me. Is mcicdda that unreliable??? Regards, Jörg Höhle

Aug. 5, 2010

Re: Please report mcicda (CDROM audio) test results

by Jeff Zaroyko

On Thu, Aug 5, 2010 at 11:51 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > >> Things you can try out using the interactive MCI shell: >> open cdaudio alias c >> status c type track 1 >> set c time format tmsf >> seek c to start >> play c from 1 to 2 wait >>This works - I hear music. > What the test does is not fundamentally different. I'd > appreciate if you could isolate the part that causes havoc. > if I: open cdaudio alias c status c type track 1 # Response: audio (the same for tracks 1-12, 13 is out of range - only 12 tracks on cd) seek c to start > status c position mci.c:188: command: status c position mci.c:193: Response: 00:02:00 > resume c # yields MCIERR_HARDWARE nothing printed > seek c to start notify mci.c:188: command: seek c to start notify mci.c:167: Notification type 0001 > status c type track 1 mci.c:188: command: status c type track 1 mci.c:193: Response: audio > set c time format tmsf no response > play from <1_or_last_track> notify play from 1 notify mci.c:188: command: play from 1 notify mci.c:191: Test failed: mci play from 1 notify error: 300(44 MCIERR_NOTIFY_ON_AUTO_OPEN) > >> waiting a minute, it hasn't returned to accepting input >>here, so I've ^C. > Really? Wait never failed on me. > Did you perhaps get confused because no prompt ever > appears? Just hit return to get MCIERR_MISSING_COMMAND_STRING. It stopped accepting input, any letters, return were all blocked - nothing except ^C. I tested it again, same thing happened. > >>The data+audio cd as previously used: >>mcicda.c:372: Tests skipped: Got no mixed data+audio CD. > The source code led me to believe that data tracks always come > first. Perhaps that's a broken assumption. What's the response to: > status c type track 1 > status c type track 2 > status c type track ... until the last one? > I'd expect > Other [typically 1 single data track] > Audio [for track 2..n] Every track is listed as audio, meanwhile I see the drive with included programs etc is mapped in explorer. > Thank you, > Jörg.

Aug. 5, 2010

Please report mcicda (CDROM audio) test results

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

Hi, > Things you can try out using the interactive MCI shell: > open cdaudio alias c > status c type track 1 > set c time format tmsf > seek c to start > play c from 1 to 2 wait >This works - I hear music. What the test does is not fundamentally different. I'd appreciate if you could isolate the part that causes havoc. status c position resume c # yields MCIERR_HARDWARE seek c to start notify status c type track 1 set c time format tmsf play from <1_or_last_track> notify > waiting a minute, it hasn't returned to accepting input >here, so I've ^C. Really? Wait never failed on me. Did you perhaps get confused because no prompt ever appears? Just hit return to get MCIERR_MISSING_COMMAND_STRING. >The data+audio cd as previously used: >mcicda.c:372: Tests skipped: Got no mixed data+audio CD. The source code led me to believe that data tracks always come first. Perhaps that's a broken assumption. What's the response to: status c type track 1 status c type track 2 status c type track ... until the last one? I'd expect Other [typically 1 single data track] Audio [for track 2..n] Thank you, Jörg.

Aug. 5, 2010

Re: [PATCH 5/6] d3dx9_36/tests: Added trigonometric functions test to HLSL test suite

by Octavian Voicu

On Thu, Aug 5, 2010 at 3:58 PM, Joris Huizer <joris_huizer(a)yahoo.com> wrote: > In this patch, you have this code: > > + void *ret = NULL; > //... > + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); > + for(i = 0;i < 32;i++) { > //... > + memcpy((void*) (((DWORD) ret) + (4 * i)), lr.pBits, 4); > //... > + } > > I'm not sure, but I think this will cause 64-bit issues (truncating to a 32-bit value?) > Even if it doesn't, it seems simpler (more readable) to use a char pointer instead of a void pointer, like > > + char *ret; > //... > + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); > //... > + memcpy(ret + (4 * i), lr.pBits, 4); Or just use a DWORD pointer: + DWORD *ret; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); + for(i = 0;i < 32;i++) { //... + ret[i] = lr.pBits; //... + }

Aug. 5, 2010

[PATCH 5/6] d3dx9_36/tests: Added trigonometric functions test to HLSL test suite

by Joris Huizer

Hello Travis Athougies, In this patch, you have this code: + void *ret = NULL; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); + for(i = 0;i < 32;i++) { //... + memcpy((void*) (((DWORD) ret) + (4 * i)), lr.pBits, 4); //... + } I'm not sure, but I think this will cause 64-bit issues (truncating to a 32-bit value?) Even if it doesn't, it seems simpler (more readable) to use a char pointer instead of a void pointer, like + char *ret; //... + ret = HeapAlloc(GetProcessHeap(), 0, 4 * samples); //... + memcpy(ret + (4 * i), lr.pBits, 4); HTH, regards, Joris

Aug. 5, 2010

Re: Please report mcicda (CDROM audio) test results

by Jeff Zaroyko

On Thu, Aug 5, 2010 at 6:39 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> > Hi, > > Jeff Zaroyko wrote: >>mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >>mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. > > All failures are explained by your drive's inability to play any piece > of music from the CD in your system. PLAY fails, causing other tests to fail. > Why you'll have to investigate. > Did that machine ever play music from an audio CD? Yes, VLC plays from an audio CD without issue, in addition it also works with Jedi Knight: Dark Forces II demo, which plays cd music (despite there being no audio cd for the demo). > An updated patch with one new bug is at > https://testbot.winehq.org/JobDetails.pl?Key=4314 > mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION > I've added a skip when PLAY returns an error. > Native MCICDA does not perform a lot of error checking, e.g. > "status c current track" returns 1 when there's no disk in drive. The data+audio cd as previously used: mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION mcicda.c:243: Test failed: info 2flags: 0=NOERROR mcicda.c:307: track #1 length 76134ms mcicda.c:372: Tests skipped: Got no mixed data+audio CD. mcicda.c:389: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:392: Tests skipped: Cannot manage to play track 1. mcicda: 57 tests executed (0 marked as todo, 3 failures), 2 skipped. The same audio cd as used previously which has audio only: mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION mcicda.c:243: Test failed: info 2flags: 0=NOERROR mcicda.c:307: track #1 length 252067ms mcicda.c:372: Tests skipped: Got no mixed data+audio CD. mcicda.c:389: Test failed: PLAY from 1 notify: MCIERR_HARDWARE mcicda.c:392: Tests skipped: Cannot manage to play track 1. mcicda: 57 tests executed (0 marked as todo, 3 failures), 2 skipped. Indeed, the tests don't produce any audio. > Things you can try out using the interactive MCI shell: > open cdaudio alias c > status c type track 1 > set c time format tmsf > seek c to start > play c from 1 to 2 wait This works - I hear music. After playing the first track to completion and waiting a minute, it hasn't returned to accepting input here, so I've ^C. > play c from 10 to 11 wait > seek c to 3 > play c > close c > That's not unlike how apps use mcicda. > > Regards, > Jörg.

Aug. 5, 2010

Please report mcicda (CDROM audio) test results

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

Hi, Jeff Zaroyko wrote: >mcicda.c:355: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >mcicda: 90 tests executed (0 marked as todo, 14 failures), 0 skipped. All failures are explained by your drive's inability to play any piece of music from the CD in your system. PLAY fails, causing other tests to fail. Why you'll have to investigate. Did that machine ever play music from an audio CD? An updated patch with one new bug is at https://testbot.winehq.org/JobDetails.pl?Key=4314 mcicda.c:181: Test failed: GETDEVCAPS 4001: MCIERR_UNSUPPORTED_FUNCTION I've added a skip when PLAY returns an error. Native MCICDA does not perform a lot of error checking, e.g. "status c current track" returns 1 when there's no disk in drive. Things you can try out using the interactive MCI shell: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait play c from 10 to 11 wait seek c to 3 play c close c That's not unlike how apps use mcicda. Regards, Jörg.

Aug. 5, 2010