March 2007 - Wine-Devel - list.winehq.org

Re: Hardware cursor patch that does not break 'make test'.

by Stefan Dösinger

Am Freitag 30 März 2007 16:36 schrieb Andrew Riedi: > Here is the patch, opps, forgot to attach. > > On 3/30/07, Andrew Riedi <andrewriedi(a)gmail.com> wrote: > > Here is an updated patch that does not break make test. Sorry about > > sending in a bad patch, I always saw that regular make would create stuff > > in /tests dir's and thought that tested stuff. :\ Anyhow, this one > > should be fine. > > > > changelog: wined3d: Add hardware cursor support. Wouldn't you have to restore the original cursor in device::release? In general this shouldn't matter because 99% of all applications will terminate after destroying the device, but I think we should take care of that. What happens to cursorInfo.hbmMask and cursorinfo.hbmcolor after CreateIconIndirect? Is it destroyed with the cursor, or does it leak after cursorInfo, which sits on the stack, is destroyed?

March 30, 2007

re: Corrupted system.reg in clustered environment - where to look?

by Dan Kegel

Alexander.Farber at nokia.com wrote: > [I use wine on multiple machines with ~/.wine shared via NFS, > and after a while, the registry is corrupt.] Well, if it hurts, don't do it :-) Seriously. NFS is not a good place to put WINEPREFIX. In my testing, it causes serious performance problems. And NFS file locking has been broken from day 1. They keep trying to make it work, but it's never going to make you happy. So why not take the easy way out, and put WINEPREFIX on local disk? Surely you can do this. If you really need the Wine applications to share data, you can do it by creating D: or some directory in C: as a shared folder. Just don't share everything. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

March 30, 2007

Re: Stub for all raw input functions

by Kovács András

2007. március 30. 13.28 dátummal ezt írta: > "Kovács András" <andras(a)csevego.net> wrote: > > +LRESULT WINAPI DefRawInputProc( PRAWINPUT *paRawInput, INT nInput, UINT > > cbSizeHeader ) +{ > > + FIXME("(paRawInput=%p, nInput=%d, cbSizeHeader=%d) stub!\n", > > *paRawInput, nInput, cbSizeHeader); + > > + return S_OK; > > +} > > Although MSDN documents that on success DefRawInputProc returns S_OK, > that's most likely a misguided documenters error: S_OK is an HRESULT > and an OLE error value, while it's user32 and return type is LRESULT. > So IMO simply returning 0 should be OK here. > > > +BOOL WINAPI RegisterRawInputDevices( PRAWINPUTDEVICE pRawInputDevices, > > UINT uiNumDevices, UINT cbSize ) +{ > > + FIXME("(pRawInputDevices=%p, uiNumDevices=%d, cbSize=%d) stub!\n", > > pRawInputDevices, uiNumDevices, cbSize); + > > + return TRUE; > > +} > > Probably this stub should return FALSE. I decided to return this stub TRUE, because Rayman Raving Rabbids won't start otherwise. It won't hurt, because app just won't get WM_INPUT messages. > > > +UINT WINAPI GetRawInputBuffer( PRAWINPUT pData, PUINT pcbSize, UINT > > cbSizeHeader ) +{ > > + FIXME("(pData=%p, pcbSize=%p, cbSizeHeader=%d) stub!\n", pData, > > pcbSize, cbSizeHeader); + > > + return 0; > > +} > > MSDN says that an error indicator is -1, not 0, same as for others raw > input APIs. Same as the another function, I just represent, that nothing will be returned. This function won't be called, because app will call if it received a WM_INPUT message. -- ---------------------------- Kovács András (andras) NetClub Vezető Rendszergazda Lamarr csevego.net andras(a)csevego.net ----------------------------

March 30, 2007

Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.

by Tom Spear

I agree that wine should be able to run office out of the box, but I also agree with most of the developers' goals, which is to rewrite the windows api (that is my interpretation, and slimmed down at that). It is unfortunate that office doesn't work, but in order to make sure the api is clean and we replicate windows, bugs and all, we can't have hacks in the main source tree. Having more people get involved is always worth it, and ideas such as yours are not a waste of the developers' time. Unfortunately linux adoption has not become widespread enough for most people simply because the driver support for all the little gismos and gadgets is not there, and it doesnt just work, which is what most people want, and so without the LUB incerasing, the WUB will not increase. Tom On 3/29/07, Sasan Iman <iman(a)simantis.com> wrote: > > Thank you all for your replies. > > First of all, my conspiracy accusation was meant more as a joke than a > real belief. Being a hardcore engineer myself, albeit not in your > domain, I appreciate the hard work and dedication that goes into these > types of projects. > > Second, the explanation about running Office requiring special hacks > makes a lot of sense so from a technical point of view, I understand the > reason for having a side release (through Codeweaver) for running Office. > > But third, I must say that even though I agree with your general > comments that Wine is not targeted to an application but is meant to be > a core implementation, but I think having the top most used windows > software working on Wine out of the box will do wonders for its > popularity (I have no proof for this other than the fact that I > personally don't run wine because I can't run Office and I have tried > 6-7 times in the last 3 years every time hoping the new release will do > the trick). I don't know how much effort it would take to get Office > working on Wine but if getting it to work out-of-the-box means putting > it on many more systems (leading to more people getting interested, more > mileage leading to more bug reports, more people finding reason to get > involved to fix bugs, etc.) then the extra effort may well be worth it. > And let me say that Office alternatives on linux are not really a > solution at this point. For example, even though OpenOffice is good for > writing documents from scratch, documents' look and feel is different in > OpenOffice than Word and that just forces me to find a Windows machine > every time I need to open a Word document. > > I don't really know how many people like me are out there. If I am the > only one, then I am wasting your times. But if there are many others > like me, then I don't think any of you will argue against the benefits > and the priority of having Office work in the stock release. Maybe a > good way to approach this is to put up a survey or a poll on WineHQ and > ask people if they'd use Wine if software X and Y and Z was running > out-of-the-box? That way you'd also find out how many non-technical > people are following Wine to solve their computing needs. > > Thanks again for your hard works. I've been cheering you guys on for a > few years and will continue to do so. > > Sasan > > > > Brian Vincent wrote: > > On 3/28/07, Sasan Iman <iman(a)simantis.com> wrote: > >> I know that if you fiddle around with the stock release long enough you > >> can get MS Office working on Wine as I have on a number of occasions, > >> but shouldn't making this work for everyone be the highest priority for > >> getting Wine to be adopted more widely?! Or is Wine more targeted to > >> gamers which is mostly what I read about on WineHQ? > > > > CodeWeavers isn't Evil. I think everyone involved in Wine would agree > > with that. There is absolutely no question that without their > > involvement several core pieces of Wine probably wouldn't exist. For > > example, MSI, COM, MSHTML, etc. We'd probably still have a good > > Direct3D implementation though because Stefan is sick like that. > > > > As far as getting Office to work, you and everyone else are more than > > welcome to work on that. We even have a free graphical regression > > testing system (cxtest) that CodeWeavers developed that could help you > > maintain that. Personally, I'd be ecstatic if you'd be willing to > > work on that. > > > > Finally, I wouldn't exactly say Wine is targeted at gamers any more > > than anything else. > > > > -Brian > > > -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email

March 30, 2007

RE: Corrupted system.reg in clustered environment - where to look?

by Alexander.Farber＠nokia.com

Hi Alexandre, > From: ext Alexandre Julliard [mailto:julliard(a)winehq.org] > > For the standard registry files you'd have to do it in > load_init_registry_from_file() and save_branch(). It still won't > prevent one server from overwriting changes made by others of course. thanks, you are correct: the load_registry() and save_registry() aren't called in my case at all - I was modifying wrong functions. Here I've added few fprintf's: salsim04:afarber {528} wine perl -v load_init_registry_from_file(/disks/ouusers/afarber/.wine/system.reg, key) load_init_registry_from_file(/disks/ouusers/afarber/.wine/userdef.reg, key) load_init_registry_from_file(/disks/ouusers/afarber/.wine/user.reg, key) save_branch(key, /disks/ouusers/afarber/.wine/system.reg) save_branch, renaming /disks/ouusers/afarber/.wine/reg205b0000.tmp -> /disks/ouusers/afarber/.wine/system.reg save_branch(key, /disks/ouusers/afarber/.wine/userdef.reg) save_branch, renaming /disks/ouusers/afarber/.wine/reg205b0000.tmp -> /disks/ouusers/afarber/.wine/userdef.reg save_branch(key, /disks/ouusers/afarber/.wine/user.reg) save_branch, renaming /disks/ouusers/afarber/.wine/reg205b0000.tmp -> /disks/ouusers/afarber/.wine/user.reg This is perl, v5.6.1 built for MSWin32-x86-multi-thread (with 1 registered patch, see perl -V for more detail) Copyright 1987-2001, Larry Wall Binary build 635 provided by ActiveState Corp. http://www.ActiveState.com Built 15:34:21 Feb 4 2003 Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. salsim04:afarber {529} save_branch(key, /disks/ouusers/afarber/.wine/system.reg) save_branch, renaming /disks/ouusers/afarber/.wine/reg205b0000.tmp -> /disks/ouusers/afarber/.wine/system.reg save_branch(key, /disks/ouusers/afarber/.wine/userdef.reg) save_branch(key, /disks/ouusers/afarber/.wine/user.reg) save_branch, renaming /disks/ouusers/afarber/.wine/reg205b0000.tmp -> /disks/ouusers/afarber/.wine/user.reg However now I'm really lost, because I don't understand where does the file corruption occur. In my case the ~/.wine/system.reg is a regular file stored in my NFS- mounted home dir. That is why a tmp file is used and later renamed. Shouldn't that operation be atomic and if not, how could I protect it (locking a dummy file?) Regards Alex PS: BTW I've noticed a bug - the variable "count" in the save_branch() is probably meant to be static. But it is not and that's why the tmp file's name (the "reg205b0000.tmp" above) never changes.

March 30, 2007

Re: [1/2] regedit: Support the REG_MULTI_SZ.

by Byeong-Sik Jeon

oops!!! you are right. Thank you. Juan Lang wrote: > Hi Byeong-Sik, > > + lRet = RegSetValueEx(hKey, valueName, 0, type, > (LPBYTE)stringValueData, j); > > I think that should be j * sizeof(TCHAR), yes? > --Juan

March 30, 2007

Re: [1/2] regedit: Support the REG_MULTI_SZ.

by Juan Lang

Hi Byeong-Sik, + lRet = RegSetValueEx(hKey, valueName, 0, type, (LPBYTE)stringValueData, j); I think that should be j * sizeof(TCHAR), yes? --Juan ____________________________________________________________________________________ Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367

March 30, 2007

Re: Corrupted system.reg in clustered environment - where to look?

by Alexandre Julliard

<Alexander.Farber(a)nokia.com> writes: > I've tried adding file locking using fcntl() (which should > work over NFS too) by modifiyng load_registry() and > save_registry() as in the attached diff, but unfortunately > it doesn't help. For the standard registry files you'd have to do it in load_init_registry_from_file() and save_branch(). It still won't prevent one server from overwriting changes made by others of course. > Why updating registry is needed at all and can I disable > it maybe? (And where would be the good spot to do that?) If you make the WINEPREFIX directory and the registry files read-only that should prevent the server from updating them. -- Alexandre Julliard julliard(a)winehq.org

March 30, 2007

Corrupted system.reg in clustered environment - where to look?

by Alexander.Farber＠nokia.com

Hello Wine developers, we try to use Wine in clustered environment with multiple Wine processes being started simultaneously on 8 to 80 Linux machines by a modified GNU make. The source code being built is located on an NFS mount visible by all cluster machines. Unfortunately Wine fails after some time because of corrupted ~/.wine/system.reg. I guess multiple Wine processes try to update some keys in that file, like (differing) processor steppings etc. and this goes wrong at some point. Also I've noticed, that the registry is being re-saved every 30 seconds (why?) - here in wine-0.9.32/server/registry.c: static const int save_period = 30000; /* delay between periodic saves (in ms) */ I've tried adding file locking using fcntl() (which should work over NFS too) by modifiyng load_registry() and save_registry() as in the attached diff, but unfortunately it doesn't help. Does anybody have a hint where to look? Why updating registry is needed at all and can I disable it maybe? (And where would be the good spot to do that?) Thank you Alex

March 30, 2007

Re: extracting info from a minidump via winedbg

by Dennis Schridde

Am Freitag, 30. März 2007 schrieb Eric Pouech: > 2007/3/29, Dennis Schridde <devurandom(a)gmx.net>: > > Am Donnerstag, 29. März 2007 schrieb Eric Pouech: > > > Dennis Schridde a écrit : > > > > Hello Wine users! > > > > > > > > I've got a minidump from a ("real") Windows user of our game and > > > > would like to extract information from it using winedbg. > > > > > > > > > > > > The information winedbg gives me by default, is this: > > > > > > > > [...] > > > > > > > > Which is pretty rare. > > > > Via addr2line I can translate the backtrace to possibly valid > > > > locations > > > > > > in our sourcefiles. > > > > > > > > > > > > My questions are: > > > > - Why doesn't winedbg extract the sourcecode locations itself? > > > > > > because it needs the original PE files (.exe, .dll) to get to the debug > > > information > > > those files must be seated in directories listed in the _NT_SYMBOL_PATH > > > environment variable > > > > Maybe I am just doing it wrong, but > > _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp > > doesn't change anything... (Even supplying the full path doesn't.) > > The exe (not all dlls, because I don't have a copy of the user's system) > > is of > > course in the working directory. > > But the debug info is not always in the .exe itself. the .exe can contain > only a pointer to the debug info This exe was compiled using the GCC switch "-g" and was not striped afterwards, it is ~10MB big (the usual size of our app when compiled in debug mode) and winedump drops a long list of I don't know what when I run "winedump -G warzone2100.exe". > what does 'winedbg -x debug -g warzone2100.exe' give ? Usage information... winedbg has neither a -x nor a -g parameter. winedump has a -x parameter (which takes no option) and a -G parameter. It complains about not being able to treat multiple files. So you probably meant a completely different tool... > > > - Why doesn't winedbg show me the other information included in the > > > > > > > minidump, like the loaded modules, commandline options or version > > > > information? > > > > > > 'info share' should do part of it... winedbg doesn't show the command > > > line info nor options > > > > That only shows me the memory ranges of some modules. The minidump > > includes > > more info, like the paths to dlls and similar. I am not sure whether it > > includes version information, but it certainly contains the commandline > > used > > to start the app. > > > > > other thing you can do is to use winedump (man winedump) > > > > How do I do this? And what will it provide? I tried > > winedump -G warzone2100.exe > > but I have no idea what I shall do with that tremedously long and cryptic > > list. > > winedump warzone2100.mdmp This is actually useful. Things like file versions, modules and so on are printed. What's still missing (and only visible in the binary listing of "Memory ranges" is the commandline. Are there plans to make this info accessible from winedbg? Or to include things like backtrace information into winedump? --Dennis

March 30, 2007