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