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

HEAP and FarCry installer

by wylda＠volny.cz

Hope i don't bother you much, but i guess you would tell me... I still have a problem with FarCry installer. During that i found HEAP issue - based on assumption, that message "Heap invalid in-use arena magic 00eefeee" is unhealthy. So program allocates 6fc bytes at 0x14c160 and free those bytes at the end of the following list, but immediately tries to free another heap at 14c188 which belongs to the freed area already, right?. Also there is no trace, that the program allocates that 14c188 memory. Is that bug or nothing unusual? Longer log attached. 0009:Call ntdll.RtlAllocateHeap(00110000,00000000,000006fc) ret=7dfef944 0009:Ret ntdll.RtlAllocateHeap() retval=0014c160 ret=7dfef944 0009:Call version.GetFileVersionInfoW(00157a88 L"C:\\Program Files\\Common Files\\InstallShield\\Driver\\9\\Intel 32\\IDriver.exe",00000000,000006fc,0014c160) ret=7dff45c1 ... 0009:Ret version.GetFileVersionInfoW() retval=00000001 ret=7dff45c1 0009:Call version.VerQueryValueW(0014c160,7e078b84 L"\\",0034beec,0034bee4) ret=7dff45e7 0009:Ret version.VerQueryValueW() retval=00000001 ret=7dff45e7 0009:Call ntdll.RtlFreeHeap(00110000,00000000,0014c160) ret=7dfefa1e 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=7dfefa1e 0009:Call ntdll.RtlFreeHeap(00110000,00000000,0014c188) ret=7dfefa1e warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic 00eefeee for 0x14c180 0009:Ret ntdll.RtlFreeHeap() retval=00000000 ret=7dfefa1e

Aug. 29, 2010

Re: [PATCH 4/6] winealsa.drv: Append hw address to handle to prevent name collision. (resend)

by Jeff Cook

On Tue, Aug 3, 2010 at 7:49 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >> + memcpy(ww->ds_desc.szDesc, description, >> + min( (sizeof(ww->ds_desc.szDesc) - 1), strlen(description)) >> ); > > This does not guarantee that ww->ds_desc.szDesc will be \0 terminated. > > Vitaliy. > What do you want me to do? This looks pretty safe to me and I just copied the block from elsewhere and replaced the variables. Do you want me to manually read to the end of ww->ds_desc.szDesc and replace with a \0? Sorry for the noobness. From Jeff

Aug. 29, 2010

Re: [PATCH 5/6] winealsa.drv: Don't open the same card on every loop. (resend)

by Jeff Cook

On Tue, Aug 3, 2010 at 3:57 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Jeff Cook <jeff(a)deserettechnology.com> writes: > >> @@ -753,7 +753,7 @@ static int ALSA_ScanDevices(int directhw, >> char *pcmname = NULL; >> snd_pcm_t *pcm; >> >> - sprintf(defaultpcmname, "default"); >> + sprintf(defaultpcmname, "default:%d", card); > > We used to do that, but it was changed because it's not correct, cf. bug 10942. The thing here is that default:x seems to be the only way to get a card to open compatibly with most setups. I tried opening with plughw:x, hw:x, dmix:x, and any other prefix that was suggested, but default:x was the only thing that worked with my dmix-based ALSA setup. Since dmix is on by default in ALSA, I'd venture that most normal sound setups would break otherwise too. dmix:x worked with dmix, but still behaved oddly (I don't remember exactly what it did), and I reckon that it probably wouldn't work with setups that don't use dmix. Does anyone have a suggested device-opener that is both correct according to API/docs and correct in that it actually works with at least dmix? From Jeff > > -- > Alexandre Julliard > julliard(a)winehq.org >

Aug. 29, 2010

HEAP corruption again?

by wylda＠volny.cz

Hi, i wonder what is wine trying to tell me by "just discovered" message: warn:heap:HEAP_ValidateInUseArena Heap 0x110000: invalid in-use arena magic 00555555 for 0x118c10 Is that some kind of corruption or harmless? I found out, that ARENA_INUSE_MAGIC should be 0x455355. Then ARENA_INUSE_FILLER is 0x55, so it looks to me, that wine overwrites 455355 by several 55 and then complains ;) What is it good for to put there 455355 and then intentionally overwrite(??) that by different value? W.

Aug. 28, 2010

Re: Help with 6120d7cc145, causing bugs

by Jeff Cook

Wylda reported success with the attached patch on bug 23902. Does it seem OK to everyone else? In this case, the extra channel needed for capture is not added when a micelem is found, because micelem should only be found when there is no other suitable playback or capture controls (i.e. "Mic" element only). Though I'm not sure if that's working, so the micelem detection could probably still stand for some reworking, but this seems to fix things for now. On Fri, Aug 27, 2010 at 7:51 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 27 August 2010 15:14, <wylda(a)volny.cz> wrote: >> All apps are working perfectly! Could i kindly ask you for sending >> to patches today? It looks like i will have spare time for testing, >> so it will help me to not to mess with revering. >> > It's probably not quite correct. In particular, before 6120d7cc145 > it's likely the Mic element would be counted in capcontrols as well, > and skipped for the chan count in some cases. Also, the channel count > for USB mics will probably end up as 2 now, which would make it hit > the "No channels found, skipping device!\n" path again. I think I'd > prefer the original author or Maarten to have a look at this, the code > looks somewhat complicated to me, perhaps more so than really needed. >

Aug. 28, 2010

Re: [PATCH 1/6] winealsa.drv: Init mixer on cards with a single Mic control, like snd_usb_audio mics (try 2)

by Jeff Cook

On Tue, Aug 17, 2010 at 3:00 AM, sudemon <sudemon(a)gmail.com> wrote: > On 03.08.2010 04:36, Jeff Cook wrote: >> >> What compiler are you running? It works fine for me and I don't see >> any errors or warnings. > > I also don't see any errors or warnings. > > Аfter 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 commit - my games just crash > on start without errors (windows version is win98). Found by Regression test > (16 august master VS wine-1.3.0). > > After this commands games don't crash: > $ git bisect reset > $ git show 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 | patch -p1 -R Sudemon, check out bug 23902. http://bugs.winehq.org/show_bug.cgi?id=23902 Try compiling from latest git, one of the fixes in that thread has already been committed. If that doesn't work, please try the patch located here: http://bugs2.winehq.org/attachment.cgi?id=30459 . From Jeff

Aug. 28, 2010

Re: msvcrt:string Avoid size_t in ok()

by James McKenzie

Alexandre Goujon wrote: > --- > dlls/msvcrt/tests/string.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index 94c2fa3..3c143d1 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -1185,22 +1185,22 @@ static void test_mbstowcs(void) > mOut[4] = '!'; mOut[5] = '\0'; > > ret = mbstowcs(NULL, mSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > > Alexandre: Can we avoid a typo by substituting: "Did not returned <value>\n" with "Did not return <value>\n" for each instance in the file? Thank you. James McKenzie

Aug. 28, 2010

Re: msvcrt:string Avoid size_t in ok()

by Jerome Leclanche

Not to be pedantic, but "did not return" is what you meant. J. Leclanche On Sat, Aug 28, 2010 at 2:38 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > --- > dlls/msvcrt/tests/string.c | 12 ++++++------ > 1 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/dlls/msvcrt/tests/string.c b/dlls/msvcrt/tests/string.c > index 94c2fa3..3c143d1 100644 > --- a/dlls/msvcrt/tests/string.c > +++ b/dlls/msvcrt/tests/string.c > @@ -1185,22 +1185,22 @@ static void test_mbstowcs(void) > mOut[4] = '!'; mOut[5] = '\0'; > > ret = mbstowcs(NULL, mSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > > ret = mbstowcs(wOut, mSimple, 4); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "mbstowcs did not returned 4\n"); > ok(!memcmp(wOut, wSimple, 4*sizeof(wchar_t)), "wOut = %s\n", wine_dbgstr_w(wOut)); > ok(wOut[4] == '!', "wOut[4] != \'!\'\n"); > > ret = wcstombs(NULL, wSimple, 0); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "wcstombs did not returned 4\n"); > > ret = wcstombs(mOut, wSimple, 6); > - ok(ret == 4, "ret = %d\n", ret); > + ok(ret == 4, "wcstombs did not returned 4\n"); > ok(!memcmp(mOut, mSimple, 5*sizeof(char)), "mOut = %s\n", mOut); > > ret = wcstombs(mOut, wSimple, 2); > - ok(ret == 2, "ret = %d\n", ret); > + ok(ret == 2, "wcstombs did not returned 2\n"); > ok(!memcmp(mOut, mSimple, 5*sizeof(char)), "mOut = %s\n", mOut); > > if(!setlocale(LC_ALL, "Japanese_Japan.932")) { > @@ -1209,7 +1209,7 @@ static void test_mbstowcs(void) > } > > ret = mbstowcs(wOut, mHiragana, 6); > - ok(ret == 2, "ret = %d\n", ret); > + ok(ret == 2, "mbstowcs did not returned 2\n"); > ok(!memcmp(wOut, wHiragana, sizeof(wHiragana)), "wOut = %s\n", wine_dbgstr_w(wOut)); > > ret = wcstombs(mOut, wHiragana, 6); > -- > 1.7.0.4 > > > >

Aug. 28, 2010

Re: d3d9 equivalent of D3DXFVFFromDeclarator?

by Misha Koshelev

On Fri, Aug 27, 2010 at 10:53 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 28 August 2010 02:44, Misha Koshelev <misha680(a)gmail.com> wrote: >> I am looking again at d3d9, but feel like I am running in circles a >> little bit trying to chase down where convFVF and convertedDecls is >> coming from. >> >> If you have any hints/advice, much appreciated. If there is a better >> place to look as well (like wined3d), please let me know. >> > We only convert from FVF to declaration in d3d9 / wined3d, not the > other way around. Converting from declaration to FVF may be a little > harder, but essentially you'd do FVF to declaration conversion in > reverse. I.e., you consume declaration elements from the declaration, > and check if they (exactly) match something that can be mapped to an > FVF. > > Suppose for example that you have the following declaration: > { > {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0}, > {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0}, > {0, 16, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_NORMAL, 0}, > D3DDECL_END() > } > > You'd check the first declaration element, and see that is matches > D3DFVF_XYZ. Then you look at the next and see that it matches e.g. > D3DFVF_DIFFUSE. The next element would match D3DFVF_NORMAL, but you > can't have that, because normal data should come before color data in > the vertex buffer, so this declaration can't be mapped to an FVF. > I.e., ordering of declaration elements matters, you can't have holes / > padding, etc. It may be interesting to test if just the order of the > data in the vertex buffer matters, or also the order of elements in > the declaration. Example: > > { > {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0}, > {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0}, > D3DDECL_END() > } > and > { > {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0}, > {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0}, > D3DDECL_END() > } > > describe the same vertex buffer layout, but may behave differently for > D3DXFVFFromDeclarator(). > Thank you for the thorough explanation. One point of clarification if possible. The need for D3DXFVFFromDeclarator() from the standpoint ID3DXMesh is for the GetFVF() function. It seems, per dlls/d3d9/tests/vertexdeclaration.c test_decl_to_fvf that the same functionality (to return an FVF from a device) exists in d3d9 as well. I was wondering how this is done, and whether a similar mechanism would be acceptable for ID3DXMesh? Thank you Misha

Aug. 28, 2010

Re: winebuild on sparc, RFC

by Alexandre Julliard

Austin English <austinenglish(a)gmail.com> writes: > The first blocks running wine, the second blocks building it. For the > second, however, I found an old patch: > http://www.mail-archive.com/wine-devel(a)winehq.org/msg23307.html > > and rediffed it to current wine. With it, wine mostly compiles (mshtml > gets a 'Bus error' when compiling, but no gcc warning/error). I'm not > sure if the patch is correct, and I've contacted Eric to ask him to > submit the patch, but didn't receive a reply. If it's correct, I'll > send it in, with his name on it. It's not correct. Code should go in the text segment. -- Alexandre Julliard julliard(a)winehq.org

Aug. 28, 2010

winebuild on sparc, RFC

by Austin English

Howdy, Out of curiosity, I've been testing compiling Wine on Sparc. I've sent a few patches to fix a few problems that have crept up over the years. There are two big bugs left though: http://bugs.winehq.org/show_bug.cgi?id=24050 and http://bugs.winehq.org/show_bug.cgi?id=24142 The first blocks running wine, the second blocks building it. For the second, however, I found an old patch: http://www.mail-archive.com/wine-devel(a)winehq.org/msg23307.html and rediffed it to current wine. With it, wine mostly compiles (mshtml gets a 'Bus error' when compiling, but no gcc warning/error). I'm not sure if the patch is correct, and I've contacted Eric to ask him to submit the patch, but didn't receive a reply. If it's correct, I'll send it in, with his name on it. So, those of you who know winebuild (or better yet, Sparc), would you please check the attached patch. Thanks! -Austin

Aug. 28, 2010

Re: dbghelp: Remove unused functions?

by Eric Pouech

Le 28/08/2010 15:13, Andrew Talbot a écrit : > Hi, > > Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c are not called. May I remove them or does anyone have plans for them? > > Thanks, > > Andy. > > > > > you can remove them. they have been superseeded by the ones in image_private.h A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

Aug. 28, 2010

dbghelp: Remove unused functions?

by Andrew Talbot

Hi, Static functions pe_get_sect() and pe_get_sect_size() in dbghelp/pe_module.c are not called. May I remove them or does anyone have plans for them? Thanks, Andy.

Aug. 28, 2010

Re: d3d9 equivalent of D3DXFVFFromDeclarator?

by Henri Verbeet

On 28 August 2010 02:44, Misha Koshelev <misha680(a)gmail.com> wrote: > I am looking again at d3d9, but feel like I am running in circles a > little bit trying to chase down where convFVF and convertedDecls is > coming from. > > If you have any hints/advice, much appreciated. If there is a better > place to look as well (like wined3d), please let me know. > We only convert from FVF to declaration in d3d9 / wined3d, not the other way around. Converting from declaration to FVF may be a little harder, but essentially you'd do FVF to declaration conversion in reverse. I.e., you consume declaration elements from the declaration, and check if they (exactly) match something that can be mapped to an FVF. Suppose for example that you have the following declaration: { {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0}, {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0}, {0, 16, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_NORMAL, 0}, D3DDECL_END() } You'd check the first declaration element, and see that is matches D3DFVF_XYZ. Then you look at the next and see that it matches e.g. D3DFVF_DIFFUSE. The next element would match D3DFVF_NORMAL, but you can't have that, because normal data should come before color data in the vertex buffer, so this declaration can't be mapped to an FVF. I.e., ordering of declaration elements matters, you can't have holes / padding, etc. It may be interesting to test if just the order of the data in the vertex buffer matters, or also the order of elements in the declaration. Example: { {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0}, {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0}, D3DDECL_END() } and { {0, 12, D3DDECLTYPE_D3DCOLOR, 0, D3DDECLUSAGE_COLOR, 0}, {0, 0, D3DDECLTYPE_FLOAT3, 0, D3DDECLUSAGE_POSITION, 0}, D3DDECL_END() } describe the same vertex buffer layout, but may behave differently for D3DXFVFFromDeclarator().

Aug. 27, 2010

d3d9 equivalent of D3DXFVFFromDeclarator?

by Misha Koshelev

Dear All: Thanks a lot Henri for your wonderful D3DXDeclaratorFromFVF patches. It is wonderful to be exposed to the "right" way to implement this function. I am starting to look at D3DXDeclaratorFromFVF, as this would be the next step before implementing ID3DXMesh. I am looking again at d3d9, but feel like I am running in circles a little bit trying to chase down where convFVF and convertedDecls is coming from. If you have any hints/advice, much appreciated. If there is a better place to look as well (like wined3d), please let me know. Thank you! Misha

Aug. 27, 2010

Re: banning spammer from the forum

by David Hagood

On Fri, 2010-08-27 at 08:25 -0500, Rosanne DiMesio wrote: > Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. > It would also be a good idea to purge those spams from the archive: the goal of them being to create links to the spamvertized sites in order to raise their page rank in search engines.

Aug. 27, 2010

Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

by Octavian Voicu

On Fri, Aug 27, 2010 at 7:36 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Octavian Voicu wrote: >>> so binary compatibility in RC files is required >>We don't have this right now. Native winmm.dll uses integer resource >>ids (id 200 for core commands, [...]) >>Wine currently uses string ids > Could you please elaborate on that? I wasn't aware of an incompatibility. Check out this job on wine testbot: https://testbot.winehq.org/JobDetails.pl?Key=4830 I copied the table loading code from mci.c, but had to change the code that loaded the tables, because in native winmm.dll, tables are identified by an integer resource id (not a string one): str = MAKEINTRESOURCEW(200); /* this is for CORE table I guess, as it doesn't match any known device type */ I read somewhere that WIN98 and earlier stored tables in mmsystem.dll, that's why all the tests fail. If somebody would be interested, he could use resedit (free download from www.resedit.net) to open resources in dlls (www.topdll.com has a lot of dlls of various versions). Latest ones have versions something like 6.1.7600.* (ie. the ones used by win7). Anyway, compare the full log (from the testbot job 4830 linked eralier) for tests W7PROX64 (32 bit mci) and W7PROX64 (64 bit mci). Conclusion is that 32 bit mci uses MCI_INTEGER as return type for MCI_STATUS, while 64 bit one uses MCI_INTEGER64. I'll add MCI_INTEGER64 to mmddk.h (#ifdef-ed like in the ddk) and also something like MCI_INTEGER3264 which will be MCI_INTEGER on 32 bit systems, and MCI_INTEGER64 on 64 bit systems. Then use MCI_INTEGER3264 in winmm_res.rc & others. >>> I don't agree here. IMO the parser should be the most agnostic possibly >>> against the real data structures >>Not sure if I understand exactly what you mean here > > I believe Eric envisions a parser that needs no MCI_*_PARMS at all > because everything lies in the resource (except that the first > DWORD_PTR is the callback). Even MCI_RETURN need not be second (yet > there's no known case where that happens). It would be a major change > from the current parser. > > It could be sketched as follows: > - get first token (verb) > - get second token (beware of quoting) ("device") > - find driver according to device > - either name of an existing alias > - or name of MCI driver ("waveaudio") > - or waveaudio!foo.wav > - or "all" > - or something else > - load driver's command table (may need loading driver!) > - parse command options according to table > > Now we know the command's numeric value and can act upon it. > That would be much more compatible than what is in place now. > > Still, the devil lies in the details. E.g. a) > sound > sound notify > are valid MCI commands. Look ma, no device! I'll look into it, sounds like a challenge :) > b) Sysinfo cdaudio quantity open > need IMHO not load the cdaudio driver. It strictly operates at winmm's > level. Perhaps first try to identify the verb via the core table, and > if it's a core command like MCI_SYSINFO, never load the driver? > MCI_SYSINFO_PARMS.wDeviceType needs special treatment anyway, > the parser is not enough. > > c) When to unload the driver? > > At some point one needs MCI_*_PARMS. For instance, it's winmm's job > to detect MCIERR_DUPLICATE_ALIAS. How is it going to access the alias > field if not via MCI_OPEN_PARMS and thus imposing that all > MCI_*_OPEN_PARMS are congruent? (e.g. MCI_DGV|WAVE_OPEN_PARMS). > > One could imagine backparsing the resource file to detect the position > of the slot that defines the MCI_ALIAS element... This is just crazy. > > I've tests that prove (and a patch in my queue) that unlike the > mciSendCommand interface, the string parser always sets an alias. So > at some point it must set the lpstrAlias slot. How is it going to do > that if not via MCI_OPEN_PARMS? Not very familiar with this part yet, so I'll focus on getting basic 64 bit support working first, while also looking at the big picture when possible. Octavian

Aug. 27, 2010

[PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

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

Hi, Octavian Voicu wrote: >> so binary compatibility in RC files is required >We don't have this right now. Native winmm.dll uses integer resource >ids (id 200 for core commands, [...]) >Wine currently uses string ids Could you please elaborate on that? I wasn't aware of an incompatibility. >> I don't agree here. IMO the parser should be the most agnostic possibly >> against the real data structures >Not sure if I understand exactly what you mean here I believe Eric envisions a parser that needs no MCI_*_PARMS at all because everything lies in the resource (except that the first DWORD_PTR is the callback). Even MCI_RETURN need not be second (yet there's no known case where that happens). It would be a major change from the current parser. It could be sketched as follows: - get first token (verb) - get second token (beware of quoting) ("device") - find driver according to device - either name of an existing alias - or name of MCI driver ("waveaudio") - or waveaudio!foo.wav - or "all" - or something else - load driver's command table (may need loading driver!) - parse command options according to table Now we know the command's numeric value and can act upon it. That would be much more compatible than what is in place now. Still, the devil lies in the details. E.g. a) sound sound notify are valid MCI commands. Look ma, no device! b) Sysinfo cdaudio quantity open need IMHO not load the cdaudio driver. It strictly operates at winmm's level. Perhaps first try to identify the verb via the core table, and if it's a core command like MCI_SYSINFO, never load the driver? MCI_SYSINFO_PARMS.wDeviceType needs special treatment anyway, the parser is not enough. c) When to unload the driver? At some point one needs MCI_*_PARMS. For instance, it's winmm's job to detect MCIERR_DUPLICATE_ALIAS. How is it going to access the alias field if not via MCI_OPEN_PARMS and thus imposing that all MCI_*_OPEN_PARMS are congruent? (e.g. MCI_DGV|WAVE_OPEN_PARMS). One could imagine backparsing the resource file to detect the position of the slot that defines the MCI_ALIAS element... This is just crazy. I've tests that prove (and a patch in my queue) that unlike the mciSendCommand interface, the string parser always sets an alias. So at some point it must set the lpstrAlias slot. How is it going to do that if not via MCI_OPEN_PARMS? Regards, Jörg Höhle

Aug. 27, 2010

Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

by Octavian Voicu

On Fri, Aug 27, 2010 at 4:25 PM, Eric Pouech <eric.pouech(a)orange.fr> wrote: > 2010/8/27 Octavian Voicu octavian.voicu(a)gmail.com >> I didn't think it was necessary to test on native systems. The command >> parsing looks like internal winmm stuff, which makes no difference to >> the exported interfaces, as long as the command string is parsed into >> the corresponding MCI_ structures correctly. > > no the format of MCI string tables is public, and Wine aims at supporting > native MCI drivers (which can come with their own tables) > so binary compatibility in RC files is required We don't have this right now. Native winmm.dll uses integer resource ids (id 200 for core commands, and the MCI_DEVTYPE_ constants for the rest; can't figure what device is 524 though, last device is MCI_DEVTYPE_SEQUENCER which is 523). Wine currently uses string ids, with a table to map device ids to device name strings. Also, winmm_res.rc and others looks really bad because they use numeric constants (eg. 0x00000803L instead of MCI_OPEN, 0). >>In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe >>also stick MCI_GENERIC_PARMS in there. > I don't agree here. IMO the parser should be the most agnostic possibly > against the real data structures (the MCI string table shall contain the > definition of the structures including type of data). so, using unions and > structures is going into the right direction (even if I agree that current > parser doesn't fully comply with that goal) Not sure if I understand exactly what you mean here. Bottom line is that unions & structures are the way to go, like in Joerg's patch, but maybe try to make it look prettier? Octavian PS: found this really useful pdf documenting MCI: http://mediaxw.sourceforge.net/files/tmp/Windows%20NT%20DDK%20-%20Multimedi…

Aug. 27, 2010

Re: banning spammer from the forum

by Jeremy Newman

Done. On 08/27/2010 08:25 AM, Rosanne DiMesio wrote: > Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. >

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by Henri Verbeet

On 27 August 2010 15:14, <wylda(a)volny.cz> wrote: > All apps are working perfectly! Could i kindly ask you for sending > to patches today? It looks like i will have spare time for testing, > so it will help me to not to mess with revering. > It's probably not quite correct. In particular, before 6120d7cc145 it's likely the Mic element would be counted in capcontrols as well, and skipped for the chan count in some cases. Also, the channel count for USB mics will probably end up as 2 now, which would make it hit the "No channels found, skipping device!\n" path again. I think I'd prefer the original author or Maarten to have a look at this, the code looks somewhat complicated to me, perhaps more so than really needed.

Aug. 27, 2010

Re: msvcrt:locale Properly fix setlocale()

by Alexandre Julliard

GOUJON Alexandre <ale.goujon(a)gmail.com> writes: > On 08/27/2010 03:22 PM, Alexandre Julliard wrote: >> I don't think it makes sense to declare minor spelling differences as >> broken, or to change the kernel resources for this > > I did not write these broken. I just removed the todo_wine and fix the nls. > I think they have been added to match what wine setlocale was returning. > Should I resend my patch removing all of these broken() ? Not all of them, but those that don't make sense, yes. For instance "Norwegian-Nynorsk" and "Norwegian (Nynorsk)" are both OK since they both appear on Windows, there's no reason to declare one broken. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2010

Re: msvcrt:locale Properly fix setlocale()

by GOUJON Alexandre

On 08/27/2010 03:22 PM, Alexandre Julliard wrote: > I don't think it makes sense to declare minor spelling differences as > broken, or to change the kernel resources for this I did not write these broken. I just removed the todo_wine and fix the nls. I think they have been added to match what wine setlocale was returning. Should I resend my patch removing all of these broken() ?

Aug. 27, 2010

Fwd: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit.

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

Octavian, >I just looked in mmddk.h and they have this: >#define MCI_INTEGER64 13 It's good you found out about MCI_INTEGER64. Yet it's completely crazy because googling it yields 6 hits in total, all about Wine bug 22146. Bing shows nothing at all. How can such a name be that invisible? >So, do you want to fix your patches and send them, or do you want me >to continue working on this patch set? I'm fine if you do (as I've plenty of other patches in my queue) especially if you also fix the parser to handle MCI_HWND (another DWORD_PTR), which is the second half needed for 64bit as I mention in http://bugs.winehq.org/show_bug.cgi?id=22146#c12 GetDWORD also needs some change to be able to parse DWORD_PTR things, e.g. window handles. I've not yet written a single test for that (no mciavi tests). I'll send you all the MCI tests I have written ASAP. Even without written tests, one can use WINEDEBUG=+mci and analyse the parser logs for individual commands sent e.g. via the interactive MCI shell you'll find in http://bugs.winehq.org/show_bug.cgi?id=20232#c10 You obviously own a 64bit system so it's easier for you to test. I don't and had to beg. Regards, Jörg Höhle

Aug. 27, 2010

banning spammer from the forum

by Rosanne DiMesio

Can someone with forum admin rights please ban user Eden1023? I've had to delete multiple spam posts by this user every day for the past few days. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Aug. 27, 2010