wine-devel January 2002

wine-devel@winehq.org

105 participants
218 discussions

Re: small configure patch
by Andreas Mohr 21 Jan '02

21 Jan '02

On Sun, Jan 20, 2002 at 09:49:49PM +0100, Ove Kaaven wrote: > Log: > Andrew Lewycky <andrew(a)transgaming.com> > Ove Kaaven <ovek(a)transgaming.com> > Check for common broken nVidia+Mesa OpenGL library setups. > Add some quoting. > > Index: wine/configure.in > diff -u wine/configure.in:1.1.1.25 wine/configure.in:1.50 > --- wine/configure.in:1.1.1.25 Wed Jan 16 10:58:58 2002 > +++ wine/configure.in Fri Jan 18 09:28:22 2002 > @@ -253,6 +281,14 @@ > ) dnl *** End of X11/Xlib.h check > > dnl Check for the presence of OpenGL > + > + if test -e /usr/X11R6/lib/libGL.a -a ! -e /usr/X11R6/lib/libGL.so > + then > + AC_MSG_ERROR( > +[/usr/X11R6/lib/libGL.a is present on your system. > +This prevents linking to OpenGL. Delete the file and restart configure.]) > + fi Umm, doesn't this get cached in config.cache ? Shouldn't we therefore add to delete config.cache before restarting, too ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

2 1

Fix for the web site (WineHQ)
by Francois Gouget 21 Jan '02

21 Jan '02

This fixes a bug in the Web site: a pre tag was not closed properly. Changelog: * dev.shtml Fix a mis-closed <pre> tag -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds

3 2

Re: struct async-private - now tested and cleaned up
by Alexandre Julliard 21 Jan '02

21 Jan '02

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > It is a polished resubmit of my former posting, without the GetOverlappedResult() stuff > which will follow in a separate patch. It is against clean CVS 2002-01-15. > > I would be really grateful if this patch was applied, because it is a prerequisite for me to > get going with Winsock2 overlapped IO. The comm.c part doesn't apply, are you sure this is against a clean CVS? You should probably consider using cvs diff, it helps making sure you do the diff against the right file. Also note that because of dll separation you cannot use functions like register_async() from winsock. If absolutely necessary they could be exported, but I think it would be much better to use straight server calls (and in theory these functions shouldn't be used from comm.c either). -- Alexandre Julliard julliard(a)winehq.com

3 2

Re: SetEndOfFile fix
by Andreas Mohr 21 Jan '02

21 Jan '02

On Sun, Jan 20, 2002 at 08:13:53PM +0100, Rein Klazes wrote: > hi, > > This fixes office 97 MSword error (disk full or write protected) when > saving files on a vfat partition. MSword calls SetEndOfFile() which > uses ftruncate() that, in Linux, cannot grow files in this filesystem. Ah ! :-))) I already suspected this to be the case. At least I already found due to some error code that some ftruncate() must have failed, and I think I thus called it an ftruncate problem. Oh, and yes, that error condition was in the server, too, so it must have been this ftruncate. And one more: In several cases, some guys reported that programs needed some "touch"ing before being able to save a file. What do you wanna bet that *this* is the problem that's now solved ?? :) In short: a very important fix, I think. I guess we can call you a Wine Master now ;) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

1 0

Re: SetEndOfFile fix
by lawson_whitney＠juno.com 20 Jan '02

20 Jan '02

On Sun, 20 Jan 2002, Rein Klazes wrote: > hi, > > BTW. A google search shows that the ftruncate problem has been > mentioned at least 3 times on c.e.m.w. in the last 6 months Since > nobody entered a fix, I could be overlooking something... Not exactly, I think. I remember several mentions of MSword (disk full or write protected), but nobody called it an ftruncate problem. I did think up some other rather ingenious ways you could misconfigure a fat filesystem to cause wine to be unable to save a file, but I missed ftruncate. I thought ftruncate only didn't work with umsdos, but I see I was wrong. I think you have just been paying better attention than some others of us. Good catch! > > Rein. > Lawson

1 0

Re: Questions for developing functions
by David Elliott 20 Jan '02

20 Jan '02

On 2002.01.20 12:46 Gerhard W. Gruber wrote: > On Sun, 20 Jan 2002 11:38:48 -0500, David Elliott <dfe(a)tgwbd.org> wrote: > > >Well, if the code you contribute could be considered a derived work of > the > >code you disassembled then you'd have problems. But for instance if you > > >disassembled for the purposes of figuring out how many arguments the > >function takes and what not but didn't actually directly write your code > > >based on the disassembly, then you should be in the clear as far as that > > >is concerned. > > Of course I primarily use that insight to get information on what > arguments > are used. I don't intend to make a 1:1 representation of the binary code > to C. > :) > > >Now, as for the breaking of the license agreement on your software. > That > >mostly concerns you as you are the person under the license, not the > Wine > >project. So if you feel like you would get into legal trouble by even > >disassembling something to simply see what types of parameters it takes, > > >then I would suggest that you didn't do it. However if you feel that > you > >would not get into legal trouble, and assuming you don't create your > >implementation directly from the disassembly (i.e. you reimplement from > >scratch, but just use the disassembly to get some ideas of function > >parameters) then you should be very much in the clear, and so should the > > >wine project. > > Thanks. :) > Remember though.. I am not a lawyer, and I am not Alexandre Julliard. > >Hey man, if no one responds in this mailing list within a reasonable > >timeframe then probably no-one is working on it. Just have a go and if > >someone else beats you to it without saying anything you can always do a > > >peer-review of the code and see if maybe something should be done > >different. Two pairs of eyes are better than one. > > OK. Sorry to bother you with this, but I'm just starting out, so I don't > know > much about the procedure on how to contribute a bit. :) I'd also hate to > start > investingating when a few days later a patch is thrown at the list that > does > what I just started out to do. :) I also think that it wasted time on > behalf > of wine if many developers work on the same things and leave other areas > to > its own. > No, it's not a bother.. the fact that you just posted saying that you were gonna work on it is desirable. -Dave

1 0

Questions for developing functions
by Gerhard W. Gruber 20 Jan '02

20 Jan '02

I have already posted this in the NG but I was told that this would be more appropriate here. One of my questions is how wine developers actualy develop their functions. I'm aware that some functions are (rather) easily determind just because of their name (i.e. CreateFile). Other functions can be derived from reading the documentation but there is quite a number of functions that arenot documented and some are not even mentioned anywhere (like functions in the rpcnt.dll). Now I wonder how you go about this. My approach would be to disassemble such functions and see how they work. Of course I know that in some countries this will be illegal while it is not in others. If I live in a country where this is legal would it still be a problem for the maintainer if I submit a function that is written based on the method I used to get the knowledge to write it? How do you circumvent that problem that you might infringe copyright as reverse engineering is usually prohibited by the licence where this licence is actually legally binding. Another question is concerning the function CreateDispTypeInfo. I'd like to work on Hotline which uses this function. As I noticed, this function is stubbed but not implemented and the last time it was worked on was somewhere in 2000, so I'd like to know if somebody is working on this. If I start work on it, do I have to submit this info somewhere in order to avoid duplicate work? Thanks. -- Bye, Gerhard If you think education is expensive, try ignorance.

2 1

Int 09 keyboard handler?
by Nog 20 Jan '02

20 Jan '02

Hi there, For 3 days now I have been trying to get Monkey Island 2 to work with wine, but I just can't seem to make it respond to keyboard input. The game installs a keyboard handler on int 09 which works. When a key gets pressed on the keyboard the key does get queued and then Monkey Island reads the key from port 0x60, which returns the correct key. So everything seems to work on the wine side of things but the game does not respond in any way. I have attached a +int,+io trace if that helps anyone. nog.

1 0

Full screen, always on top window doesn't get keyboard input
by Ori Pessach 19 Jan '02

19 Jan '02

Hello, While playing some more with Pajama Sam (for those of you who are wondering: yes, that's all I ever play. Pajama Sam Rocks!), I noticed the following bug: The game opens a full screen window, which doesn't get keyboard input. Furthermore, under RedHat 7.2's KDE 2 window manager, managed game dialog boxes appear BELOW the game window. The dialogs, even though they're invisible, respond to keyboard input. For example, it is possible to exit the game by clicking the exit icon, and pressing "Y", for Yes, on the dialog. Under Gnome's window manager (Sawfish?) the dialogs appear in front of the game window, but the game window still doesn't accept keyboard input. Under KDE, I can't get any other window to appear in front of the game window, nor can I minimize it. I looked at dlls/x11drv, and didn't see any WM hints being set that are obviously bad. Chances are that I wouldn't recognize bad WM hints even if they jumped up and bit me on the forehead, though. I've also poked around the system with xwininfo, and found out that the game has a full screen window, named "Pajama Sam", which has a nameless child window, which is also full window and visible. Only the parent window has any WM hints set. I seem to remember some discussion a while ago, about similar problems with installers (???). Could that be related? Bye, Ori _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

WinProc recursion
by Niclas Carlsson 19 Jan '02

19 Jan '02

Hi! The 7 year old incarnation of m$word currently causes some weird problems. What happens is that a certain dlgproc (or winproc?) WM_NCPAINT handler calls DefWindowProc and then UpdateWindow. This last call causes Wine to emit a WM_PAINT which calls BeginPaint which emits a WM_NCPAINT etc ad nauseum. ==> Recursion until the stack overflows. Of course, other things may have made the logic in the winproc go haywire, but doing the same thing (calling DefWindowProc followed by UpdateWindow in WM_NCPAINT) under win95 works just fine. The same application bombs under Wine. I'm using CVS as of yesterday (20020118). Here's the relevant part of the word backtrace: 146 0x406450d5 (RedrawWindow+0x3b1(hwnd=0x1002a, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:787] in libuser32.so) (ebp=40419b0c) 147 0x40645129 (UpdateWindow+0x21(hwnd=0x1002a) [painting.c:802] in libuser32.so) (ebp=40419b28) 148 0x500236e8 (winword.exe.PvAllocStack+0x10755 in D:\Program\office95\Winword\winword.exe) (ebp=40419ba8) 149 0x40656257 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40419bcc) 150 0x406562ed (WINPROC_CallWndProc+0x8d(proc=0x50023491, hwnd=0x1002a, msg=0x85, wParam=0xbe76, lParam=0x0) [winproc.c:167] in libuser32.so) (ebp=40419bfc) 151 0x4065bb0b (CallWindowProcA+0x3b(func=0x50023491, hwnd=0x1002a, msg=0x85, wParam=0xbe76, lParam=0x0) [winproc.c:2594] in libuser32.so) (ebp=40419c24) 152 0x405f8df3 (call_window_proc+0xf3(hwnd=0x1002a, msg=0x85, wparam=0xbe76, lparam=0x0, unicode=0x0) [message.c:1106] in libuser32.so) (ebp=40419c74) 153 0x405f99c6 (SendMessageTimeoutA+0xea(hwnd=0x1002a, msg=0x85, wparam=0xbe76, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40419cf4, hwnd=0x1002a) [message.c:1502] in libuser32.so) (ebp=40419ccc) 154 0x405f9b1f (SendMessageA+0x33(hwnd=0x1002a, msg=0x85, wparam=0xbe76, lparam=0x0) [message.c:1547] in libuser32.so) (ebp=40419cf8) 155 0x405fc29c (begin_ncpaint+0x90(hwnd=0x1002a) [painting.c:116] in libuser32.so) (ebp=40419d24) 156 0x405fc3a9 (BeginPaint+0x6d(hwnd=0x1002a, lps=0x40419da8) [painting.c:157] in libuser32.so) (ebp=40419d64) 157 0x50023575 (winword.exe.PvAllocStack+0x105e2 in D:\Program\office95\Winword\winword.exe) (ebp=40419de8) 158 0x40656257 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40419e0c) 159 0x406562ed (WINPROC_CallWndProc+0x8d(proc=0x50023491, hwnd=0x1002a, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:167] in libuser32.so) (ebp=40419e3c) 160 0x4065b7a6 (WINPROC_CallProc32WTo32A+0x8a(func=0x50023491, hwnd=0x1002a, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2438] in libuser32.so) (ebp=40419e64) 161 0x4065bc38 (CallWindowProcW+0x88(func=0x409b090e, hwnd=0x1002a, msg=0xf, wParam=0x0, lParam=0x0) [winproc.c:2645] in libuser32.so) (ebp=40419e8c) 162 0x405f8dce (call_window_proc+0xce(hwnd=0x1002a, msg=0xf, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1102] in libuser32.so) (ebp=40419edc) 163 0x405f986d (SendMessageTimeoutW+0xdd(hwnd=0x1002a, msg=0xf, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40419f58) [message.c:1454] in libuser32.so) (ebp=40419f30) 164 0x405f9adf (SendMessageW+0x33(hwnd=0x1002a, msg=0xf, wparam=0x0, lparam=0x0) [message.c:1536] in libuser32.so) (ebp=40419f5c) 165 0x40644b9c (RDW_Paint+0xbc(wndPtr=0x40345d6c, hrgn=0x0, flags=0x180, ex=0x0) [painting.c:599] in libuser32.so) (ebp=40419f90) 166 0x406450d5 (RedrawWindow+0x3b1(hwnd=0x1002a, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:787] in libuser32.so) (ebp=40419ffc) 167 0x40645129 (UpdateWindow+0x21(hwnd=0x1002a) [painting.c:802] in libuser32.so) (ebp=4041a018) Here's a corresponding relay trace: 0806e328:Call window proc 0x50023491 (hwnd=0001002a,msg=WM_PAINT,wp=00000000,lp=00000000) 0806e328:Call user32.GetWindowLongA(0001002a,00000000) ret=500238be 0806e328:Ret user32.GetWindowLongA() retval=4031ecfc ret=500238be 0806e328:Call user32.BeginPaint(0001002a,40524d1c) ret=50023575 0806e328:Call window proc 0x50023491 (hwnd=0001002a,msg=WM_NCPAINT,wp=00001abe,lp=00000000) 0806e328:Call user32.GetWindowLongA(0001002a,00000000) ret=500238be 0806e328:Ret user32.GetWindowLongA() retval=4031ecfc ret=500238be 0806e328:Call user32.DefWindowProcA(0001002a,00000085,00001abe,00000000) ret=500236d3 0806e328:Call x11drv.GetDC(0001002a,0000091c,00001abe,00050093) ret=4062f66c 0806e328:Call x11drv.SetDeviceClipping(4033f59c) ret=40702c4b 0806e328:Ret x11drv.SetDeviceClipping() retval=00000000 ret=40702c4b 0806e328:Ret x11drv.GetDC() retval=00000001 ret=4062f66c 0806e328:Call x11drv.SetDeviceClipping(4033f59c) ret=40702c4b 0806e328:Ret x11drv.SetDeviceClipping() retval=00000000 ret=40702c4b 0806e328:Call x11drv.SelectObject(4033f59c,000000e6) ret=4070f7fa 0806e328:Ret x11drv.SelectObject() retval=0000008a ret=4070f7fa 0806e328:Call x11drv.SetDeviceClipping(4033f59c) ret=40702c4b 0806e328:Ret x11drv.SetDeviceClipping() retval=00000000 ret=40702c4b 0806e328:Call x11drv.SelectObject(4033f59c,00000000) ret=4070f7fa 0806e328:Ret x11drv.SelectObject() retval=00000000 ret=4070f7fa 0806e328:Call x11drv.SelectObject(4033f59c,0000006e) ret=4070f7fa 0806e328:Ret x11drv.SelectObject() retval=0000006e ret=4070f7fa 0806e328:Call x11drv.GetDeviceCaps(4033f59c,00000022) ret=407057c8 0806e328:Ret x11drv.GetDeviceCaps() retval=000039f7 ret=407057c8 0806e328:Call x11drv.SelectObject(4033f59c,000000a2) ret=4070f6f9 0806e328:Ret x11drv.SelectObject() retval=00000001 ret=4070f6f9 0806e328:Call x11drv.SelectObject(4033f59c,0000008a) ret=4070f7fa 0806e328:Ret x11drv.SelectObject() retval=000000e6 ret=4070f7fa 0806e328:Call x11drv.SetBkColor(4033f59c,00ffffff) ret=40705846 0806e328:Ret x11drv.SetBkColor() retval=00ffffff ret=40705846 0806e328:Call x11drv.SetTextColor(4033f59c,00000000) ret=407058da 0806e328:Ret x11drv.SetTextColor() retval=00000000 ret=407058da 0806e328:Ret user32.DefWindowProcA() retval=00000000 ret=500236d3 0806e328:Call user32.UpdateWindow(0001002a) ret=500236e8 0806e328:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,405247bc,00000000,000000ff,00000000) ret=4063ebcd 0806e328:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000000 ret=4063ebcd 0806e328:Call window proc 0x50023491 (hwnd=0001002a,msg=WM_PAINT,wp=00000000,lp=00000000) 0806e328:Call user32.GetWindowLongA(0001002a,00000000) ret=500238be 0806e328:Ret user32.GetWindowLongA() retval=4031ecfc ret=500238be 0806e328:Call user32.BeginPaint(0001002a,405246e8) ret=50023575 0806e328:Call window proc 0x50023491 (hwnd=0001002a,msg=WM_NCPAINT,wp=00001ac6,lp=00000000) Cheers, Nicke -- -[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
22
Older →

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 January 2002