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