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

Re: toolbar.c problem (ATTN: Duane)

by Duane Clark

Dusan Vujosevic wrote: > Hello, > > ----- Original Message ----- > From: "Duane Clark" <dclark(a)akamail.com> > ... >>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. > > > How about we test whether the button has TBSTYLE_DROPDOWN > style set and not send the message in that case??? Okay by me. I certainly did not test for that case. >>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. > > > Wine or Windows? I don't follow this / can't reproduce it under either one. Under Wine, I can make the flying toolbar stick (even with my patch) by holding the mouse button down and sliding it out of the main toolbar. Once out of the toolbar, I can let up the mouse button without the toolbar going away. Once stuck, if I simply slide the mouse across the flying toolbar, it disappears. This does not happen under Windows. Note that I have my window manager set for "focus follows mouse", which perhaps could possibly have some effect here. However, other programs I have tried with flying toolbars, including Word2000 and Acroread, do not have this problem (nor the mouseup problem), so it is not a simple generic problem. >>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. > > > I use Spy++ on it... What was the problem? I tried APIS32, but it barfed on this particular program. Unfortunately for me, my real work is once again interfering severely with the amount of time I have to spend on Wine :-( But I will try to get in a couple of tests with ControlSpy with the TBSTYLE_DROPDOWN style, since it should not take much time, perhaps this weekend.

April 18, 2002

Please educate me

by Medland, Bill

Can anyone explain what is going on here please; this is obviously an area of bash etc I don't understand. This morning I was doing a fresh install on a totally clean machine from the Wine-20020411 tarball under Redhat 7.1. All went reasonable well until I saw a "..<something not write> .." go flashing past as I ran wineinstall and later on the regapi failed because it couldn't find libntdll.dll.so. OK so I guess it was the ldconfig that failed!! So I thought "lets fix it". Yes; in the last fix to wineinstall where we went with using "su root" instead the ldconfig was hard-coded (and wasn't on the path for simply "su root"). So I followed up on the machine I normally use and started messing about with $ac_cv_path_LDCONFIG. I got that working, consistant on hand-editing the config.cache to change "true" to "/sbin/ldconfig". So the remaining thing was to get the cache entry generated correctly. This is where the problem is. (I still don't understand why it should get set either to the name of an executable or to the value "true"; I dislike variables holding dissimilar types). Anyway I was watching the loop so see why it wasn't finding the /sbin/ldconfig and I noticed that for ac_dir in /sbin:/usr/sbin:$PATH was splitting as 1. /sbin:/usr/sbin:/usr/local/bin 2. /bin 3. /usr/bin etc. Now, I know I can force it to work by changing the for loop to for ac_dir in /sbin /usr/sbin $PATH However the original form used to work (I guess, since the cache is correct on my other machine) so I'd rather know why it isn't working currently and fix that Can anyone explain why it isn't splitting the for the way we want it to TIA Bill

April 18, 2002

Re: toolbar.c problem (ATTN: Duane)

by Dusan Vujosevic

Hello, ----- Original Message ----- From: "Duane Clark" <dclark(a)akamail.com> To: "Dusan Vujosevic" <dusanv(a)cadlink.com> Cc: <wine-devel(a)winehq.com> Sent: Thursday, April 18, 2002 12:44 PM Subject: Re: toolbar.c problem (ATTN: Duane) > 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. How about we test whether the button has TBSTYLE_DROPDOWN style set and not send the message in that case??? > So > I guess Alexandre gets to pick which incorrect version to use ;) Hm :/ > 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. Wine or Windows? I don't follow this / can't reproduce it under either one. > 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. I use Spy++ on it... What was the problem? > Certainly a common > problem is that a fix in one area exposes a problem elsewhere, and that > possibly is what happened here. Probably. I am really intersted in helping track this one down (although I can work around it in SL and that's what I'll do for the time being ...). Cheers, Dusan

April 18, 2002

Re: CoGetClassObject and SHQueryValueEx A/W/AW fixxes

by Leo van den Berg

please hold this one off, i have to add some changes to Makefiles to enable a clean complete build.. (only tried incremental) will be fixxed, sorry bout this. regards, leo Leo van den berg wrote: >Cleaned up and fixxed Registry Path finding of Inprocess32 & LocalServer32, >registry entrys like '%SystemRoot%' don't break programs anymore now. >Found that SHQueryValueEx - family of functions were broken (and derived >functions as well ofcourse). Not 100% happy about the result, but it seems >to *work* now. > >any comments welcome ofcourse, > Leo van den Berg >

April 18, 2002

Re: COMI

by Sylvain Petreolle

http://appdb.codeweavers.com/appview.php?appId=121&versionId=169 --- 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: 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

Re: Installing MS Office gives error in installer

by mdew

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. > 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!" 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. Those are my thoughts anyway.. -mdew -- ph33r! Linux mdew 2.4.18-xfs #1 Sun Mar 31 15:53:58 NZST 2002 i686 unknown

April 18, 2002

Re: Urgent need for advice: POLLHUP and sockets

by Martin Wilck

Ove, 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) )) ?? 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. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 18, 2002

Re: PATCH: accept-deferred.diff (5 in series)

by Martin Wilck

On 17 Apr 2002, Alexandre Julliard wrote: > Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > > > PATCH: accept-deferred.diff > > > > If a connection request is deferred in a call to WSAAccept(), > > a subsequent accept()/WSAAccept() call must return the > > previously deferred connection rather than a new one. OK - I keep overlooking issues like that :( Thanks for spotting it. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 18, 2002

Duplication of definition of /.wine

by Vincent Béron

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? Vincent

April 18, 2002

Re: Duplication of definition of /.wine

by Marcus Meissner

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

April 18, 2002

toolbar.c problem (ATTN: Duane)

by Dusan Vujosevic

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. If other apps are were having problems with 1.106 (Duane was mentioning Acrobat Reader - I will test that..) I suggest that the problem might be elsewhere. Should I supply a patch? Cheers, Dusan

April 18, 2002

Re: IOCTL_SCSI_GET_ADDRESS implementation

by Rizsanyi Zsolt

forgot to attach the files :(

April 18, 2002

Re: Installing MS Office gives error in installer

by Hetz Ben Hamo

Hi, I suggest that if you have problems with CrossOver Office - that you should report them (with a full output text) to the CodeWeavers support site - thats why they have their ticket system which works pretty well - http://support.codeweavers.com/ (after all - if you bought a product - you deserve full support).. 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.. 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. Hetz On Thursday 18 April 2002 01:46 am, Rizsanyi Zsolt wrote: > On Wednesday 17 April 2002 21:42, Speeddymon wrote: > > I just recently installed wine-20020411 (as you may > > have noticed from my patch) > > I haven't tried installing Office 2000 on previous > > versions, but heard that it worked, so I decided to > > try it. First I tried it in Crossover Office (since i > > just recently got that also) and the Office 2000 > > installer complained that it couldnt find a package to > > install on the installation media. So I tried it in > > wine and it did the same thing... There were no debug > > messages or anything (in the console). > > > > If anyone knows of a way around this, please let me > > know... If it has been mentioned before please point > > me to the right wine-devel archive so I can find it...

April 17, 2002

IOCTL_SCSI_GET_ADDRESS implementation

by Rizsanyi Zsolt

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 - 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'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? - and of course I want comments about anything - This is my first serious patch to wine The cdrom.diff is my patch, and the ntddscsi.h is a header file created by Laurent Pinchart who is working on IOCTL_SCSI_PASS_THROUGH_DIRECT, but has not sent his patch to the list yet... Thanks in advance for your help Zsolt Rizsanyi

April 17, 2002

Re: Installing MS Office gives error in installer

by Rizsanyi Zsolt

On Wednesday 17 April 2002 21:42, Speeddymon wrote: > I just recently installed wine-20020411 (as you may > have noticed from my patch) > I haven't tried installing Office 2000 on previous > versions, but heard that it worked, so I decided to > try it. First I tried it in Crossover Office (since i > just recently got that also) and the Office 2000 > installer complained that it couldnt find a package to > install on the installation media. So I tried it in > wine and it did the same thing... There were no debug > messages or anything (in the console). > > If anyone knows of a way around this, please let me > know... If it has been mentioned before please point > me to the right wine-devel archive so I can find it... I have also dared to try to install office2k, and had the same problem. But I have found a workaround... When the installation fails, the MSI installer is already copied to your windows directory (I think its name is installmsi.exe or something like that - I dont have it at hand). So I have tried to invoke it with the msi file in the root of the CD (the data1.msi or something like that - the other msi is something else). This way the installation started. The configuration of what programs to install worked perfectly, but when copying the files the installer broke, and said that it can't write a file. I dont know what was the problem. I had enough space, the persmissions were ok, and so on. I have tried again, and the installer broke again but now with a different file. So I give up, since I don't really need it to install, just I wanted to see what the people are talking about... But if you find a solution (or submit a patch :), then I will be interested... Best regards, Zsolt Rizsanyi

April 17, 2002