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 Chris Howe

2009/2/17 Alexandre Julliard <julliard(a)winehq.org> > 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. Well, no, that's the nature of dlls though. There's no guarantee that if an app supplies one to override a system dll it will make anything run any "better" than the system dll. However the app that supplies a dll most certainly expects it will get that dll, including whatever buggy behaviour it contains and may indeed rely on to work, which is why Windows lets the app hang itself with its own rope and looks there first. -- Chris

Feb. 17, 2009

Re: WINEGATE.DLL: Wine gateway to native Unix libraries

by Martin Hinner

On Mon, Feb 16, 2009 at 12:14 PM, Francois Gouget <fgouget(a)free.fr> wrote: >> From what I understand, they're not accessible to full win32 apps. > > FWIW, it's kernel32.wine_get_unix_file_name(). So it's available to any > Win32 application that knows about it. Just LoadLibrary()+GetProcAddress(). This is really nice end of our conversation, giving new dimension to all sharp statements (hack, not going into wine, etc) :-). Just to add few comments at once, the problem is solved for us (libwinegate.dll.so is shipped with the software, we'll have to recompile it when libwine/libc changes...), so there is no need for other argumentation. I have already given up. Regarding to maintenance of linux library, I meant to have different BINARY versions (because of other dependencies), not source code. And finally regarding putting WINEGATE to some wiki: Feel free to do it, consider it public domain. But I think the point of this library was that if it is compiled WITH wine package, it would smoothly solve dependency problems (i.e. no need to carry separate WINEGATE-libcX-OSy-platformZ libraries). 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 Alexandre Julliard

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. -- Alexandre Julliard julliard(a)winehq.org

Feb. 17, 2009

Re: big patch to implement SetupPromptForDisk (please comment)

by Michael Stefaniuc

Hello Ricardo, Ricardo Filipe wrote: > 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 Ahem ... git apply /tmp/0001-setupapi-implement-SetupPromptForDiskA-W.txt /tmp/0001-setupapi-implement-SetupPromptForDiskA-W.txt:25: trailing whitespace. * /tmp/0001-setupapi-implement-SetupPromptForDiskA-W.txt:254: trailing whitespace. struct PromptDiskParamsA *params = /tmp/0001-setupapi-implement-SetupPromptForDiskA-W.txt:265: trailing whitespace. struct PromptDiskParamsA *params = /tmp/0001-setupapi-implement-SetupPromptForDiskA-W.txt:373: trailing whitespace. struct PromptDiskParamsW *params = /tmp/0001-setupapi-implement-SetupPromptForDiskA-W.txt:384: trailing whitespace. struct PromptDiskParamsW *params = warning: squelched 9 whitespace errors warning: 14 lines add whitespace errors. > 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. bye michael

Feb. 17, 2009

Re: winex11.drv: Map Super_L, Super_R, and Menu keys, correctly.

by Dmitry Timoshkov

"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" > > 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. ;) http://www.winehq.org/sending_patches It's been a policy for Wine patches for a long time, in general Wine doesn't accept patches from an anonymous source. -- Dmitry.

Feb. 17, 2009

Re: winex11.drv: Map Super_L, Super_R, and Menu keys, correctly.

by Paul Bryan Roberts

> 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. ;)

Feb. 17, 2009

Re: GSoC 2009 coming up

by Kai Blin

On Tuesday 17 February 2009 04:41:11 Brian Vincent wrote: > On Sat, Feb 14, 2009 at 2:39 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > > We should also investigate possible changes to the requirements (weekly > > reports to the mailing list come to mind). Maarten, any comments? > > My gut instinct was weekly reports would be a bad idea for students - of > course they're just going to procrastinate until the last month and then do > all the work at once. Yes, Kai, I realize you were the exception to that > rule. That's not going to work anyway. There's a mid-term evaluation you're going to get failed at if you didn't produce anything until the mid-term. :) > Then my second thought was: "Hey, if this was the real world their manager > would certainly be expecting progress reports. Therefore mentors should > too." And, it makes for simple updates to include for WWN issues. I > think it'd be interesting to weekly or bi-weekly reports, but I think > mentors will need to apply a little tactful pressure in order to get the > status report updates. 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. Also, if the weekly reports don't only include "that's what I did last week" but also "this is my plan for the next week", students can get early feedback if whatever they're planning to do next looks like a bad idea to some other developer. It also helps integrating the students in the community, as they're not only talking to their mentor. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Feb. 17, 2009

Re: advapi32: GetNamedSecurityInfoExA Stub

by Dmitry Timoshkov

"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. -- Dmitry.

Feb. 17, 2009

Re: Wine talk on FOSDEM

by Chris Wulff

On Mon, 2009-02-16 at 00:16 +0000, Ricardo Filipe wrote: > > > 2009/2/15 Stefan Dösinger <stefandoesinger(a)gmx.at> > Am Sonntag, 15. Februar 2009 23:03:27 schrieb Marcus Meissner: > > Hi, > > > And my slides are here (feel free to reuse): > > > http://files.opensuse.org/opensuse/en/0/05/Fosdem2009-wine.pdf > > Just skimmed over them out of curiosity, found one mistake: > GameGuard does not > work because it is a rootkit that doesn't work with Wine by > design. > > > yeah i was just looking at that too... > all those online protection libraries still don't work, which i think > is the next step we have to take on games :p > > also the game wasn't heroes of might and magic III , it was dark > messiah :P > > the german accent gives the presentation a new horizon :D good job. :) At least for the HackShield system there isn't all that much missing. It is mainly a double handful of functions in ntoskrnl.exe and a few other bits. I've gotten that one working at least in the Ragnarok Online 2 game (with a number of less than ideal bits.) There are probably other variations on things that need to happen in other games. Here's the short list of what's missing for this one at least. Maybe this can get somebody started though I don't ever seem to have enough time to clean this up and get it in for a real patch. * Proper handling of (what I think is) shared memory. There are some things that get filled into the Peb (reactos does this as part of the csrss process I think but I'm not really sure what all is needed.) Filling in a couple blobs of empty data before the driver ioctls was enough to make hackshield happy but this needs to go somewhere else. * A pile of functions that just need to be properly implemented (kernel Mdl, WorkItem, Semaphore, Event, etc.) * Possibly some way to prioritize "driver" threads above those of the application. This one is a bit hard given the way that wine works. This may or may not actually work ok once the kernel locking objects work right (or it could be the app expects the priority to take care of it.) In this patch I am suspending and resuming some threads in the application because it crashes if some driver activities don't complete first. * There are still some crashes in the hackshield driver (caught and ignored by the try/catch block around the ioctl dispatch) that need to be investigated and fixed for it to be really fully functional as opposed to hacked up. As I said, the attached patch gets it working but still needs plenty of work. A bunch of the datatypes in wdm.h may actually belong someplace else (like wininternals.h.) The locking function implementations are wrong too as they are just abusing some of the fields to try to call existing wine functions. -- Chris Wulff

Feb. 17, 2009

Re: big patch to implement SetupPromptForDisk (please comment)

by Vincent Povirk

>From just looking at the patch (no testing or verifying the behavior on windows): You should add comdlg32 to DELAYIMPORTS, not IMPORTS, since it will be rarely needed and setupapi is used a lot. DELAYIMPORTS is like IMPORTS, but comdlg32 won't be loaded until you call a function that it provides. You should handle the A/W split by invoking the W version first and then writing the A version as a wrapper around that (converting arguments to unicode and any unicode results back to ansi). There's no need to duplicate so much code. You're using some lstr* functions instead of str* functions. The l functions are like the normal functions except that they catch invalid page faults. Unless you do not trust the pointers you are using AND you know that windows doesn't crash when they are invalid, you probably want to use the normal str* functions. I think it's safe to assume that if you use GetModuleHandle from within the module whose handle you ask for, it will succeed. In fact, I think you can simply store the module handle in a global variable when it's first loaded and use that global variable later on. (Someone correct me if I'm wrong.) Standard practice is to write tests mostly on the A version so that they can run on Windows 9x. MSDN claims the function is not available on Windows 9x; I guess it doesn't matter if that's true. You've, uh, done something weird with the whitespace around SPDRP_MAXIMUM_PROPERTY in setupapi.h. My text editor displays that line broken in the middle, but the line numbers indicate it's one line. I think this is big and new enough to warrant a new source file, perhaps a dialogs.c. (are there other dialogs in setupapi that need to be implemented?) I'm curious what happens if you tell if you're looking for a file on C: that you know exists. If it doesn't bring up a dialog, that might allow you to create a few tests that succeed. > it lacks LOTS of details though, i just implemented the juice of it and some simple details. This is EXACTLY what you should do. In fact, you may want to split some of the current details out into later patches. Vincent Povirk

Feb. 17, 2009