February 2009 - Wine-devel - list.winehq.org

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
by James Mckenzie 17 Feb '09

17 Feb '09

Alexandre Julliard <julliard(a)winehq.org> wrote: >Sent: Feb 17, 2009 5:07 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one? > >Dan Kegel <dank(a)kegel.com> writes: > >> See http://bugs.winehq.org/show_bug.cgi?id=14980 >> >> Essentially, to run Office 2007, you have to set an override >> for riched20. Since Office installs a new, spiffier version >> of riched20 in its own private directory, and expects to >> find it there, isn't it a bug that we don't let it have it? > >There's no guarantee that using the private version would help. In some >cases it does, in other cases it makes things worse. So defaulting to >builtin is preferable, this way at least when it doesn't work we have a >chance of fixing it. > I think the phrase for this is 'dll hell'. That is Application A ships with and places a copy of xyz.dll in the program directory and uses it, exclusively. This was fine for some versions of Windows when xyz.dll could add in its own functions at the end of the dll and include all of the functionality of the system provided xyz.dll. However, this breaks when the system is upgraded (witness what happened to a bunch of programs when XP SP2 was released or you upgraded from Windows 3.1 to Windows 3.11, etc.). This may or may not happen with Wine because we added the ability to first call the Native xyz.dll and if a function did not exist there, call Wine's xyz.dll. This allows the Wine project to call Wine specific versions of library code and continue to use program supplied dlls. Good idea and one that should be retained. However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them. Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions. This may also be true of other programs. James McKenzie

3 2

[RFC] Named Pipes emulation and interoperability layer
by Luke Kenneth Casson Leighton 17 Feb '09

17 Feb '09

http://lkcl.net/namedpipes/namedpipes-emulation.txt this specification is intended to be implemented as a library, similar to a systems library that provides for example TCP/IP in userspace. thus it could easily be utilised by samba, samba tng, samba 4, apache runtime or in fact any POSIX-compliant system that intends to offer interoperable "Windows NT Named Pipe Emulation". the purpose of the document is to provide a guide to creating emulated implementation of Windows NT Named Pipes. implementors could use this to communicate between clients and servers inside their applications (such as the Wine application), with the added benefit that additional applications (such as the Samba application) that also conformed to the specification could interoperate. For example, the creation of a NamedPipe inside a Samba service could be talked to by a Wine client, and vice-versa. ultimately the specification _could_ potentially be used as a guide to writing a kernel-level implementation of Windows NT Named Pipes emulation. Note that this specification does NOT include "transfer of data over a network", as that task is carried out by SMB clients and SMB servers utilising SMBopenX, SMBclose, SMBreadX, SMBwriteX and SMBtrans2 subcommands 0x1, 0x26 and 0x53 to represent SetNPHS, WaitNamedPipe and TransactNamedPipe. Note that this specification does NOT have the API of the Win32 functions it is intended to emulate but is instead based very much on the design of the SMB protocols (much simplified), and thus provides an exact topological mapping of all SMB operations necessary to provide full Named Pipes functionality. Missing from the specification (but mandatory) at this time is PeekNamedPipe and GetNamedPipeHandleState, because it is clear that the functionality inside of Samba is entirely missing support for such (see call_trans2qpipeinfo in samba 3 smbd/trans2.c source code). Research WILL be required at a later stage in the form of running Win32 test applications, along with examination of the resultant network traffic, in order to determine the necessary support inside Samba for these two vital Named Pipe operations. From the design of Wine, and the stub code in smbd/trans2.c it is likely that these two functions will simply be direct mappings from NtQueryFileInformation #defines onto Trans2_QueryFileInfo, with blindingly obvious parameters and data structures to anyone familiar with both dlls/ntdll/file.c in Wine, and smbd/trans2.c in Samba. l.

1 0

http://wiki.winehq.org/NamedPipes - documenting the samba / wine NamedPipes integration
by Luke Kenneth Casson Leighton 17 Feb '09

17 Feb '09

i've been updating this page with relevant information that is part requirements specification, part documentation. of particular relevance is the lack of support (in both tng and samba 3) for transferring SetNamedPipeHandleState semantics, although the "stub" functionality inside tng (smbd/pipe-proxy.c) at least records the NP message-mode flags, and then _completely_ ignores them ha ha :) exactly how this is to be implemented is unclear, and to be absolutely honest, by far the simplest-sounding approach may be to actually compile samba up as a win32 app! under such circumstances, it would be incredibly easy to then call the wine-emulated NamedPipe win32 functions CreateNamedPipe, SetNamedPipeHandleState etc. etc. given that samba tng has _already_ successfully been ported to win32, it has a head start here. and in that regard, ReactOS has it made, done and dusted! the alternative is... gaahd, i dunno... messy, to say the least, and *shudder* an mmap'd tdb is sounding _really_ attractive. tell me if this sounds reasonable. basically, a mini-wineserver protocol - a mini-SMB protocol - is required. commands to "send", "receive", "setnamedpipestate", "waitnamedpipestate" and "close". all required. * samba 3 / tng create or access named pipes as emulations over unix domain sockets, including sending a security context. in samba 3, that's called a SamInfo3, but it looks suspiciously like a NETLOGON NET_USER_INFO_3) and in tng it's a NET_USER_INFO_3... so... yep, it looks like just the name has been changed. * a program wants to create or access a named pipe; it asks wineserver (via a new function) to create or open up a unix domain socket. the locations will be the same. i.e. tng / samba3's unix domain socket pipe locations same as wineserver's. * sending / receiving of the security context blob is done in the dlls NOT in wineserver, so as to avoid blocking wineserver. * read, write, snphs, wnphs are all done with a 2-byte command prefix, followed by parameters, followed by data. exactly the same as is done in SMB and in wineserver. ... you know... if SMB wasn't so damn complicated i'd say bugger it, just send the SMBs to Wine, for _it_ to sort out!! in fact, with cliffsd's auto-generated SMB parsing code, that might even still be a valid option, given that the relevant code for parsing the SMBs is public domain. what do people think? does this sound like a reasonable proposition - a mini SMB/wineserver protocol - for use for inter-communication between wine and samba in order to exchange named pipe traffic? l.

3 5

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
by James Mckenzie 17 Feb '09

17 Feb '09

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Feb 17, 2009 7:27 AM >To: Alexandre Julliard <julliard(a)winehq.org> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org>, Dan Kegel <dank(a)kegel.com> >Subject: Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one? > >On Tue, Feb 17, 2009 at 6:07 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Dan Kegel <dank(a)kegel.com> writes: >> >>> See http://bugs.winehq.org/show_bug.cgi?id=14980 >>> >>> Essentially, to run Office 2007, you have to set an override >>> for riched20. Since Office installs a new, spiffier version >>> of riched20 in its own private directory, and expects to >>> find it there, isn't it a bug that we don't let it have it? >> >> There's no guarantee that using the private version would help. In some >> cases it does, in other cases it makes things worse. So defaulting to >> builtin is preferable, this way at least when it doesn't work we have a >> chance of fixing it. >> > >What happened to 'bug for bug compatibility'? > Austin: These are considered private dlls as they extend functions that do not exist in the original system dll. When they are incorporated into the standard system dlls, then the new functions, and bugs, should be incorporated into the Wine versions. I think this is what AJ and Dan K are saying. James McKenzie

1 0

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?
by James Mckenzie 17 Feb '09

17 Feb '09

Dan Kegel <dank(a)kegel.com> >Sent: Feb 17, 2009 7:26 AM >To: James Mckenzie <jjmckenzie51(a)earthlink.net> >Cc: Alexandre Julliard <julliard(a)winehq.org>, "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one? > >On Tue, Feb 17, 2009 at 6:23 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> However, some programs will NOT function without their program specific dlls, and it appears that Office 2007 is one of them. Thus, it will be necessary to switch from built-in to native, built-in for this program until Wine incorporates all of the new functions. > >But in this case, the app is using a private fork of the DLL in question, >and the new functions in the private fork will probably never go >into the public one. Dan, never assume what the Evil Empire is going to do. They may or may not put this into the dlls in Windows7 (TM). Since I'm strictly Mac for now, I don't have any idea either. Maybe someone with this operating system can look into this and give us feedback, but I'm with you as this is another method of operation of this company. James McKenzie

1 0

Re: tools/winemaker: change tabs into eight spaces
by James Mckenzie 17 Feb '09

17 Feb '09

André Hentschel <nerv(a)dawncrow.de> wrote: > > Changes the spacing of the entire file. Also, if you are going to take this time, change indenting to two or four per level. James McKenzie

1 0

Re: [1/4](try 2)wininet: parse cookie information from cookie value
by Alexandre Julliard 17 Feb '09

17 Feb '09

Aric Stewart <aric(a)codeweavers.com> writes: > + ptr = strchrW(ptr,';'); > + *ptr = 0; > + ptr++; > + while (*ptr == ' ') ptr++; /* whitespace */ > + /* FIXME use LOCALE_INVARIANT when implemented */ > + if (CompareStringW(MAKELCID(LANG_ENGLISH, SUBLANG_DEFAULT), > + NORM_IGNORECASE, ptr, 6, szDomain, 6) == 2) You need to check that the next char is a valid terminator (probably '=', not sure if other values are possible). Also using strncmpiW would make the code more readable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winex11.drv: Map Super_L, Super_R, and Menu keys, correctly.
by James Mckenzie 17 Feb '09

17 Feb '09

Paul Bryan Roberts <pbronline-wine(a)yahoo.co.uk> wrote: > >> You need to generate the patch from the top of the wine directory. You >> also need to use your real name for copyright-tracking purposes. > >"copyright-tracking purposes" > That is a way of saying that we need, for legal reasons, to know the originator of each and every line of code that exists in the Wine project code base. >and there was me thinking you wanted my real name so I could take all your feedback personally. ;) > That's another reason for using your real name. However, the first reason is that if you do not supply your real name, your code will not be accepted into the project no matter how critically it is needed. James McKenzie

1 0

big patch to implement SetupPromptForDisk (please comment)
by Ricardo Filipe 17 Feb '09

17 Feb '09

hello guys. i have took the endeavour of making my first dialog patch, managed to do it this weekend, to implement SetupPromptForDisk, which i stubbed but had some problems on the stub. gave me some big headaches to make this work x) so here is the patch, i've made the two versions of the dialog, but before submiting i'd like your comments on it. what is wrong in it? in which file should it be? i left it in stubs.c but i think misc.c might be a better place. is it testable? i once asked this on IRC and got a "no" for response, is it not testable? should i put some comments? code documentation (or lack there of) is a flaw of mine... i'm hoping for your replies so that i can submit as soon as possible. i've made some tests for "manual" testing and i have tested in "A vampire Story", the game that needed the stub, and it all worked fine. yhey! it lacks LOTS of details though, i just implemented the juice of it and some simple details. regards.

3 3

Re: winex11.drv: Map Super_L, Super_R, and Menu keys, correctly.
by Paul Bryan Roberts 17 Feb '09

17 Feb '09

> You need to generate the patch from the top of the wine directory. You > also need to use your real name for copyright-tracking purposes. "copyright-tracking purposes" is there a Wiki page that explains this to the uninitiated ? I looked, did not find. Google led me straight back to the cited post on wine-devel(a)winehq.org. and there was me thinking you wanted my real name so I could take all your feedback personally. ;)

2 1