June 2013 - Wine-Devel - list.winehq.org

Re: ntdll: Add stub for LdrResolveDelayLoadedAPI and reference it in kernel32

by Dmitry Timoshkov

André Hentschel <nerv(a)dawncrow.de> wrote: > diff --git a/include/delayloadhandler.h b/include/delayloadhandler.h > new file mode 100644 > index 0000000..e48e415 > --- /dev/null > +++ b/include/delayloadhandler.h I don't see such file in PSDK 7.1, where does it come from? > diff --git a/include/winnt.h b/include/winnt.h > index 171141e..393f5a7 100644 > --- a/include/winnt.h > +++ b/include/winnt.h > @@ -3052,6 +3052,28 @@ typedef struct _IMAGE_RELOCATION > > #define IMAGE_SIZEOF_RELOCATION 10 > > +typedef struct _IMAGE_DELAYLOAD_DESCRIPTOR > +{ > + union > + { > + DWORD AllAttributes; > + struct > + { > + DWORD RvaBased:1; > + DWORD ReservedAttributes:31; > + }; > + } Attributes; > + > + DWORD DllNameRVA; > + DWORD ModuleHandleRVA; > + DWORD ImportAddressTableRVA; > + DWORD ImportNameTableRVA; > + DWORD BoundImportAddressTableRVA; > + DWORD UnloadInformationTableRVA; > + DWORD TimeDateStamp; > +} IMAGE_DELAYLOAD_DESCRIPTOR, *PIMAGE_DELAYLOAD_DESCRIPTOR; > +typedef const IMAGE_DELAYLOAD_DESCRIPTOR *PCIMAGE_DELAYLOAD_DESCRIPTOR; Same question here about IMAGE_DELAYLOAD_DESCRIPTOR. Besides, the structure contains namesless structure which is not compatible with some compilers and needs to be fixed. -- Dmitry.

June 6, 2013

Re: [PATCH 2/3] oleaut32/tests: Add save/load tests for created typelibs

by Marvin

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=25849 Your paranoid android. === WXPX64 (64 bit typelib) === typelib.c:2549: Test failed: cbSizeInstance = 8 typelib.c:2554: Test failed: cbSizeVft = 128 typelib.c:2556: Test failed: cbAlignment = 8 typelib.c:2631: Test failed: got 32 typelib.c:2657: Test failed: got 40 typelib.c:2682: Test failed: got 48 typelib.c:2743: Test failed: got 56 typelib.c:2791: Test failed: got 64 typelib.c:2830: Test failed: got 72 typelib.c:2869: Test failed: got 80 typelib.c:2911: Test failed: got 88 typelib.c:2947: Test failed: got 96 typelib.c:2977: Test failed: got 104 typelib.c:3011: Test failed: got 112 typelib.c:3044: Test failed: got 120 typelib.c:3080: Test failed: cbSizeInstance = 8 typelib.c:3085: Test failed: cbSizeVft = 21856 typelib.c:3086: Test failed: cbAlignment = 8 typelib.c:3105: Test failed: got 5550 typelib.c:3137: Test failed: got 5558 typelib.c:3169: Test failed: cbSizeInstance = 8 typelib.c:3175: Test failed: cbAlignment = 8 typelib.c:3196: Test failed: cbSizeInstance = 8 typelib.c:3202: Test failed: cbAlignment = 8 typelib.c:3242: Test failed: cbSizeInstance = 8 typelib.c:3247: Test failed: cbSizeVft = 56 typelib.c:3248: Test failed: cbAlignment = 8 typelib.c:3263: Test failed: cbSizeInstance = 8 typelib.c:3268: Test failed: cbSizeVft = 64 typelib.c:3269: Test failed: cbAlignment = 8 === WVISTAX64 (64 bit typelib) === typelib.c:2549: Test failed: cbSizeInstance = 8 typelib.c:2554: Test failed: cbSizeVft = 128 typelib.c:2556: Test failed: cbAlignment = 8 typelib.c:2631: Test failed: got 32 typelib.c:2657: Test failed: got 40 typelib.c:2682: Test failed: got 48 typelib.c:2743: Test failed: got 56 typelib.c:2791: Test failed: got 64 typelib.c:2830: Test failed: got 72 typelib.c:2869: Test failed: got 80 typelib.c:2911: Test failed: got 88 typelib.c:2947: Test failed: got 96 typelib.c:2977: Test failed: got 104 typelib.c:3011: Test failed: got 112 typelib.c:3044: Test failed: got 120 typelib.c:3080: Test failed: cbSizeInstance = 8 typelib.c:3085: Test failed: cbSizeVft = 21856 typelib.c:3086: Test failed: cbAlignment = 8 typelib.c:3105: Test failed: got 5550 typelib.c:3137: Test failed: got 5558 typelib.c:3169: Test failed: cbSizeInstance = 8 typelib.c:3175: Test failed: cbAlignment = 8 typelib.c:3196: Test failed: cbSizeInstance = 8 typelib.c:3202: Test failed: cbAlignment = 8 typelib.c:3242: Test failed: cbSizeInstance = 8 typelib.c:3247: Test failed: cbSizeVft = 56 typelib.c:3248: Test failed: cbAlignment = 8 typelib.c:3263: Test failed: cbSizeInstance = 8 typelib.c:3268: Test failed: cbSizeVft = 64 typelib.c:3269: Test failed: cbAlignment = 8 === W7PROX64 (64 bit typelib) === typelib.c:2549: Test failed: cbSizeInstance = 8 typelib.c:2554: Test failed: cbSizeVft = 128 typelib.c:2556: Test failed: cbAlignment = 8 typelib.c:2631: Test failed: got 32 typelib.c:2657: Test failed: got 40 typelib.c:2682: Test failed: got 48 typelib.c:2743: Test failed: got 56 typelib.c:2791: Test failed: got 64 typelib.c:2830: Test failed: got 72 typelib.c:2869: Test failed: got 80 typelib.c:2911: Test failed: got 88 typelib.c:2947: Test failed: got 96 typelib.c:2977: Test failed: got 104 typelib.c:3011: Test failed: got 112 typelib.c:3044: Test failed: got 120 typelib.c:3080: Test failed: cbSizeInstance = 8 typelib.c:3085: Test failed: cbSizeVft = 21856 typelib.c:3086: Test failed: cbAlignment = 8 typelib.c:3105: Test failed: got 5550 typelib.c:3137: Test failed: got 5558 typelib.c:3169: Test failed: cbSizeInstance = 8 typelib.c:3175: Test failed: cbAlignment = 8 typelib.c:3196: Test failed: cbSizeInstance = 8 typelib.c:3202: Test failed: cbAlignment = 8 typelib.c:3242: Test failed: cbSizeInstance = 8 typelib.c:3247: Test failed: cbSizeVft = 56 typelib.c:3248: Test failed: cbAlignment = 8 typelib.c:3263: Test failed: cbSizeInstance = 8 typelib.c:3268: Test failed: cbSizeVft = 64 typelib.c:3269: Test failed: cbAlignment = 8 === TEST64_W7SP1 (64 bit typelib) === typelib.c:2549: Test failed: cbSizeInstance = 8 typelib.c:2554: Test failed: cbSizeVft = 128 typelib.c:2556: Test failed: cbAlignment = 8 typelib.c:2631: Test failed: got 32 typelib.c:2657: Test failed: got 40 typelib.c:2682: Test failed: got 48 typelib.c:2743: Test failed: got 56 typelib.c:2791: Test failed: got 64 typelib.c:2830: Test failed: got 72 typelib.c:2869: Test failed: got 80 typelib.c:2911: Test failed: got 88 typelib.c:2947: Test failed: got 96 typelib.c:2977: Test failed: got 104 typelib.c:3011: Test failed: got 112 typelib.c:3044: Test failed: got 120 typelib.c:3080: Test failed: cbSizeInstance = 8 typelib.c:3085: Test failed: cbSizeVft = 21856 typelib.c:3086: Test failed: cbAlignment = 8 typelib.c:3105: Test failed: got 5550 typelib.c:3137: Test failed: got 5558 typelib.c:3169: Test failed: cbSizeInstance = 8 typelib.c:3175: Test failed: cbAlignment = 8 typelib.c:3196: Test failed: cbSizeInstance = 8 typelib.c:3202: Test failed: cbAlignment = 8 typelib.c:3242: Test failed: cbSizeInstance = 8 typelib.c:3247: Test failed: cbSizeVft = 56 typelib.c:3248: Test failed: cbAlignment = 8 typelib.c:3263: Test failed: cbSizeInstance = 8 typelib.c:3268: Test failed: cbSizeVft = 64 typelib.c:3269: Test failed: cbAlignment = 8

June 5, 2013

Re: cmd: Disable Ctrl-C interrupt

by Jason Edmeades

Hi Hugh, Thanks for looking at this issue with wine's cmd I do not think this patch is enough - From memory (I once tried something similar) the problem with resolving it the way you have is you then lose the ability of breaking out of a batch program. I think the right solution needs an actual handler which resets back to the command prompt mode, optionally asking something like whether you want to end the program or not (with a no continuing from where it left off, with consideration around for loops etc!). I would suggest it's better to allow control c for now rather than get into situations you cannot terminate Jason

June 5, 2013

Re: ole32: Add a basic OLE client/server test suite. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > If it's a test app meant to investigate the behavior, that's fine, but > then there's no reason to put it in the test suite. > > Just use it to figure out the behavior, and then write a proper test > that checks for that behavior using ok() and the like. At that point you > don't need traces, because the test is supposed to run unattended and > detect failures on its own, without requiring anybody to look at a > trace. My intention was to make the test look like a user32 message test at some point, and even in its current state it already can help other developers. At the moment there is no ole32 tests with a server running in a separate process, so this test would be a good start. I already have other tests which show problems in the client interacting with local server using an in-process handler, but without an initial test accepted it's impossible to add other tests. -- Dmitry.

June 5, 2013

Re: ole32: Add a basic OLE client/server test suite. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> Launching the server in responce to say CoCreateInstance is out of our >> >> control, happens behind the scene, and the server runs in its own console, >> >> so it's impossible make a simple redirection by passing in/out handles to >> >> CreateProcess. So using a pipe and a passing its write end via shared memory >> >> seems like an obvious solution. Without a mutex client and server output is >> >> messed up under Windows. Redefining trace allows to write to the pipe in >> >> the server and synchronize server output on the client side. >> > >> > Did my explanation help with understanding the reasons behind the test >> > implementation details? >> > >> >> If you have a suggestion how to simplify all of this please let me know. >> > >> > It's pretty hard to make any progress without a reponse. >> >> The easy way is to not print traces in the server, you shouldn't need >> that once your test is working. > > The whole complexity of the test is because I really need to see what > actions on the server side a client request does produce. That's the actual > reason of the test, without it the test doesn't make sense. I need to see > output of client and server in order to see why a pretty complex client/ > server COM application fails to connect to its components. My test shows > that for instance CoCreateInstance on the client side leads to interface > queries on the server side from the class factory instead of the object, > without my test I wouldn't figure that out. If it's a test app meant to investigate the behavior, that's fine, but then there's no reason to put it in the test suite. Just use it to figure out the behavior, and then write a proper test that checks for that behavior using ok() and the like. At that point you don't need traces, because the test is supposed to run unattended and detect failures on its own, without requiring anybody to look at a trace. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2013

Re: ole32: Add a basic OLE client/server test suite. Take 2.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> Launching the server in responce to say CoCreateInstance is out of our > >> control, happens behind the scene, and the server runs in its own console, > >> so it's impossible make a simple redirection by passing in/out handles to > >> CreateProcess. So using a pipe and a passing its write end via shared memory > >> seems like an obvious solution. Without a mutex client and server output is > >> messed up under Windows. Redefining trace allows to write to the pipe in > >> the server and synchronize server output on the client side. > > > > Did my explanation help with understanding the reasons behind the test > > implementation details? > > > >> If you have a suggestion how to simplify all of this please let me know. > > > > It's pretty hard to make any progress without a reponse. > > The easy way is to not print traces in the server, you shouldn't need > that once your test is working. The whole complexity of the test is because I really need to see what actions on the server side a client request does produce. That's the actual reason of the test, without it the test doesn't make sense. I need to see output of client and server in order to see why a pretty complex client/ server COM application fails to connect to its components. My test shows that for instance CoCreateInstance on the client side leads to interface queries on the server side from the class factory instead of the object, without my test I wouldn't figure that out. > But I'm sure you can find other ways, > like using a file in line-buffered mode or things like that. Think about > it some more. That would help with avoding a mutex, but mutex is a tiny part of the test. -- Dmitry.

June 5, 2013

Re: [PATCH 3/5] wined3d: Pass a wined3d_resource_desc structure to wined3d_texture_create_cube().

by Henri Verbeet

On 5 June 2013 11:22, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2013-06-05 11:06, schrieb Henri Verbeet: >> + desc.width = edge_length; + desc.height = edge_length; + >> desc.depth = 1; > Wouldn't it make sense to either set desc.height = 1 or desc.depth = > edge_length? I suppose you could make an argument along those lines, but the actual dimensions of the base mip level are edge_length x edge_length x 1.

June 5, 2013

Re: ole32: Add a basic OLE client/server test suite. Take 2.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > >> Alexandre Julliard <julliard(a)winehq.org> wrote: >> >> > It seems to be awfully complicated. In particular I don't think you need >> > a shared mapping plus a pipe plus a mutex just to log tracing >> > output. Redefining standard macros is also not a good idea. >> >> Launching the server in responce to say CoCreateInstance is out of our >> control, happens behind the scene, and the server runs in its own console, >> so it's impossible make a simple redirection by passing in/out handles to >> CreateProcess. So using a pipe and a passing its write end via shared memory >> seems like an obvious solution. Without a mutex client and server output is >> messed up under Windows. Redefining trace allows to write to the pipe in >> the server and synchronize server output on the client side. > > Did my explanation help with understanding the reasons behind the test > implementation details? > >> If you have a suggestion how to simplify all of this please let me know. > > It's pretty hard to make any progress without a reponse. The easy way is to not print traces in the server, you shouldn't need that once your test is working. But I'm sure you can find other ways, like using a file in line-buffered mode or things like that. Think about it some more. -- Alexandre Julliard julliard(a)winehq.org

June 5, 2013

Re: [PATCH] d3dx9_36: Implement ID3DXSkinInfoImpl_UpdateSkinnedMesh.

by Christian Costa

2013/6/5 Rico Schüller <kgbricola(a)web.de> > On 05.06.2013 08:48, Christian Costa wrote: > >> bone = &This->bones[bone_num]; >> + /* Decrement refcounts of vertices previously influenced */ >> + for (i = 0; i < bone->num_influences; i++) >> + if (bone->vertices[i] < This->num_vertices) /* Ignore out of >> range value */ >> + This->vertices_refcounts[bone-**>vertices[i]]--; >> bone->num_influences = num_influences; >> HeapFree(GetProcessHeap(), 0, bone->vertices); >> HeapFree(GetProcessHeap(), 0, bone->weights); >> bone->vertices = new_vertices; >> bone->weights = new_weights; >> + /* Increment refcounts of vertices newly influenced */ >> + for (i = 0; i < bone->num_influences; i++) >> + { >> + if (bone->vertices[i] < This->num_vertices) /* Ignore out of >> range value */ >> + This->vertices_refcounts[bone-**>vertices[i]]--; >> + } >> > > Please have a look at the code style (brackets {} at the for loops?). It > should be a bit more consistent. Also I think an increment (as said in the > comment) is something like "This->vertices_refcounts[** > bone->vertices[i]]++;". > Oups! It's the wrong patch. I will send an updated version. Thanks! > > Maybe you could add a test to verify if the comment or the code is correct? > Ok. I'll add a basic skinning test. I need one anyway. Vertices skinning is ok but normals one does not look the same as native. Christian

June 5, 2013

Re: [PATCH 1/2] server: Don't create new handle when DUP_HANDLE_CLOSE_SOURCE is used if possible (try2)

by Piotr Caban

On 06/04/13 21:56, Alexandre Julliard wrote: > Piotr Caban <piotr(a)codeweavers.com> writes: > >> @@ -890,6 +890,7 @@ struct rawinput_device >> obj_handle_t handle; /* duplicated handle in dst process */ >> int self; /* is the source the current process? */ >> int closed; /* whether the source handle has been closed */ >> + int reused; /* whether the source handle has been reused */ > > I don't think you need an extra flag, there's nothing the client has to > do differently in that case (the warning is mostly cosmetic anyway). > I'll send a patch with the warning message removed unless you think that it's better to keep it. Thanks, Piotr

June 5, 2013