wine-devel November 2001

65 participants
144 discussions

__p___argc, MSVCRT,__wine_get_main_args and ParseOptions
by Uwe Bonnes 04 Dec '01

04 Dec '01

Hallo, running with builtin msvcrt like > wine --dll msvcrt=b a.exe for the following source: #include <stdio.h> #include <stdlib.h> #define _stat stat int main( void ) { printf("%d\n",__p___argc()); printf("%d\n",*(__p___argc())); return 0; } still counts _two_ arguments, as it sees "wine a.exe". OPTIONS_ParseOptions,__wine_get_main_args and __wine_get_wmain_args are very delicate stocked on each other, so I don't know which one to change. For a short test I did hertz:/spare/bon/wine-clean> cvs -d $CVSROOT diff -u wine/misc/options.c Index: wine/misc/options.c =================================================================== RCS file: /home/wine/wine/misc/options.c,v retrieving revision 1.29 diff -u -r1.29 options.c --- wine/misc/options.c 2001/11/06 00:49:48 1.29 +++ wine/misc/options.c 2001/11/20 20:18:44 @@ -356,8 +356,8 @@ */ int __wine_get_main_args( char ***argv ) { - *argv = app_argv; - return app_argc; + *argv = &app_argv[1]; + return app_argc-1; } (leaving aside __wine_get_wmain_args for the moment) and was able to run some programm that didn't run before. Can anybody help with the right fix? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 4

Re: Proposed solution for mouse capture problems
by Alexandre Julliard 03 Dec '01

03 Dec '01

Jukka Heinonen <jhei(a)iki.fi> writes: > 1. Function process_raw_mouse_message should only determine which > window was under mouse and resend message to that window as > a cooked message. Everything else (especially separating normal > messages from nonclient messages and handling mouse captures) > should be moved to process_cooked_mouse_message. Actually, > I fail to see why raw messages are needed at all, since function > SendInput could do this as well. No, processing raw messages requires sending messages to the app (mainly WM_NCHITTEST) and you cannot do this from anywhere. Also if you separate the window determination from the rest you'll have to send two WM_NCHITTEST for every message which is clearly wrong. Maybe what we should do is when the cooked message is rejected by the message filter it should be queued back as a raw message and processed again next time around. > 3. Supporting multi-threaded capture is actually the easiest part, > although it might be quite useless (Does any application really > require it?). When mouse button is pressed in capturing window, > process_cooked_mouse_message sets process-wide flag that states > that global capture is in effect. After that, either > process_raw_mouse_message or SendInput sees that this flag is > set and resends all mouse messages to capturing window until > button release message is received, which clears the flag. I'm not sure what you are trying to fix here. This should already work fine, X takes care of sending messages to the right thread when mouse is captured. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Is there a good reason why we ...
by Alexandre Julliard 30 Nov '01

30 Nov '01

"Bill Medland" <medbi01_1(a)accpac.com> writes: > Is there a good reason why we have to specify the full correct path to a dll > in the dll overrides section if it isn't in the windows system? Because you can have multiple versions of the same dll in different directories, and we need a way of distinguishing them. For instance an app may include its own version of shell32 in its private directory, and you want to be able to switch this one to builtin without impacting other apps using the standard shell32. There may be better ways to provide this feature though, suggestions are welcome. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Gerard Patel 30 Nov '01

30 Nov '01

At 09:35 PM 29/11/2001 -0800, you wrote: >*Doesn't this fix the problem in Word where if you have multiple >documents open and you switch between them, you can't use the menu bar >any longer?* Sorry, I don't know. I doubt it, since in mdi code it is stated that Word does not use MDI. Of course the comment has been here for a long time and could be obsolete, but I doubt that Ms could have switched Word to use MDI since they have obsoleted MDI since a long time. Gerard

1 0

Re: [PROBLEM REPORT] Focus problem for mdi children
by Michael Cardenas 30 Nov '01

30 Nov '01

*Doesn't this fix the problem in Word where if you have multiple documents open and you switch between them, you can't use the menu bar any longer?* ------------------------------------------------------------------------------- * From:* Alexandre Julliard (/ julliard(a)winehq.com/ <mailto:[email protected]?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%[email protected]%3E> ) *Date:* Wed Nov 07 2001 - 19:46:37 EST * ** Gerard Patel <gerard.patel(a)nerim.net <mailto:[email protected]?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%[email protected]%3E>> writes: > Using this patch : > --- winpos.c.orig Wed Nov 7 10:41:32 2001 > +++ winpos.c Thu Nov 8 00:44:29 2001 > @@ -955,7 +955,20 @@ > ShowCaret(winpos->hwnd); > } > > - if (!(winpos->flags & SWP_NOACTIVATE)) SetActiveWindow( winpos->hwnd ); > + if (!(winpos->flags & SWP_NOACTIVATE)) > + { > + SetActiveWindow( winpos->hwnd ); > + if (!(wndPtr = WIN_FindWndPtr(winpos->hwnd))) return FALSE; > + > + /* child windows get WM_CHILDACTIVATE message */ > + if( (wndPtr->dwStyle & (WS_CHILD | WS_POPUP)) == WS_CHILD ) > + { > + WIN_ReleaseWndPtr(wndPtr); > + SendMessageA(winpos->hwnd, WM_CHILDACTIVATE, 0, 0L); > + } > + else > + WIN_ReleaseWndPtr(wndPtr); > + } > > /* And last, send the WM_WINDOWPOSCHANGED message */ > > > seems to fix the problem. It may be too simple though :-) No actually it's pretty much the right thing. I have applied a slightly simplified version of your patch, thanks for the report. -- Alexandre Julliard julliard(a)winehq.com <mailto:[email protected]?Subject=Re:%20%5BPROBLEM%20REPORT%5D%20Focus%20problem%20for%20mdi%20children&In-Reply-To=%[email protected]%3E> -- //------------------------------------------ Michael Cardenas Software Engineer Lindows.com, Inc. http://www.lindows.com 858-410-5950 619-972-8153 //------------------------------------------- --

1 0

Is there a good reason why we ...
by Bill Medland 29 Nov '01

29 Nov '01

I've just tripped over this again which reminded me to ask why we do it. Is there a good reason why we have to specify the full correct path to a dll in the dll overrides section if it isn't in the windows system? A program runs at some location on the path. It uses a dll which is in the same directory. I want explicitly to use a winelib builtin "dll" instead of it. I can't simply say "a4wwine"="builtin"; I have to use the full path. That would cause problems if the exe and dll moved. Is there a good reason for this behaviour? (i.e. would it be a waste of my time changing the dll override stuff?) Bill

1 0

FoxPro 5 Applications
by Rick Romero 29 Nov '01

29 Nov '01

Hello, I've been attempting to get Foxpro 5 applications running for a while now. Actually, I just download from cvs randomly, and see what happens. It's been a while, but I decided to try again in October. At that time, there was an OLE error, but the only other strange occurance was a 'locking' of the screen on a print preview. Since then, this 'locking' is the only issue (though I havn't yet attempted to print). The apps I'm trying are my own, basically just a form is called, the user puts in a date range, and a report is run. You can view the report in the print preview window, close the window, use the scroll button on the mouse to change pages, etc. BUT, if you click on the preview itself, and attempt to scroll down to the bottom of the page, a 'lockup' appears to happen. I've just been waiting around hoping for it to be fixed. Today, for giggles, I decided to run the whole Visual Foxpro development environment. It ran! (BTW, I'm trying to do this all with fake windows, and all I've added is the VFP 5 runtime) BUT, anytime I click in an edit Window, MDI interface, the program acts as if I'm holding the shift key down, and as I move my mouse, all the text gets highlighted. I can't 'turn it off', so if there wasn't any text there, it surely would appear locked. I've changed the config from the fake_windows, to point to my Win2k install, but the behavior is the same. I'm actually getting kind of excited now, because we're a small company, and all we run is Fox5 apps (SBT / Skyline -- well, and a couple Fox2.6 win), and Office 2k. If I can run the development environment in Linux, I can take a real look at using linux desktops, either directly, or via LTSP. I don't get any debug info when the 'shift' occurs, and I'm not sure how to dump enough information to see the 'shift keypress' happen (assuming I could fix the problem myself in a way that doesn't interfere with the programming standards..), can someone point me in the right direction? Thanks for your time. Rick Romero

1 0

Proposed solution for mouse capture problems
by Jukka Heinonen 29 Nov '01

29 Nov '01

Okay, here is my proposal about how to fix broken message handling when mouse capturing is in effect. I would like to get some comments so that I can see that I haven't missed anything essential and because I would like to know whether someone is already working on this... Proposal has three parts, but part number one is the most important one, other two parts just show what would need to be done to make capturing work like described in MSDN documentation. 1. Function process_raw_mouse_message should only determine which window was under mouse and resend message to that window as a cooked message. Everything else (especially separating normal messages from nonclient messages and handling mouse captures) should be moved to process_cooked_mouse_message. Actually, I fail to see why raw messages are needed at all, since function SendInput could do this as well. 2. When requesting queued messages from wineserver, the request should also include the window that is capturing mouse input in the current thread - or this could be stored in the wineserver. If there are queued cooked mouse messages, wineserver considers them as if all child windows of capturing window had the handle of the capturing window. This should prevent problems if application requests messages about a single window. 3. Supporting multi-threaded capture is actually the easiest part, although it might be quite useless (Does any application really require it?). When mouse button is pressed in capturing window, process_cooked_mouse_message sets process-wide flag that states that global capture is in effect. After that, either process_raw_mouse_message or SendInput sees that this flag is set and resends all mouse messages to capturing window until button release message is received, which clears the flag. Function process_cooked_mouse_message needs to eat these messages if target window was not capturing window anymore. Proper locking should make sure that no important messages are lost (mouse move events are not important; we might lose button release event, but only if capture has been stopped manually before that and in that case not delivering button release is likely the best thing to do). -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: [patch] Winsock fixes
by Ove Kaaven 29 Nov '01

29 Nov '01

On Wed, 28 Nov 2001, Paul Rupe wrote: > I have found two bugs in dlls/winsock/socket.c. One I posted about a > few days ago in wine.devel. WS_accept calls WS_getpeername but passes > it the Unix file descriptor rather than the Windows socket handle. A > simple one-line change takes care of that. That's Francois's fault, when he split out the sockaddr_xxx conversions. > The second problem is more subtle, and I'm not sure if my solution is > enough. In WINSOCK_DoAsyncEvent there is a loop that dispatches all > events currently available on the socket. The problem is the order, it > simply calls them in increasing order by FD_xxx values. Since FD_READ > is numerically smaller than FD_CONNECT, a socket that has both events > will fire the read event before the connect. When that happens, the app > gets a read event before it thinks it's connected and ignores it. > Ideally, the loop should post them in the order in which they occurred, > but does wine keep track of that? Instead, I changed the loop so that > it checks FD_CONNECT and FD_CLOSE before FD_READ and FD_WRITE. I'm not > sure if the order I chose is the optimal one, but the app I was testing > (Xnews) works every time now. It'd seem to me that FD_CLOSE should be dispatched last, not first... Anyway, now that Alexandre moved the window message queues away from the wine clients and into the wineserver, these event message dispatches could also be done in the wineserver (where the winsock events are generated), instead of using the service thread callback WINSOCK_DoAsyncEvent. Alexandre wants to phase out the service thread anyway, so he probably won't oppose this. Any volunteers for that?

1 0

New Idea
by Matt Q 29 Nov '01

29 Nov '01

I don't know if this is the right news group for this but what the heck... This is a new idea I had. It strikes me that it would be better if wine some how customised it's self to a single users software/configuration... I'd heard that sometimes when one thing is fixed it sometimes breaks another... This wouldn't be a problem if the thing that would hypothetically get broken wasn't installed on the end users machine... so theoretically if you had some way of sending a patch to an end user which corrected the problem at hand it would be good... so what if every time wine crashed it popped up a window and if the user wished it it would send it's very verbose out put to some kind of a bug reporting system (repository)... and in return search the repository for a patch for this particular problem... (using the verbose output).... there is a chance that the patch might break something else but in that case there is a chance that it might find another patch to fix the whole situation... they have a system like this under M$ Win and netscape except that they rely on periodic updates to take care of the problem... but who is to say that every computer is built the Same and has the Same sofware so that the Same super patch will fix every one's computer... Note 1... If M$ screws anyone on rights to this idea they can claim next logical step kind of like one step shopping... Note 2... Basically the only two weakness of the system would be One the inablility to match the output with a patch... but with a decent database program should that be problem? and Two having enough programers to right mini patches..... I'm writing from memory but I think there are 300 developers.... wouldn't that be enough..... just a thought though so take it with a grain of salt... p.s. what brought this to mind back when I was following the wine project much more closely, 2-3 years ago, when it was almost the only way to run windows programs under linux, I'd heard that many of the problems could be fixed by just a tweak here or there and mabey a few lines of code changed... still don't know much C so I doubt I'll be much help as a developer if you want to get back with me over this : ) ICQ# 135184436 turtleislow

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel November 2001