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

Re: advapi32: GetNamedSecurityInfoExA Stub

by Paul Bryan Roberts

Dmitry Timoshkov wrote: > "Paul Bryan Roberts" <pbronline-wine(a)yahoo.co.uk> wrote: > >>> It appears that GetNamedSecurityInfoExA signature doesn't match >>> the MSDN/PSDK one. Also it's a common practice to simultaneously >>> add both A and W versions, and add prototypes to an appropriate >>> .h file. >>> >> Ah, right you are, thanks. >> >> I guess that should have read 'most obviously incorrect'. >> >> I cannot find any reference to GetNamedSecurityInfoEx with or without >> the A or W on http://www.msdn.microsoft.com. I have looked several >> times over the last six months or so. Is there another MSDN somewhere ? > > That's the one. I made the statement that GetNamedSecurityInfoEx doesn't > match > the MSDN/PSDK signature just looking at the existing > GetNamedSecurityInfo one. > It appears that there are some unofficial GetNamedSecurityInfoEx docs, > but if > you are using them, you should clearly point out to teh source in the patch > comment, and not copy the API description from that source. > > Does simple uncommenting of GetNamedSecurityInfoExA/W stubs in the .spec > file help? Or the installer actually calls the APIs? > >> GetSecurityInfoExW and (there is no stub for) GetSecurityInfoExA have >> prototypes in include/aclapi.h. Would that be an appropriate .h to >> add prototypes for GetNamedSecurityInfoExA and >> GetNamedSecurityInfoExW to ? > > I guess so. > >> If you would like I could add a stub for GetSecurityInfoExA too. One >> patch or two ? > > A single patch is fine. > I confirmed that the installer actually calls GetNamedSecurityInfoExA during a normal install under native WindowsTM. I set break points on the routine in the debugger that comes with the MS Debugging Tools. The debugger broke the expected 9 times between two reference break points. I first guessed the number of parameters by counting the number of push statements executed by the Wine debugger before making a call. I later used WINEDEBUG=+snoop with WINEDLLOVERRIDES=advapi32 to corroborate. I triangulated (biangulated ?) the function prototype from the prototypes for GetSecurityInfoExW() and GetNamedSecurityInfoA() that appear in wine/dlls/advapi32/security.c and took the return value from the first of those two. This is all my own work inspired by what Wine folks who have gone before me have done. Before I mustered the courage to submit the stub for the second time, I compared my prototype with that to be found at: http://www.piclist.com/techref/os/win/api/win32/func/src/f35_10.htm The third submission would not have occurred without the encouragement of Dan Kegel. I also owe thanks to Dmitry Timoshkov (oh, that's you - hi! ) for pointing me in the direction of the MS Debugging Tools. I did reference the piclist web-page in the analysis I attached to bug 14334 but accept that no one is ever likely to read it. Please confirm you don't actually want a web-page reference in the Wine source. Would that not raise "copyright-tracking" issues ?

Feb. 17, 2009

Re: GSoC 2009 coming up

by Owen Rudge

> My biggest motivation for requiring weekly status updates is that in the past > years I had a hard time following the GSoC projects I was not involved with > directly. At WorldForge, we required weekly reports to the mentor at first > and then decided that the weekly reports should go to the developer mailing > list. That kept everybody informed what was going on. I would say this seems sensible - the weekly reports would not necessarily have to be greatly detailed, but I imagine it would help to keep students on track, and would enable the rest of the community to know what's going on with the students. From experience, I would say that I probably only tended to post on the lists when I had specific problems, or patches to submit, so a weekly update would have likely resulted in more interaction. Cheers, -- Owen Rudge http://www.owenrudge.net/

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Francois Gouget

On Tue, 17 Feb 2009, James Mckenzie wrote: [...] > 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. No. Dll hell is when Application A 'upgrades' (replaces) a system dll in c:\Windows\system32, thus breaking Application B. What you describe, putting customized dlls you need in your own c:\Program Files\Xxx directory is a reaction to dll hell and is supposed to avoid it. > 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. Functions are not added at the start or end of dlls. They are just added. > 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. As far as I know Wine does not automagically fall back to Wine's implementation if a function is missing from a native dll. You need to set the dll overrides manually. It's better than having to grab backed up dlls to copy them to the program's directory like you would have to do on Windows, but not very much (for non-technical users it's really the same). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Feb. 17, 2009

Re: Wine & viruses

by Mihai Donțu

On Tuesday 17 February 2009, Martin Hinner wrote: > Hi, > > I will start one more hot discussion. Sorry if it was discussed > earlier, I am not regular reader of this mailing-list. I tried to > search google, found several discussions, but no real result: > > http://www.linux.com/feature/42031 > http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus > https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 > wine-devel mailing list google results > > The problem is that some (almost all?) distributions simply execute > .exe file when you click on it. I was amazed when testing JTAGTest on > Linux! This is in my opinion quite big issue as ordinary users do not > have problem clicking on "New folder.exe" on their flashdisk etc. It's > good that wine is so compatible that it runs even viruses, but I think > there should be some (optional) protection. The biggest problem seem > to be removable media, in many distributions mounted under /mnt or > /media. Please think about this twice before writing "problem is in > Microsoft not in Wine", "it's not a bug but feature", etc. It's too > childish IMO. > > - What about creating a configurable list of directories, where wine > would first ask if you really want to execute the program? It would be > up to distribution what is set-up by default. > > - It's long time I have been interested in viruses, but I think that > 90% of most common virus infected/trojan .exe files can be pretty > easily identified. Almost every modern virus is trying to connect to > the internet either by opening socket or using few standard DLL > functions. What about adding some checks to Wine that would check the > calling function code sample against some small database to see if > this is a virus and ask user? Or adding some "API" functions to allow > someone to write such program? I have done quite a lot of work with PE > loading and code modification and I think it could be moved to level > when it works without crashing anything. > > I understand, that none of this is system solution. But are > anti-viruses system solution? They solve real world problem. > > Regarding API I have mentioned above I mean some hookdll() function > that would re-direct GetProcAddress() or PE loader for defined > functions, i.e.: > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 > http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 > > Obviously this would have to be global for wine (libwine.so?), not as > a PE exported API function. Pre-loaded "antivirus" would be able to > hook Winsock functions + some other important stuff and then check if > the binary code is not on the list. I think that soon there will no longer be a need to hack wine in order to prevent the spread of malware. There is already work in progress on an API (a derivative of dazuko) that will allow for antivirus scanners to intercept all filesystem accesses and scan for, well, viruses. It seems to me that this is the right way to go. -- Mihai Donțu

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Dan Kegel

On Tue, Feb 17, 2009 at 8:10 AM, Rosanne DiMesio <dimesio(a)earthlink.net> wrote: > I have both Office 2003 (which also installs the private dlls) and Office 2007 on my system. I regularly use Word, occasionally Powerpoint, and I can verify that it solves a number of other bugs besides the one Dan pointed to: > > http://bugs.winehq.org/show_bug.cgi?id=15269 > http://bugs.winehq.org/show_bug.cgi?id=14041 > http://bugs.winehq.org/show_bug.cgi?id=8358 > > Now, as for the risk of making things worse: with Word 2003, I did originally encounter one minor glitch caused by the override (needed for the thesaurus): it used to trigger a popup error message about a file not found when using Insert=>Special Characters. It did not stop the feature from working (you could simply close the popup), and is no longer happening in recent versions of Wine, but it does raise the question of whether bugs triggered by using the private dll would be considered valid. > > Finally, the issue goes beyond riched20--Office 200x installs other private dlls. An override for usp10 is needed to get the equation toolbar working in Word 2007. That's good data, thanks. Now whoever implements Alexandre's suggestion has more to test against. - Dan

Feb. 17, 2009

Wine & viruses

by Martin Hinner

Hi, I will start one more hot discussion. Sorry if it was discussed earlier, I am not regular reader of this mailing-list. I tried to search google, found several discussions, but no real result: http://www.linux.com/feature/42031 http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 wine-devel mailing list google results The problem is that some (almost all?) distributions simply execute .exe file when you click on it. I was amazed when testing JTAGTest on Linux! This is in my opinion quite big issue as ordinary users do not have problem clicking on "New folder.exe" on their flashdisk etc. It's good that wine is so compatible that it runs even viruses, but I think there should be some (optional) protection. The biggest problem seem to be removable media, in many distributions mounted under /mnt or /media. Please think about this twice before writing "problem is in Microsoft not in Wine", "it's not a bug but feature", etc. It's too childish IMO. - What about creating a configurable list of directories, where wine would first ask if you really want to execute the program? It would be up to distribution what is set-up by default. - It's long time I have been interested in viruses, but I think that 90% of most common virus infected/trojan .exe files can be pretty easily identified. Almost every modern virus is trying to connect to the internet either by opening socket or using few standard DLL functions. What about adding some checks to Wine that would check the calling function code sample against some small database to see if this is a virus and ask user? Or adding some "API" functions to allow someone to write such program? I have done quite a lot of work with PE loading and code modification and I think it could be moved to level when it works without crashing anything. I understand, that none of this is system solution. But are anti-viruses system solution? They solve real world problem. Regarding API I have mentioned above I mean some hookdll() function that would re-direct GetProcAddress() or PE loader for defined functions, i.e.: http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 Obviously this would have to be global for wine (libwine.so?), not as a PE exported API function. Pre-loaded "antivirus" would be able to hook Winsock functions + some other important stuff and then check if the binary code is not on the list. Martin

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Rosanne DiMesio

> > > 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. > If you don't mind hearing from a real user... I have both Office 2003 (which also installs the private dlls) and Office 2007 on my system. I regularly use Word, occasionally Powerpoint, and I can verify that it solves a number of other bugs besides the one Dan pointed to: http://bugs.winehq.org/show_bug.cgi?id=15269 http://bugs.winehq.org/show_bug.cgi?id=14041 http://bugs.winehq.org/show_bug.cgi?id=8358 Now, as for the risk of making things worse: with Word 2003, I did originally encounter one minor glitch caused by the override (needed for the thesaurus): it used to trigger a popup error message about a file not found when using Insert=>Special Characters. It did not stop the feature from working (you could simply close the popup), and is no longer happening in recent versions of Wine, but it does raise the question of whether bugs triggered by using the private dll would be considered valid. Finally, the issue goes beyond riched20--Office 200x installs other private dlls. An override for usp10 is needed to get the equation toolbar working in Word 2007. -- Rosanne DiMesio <dimesio(a)earthlink.net>

Feb. 17, 2009

[RFC] Named Pipes emulation and interoperability layer

by Luke Kenneth Casson Leighton

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.

Feb. 17, 2009

Re: http://wiki.winehq.org/NamedPipes - documenting the samba / wine NamedPipes integration

by Luke Kenneth Casson Leighton

ok, written up as a specification - http://lkcl.net/namedpipes/namedpipes-emulation.txt: please review and provide feedback. kai, volker, you may wish to forward this to the samba technical lists. l.

Feb. 17, 2009

Re: search path redux - if office 2007 always uses a private riched20, why does wine interpose its own global one?

by Dan Kegel

On Tue, Feb 17, 2009 at 7:10 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Which version resources are you thinking of? > > The version of the native dll, compared to the builtin. I could imagine > a heuristic where if the major version of native is higher than builtin > you default to native or something like that. I'm sure there are other > possibilities too. Oh. Thanks for the hint! - Dan

Feb. 17, 2009