January 2009 - Wine-Devel - list.winehq.org

Re: [patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)

by Alexandre Julliard

Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> writes: > also i have double-copies of server_set_named_pipe_info(), one in > kernel32 and another in ntdll because i am using it in both places, i > think SetNamedPipeHandleState() should be calling an NtFsControlIo > rather than using server_set_named_pipe_info() but for the life of me > i _really_ don't want to be finding out what the heck that function is > :) hmm, maybe i can find out by copying ntdll.dll over to wine and > doing a WINEDEBUG=trace+ntdll,kernel32 to see what functions get > called. > > anyway the primary purpose of submitting the patch is to ask people if > i'm along the right lines. anything seriously objectionable, etc. > etc. You can't do that stuff on the client side. You either have to do all pipe I/O in the server, or add named pipe support in the kernel. The latter is harder, but would be much more useful. -- Alexandre Julliard julliard(a)winehq.org

Jan. 31, 2009

[patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)

by Luke Kenneth Casson Leighton

http://bugs.winehq.org/attachment.cgi?id=19132 ok this is the beginnings of an implementation of messagemode, it passes the test1 and send2recv2 tests and fails the shortread test as part of PeekNamedPipe(). i'm not exactly sure why, yet. i get the distinct feeling that there's confusion over who writes into the wineserver data structures what the "availdata" is. msrpc.exe says "set availdata to 9", msrpcd.exe says "set it to 0, we did a write!" and it's all just ohhhh dear. also i have double-copies of server_set_named_pipe_info(), one in kernel32 and another in ntdll because i am using it in both places, i think SetNamedPipeHandleState() should be calling an NtFsControlIo rather than using server_set_named_pipe_info() but for the life of me i _really_ don't want to be finding out what the heck that function is :) hmm, maybe i can find out by copying ntdll.dll over to wine and doing a WINEDEBUG=trace+ntdll,kernel32 to see what functions get called. anyway the primary purpose of submitting the patch is to ask people if i'm along the right lines. anything seriously objectionable, etc. etc. l.

Jan. 31, 2009

Re: Quick and dirty testcases for MS-DOS API?

by King InuYasha

If gas is ugly and people are thinking about nasm, what about yasm? It is closer to the Intel syntax as far as assembly is concerned, and even VirtualDub has switched from MASM to YASM, mainly because they support VC debugging symbols along with regular MinGW ones. On Fri, Jan 30, 2009 at 9:50 AM, Dan Kegel <dank(a)kegel.com> wrote: > On Fri, Jan 30, 2009 at 1:37 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > > Would gas work? > > Yeah, it's a little ugly, though. > > Alexandre's right, we can add the machinery if/when we have so > much code that the array of hex approach sags. > > >

Jan. 31, 2009

Fw : BOOL WINAPI versus BOOL in d3dx9 and d3dx8

by paulo lesgaz

Hi, the declaration of IntersectionTri is BOOL IntersectionTri(.....) in d3dx8mesh.h and BOOL WINAPI IntersectionTri(.....) in d3dx9mesh.h . Is the latter one compatible with the former one (so I can forward d3dx9 function to the d3dx8 one) or must I implement them separately? David

Jan. 31, 2009

[RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.14

by Paul TBBle Hampson

>From the discussion regarding the drawStridedSlow implementation of vertex blending, what shook out was the suggestion that WineD3D will need a vertex-program fixed function vertex pipeline at some point anyway, and therefore it doesn't make sense to add another software implementation to drawStridedSlow but to instead get the vertex pipeline in place and build the vertex blending functionality on top of that. Towards that aim, I've ported Stefan Dösinger's initial implementation of this from October last year [1] to what turned out to be 1.1.14. It fails two more D3D9 tests than 1.1.14: visual.c:914: Test failed: Transformed vertex with linear vertex fog has color 0000ff00 visual.c:986: Test failed: Transformed vertex with linear vertex fog has color 0000ff00 (I don't know if these failed when it was first implemented, so I don't know if the problem is the patch, the port, or even the test. This is on my nVidia 8600 w/180.22 binary drivers, in case it makes a difference.) I haven't run it with any games yet, or profiled it. Stefan's commented since that it was slower than the current system, albeit unoptimised, and that was the reason he didn't undertake any further work on it. I don't know what games use the fixed-function pipeline, so I'm open to suggestions and bug report references. All but the last patch in this tarball are ports of Stefan's original, and were done using git-am so still retain his original headers. The sorta-nasty no_d3dcolor_swizzle code in get_color and its caller in the last patch is entirely my fault though. ^_^ The last patch is actually also from Stefan's code, but it's an attempt by me to reinsert fog code I have removed, possibly incorrectly. However, it didn't fix the above fog failures, so I left it as a separate patch. I'm not totally sure I've got all the hard parts of the port right. The two relevant changes since these patches were applied were the implementation of EXT_vertex_buffer_bgra and the rearrangement of the fog code. For EXT_vertex_array_bgra and vertex_pipe->can_convert_d3dcolor, I'm not sure if there are places that check one and should check the other, and I'm not sure if the test in state.c line 4280 (streamsrc) is doing the right thing. I think it is doing the right thing. The vertex program recognises and handles a position_transformed vertex declaration itself. Of the original 13-patch series, patches 4 and 5 were rendered completely uninteresting by the fog changes, and 7 and 13 had already gone into the main tree. There was also what I believe was a bug in patch 2, which basically left pCaps->MaxUserClipPlanes uninitialised rather than fetching the value from the vertex_pipeline's get_caps method result. Anyway, here it is. I hope this is of benefit to someone. The next thing I plan to do with this is try and wrap my head around the internals of the arbvp vertex program so I can implement vertex blending there. [1] http://www.mail-archive.com/wine-devel(a)winehq.org/msg49501.html -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE Very-later-year Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson(a)Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.5/au/ -----------------------------------------------------------

Jan. 31, 2009

Running the fusion tests

by Paul Vriens

Hi, I didn't look into this yet but currently the fusion tests are only run on Wine. I can happily run the fusion tests on my XP box if I just crossbuild these tests. It's only when run through winetest that these tests are not run. I guess it has to do with how this library should be loaded (not directly through LoadLibrary)? -- Cheers, Paul.

Jan. 31, 2009

Re: http://wiki.winehq.org/NamedPipes

by Luke Kenneth Casson Leighton

> Funny enough, the Samba project codenamed "franky" > (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not > quite there yet, but after some nice work done in the Samba3 smbd by Volker > Lendecke and some more work in the Samba4 "samba" daemon by Stefan > Metzmacher, Jelmer Vernooij and some overall effort by other folks from the > Samba Team, franky is coming along quite well. kai, thinking about this some more (hi volker, nice to see you're still working on this stuff!) i just want to emphasise a few things: 1) i really am absolutely delighted that a break-out mechanism has been added to samba, for many many reasons 2) you will also need to add a break-out mechanism for the entire IPC$ channel, along the same architecture lines, for exactly the same reasons. wine and other systems have their _own_ implementations of NetUserGetInfo and other functions; in combination with the code in cliffsd (which is again public domain and was written from taking the IPC spec document and using it as an IDL file!) it will be possible for wine add IPC$ functions to WineServer with minimal coding effort on the part of the Wine Developers. the way that i implemented this (or maybe planned to - looking at the code i don't see it. odd. oh well!) in samba tng was to create a daemon called "lanmand", which received an authentication context "blob" (effectively a marshalled NET_USER_GET_INFO_3 structure aka a SAMR_USER_INFO_21), and the functions where the "break-out" occurred were on SMB_TransactNamedPipe, SMB_ReadX, SMB_WriteX and SMB_Close on anything that's an IPC$. think about it: the wine team have to get notifications to wineserver of events such as WaitNamedPipeState, SetNamedPipeState etc. etc. and the only way to do _that_ properly is if they receive proper notifications. it's made a little more complex unfortunately in that _some_ of the data needs to go to the LANMAN break-out mechanism, and _some_ of the data needs to go into the DCE/RPC IPC$ stuff. ohhh, no it isn't: it's actually very simple: i forgot - there's a PIPE named LANMAN, isn't there? :) so, actually, it might be simpler than i thought, in that WineServer could simply have its own LANMAN pipe service (bypassing the one that's hard-coded in smbd). ... you'll work it out :) 3) the strategic importance of the "break-out" mechanism cannot be underestimated. by not implementing a break-out mechanism for all these years, samba has effectively been operating under a "proprietary implementation" shadow, made all the more worse by the fact that the source code is GPL'd and so it _looks_ like it's free software. free software projects, as the trolltech code base and other examples showed by being effectively a "one-way-push" instead of a "collaborating encouraging community project", are not just about "freeing the code", when it comes to multi-man-decade efforts such as samba, wine, reactos etc. it's your _responsibility_ to ensure that there are interfaces where other projects can interoperate. otherwise, you are doing _exactly_ what microsoft has been doing - shutting the door in people's faces by not allowing them to interoperate along clearly-defined interface boundaries. and that's the primary reason why i was so pissed off with what was going on in samba. you weren't just shutting out samba tng by not adding in the break-out mechanism, you were shutting _everybody_ out - wine, reactos, embedded NAS storage devices, sun microsystems, _everybody_ who wanted to use smbd's expertise as a service that could be improved on _every_ single one of them was shut out - and thus you've been _pretending_ to serve the free software community.... ... up until now, when you are now, finally, _actually_ serving the free software community. which is why, and i cannot say this enough times, nor emphasise it enough, that it's such a big damn deal to have this interoperability interface. so - keep it up, and xxxxing well done! oh - did andrew bartlett complete that authentication plugin interoperability interface? because that's another critical / crucial area that needs to be .so dynamically-loadable (a la pam) so that it can be "broken out of", as well. wine and reactos will need that at some point (actually, they'll probably need it at exactly the same time as implementing a \\PIPE\LANMAN and \\PIPE\<generic_service>) l.

Jan. 31, 2009

Re: Reliable Datagram / Stream behaviour of NT Pipes

by Luke Kenneth Casson Leighton

juan, hi, >> Some nice C test cases >> would go a long way toward a correct implementation. > > ok, then that's where i'll start. i've got a qemu'd xp so i can > actually test that they work properly on nt. > > i've just dragged the tng source code out of cvs, first time in ages, > so there's plenty there to work from, really quite quickly. http://bugs.winehq.org/attachment.cgi?id=19121 ok - i documented how to use the test code, in the bugreport. i'll extend it later, to cover the cross-process things you mentioned. short reads etc. one test i'm looking forward to adding is passing a 4-byte handle as a "number" over to another process and trying to use that :) are there any tests of any kind, for NamedPipes? i don't mind writing some weird test cases if it would help. opening pipes read-only and writing to them, that sort of thing. ohh i nearly forgot about transactnamedpipe - got to add that, too - it'll again be absolutely essential for samba-integration. l.

Jan. 31, 2009

Re: http://wiki.winehq.org/NamedPipes

by Luke Kenneth Casson Leighton

On Sat, Jan 31, 2009 at 9:50 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > On Friday 30 January 2009 19:38:20 Luke Kenneth Casson Leighton wrote: > >> samba having "break-out" for named pipes traffic is one of those >> absolutely _essential_ things that should have fucking well gone into >> the samba source code a _long_ time ago. around 1998 would have been >> good. > > Funny enough, the Samba project codenamed "franky" > (http://wiki.samba.org/index.php/Franky) will be doing all of this. It's not HOOORAAAAAY! time for a celebration. nearly a decade waiting for that stuff. that's really good news - thank you, kai.

Jan. 31, 2009

Re: New Coverity run

by Paul Vriens

Marcus Meissner wrote: > On Fri, Jan 23, 2009 at 09:44:45PM +0100, Paul Vriens wrote: >> Hi, >> >> I've been in touch with David Maxwell and he looked into the 'lack' of >> reports since the end of October. > > And there is now Run 278 :) > > Ciao, Marcus Hi, We even have a run 280 now but it seems that Coverity didn't fetch the new source to check against. I've sent David Maxwell an email about this. -- Cheers, Paul.

Jan. 31, 2009