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

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Robert Kim App and Facebook Marketing

"my 3G Internet > connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one > cares) > " HAHA!!! Don't you have a starbucks near by??? They do free wifi now! On Tue, Aug 31, 2010 at 3:58 AM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Is the attached patch well formed ? > Can someone give it a try ? > I don't want to run it, I fear it'll download all tables : my 3G Internet > connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one > cares) > > > > -- 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-… http://sparkah.com/2010/08/25/facebook-marketing-strategies-from-nyc-and-lo…

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 18:48, misha680 <misha680(a)gmail.com> wrote: > D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per > include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 > it is last, I assume it would also come last? > The LASTBETA FVF flags don't add elements themselves, they modify the D3DFVF_XYZBn ones. See also D3DXDeclaratorFromFVF() for reference.

Aug. 31, 2010

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.

by Francois Gouget

On Tue, 31 Aug 2010, testbot(a)testbot.winehq.org wrote: [...] > http://testbot.winehq.org/JobDetails.pl?Key=4872 [...] > === W98SE (32 bit process) === > Failure running script in VM: Exceeded timeout limit of 315 sec This is strange. Testbot says the process timed out yet the full log has the expected summary line listing the tests that were run as well as the 'process done' line so it looks like the test completed: > process: 320 tests executed (0 marked as todo, 0 failures), 5 skipped. > kernel32:process done (0) -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by misha680

Henri Verbeet wrote: > > On 31 August 2010 18:16, Misha Koshelev <misha680(a)gmail.com> wrote: >>> Well yes, but I'd say that ordering should apply to *any* FVF element, >>> not just colors and normals. E.g., point size before position or >>> texture before color should be just as untranslatable. >> Thank you. I was not aware of these constraints. >> >> Is there, by any chance, a good place for this? I have been checking >> the MSDN docs so far: >> http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx >> but at least upon my initial reads did not notice any such guidelines. >> > It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | > D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific > vertex buffer layout, if you translate a declaration to that, it > should better describe that exact same layout.) > Thank you. I had to check a reference but I think I understand now. http://www.xmission.com/~legalize/book/download/05-Modeling.pdf pg. 168 "The vertex components are laid out in memory in the same order as the vertex components listed in the table, starting with the position component. #define D3DFVF_XYZ 0x002 #define D3DFVF_XYZRHW 0x004 #define D3DFVF_XYZB1 0x006 #define D3DFVF_XYZB2 0x008 #define D3DFVF_XYZB3 0x00a #define D3DFVF_XYZB4 0x00c #define D3DFVF_XYZB5 0x00e #define D3DFVF_NORMAL 0x010 #define D3DFVF_PSIZE 0x020 #define D3DFVF_DIFFUSE 0x040 #define D3DFVF_SPECULAR 0x080 #define D3DFVF_TEX0 0x000 #define D3DFVF_TEX1 0x100 #define D3DFVF_TEX2 0x200 #define D3DFVF_TEX3 0x300 #define D3DFVF_TEX4 0x400 #define D3DFVF_TEX5 0x500 #define D3DFVF_TEX6 0x600 #define D3DFVF_TEX7 0x700 #define D3DFVF_TEX8 0x800 #define D3DFVF_LASTBETA_UBYTE4 0x1000 Every FVF must include a position with one of the D3DFVF XYZ, D3DFVF - XYZRHW, D3DFVF XYZB1, D3DFVF XYZB2, D3DFVF XYZB3, D3DFVF XYZB4, or D3D- FVF XYZB5. The remaining FVF flags are all optional." D3DFVF_LASTBETA_D3DCOLOR is not present in the list above, but as, per include/d3d9types.h:#define D3DFVF_LASTBETA_D3DCOLOR 0x8000 it is last, I assume it would also come last? Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXFVFFromDeclarator-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 18:16, Misha Koshelev <misha680(a)gmail.com> wrote: >> Well yes, but I'd say that ordering should apply to *any* FVF element, >> not just colors and normals. E.g., point size before position or >> texture before color should be just as untranslatable. > Thank you. I was not aware of these constraints. > > Is there, by any chance, a good place for this? I have been checking > the MSDN docs so far: > http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx > but at least upon my initial reads did not notice any such guidelines. > It's implied by the way FVFs work. (Think about it, "D3DFVF_XYZ | D3DFVF_DIFFUSE | D3DFVF_PSIZE" for example describes a very specific vertex buffer layout, if you translate a declaration to that, it should better describe that exact same layout.)

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Misha Koshelev

On Tue, Aug 31, 2010 at 7:58 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 31 August 2010 14:47, misha680 <misha680(a)gmail.com> wrote: >> As you can see by the tests added, colors and normals have an ordering that >> is specifically constrained within the FVF. >> > Well yes, but I'd say that ordering should apply to *any* FVF element, > not just colors and normals. E.g., point size before position or > texture before color should be just as untranslatable. Thank you. I was not aware of these constraints. Is there, by any chance, a good place for this? I have been checking the MSDN docs so far: http://msdn.microsoft.com/en-us/library/bb147173%28VS.85%29.aspx but at least upon my initial reads did not notice any such guidelines. > >> To clarify, by saying that the booleans are redundant, do you mean to say >> that, say, if I have a normal element, I should iterate back through all >> declaration elements that have already been processed and check for a prior >> color element, and then return D3DERR_INVALIDCALL? >> > No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already > have a normal. That is a great idea! I honestly did not think of that at all. Thank you for the wonderful hint. Misha

Aug. 31, 2010

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx

by Owen Rudge

Hi Henri, > Probably depends on the device supporting NPOT textures again. The capabilities are checked in the D3DXCheckTextureRequirements function, and the values adjusted if necessary. > (Yeah, this is a mostly unchanged copy of my earlier comments.) My apologies, I somehow missed the previous e-mail at the time. (I do see it now.) Thanks for your feedback, -- Owen Rudge http://www.owenrudge.net/

Aug. 31, 2010

Re: [PATCH 4/4] ws2_32: implement AcceptEx and GetAcceptExSockaddrs

by Alexandre Julliard

Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> writes: > /*********************************************************************** > + * WS2_async_recv_accept (INTERNAL) > + * > + * This function is used to finish the read part of an accept request. It is > + * needed to place the completion on the correct socket (listener). > + */ > +static NTSTATUS WINAPI WS2_async_recv_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ > + void *junk; > + struct ws2_accept_async *wsa = arg; > + > + status = WS2_async_recv( wsa->read, iosb, status, &junk ); > + if (status == STATUS_PENDING) > + return status; > + > + if (wsa->user_overlapped->hEvent) > + SetEvent(wsa->user_overlapped->hEvent); > + if (wsa->cvalue) > + WS_AddCompletion( HANDLE2SOCKET(wsa->listen_socket), wsa->cvalue, iosb->u.Status, iosb->Information ); > + HeapFree( GetProcessHeap(), 0, wsa->read ); > + HeapFree( GetProcessHeap(), 0, wsa ); > + > + return status; > +} > + > +/*********************************************************************** > + * WS2_async_accept (INTERNAL) > + * > + * This is the function called to satisfy the AcceptEx callback > + */ > +static NTSTATUS WINAPI WS2_async_accept( void *arg, IO_STATUS_BLOCK *iosb, NTSTATUS status ) > +{ These are not valid async callbacks, the way async callbacks work has changed since the patch was first written. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2010

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

by Mikko Rasa

On 31.08.2010 16:16, Henri Verbeet wrote: > On 30 August 2010 18:37, Mikko Rasa<tdb(a)tdb.fi> wrote: >> + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); > ... >> - stream_sizes->cbHeader = 5; >> - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ >> + stream_sizes->cbHeader = ctx->header_bytes; >> + stream_sizes->cbTrailer = ctx->trailer_bytes; > Does this imply TLS record padding should be disabled? I imagine an > encrypted message may not fit in the application provided buffers > otherwise. That was originally so I could determine the end of the message and fill a SECBUFFER_EXTRA buffer if there's any leftover data (probably because the input buffer contained part of the next message). However, since I had to do my own TLS frame decoding anyway in a later patch, I don't really need to know the MAC size anymore. I'll produce a revised patchset shortly, taking into account Hans's feedback as well. -- Mikko

Aug. 31, 2010

Re: [PATCH 2/3] Store header and trailer byte counts in schan_context for future use

by Henri Verbeet

On 30 August 2010 18:37, Mikko Rasa <tdb(a)tdb.fi> wrote: > + ctx->trailer_bytes = pgnutls_mac_get_key_size(pgnutls_mac_get(ctx->session)); ... > - stream_sizes->cbHeader = 5; > - stream_sizes->cbTrailer = mac_size + 256; /* Max 255 bytes padding + 1 for padding size */ > + stream_sizes->cbHeader = ctx->header_bytes; > + stream_sizes->cbTrailer = ctx->trailer_bytes; Does this imply TLS record padding should be disabled? I imagine an encrypted message may not fit in the application provided buffers otherwise.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 31 August 2010 14:47, misha680 <misha680(a)gmail.com> wrote: > As you can see by the tests added, colors and normals have an ordering that > is specifically constrained within the FVF. > Well yes, but I'd say that ordering should apply to *any* FVF element, not just colors and normals. E.g., point size before position or texture before color should be just as untranslatable. > To clarify, by saying that the booleans are redundant, do you mean to say > that, say, if I have a normal element, I should iterate back through all > declaration elements that have already been processed and check for a prior > color element, and then return D3DERR_INVALIDCALL? > No, but you can check "*fvf & D3DFVF_NORMAL" to see if you already have a normal.

Aug. 31, 2010

Re: [PATCH] Only process full TLS frames in schan_DecryptMessage

by Hans Leidekker

On Mon, 2010-08-30 at 23:57 +0300, Mikko Rasa wrote: > + SIZE_T expected_size; > ssize_t received = 0; > ssize_t ret; > int idx; > - char *buf_ptr; > + unsigned char *buf_ptr; > unsigned int offset; > > TRACE("context_handle %p, message %p, message_seq_no %d, quality %p\n", > @@ -1230,12 +1243,22 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle > if (idx == -1) > return SEC_E_INVALID_TOKEN; > buffer = &message->pBuffers[idx]; > + buf_ptr = (unsigned char *)buffer->pvBuffer; > + > + expected_size = 5 + ((buf_ptr[3] << 8) | buf_ptr[4]); > + if(buffer->cbBuffer < expected_size) > + { > + TRACE("Expected %u bytes, but buffer only contains %u bytes\n", expected_size, buffer->cbBuffer); > + TRACE("Returning SEC_E_INCOMPLETE_MESSAGE\n"); > + return SEC_E_INCOMPLETE_MESSAGE; > + } This produces a compiler warning here: schannel.c: In function ‘schan_DecryptMessage’: schannel.c:1251: warning: format ‘%u’ expects type ‘unsigned int’, but argument 5 has type ‘SIZE_T’

Aug. 31, 2010

Re: [PATCH 3/3] Fill buffers in schan_DecryptMessage the same way as windows does

by Hans Leidekker

On Mon, 2010-08-30 at 19:37 +0300, Mikko Rasa wrote: > - memcpy(buffer->pvBuffer, data, received); > - buffer->cbBuffer = received; > + buf_ptr = (char *)buffer->pvBuffer; You don't need this cast. > + offset = ctx->header_bytes; > + memcpy(buf_ptr + offset, data, received); > HeapFree(GetProcessHeap(), 0, data); > > + schan_decrypt_fill_buffer(message, SECBUFFER_DATA, buf_ptr + offset, received); > + offset += received; > + > + schan_decrypt_fill_buffer(message, SECBUFFER_STREAM_TRAILER, buf_ptr + offset, buffer->cbBuffer - offset); > + offset += ctx->trailer_bytes; > + > + if(buffer->cbBuffer > offset) > + schan_decrypt_fill_buffer(message, SECBUFFER_EXTRA, buf_ptr + offset, buffer->cbBuffer - offset); > + > + buffer->BufferType = SECBUFFER_STREAM_HEADER; > + buffer->cbBuffer = ctx->header_bytes; > + FWIW, this patch set passes my tests.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by misha680

Henri Verbeet wrote: > > On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: >> Looking forward to (constructive) comments. >> > Why are colors and normals special? What use is hasPosition? What > happens when the source declaration has e.g. two color elements with > usage index 0, or two position elements? Note that the booleans are > redundant, you store that information in the FVF. > > > > As you can see by the tests added, colors and normals have an ordering that is specifically constrained within the FVF. To clarify, by saying that the booleans are redundant, do you mean to say that, say, if I have a normal element, I should iterate back through all declaration elements that have already been processed and check for a prior color element, and then return D3DERR_INVALIDCALL? Again, for the case of two color elements or two normal elements, are you suggesting I do the same (iterate through all past elements)? Wouldn't, in this case, a boolean be more efficient? hasPosition I apologize does not need to be there. Just trying to clarify your points regarding your comments re booleans and specialty of colors and normals. Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXFVFFromDeclarator-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 31, 2010

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.

by Jacek Caban

On 8/31/10 2:03 PM, Alexandre Julliard wrote: > Jacek Caban<jacek(a)codeweavers.com> writes: >> They are defined by default by midl. > __midl is supposed to be set to the midl compiler version, and I'm not > entirely convinced it's appropriate for us to define it. My motivation was to make headers prepared for midl to work. They usually check only if __midl is defined and that's all we can sanely do. > Also, _WIN64 can't depend on how widl was built, since it can generate > both 32-bit and 64-bit code. Right, I've sent the patch too quickly, sorry. > You'd have to parse everything twice if you wanted to make use of this. That's a matter of not using it, but if midl defines it, I think we should do it as well. I will resend the patch with _WIN32 define only. Thanks, Jacek

Aug. 31, 2010

Re: [2/3] d3dx9: Implement D3DXCreateTextureFromFileInMemoryEx

by Henri Verbeet

On 26 July 2010 23:05, Owen Rudge <owen(a)owenrudge.net> wrote: > + if ((filter & 0xFFFF) > D3DX_FILTER_BOX && filter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if ((mipfilter & 0xFFFF) > D3DX_FILTER_BOX && mipfilter != D3DX_DEFAULT) > + return D3DERR_INVALIDCALL; > + > + if (!filter || !mipfilter) > + return D3DERR_INVALIDCALL; I think those should be handled implicitly by D3DXLoadSurfaceFromFileInMemory() / D3DXFilterTexture(). > + if (filter == D3DX_DEFAULT) > + filter = D3DX_FILTER_TRIANGLE | D3DX_FILTER_DITHER; > + > + if (mipfilter == D3DX_DEFAULT) > + mipfilter = D3DX_FILTER_BOX; Same. > + if (width == 0 || width == D3DX_DEFAULT_NONPOW2) > + width = imginfo.Width; Probably depends on the device supporting NPOT textures again. > + if ((pool != D3DPOOL_DEFAULT) && (usage != D3DUSAGE_DYNAMIC)) Dynamic textures are a device capability. (Yeah, this is a mostly unchanged copy of my earlier comments.)

Aug. 31, 2010

Re: widl: Added default __midl, _WIN32 and _WIN64 defines.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > They are defined by default by midl. __midl is supposed to be set to the midl compiler version, and I'm not entirely convinced it's appropriate for us to define it. Also, _WIN64 can't depend on how widl was built, since it can generate both 32-bit and 64-bit code. You'd have to parse everything twice if you wanted to make use of this. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Nicolas Le Cam

2010/8/31 Francois Gouget <fgouget(a)free.fr> > On Tue, 31 Aug 2010, Alexandre Julliard wrote: > > > Francois Gouget <fgouget(a)free.fr> writes: > > > > > http://source.winehq.org/patches/data/65442 > > > > > > According to http://source.winehq.org/patches/ this patch causes a > build > > > error (or maybe a new warning). However here (gcc 4.4) I see no warning > > > at all. > [...] > > It's an undefined reference, probably you don't have OpenAL so that code > > doesn't get compiled. > > Ah, right, it's MMDevice_GetPropValue() that gets used from audio.c if > OpenAL is supported. And OpenAL is missing because I'm on a Debian 64 > system so there's no package providing the 32bit version :-( > > Does anyone know of 'clean' ways of getting libv4l, libgsm, libmpg123 > and libopenal on a 64bit Debian system? I would try apt-cross but I was > once told that using it to get 32bit libraries on 64bit system was > stupid, not meant to work, etc. > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > Linux: It is now safe to turn on your computer. > > > I don't know of a 'clean' way (and I'm also interested if anyone knows) but, at least, lib32v4l-0 is available for squeeze and sid since early june (it also seems to be in lenny-backports but from the older, now removed, libv4l source package). -- Nicolas Le Cam

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

Is the attached patch well formed ? Can someone give it a try ? I don't want to run it, I fear it'll download all tables : my 3G Internet connection is limited to 20 kB/s now (I downloaded more than 5 GB but no one cares)

Aug. 31, 2010

Re: Chinese translation of key pages on wiki.winehq.org?

by Frédéric Delanoy

On Tue, Aug 31, 2010 at 02:40, Dan Kegel <dank(a)kegel.com> wrote: > Are there any Chinese speakers on the list? > Any interest in starting a Chinese translation of wiki.winehq.org? > > I bring this up because a Chinese user/developer is asking for help > getting started with submitting translations to Wine. I think he would find > Chinese versions of > http://wiki.winehq.org/SubmittingPatches > and perhaps even > http://wiki.winehq.org/Translating > helpful. > > It seems strange for a translator to need help reading English > documents, but perhaps it would help them come up the curve > faster. Well maybe it's because (some of) these pages are not clear enough for non-techies. Maybe he could tell what parts he didn't understand so the wiki pages can be improved (it would help for other languages, too). Rgds, Frédéric

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/31/2010 12:23 PM, Dmitry Timoshkov wrote: > Wine's aim is to run Windows applications, not to implement everything > Windows has. I disagree about that but it doesn't matter after all. > Spending time fixing > differencies nobody cares about is a time loss You're probably right but what about if the solution is known and working ? I don't ask you to waste your time fixing useless things (that's what I seems to do) but just help me to translate a single line change in a C file into a (probably single) perl line. [1] After that, all msvcrt:string tests (1415 exactly) will pass and I won't have to change these locale files again. --- [1] You're not paid for that so if anyone could help me on it, this topic will simply end .. with a better Wine.

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Francois Gouget

On Tue, 31 Aug 2010, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > > > http://source.winehq.org/patches/data/65442 > > > > According to http://source.winehq.org/patches/ this patch causes a build > > error (or maybe a new warning). However here (gcc 4.4) I see no warning > > at all. [...] > It's an undefined reference, probably you don't have OpenAL so that code > doesn't get compiled. Ah, right, it's MMDevice_GetPropValue() that gets used from audio.c if OpenAL is supported. And OpenAL is missing because I'm on a Debian 64 system so there's no package providing the 32bit version :-( Does anyone know of 'clean' ways of getting libv4l, libgsm, libmpg123 and libopenal on a 64bit Debian system? I would try apt-cross but I was once told that using it to get 32bit libraries on 64bit system was stupid, not meant to work, etc. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.

Aug. 31, 2010

Re: d3dx9: Implement D3DXFVFFromDeclarator.

by Henri Verbeet

On 30 August 2010 23:07, Misha Koshelev <misha680(a)gmail.com> wrote: > Looking forward to (constructive) comments. > Why are colors and normals special? What use is hasPosition? What happens when the source declaration has e.g. two color elements with usage index 0, or two position elements? Note that the booleans are redundant, you store that information in the FVF.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Dmitry Timoshkov

GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > You've done great things on wine for a long time and fixed plenty of > bugs (again, thanks) but ... how can you say that (the last sentence) ? > I don't want to offense you, I'm no one, and I don't say that just to be > mean .. but there won't be any problem until an application rely on it. > And that's wine is for : provide an implementation of win32 API, mimic > windows behavior (and its bugs). Wine's aim is to run Windows applications, not to implement everything Windows has. Therefore Wine only implements things the Windows applications depend upon. There are hundreds (if not thousands) APIs, or things that differ in Wine in comparoson to Windows. That only starts to matter once there is a Windows application that doesn't run due to that. Spending time fixing differencies nobody cares about is a time loss. -- Dmitry.

Aug. 31, 2010

Re: kernel32/tests: Fix compilation on systems that don't support nameless unions or structs.

by testbot＠testbot.winehq.org

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=4872 Your paranoid android. === W98SE (32 bit process) === Failure running script in VM: Exceeded timeout limit of 315 sec

Aug. 31, 2010

Re: wined3d: separate driver info from GPU info (try3)

by Henri Verbeet

On 31 August 2010 00:46, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > In the previous version of this patch, no version info was returned > for Windows versions which were not in the table. I verified on > Vista/Win7 what version numbers, gpu names and driver strings are > returned to applications running in 9x/2k/xp compatibility mode. It > appears that by default (perhaps the shim database can override it?) > these applications receive information about the current drivers > instead of fake information. For now I'm returning XP driver info if > no match was found. > > Future patches will add the 9x/Vista/Win7 info. When we reach that > stage and a user uses a Geforce 8800 and winver=win98, it will behave > the same as Windows (I assume XP is the default version number). > No. This will simply break currently working functionality. Regardless, I think it's a design flaw anyway to require separate entries for different Windows versions even though they're using the same driver model.

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > http://source.winehq.org/patches/data/65442 > > According to http://source.winehq.org/patches/ this patch causes a build > error (or maybe a new warning). However here (gcc 4.4) I see no warning > at all. > > Does this patch cause warnings / errors for anyone? > (it would be nice if the patches website could include the build error log<g>). It's an undefined reference, probably you don't have OpenAL so that code doesn't get compiled. -- Alexandre Julliard julliard(a)winehq.org

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/31/2010 11:20 AM, Dmitry Timoshkov wrote: > Windows uses an older Unicode specification, that's pretty normal that > unicode.org and Windows data differ in some places. There is no need > to change the mapping unless there is an application that depends on it Thanks for your answer. You've done great things on wine for a long time and fixed plenty of bugs (again, thanks) but ... how can you say that (the last sentence) ? I don't want to offense you, I'm no one, and I don't say that just to be mean .. but there won't be any problem until an application rely on it. And that's wine is for : provide an implementation of win32 API, mimic windows behavior (and its bugs). I can't help wine with crypto/gdi/d3d stuff so I'm looking for todo_wine I can solve and I can fix this one. As always, I understood what was wrong and proposed a patch to 1) remove todo_wine (statistically, wine is now more windows-compliant ) 2) correct wine behavior 3) prevent (maybe close) bugs Why do you want me not to fix a potential bug ? Anyway, I'll try to read cpmap.pl and try to understand what I can do with it. I'm open-minded and ready to discuss / understand and change if needed.

Aug. 31, 2010

Re: mmdevapi: Make MMDevice_[GS]etPropValue() static.

by Francois Gouget

http://source.winehq.org/patches/data/65442 According to http://source.winehq.org/patches/ this patch causes a build error (or maybe a new warning). However here (gcc 4.4) I see no warning at all. Does this patch cause warnings / errors for anyone? (it would be nice if the patches website could include the build error log<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

Aug. 31, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Henri Verbeet

I think you want these to show up in your editor while writing the code, not after the fact. "set list listchars=tab:»·,trail:·" for vim, but I'm sure any other half-decent editor will have equivalent functionality.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by Dmitry Timoshkov

GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > > --- a/libs/wine/c_1361.c > > +++ b/libs/wine/c_1361.c > > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > > uni2cp_low, > > uni2cp_high, > > { > > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > > } > > }; > > > May I ask some guidance to make this [1] patch accepted ? > Tests prove that the values above needs to be modified. > Actually, I don't know if "uni2cp_high" is generated from the Internet > or cpmap.pl (maybe both) > Anyway, I don't understand perl. > > May > http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT > be wrong ? > Or may Windows doesn't fully comply with unicode ? Windows uses an older Unicode specification, that's pretty normal that unicode.org and Windows data differ in some places. There is no need to change the mapping unless there is an application that depends on it. -- Dmitry.

Aug. 31, 2010

Re: msvcrt:string Fix codepage table 1361 (Korean Johab)

by GOUJON Alexandre

On 08/28/2010 02:12 PM, Alexandre Goujon wrote: > I know that libs/wine/c_1361.c is generated ("DO NOT EDIT!!"). > However (union cptable)cptable_1361.dbcs->lead_bytes needs to be modified according tests > [...] > diff --git a/libs/wine/c_1361.c b/libs/wine/c_1361.c > index b424cb1..50d2c47 100644 > --- a/libs/wine/c_1361.c > +++ b/libs/wine/c_1361.c > @@ -8902,6 +8902,6 @@ const struct dbcs_table cptable_1361 = > uni2cp_low, > uni2cp_high, > { > - 0x84, 0xd3, 0xd9, 0xde, 0xe0, 0xf9, 0x00, 0x00 > + 0x81, 0xd3, 0xd8, 0xde, 0xe0, 0xf9, 0x00, 0x00 > } > }; > May I ask some guidance to make this [1] patch accepted ? Tests prove that the values above needs to be modified. Actually, I don't know if "uni2cp_high" is generated from the Internet or cpmap.pl (maybe both) Anyway, I don't understand perl. May http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/KSC/JOHAB.TXT be wrong ? Or may Windows doesn't fully comply with unicode ? Thanks --- [1] : http://source.winehq.org/patches/data/65550

Aug. 31, 2010

Re: Wine 1.4 plans?

by Tom Wickline

On Tue, Aug 31, 2010 at 9:45 AM, Austin English <austinenglish(a)gmail.com>wrote: > On Mon, Aug 30, 2010 at 4:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > > I suppose we'll hear what the goals for 1.4 are at Wineconf, but > > here's my little wish list: > > > > Bug 6971, the mouse problem affecting many FPS-style games (Alexandre > > thinks it would take a month of his time?) > > Solving Wine's problems with Pulseaudio (bug #10495) > > Mono integration similar to the current Gecko integration (go Vincent!) > > Finishing d3dx9_36 and friends (i.e. getting rid of the need to run > > winetricks to load bits of Direct3D9) > > Excellent continuous build and test services at winehq.org, including > > performance tests (ok, this isn't really a wine feature) > > Move away from using 2D graphics acceleration, as Windows has done > > (this is both a superset and a subset of the DIBEngine idea) (heard > > this from Roderick) > > Arabic/Hebrew/other RTL left languages support is improving, that may > be a good candidate. > > Also, complete msvcr/mvscp and friends would be nice. > Rich Edit bugs and performance fixes would also be a nice, Ive not benchmarked it lately but Native Rich Edit use to be about 80% faster then builtin. Tom > -- > -Austin > > > -- Wine is not a conclusion but a process...

Aug. 31, 2010

Re: Wine 1.4 plans?

by Austin English

On Mon, Aug 30, 2010 at 4:06 PM, Dan Kegel <dank(a)kegel.com> wrote: > I suppose we'll hear what the goals for 1.4 are at Wineconf, but > here's my little wish list: > > Bug 6971, the mouse problem affecting many FPS-style games (Alexandre > thinks it would take a month of his time?) > Solving Wine's problems with Pulseaudio (bug #10495) > Mono integration similar to the current Gecko integration (go Vincent!) > Finishing d3dx9_36 and friends (i.e. getting rid of the need to run > winetricks to load bits of Direct3D9) > Excellent continuous build and test services at winehq.org, including > performance tests (ok, this isn't really a wine feature) > Move away from using 2D graphics acceleration, as Windows has done > (this is both a superset and a subset of the DIBEngine idea) (heard > this from Roderick) Arabic/Hebrew/other RTL left languages support is improving, that may be a good candidate. Also, complete msvcr/mvscp and friends would be nice. -- -Austin

Aug. 31, 2010

Chinese translation of key pages on wiki.winehq.org?

by Dan Kegel

Are there any Chinese speakers on the list? Any interest in starting a Chinese translation of wiki.winehq.org? I bring this up because a Chinese user/developer is asking for help getting started with submitting translations to Wine. I think he would find Chinese versions of http://wiki.winehq.org/SubmittingPatches and perhaps even http://wiki.winehq.org/Translating helpful. It seems strange for a translator to need help reading English documents, but perhaps it would help them come up the curve faster. - Dan

Aug. 31, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Andrew Eikum

On 08/30/2010 05:44 PM, Octavian Voicu wrote: > 1. You set color.ui to always and you're using less or another pager > that doesn't support color. You don't need to use a pager in git diff. > Normally, if you set color.ui to auto (or true), then color escape > sequences are only enabled when output is a terminal (not a pipe or > file). > > Instead of `git diff | less' just use `git diff'. If you really want > to use less, `git diff | less -r' should work with colors (-r enables > interpreting color escape codes in less). Git automatically invokes a pager, as given by your 'core.pager' setting (see 'man git-config'). It defaults to 'less'. If you're not getting color, check your LESS environment variable. Unset it to use Git's default settings (which should work with color escape sequences), or set it to something like "-R". See 'man less' for more options, obviously. If the above all seems correct, try a different or newer terminal emulator to help diagnose the problem. Andrew

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 9:25 PM, David Adam <david.adam.cnrs(a)gmail.com> wrote: > Does not work for me :crying: I voluntary added trailing space to my file. > Nothing appears in red. I obtain in white and black > testcooperativelevels_normal();ESC[m > ESC[32m+ESC[mESC[32m testcooperativelevels_normal_other_ddraw();ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > ESC[32m+ESC[mESC[41m ESC[m > releasedirectdraw();ESC[m > > I use kconsole. Maybe it is the problem ?? Something that starts with ESC[ is an escape sequence, it clearly shows that git is coloring the output, but your terminal isn't interpreting this. I also use kconsole (konsole actually, KDE terminal emulator right?). I see two possible causes: 1. You set color.ui to always and you're using less or another pager that doesn't support color. You don't need to use a pager in git diff. Normally, if you set color.ui to auto (or true), then color escape sequences are only enabled when output is a terminal (not a pipe or file). Instead of `git diff | less' just use `git diff'. If you really want to use less, `git diff | less -r' should work with colors (-r enables interpreting color escape codes in less). 2. Your terminal is not properly configured and colors don't work. Do you have colors in other commands, like in ls? Maybe this helps: https://bbs.archlinux.org/viewtopic.php?pid=511623 I have $TERM set to xterm. What distribution are you using? Maybe you can google for an answer on how to configure your terminal emulator to work with colors. Octavian

Aug. 30, 2010

Wine 1.4 plans?

by Dan Kegel

I suppose we'll hear what the goals for 1.4 are at Wineconf, but here's my little wish list: Bug 6971, the mouse problem affecting many FPS-style games (Alexandre thinks it would take a month of his time?) Solving Wine's problems with Pulseaudio (bug #10495) Mono integration similar to the current Gecko integration (go Vincent!) Finishing d3dx9_36 and friends (i.e. getting rid of the need to run winetricks to load bits of Direct3D9) Excellent continuous build and test services at winehq.org, including performance tests (ok, this isn't really a wine feature) Move away from using 2D graphics acceleration, as Windows has done (this is both a superset and a subset of the DIBEngine idea) (heard this from Roderick)

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Juan Lang

> Yeah, I'm not really sure how this is supposed to work. load_mono() > ensures that mono is loaded, so mono_handle should be set if it > succeeds. Unless someone calls CorExitProcess in another thread and > unloads it before we can grab the critical section again. > > Maybe load_mono should return without releasing the critical section, > thus preventing that race? The caller will almost always want to > proceed to create an AppDomain afterwards.. Ah, I see, you really did mean that. No, I don't think leaving the critical section open is the best thing. I expect someone calling CorExitProcess should expect problems if they continue to call mscoree functions after that. --Juan

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Vincent Povirk

> Hi Vincent, > > + EnterCriticalSection(&mono_lib_cs); > + if (!mono_handle) > + { > + ERR("CorExitProcess called on another thread?\n"); > + return -1; > you don't release mono_lib_cs here. Doh, thanks. > Similarly, in patch 3, > STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void > **ppObject) > (snip) > + EnterCriticalSection(&mono_lib_cs); > + if (!mono_handle) > + { > + ERR("CorExitProcess called on another thread?\n"); > + return E_FAIL; > > you don't release mono_lib_cs here, and the error message looks suspicious. > --Juan Yeah, I'm not really sure how this is supposed to work. load_mono() ensures that mono is loaded, so mono_handle should be set if it succeeds. Unless someone calls CorExitProcess in another thread and unloads it before we can grab the critical section again. Maybe load_mono should return without releasing the critical section, thus preventing that race? The caller will almost always want to proceed to create an AppDomain afterwards..

Aug. 30, 2010

Re: [1/3] mscoree: Store the AppDomain from CorExeMain, for use in other functions.

by Juan Lang

Hi Vincent, + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return -1; you don't release mono_lib_cs here. Similarly, in patch 3, STDAPI ClrCreateManagedInstance(LPCWSTR pTypeName, REFIID riid, void **ppObject) (snip) + EnterCriticalSection(&mono_lib_cs); + if (!mono_handle) + { + ERR("CorExitProcess called on another thread?\n"); + return E_FAIL; you don't release mono_lib_cs here, and the error message looks suspicious. --Juan

Aug. 30, 2010

Re: DIB clarification

by Ken Thomases

On Aug 29, 2010, at 8:49 PM, Jeff Cook wrote: > To clarify, it's not about having secret DIB engine code, it's about > saying "I guess we just won't find time to provide useful feedback > until some company sponsors it...", as I saw several times during the > old threads. What Jeremy neglected to say (although he's made this point before) is that Alexandre has, as a matter of contract, _complete_ independence as Wine maintainer. If, hypothetically, Jeremy wanted to and did "order" Alexandre to slow-walk the DIB engine (or anything else), Alexandre could and would simply ignore him. If Jeremy fired Alexandre for refusing such an order, Alexandre would have excellent grounds to sue CodeWeavers into the ground. Not that either of them is so inclined. As far as Alexandre's famed terseness, you're completely mistaken if you imagine he's any less terse or more forthcoming with us CodeWeavers than he is with any other Wine contributor. In public or behind the scenes. It's just his nature. :) Cheers, Ken

Aug. 30, 2010

Re: DIB clarification

by Roderick Colenbrander

On Sun, Aug 29, 2010 at 2:18 PM, Jeff Cook <jeff(a)deserettechnology.com> wrote: > I hate to stir the pot, especially as an unknown in the community, but > I've spent the last few hours reading WINE's history regarding DIB > engines and it is pretty distressing. > > I have seen expressions of frustration from many regarding the > handling of the mostly-functional DIB engine that Massimo wrote. AJ's > terseness on the issue is puzzling. I find it really weird that such a > major and long-standing thing would just be left to languish without > any detailed reasons. Though I do not believe it, you can start to see > why the slashdotter described Codeweavers' corporate agenda as "evil"; > it almost feels like Codeweavers is holding DIB hostage, just waiting > for someone to get fed up and fork over the cash for it. This wouldn't > be a problem of course if it appeared that Alexandre was willing to > work with external developers on the DIB engine, but he has given very > sparse criticism. > > Should we all just accept that Massimo's engine is yet another DIB > engine gone to waste and there is no future hope for it at all? Max's > statements to that effect can be confusing out of context because of > his non-native English, but everything I have seen indicates that he > is totally willing to work on upstream merging if Alexandre is willing > to cooperate. All cases of saying "it won't get merged" etc. by Max > seem to reference AJ's reluctance to provide useful criticism on the > code that gets posted. > > It is not my intention to start another huge flamewar or thread on the > matter. I just want to promote a reliable roadmap and help resolve > this -- it seems like a total shame that there have been multiple DIB > engines written and no parts of any of them were deemed worthy of > inclusion in WINE. Max at least has indicated a desire to modify the > code as necessary if a useful road map or ideation were provided, so > why is it so hard to get the road map? Alexandre is right that the > architecture is a lot of work, but I am not asking for him to write > out a complete spec, and I don't think the community is, either; the > main thing, as far as I can tell, is that the interaction and feedback > on a major step forward for WINE has been minimal. > > People are still reporting major speedups on bug #421 so I don't think > this is a lost cause unworthy of effort as some suggest. > > The most feedback I was able to find from Alexandre was on May 2009's > DIB engine passing all tests thread at > http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 > . Alexandre's single major standing complaints seem to be a lack of > test cases and Massimo not establishing a good record with simple > patches. Are those still valid reasons? > > The complaint regarding driver loading was addressed, but it sounds > like Alexandre wants it in the opposite direction (forwarding calls > from winex11.drv (or whatever driver) to winedib.drv instead of the > other way around). Is that a very serious problem? > > So, if we can, let's get a few points down on what needs to be > modified for DIB to make it into WINE, even as an experimental branch: > > 1) Write more gdi32 and any other relevant test cases to prove that > the DIB engine is generally well-behaved > 2) Reverse the DIB ordering and call winedib.drv only as needed, > instead of passing everything through winedib.drv first. > 3) ? > > Or, in the case that Max's DIB is gone forever and is considered > irreparable, why don't we discuss what's needed for a different DIB > engine? > > 1) Write more gdi32 and any other relevant test cases to prove that > the DIB engine is generally well-behaved > 2) Works well with any wine display driver. (already in Max's code) > 3) Applied and developed cooperatively and incrementally with the WINE community > 4) Easily disabled / non-disruptive (already in Max's code) > 5) ? What else needs to go here? > > Is this accurate? > > Others mentioned that benchmarks that prove the usefulness of a DIB > engine might help. Do those still need to be performed? > > Thanks for reading. > From > Jeff > Let me give my stance on the DIB engine but before I do that lets give a rough summary what the DIB engine is about because not everyone has a good idea what it is, some people think it is something magical. A DIB(Section) is a type of surface you can draw to using GDI calls but you can also directly mess with its bits. On Windows DIB rendering is all done in software ('using the DIB engine'). In Wine we cheat by delegating most of the work to X11. This causes various challenges and some cause performance issues (though various of them are fixable even without a DIB engine). Two of the challenges: - A copy of the DIB exists on the X-server and in system memory and both copies have to be synced. You don't always want to have them in sync (it might cause unneeded x11->sysmem copies). The syncing is done using memory protection tricks. If the system memory copy is not up to date, a segmentation fault is triggered on access to the bits and during that time the DIB is copied back from the X-server. This causes an issue for some bad applications which directly mess with the stack pointer while they are playing with the DIB. - Depth conversion. When the DIB is at a different color depth (lets say it is 8-bit) than the X-server, the DIB is first converted to the depth of the X-server and afterwards it is converted back. Depending on the color depth this can be a heavy operation (various old games like Age of Empires are quite slow due to this). This used to be a big problem but due to XRender work for Wine, the conversion is not needed anymore for 16-bit/24-bit/32-bit DIBSections. It is still an issue for 8-bit and some other depths but for a big part it can be fixed (Alexandre also said it is more correct if a DIB is 8-bit, to just pass it as 8-bit to X). Do we really need a DIB engine? For a part, 'time' has made the need for a DIB engine less important. Systems have become faster, X11 has become faster, XRender has helped and so on. There are applications which can really profit from a DIB engine but some of them can be made happy by improving the current code (e.g. don't perform color conversion and let X11 work at the depth of the DIB). Personally I think the requirements for a DIB engine have changed and if we add one it should be part of a big Wine 2D rendering rewrite. In previous threads about a Wine quartz/cocoa driver, I mentioned that in Vista/Win7 Microsoft drastically changed their 2D engine and I think we should do something similar. The best way to summarize the changes is that their 'DIB engine' takes care of most tasks of the 'DDB engine'. Except for some common BitBlt ROPs, color filling, font rendering and a few other operations (this are the same calls Cairo/Cocoa/XRender supports) EVERYTHING is software rendered. If we would go the Vista/Win7 way, the DIB engine would be something different from the previously proposed ones. We would move most of our rendering to the shared DIB/DDB engine. The few hw accelerated DDB operations could be implemented using OpenGL/XRender or it could even make sense to use Direct3D. The winex11 driver would implement these DDB options, would handle window management and input. Further it would be a lot easier to write a Cocoa driver for Mac. I'm not sure if we will make such drastic changes at all. It would be a huge project (at least 1 year but likely more) of work. Roderick

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by David Adam

Does not work for me :crying: I voluntary added trailing space to my file. Nothing appears in red. I obtain in white and black testcooperativelevels_normal();ESC[m ESC[32m+ESC[mESC[32m testcooperativelevels_normal_other_ddraw();ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m ESC[32m+ESC[mESC[41m ESC[m releasedirectdraw();ESC[m I use kconsole. Maybe it is the problem ?? Thanks for the advices A+ David 2010/8/30 Octavian Voicu <octavian.voicu(a)gmail.com> > Try running: > > git config --global color.ui auto > > This will activate colorful output for all git commands (in particular > for `git diff' too). > > Then, when you run `git diff' from a terminal you will see whitespace > errors (eg. trailing whitespace) highlighted with a red background. > > Hope it helps, > Octavian >

Aug. 30, 2010

Re: user32: Make GetWindowPlacement() work for other process windows. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)codeweavers.com> writes: > This patch fixes the problem reported in the bug 12001. > > This version of the patch uses an internal message to fetch window state > from a foreign thread. Another aproach could be to store the window state in > the server, but that would require to introduce another server call for it. I'd be surprised if GetWindowPlacement required the other thread to be running a message loop on Windows... -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: [PATCH 04/12] [Server]: enhanced the console input object so that it doesn't require a wineconsole to be running

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > + if (tcgetattr(fd, &term) < 0) fprintf(stderr, "Couldn't get termios\n"); > + console_input->termios = term; > + term.c_lflag &= ~(ECHO | ECHONL | ICANON | IEXTEN); > + term.c_iflag &= ~(BRKINT | ICRNL | INPCK | ISTRIP | IXON); Errors need to be handled properly in the server, you can't just print a message and continue as if nothing happened. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: DIB clarification

by James Mckenzie

Michael Stefaniuc <mstefani(a)redhat.com> wrote: > >Now that "that waive with $$$" isn't very likely as the cost/benefit >ratio isn't very good. More likely is that Codeweavers will start >working on a Quartz driver and that work will make the DIB engine >"cheaper" to implement. Again, this is my *personal* opinion. > I would like to add my *personal* comment to the above. Both the DIB engine and implementing Auqa/Quartz on Wine are HUGE projects that will take a lot of time. Huw Davis (sp?) and Max put a lot of time into the DIB project and according to Tom Wickline, Max is still working on it (see Tom's message on in this thread for more information.) Emmanual Mallard and others put in a lot of time on the Aqua/Quartz implementation without a full implementation and Emmanual (to my knowledge) stopped working on it almost two years ago. These both *appear* to be interlinked as the DIB engine has to be implemented before full functionality is available for Aqua/Quartz will work (these are not my words and this was posted here in the Wine Development List.) My words of caution were misread by others here. I was going to work on the Quartz project based upon work that I had participated in another FOSS project, but after looking it over very carefully, I decided to set it aside and work on other much smaller, bigger bang for the time, projects. One I have been working on for two years and that work had to be abandoned as the implementation was not correct (thank you AJ for pointing this out in very blunt words.) What to do about these two 'features' missing? Maybe CodeWeavers will pick them up (they may already have.) Maybe someone or a team will take them over. I will move onto fixing bugs and missing features that are 'important' to me and leave the rest to others who have more time and ambition. Thank everyone here for your words of encouragement and I will continue to work on the three functions I would like to see implemented that will make some of the 'fixmes' go away. James McKenzie

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 2:11 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Can someone add this here > http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 Added this to the wiki. Can't find a way to create links to sections within the page though; the ids of the sections are regenerated on each save.

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

On Mon, Aug 30, 2010 at 2:11 PM, GOUJON Alexandre <ale.goujon(a)gmail.com> wrote: > Hey, that's pretty cool. > > Can someone add this here > http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 > ? > > Thanks for the tip Octavian ! Well, that's what I love about git the most -- the pretty colored output :P Glad I could help.

Aug. 30, 2010

[PATCH v2] winedbg: gdb proxy mode: support qAttached packet

by Paul Bolle

Add support for the qAttached packet. Main benefit is that gdb now will ask if it should detach from the debuggee if it was attached to a debuggee instead of asking whether the debuggee should be killed. (It still will ask whether the debuggee should be killed if it launched the debuggee itself). Signed-off-by: Paul Bolle <pebolle(a)tiscali.nl> --- On Wed, 2009-11-04 at 21:42 +0100, Eric Pouech wrote: > [...] inclusion in gdbctx is preferred (and storage should rather be an > integer rather than a string pointer) programs/winedbg/gdbproxy.c | 25 +++++++++++++++++++++---- 1 files changed, 21 insertions(+), 4 deletions(-) diff --git a/programs/winedbg/gdbproxy.c b/programs/winedbg/gdbproxy.c index 4f12481..0f5088c 100644 --- a/programs/winedbg/gdbproxy.c +++ b/programs/winedbg/gdbproxy.c @@ -109,6 +109,8 @@ struct gdb_context struct gdb_ctx_Xpoint Xpoints[NUM_XPOINT]; /* Unix environment */ unsigned long wine_segs[3]; /* load addresses of the ELF wine exec segments (text, bss and data) */ + /* attached or launched? */ + int attached; }; static BOOL tgt_process_gdbproxy_read(HANDLE hProcess, const void* addr, @@ -1794,6 +1796,15 @@ static enum packet_return packet_query(struct gdb_context* gdbctx) return packet_done; } break; + case 'A': + /* Since gdb's multiprocess protocol extensions aren't supported, this + * shouldn't be "qAttached:PID", just "qAttached", but check anyway. */ + if (gdbctx->in_packet_len == 8 && strncmp(gdbctx->in_packet, "Attached", 8) == 0) + { + packet_reply(gdbctx, gdbctx->attached ? "1": "0", 1); + return packet_done; + } + break; case 'C': if (gdbctx->in_packet_len == 1) { @@ -2179,6 +2190,7 @@ static int fetch_data(struct gdb_context* gdbctx) #define FLAG_NO_START 1 #define FLAG_WITH_XTERM 2 +#define FLAG_ATTACHED 4 static BOOL gdb_exec(const char* wine_path, unsigned port, unsigned flags) { @@ -2318,6 +2330,7 @@ static BOOL gdb_init_context(struct gdb_context* gdbctx, unsigned flags) gdbctx->in_trap = FALSE; gdbctx->trace = /*GDBPXY_TRC_PACKET | GDBPXY_TRC_COMMAND |*/ GDBPXY_TRC_COMMAND_ERROR | GDBPXY_TRC_COMMAND_FIXME | GDBPXY_TRC_WIN32_EVENT; gdbctx->process = NULL; + gdbctx->attached = (flags & FLAG_ATTACHED) ? 1 : 0; for (i = 0; i < NUM_XPOINT; i++) gdbctx->Xpoints[i].type = -1; for (i = 0; i < sizeof(gdbctx->wine_segs) / sizeof(gdbctx->wine_segs[0]); i++) @@ -2350,6 +2363,7 @@ static int gdb_remote(unsigned flags) struct pollfd pollfd; struct gdb_context gdbctx; BOOL doLoop; + BOOL kill; for (doLoop = gdb_init_context(&gdbctx, flags); doLoop;) { @@ -2365,8 +2379,8 @@ static int gdb_remote(unsigned flags) { if (gdbctx.trace & GDBPXY_TRC_LOWLEVEL) fprintf(stderr, "Gdb hung up\n"); - /* kill also debuggee process - questionnable - */ - detach_debuggee(&gdbctx, TRUE); + kill = (flags & FLAG_ATTACHED) ? FALSE : TRUE; + detach_debuggee(&gdbctx, kill); doLoop = FALSE; break; } @@ -2412,8 +2426,11 @@ int gdb_main(int argc, char* argv[]) } return -1; } - if (dbg_active_attach(argc, argv) == start_ok || - dbg_active_launch(argc, argv) == start_ok) + if (dbg_active_attach(argc, argv) == start_ok) { + gdb_flags |= FLAG_ATTACHED; + return gdb_remote(gdb_flags); + } + else if (dbg_active_launch(argc, argv) == start_ok) return gdb_remote(gdb_flags); #else fprintf(stderr, "GdbProxy mode not supported on this platform\n"); -- 1.7.2.1

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by GOUJON Alexandre

On 08/30/2010 12:34 AM, Octavian Voicu wrote: > Try running: > > git config --global color.ui auto > > This will activate colorful output for all git commands (in particular > for `git diff' too). > > Then, when you run `git diff' from a terminal you will see whitespace > errors (eg. trailing whitespace) highlighted with a red background. > Hey, that's pretty cool. Can someone add this here http://wiki.winehq.org/GitWine#head-b20b05157175835751686365f9818ae978ceca23 ? Thanks for the tip Octavian !

Aug. 30, 2010

Re: msvcrt:locale Properly fix setlocale and clean up tests

by Alexandre Julliard

GOUJON Alexandre <ale.goujon(a)gmail.com> writes: > On 08/30/2010 11:21 AM, Alexandre Julliard wrote: >> Now you are overdoing it. I said to remove broken() for minor spelling >> differences, not for everything. For instance confusing 936 and 950 >> codepages for Chinese is broken, it's not just a spelling difference > Sorry, I'm trying to do my best but >> Not all of them, but those that don't make sense > was too vague so I considered the following as a rule >> are both OK since they both appear on Windows > (appeared on window = ok() ) The whole point of broken() is for things that appear on Windows but are not considered valid. > So, just to be clear > > - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > - || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) > - || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); > + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + || !strcmp(ret, "Chinese_People's Republic of China.936") > + || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); > is correct Yes. > And what about not returned strings e.g. > > - ok(!strcmp(ret, "English_New Zealand.1252") > - || broken(!strcmp(ret, "English_United States.1252")), "ret = %s\n", ret); > + ok(!strcmp(ret, "English_New Zealand.1252"), "ret = %s\n", ret); > > Should I keep them ? (in this case, transform the broken() in ok() ) > Or delete them as I did ? You can't delete them since they appear on Windows (otherwise they wouldn't be marked as broken). And clearly "New Zealand" is not a different spelling of "United States" ;-) so it should remain broken. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: DIB clarification

by Michael Stefaniuc

Jeff Cook wrote: > On Sun, Aug 29, 2010 at 7:12 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >>> This could also help. If I recall correctly, Jeremy White mentioned >>> at Wineconf 2008 that this was a major reason they haven't invested >>> serious energy into one themselves: they had a hard time finding an >>> application that they cared about that benefited significantly from a >>> DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't >>> care about AutoCAD, or whether they hadn't tested with it, or whether >>> my memory is just faulty, I'm not sure. >> Yes, that's essentially right, although note that we did invest some >> fairly serious energy into the DIB engine prior to coming to that conclusion. >> (I remember how pleased Huw was that his benchmarks were 1000 times >> faster, and how displeased he was when it made Powerpoint slower...) >> >> That effort all went into Wine, and I hope and believe that it has >> helped others as they have worked on the DIB engine. >> >> But we don't have any secret stash of DIB engine code to further our >> evil plans for world domination. We rely on our gorgeous femme bots >> and Alexandre's magic 'all' patch for that <grin>. >> > To clarify, it's not about having secret DIB engine code, it's about > saying "I guess we just won't find time to provide useful feedback > until some company sponsors it...", as I saw several times during the > old threads. This is a misunderstanding. Codeweavers figured out that they do not *need* the DIB engine aka it isn't the bottleneck. The estimates to get it implemented/merged where 6-12 man month of "architect level" Wine developer time. A huge time investment for little gain and thus Codeweavers decided to invest their resources in other areas that have a higher return of investment. Now people keep asking about the DIB engine and how to motivate Codeweavers to work on that. I replied to that that in my *personal* opinion they won't do that unsexy and costly work unless somebody is waiving at them with some serious amount of money. That's the standard way in the enterprise world of rising the priority of a bug. But this is my *personal* opinion; I never ever have seen a Codeweavers employee say something like that. And I know Jeremy, he would *love* to get a DIB engine for free, especially as he knows its value in $$$ ;) Now that "that waive with $$$" isn't very likely as the cost/benefit ratio isn't very good. More likely is that Codeweavers will start working on a Quartz driver and that work will make the DIB engine "cheaper" to implement. Again, this is my *personal* opinion. bye michael

Aug. 30, 2010

Re: msvcrt:locale Properly fix setlocale and clean up tests

by GOUJON Alexandre

On 08/30/2010 11:21 AM, Alexandre Julliard wrote: > Now you are overdoing it. I said to remove broken() for minor spelling > differences, not for everything. For instance confusing 936 and 950 > codepages for Chinese is broken, it's not just a spelling difference Sorry, I'm trying to do my best but > Not all of them, but those that don't make sense was too vague so I considered the following as a rule > are both OK since they both appear on Windows (appeared on window = ok() ) So, just to be clear - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") - || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) - || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") + || !strcmp(ret, "Chinese_People's Republic of China.936") + || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); is correct - todo_wine ok(!strcmp(ret, "Chinese (Traditional)_Taiwan.950") - || broken(!strcmp(ret, "Chinese_Taiwan.950")), "ret = %s\n", ret); + ok(!strcmp(ret, "Chinese (Traditional)_Taiwan.950") + || !strcmp(ret, "Chinese_Taiwan.950"), "ret = %s\n", ret); this one too And what about not returned strings e.g. - ok(!strcmp(ret, "English_New Zealand.1252") - || broken(!strcmp(ret, "English_United States.1252")), "ret = %s\n", ret); + ok(!strcmp(ret, "English_New Zealand.1252"), "ret = %s\n", ret); Should I keep them ? (in this case, transform the broken() in ok() ) Or delete them as I did ? Thanks

Aug. 30, 2010

Re: msvcrt:locale Properly fix setlocale and clean up tests

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > I removed all broken() and ran the tests on all WineTestBot machines > (https://testbot.winehq.org/JobDetails.pl?Key=4829) > Then, I cleaned up tests accordingly : removed superflous broken() and extending ok(). > (https://testbot.winehq.org/JobDetails.pl?Key=4831) Now you are overdoing it. I said to remove broken() for minor spelling differences, not for everything. For instance confusing 936 and 950 codepages for Chinese is broken, it's not just a spelling difference. -- Alexandre Julliard julliard(a)winehq.org

Aug. 30, 2010

Re: DIB clarification

by Austin English

On Sun, Aug 29, 2010 at 7:00 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > One additional note: We should, as a project, not accept 'broken' code. I > work with a real-time project and get paid for this that soon will have this > policy in effect. No broken code, it is way to hard to go back and fix it > later. This is one thing I like AJ for. The DIB engine is his one > execption in that he wants it fully implemented and all in one piece. > > Also, Max's code has shown up in another 'for pay' project and where > implementation was done, works. Where implementation is not complete, it is > seriously broken. The problem is where it works and does not work is not > cleanly defined. Lots of 'surprises' and 'gotchas'. > > Anyway, Jeff, please look at Max's code and then ask AJ for specific > guidance on the how to work on this. This is a MAJOR part of the project > that needs to be implemented. Don't feel insulted when you get reject after > reject from AJ. As specific questions, and he does give answers. If he > states "it's broken" he wants you to figure it out and the brokenness is > very obvious. Yes, I've had patches rejected by him and that is all he > said. I figured out the brokenness and fixed it. I've had to back off the > patch as it used code that was rejected and now I know why. James, I hate to be blunt, but you've been repeatedly told to stop giving advice while implying that you are a senior wine developer with lots of experience on the project. I've seen several (potential) new contributors take your advice, submit patches based on it, then have to rework a lot of it based on faulty advice. Lots of people on wine-devel aren't wine developers, or contribute infrequently, but still give good advice, based on what they know and their experience. However, giving authoritative answers when you lack that authority/experience is damaging not only to those contributors, but to wine as a whole. I think http://www.winehq.org/pipermail/wine-devel/2010-July/085495.html sums it up very nicely. /rant -- -Austin

Aug. 30, 2010

Re: DIB clarification

by Tom Wickline

On Mon, Aug 30, 2010 at 8:00 AM, James McKenzie <jjmckenzie51(a)earthlink.net>wrote: > > Also, Max's code has shown up in another 'for pay' project and where > implementation was done, works. Where implementation is not complete, it is > seriously broken. The problem is where it works and does not work is not > cleanly defined. Lots of 'surprises' and 'gotchas'. > > Hello, Max's DIB Engine is built into Bordeaux : http://www.bordeauxgroup.com/mostly for nontechnical people who want to test Max's work in progress. The DIB Engine is turned off by default and unsupported apps can only be installed via the command line at this time. As for CodeWeavers... They are some of the nicest people you will ever meet in your life, not to mention some of the brightest people on this planet. Jeremy did whoever offer to buy the "evil empire" last year for $1 down and the rest payed from future profits if memory serves me right. I'm not sure if Ballmer ever got back to them on the offer. :) See : http://www.codeweavers.com/about/general/press/20090724/ I think my sig pretty much says everything else.. Cheers, Tom -- Wine is not a conclusion but a process...

Aug. 30, 2010

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

by Vitaliy Margolen

On 08/29/2010 12:43 AM, Jeff Cook wrote: > 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. strlen returns number of characters without terminating \0. If you using memcpy to copy strings you must add additional byte (if destination is big enough). Or explicitly zero terminate the destination string (if result was truncated). What you really want is a strlcpy() which unfortunately not present on all platforms. And don't even think using strncpy - it's the worst string function ever made. Just the fact that you copied the exact code doesn't automatically make it correct. Vitaliy.

Aug. 30, 2010

Re: DIB clarification

by Jeff Cook

On Sun, Aug 29, 2010 at 7:12 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: >> This could also help. If I recall correctly, Jeremy White mentioned >> at Wineconf 2008 that this was a major reason they haven't invested >> serious energy into one themselves: they had a hard time finding an >> application that they cared about that benefited significantly from a >> DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't >> care about AutoCAD, or whether they hadn't tested with it, or whether >> my memory is just faulty, I'm not sure. > > Yes, that's essentially right, although note that we did invest some > fairly serious energy into the DIB engine prior to coming to that conclusion. > (I remember how pleased Huw was that his benchmarks were 1000 times > faster, and how displeased he was when it made Powerpoint slower...) > > That effort all went into Wine, and I hope and believe that it has > helped others as they have worked on the DIB engine. > > But we don't have any secret stash of DIB engine code to further our > evil plans for world domination. We rely on our gorgeous femme bots > and Alexandre's magic 'all' patch for that <grin>. > > Cheers, > > Jeremy > To clarify, it's not about having secret DIB engine code, it's about saying "I guess we just won't find time to provide useful feedback until some company sponsors it...", as I saw several times during the old threads. From Jeff

Aug. 30, 2010

Re: DIB clarification

by Jeremy White

> This could also help. If I recall correctly, Jeremy White mentioned > at Wineconf 2008 that this was a major reason they haven't invested > serious energy into one themselves: they had a hard time finding an > application that they cared about that benefited significantly from a > DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't > care about AutoCAD, or whether they hadn't tested with it, or whether > my memory is just faulty, I'm not sure. Yes, that's essentially right, although note that we did invest some fairly serious energy into the DIB engine prior to coming to that conclusion. (I remember how pleased Huw was that his benchmarks were 1000 times faster, and how displeased he was when it made Powerpoint slower...) That effort all went into Wine, and I hope and believe that it has helped others as they have worked on the DIB engine. But we don't have any secret stash of DIB engine code to further our evil plans for world domination. We rely on our gorgeous femme bots and Alexandre's magic 'all' patch for that <grin>. Cheers, Jeremy

Aug. 30, 2010

Re: DIB clarification

by James McKenzie

Juan Lang wrote: > Hi Jeff, > > this has in fact come up before, and been addressed. The main problem > with the current attempt, as far as I know, is that the risk of > regressions is so high that only very high quality changes stand any > chance of getting accepted. In the case of a DIB engine, the attempts > have usually required accepting a large piece of new code wholesale, > with a promise of future fixes. This is a very risky way to make a > change, and Alexandre has repeatedly shown his preference for small, > incremental changes wherever possible. > > Juan and others: One additional note: We should, as a project, not accept 'broken' code. I work with a real-time project and get paid for this that soon will have this policy in effect. No broken code, it is way to hard to go back and fix it later. This is one thing I like AJ for. The DIB engine is his one execption in that he wants it fully implemented and all in one piece. Also, Max's code has shown up in another 'for pay' project and where implementation was done, works. Where implementation is not complete, it is seriously broken. The problem is where it works and does not work is not cleanly defined. Lots of 'surprises' and 'gotchas'. Anyway, Jeff, please look at Max's code and then ask AJ for specific guidance on the how to work on this. This is a MAJOR part of the project that needs to be implemented. Don't feel insulted when you get reject after reject from AJ. As specific questions, and he does give answers. If he states "it's broken" he wants you to figure it out and the brokenness is very obvious. Yes, I've had patches rejected by him and that is all he said. I figured out the brokenness and fixed it. I've had to back off the patch as it used code that was rejected and now I know why. James McKenzie

Aug. 30, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by James McKenzie

Octavian Voicu wrote: > Try running: > > git config --global color.ui auto > > This will activate colorful output for all git commands (in particular > for `git diff' too). > > Then, when you run `git diff' from a terminal you will see whitespace > errors (eg. trailing whitespace) highlighted with a red background. > I've got to try that. Thanks Octavian. James McKenzie

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by James McKenzie

David Adam wrote: Looks like you are trying very hard to avoid the [try 4] moniker. Please add this to each version of the patch you are submitting. Use the notes feature of git commit to put in why you are submitting a new try. Second, if the patch will NOT apply due to whitespace issues, it will NOT be approved. Please read the Wiki page on Patches. Third, it really appears that you are avoiding the friendly advise given here. We are trying to help you prevent resubmit and then another resubmit for the same problem. You have already aggravated one reviewer that has attempted to help you get this patch accepted. James McKenzie

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Octavian Voicu

Try running: git config --global color.ui auto This will activate colorful output for all git commands (in particular for `git diff' too). Then, when you run `git diff' from a terminal you will see whitespace errors (eg. trailing whitespace) highlighted with a red background. Hope it helps, Octavian

Aug. 29, 2010

Re: DIB clarification

by Juan Lang

Hi Jeff, this has in fact come up before, and been addressed. The main problem with the current attempt, as far as I know, is that the risk of regressions is so high that only very high quality changes stand any chance of getting accepted. In the case of a DIB engine, the attempts have usually required accepting a large piece of new code wholesale, with a promise of future fixes. This is a very risky way to make a change, and Alexandre has repeatedly shown his preference for small, incremental changes wherever possible. Without knowing the area in depth, I can only offer this commentary on Massimo's work: Massimo doesn't have a proven track record in the community, so I personally wouldn't trust his ability to minimize regressions, or to maintain his code until regressions he's caused have been fixed. This is nothing to do with him personally, I'd have the same expectations of any relatively new contributor. As to the first, minimizing regressions, this is something a new developer can address by testing an area thoroughly. Often, the best path forward for new code is to introduce substantial new tests in the area before beginning to make functional changes. > I hate to stir the pot, especially as an unknown in the community, but > I've spent the last few hours reading WINE's history regarding DIB > engines and it is pretty distressing. If you hate to do it, why do you do it? It's hard to maintain equanimity when you describe CodeWeavers as evil. Even if you do ascribe that to someone else, why on earth do you bother to repeat it? Such a sentiment is so absurd, it could best be accepted as a joke, but a bad one. Think about it: who has contributed the most, in real dollars, to Wine's development over time? Who releases their own Wine tree in source form? Who employs the most Wine contributors? Just because some pissed off slashdotter said something doesn't make it worthy of a second's thought. Full disclosure: I once did a very small amount of contract work for CodeWeavers, approximately 6 years ago. > AJ's terseness on the issue is puzzling. I find it really weird that such a > major and long-standing thing would just be left to languish without > any detailed reasons. Though I do not believe it, you can start to see > why the slashdotter described Codeweavers' corporate agenda as "evil"; Maybe to you, because you're new around here. When has Alexandre ever been long-winded? He's terse here just as he is elsewhere. If there is any single reason to reject a piece of code, that's enough. See e.g. Henri's comment on a patch the other day [1]: when we give negative feedback on a patch here, we usually don't point out every instance of an error, and expect the contributor to generalize from the feedback. Hence negative feedback here is usually terse. > it almost feels like Codeweavers is holding DIB hostage, just waiting > for someone to get fed up and fork over the cash for it. You can only hold hostage something that exists. There is no such beast as a working DIB engine. > . Alexandre's single major standing complaints seem to be a lack of > test cases and Massimo not establishing a good record with simple > patches. Are those still valid reasons? Yes, of course they are. That's a valid reason for rejection of simple patches. Why shouldn't it be for major, high-risk-of-regression patches? > 1) Write more gdi32 and any other relevant test cases to prove that > the DIB engine is generally well-behaved Yes, this is certainly needed. > Others mentioned that benchmarks that prove the usefulness of a DIB > engine might help. Do those still need to be performed? This could also help. If I recall correctly, Jeremy White mentioned at Wineconf 2008 that this was a major reason they haven't invested serious energy into one themselves: they had a hard time finding an application that they cared about that benefited significantly from a DIB engine. Usually, bottlenecks were elsewhere. Whether they didn't care about AutoCAD, or whether they hadn't tested with it, or whether my memory is just faulty, I'm not sure. Hope that helps, --Juan [1] http://www.winehq.org/pipermail/wine-devel/2010-August/086207.html

Aug. 29, 2010

Re: ddraw [patch 1/2]: SetCooperativeLevels with Normal+Fullscreen+Exclusive mode is authorized

by Henri Verbeet

On 29 August 2010 20:45, David Adam <david.adam.cnrs(a)gmail.com> wrote: > - You clearly ignored my previous comments about trailing spaces. - This patch changes a lot more things than just allowing DDSCL_NORMAL | DDSCL_FULLSCREEN. E.g. the call to IWineD3DDevice_AcquireFocusWindow(). - Still needs more tests. For example, is the whole wndproc replacement stuff a property of DDSCL_EXCLUSIVE or a property of DDSCL_FULLSCREEN? - I'm not going to look at or comment on any patch with basic whitespace issues anymore.

Aug. 29, 2010

Re: ddraw [patch 2/2]: Add more combinaison tests for SetCooperativeLevels

by testbot＠testbot.winehq.org

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=4844 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Aug. 29, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by Mariusz Pluciński

W dniu 29.08.2010 18:33, Octavian Voicu pisze: > 2010/8/29 Mariusz Pluciński<vshader(a)gmail.com>: >> Could you tell me is there proper way to tell make to track changes in my >> custom file? Expected effect is running wrc while build if there was >> modification in my .gdf.xml file (currently, it is started only if .rc file >> was modified). Of course, Makefiles in Wine are auto-generated, so the >> solution would add code only to Makefile.in file. > > You need to add a @makedep directive in gameux/tests/rsrc.rc: > > /* @makedep: test.gdf.xml */ > ID_GDF_XML DATA "test.gdf.xml" > > This should include test.gdf.xml as a dependency for rsrc.res in the > automatically generated Makefile. See dlls/cards/cards.rc for more > examples. > > Octavian > Thanks Octavian, it works exactly as I expected.

Aug. 29, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by Octavian Voicu

2010/8/29 Mariusz Pluciński <vshader(a)gmail.com>: > Could you tell me is there proper way to tell make to track changes in my > custom file? Expected effect is running wrc while build if there was > modification in my .gdf.xml file (currently, it is started only if .rc file > was modified). Of course, Makefiles in Wine are auto-generated, so the > solution would add code only to Makefile.in file. You need to add a @makedep directive in gameux/tests/rsrc.rc: /* @makedep: test.gdf.xml */ ID_GDF_XML DATA "test.gdf.xml" This should include test.gdf.xml as a dependency for rsrc.res in the automatically generated Makefile. See dlls/cards/cards.rc for more examples. Octavian

Aug. 29, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by Mariusz Pluciński

W dniu 26.08.2010 18:34, (Marvin) pisze: > 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=4793 > > Your paranoid android. > > > === W7PRO (32 bit gameexplorer) === > gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) > gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) > > === W7PROX64 (32 bit gameexplorer) === > gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) > gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) > > === W7PROX64 (64 bit gameexplorer) === > gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) > gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) > It seems that test bot did not rebuild the .gdf.xml file which I attached as resource (I don't see call of wrc in WINEBUILD log). I also notified similar behavior on my machine. It is because there's no rule in Makefile which depends on this file. Could you tell me is there proper way to tell make to track changes in my custom file? Expected effect is running wrc while build if there was modification in my .gdf.xml file (currently, it is started only if .rc file was modified). Of course, Makefiles in Wine are auto-generated, so the solution would add code only to Makefile.in file.

Aug. 29, 2010

Re: HEAP and FarCry installer

by Henri Verbeet

2010/8/29 <wylda(a)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? > Yeah, that looks like a bug, but from the log it's not clear that it isn't just the application doing that. A good start would be to check to what module the "ret" addresses for both the HeapAlloc() and the HeapFree() (7dfef944 and 7dfefa1e in the log) belong. If that's the application or one of its dlls it's likely just an application bug, if on the other hand it's a Wine dll (e.g. msi) that's where you should be looking.

Aug. 29, 2010

Re: d3d9 equivalent of D3DXFVFFromDeclarator?

by Henri Verbeet

On 28 August 2010 23:35, Misha Koshelev <misha680(a)gmail.com> wrote: > 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. > Possibly. If you look at the tests in (d3d9) test_fvf_decl_conversion() you'll see that only the first two declarations return anything other than 0 (D3DFVF_XYZ and D3DFVF_XYZRHW), and those are marked as todo_wine. This is "implemented" by vertexdeclaration_init() *not* setting convFVF, and IDirect3DDevice9Impl_GetFVF() returning "decl->convFVF" when a vertex declaration is set. So declarations created by the application will always have 0 for FVF, while the ones created by getConvertedDecl() will have a non-zero FVF associated. It may well be the case that the test is simply flawed; I wouldn't call any of the declarations that return a 0 FVF reasonable. Most of them don't include position data, and the ones that do can't be expressed as an FVF at all. Nevertheless, the simple fact is that d3d9 doesn't currently implement conversion of vertex declarations to FVFs.

Aug. 29, 2010

Re: DIB clarification

by Jesse Allen

On Sun, Aug 29, 2010 at 6:18 AM, Jeff Cook <jeff(a)deserettechnology.com> wrote: > Alexandre is right that the > architecture is a lot of work, but I am not asking for him to write > out a complete spec, and I don't think the community is, either; the > main thing, as far as I can tell, is that the interaction and feedback > on a major step forward for WINE has been minimal. I know it seems frustrating of the lack of response. When I went through the summer of code, the most I got from Alexandre was, 'it doesn't work'. Well what doesn't work? And the honest answer from my own assessment was my engine wasn't finished--which is why I didn't push for a merge then. The school I went to required too much time for me to continue the work, so I put it on hold. That is when Max came in. He found that the code was useful for speeding up his AutoCad. And with the work he has done since then, others have found it useful. So it is not a waste. > > The most feedback I was able to find from Alexandre was on May 2009's > DIB engine passing all tests thread at > http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 > . Alexandre's single major standing complaints seem to be a lack of > test cases and Massimo not establishing a good record with simple > patches. Are those still valid reasons? > Yes, very much so. The thread shows that there are problems exhibited by the engine which there are no test case for. So passing all tests that have been previously provided are not enough. That would be an area where simple patches can be done. The dib engine 'blob' outside of the tree might be a maintenance issue for someone with the lack of time, and will be very hard to review. So something else will have to be done to get it mainline, if we ignore the implementation choice at the moment. But certainly not all is lost. We now know more than we did before. Jesse

Aug. 29, 2010

DIB clarification

by Jeff Cook

I hate to stir the pot, especially as an unknown in the community, but I've spent the last few hours reading WINE's history regarding DIB engines and it is pretty distressing. I have seen expressions of frustration from many regarding the handling of the mostly-functional DIB engine that Massimo wrote. AJ's terseness on the issue is puzzling. I find it really weird that such a major and long-standing thing would just be left to languish without any detailed reasons. Though I do not believe it, you can start to see why the slashdotter described Codeweavers' corporate agenda as "evil"; it almost feels like Codeweavers is holding DIB hostage, just waiting for someone to get fed up and fork over the cash for it. This wouldn't be a problem of course if it appeared that Alexandre was willing to work with external developers on the DIB engine, but he has given very sparse criticism. Should we all just accept that Massimo's engine is yet another DIB engine gone to waste and there is no future hope for it at all? Max's statements to that effect can be confusing out of context because of his non-native English, but everything I have seen indicates that he is totally willing to work on upstream merging if Alexandre is willing to cooperate. All cases of saying "it won't get merged" etc. by Max seem to reference AJ's reluctance to provide useful criticism on the code that gets posted. It is not my intention to start another huge flamewar or thread on the matter. I just want to promote a reliable roadmap and help resolve this -- it seems like a total shame that there have been multiple DIB engines written and no parts of any of them were deemed worthy of inclusion in WINE. Max at least has indicated a desire to modify the code as necessary if a useful road map or ideation were provided, so why is it so hard to get the road map? Alexandre is right that the architecture is a lot of work, but I am not asking for him to write out a complete spec, and I don't think the community is, either; the main thing, as far as I can tell, is that the interaction and feedback on a major step forward for WINE has been minimal. People are still reporting major speedups on bug #421 so I don't think this is a lost cause unworthy of effort as some suggest. The most feedback I was able to find from Alexandre was on May 2009's DIB engine passing all tests thread at http://www.winehq.org/pipermail/wine-devel/2009-May/thread.html#75864 . Alexandre's single major standing complaints seem to be a lack of test cases and Massimo not establishing a good record with simple patches. Are those still valid reasons? The complaint regarding driver loading was addressed, but it sounds like Alexandre wants it in the opposite direction (forwarding calls from winex11.drv (or whatever driver) to winedib.drv instead of the other way around). Is that a very serious problem? So, if we can, let's get a few points down on what needs to be modified for DIB to make it into WINE, even as an experimental branch: 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Reverse the DIB ordering and call winedib.drv only as needed, instead of passing everything through winedib.drv first. 3) ? Or, in the case that Max's DIB is gone forever and is considered irreparable, why don't we discuss what's needed for a different DIB engine? 1) Write more gdi32 and any other relevant test cases to prove that the DIB engine is generally well-behaved 2) Works well with any wine display driver. (already in Max's code) 3) Applied and developed cooperatively and incrementally with the WINE community 4) Easily disabled / non-disruptive (already in Max's code) 5) ? What else needs to go here? Is this accurate? Others mentioned that benchmarks that prove the usefulness of a DIB engine might help. Do those still need to be performed? Thanks for reading. From Jeff

Aug. 29, 2010

Re: msvcrt:string Avoid size_t in ok()

by GOUJON Alexandre

On 08/29/2010 02:36 AM, James McKenzie wrote: > 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 > Sorry for the typo, I guess I wrote it too fast. And no problem, I'll send a try2.

Aug. 29, 2010

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. 29, 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. 29, 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. 29, 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. 29, 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. 29, 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. 28, 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. 28, 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

Re: msvcrt:locale Properly fix setlocale()

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > @@ -431,7 +431,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "non"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > + ok((!strcmp( ret, "Norwegian-Nynorsk_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmål)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")), "ret = %s\n", ret); > @@ -453,7 +453,7 @@ static void test_setlocale(void) > ret = setlocale(LC_ALL, "norwegian-nynorsk"); > ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); > if(ret) > - todo_wine ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > + ok(!strcmp(ret, "Norwegian-Nynorsk_Norway.1252") > || broken(!strcmp(ret, "Norwegian_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Nynorsk)_Norway.1252")) > || broken(!strcmp(ret, "Norwegian (Bokmal)_Norway.1252")) I don't think it makes sense to declare minor spelling differences as broken, or to change the kernel resources for this. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by sudemon

On 27.08.2010 18:47, Henri Verbeet wrote: > 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually does, does the > attached patch make any difference for you? Thanks, patch solved the problem.

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by wylda＠volny.cz

> Actually, looking a bit at what > 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually > does, does the attached patch make any difference for you? Yes! :-D For crashing tested on: Warcarft 3, 3DMark 2001 SE, Harbinger For HEAP corruption tested on: Demoscene debris 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. Thank you for quick analysis and patch. W.

Aug. 27, 2010

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

by Alexandre Julliard

Octavian Voicu <octavian.voicu(a)gmail.com> writes: > The reason for which I opted for a BYTE* is so that I can use sizeof() > to increment the pointer correctly. DWORD_PTR has a different size of > 32- and 64-bit systems, so using DWORD* would make it more complicated > to increment with sizeof(DWORD_PTR). Another reason is that offset is > now in bytes, so supplying a pointer of different size wouldn't make > much sense. There's no reason to change this. Just work with DWORDs throughout, it will avoid a lot of ugly casts. -- Alexandre Julliard julliard(a)winehq.org

Aug. 27, 2010

Re: Try 4: SetCooperative Levels with Normal+Fullscreen+Exclusive is authorized

by Henri Verbeet

On 27 August 2010 11:05, paulo lesgaz <jeremielapuree(a)yahoo.fr> wrote: > I modified my patch to follow Henri's and Stefan's requests and hints. Do > you have more observations to do with this one? > Not exactly a new one, but you still have whitespace errors.

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by Henri Verbeet

On 27 August 2010 14:33, Henri Verbeet <hverbeet(a)gmail.com> wrote: > clearly outside that range. At first sight I'd say there's an error in > the calculation for "mixdev[mixnum].chans" somewhere, that's what > ultimately determines the size of the block that's allocated above, > and should correspond to the number of lines filled in filllines(), 16 > in the log you attached. > Actually, looking a bit at what 6120d7cc14522983fbc38026ab4fcb6e4a68cdf0 actually does, does the attached patch make any difference for you?

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by Henri Verbeet

On 27 August 2010 14:04, <wylda(a)volny.cz> wrote: > > Also from log previously attached, following string is written to > address out of this word, isn't? Look like some return address than > HEAP, right? > > 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,0021cac8 > "HDA NVidia",ffffffff,7dfc9ee4,00000020) ret=7dfb2ae4 > 0009:Ret KERNEL32.MultiByteToWideChar() retval=0000000b > ret=7dfb2ae4 > Well, it would be this one: > 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18 "Digital",ffffffff,004e3044,00000020) ret=7dfb268b > 0009:Ret KERNEL32.MultiByteToWideChar() retval=00000008 ret=7dfb268b > 0009:Call ntdll.RtlAllocateHeap(00110000,00000008,000004ec) ret=7dfb31c2 > 0009:Ret ntdll.RtlAllocateHeap() retval=004e2b58 ret=7dfb31c2 This allocates 0x4ec bytes at 0x4e2b58, so that's 0x4e2b58 -> 0x4e3044. MultiByteToWideChar() writing 0x20 wide chars at 0x4e3044 is clearly outside that range. At first sight I'd say there's an error in the calculation for "mixdev[mixnum].chans" somewhere, that's what ultimately determines the size of the block that's allocated above, and should correspond to the number of lines filled in filllines(), 16 in the log you attached.

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by wylda＠volny.cz

Also from log previously attached, following string is written to address out of this word, isn't? Look like some return address than HEAP, right? 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,0021cac8 "HDA NVidia",ffffffff,7dfc9ee4,00000020) ret=7dfb2ae4 0009:Ret KERNEL32.MultiByteToWideChar() retval=0000000b ret=7dfb2ae4

Aug. 27, 2010

Re: Help with 6120d7cc145, causing bugs

by wylda＠volny.cz

> > There have been a few bug reports... > http://bugs.winehq.org/show_bug.cgi?id=23902 and > http://bugs.winehq.org/show_bug.cgi?id=24131 . > > It seems that in some relatively rare sound > setups, an inappropriate sound element gets fed in to > filllines_no_master which leads to a crash on audio initialize. Hi, i put eyes & fingers into a code, which is bad. People like me, should never do such things, but it just shows my desperateness around this problem. Am i correct when saying: HEAP is allocated begining at 0x004e2b58 and 1260bytes long: 0009:Call ntdll.RtlAllocateHeap(00110000,00000008,000004ec) ret=7dfb31c2 0009:Ret ntdll.RtlAllocateHeap() retval=004e2b58 ret=7dfb31c2 so HEAP ends up at 0x004E3043 followed by 12 "safety bytes" (starting at 0x004e3044), because i run the app with WINEDEBUG=warn+heap. This allocation is shortly followed and used by: 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d5807e8 "Headphone",ffffffff,004e2b58,00000020) ret=7dfb2382 0009:Ret KERNEL32.MultiByteToWideChar() retval=0000000a ret=7dfb2382 ... 0009:Call KERNEL32.MultiByteToWideChar(0000fdf2,00000000,7d6d8b18 "Digital",ffffffff,004e3044,00000020) ret=7dfb268b 0009:Ret KERNEL32.MultiByteToWideChar() retval=00000008 ret=7dfb268b So this "D" is written to a place (0x004e3044), where it shouldn't be ("safety bytes"). At the end of application run, the wine complains: 0009:Call ntdll.RtlFreeHeap(00110000,00000000,004e2b58) ret=7dfb3778 err:heap:HEAP_ValidateInUseArena Heap 0x110000: block 0x4e2b58 tail overwritten at 0x4e3044 (byte 0/12 == 0x44) And this 0x44 stands for "D" from ascii? Mentioned address 0x4e2b58 appears only in the begining (allocation) and at the end (free). Is this helpful somehow? What should i do something next? Thanks in advance for any help. Longer log attached. W.

Aug. 27, 2010

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

by Octavian Voicu

Same here. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 3:12 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 2:15 PM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > I just looked in mmddk.h and they have this: > > #ifdef _WIN64 > #define MCI_INTEGER64 13 > #endif // _WIN64 > > Which is really funny, because I wrote that patch without knowing > anything about that. Gonna take a look at resources inside a 64-bit > winmm.dll and report back, but it is pretty obvious what I'll find -- > they wouldn't define MCI_INTEGER64 for nothing. I can confirm it, the 64-bit dll uses MCI_INTEGER64 (0x0000000D), while the 32-bit one uses MCI_INTEGER. Maybe we should also have #ifdefs in mmddk.h and winmm_res.rc. So, do you want to fix your patches and send them, or do you want me to continue working on this patch set? You should also send the mciParser test (btw, I tested my patch set with your extra tests and they all pass). Octavian

Aug. 27, 2010

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

by Octavian Voicu

For some reason I forgot to hit reply to all. ---------- Forwarded message ---------- From: Octavian Voicu <octavian.voicu(a)gmail.com> Date: Thu, Aug 26, 2010 at 2:15 PM Subject: Re: [PATCH 1/3] winmm: Fix mciSendString command parsing on 64-bit. To: Joerg-Cyril.Hoehle(a)t-systems.com On Thu, Aug 26, 2010 at 1:11 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 > and the partial patch and additional test cases there? First of all, I wasn't aware of it, so thanks for pointing it out. I just saw the crash on my system and tried to fix it; to my shame, I didn't search wine bug database. Sorry for the duplicate work. >>winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >>+#define MCI_INTEGER_PTR 13 > What kind of testing did you perform on native systems to derive the existence of this value? > If such value does not exist, then I fear your patch set looses the ability to > drop in native dlls for compatibility testing and validation. > If it exists, then it's good news you found it. The only testing I ran is winmm:mci tests. With my patch set, 27 tests fail on 64 bit (compared to 23 on 32bit). I'm guessing the 4 extra failures are in other parts of the code. Not sure about TODOs, as I had no tests marked as TODO when I ran the tests from command line (the 23 tests that also fail on 32-bit are definitely marked as TODOs on test.winehq.org) 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. MCI_GetDWord, MCI_GetString, MCI_ParseOptArgs, MCI_HandleReturnValues, the functions which I modified, are explicitly listed as internal functions. I just looked in mmddk.h and they have this: #ifdef _WIN64 #define MCI_INTEGER64 13 #endif // _WIN64 Which is really funny, because I wrote that patch without knowing anything about that. Gonna take a look at resources inside a 64-bit winmm.dll and report back, but it is pretty obvious what I'll find -- they wouldn't define MCI_INTEGER64 for nothing. >>-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >>+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >>- if (!MCI_GetDWord(&(data[offset+0]), &args) || >>- !MCI_GetDWord(&(data[offset+1]), &args) || >>- !MCI_GetDWord(&(data[offset+2]), &args) || >>- !MCI_GetDWord(&(data[offset+3]), &args)) { >>+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >>+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { > > The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, > they are DWORD with some DWORD_PTR in between. > Wouldn't using DWORD* data help avoid such pointer arithmetic > and eliminate several hunks of the patch ? The reason for which I opted for a BYTE* is so that I can use sizeof() to increment the pointer correctly. DWORD_PTR has a different size of 32- and 64-bit systems, so using DWORD* would make it more complicated to increment with sizeof(DWORD_PTR). Another reason is that offset is now in bytes, so supplying a pointer of different size wouldn't make much sense. Argument type in MCI_GetDWord and MCI_GetString was changed for consistency, it wouldn't matter very much there. For the same reason I changed all the &data[offset] into data+offset. In any case, using the MCI_XYZ_PARMS union looks much better :) Maybe also stick MCI_GENERIC_PARMS in there.

Aug. 27, 2010

Re: Any idea how to solve that ?

by GOUJON Alexandre

On 08/27/2010 09:53 AM, GOUJON Alexandre wrote: > Hi, > > No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale > on wine] mail. > So I'm asking again if someone has an idea. > If solved, msvcrt:locale test on wine will pass without any error. > > The situation is the following : > setlocale(LC_ALL, "esn"); > > ok(!strcmp(ret, "Spanish_Spain.1252") > > setlocale(LC_ALL, "spanish-modern"); > > ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") > > with > static const char * const _country_synonyms[] = > { ... "spanish-modern", "esn" } > -> this has to be changed since above tests prove they're not the same > > I submitted a job for the WineTestBot for finding what esX '=' Spanish > - Modern Sort_Spain.1252 > And the result is : none. > > So, should I create another esX ? > What template for this new one ? > Another idea ? > > Each todo_wine we remove may resolve (or prevent) bugs. Well, in fact MSDN was right : spanish-modern '=' esn except some W98 and NT4. According to the test https://testbot.winehq.org/JobDetails.pl?Key=4821 the ok() is in fact a broken() and the broken() ... So the (wine msvcrt:locale) code is already right. Cool !

Aug. 27, 2010

Try 4: SetCooperative Levels with Normal+Fullscreen+Exclusive is authorized

by paulo lesgaz

Hello, I modified my patch to follow Henri's and Stefan's requests and hints. Do you have more observations to do with this one? As previously, all the tests go on passing. A+ David

Aug. 27, 2010

Re: [1/5] msi/tests: Use a different product code in the package tests to avoid cascading test failures.

by testbot＠testbot.winehq.org

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=4818 Your paranoid android. === W7PROX64 (64 bit package) === package.c:8385: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8396: Test failed: Expected "C:\winetest\", got "" package.c:8407: Test failed: Expected "C:\winetest\", got "" package.c:8457: Test failed: Expected "C:\winetest\FileName3.dll", got "" package.c:8468: Test failed: Expected "C:\winetest\FileName5.dll", got "" package.c:8477: Test failed: Expected "C:\", got "" package.c:8483: Test failed: Expected "C:\winetest\", got "" package.c:8504: Test failed: Expected "C:\winetest\FileName1", got "" package.c:8513: Test failed: Expected "C:\winetest\FileName1", got ""

Aug. 27, 2010

Re: kernel32: add error text for WSAECONNREFUSED

by Dmitry Timoshkov

Dan Kegel <dank(a)kegel.com> wrote: > This gets Pando-based installers further, see > http://bugs.winehq.org/show_bug.cgi?id=24019 > > There's obviously more to do here, but this little bit is useful. Please simultaneously add it to all other language files. -- Dmitry.

Aug. 27, 2010

Re: windowscodecs: support ICO files with embedded PNGs

by Damjan Jovanovic

If this patch isn't accepted then the winemenubuilder ones shouldn't be either. PNG is typically used to compress the largest icon in the ICO file, and the largest icon is the one winemenubuilder will extracts to be used during the +/- 1 minute delay in Gnome before a menu item starts having the best-sized icon, so with the winemenubuilder patches and without this one some icons will regress to showing nothing initially. IWICStream::InitializeFromIStreamRegion can always come later. The read loop is thus temporary, and a 256x256 PNG (the largest size ICO supports) cannot take up more than 256*256*4 bytes = 256 kB, so the memory usage with this patch is not a concern. On Fri, Aug 27, 2010 at 7:42 AM, Vincent Povirk <madewokherd(a)gmail.com>wrote: > You mean you're not going to implement > IWICStream::InitializeFromIStreamRegion? That's no fun. > > Also, that read loop is a bit silly. You might as well just lock the > HGLOBAL and read into it directly. > > On Fri, Aug 27, 2010 at 12:30 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> > wrote: > > Changelog: > > * windowscodecs: support ICO files with embedded PNGs > > Closes #23708. > > Damjan Jovanovic > > > > > > > > > > >

Aug. 27, 2010

Any idea how to solve that ?

by GOUJON Alexandre

Hi, No one have replied for my ["Spanish - Modern Sort_Spain.1252" locale on wine] mail. So I'm asking again if someone has an idea. If solved, msvcrt:locale test on wine will pass without any error. The situation is the following : setlocale(LC_ALL, "esn"); > ok(!strcmp(ret, "Spanish_Spain.1252") setlocale(LC_ALL, "spanish-modern"); > ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") with static const char * const _country_synonyms[] = { ... "spanish-modern", "esn" } -> this has to be changed since above tests prove they're not the same I submitted a job for the WineTestBot for finding what esX '=' Spanish - Modern Sort_Spain.1252 And the result is : none. So, should I create another esX ? What template for this new one ? Another idea ? Each todo_wine we remove may resolve (or prevent) bugs.

Aug. 27, 2010

Re: windowscodecs: support ICO files with embedded PNGs

by Vincent Povirk

You mean you're not going to implement IWICStream::InitializeFromIStreamRegion? That's no fun. Also, that read loop is a bit silly. You might as well just lock the HGLOBAL and read into it directly. On Fri, Aug 27, 2010 at 12:30 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > Changelog: > * windowscodecs: support ICO files with embedded PNGs > Closes #23708. > Damjan Jovanovic > > > >

Aug. 27, 2010

Re: mpr: Fix translations

by James McKenzie

Amine Khaldi wrote: [nothing] Can you please put some sort of tracking information when resubmitting a patch like [try2]. This will keep those of us who are manually tracking and applying your fixes in sync. Thank you. James McKenzie

Aug. 27, 2010

Re: RFC: Resolving a full screen bug

by Erich Hoover

On Thu, Aug 26, 2010 at 2:02 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > ... > It's not correct, the iconic flag is supposed to reflect the state that > we have asked from X. What is the exact sequence that leads to the > window remaining iconified? I figured this still wasn't quite right. It's not that it remains iconified, it's that it goes to "partial-screen" (see attached screenshot) instead of full-screen. The relevant calls appear to be (noting that my display is currently set to 1440x900): > trace:win:WIN_CreateWindowEx L"Borderlands" L"LaunchUnrealUWindowsClient" ex=00040000 style=00cb0000 360,225 720x450 parent=(nil) menu=(nil) inst=0x400000 params=(nil) > trace:win:dump_window_styles style: WS_CAPTION WS_SYSMENU WS_MINIMIZEBOX WS_MAXIMIZEBOX > trace:win:dump_window_styles exstyle: WS_EX_APPWINDOW > ... > trace:win:SetWindowPos hwnd 0x30096, after (nil), 21,846 (32x32), flags 00008160 > trace:win:dump_winpos_flags flags: SWP_FRAMECHANGED SWP_SHOWWINDOW SWP_NOCOPYBITS SWP_STATECHANGED > ... > trace:win:SetWindowPos hwnd 0x30096, after (nil), 0,0 (1440x900), flags 00000014 > trace:win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOACTIVATE > ... > trace:win:SetWindowPos hwnd 0x30096, after (nil), 0,0 (0x0), flags 00000043 > trace:win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOMOVE SWP_SHOWWINDOW > ... So, you can see why I was suspicious of the "iconic" status not being updated and that resulting in the window not transitioning to the full-screen size. Erich Hoover ehoover(a)mines.edu

Aug. 27, 2010

Re: user32: Make GetMessage and PeekMessage patchable

by Stefan Dösinger

Am 26.08.2010 um 07:08 schrieb Henri Verbeet: > On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >> From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> > Please configure git properly? Oops, sorry. I am surprised I never sent a patch from this machine since I set it up more than a year ago...

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Hin-Tak Leung

--- On Thu, 26/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > Also, half of the > > cross-compiling dependencies are available (and more > up to date) on fedora > > under the ming32-* packages. > > I don't use fedora, but you're welcome to add that > information for the > benefit of fedora users. (Or even a reference for yourself; > that's > pretty much what I use the wiki for.) > > Maybe I'll fix the svn references sometime, if I remember. I have added the github info - wasn't too sure about editing/removing old stuff, so I just added an extra paragraph at the end of the svn checkout part. I'll make another section later about building on fedora and fedora-specific info.

Aug. 26, 2010

Re: [PATCH] inetcpl: Add initial applet

by Detlef Riekenberg

Am Dienstag, den 24.08.2010, 17:56 -0700 schrieb Juan Lang: > Hi Detlef, > were you planning to resubmit this patch? [1] Yes, after the next release but as a more complete Patchset. > Using our own inetcpl.cpl would allow us to avoid > that, by exposing cryptui.CryptUICertMgr without using any native > DLLs. Good Idea. -- By by ... Detlef

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Also, half of the > cross-compiling dependencies are available (and more up to date) on fedora > under the ming32-* packages. I don't use fedora, but you're welcome to add that information for the benefit of fedora users. (Or even a reference for yourself; that's pretty much what I use the wiki for.) Maybe I'll fix the svn references sometime, if I remember.

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Hin-Tak Leung

Vincent Povirk wrote: <snipped> >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > > Judging by bugzilla, there don't seem to be any large projects that > would help compatibility enough to be worthwhile. All the mscoree bugs > only affect one app. Sorry for going off-track in this thread again... I just noticed a couple of outdated-ness on http://wiki.winehq.org/Mono - the Ximian people have switched to git on github for hosting the development about a month ago. It is on git://github.com/mono/mono.git or thereabouts. Also, half of the cross-compiling dependencies are available (and more up to date) on fedora under the ming32-* packages.

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Juan Lang

> ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), > which looks to be what he intended. Ah, yes 'tis. Perhaps it's a deficiency of my brain, but when reading bit-twiddling code, I remember the bitwise operators, but when reading logical code, I tend to stick to the boolean operators more. David, AJ will probably override me and say it's not necessary, but to my eyes != looks clearer. Thanks, --Juan

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 19:32, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Aug 26, 2010 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: >> Hi David, I know this was committed already, but something caught my >> eye that I didn't understand: >> >> + if(This->navpane.show ^ show_navpane) >> >> Is this a cute way to write if(This->navpane.show && show_navpane) ? >> If so, why ^ rather than &&? > > ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), > which looks to be what he intended. > > Octavian > It's indeed supposed to be !=, which also seems like the easier and better way of expressing it. :-) I guess the only reason I used ^ is that that was what came to my mind when I wrote the code in question. It shouldn't matter in practice, but I can include a patch for it in my next batch of patches.

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Octavian Voicu

On Thu, Aug 26, 2010 at 8:11 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Hi David, I know this was committed already, but something caught my > eye that I didn't understand: > > + if(This->navpane.show ^ show_navpane) > > Is this a cute way to write if(This->navpane.show && show_navpane) ? > If so, why ^ rather than &&? ^ is bitwise-XOR, so it is more like if(This->navpane.show != show_navpane), which looks to be what he intended. Octavian

Aug. 26, 2010

Re: shell32: Add a navigation pane to the ExplorerBrowser control.

by Juan Lang

Hi David, I know this was committed already, but something caught my eye that I didn't understand: + if(This->navpane.show ^ show_navpane) Is this a cute way to write if(This->navpane.show && show_navpane) ? If so, why ^ rather than &&? Thanks, --Juan

Aug. 26, 2010

Re: [PATCH 1/1] gameux/tests: verifying registry values created by GameExplorer (try 4)

by testbot＠testbot.winehq.org

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=4793 Your paranoid android. === W7PRO (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (32 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1) === W7PROX64 (64 bit gameexplorer) === gameexplorer.c:453: Test failed: failed while checking registry value (error 0x1) gameexplorer.c:471: Test failed: failed while checking registry value (error 0x1)

Aug. 26, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (try 3)

by Oldřich Jedlička

On Wednesday 25 August 2010 12:03:50 Stefan Dösinger wrote: > > + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > > + "Attaching a back buffer to a front buffer returned %08x\n", hr); > > The patch looks OK. Out of curiosity, which windows system returns > DDERR_CANNOTATTACHSURFACE? Allowing this result with broken() is OK since > you have an application that depends on this behavior. I've searched my previous patches and I think that I've copied it during my first tries from dsurface.c: AttachmentTest. I don't know if it is needed in my tests too, probably not for the testbot. It looked like a good idea to have the check too if it had been in AttachmentTest already. I can remove it with further patch (also from the dsurface.c: BackBufferAttachmentFlipTest). Should I remove it? I will wait for the patch to be applied first and I will send small correction to remove the broken() check, right? I can remove the broken() check from my "New attachment tests for 3D back buffers." patch too. Should I remove it or keep it? Oldřich.

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by James Mckenzie

Vincent Povirk <madewokherd(a)gmail.com> wrote: >Sent: Aug 26, 2010 9:03 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: wine-devel(a)winehq.org, Stefan Dösinger <stefandoesinger(a)gmx.at> >Subject: Re: Inviting Mono and pulseaudio to wineconf? > >> Mono: >> Vincent, what do you think? Probably they're not holding us up, >> but maybe they'd like to see a presentation from you about >> status of Mono integration? > >Oh geez. Um. Well, they are indeed not holding us up. In all my >communication with them, they've been very helpful. > Since Microsoft appears to have taken a hostile turn towards anything released with Windows 7, WMP 10, .NET .3.5 + working with Wine, it would be very interesting to see what the Mono team's stance is on integration with Wine and the path onward. At one time it was very hostile, now it seems to have changed to at least neutral and maybe even what we call 'hallway' friendly. >I don't know that the current status of Mono integration is much to talk about. > >> http://wiki.winehq.org/Mono is looking good. (Think there's a Summer >> of Code 2011 project or two in there?) > >Judging by bugzilla, there don't seem to be any large projects that >would help compatibility enough to be worthwhile. All the mscoree bugs >only affect one app. > Hmmm. Maybe we need to widen the 'gene pool' to see if other applications are affected. James McKenzie

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Mono: > Vincent, what do you think? Probably they're not holding us up, > but maybe they'd like to see a presentation from you about > status of Mono integration? Oh geez. Um. Well, they are indeed not holding us up. In all my communication with them, they've been very helpful. I don't know that the current status of Mono integration is much to talk about. > http://wiki.winehq.org/Mono is looking good. (Think there's a Summer > of Code 2011 project or two in there?) Judging by bugzilla, there don't seem to be any large projects that would help compatibility enough to be worthwhile. All the mscoree bugs only affect one app.

Aug. 26, 2010

Re: : Use SUBLANG_NEUTRAL for language-independent resources

by Greg Geldorp

> From: Francois Gouget <fgouget(a)free.fr> > > According to past Winetest results these platforms could (should?) have > it though. A full log is strange but I don't how it could be cause by my > patch: > > gameux: start - - > Usage: C:\winetest\gameux_test64.exe test_name > > Valid test names: > gameexplorer > gamestatistics > gameux: done (1) > > No test summary line found Your patch only changed the .rc file. TestBot doesn't know what tests to run in that case (it determines the tests to run from the .c files that were changed). Same kind of thing happens when the .js files for the jscript.dll tests are changed. I'll see if I can teach it to just run all tests in these cases. Ge.

Aug. 26, 2010

Re: [5/5] d3d10: Implement D3D10CompileShader, forward to d3dcompiler.

by Henri Verbeet

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > +#define COBJMACROS > #include "config.h" > #include "wine/port.h" > - > +#include "objbase.h" > +#include "d3dcompiler.h" > #include "d3d10_private.h" You should probably just include d3dcompiler.h from d3d10_private.h.

Aug. 26, 2010

Re: [2/5] d3dcompiler: Stub D3DCompile implementation.

by Henri Verbeet

On 26 August 2010 17:26, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Please stick to the coding style used in the rest of the d3d10 dlls (see e.g. blob.c for reference). This applies to patches 4 and 5 as well.

Aug. 26, 2010

Re: user32: Make GetMessage and PeekMessage patchable

by Henri Verbeet

On 26 August 2010 15:51, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > From: =?UTF-8?q?Stefan=20D=C3=B6singer?= <stefan(a)macbook.local> Please configure git properly?

Aug. 26, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

On Wed, Aug 25, 2010 at 9:51 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: >>> Would it be appropriate and useful to invite someone from >>> Mono and Pulseaudio to attend Wineconf this year? > > I guess it never hurts to have people around, but we should have a set of issues to discuss with them. Pulseaudio: What's the status with http://bugs.winehq.org/show_bug.cgi?id=10495 ? Alexandre said in http://bugs.winehq.org/show_bug.cgi?id=10495#c251 that it's being worked on... Mono: Vincent, what do you think? Probably they're not holding us up, but maybe they'd like to see a presentation from you about status of Mono integration? http://wiki.winehq.org/Mono is looking good. (Think there's a Summer of Code 2011 project or two in there?) - Dan

Aug. 26, 2010

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.

by Francois Gouget

On Thu, 26 Aug 2010, testbot(a)testbot.winehq.org wrote: [...] > http://testbot.winehq.org/JobDetails.pl?Key=4787 > > Your paranoid android. > > === W98SE (32 bit) === > === W2KPROSP4 (32 bit) === > === WXPPROSP3 (32 bit) === > === W2K3R2SESP2 (32 bit) === > === W2K8SE (32 bit) === > No test summary line found I think it's just because these platforms don't have the gameux library. Isn't testbot supposed to detect that though? > === WVISTAADM (32 bit) === > === W7PRO (32 bit) === > === W7PROX64 (32 bit) === > === W7PROX64 (64 bit) === > No test summary line found According to past Winetest results these platforms could (should?) have it though. A full log is strange but I don't how it could be cause by my patch: gameux: start - - Usage: C:\winetest\gameux_test64.exe test_name Valid test names: gameexplorer gamestatistics gameux: done (1) No test summary line found -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

Aug. 26, 2010

Re: Use SUBLANG_NEUTRAL for the Gaelic resources?

by Francois Gouget

On Tue, 24 Aug 2010, Huw Davies wrote: [...] > > If not it would be better to use SUBLANG_NEUTRAL instead of > > SUBLANG_GAELIC. For instance: > > I think they're different enough to warrant falling back to English > rather than Irish (which is essentially what you're asking). Works for me. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Aug. 26, 2010

Re: gameux: Use SUBLANG_NEUTRAL for language-independent resources.

by testbot＠testbot.winehq.org

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

Aug. 26, 2010

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 13:03, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 8/26/2010 14:53, David Hedberg wrote: >> >> + *ppvObject = NULL; >> + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) >> + { >> + *ppvObject = iface; >> + } >> + > > Why don't you allow IUnknown here? > An oversight on my part I guess, although I'm not sure anyone will ever request IUnknown here in this case. I'll add it.

Aug. 26, 2010

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.

by David Hedberg

On Thu, Aug 26, 2010 at 13:15, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 8/26/2010 14:53, David Hedberg wrote: >> >> --- >> dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- >> dlls/shell32/tests/ebrowser.c | 174 >> ++++++++++++++++++++++++++++++++++++++++- >> 2 files changed, 251 insertions(+), 21 deletions(-) >> >> diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c >> index b243aa0..1137880 100644 >> --- a/dlls/shell32/ebrowser.c >> +++ b/dlls/shell32/ebrowser.c >> @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { >> LPITEMIDLIST current_pidl; >> >> IUnknown *punk_site; >> + ICommDlgBrowser3 *pcdb3_site; >> + UINT cdb_site_supported; >> } ExplorerBrowserImpl; > > I think a better way for this would be to store a pointer for each interface > version, instead of having additional switch. When you have separate > pointers a call looks more obvious like: > > if (pcdb_site) ICommDlgBrowser_*(pcdb_site). > > Makes sense, I'll send a new version. Thanks.

Aug. 26, 2010

Re: [PATCH 1/5] shell32: Check for ICommDlgBrowser from Site and use it in the IExplorerBrowser control.

by Nikolay Sivov

On 8/26/2010 14:53, David Hedberg wrote: > --- > dlls/shell32/ebrowser.c | 98 +++++++++++++++++++---- > dlls/shell32/tests/ebrowser.c | 174 ++++++++++++++++++++++++++++++++++++++++- > 2 files changed, 251 insertions(+), 21 deletions(-) > > diff --git a/dlls/shell32/ebrowser.c b/dlls/shell32/ebrowser.c > index b243aa0..1137880 100644 > --- a/dlls/shell32/ebrowser.c > +++ b/dlls/shell32/ebrowser.c > @@ -73,6 +73,8 @@ typedef struct _ExplorerBrowserImpl { > LPITEMIDLIST current_pidl; > > IUnknown *punk_site; > + ICommDlgBrowser3 *pcdb3_site; > + UINT cdb_site_supported; > } ExplorerBrowserImpl; I think a better way for this would be to store a pointer for each interface version, instead of having additional switch. When you have separate pointers a call looks more obvious like: if (pcdb_site) ICommDlgBrowser_*(pcdb_site).

Aug. 26, 2010

Re: [PATCH 4/5] shell32: Add INameSpaceTreeControlEvents stub to the ExplorerBrowser control.

by Nikolay Sivov

On 8/26/2010 14:53, David Hedberg wrote: > + *ppvObject = NULL; > + if(IsEqualIID(riid,&IID_INameSpaceTreeControlEvents)) > + { > + *ppvObject = iface; > + } > + Why don't you allow IUnknown here?

Aug. 26, 2010

Re: mpr: Fix Czech translation.

by Alexandre Julliard

Amine Khaldi <amine.khaldi(a)reactos.org> writes: > Regards, > Amine. There's no need to send a separate patch for each language, it's the same change for all. Also make sure your mailer doesn't mangle the high bit chars. -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2010

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

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

Octavian, are you aware of bug http://bugs.winehq.org/show_bug.cgi?id=22146 and the partial patch and additional test cases there? >winmm: Add MCI_INTEGER_PTR return type for DWORD_PTR return values. >+#define MCI_INTEGER_PTR 13 What kind of testing did you perform on native systems to derive the existence of this value? If such value does not exist, then I fear your patch set looses the ability to drop in native dlls for compatibility testing and validation. If it exists, then it's good news you found it. >-static DWORD MCI_ParseOptArgs(DWORD_PTR* data, int _offset, LPCWSTR lpCmd, >+static DWORD MCI_ParseOptArgs(BYTE* data, int _offset, LPCWSTR lpCmd, >- if (!MCI_GetDWord(&(data[offset+0]), &args) || >- !MCI_GetDWord(&(data[offset+1]), &args) || >- !MCI_GetDWord(&(data[offset+2]), &args) || >- !MCI_GetDWord(&(data[offset+3]), &args)) { >+ if (!MCI_GetDWord(data+offset+0*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+1*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+2*sizeof(DWORD), &args) || >+ !MCI_GetDWord(data+offset+3*sizeof(DWORD), &args)) { The MCI_XYZ_PARMS structures are neither DWORD_PTR, not BYTE*, they are DWORD with some DWORD_PTR in between. Wouldn't using DWORD* data help avoid such pointer arithmetic and eliminate several hunks of the patch ? Regards, Jörg Höhle

Aug. 26, 2010

Re: RFC: Resolving a full screen bug

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > I've been periodically revisiting a patch I've been using to fix a bug > with running Borderlands under Wine at the same resolution as the > desktop ( original message: > http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). > Attached is an iteration that appears to resolve the issue without > impacting the other applications I normally run. It appears that the > problem arises since Borderlands goes straight from being iconified to > being exactly the desktop resolution, as a result Wine never turns off > the "iconic" flag - so the application window is not sized or > positioned properly. I would appreciate it if I could get some > feedback on this patch, it doesn't seem to break anything but it would > be nice to have an expert opinion. It's not correct, the iconic flag is supposed to reflect the state that we have asked from X. What is the exact sequence that leads to the window remaining iconified? -- Alexandre Julliard julliard(a)winehq.org

Aug. 26, 2010

RFC: Resolving a full screen bug

by Erich Hoover

I've been periodically revisiting a patch I've been using to fix a bug with running Borderlands under Wine at the same resolution as the desktop ( original message: http://www.winehq.org/pipermail/wine-devel/2010-May/083339.html ). Attached is an iteration that appears to resolve the issue without impacting the other applications I normally run. It appears that the problem arises since Borderlands goes straight from being iconified to being exactly the desktop resolution, as a result Wine never turns off the "iconic" flag - so the application window is not sized or positioned properly. I would appreciate it if I could get some feedback on this patch, it doesn't seem to break anything but it would be nice to have an expert opinion. Erich Hoover ehoover(a)mines.edu

Aug. 26, 2010

Re: winetrick & mono dot net 3.5 emmulation.

by Hin-Tak Leung

apologies - for laziness, I picked one message with Dan Kegel and did a reply and emptied subject/body. I guess that messes up e-mail software that actually uses the invisible headers for threads. -------- Original Message -------- Subject: Re: winetrick & mono dot net 3.5 emmulation. Date: Wed, 25 Aug 2010 21:01:09 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> Hin-Tak Leung wrote: > The installer of one application I have requires Net 3.5 and refuses > to install > if it is not detected. Yet it runs adequately well with mono 2.6.x > (when installed to Vista then copied over). So I am wondering if there > should be a winetrick "lie about having .net 3.5" registry setting, > and go about seeing what needs to be done - e.g. how is that installer > detecting dot net 3.5 ? > > > > Can you open a separate thread for this? I'm going ahead and deleting all of the messages from the hijacked thread on my system and you have a very good point to make. James McKenzie

Aug. 26, 2010

Re: winetrick & mono dot net 3.5 emmulation.

by Vincent Povirk

Wine should probably include whatever registry key is needed by default.

Aug. 25, 2010

WineConf 2010

by Francois Gouget

WineConf 2010 is now all set: Where: Hotel Ibis Bastille in Paris When: November, Saturday 20th ~9am to Sunday 21st ~5pm You should book your hotel room directly from the hotel; the sooner the better. Also if you have not booked your plane tickets yet, this is your reminder. All the details should be available on the WineConf 2010 wiki page: http://wiki.winehq.org/WineConf2010 Again, note that most further communication will happen on the wineconf(a)winehq.org mailing list. So subscribe there to be sure not to miss the latest news. This is also the place to go if you have questions, etc. I hope to see you all in Paris! -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Aug. 25, 2010

Re: winetrick & mono dot net 3.5 emmulation.

by Dan Kegel

On Wed, Aug 25, 2010 at 7:02 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > The installer of one application I have requires Net 3.5 and refuses to > install > if it is not detected. Yet it runs adequately well with mono 2.6.x (when > installed to Vista then copied over). So I am wondering if there should be a > winetrick "lie about having .net 3.5" registry setting, and go about seeing > what needs to be done - e.g. how is that installer detecting dot net 3.5 ? Sure, a fakedotnet35 verb seems like a fine thing for the short term, if it makes an app happy. Or maybe it should be added to the mono26 verb. Ideally Wine would load mono and set those variables automatically, but it might be a while before somebody has the time to make it all work smoothly like that.

Aug. 25, 2010

winetrick & mono dot net 3.5 emmulation.

by Hin-Tak Leung

The installer of one application I have requires Net 3.5 and refuses to install if it is not detected. Yet it runs adequately well with mono 2.6.x (when installed to Vista then copied over). So I am wondering if there should be a winetrick "lie about having .net 3.5" registry setting, and go about seeing what needs to be done - e.g. how is that installer detecting dot net 3.5 ?

Aug. 25, 2010

re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite

by Dan Kegel

Henri wrote: > You still have basic formatting errors like trailing spaces, mixing > tabs and spaces, inconsistent "*" placement, etc. > ... unnecessary cast... > wine-patches reviews are supposed to catch non-trivial interactions with > other parts of the code, not trivial whitespace errors. Looking at http://wiki.winehq.org/SubmittingPatches, I didn't see a nice, concise checklist of things to check for, so I added one at the top, and linked to Henri's post. Improvements welcome. - Dan

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Vincent Povirk

> Maybe we should preemptively invite an OpenAL guy :-) I assume you mean Chris Robinson. And yes, we should totally invite him.

Aug. 25, 2010

Re: [PATCH 2/7] d3dx9_36/tests: Added HLSL test suite

by Henri Verbeet

On 25 August 2010 09:58, Travis Athougies <iammisc(a)gmail.com> wrote: > +static IDirect3DPixelShader9* compile_pixel_shader(IDirect3DDevice9* device, const char *shader, const char *profile,· > +»······»·······»·······»·······»·······»······· ID3DXConstantTable **constants) You still have basic formatting errors like trailing spaces, mixing tabs and spaces, inconsistent "*" placement, etc. > + hres = IDirect3DDevice9_CreateVertexShader(device_ptr, (DWORD*) ID3DXBuffer_GetBufferPointer(compiled), &vshader_passthru); Here's another unnecessary cast. For the record, I'm not going to point out every single flaw in every single patch. If I find an issue in a patch, you should take that as a hint that perhaps you didn't review your patches careful enough before sending them, and go over them again yourself. Anyway, we've decided to implement the shader assembler and compiler in the d3dcompiler dll. I think it makes sense to move any compiler/assembler tests there as well. Note that I'm going to request that d3dcompiler follows the same general style as used in dxgi/d3d10core/d3d10, this is different from the style used in most of d3dx9. Something else. In my opinion an internship should imply some level of guidance/training, not simply "cheap labor". In particular, while ideally you would have caught the issues mentioned in this and previous reviews yourself, whoever has been mentoring you certainly should have, these are basic C / Wine development issues. The process is supposed to look somewhat like this: 1. Carefully write the patch. 2. Carefully review the patch. 3. If you find any issues, carefully fix them and go back to 2. 4. Run the test suite. 5. If it finds any issues, carefully fix them and go back to 2. 6. Send the patch to your mentor for review. 7. If he finds any issues, carefully fix them and go back to 2. 8. If it's still the same day as on 1, consider waiting a day, so you can give the patch a fresh look in the next step. 9. Repeat steps 2 through 5 before sending the patch to wine-patches. 10. Send the patch to wine-patches. 11. If it finds any issues, carefully fix them and go back to 2. Replace "patch" with "patchset" if you're doing more complicated things. Ideally step 6 would produce something like a "Signed-off-by" or "Reviewed-by" tag. If you're at step 11 for the third or fourth time, and there are still problems with the patch, there are structural failures at 1, 2 and 6. Failures at 1 and 2 are somewhat expected for an internship, depending on what kind of standards a specific organization sets, but that's exactly what step 6 is supposed to catch. I.e., when I find an issue in a patch that means at the very least that you didn't catch it when writing the patch, didn't catch it when reviewing the patch the first time, your mentor didn't catch it, and you didn't catch it during review before sending the patch. The things wine-patches reviews are supposed to catch are non-trivial interactions with other parts of the code, not trivial whitespace errors.

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

On Wed, Aug 25, 2010 at 6:36 AM, Jeff Cook <jeff(a)deserettechnology.com> wrote: >> Having a good pulseaudio driver (in the new wine audio design) might >> not be a bad thing. > > My understanding is that the new mmdevapi code leverages OpenAL, which > theoretically should take care of the pulseaudio issues assuming both > sides implement the protocol appropriately. Sure, and Pulseaudio leverages the ALSA API, which theoretically should take care of compatibility problems, assuming both sides implement the API properly. But you raise a good point. Hey, Maarten, how's the OpenAL stuff coming? Will there be something to demo before Wineconf? Maybe we should preemptively invite an OpenAL guy :-) - Dan

Aug. 25, 2010

Re: mscoree: improve GetCORSytemDirectory

by testbot＠testbot.winehq.org

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

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Henri Verbeet

On 25 August 2010 14:31, Misha Koshelev <misha680(a)gmail.com> wrote: > for some reason were from Paulo Lesgaz. > For what it's worth, "Paulo Lesgaz" is an (obvious) pseudonym, as is "Jérémie Lapurée". See e.g. http://fr.wikipedia.org/wiki/Joe_Bar_Team for reference.

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Misha Koshelev

On Wed, 2010-08-25 at 12:28 +0200, Henri Verbeet wrote: > On 25 August 2010 04:04, misha680 <misha680(a)gmail.com> wrote: > > What do you think about this one on top of those? I will wait to send to > > wine-patches until your patches have been committed. > > http://wine.1045685.n5.nabble.com/file/n2652101/0004-d3dx9-Implement-D3DXDe… > > Still not quite right, I'm afraid, although it's a bit closer. > However, as mentioned in > http://www.winehq.org/pipermail/wine-devel/2010-August/086112.html, > since this is about the tenth version of D3DXDeclaratorFromFVF() I'm > seeing (not counting the ones in d3d9 and wined3d...), I went ahead > and just implemented it myself. The patch attached to that mail is the > initial untested version. The patch attached to this mail is what I > think it should look like after doing some tests. I'll probably send > it in tomorrow. Thank you so much. My apologies - for some reason I got confused and thought that the patches in http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXDeclaratorFromFVF-… for some reason were from Paulo Lesgaz. Thank you for your help with this! Misha

Aug. 25, 2010

"Spanish - Modern Sort_Spain.1252" locale on wine

by GOUJON Alexandre

Hi everyone, I'm trying to fix msvcrt:locale on wine and it appears "Spanish - Modern Sort_Spain.1252" locale is missing. According to msdn (http://msdn.microsoft.com/en-us/library/39cwe7zf%28v=VS.71%29.aspx) "esn" and "spanish-modern" are equivalent which is false [quoted from msvcrt/tests/locale.c] ret = setlocale(LC_ALL, "esn"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish_Spain.1252") || broken(!strcmp(ret, "Spanish - Modern Sort_Spain.1252")), "ret = %s\n", ret); and ret = setlocale(LC_ALL, "spanish-modern"); ok(ret != NULL || broken (ret == NULL), "ret == NULL\n"); if(ret) ok(!strcmp(ret, "Spanish - Modern Sort_Spain.1252") || broken(!strcmp(ret, "Spanish_Spain.1252")), "ret = %s\n", ret); If I modify dlls/kernerl32/nls/esn.nls LOCALE_SENGLANGUAGE "Spanish" to LOCALE_SENGLANGUAGE "Spanish - Modern Sort" then it'll fix the second test and break the first one. So I'm wondering what to do. Create another nls file based on esn with a different LOCALE_SENGLANGUAGE ? (and change _country_synonyms[] in locale.c) Hard code this (i.e. if .. == "spanish-modern" .. ) ? Other advice ? Thanks in advance

Aug. 25, 2010

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Henri Verbeet

On 25 August 2010 08:48, David Adam <david.adam.cnrs(a)gmail.com> wrote: > + if(cooplevel == (DDSCL_NORMAL | DDSCL_EXCLUSIVE) ) So what happens if you set e.g. "DDSCL_NORMAL | DDSCL_EXCLUSIVE | DDSCL_FPUPRESERVE"? You also still have trailing spaces. The way this would conceptually make sense to me is if you always need either NORMAL or EXCLUSIVE, with NORMAL | EXCLUSIVE -> EXCLUSIVE and EXCLUSIVE requiring FULLSCREEN. (Well, except for SETFOCUSWINDOW, which seems to live in a world of its own.) I.e., something along these lines: if (coop & SETFOCUSWINDOW) { ... return; } if (coop & EXCLUSIVE) { if (!(coop & FULLSCREEN)) fail(); ... } else if (coop & NORMAL) { ... } else fail();

Aug. 25, 2010

wined3d and visual studio: The remaining uglyness

by Stefan Dösinger

Hi, I've spent some time to get wined3d to compile with visual studio on Windows. I sent some code fixes needed for that, but a few hacks are remaining. I'm sending them here for discussion. First, why did I look at Visual Studio: *) mingw on windows a bit messy. Cross Compiling all the time even more so *) msvc is the native toolkit, it opens up many other tools. I was interested in VsPerfKit specifically. Basically I set up a Visual Studio process to compile libport, libwine, wined3d, d3d8 and d3d9 out of tree, referencing the code files via relative paths(../../wine/dlls/wined3d/*.c). This was done manually, there's no integration with Wine's native build system. That's hack #1. Unfortunately I can't attach the project right now, it's on a different computer at home. I think we have a script to generate msvc projects for the tests. Maybe the right way is to extend this to the DLLs and programs. I wrote a hand-written config.h file defining a few HAVE_XXX_H constants. That is hack #2 and relates to Alexandre's concern about the libport isnan and isinf implementations. More specific code issues: *) MIDL uses cdecl as the default calling convention for exported functions. Patch 6 in the archive fixes wined3d.idl to work correctly with midl, but this change causes a segfault in widl. *) Msvc complains that -unsigned_int is still unsigned, and the integer overflow just happens to do what you want. The easiest way is to write 0 - unsigned_int, but I'm not sure about it. *) NaN and Inf generation *) msvc doesn't like the predeclaration of **environ. It causes a unknown symbol error at link time.

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by Henri Verbeet

On 25 August 2010 04:04, misha680 <misha680(a)gmail.com> wrote: > What do you think about this one on top of those? I will wait to send to > wine-patches until your patches have been committed. > http://wine.1045685.n5.nabble.com/file/n2652101/0004-d3dx9-Implement-D3DXDe… Still not quite right, I'm afraid, although it's a bit closer. However, as mentioned in http://www.winehq.org/pipermail/wine-devel/2010-August/086112.html, since this is about the tenth version of D3DXDeclaratorFromFVF() I'm seeing (not counting the ones in d3d9 and wined3d...), I went ahead and just implemented it myself. The patch attached to that mail is the initial untested version. The patch attached to this mail is what I think it should look like after doing some tests. I'll probably send it in tomorrow.

Aug. 25, 2010

Re: ddraw: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

Hi, Your CreateSurface tests are missing in this patch(assuming that paulo lesgaz is your alter ego) There's a comment above the SetCooperativeLevel implementation that needs adjustments. > if(cooplevel & DDSCL_NORMAL) > { > - /* Can't coexist with fullscreen or exclusive */ > - if(cooplevel & (DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE) ) > + /* Can't coexist with exclusive only*/ > + if(cooplevel = DDSCL_NORMAL | DDSCL_EXCLUSIVE ) This check doesn't do what you intend it to do. An application may pass NORMAL | EXCLUSIVE | FPUSETUP for instance Also, your test shows that NORMAL | EXCLUSIVE | FULLSCREEN means fullscreen mode. The CreateSurface test passes because the FULLSCREEN and EXCLUSIVE flags are added, but the window is still set up for windowed rendering. In this flag combination you want to enter the fullscreen setup codepath.

Aug. 25, 2010

Re: ddraw/tests: New visual back buffer flipping tests. (try 3)

by Stefan Dösinger

> + hr = IDirectDrawSurface_AddAttachedSurface(Primary, Backbuffer); > + todo_wine ok(hr == DD_OK || broken(hr == DDERR_CANNOTATTACHSURFACE), > + "Attaching a back buffer to a front buffer returned %08x\n", hr); The patch looks OK. Out of curiosity, which windows system returns DDERR_CANNOTATTACHSURFACE? Allowing this result with broken() is OK since you have an application that depends on this behavior.

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Stefan Dösinger

Am 25.08.2010 um 04:34 schrieb James McKenzie: > Dan Kegel wrote: >> Would it be appropriate and useful to invite someone from >> Mono and Pulseaudio to attend Wineconf this year? >> We do have to work well with those projects, maybe that would help >> solve a couple current or future problems. >> > Dan: > > +1 on Mono, -1 on PulseAudio I guess it never hurts to have people around, but we should have a set of issues to discuss with them.

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Scott Ritchie

On 08/24/2010 12:32 PM, Dan Kegel wrote: > Would it be appropriate and useful to invite someone from > Mono and Pulseaudio to attend Wineconf this year? > We do have to work well with those projects, maybe that would help > solve a couple current or future problems. > > If I remember right I floated this idea (with Mono) earlier, and there was some conflict that meant it wouldn't work. I believe I was thinking of scheduling concurrent conferences however - we could always just bring Mono people to wineconf as a separate thing. Thanks, Scott Ritchie

Aug. 25, 2010

Re: ddraw [try 3]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by testbot＠testbot.winehq.org

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=4741 Your paranoid android. === W98SE (32 bit ddrawmodes) === No test summary line found === W7PROX64 (64 bit ddrawmodes) === Timeout

Aug. 25, 2010

Help with 6120d7cc145, causing bugs

by Jeff Cook

Just wondering if I could get a bit more review on commit 6120d7cc145 which was committed in early August. Here's a link: http://source.winehq.org/git/wine.git/?a=commit;h=6120d7cc14522983fbc38026a… There have been a few bug reports filed against it recently, see http://bugs.winehq.org/show_bug.cgi?id=23902 and http://bugs.winehq.org/show_bug.cgi?id=24131 . It seems that in some relatively rare sound setups, an inappropriate sound element gets fed in to filllines_no_master which leads to a crash on audio initialize. To me this is weird because the program is currently written so that it flows into filllines_no_master only if there no is master control. A patch adding else if (micelem) instead of just else was recently committed and fixed at least one person's problem. Some people on the bug report are unable to provide full debug information so it makes this harder. If you have the time, please review the patch and let me know what errors you notice that may be causing the aforementioned bug. I am new to Wine dev so please forgive anything really stupid. :) Thanks From Jeff. -- Jeff Cook (801) 231-3157 jeff(a)deserettechnology.com

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Jeff Cook

On Wed, Aug 25, 2010 at 12:10 AM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > I'm not against inviting Pulseaudio guys. Sure, Pulseaudio was added > to distributions way too early and there still are a lot of issues but > sound servers like pulseaudio are really the way to go for the future. > People want to be able to plug in lets say a usb headset (so another > soundcard) when playing a game and expect audio to move over to it or > want to see audio move over to their HDTV when they plug it in and > that's stuff which requires some form of arbiter at the user side. > > Having a good pulseaudio driver (in the new wine audio design) might > not be a bad thing. My understanding is that the new mmdevapi code leverages OpenAL, which theoretically should take care of the pulseaudio issues assuming both sides implement the protocol appropriately. > > Roderick

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by Roderick Colenbrander

I'm not against inviting Pulseaudio guys. Sure, Pulseaudio was added to distributions way too early and there still are a lot of issues but sound servers like pulseaudio are really the way to go for the future. People want to be able to plug in lets say a usb headset (so another soundcard) when playing a game and expect audio to move over to it or want to see audio move over to their HDTV when they plug it in and that's stuff which requires some form of arbiter at the user side. Having a good pulseaudio driver (in the new wine audio design) might not be a bad thing. Roderick On Tue, Aug 24, 2010 at 7:34 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Dan Kegel wrote: >> >> Would it be appropriate and useful to invite someone from >> Mono and Pulseaudio to attend Wineconf this year? >> We do have to work well with those projects, maybe that would help >> solve a couple current or future problems. >> > > Dan: > > +1 on Mono, -1 on PulseAudio > > James McKenzie > > > >

Aug. 25, 2010

Re: Inviting Mono and pulseaudio to wineconf?

by James McKenzie

Dan Kegel wrote: > Would it be appropriate and useful to invite someone from > Mono and Pulseaudio to attend Wineconf this year? > We do have to work well with those projects, maybe that would help > solve a couple current or future problems. > Dan: +1 on Mono, -1 on PulseAudio James McKenzie

Aug. 25, 2010

Re: d3dx9: Implement D3DXDeclaratorFromFVF. (try 2)

by misha680

Henri Verbeet wrote: > > On 24 August 2010 05:05, Misha Koshelev <misha680(a)gmail.com> wrote: >> + elements[idx].Stream = 0xFF; >> + elements[idx].Offset = D3DXGetDeclVertexSize(elements, 0); >> + elements[idx].Stream = 0; > That's ugly. > >> + memcpy(Declaration, elements, size * sizeof(D3DVERTEXELEMENT9)); > That's unnecessary. > > > > Thanks, I noticed your patches here: http://source.winehq.org/patches/data/65330 http://source.winehq.org/patches/data/65331 http://source.winehq.org/patches/data/65331 What do you think about this one on top of those? I will wait to send to wine-patches until your patches have been committed. http://wine.1045685.n5.nabble.com/file/n2652101/0004-d3dx9-Implement-D3DXDe… 0004-d3dx9-Implement-D3DXDeclaratorFromFVF.txt Thank you Misha -- View this message in context: http://wine.1045685.n5.nabble.com/Re-d3dx9-Implement-D3DXDeclaratorFromFVF-… Sent from the Wine - Devel mailing list archive at Nabble.com.

Aug. 25, 2010

Re: Ongoing Debian package maintenance.

by Lei Zhang

On Tue, Aug 24, 2010 at 3:06 PM, Ben Klein <shacklein(a)gmail.com> wrote: > On 24 August 2010 04:34, Lei Zhang <thestig(a)google.com> wrote: >> >> On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: >> > Hello everyone, >> > >> > My health has not improved at all since my last call for help with the >> > Debian package management. I really need someone to take over from me, or at >> > least some help to devise a new set of (semi-)automated build scripts. Any >> > volunteers? >> >> Hi Ben, >> >> Does the task basically involve building new .deb packages for every >> release? I can probably take over this if nobody else volunteered. > > Yes, that is essentially the job. For every release of Wine, produce a > package for Debian's stable branch and testing/unstable. Ok, I'll take the job. If you have any documentation / pointers on what the package maintainer needs to do, send them my way, or better yet, put it on the Wine wiki.

Aug. 25, 2010

Re: [PATCH] inetcpl: Add initial applet

by Juan Lang

Hi Detlef, were you planning to resubmit this patch? [1] A user asked how to import a certificate recently [2], and I directed him to install ie6 to do so, but that has a lot of side effects which may not be wanted. Using our own inetcpl.cpl would allow us to avoid that, by exposing cryptui.CryptUICertMgr without using any native DLLs. Thanks, --Juan [1] http://www.winehq.org/pipermail/wine-patches/2010-May/088373.html [2] http://forum.winehq.org/viewtopic.php?t=9399

Aug. 25, 2010

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.

by testbot＠testbot.winehq.org

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

Aug. 24, 2010

Re: [3/3] d3dcompiler: Move D3DAssemble tests from d3dx9_36.

by testbot＠testbot.winehq.org

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

Aug. 24, 2010

Re: [4/4] oleaut32/tests: Some tests for IPicture::get_Handle()

by testbot＠testbot.winehq.org

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=4738 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:796: Test failed: got 0 olepicture.c:808: Test failed: got 0

Aug. 24, 2010

Re: Ongoing Debian package maintenance.

by Ben Klein

On 24 August 2010 04:34, Lei Zhang <thestig(a)google.com> wrote: > > On Fri, Aug 20, 2010 at 4:00 PM, Ben Klein <shacklein(a)gmail.com> wrote: > > Hello everyone, > > > > My health has not improved at all since my last call for help with the > > Debian package management. I really need someone to take over from me, or at > > least some help to devise a new set of (semi-)automated build scripts. Any > > volunteers? > > Hi Ben, > > Does the task basically involve building new .deb packages for every > release? I can probably take over this if nobody else volunteered. Yes, that is essentially the job. For every release of Wine, produce a package for Debian's stable branch and testing/unstable. > Get better! Thanks, Lei. I'm going through some tests at the moment and think I know what the outcome of the next one will be, which is good because it will tell me what's been wrong for YEARS with me (though it's got a LOT worse these past few months).

Aug. 24, 2010

Re: [3/4] oleaut32/olepicture: Fix ::get_hPal() behaviour for certain picture types

by testbot＠testbot.winehq.org

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=4737 Your paranoid android. === W7PROX64 (64 bit olepicture) === olepicture.c:765: Test failed: got 0 olepicture.c:777: Test failed: got 0

Aug. 24, 2010

Inviting Mono and pulseaudio to wineconf?

by Dan Kegel

Would it be appropriate and useful to invite someone from Mono and Pulseaudio to attend Wineconf this year? We do have to work well with those projects, maybe that would help solve a couple current or future problems.

Aug. 24, 2010

Re : Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

Added new tests for d3d7. No change. All the tests passed on real Vista David ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 20h 00min 05s Objet : Re: Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized Am 24.08.2010 um 17:48 schrieb paulo lesgaz: Is this patch correct to test d3d7 and d3d2 SetCooperativeLevel? >For now, all the tests pass on a real vista box. >Actually, I missed something: The exising test tests IDirectDraw, not >IDirectDraw7. So it is testing the oldest ddraw interface. Can you test >IDirectDraw7 instead of IDirectDraw2? If microsoft added extra sanity checks >they did so most likely in the newer interfaces.

Aug. 24, 2010

Re: Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

Am 24.08.2010 um 17:48 schrieb paulo lesgaz: > Is this patch correct to test d3d7 and d3d2 SetCooperativeLevel? > For now, all the tests pass on a real vista box. Actually, I missed something: The exising test tests IDirectDraw, not IDirectDraw7. So it is testing the oldest ddraw interface. Can you test IDirectDraw7 instead of IDirectDraw2? If microsoft added extra sanity checks they did so most likely in the newer interfaces.

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Vincent Povirk

Yes, build-mingw32.sh works, but the resulting build is incomplete. For example, it lacks libgluezilla and a mozilla library to glue to, so the browsing component does not work. This is in the official Windows builds of Mono. I don't know what else is missing. On Tue, Aug 24, 2010 at 12:45 PM, Hin-Tak Leung <hintak_leung(a)yahoo.co.uk> wrote: > --- On Tue, 24/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> > And eventually mono will be >> installed automatically like gecko is? >> >> If I ever get the damn thing to build fully on a Linux box, >> yes. > > Is there a problem with that? Mono comes with a script called "build-mingw32.sh" for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle. > > There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now. > > > > >

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Hin-Tak Leung

--- On Tue, 24/8/10, Vincent Povirk <madewokherd(a)gmail.com> wrote: > > And eventually mono will be > installed automatically like gecko is? > > If I ever get the damn thing to build fully on a Linux box, > yes. Is there a problem with that? Mono comes with a script called "build-mingw32.sh" for cross-compiling on linux. I use that for every mono release since about 2.2 as I need a little customization, changing the heap setting, before they get the new garbage collector code scheduled for 2.8(?) ready. I only rebuild the runtime - not the class libraries, so I stop the build in the middle. There are some dependency differences (depending on different versions of dependent dll's) against MSVC builds, file naming differences (the mono dll is called libmono.dll in one but just mono.dll in the other - I filed a bug for it and it is still open), and dependencies on gcc_s*.dll from exception unwinding, but it is basically inter-operable - as I swap one part of the stock msvc build with a custom mingw cross-compiled part for every release for much of the last two years now.

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Vincent Povirk

> And eventually mono will be installed automatically like gecko is? If I ever get the damn thing to build fully on a Linux box, yes.

Aug. 24, 2010

Re : Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

Is this patch correct to test d3d7 and d3d2 SetCooperativeLevel? For now, all the tests pass on a real vista box. David ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : paulo lesgaz <jeremielapuree(a)yahoo.fr> Cc : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 16h 44min 38s Objet : Re: Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized I think those tests should do, but have a few spelling issues and you're not releasing the surface. So if I understand things correctly: *) NORMAL | FULLSCREEN | EXCLUSIVE -> fullscreen mode *) NORMAL | EXCLUSIVE -> error *) NORMAL | FULLSCREEN -> windowed mode For testing older ddraw interface vesions you can QueryInterface the ddraw object for IID_IDirectDraw, IID_IDirectDraw2(and ddraw3 and ddraw4). Then you run the same tests on those. I am pretty sure the check that NORMAL mode is mutually exclusive with FULLSCREEN/EXCLUSIVE already existed in old ddraw, and is motivated by a statement in msdn that those modes are mutually exclusive - which makes sense, you can't be in fullscreen mode and not be in fullscreen mode at the same time. It seems that one flag is ignored rather than an error returned. On a general note, I am away from home the next weeks. I expect to be able to read mail, but it will me sporadic(ok, I haven't been reliable in the past few weeks either) Am 24.08.2010 um 15:26 schrieb paulo lesgaz: Such tests are what you were thinking about? >They all passed on my real vista box. > >David > > > > > > ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> >À : wine-devel(a)winehq.org >Envoyé le : Mar 24 août 2010, 11h 30min 59s >Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + >normal is authorized > >Hi, >Can you add a test that tests in which mode ddraw is after such a call? >Specfically, try to create a double buffered primary surface. If this succeeds, >ddraw is in fullscreen mode. If ddraw is in normal mode you'll get >DDERR_NOEXCLUSIVEMODE (or similar) back. > >Am 24.08.2010 um 10:00 schrieb David Adam: > >> Fixed a typo >> >> A+ >> >> David >> <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch> > > > > ><0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

wine.inf: added .NET InstallRoot key

by Louis Lenders

Dan Kegel <dank <at> kegel.com> writes: > > What is our intent with adding all these registry keys? > It seems as if they are helpful for installing mono, > but might get in the way of installing MS .net. > > If that's the intent, do y'all want me to make the > dotnet20 winetricks verb remove any registry > keys that confuse the dotnet20 installer? > > I tested dotnet 2.0 and these 2 keys don't harm the installer The only key that causes trouble AFAICT is the already present key [HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727] "Version"="2.2.30729" It makes the .NET SP1 installer crash much earlier than it does without this key

Aug. 24, 2010

Re: Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by Stefan Dösinger

I think those tests should do, but have a few spelling issues and you're not releasing the surface. So if I understand things correctly: *) NORMAL | FULLSCREEN | EXCLUSIVE -> fullscreen mode *) NORMAL | EXCLUSIVE -> error *) NORMAL | FULLSCREEN -> windowed mode For testing older ddraw interface vesions you can QueryInterface the ddraw object for IID_IDirectDraw, IID_IDirectDraw2(and ddraw3 and ddraw4). Then you run the same tests on those. I am pretty sure the check that NORMAL mode is mutually exclusive with FULLSCREEN/EXCLUSIVE already existed in old ddraw, and is motivated by a statement in msdn that those modes are mutually exclusive - which makes sense, you can't be in fullscreen mode and not be in fullscreen mode at the same time. It seems that one flag is ignored rather than an error returned. On a general note, I am away from home the next weeks. I expect to be able to read mail, but it will me sporadic(ok, I haven't been reliable in the past few weeks either) Am 24.08.2010 um 15:26 schrieb paulo lesgaz: > Such tests are what you were thinking about? > They all passed on my real vista box. > > David > > > De : Stefan Dösinger <stefandoesinger(a)gmx.at> > À : wine-devel(a)winehq.org > Envoyé le : Mar 24 août 2010, 11h 30min 59s > Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized > > Hi, > Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. > > Am 24.08.2010 um 10:00 schrieb David Adam: > > > Fixed a typo > > > > A+ > > > > David > > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch> > > > > > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Dan Kegel

On Tue, Aug 24, 2010 at 1:52 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> What is our intent with adding all these registry keys? >> It seems as if they are helpful for installing mono, >> but might get in the way of installing MS .net. > > If they prevent installing MS .NET there should be a way to undo them > like we do for IE, by unregistering mscoree or something along those > lines. OK, so people who need the native .net should use something like winetricks to do the unregistering and installation, right? And eventually mono will be installed automatically like gecko is? - Dan

Aug. 24, 2010

Re: wine.inf: added .NET InstallRoot key

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > What is our intent with adding all these registry keys? > It seems as if they are helpful for installing mono, > but might get in the way of installing MS .net. If they prevent installing MS .NET there should be a way to undo them like we do for IE, by unregistering mscoree or something along those lines. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2010

Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

Such tests are what you were thinking about? They all passed on my real vista box. David ________________________________ De : Stefan Dösinger <stefandoesinger(a)gmx.at> À : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 11h 30min 59s Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized Hi, Can you add a test that tests in which mode ddraw is after such a call? Specfically, try to create a double buffered primary surface. If this succeeds, ddraw is in fullscreen mode. If ddraw is in normal mode you'll get DDERR_NOEXCLUSIVEMODE (or similar) back. Am 24.08.2010 um 10:00 schrieb David Adam: > Fixed a typo > > A+ > > David > <0001-SetCooperativeLevel-with-Full-screen-exclusive-norma.patch>

Aug. 24, 2010

Re: msvcrt:locale Remove todo_wine and add broken when necessary

by GOUJON Alexandre

On 08/24/2010 02:51 PM, Octavian Voicu wrote: > broken() only works for tests that fail on some Windows versions; it > has no effect on Wine, see [1]. > My mistake. > Proper way to fix this bug is to make setlocale replicate Windows behavior. > I'll investigate further to fix it this way. Thanks

Aug. 24, 2010

Re: msvcrt:locale Remove todo_wine and add broken when necessary

by Octavian Voicu

On Tue, Aug 24, 2010 at 12:44 PM, Alexandre Goujon <ale.goujon(a)gmail.com> wrote: > - todo_wine ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + ok(!strcmp(ret, "Chinese (Simplified)_People's Republic of China.936") > + || broken(!strcmp(ret, "Chinese_People's Republic of China.936")) broken() only works for tests that fail on some Windows versions; it has no effect on Wine, see [1]. Proper way to fix this bug is to make setlocale replicate Windows behavior. Octavian [1] http://source.winehq.org/git/wine.git/?a=blob;f=include/wine/test.h;h=1a980…

Aug. 24, 2010

re: wine.inf: added .NET InstallRoot key

by Dan Kegel

What is our intent with adding all these registry keys? It seems as if they are helpful for installing mono, but might get in the way of installing MS .net. If that's the intent, do y'all want me to make the dotnet20 winetricks verb remove any registry keys that confuse the dotnet20 installer?

Aug. 24, 2010

Re: Wine Gecko 1.1.0 RC1

by Jacek Caban

On 8/24/10 12:12 PM, Luca Bennati wrote: > Applied the patch to master, recompiled ok. I put the rc1 cab in > /usr/share/wine/gecko/, as always. > In the creation of a new prefix, it gave me an err which wasn't there before: > err:mshtml:init_xpcom AutoRegister(NULL) failed: 80070057 > but 'wine iexplore' works better than before (sites that crashed wine > before don't crash it anymore). > I investigated it a bit recreating a new prefix with 'WINEDEBUG=+mshtml > winecfg' and here's the log: Thanks for testing. This error is a known false error. Modules loading method has changed in Gecko and AutoRegister call is no longer needed, so I'm going to remove this call. It's harmless in the new Gecko, so I'm going to do it in another patch to limit size of this one. Thanks, Jacek

Aug. 24, 2010

Re: mscoree: improve GetCORVersion

by testbot＠testbot.winehq.org

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

Aug. 24, 2010

Re : ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized

by paulo lesgaz

The added tests show that the change is correct for d3d7 at least. How can I check that they are also correct for olders ddraw? David ________________________________ De : Henri Verbeet <hverbeet(a)gmail.com> À : wine-devel(a)winehq.org Envoyé le : Mar 24 août 2010, 11h 41min 36s Objet : Re: ddraw [try 2]: SetCooperativeLevel with Full screen + exclusive + normal is authorized This looks suspicious to me, you have to assume the code wasn't just added for the hell of it, even though with ddraw you're never quite sure. Do other ddraw versions behave the same? Please don't add trailing spaces, neither in the code nor in TRACEs.

Aug. 24, 2010