April 2002 - Wine-Devel - list.winehq.org

Re: COMI

by Sylvain Petreolle

--- Johan Gill <johane(a)lysator.liu.se> a écrit : > I test Curse of Monkey Island now and then, and with > the latest CVS > update, and some before, starting the game yields a > black screen. However, > moving the mouse around causes > err:ntdll:RtlpWaitForCriticalSection section > 0x40360be8 "?" wait timed > out, retrying (60 sec) fs=027f > and when the debugger starts later on the game > starts. > > Any ideas? > > /Johan Gill, johane(a)lysator.liu.se > > ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

April 18, 2002

Re: toolbar.c problem (ATTN: Duane)

by Duane Clark

Dusan Vujosevic wrote: > Hi, > > I am having a problem with the way toolbar.c was modified between > revisions 1.107 & 1.108. My application (Signlab) pops flyout toolbars > that stay around until they lose focus. The parent toolbar receives a > 'TBN_DROPDOWN' message when someone clicks on one of its flyout buttons > (button style: TBSTYLE_DROPDOWN). It creates a flyout at that point. > > With revision 1.108 of toolbar.c in Wine the parent toolbar also > receives an WN_COMMAND after TBN_DROPDOWN message which causes Wine > (rightly so) to send an WM_SETFOCUS (and WM_ACTIVATE). That causes the > parent to regain focus and kills the flyout. The line that sends > the WN_COMMAND is in toolbar.c at line 4540 (TOOLBAR_LButtonUp() function): > SendMessageA (infoPtr->hwndNotify, WM_COMMAND, > MAKEWPARAM(infoPtr->buttons[nHit].idCommand, 0), (LPARAM)hwnd); > In revision 1.107 it used to be: > > if (bSendMessage) > SendMessageA (infoPtr->hwndNotify, WM_COMMAND, > MAKEWPARAM(btnPtr->idCommand, 0), (LPARAM)hwnd); > > And that worked fine because it would never send WM_COMMAND for a flyout > button. Note that WinXP (that's where I tested) doesn't send WM_COMMAND > after TBN_DROPDOWN has been handled. I would like to suggest revert that > line back to 1.106 because it is the correct way. It is not "the correct way", since I have tested it with control spy under WinNT and Wine. That is not to say that my patch is correct either, but it fixes two different applications I have and in my mind is closer to the correct way. There may well be some conditions under which the message should not be sent, but the previous way was not correct. So I guess Alexandre gets to pick which incorrect version to use ;) And there is more going on in your app, because the flying toolbars also disappear when the mouse is simply slid over them, without clicking. This behavior is not there under Windows, and has nothing to do with the ButtonUp change I made. The two may not be related, but I cannot help thinking they are. Unfortunately, I was not able to get a spy program to work with your app in windows, so I have not been able to figure out what messages should really be sent, and when. Certainly a common problem is that a fix in one area exposes a problem elsewhere, and that possibly is what happened here.

April 18, 2002

Re: Duplication of definition of /.wine

by Vincent Béron

Marcus Meissner a écrit : > > On Thu, Apr 18, 2002 at 02:07:25AM -0400, Vincent Béron wrote: > > I was looking for the place in the source where the ~/.wine directory > > was defined, and it turns out it's defined twice: once in > > scheduler/client.c, the other one in server/request.c. > > There's also some duplicated code: the function get_config_dir is > > defined in both of these files, and none is static. And both > > implementation are identical. Is it normal? Do they go in the same > > executable or in different ones (which ones)? I thought we would rather > > try to avoid duplication of code, no? > > They go into different binaries, one into the wineserver, one into the wine > executable. > > Ciao, Marcus Wouldn't it be possible to separate the common code (a couple #defines, plus get_config_dir) in a shared header? Vincent

April 18, 2002

COMI

by Johan Gill

I test Curse of Monkey Island now and then, and with the latest CVS update, and some before, starting the game yields a black screen. However, moving the mouse around causes err:ntdll:RtlpWaitForCriticalSection section 0x40360be8 "?" wait timed out, retrying (60 sec) fs=027f and when the debugger starts later on the game starts. Any ideas? /Johan Gill, johane(a)lysator.liu.se

April 18, 2002

Replacement of browser component (Internet Explorer/IE

by Andriy Palamarchuk

Hi everybody, I just created a bug in bugzilla for subj.: http://bugs.codeweavers.com/show_bug.cgi?id=587 I don't think everybody tracks the wine-bugz mailing list, so I decided to announce this project on wine-devel. You are welcome to add information to the bug, create subprojects, start to work on it ;-) I'm especially interested in status of work on jscript component. I did not attend Wineconf and could not find details online. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/

April 18, 2002

Re: Installing MS Office gives error in installer

by Jeremy White

> > cheaply? Im sure this is an OOS Project, are we all leaches upon the > linux community?...I feel a little cheap since I downloaded a couple of > Debain ISO's without paying for them. We use Wine to test out Windows > Apps in Wine...so its no great surprise Office 2000 has become an issue. > > > This is the same issue for Transgaming's WineX - want to run full game? then > > subscribe and support them please.. > > > > And if you want to flame me - my email is right here - fire away. > > Scenerio: What *If* I (or someone else) had a few sane bug fixes, that > allowed Office 2000 to work? What would happen?, "Umm sorry we cant > commit this....because we feel you're too cheap to buy Codeweavers great > product!" I want there to be no question on this issue. In no way do we intend or do we ever desire our work to harm or impede the forward progress of the Wine project. There is no way I would demand that Alexandre reject a patch and you wouldn't want to hear what he would say to me if I I made such a demand <grin>. > > Fixing Issues such as getting Office 2000 to work should be in the same > catagory as fixing support for any other App using wine. And it > *shouldnt* be delyed just because it "Office 2000". Im Getting the > feeling the codeweavers is failing to commit any code that would promote > any *decent* workable progress of Office 2000 using Wine CVS. > With all due respect, I resent the implication that we are deliberately crippling the public Wine CVS tree. We have merged nearly all of our code (there are pieces of it that have not been merged, but only because they are unforgivable hacks that Alexandre will not commit.) As a consequence of our work, Office and a wide range of applications now work far better than they have ever done. Now, I will say that our first priority is, and always will be, focusing on our customers and making sure that Wine works well for them. So, no, we will not rush out and focus on polishing the Wine CVS to the same level we offer our customers. But impede it? We would rather go out of business first. Cheers, Jeremy

April 18, 2002

Using WineLib directly

by Zavada, Ed

I've seen this question asked before, but there was never a response to the newsgroup. We'd like to use WineLib to provide implementations of the Windows calls in our application's Linux build while we work on a full blown port. So far, all the documentation requires that we use winebuild and generate a .so that is loaded by the wine server. Is this truely the only way to do this? Is there no way to just use the various libraries independent of wine server? For instance, I'd like to be able to make a call to MessageBox() from a native linux binary, then later eliminate the need for it (since this will ultimately be a console app). Thanks, Ed Zavada Lead Server Engineer The Sims Online Maxis East

April 18, 2002

SV: Installing MS Office gives error in installer

by Christian Jiresjö

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >On Thu, 2002-04-18 at 11:39, Hetz Ben Hamo wrote: >> As for others who tries to install Office 2000 with Wine CVS - >> nice try, but you'll need to do tons of tricks in order to >> install it. running: wine setup.exe won't do the trick. If you >> want to run Office 2000, then please don't behave cheaply - go >> pay the $50 to Codeweavers for their excellent product - they >> give all their modifications back and your money supports them in >> order to continue developing Wine.. >cheaply? Im sure this is an OOS Project, are we all leaches upon the >linux community?...I feel a little cheap since I downloaded a couple >of Debain ISO's without paying for them. We use Wine to test out >Windows Apps in Wine...so its no great surprise Office 2000 has >become an issue. I think his point was that codeweavers is doing a good job which includes giving back to the mother project and deserve to get paid for it. No one is forcing you to pay for anything that is opensource but even people who work on opensource have to eat. >> This is the same issue for Transgaming's WineX - want to run full >> game? then subscribe and support them please.. >> >> And if you want to flame me - my email is right here - fire away. >Scenerio: What *If* I (or someone else) had a few sane bug fixes, >that allowed Office 2000 to work? What would happen?, "Umm sorry we >cant >commit this....because we feel you're too cheap to buy Codeweavers >great product!" I have no doubt that they would be accepted by everyone including codeweavers. If you have such fixes then post them and discover. >Fixing Issues such as getting Office 2000 to work should be in the >same catagory as fixing support for any other App using wine. And it >*shouldnt* be delyed just because it "Office 2000". Im Getting the >feeling the codeweavers is failing to commit any code that would >promote any *decent* workable progress of Office 2000 using Wine >CVS. Codeweavers give stuff back in a pace that is okay with them. Just as the rest of the companies involved in winedevel gives back in their pace. Wine is probably not strong enough market to live on that writing customsolutions for companies can be the only source of income. Codeweavers have to make money to live as well so why should they be singled out to give all their code back rigth now and not someone else just because their product involves an app that some people consider a killer app. Only reason for choosing them might be that they were pro LGPL switch Why don't you blame transgamming for sitting on their code untill they are paid for it or xandros and lindows for what ever they keep from commiting. Those are my thoughts. >Those are my thoughts anyway.. >-mdew Mvh Christian Jiresjö Key ID / Fingerprint 0x7798D5A3 / 2743 5DC4 1618 F24C F265 3070 A070 5EF2 7798 D5A3 -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBPL69YqA7mjo2YYwkEQKnbgCeLTeSceRTZEg0Qx2LryQuvyUcejEAmwf1 0heEolUtZ9u/aUxFlpOtSOZA =8CH5 -----END PGP SIGNATURE-----

April 18, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Ove Kaaven

On Thu, 18 Apr 2002, Martin Wilck wrote: > can you comment on this line in sock_reselect: > > /* previously unconnected socket, is this reselect supposed to connect it? */ > if (!(sock->state & ~FD_WINE_NONBLOCKING)) return 0; > > Was this a short way of expressing > > if ( !(sock->state & (FD_READ|FD_WRITE|FD_OOB|FD_ACCEPT|FD_CONNECT|FD_CLOSE| > FD_WINE_LISTENING|FD_WINE_CONNECTED|FD_WINE_RAW) )) > > ?? Sort of. The FD_WINE_NONBLOCKING is the only flag that doesn't mean that the socket should enter the poll loop. (Putting a newly created (unused) connection-oriented (TCP) socket into the poll loop means POLLHUP on Linux 2.4, which is obviously bad.) FD_READ | FD_WRITE | FD_OOB: the socket is ready for data traffic (datagram socket or connected stream socket), should be polled FD_ACCEPT: the socket is listening, should be polled FD_CONNECT: connection is in progress, should be polled FD_CLOSE: not used, but would have meant should be polled for closes FD_WINE_LISTENING: same as FD_ACCEPT FD_WINE_CONNECTED: connected socket, should be polled FD_WINE_RAW: a raw socket is a datagram socket, always pollable FD_WINE_NONBLOCKING: API control flag, not a socket state, should not affect polling > Rationale: I have been adding new flags (FD_WINE_SEND_SHUTDOWN, > FD_WINE_RECV_SHUTDOWN) and my guess is they (being internal) should be > treated like FD_WINE_NONBLOCKING here, but I'm uncertain. If these are API control flags (like the nonblocking flag) and it should be able to set them without putting the socket into the main poll loop, then you should treat them like that, but if the flags convey state and can only occur on already-connected sockets, then there's no reason to check for them.

April 18, 2002

Re: IOCTL_SCSI_GET_ADDRESS implementation

by Eric Pouech

Rizsanyi Zsolt a écrit : > > Hi! > > I have implemented IOCTL_SCSI_GET_ADDRESS for non scsi cdroms. On NT this > ioctl is called on non scsi cdroms, and it should return a valid value. NT > treats the two ide controllers as scsi (at least for this ioctl). > The program which uses this ioctl, when the ioctl returns with success it > tries to read further data from the registry, from the > Machine\\HARDWARE\\DEVICEMAP\\Scsi > > I have looked at the registry of my w2k and I'm trying to set up according to > it the registry of wine. > > But I have some implementation questions: > - I'm setting up the registry in the CDROM_Open (in dlls/ntdll/cdrom.c). This > is right, because before that no ioctl could be called, but maybe I should > setup it when the devices are initialized (then of course only for the cdroms > where the Device is specified in configuration), to ensure initialization > only once, and not at every CDROM_Open two remarks here: - first of all, it would be better to move this at the drive initialisation time in files/drive.c. However, this will be done for every process started in a given session, which is not optimal (but better than each time a cdrom is opened) - another point, your code uses the Reg??? API functions to handle the registry. However, to implement correctly the DLL separation, as cdrom.c (and files/drive.c) reside in ntdll.dll they cannot use the Reg??? functions, located in advapi.dll (forwarded from kernel32.dll). You have to use the Nt???? equivalent (see dlls/ntdll/reg.c and dlls/advapi32/registry.c for the details) . > - I'm having problems with the refreshing of the registry. If I delete the > previously entered registry entries from system.reg, and run the (windows) > regedit, then at start I dont have the Scsi registry key. But if I select > ImportRegistry then the FileOpenDialog opens the cdrom, and from the debug > messages I know that the data were entered to the registry, but regedit does > not show it even if I press F5 (or select the Refresh menu) > Why is this? I know that there are VOLATILE registry keys, but dont know if > they apply here, and to how to use them... I don't know what regedit uses (I mean does it re-read the user.dat file - or any equivalent -, or does it use the RegXXX functions. If the later, this shouldn't happen, if both processes (regedit and the former) use the same server. However, Wine uses two sets of registries: its own (normally in ~/.wine/*reg) and the optional standard & native windows file. Wine never rewrites the later and always update the former. All the registry information is stored inside the server. There is some parameter in the config file to tell the server when to save the changes to the wine registry files. What could happen is that you try to access information that has not been saved yet. Anyway, you'd better use the regedit from programs/regedit to get the current information inside the current wine session > - I'm using some includes like linux/hdreg.h linux/major.h and sys/stat.h > (fstat function) - where and how to add checks for them? Is it enough if I > add those headers to the list in configure.ac? you should add the checks in configure.ac as done for linux/cdrom.h A+

April 18, 2002