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

DIB Engine - Rebased on wine-1.1.14

by Massimo Del Fedele

As before, separated in 2 patches. Ciao Max

Jan. 30, 2009

Re: Reliable Datagram / Stream behaviour of NT Pipes

by Juan Lang

Hi Luke, On Fri, Jan 30, 2009 at 9:22 AM, Luke Kenneth Casson Leighton <lkcl(a)lkcl.net> wrote: > i've encountered some bugs (thanks to python again :) ) in the wine > implementation of nt named pipes, and have raised it as a bug > http://bugs.winehq.org/show_bug.cgi?id=17195 but it started getting > complicated so i thought i'd best raise it here. > the behaviour of nt named pipes is a cross between datagrams and > streams - it's the best of both worlds: > * absolute inviolate message sizes (datagrams) > * absolute inviolate message order (streams). > the issue with the implementation of nt named pipes on top of _just_ > streams (unix sockets) is this: two packets sent get blatted into one > read. You are correct. We've known about that bug for ages, but never got around to fixing it. See e.g. Mike McCormack's interview and his comments on message mode: http://www.winehq.org/interview/7 > ... i'm veery tempted to say "can i have a go at implementing this?" > but... i know it'll be ... how-to-say... eeenteresting :) > > should i try? Yes, by all means. > would an extra server message need to be added (for read), so that the > server can keep track of how much data has been read back (of the > current datagram)? Possibly. This is tricky too, because a named pipe handle can be shared across processes. You really want named pipe reads to block until a complete datagram is available. What to do with short reads is something you'd have to figure out too. Some nice C test cases would go a long way toward a correct implementation. --Juan

Jan. 30, 2009

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

by Luke Kenneth Casson Leighton

p.s. the win32 port of samba tng was originally done for wine - and reactos's - benefit. and because it'd just be utterly one-in-the-eye to be able to turn something like a P.O.S windows98 box into a Primary Domain Controller ha ha :)

Jan. 30, 2009

http://wiki.winehq.org/NamedPipes

by Luke Kenneth Casson Leighton

rob, hi, regarding the above wiki page - there is no "obstacle". you can use any of the code that i wrote for samba (about 100,000 lines of code), i released all of it into the public domain, on dec 16th, 2005. there's enough there so that you can do an entirely "hands off" approach, getting packets in and out using (see last post!) surprise,surprise, emulated named pipes. what i did for tng was to create a "packaging" system which sent security contexts (complete security descriptors and other identifiying information) over a unix socket. it was completely transparent as far as smbd was concerned, which just "handed it around" to the appropriate daemons. i asked jeremy to add in simple support for this into main samba several times. the last time (dec 2005) once _again_ he fucked about, but did actually agree that it was a good idea. 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. _several_ projects would enormously benefitted - including samba - if that had happened. sun microsystems, who bought the [well known to be a complete piece-of-crap] port of nt to unix, AFPS, for $USD 4m and were utterly appalled by the poor quality of the implementation of the smb server gave serious consideration to dumping it, keeping the MSRPC services, and riding off the back of samba.... .. via _guess what_! a named pipe "break-out" interface. which, of course, doesn't exist. so they couldn't do it. but gordon did discuss it with me, saying things like, "y'know, if samba had a way in to its named pipes interface..." and guess what? in order for you to do named pipes via samba, you need a named pipe "break-out" interface. guess how luke howard implemented XAD (which he sold to novell a couple of years ago)? he implemented a patch to samba which provided a named pipe "break-out" interface. that patch was released back in about 2002 and has never been incorporated into samba. the protocol for a break-out interface is very simple: you need four functions ( and they can be done in as little as about 300 lines of c-code, as a patch to samba) 1) open named pipe connection 2) read pipe 3) write pipe 4) close pipe if you implement that in a dynamically-loadable .so, style, as a vector table (see e.g. apache2 module interface for example) then you can dump a .so into a directory which samba can pick up. any data that comes in from SMB will then "activate" the .so, call the open_named_pipe function in the vector table, and you're away. you release the code of the .so under the LGPL, that gets "GPL'd" by samba, license problem is solved. so, with a small patch to samba, the means to take control of the direction of wine is within _your_ hands. because the dynamically loadable .so conforms to the "break-out" interface and is loaded _by_ samba, on demand, and the code in it is part of Wine and communicates using Wine protocols - entirely under your control. ... you know... it would actually be a lot easier to integrate wine with samba tng, because the infrastructure to communicate by emulated NamedPipes already exists. take a look at the following functions: ncalrpc_l_connect ncalrpc_l_close_socket receive_msrpc msrpc_send all of which are in lib/msrpc-client.c - you'll see in there that there are corresponding functions for the samba tng win32 port - CreateNamedPipe, ReadFile, WriteFile, WaitNamedPipeHandleState, CloseHandle etc. which will help give you some _really_ big clue-handles to understand the corresponding "emulating" functions using unix sockets. you _should_ also recognise the ncalrpc_srv_get_user_creds function and its equivalent client-side "sender" ncalrpc_l_authenticate. these two are a matched pair of functions which marshal and unmarshal an NT security context [based on a NET_USER_INFO_3 structure - recognise that one? :) it's a stub in wine - now you have some code that gives it purpose! ] basically after a connect (ncalrpc_l_connect) the client sends the user creds _immediately_, and the server picks them up, and saves them in its internal context (for later passing around etc). also they end up getting used to do seteuid() but as the entire protocol was used by root _only_ it was perfect safe to do this. the unix sockets were protected 600 with the directory they were in being protected 755 because some unixen _still_ bloody well let you access a unix domain socket even if its permissions were 600, all owned by root, all services running _as_ root, so one daemon being a client passing over a security context that told _another_ daemon running as root to seteuid to a user's uid was no big hairy deal. except that andrew thought that i was some sort of fucking 17-year-old incompetent student, and he didn't like the thought of me actually being a capable unix systems programmer. thus, this code could be justified as never going into samba (even though a similar implementation was designed _by_ him for use in winbind). _really_ interesting bit of hypocrisy going on there. the sad thing is that it's stopped _so_ much progress in free software, it's unreal. anyway - you can pick up that code with: cvs -d anoncvs(a)anoncvs.samba-tng.org:/home/cvsroot co tng it's anoncvs - just press return look in tng/source/lib/msrpc-client.c btw don't be fooled into thinking that just because you're on loopback - running samba and wine on the same machine and only processing requests that come in or go out over 127.0.0.1 - don't be fooled into thinking that you can throw away the security context (the NET_USER_INFO_3 stuff) - you can't. you _really_ need to keep it around, and pass it back-and-forth. so - to recap what the protocol / procedure is: * a small .so has already been dropped into samba's lib/ directory which has been dynamically-loaded; any SMB-based "NamedPipe" traffic that is NOT destined for internal samba services (such as \\PIPE\lsarpc etc) is handed to this .so. the .so, when an incoming "ConnectNamedPipe" request is made, will direct the contents, pretty much verbatim BUT pre-pending the security context "blob" (see above) to any initial connects. * any win32 programs that call CreateNamedPipe will result in a call .. ... you know what? this is getting complex - and i'm spending quite a bit of time writing it. i designed this stuff, once, and it worked. wine needs it. samba needs it. so, i'm really _really_ sorry to have to bring this up - but it's a quite important point: if you can find someone to pay for the necessary development, i'm more than happy to do the work. i'm also happy to help advise people on how this can be implemented (if the above clues and directional guides aren't enough) it's been ten years since this kind of cross-project integration stalled: i've watched the development of wine go its way, and samba go its way, and ntfs filesystem drivers for linux go _their_ way, and all of these projects don't _actually_ cooperate or link together properly. nobody's actually _paid_ any fucking money to coordinate and liase with these projects. there's people paid to work on linux; there's people paid to work on wine; there's people paid to work on samba. and the only people who really suffer for lack of this really important strategic interoperability is: users. so can we _please_ pull our collective fingers out of our arses, get some sponsorship and funding from _somewhere_ and get moving? that last said with the utmost of respect :) l.

Jan. 30, 2009

Reliable Datagram / Stream behaviour of NT Pipes

by Luke Kenneth Casson Leighton

folks, hi, if you recall, i implemented nt named pipes in samba tng, and also implemented the use of nt named pipes as a transport in freedce, for when i ported freedce to win32. so i have quite a bit of experience when it comes to nt named pipes. i've encountered some bugs (thanks to python again :) ) in the wine implementation of nt named pipes, and have raised it as a bug http://bugs.winehq.org/show_bug.cgi?id=17195 but it started getting complicated so i thought i'd best raise it here. the behaviour of nt named pipes is a cross between datagrams and streams - it's the best of both worlds: * absolute inviolate message sizes (datagrams) * absolute inviolate message order (streams). the issue with the implementation of nt named pipes on top of _just_ streams (unix sockets) is this: two packets sent get blatted into one read. you _cannot_ allow this to happen - it screws applications up _royally_, as applications _critically_ depend on the number of reads and writes being interleaved, thanks to the characteristics of NamedPipes. standard unix applications / protocols (SMTP, etc) have no choice but to do manual synchronisation built-in to the protocol, because standard unix streams don't _have_ this "free feature". so, in samba tng, the emulated-implementation of nt named pipes (on top of unix sockets) i was forced to send a (32-bit) length field actually _in_ the data stream, just like is done in NetBIOS. the NetBIOS protocol (which was implemented by IBM, not microsoft) sends a 16-bit length field followed by that exact number of bytes. again, NetBIOS implements a "reliable datagram-stream" protocol on top of standard unix streams (tcp stream, this time) inexplicably, unix simply... is ... entirely... missing this concept. so, i'm sorry to have to tell you this, but you are absolutely forced to emulate it (by sending length, data, length data), just like everyone else ever has. so, send (write) is simple: write out the length field, write out the data. done. dead simple. read is... tricky. you _may_ have to keep track of having read the length, already. or, of how _much_ has been read already, of the "current packet being read". .... *walks through source code a bit...* ... i'm veery tempted to say "can i have a go at implementing this?" but... i know it'll be ... how-to-say... eeenteresting :) should i try? would an extra server message need to be added (for read), so that the server can keep track of how much data has been read back (of the current datagram)? l.

Jan. 30, 2009

SHGetFileInfo flag SHGFI_USEFILEATTRIBUTES together with SHGFI_PIDL (regression)

by Petr Sumbera

Hi All, What is story behind following commit? This seems to broke Zoner Photo Studio (tested on OpenSolaris). According to some documentation combination of these flags is not allowed.. http://source.winehq.org/git/wine.git/?a=blobdiff;f=dlls/shell32/shell32_ma… --- a/dlls/shell32/shell32_main.c +++ b/dlls/shell32/shell32_main.c @@ -350,10 +350,6 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, (flags & SHGFI_PIDL)? "pidl" : debugstr_w(path), dwFileAttributes, psfi, psfi->dwAttributes, sizeofpsfi, flags); - if ( (flags & SHGFI_USEFILEATTRIBUTES) && - (flags & (SHGFI_ATTRIBUTES|SHGFI_EXETYPE|SHGFI_PIDL))) - return FALSE; - /* windows initializes these values regardless of the flags */ if (psfi != NULL) { --- Petr

Jan. 30, 2009

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

by Dan Kegel

On Fri, Jan 30, 2009 at 7:51 AM, Austin English <austinenglish(a)gmail.com> wrote: > How about we merge in the wine16 tests while we're at it? That would be great, if someone wants to do it, but it's kind of a pain because it currently requires the windows version of the open watcom c compiler.

Jan. 30, 2009

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

by Austin English

On Thu, Jan 29, 2009 at 11:45 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Thu, Jan 29, 2009 at 9:40 PM, Dmitry Timoshkov > <dmitry(a)codeweavers.com> wrote: >> The exception tests in ntdll is a nice example how to do that >> without hurting readability and maintainability. > > Sure, it's doable, but after a while one's fingers begin > to bleed. It all depends on how much code we're talking > about, and how many people we expect to be able to > write DOS testcases. > > Do you see any harm in using nasm? I can't imagine > it would be hard to update our list of build dependencies, > and if anybody doesn't have it for some reason, no harm done... > - Dan > > > How about we merge in the wine16 tests while we're at it? -- -Austin

Jan. 30, 2009

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

by Dan Kegel

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. 30, 2009

Re: comctl32: Fix propsheet size calculation (resent)

by Vitaliy Margolen

Alexandre Julliard wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> writes: > >> Alexandre Julliard wrote: >>> Vitaliy <vitaliy(a)kievinfo.com> writes: >>> >>>> + /* Get non-client size */ >>>> + if (!psInfo->isModeless) >>>> + { >>>> + RECT rc1; >>>> + >>>> + GetWindowRect(hwndDlg, &rc); >>>> + GetClientRect(hwndDlg, &rc1); >>>> + tabOffsetX = rc.right - rc.left - (rc1.right - rc.left); >>>> + tabOffsetY = rc.bottom - rc.top - (rc1.bottom - rc.top); >>> That doesn't make sense. What are you trying to compute here? >>> >> The size of non-client area - window borders and the title. > > Even after fixing the typos it doesn't really make sense, especially > with names like tabOffsetX. You probably want AdjustWindowRect or > something like that. > Oh, indeed. I will resubmit using AdjustWindowRect(). Thanks. Vitaliy.

Jan. 30, 2009