- wine-devel - winehq.org

Re: Unnecessary imports?
by Ove Kaaven 21 Jan '02

21 Jan '02

On Mon, 21 Jan 2002, Francois Gouget wrote: > Compiling Wine I noticed many warnings saying that the dlls we import > are not used. Is there any reason to still import them? I suppose it could in many cases be because someone *plan* to import stuff from there sometime later (after they've churned out some code to fill the stubs in the dll implementation with)...

3 2

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

21 Jan '02

Hi Martin, Each DLL should only import standard win32 api functions exported by other (lower level) DLLs. Where possible, the code should be able to be compiled and run on a windows box. (ok, that excludes kernel, gdi, user, winsock, etc). That is necessary to support dll=native linking. In theory, we should only have to implement ntdll and the device driver interfaces, then Microsoft's kernel, gdi, user, etc. would all run on top of those too. Practically, some of our low level DLLs need the wineserver interface. Your client side register_async() func should be present in all the dlls that use it because Windows has no equivilent export from NTDLL (or any other dll). Maybe you could create an inline function in a header? My guess is that WinNT implements WSARecv() and ReadFile() using something like NtReadFile(). http://www.osr.com/ntinsider/1996/native.htm Mike > On 16 Jan 2002, Alexandre Julliard wrote: > > > 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). > > Hmm. I guess I don't fully understand dll separation. Are you telling me > that the scheduling mechanism for async requests shouls be implemented > separately in each DLL? If so, I could have spared my efforts to build > a "generic" interface to async requests. I'd just mention that > this would be error-prone, because different parts of wine with > equivalent functionality would need to be maintained. Note > that an app is allowed to mix ReadFile() and WSARecv() calls > for a socket (however braindead that would be). I'd assume that > in Windows there must be a hidden layer for asynchronous requests > somewhere, too, or do you think their respective code is completely > separate? ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

MapVirtualKeyExA fixme
by John Atkinson 21 Jan '02

21 Jan '02

I've been using an app that the shortcut keys don't work, I get the following messages. fixme:keyboard:MapVirtualKeyExA (17,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (68,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (18,0,0x04090409), hkl unhandled! fixme:keyboard:MapVirtualKeyExA (90,0,0x04090409), hkl unhandled! Does anyone know how to fix this type of problem. TIA

1 0

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

Re: common controls updown patch
by David Elliott 19 Jan '02

19 Jan '02

On 2002.01.19 04:37 Shane Shields wrote: > On Saturday 19 January 2002 12:23, you wrote: > > to realize that almost no other programming language does things like > > BASIC. > > you got that right! > > > Might I suggest Python if you are in the process of learning > programming. > > isnt programming a never ending learning experience? > Oh yeah it is. :-) > > Python is an extremely elegant language, interfaces well with C code, > and > > at the moment i am really concentrating on C. most of my C experience is > with > STL which again forces a different mind set. but once i clean my mind of > misconceptions then i can really start doing things ;-) > Don't forget, C++ and C are two different languages no matter how much all the marketing suggests that they aren't. They are close, but not quite the same. Wine is all C code with no C++ code. There have been several times when I wished Alexandre would accept C++ code into the source tree. The Windows API is fairly heavily object oriented with a C interface. Sometimes it would seem to make sense to actually use an OO language to do the OO programming. But in reality C can be easily coaxed into an OO programming style even though it is a functional language. As for Python... well, I'd really suggest taking a look at it. I was of the mindset that C and C++ were so great why bother with anything else. Then earlier last year I took a look at Python and was absolutely amazed. Looking at python code will help you out with the core concepts of programming in any lanuage. That specifically includes C and C++. Python just lends itself to good programming style. Of course any bad progrmamer can still write a bad program in it though. > > has several GUI toolkits. I think the default toolkit is Tk (yuk) but > > what do you think of QT (KDE's gui) > Well, I have mixed feelings about it. I dislike the fact that you must run all of your code through the MOC to compile it. My understanding of this is that it is done so that the event system can pass pointers to the various objects around. I think wxWindows has a by far more elegant event system. For ease of programming along with power I don't think you can beat wxWindows. wxWindows also has a non-STL but still typesafe implementation of lists and arrays! Basically all you have to do is declare that you're going to need a list or array that holds items of "SomeType" and you give it a name such as "SomeTypeList" (can be called anything though). I am thoroughly impressed with the thought that has gone into this toolkit. Plus writing to it means you get Windows, Linux, and Mac (mac support is beta) for free. This was an instant sell for my boss, which made me happy because I really didn't feel like screwing with the beast that is MFC. As for some of the other toolkits. GTK is nice and they did a really good job hacking OO code into C, a non-OO language. Supposedly this helps them because it makes it easier to do language bindings. Maybe when they started, yes. If I were to write GTK today I would do it in C++. GNU C++ has come a long way and GCC 3.0.3 is a very nice compiler. I am using linux-cross-mingw32 GCC 3.0.3 along with wxWindows to write a GUI app for work and it has been going great. The only gripe I have is that GCC takes a very long time to compile what is fairly minimal C++ code. This is on an Athlon 1.4 Ghz machine! I have watched the GCC2.96 from RH compile C code on the same machine faster than I can figure out what the hell its compiling. Took like 10 minutes to build the GCC3.0.3 cross compiler with it after I spent much longer than that fixing the bugs in the GCC3.0.3 source. > > The general form is booleanexpression?then:else > > things like that would never occur to the basic mind (there are two forms > of > basic mind if you think about it) ;-) > Yeah, I tripped over that one many a time. Eventually I started using it frequently because in many cases it makes the code so much more readable. And with C++ it's almost a requirement that you use it sometimes. > > > To drink the WINE of success you must first seek the > > > sayings of source. > > > > hehe.. how true. Do you know the author of that quote? We should put > it > > on the webpage. > > yes i know the author...........and its me! :-) If you want you can put > it on > the web page (cool!) > hehe.. thought so, I just wondered if it was a paraphrase of some other more well known quote. Anyway... this is getting to be offtopic and this message barely has anything to do with Wine, so if you reply and it doesn't have anything at all to do with Wine, please send directly. -Dave

1 0

Re: common controls updown patch
by Shane Shields 19 Jan '02

19 Jan '02

On Thursday 17 January 2002 4:13, you wrote: > The remainder of any even number divided by two is 0, the remainder of any > odd number divided by two is 1. > > Knowing this doesn't: > > len+=(len%2); > > make more sense. Leave the comment as is for clarity if you wish. > > -Dave thanks Dave, its also a lot more elegant and will work faster too. i will generate a patch for it to be applied on top of the first one. as my biggest strength is visual basic things like this dont come to me straight away. im still trying to work out what this means (delta < 0 ? 1 : -1) its got me stuck. im currently looking at the wine install script as it doesnt find the windows registry when installing wine with an existing windows installation. Shane To drink the WINE of success you must first seek the sayings of source. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 2

Re: _UNICODE vs UNICODE
by Francois Gouget 19 Jan '02

19 Jan '02

On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > Using macro name "UNICODE" instead of "_UNICODE" is a > typo, right? No, not necessarily. Windows has both and dinput.h, for instance, uses UNICODE, not _UNICODE. But I have no idea why they have two. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

2 1

Re: C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk 18 Jan '02

18 Jan '02

Alexandre Julliard wrote: > You don't need to > set the variable when running make test, but you have the possibility > to set it if you want to override the default for whatever reason. > I don't see why we should impose a less flexible solution that won't > be more robust anyway. Alexandre, by your suggestion I implemented the switch, but left automated platform detection in place. Platform detection will work when the environment variable is not set or set to unknown value. Can you suggest more reliable way to detect if test runs on Wine? One more important change in C framework is support of Unicode in testing. Dimitry, can you look at it? See how it is used in sysparams.c, search for "has_unicode" function call. I'm interested in your comments. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

5 14

Re: wine-patches@winehq.com
by Alexandre Julliard 18 Jan '02

18 Jan '02

Shane Shields <locutusenterprises(a)yahoo.com> writes: > just a little improvement suggested by dave elliot on > the updown.c patch > that i posted before. it doesnt change the > functionality but is more elegant > coding. to be installed on top of the previous patch. I must confess I still don't see the reason for your patch in the first place. Unless I missed something the behavior should be exactly the same before and after your change (I mean the first one, not the cosmetic improvement). What is it supposed to fix? -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk 18 Jan '02

18 Jan '02

Alexandre Julliard wrote: > It's not enough to simply pass converted ASCII strings > to the W functions, > we have to test with real Unicode to check for > lossy W->A->W conversions, surrogate handling, non-spacing chars, etc. Aren't all these requirements just additional to testing with converted ASCII strings? At least we'll have minimal tests of W functions without spending much time. One more advantage in creation TCHAR-portable code - we can eventually test with it multibyte character set support. We still can have specific A and W tests sections, enclosed in #ifdef _UNICODE. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

1 0

XP registry
by Eric Pouech 18 Jan '02

18 Jan '02

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/appendix/h… this may answer the latest question from Andi A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

1 0

Wine "Please Report" Error
by Scott Sipe 18 Jan '02

18 Jan '02

Hi, I'm running wine20011226 compiled on FreeBSD 4.5 rc recent build, built wine from the ports collection. When I start wine, it says: scott@dragon> wine Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: err:reg:_nt_dump_lf unknown node id 0x686c, please report! err:reg:_nt_dump_lf unknown node id 0x686c, please report! err:reg:_nt_dump_lf unknown node id 0x686c, please report! Wine release 20011226 So, what should I report? thanks, Scott

2 1

License problem with files in dlls/icmp/
by Ilja Kamps 18 Jan '02

18 Jan '02

It appaers that files under dlls/icmp/ are licensed under the BSD license and not the X11 license, this might be a problem as wine does not honor the advertisment part and also it makes wine GPL incompaitible, I would consider this a serious problem. Either we honor the advertisment part and note that wine is not directly GPL compaitible (GPL doesn't allow such texts) or we reimplement that dll. I hope I got it right.

3 3

RE: What are you really aiming to do with winetest?
by Patrik Stridvall 17 Jan '02

17 Jan '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > So what you basicly want is something like: > > > > my %return_type_exceptions; > > > > $return_type_exceptions{"foo"} = { > > Bar => "str", > > Baz => "ptr" > > }; > > > > $return_type_exceptions{"bar"} = { > > Foo => "str" > > }; > > > Yes, that would work fine for now. OK. I made a script (adapted winapi_extract) to do this (attached). Output attached as well, but you can regenerate it by doing tools/winapi/winapi_extract in the topsrcdir. I realized that when I was at it I could output the argument types as well and thus having a hash table that can be given to wine::declare directly. Here is also a script make_modules that generates modules to use this directly and thus there is no need to any spec2pm any longer. However I'm not postive that we want to have seperate include for constants and functions. Perhaps it would be better if people used to C could just do use winuser; instead of #include "winuser.h" and not have to do any additional use user32; as well. Oh, well, I don't really have any strong feelings in any direction. But it would be easier if you told me how you wanted it. Oh BTW: What is your opinion on having special Perl adapted versions of some functions like: sub GlobalGetAtomNameA { my $atom = shift; my $buffer = "\0" x 256; # FIXME: Fixed buffer length my $length = &kernel32::GlobalGetAtomNameA($atom, \$buffer, length($buffer)); return substr($buffer, 0, $length); } Should we have them as the default imported function in say kernel32.pm or should each test that wants a easier to use version declare it in the test itself.

2 1

HEAP_ZERO_MEMORY was: Re: Prevent passing uninitialised string to WARN
by Uwe Bonnes 17 Jan '02

17 Jan '02

>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes: Medland,> Bill Medland (medbi01(a)accpac.com) Prevent trying to handle Medland,> uninitialised memory as a string. Medland,> Index: wine/loader/module.c Medland,> =================================================================== Medland,> RCS file: /home/wine/wine/loader/module.c,v retrieving Medland,> revision 1.144 diff -u -r1.144 module.c --- Medland,> wine/loader/module.c 2001/12/20 00:19:42 1.144 +++ Medland,> wine/loader/module.c 2002/01/17 13:45:52 @@ -1379,6 +1379,7 @@ Medland,> filename = HeapAlloc ( GetProcessHeap(), 0, MAX_PATH + 1 ); Medland,> if ( !filename ) return NULL; Medland,> + *filename = 0; /* Just in case Wouldn't HEAP_ZERO_MEMORY be a better argument to HeapAlloc then 0? This would apply to many places. 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 2

Re: Filesystem Regression Test, was: Re: RESEND: Fix return value ...
by Dmitry Timoshkov 17 Jan '02

17 Jan '02

"Andriy Palamarchuk" <apa3a(a)yahoo.com> wrote: > For me it looks like we need to keep both tests > together, because we'll want to compare results of W > and A versions. One more advantage - it is easier to > make changes because both versions are in one place. Then we should invent some approach to easily compare two strings: ANSI and Unicode. > What approach we will use with UNICODE tests on Win95 > platform? There is no difference in API between emulated Windows versions from the Wine point of view. -- Dmitry.

2 3

Re: DOSFS_ToFCBFormat Bug Fix
by Ove Kaaven 17 Jan '02

17 Jan '02

On Sun, 13 Jan 2002 ccrayne(a)crayne.org wrote: > Change Log: > files/dos_fs.c > ccrayne(a)crayne.org > Fixed bug in DOSFS_ToFCBFormat which caused "*" to parse as "*." instead > of as "*.*" This sounds like intended behaviour. Under real DOS, "*" really means "*.". The user must type "*.*" to get all files. (This is the stuff that used to confuse DOS users converting to Linux - "*.*" no longer meant all files...) Also, your mailer seems to mangle your patches. You may want to attach them instead of pasting them to avoid that.

4 4

Re: user32.TrackMouseEvent
by David Elliott 17 Jan '02

17 Jan '02

On 2002.01.15 11:37 Rein Klazes wrote: > hi, > > to implement user32.TrackMouseEvent: > > Changelog: > dlls/comctl32/ : commctrl.c > dlls/user/ : user32.spec > windows/ : input.c > include/ : winuser.h > > Move the implementation of comctl32._TrackMouseEvent to > user32.TrackMouseEvent and call this function in accordance > with the specs. > Man, it must not be my week. I did the exact same thing two days ago ('cept I put the TME stuff into windows/tme.c instead of adding it to input.c). Was part of making IE work as mentioned in my last mail regarding the stumbling block I hit with DPA that Aric has figured out. That'll teach me to leave patches sitting around in my tree for a couple days. -Dave

1 0

Re: common controls updown patch
by David Elliott 17 Jan '02

17 Jan '02

On 2002.01.14 14:45 Shane Shields wrote: > hi all > > this is just a little patch to fix the UPDOWN_GetArrowRect function where > the > midpoint is calculated by adding 1 to odd numbers. before it just added 1 > to > every number now it tests for odd numbers before adding. > > Shane > > Thanks Dan for the tips > > Changelog: > > Shane Shields locutus(a)all.at > > updown.c UPDOWN_GetArrowRect function > added odd number checking > --- ./dlls/comctl32/updown.c.orig Mon Jan 14 20:35:07 2002 > +++ ./dlls/comctl32/updown.c Sun Jan 13 17:28:18 2002 > @@ -1,4 +1,4 @@ > -/* > +/* > * Updown control > * > * Copyright 1997 Dimitrie O. Paun > @@ -176,14 +176,16 @@ > * round the uneven numbers by adding 1. > */ > if (dwStyle & UDS_HORZ) { > - len = rect->right - rect->left + 1; /* compute the width */ > + len = rect->right - rect->left; /* compute the width */ > + if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */ > if (incr) > - rect->left = rect->left + len/2; > + rect->left = rect->left + len/2; > else > rect->right = rect->left + len/2; > } > else { > - len = rect->bottom - rect->top + 1; /* compute the height */ > + len = rect->bottom - rect->top; /* compute the height */ > + if (len % 2 != 0 ) len ++; /* if not an even number then add 1 */ > if (incr) > rect->bottom = rect->top + len/2; > else > The remainder of any even number divided by two is 0, the remainder of any odd number divided by two is 1. Knowing this doesn't: len+=(len%2); make more sense. Leave the comment as is for clarity if you wish. -Dave

1 0

Re: basic structures for async IO in winsock
by lawson_whitney＠juno.com 17 Jan '02

17 Jan '02

On Wed, 16 Jan 2002, Martin Wilck wrote: > > Patch: async-winsock.diff > Applies: CVS 2002-01-15 > > Introduce data structures and basic functions for asynchronous > Winsock2 operations. > > ChangeLog: > > include/winsock2.h: Fix LPWSAOVERLAPPED declaration. > dlls/winsock/socket.c: Add basic data strutures & functions for overlapped IO > in Winsock. > Juno 4 without the async winsock patches.

1 0

16 bit menus
by lawson_whitney＠juno.com 17 Jan '02

17 Jan '02

Good day! Last time but one I tested juno 1.49 for regressions in 16 bit comms, it downloaded a new list of access numbers. Next it presented me with the attached menu (well, I attached a trace of it making the menu), which it expects me to work through and select a new number. Unfortunately, the menu seems to be either 0 or 1 pixels high and I can't find any of the controls in there. If somebody can tell me what parameter to what function provokes this, maybe I can work out a way to fix it. Of course, anybody who knows what [s]he is doing with menus is welcome to fix it, too. I have used this menu with this app, but not for perhaps a year. Lawson

1 0

[PATCH] Overlapped recv(), WSARecv()
by Martin Wilck 17 Jan '02

17 Jan '02

This patch needs testing yet - I am sending it for people to review and point out errors right from the start. Currently I only verified that it compiles. ChangeLog: implement overlapped recv(), much like overlapped IO in files/file.c. make WS2_32 WSARecvFrom() the "working" function, all others are wrappers only. implement WSAGetOverlappedResult(). NOTE: My patches submitted yesterday and today (16/01) to wine-patches are necessary for this one to work. CVS base version is 2002-01-15. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy diff -ruX diffignore CVS/wine/dlls/winsock/socket.c MW/wine/dlls/winsock/socket.c --- CVS/wine/dlls/winsock/socket.c Wed Jan 16 18:14:19 2002 +++ MW/wine/dlls/winsock/socket.c Wed Jan 16 18:18:27 2002 @@ -85,6 +85,7 @@ #include "wine/winbase16.h" #include "wingdi.h" #include "winuser.h" +#include "winerror.h" #include "winsock2.h" #include "ws2tcpip.h" #include "wsipx.h" @@ -95,7 +96,6 @@ #include "file.h" #include "debugtools.h" - DEFAULT_DEBUG_CHANNEL(winsock); /* critical section to protect some non-rentrant net function */ @@ -167,11 +167,22 @@ if ( !as->user_overlapped ) HeapFree ( GetProcessHeap(), 0, as->overlapped ); + else + /* FIXME: is this correct? How else can we communicate the flags + to WSAGetOverlappedResult() ? */ + as->overlapped->Offset = as->flags; HeapFree ( GetProcessHeap(), 0, as->iovec ); HeapFree ( GetProcessHeap(), 0, as ); } +static void CALLBACK ws2_default_completion ( DWORD dwError, DWORD cbTransferred, + LPWSAOVERLAPPED lpOverlapped, + DWORD dwFlags ) +{ + NtSetEvent ( lpOverlapped->hEvent, NULL ); +} + /****************************************************************/ /* ----------------------------------- internal data */ @@ -307,14 +318,19 @@ static char* check_buffer(int size); -static int _get_sock_fd(SOCKET s) +static int _get_sock_fd_type (SOCKET s, enum fd_type *type, DWORD *flags) { - int fd = FILE_GetUnixHandle( s, GENERIC_READ ); + int fd = FILE_GetUnixHandleType ( s, GENERIC_READ, type, flags ); if (fd == -1) FIXME("handle %d is not a socket (GLE %ld)\n",s,GetLastError()); return fd; } +static int _get_sock_fd (SOCKET s) +{ + return _get_sock_fd_type (s, NULL, NULL); +} + static void _enable_event(SOCKET s, unsigned int event, unsigned int sstate, unsigned int cstate) { @@ -1887,34 +1903,16 @@ */ int WINAPI WS_recv(SOCKET s, char *buf, int len, int flags) { - int fd = _get_sock_fd(s); + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; TRACE("socket %04x, buf %8x, len %d, flags %d\n", s, (unsigned)buf, len, flags); - if (fd != -1) - { - INT length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds? */ - do_block(fd, 1); - } - if ((length = recv(fd, buf, len, flags)) >= 0) - { - TRACE(" -> %i bytes\n", length); - - close(fd); - _enable_event(s, FD_READ, 0, 0); - return length; - } - SetLastError(wsaErrno()); - close(fd); - } - else SetLastError(WSAENOTSOCK); - WARN(" -> ERROR\n"); - return SOCKET_ERROR; + if ( WSARecv (s, &wsabuf, 1, &n, &dwFlags, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; + else + return n; } /*********************************************************************** @@ -1932,60 +1930,14 @@ int WINAPI WS_recvfrom(SOCKET s, char *buf, INT len, int flags, struct WS_sockaddr *from, int *fromlen) { - int fd = _get_sock_fd(s); - int res; - - TRACE("socket %04x, ptr %08x, len %d, flags %d\n", s, (unsigned)buf, len, flags); -#if DEBUG_SOCKADDR - if (from) - dump_sockaddr(from); - else - DPRINTF("from = NULL\n"); -#endif + DWORD n; + WSABUF wsabuf = { len, buf }; + DWORD dwFlags = flags; - res=SOCKET_ERROR; - if (fd != -1) - { - struct sockaddr* uaddr; - int uaddrlen; - int length; - - if (_is_blocking(s)) - { - /* block here */ - /* FIXME: OOB and exceptfds */ - do_block(fd, 1); - } - - uaddr=ws_sockaddr_alloc(from,fromlen,&uaddrlen); - length=recvfrom(fd, buf, len, flags, uaddr, &uaddrlen); - if (length < 0) - { - SetLastError(wsaErrno()); - WARN(" -> ERROR\n"); - } - else if (ws_sockaddr_u2ws(uaddr,uaddrlen,from,fromlen) != 0) - { - /* The from buffer was too small, but we read the data - * anyway. Is that really bad? - */ - SetLastError(WSAEFAULT); - WARN(" -> WSAEFAULT\n"); - } - else - { - TRACE(" -> %i bytes\n", length); - _enable_event(s, FD_READ, 0, 0); - res=length; - } - close(fd); - } + if ( WSARecvFrom (s, &wsabuf, 1, &n, &dwFlags, from, fromlen, NULL, NULL) == SOCKET_ERROR ) + return SOCKET_ERROR; else - { - SetLastError(WSAENOTSOCK); - WARN(" -> WSAENOTSOCK\n"); - } - return res; + return n; } /*********************************************************************** @@ -2811,6 +2763,44 @@ return SOCKET_ERROR; } +/********************************************************************** + * WSAGetOverlappedResult (WS2_32.40) + */ +BOOL WINAPI WSAGetOverlappedResult ( SOCKET s, LPWSAOVERLAPPED lpOverlapped, + LPDWORD lpcbTransfer, BOOL fWait, + LPDWORD lpdwFlags ) +{ + DWORD r; + + TRACE ( "socket %d ovl %p trans %p, wait %d flags %p\n", + s, lpOverlapped, lpcbTransfer, fWait, lpdwFlags ); + + if ( !(lpOverlapped && lpOverlapped->hEvent) ) + { + ERR ( "Invalid pointer\n" ); + WSASetLastError (WSA_INVALID_PARAMETER); + return FALSE; + } + + do { + TRACE("waiting on %p\n",lpOverlapped); + r = WaitForSingleObjectEx (lpOverlapped->hEvent, fWait ? INFINITE : 0, TRUE); + TRACE("wait on %p returned %ld\n",lpOverlapped,r); + } while (r == STATUS_USER_APC); + + if ( lpcbTransfer ) + *lpcbTransfer = lpOverlapped->InternalHigh; + + if ( lpdwFlags ) + *lpdwFlags = lpOverlapped->Offset; /* see ws2_async_call_completion */ + + if (lpOverlapped->Internal == STATUS_PENDING ) + WSASetLastError ( WSA_IO_INCOMPLETE ); + + return (r == WAIT_OBJECT_0); +} + + /*********************************************************************** * WINSOCK_DoAsyncSelect */ @@ -3481,34 +3471,267 @@ /*********************************************************************** + * WSARecv (WS2_32.67) + */ +int WINAPI WSARecv (SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, + LPDWORD NumberOfBytesReceived, LPDWORD lpFlags, + LPWSAOVERLAPPED lpOverlapped, + LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine) +{ + + return WSARecvFrom (s, lpBuffers, dwBufferCount, NumberOfBytesReceived, lpFlags, + NULL, NULL, lpOverlapped, lpCompletionRoutine); + +} + +/*********************************************************************** + * WS2_recv (INTERNAL) + */ +static int WS2_recv (int fd, struct iovec* iov, int count, + struct WS_sockaddr *lpFrom, LPINT lpFromlen, LPDWORD lpFlags) +{ + /* Uses recvmsg() in order to provide scatter-gather I/O */ + struct msghdr hdr; + int n; + TRACE ( "fd %d, iovec %p, count %d addr %p, len %p, flags %lx\n", + fd, iov, count, lpFrom, lpFromlen, *lpFlags); + + hdr.msg_name = NULL; + + if ( lpFrom ) + { +#if DEBUG_SOCKADDR + dump_sockaddr (lpFrom); +#endif + + hdr.msg_namelen = *lpFromlen; + hdr.msg_name = ws_sockaddr_alloc (lpFrom, lpFromlen, &hdr.msg_namelen); + if ( !hdr.msg_name ) + { + WSASetLastError ( WSAENOBUFS ); + n = -1; + goto out; + } + } + else + hdr.msg_namelen = 0; + + hdr.msg_iov = iov; + hdr.msg_iovlen = count; + hdr.msg_control = NULL; + hdr.msg_controllen = 0; + hdr.msg_flags = 0; + + if ( (n = recvmsg (fd, &hdr, *lpFlags)) == -1 ) + goto out; + + if ( lpFrom && + ws_sockaddr_u2ws ( hdr.msg_name, hdr.msg_namelen, + lpFrom, lpFromlen ) != 0 ) + { + /* The from buffer was too small, but we read the data + * anyway. Is that really bad? + */ + WSASetLastError ( WSAEFAULT ); + WARN ( "Address buffer too small\n" ); + } + +out: + TRACE ( "recvmsg returned %d\n", n ); + + ws_sockaddr_free ( hdr.msg_name, lpFrom ); + return n; +} + + +/*********************************************************************** + * WS2_async_recv (INTERNAL) + */ +static void WS2_async_recv (async_private *as) +{ + ws2_async* wsa = (ws2_async*) as; + int result, err; + + TRACE ( "async %p\n", wsa ); + + result = WS2_recv ( wsa->async.fd, wsa->iovec, wsa->n_iovecs, + wsa->addr, wsa->addrlen, &wsa->flags ); + + if (result >= 0) + { + wsa->overlapped->Internal = STATUS_SUCCESS; + wsa->overlapped->InternalHigh = result; + TRACE ( "received %d bytes\n", result ); + return; + } + + err = errno; + if ( err == EAGAIN || err == EINTR ) + { + wsa->overlapped->Internal = STATUS_PENDING; + TRACE ( "still pending\n" ); + } + else + { + wsa->overlapped->Internal = STATUS_UNSUCCESSFUL; + TRACE ( "Error: %d\n", errno ); + } +} + +/*********************************************************************** * WSARecvFrom (WS2_32.69) */ INT WINAPI WSARecvFrom( SOCKET s, LPWSABUF lpBuffers, DWORD dwBufferCount, - LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, struct WS_sockaddr *lpFrom, - LPINT lpFromlen, LPWSAOVERLAPPED lpOverlapped, + LPDWORD lpNumberOfBytesRecvd, LPDWORD lpFlags, + struct WS_sockaddr *lpFrom, LPINT lpFromlen, + LPWSAOVERLAPPED lpOverlapped, LPWSAOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine ) { - DWORD dwCount; - INT rc; + struct iovec* iovec; + int fd, i, length, err = WSAENOTSOCK; + enum fd_type type; + DWORD flags; + ws2_async *wsa; + + fd = _get_sock_fd_type (s, &type, &flags); + + TRACE("socket %04x, wsabuf %p, nbufs %ld, flags %ld, from %p, " + "fromlen %ld, ovl %p, func %p, fd %d, type %d, flags %ld\n", + s, lpBuffers, dwBufferCount, *lpFlags, lpFrom, + (lpFromlen ? *lpFromlen : -1L), + lpOverlapped, lpCompletionRoutine, + fd, (int) type, flags); - FIXME( "(%i,%p,%lu,%p,%p,%p,%p,%p,%p: stub\n", - s, lpBuffers, dwBufferCount, lpNumberOfBytesRecvd, lpFlags, - lpFrom, lpFromlen, lpOverlapped, lpCompletionRoutine ); + if (fd == -1) + { + err = WSAENOTSOCK; + goto error; + } - for( dwCount = 0, rc = 0; dwCount < dwBufferCount; dwCount++ ) - { + iovec = HeapAlloc (GetProcessHeap(), 0, + dwBufferCount * sizeof (struct iovec) ); + if ( !iovec ) + { + err = WSAENOBUFS; + goto err_close; + } - if( ( rc = WS_recvfrom(s, lpBuffers[ dwCount ].buf, (INT)lpBuffers[ dwCount ].len, - (INT)*lpFlags, lpFrom, lpFromlen ) ) != 0 ) + for (i = 0; i < dwBufferCount; i++) { - break; + iovec[i].iov_base = lpBuffers[i].buf; + iovec[i].iov_len = lpBuffers[i].len; } - } + if ( (lpOverlapped || lpCompletionRoutine) && flags & FD_FLAG_OVERLAPPED ) + { + /* Asynchronous recv */ - return rc; -} + wsa = HeapAlloc ( GetProcessHeap(), 0, sizeof (ws2_async) ); + if ( !wsa ) + { + err = WSAENOBUFS; + goto err_free; + } + + wsa->async.ops = &ws2_async_ops; + wsa->async.handle = (HANDLE) s; + wsa->async.fd = fd; + wsa->async.type = ASYNC_TYPE_READ; + wsa->async.func = WS2_async_recv; + wsa->user_overlapped = lpOverlapped; + if ( lpOverlapped ) + wsa->overlapped = lpOverlapped; + else + { + wsa->overlapped = HeapAlloc ( GetProcessHeap(), 0, + sizeof (WSAOVERLAPPED) ); + if ( !wsa->overlapped ) + { + err = WSAENOBUFS; + goto err_free_as; + } + } + wsa->completion_func = ( lpCompletionRoutine ? + lpCompletionRoutine : ws2_default_completion ); + wsa->iovec = iovec; + wsa->n_iovecs = dwBufferCount; + wsa->addr = lpFrom; + wsa->addrlen = lpFromlen; + wsa->flags = *lpFlags; + + wsa->overlapped->Internal = STATUS_USER_APC; + wsa->overlapped->InternalHigh = 0; + TRACE ( "async %p, overlapped: %p, user overlapped: %p, completion: %p\n", + wsa, wsa->overlapped, wsa->user_overlapped, wsa->completion_func ); + + if ( !register_async ( &wsa->async ) ) + { + err = wsaErrno (); + goto err_free_ov; + } + + /* Check for immediate completion + (only possible if lpOverlapped is non-NULL) */ + if ( !lpOverlapped ) + { + WSASetLastError ( WSA_IO_PENDING ); + return SOCKET_ERROR; + } + else if ( WSAGetOverlappedResult ( (HANDLE) s, lpOverlapped, + lpNumberOfBytesRecvd, FALSE, lpFlags) ) + { + return 0; + } + else if ( WSAGetLastError () == WSA_IO_INCOMPLETE ) + { + WSASetLastError ( WSA_IO_PENDING ); + return SOCKET_ERROR; + } + else + goto err_free_ov; + } + + /* Synchronous recv */ + + if (_is_blocking(s)) + { + /* block here */ + /* FIXME: OOB and exceptfds? */ + do_block(fd, 1); + } + + length = WS2_recv ( fd, iovec, dwBufferCount, lpFrom, lpFromlen, lpFlags ); + if ( length == -1 ) + { + err = wsaErrno(); + goto err_free; + } + + TRACE(" -> %i bytes\n", length); + + *lpNumberOfBytesRecvd = length; + + WS_FREE (iovec); + close(fd); + _enable_event(s, FD_READ, 0, 0); + + return 0; + +err_free_ov: + if ( !wsa->user_overlapped ) + HeapFree ( GetProcessHeap(), 0, wsa->overlapped ); +err_free_as: + HeapFree ( GetProcessHeap(), 0, wsa ); +err_free: + WS_FREE (iovec); +err_close: + close (fd); +error: + WARN(" -> ERROR %d\n", err); + SetLastError ( err ); + return SOCKET_ERROR; +} /*********************************************************************** * WSCInstallProvider (WS2_32.88) diff -ruX diffignore CVS/wine/dlls/winsock/ws2_32.spec MW/wine/dlls/winsock/ws2_32.spec --- CVS/wine/dlls/winsock/ws2_32.spec Tue Jan 15 20:17:38 2002 +++ MW/wine/dlls/winsock/ws2_32.spec Wed Jan 16 18:13:36 2002 @@ -52,7 +52,7 @@ 37 stub WSAEnumProtocolsA 38 stub WSAEnumProtocolsW 39 stdcall WSAEventSelect(long long long) WSAEventSelect -40 stub WSAGetOverlappedResult +40 stdcall WSAGetOverlappedResult(long ptr ptr long ptr) WSAGetOverlappedResult 41 stub WSAGetQOSByName 42 stub WSAGetServiceClassInfoA 43 stub WSAGetServiceClassInfoW @@ -79,7 +79,7 @@ 64 stub WSANtohl 65 stub WSANtohs 66 stub WSAProviderConfigChange -67 stub WSARecv +67 stdcall WSARecv(long ptr long ptr ptr ptr ptr) WSARecv 68 stub WSARecvDisconnect 69 stdcall WSARecvFrom(long ptr long ptr ptr ptr ptr ptr ptr ) WSARecvFrom 70 stub WSARemoveServiceClass diff -ruX diffignore CVS/wine/files/file.c MW/wine/files/file.c --- CVS/wine/files/file.c Wed Jan 16 18:14:09 2002 +++ MW/wine/files/file.c Wed Jan 16 17:34:34 2002 @@ -224,7 +224,7 @@ * Retrieve the Unix handle corresponding to a file handle. * Returns -1 on failure. */ -static int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum fd_type *type, DWORD *flags ) +int FILE_GetUnixHandleType( HANDLE handle, DWORD access, enum fd_type *type, DWORD *flags ) { int ret, fd = -1; diff -ruX diffignore CVS/wine/include/file.h MW/wine/include/file.h --- CVS/wine/include/file.h Wed Jan 16 18:14:04 2002 +++ MW/wine/include/file.h Wed Jan 16 18:15:12 2002 @@ -12,6 +12,9 @@ #include "winbase.h" #include "wine/windef16.h" /* HFILE16 */ +/* FIXME: including server/protocol.h here leads to a handle_t type conflict elsewhere */ +enum fd_type; /* declared in server_protocol.h */ + #define MAX_PATHNAME_LEN 1024 /* Definition of a full DOS file name */ @@ -97,6 +100,7 @@ extern int FILE_strncasecmp( const char *str1, const char *str2, int len ); extern void FILE_SetDosError(void); extern HANDLE FILE_DupUnixHandle( int fd, DWORD access, BOOL inherit ); +extern int FILE_GetUnixHandleType ( HANDLE handle, DWORD access, enum fd_type *type, DWORD *flags ); extern int FILE_GetUnixHandle( HANDLE handle, DWORD access ); extern BOOL FILE_Stat( LPCSTR unixName, BY_HANDLE_FILE_INFORMATION *info ); extern HFILE16 FILE_Dup2( HFILE16 hFile1, HFILE16 hFile2 );

2 1

Re: SHGetSpecialFolderLocation function
by juergen.schmied＠debitel.net 17 Jan '02

17 Jan '02

> What I've found though with the SHGetSpecialFolderLocation, is that it seems > to me that it is designed to allow the caller to pick an arbitrary value for > the CSIDL, and that this will cause windows to create a new CSIDL. As the > function's implementation currently stands, it has a hard-coded table of > possible CSIDLs, and rejects calls with unknown CSIDLs. This is right. There is a list with valid CSIDL's. These CSIDL's are mapped to a unique value name in the registry. These functions are supposed to fail when called with a CSIDL which is not predefined. (Whats not saying wine knows all CSIDL's). > Has anyone else looked at this function, and does anyone have any comments or > suggestions on ways to address this? I'm thinking that these values probably > need to go into the registry, or something, rather than being stored in the > code... There is only a need to store the values in the registry when the path is different from the default value. If the there are no registry entrys in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\Shell Folders HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ Explorer\User Shell Folders HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVer sion\Explorer\Sh ell Folders HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVer sion\Explorer\Us er Shell Folders the the default values are used. (Was in w95, nt4 like this. Don't know it its true for w2k since apparently most values are set at installation time and there are more values used than before.) Last but the not least: the current implementation was designed to work without much preset values in the registry to simplify the installation. The implementation should be cleaned up starting with ShGetFolderLocation since this is the common base of SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocationand SHGetSpecialFolderPath and you should have a fallback to deal with a empty registry. (I'm not up to date with the wine installation procedure but the installer would have to put many keys in the registry for a good shell32 konfiguration.) Juergen --- juergen.schmied(a)debitel.net

1 0

Re: [PATCH] Overlapped recv(), WSARecv()
by lawson_whitney＠juno.com 16 Jan '02

16 Jan '02

> > This patch needs testing yet - I am sending it for people to > review and point out errors right from the start. > > Currently I only verified that it compiles. > > ChangeLog: > implement overlapped recv(), much like overlapped IO in > files/file.c. > make WS2_32 WSARecvFrom() the "working" function, > all others are wrappers only. > implement WSAGetOverlappedResult(). > > NOTE: My patches submitted yesterday and today (16/01) to wine-patches > are necessary for this one to work. CVS base version is 2002-01-15. > > Martin > > -- Just to add insult to injury, this letter is by juno version 4 using winsocks, this patch and the 3 others mentioned above. Had to use patch -l again. It doesn't constitute a test for asynchronous winsocks, but at least the patches don't break my mail apps. Maybe. Lawson

1 1

RE: What are you really aiming to do with winetest?
by Patrik Stridvall 16 Jan '02

16 Jan '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Perhaps you remember me wanting to extend the .spec files > > with information whether a ptr/str was [in], [out], [in/out] > > > > In Perl all string, like in C, are read/write, so I think > > we can live without it. > > > > But return type would be nice to have in the .spec files. > > We discussed this before; I agree it would be nice to have a lot more > information like in/out, return values, more detailed types, etc. But > I don't think the spec file is the right place for that. I'd like the > spec to remain simple (and in fact to even be simplified) and to > contain only the minimal info needed to generate a correct dll. Yes, I remember. I just pointed out the possibillity, in case you had changed your mind. > All > the rest that's used for debug/testing should be moved somewhere else, > preferably directly into the code. So what you basicly want is something like: my %return_type_exceptions; $return_type_exceptions{"foo"} = { Bar => "str", Baz => "ptr" }; $return_type_exceptions{"bar"} = { Foo => "str" }; A file in this format could quite easily be generated by an appropriate script as well.

2 1

RE: What are you really aiming to do with winetest?
by Patrik Stridvall 16 Jan '02

16 Jan '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > It would be nice if you commented on what you > > think about my spec2pm script for automatically > > generating Perl modules for calling the Windows API. > > Sure; I was looking into integrating it, but found some problems. > I agree generating modules automatically is a good idea; the main > problem right now is that we cannot get the return type of the > functions, and this breaks functions returning a string. Yes, that is true. But it was better than nothing. Many (most?) functions, like strcpy, returns a pointer returns a pointer to one of the arguments anyway so there is little need to actually access it in the test. But of course it should be solved. I see two way of solving this. 1. Extend the spec files to include this information. 2. Have an exception table like the one in make_symbols Fortunately winetest uses Perl, not Python. If we did we would have an additional problem, namely that strings in Python are read-only and passing it as an [out] or [in/out] string would break Python semantics. Perhaps you remember me wanting to extend the .spec files with information whether a ptr/str was [in], [out], [in/out] In Perl all string, like in C, are read/write, so I think we can live without it. But return type would be nice to have in the .spec files. I think I can quite easily can adapt winapi_fixup to do this automatically for all spec files if you wish. You have to decide on the syntax though. > > Also, I'm not sure that you are trying to do: > > The files generated by make_symbols are quite useless, > > they just contain a lot of LOCAL variables. > > They seem to work just fine for me, but I'm no Perl expert, so if you > think your approach is better I'll do it that way. Hmm. I guess that is because you usually write Perl application without "use strict". IIRC variables defaults to global without it and to _local_ with it. In any case, my test with "use strict" didn't work. Anyway, my way is the offical way that is recommended in the Perl documentation and work both with and without "use strict". As a special bonus you can now do things like: use winerror qw(ERROR_CALL_NOT_IMPLEMENTED); without having to, like C, include everything.

2 1

Re: C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk 16 Jan '02

16 Jan '02

Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > >>Can you suggest how to implement these switches - as >>command-line arguments or environment variables? >> > > Environment variables are better. I did that already in the perl > framework, look at the runtest script for the variables I'm using. You > probably want to do things the same way so that it's easier to mix > Perl and C tests. Looked at the runtest script. Defined processing of environment variables WINETEST_DEBUG and WINETEST_DIE_ON_FAILURE. As we discussed before we can define platform at runtime, so do we really need the WINETEST_PLATFORM switch? This is one more thing to break. Somebody will eventually mess with the switch when they run the test application manually. Automatic platform definition is pretty reliable. Attached new version of the library. > I don't have a die on failure flag though, but I > don't think this is really necessary. It is not really necessary, only nice thing to have :-) I was thinking about situations when we need to run big batch of tests on unfamiliar platform - e.g. on untested version of Windows or move tests between Win32 implementation. In these situations we are interested to see all possible failures to see amount of work needed to fix them. On other hand we'd like to see only 1 failure on testing regressions. I'm going to leave the option for now. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 3

The 4th Coming : Mmsystem Question
by Sylvain Petreolle 16 Jan '02

16 Jan '02

Hi, Using The 4th Coming game (directx game), wine crashes (no debugger is launched) after displaying following some error messages : (game is at http://t4cweb.aliens.com/download/T4csetup.exe) you can use the following game account : T4CWineUser pass: test4U err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=044f err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=043f err:ntdll:RtlpWaitForCriticalSection section 0x59c150 "?" wait timed out, retrying (60 sec) fs=008f err:mmsys:MULTIMEDIA_GetIData IData not found for pid=0806b920. Suicide !!! (displayed 4 times) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

1 0

Re: async immediate completion - now tested
by l_whitney＠juno.com 16 Jan '02

16 Jan '02

On Tue, Jan 15, 2002 at 08:06:22PM +0100, Martin Wilck wrote: > > PATCH: async-immediate.diff > > This patch uses a more elegant and (IMO) more wine-ish method to check for > possible immediate completion of asynchronous IO requests in ReadFile() and > WriteFile(). > If you get this, async-struct and async-immediate don't harm the 16 bit app. Just making sure I tested exactly what is being proposed. Lawson ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/.

2 1

Re: Listview Unicodification (take 3) (fwd)
by Gerard Patel 16 Jan '02

16 Jan '02

At 01:58 PM 1/15/02 -0500, you wrote: >[once again, I attached the patch by mistake, and the mail did not go >through...oh well, that happens if you don't sleep at night:) ] I think that by zipping the patch it should be below 64K and be fine. >Here is the latest version of the Unicode ListView control: >http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff Better - all columns have something now - but only the first character. This fixes it : @@ -5075,7 +5076,14 @@ else if (lpLVItem->mask & LVIF_TEXT) { if (internal) lpLVItem->pszText = *ppszText; - else textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW); + else + { + if (isW) + textcpynT(lpLVItem->pszText, *ppszText, lpLVItem->cchTextMax, isW); + else + WideCharToMultiByte(CP_ACP,0,*ppszText,-1,lpLVItem->pszText, + lpLVItem->cchTextMax,NULL,NULL); + } } if (lpLVItem->iSubItem == 0) I'll let you turn into something correct since it's now more than 2 in the morning and I need some sleep even if you don't. Gerard

2 1

Listview Unicodification (take 4)
by Dimitrie O. Paun 16 Jan '02

16 Jan '02

OK guys, This one fixes the bug found by Gerard (thanks a lot -- very good spotting). You can find the patch here: http://www.cs.toronto.edu/~dimi/listview-unicode-4.diff This one can go to Alexandre, as far as I'm concerned. So if you still see big problems, please let me know. -- Dimi.

1 0

Re: WSAAccept
by Martin Wilck 16 Jan '02

16 Jan '02

Hi Daniel, I have some concerns wrt your WSAAccept implementation you sent to wine-patches on Sunday. I have thought a bit about this function (did you notice my preliminary implementation on Nov. 7 (subject "[EXPERIMENTAL PATCH]: Winsock2" ?). The problem I see is related to the treatment of the peer when the user-supplied condition function returns CF_REJECT or CF_DEFER. Your implementation calls WS_Accept _before_ calling the condition function. That is, the peer will think its connection request was accepted, and possibly start to send or poll for data. Then if the Condition function returns CF_REJECT, the connection is closed. Even worse, for CF_DEFER, the peer receives nothing, the new socket cs returned by WS_Accept remains open but is forgotten after WSAAccept() returns (correct me if I'm wrong). So the peer will think it's connected, but no future WSAAccept or WS_Accept call will ever return a socket connected to it, and it'll be sending data into the void. I think you must at least closesocket(cs) for CS_DEFER as well to avoid this situation. Alternatively (that's the way I did it) the new socket can be stored in the wineserver to be returned by future WSAAccept calls. The Winsock2 specs say that "[WSAAccept] extracts the first connection on the queue of pending connections" (after a CF_DEFER, that should be the previously deferred connection, until it's either accepted or rejected). Moreover, it says that "[In the CF_DEFER case] no action about this connection request should be taken by the service provider". Taken seriously, this means that it's wrong to call accept() on this request before a positive decision was made by the Condition function. Summarizing, the peer should see: CF_ACCEPT: his request is accepted (this case is OK). CF_REJECT: his request is rejected (not ok, he receives an accept followed by a close). CF_DEFER: nothing (not OK, he receives an accept followed by ???) I have no idea how this affects behaviour of "real" applications. The essential problem is that there is no way (well, I have found none) to obtain the peer's socket address on Linux without accept()ing first. I guess that is what made you call accept() before the condition routine. Perhaps someone can come up with a method to read the socket address of a waiting connection request before it's accepted, but my guess is this won't work without a kernel hack. At the very least, though, I consider it necessary to include a FIXME that tells users that this function may behave different from what the specs say. Please don't get me wrong, it's great to see other people work on Winsock, and your code is clean. I just thought I need to express these concerns. Regards, Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 3

Filesystem Regression Test, was: Re: RESEND: Fix return value ...
by Uwe Bonnes 16 Jan '02

16 Jan '02

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello. Please use this patch instead of the previous one. I'll Dmitry> try to find some time and figure out how to write regression Dmitry> test for this functions. Please let us know if you find some sensible way to test filesystem functions. What I do now is - export some filesystem tree with SMB(NCP) - import it in Vmware with some drive letter - use the same drive letter in the wine-config for the same filesystem tree I don't think this solution is very sensible for a more generalized test... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 7

Using Python with Wine
by Gerard Patel 16 Jan '02

16 Jan '02

I have finally succeeded in using Python to make test applications. I find the idea pretty interesting to build quick-and-dirty applications to test a specific api. Here is how it can be done. Get from www.python.org : Python 2.1.1 for windows http://www.python.org/ftp/python/2.1.1/ Get from ftp://ftp.nightmare.com/pub/python/python-ext/ npstruct-2001-05-20.zip calldll-2001-05-20.zip dynwin-2001-05-20.zip Install python under Wine : ./wine -managed <path to python installer>Python-2.1.1.exe unzip the 3 additional packages under the Python directory (c:\program files\python21) add these 3 directories to the Python path. The easier way is to create a dir.pth file in the main Python directory containing : c:\\Program Files\\Python21\\calldll c:\\Program Files\\Python21\\npstruct c:\\Program Files\\Python21\\dynwin add the path to the main python directory to the Wine path. launch python (the command line version, I did not try the gui version) : wine python Here are some commands I tried (I edited out most of the Wine Fixme and Err, and removed prompts) : import windll (.... 1. Basic example) user32=windll.module("user32") cstr=windll.cstring MessageBox=user32.MessageBox MessageBox(0,cstr('test'),cstr('example'),0) 1 (1 is the value returned by MessageBox - success) (.... 2. more involved example, using buffers) winmm=windll.module('winmm') winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) 279 (error 279) buf=windll.membuf(256) winmm.mciGetErrorString(279,buf,255) 1 import calldll print calldll.read_string(buf) Cannot use 'all' as the device name with the specified command. (I fix line 516 of mci.c to return a correct error message and compile Wine, try again) i = winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) fixme:mci:MCI_LoadMciDriver Couldn't load driver for type WAVEAUDIO. If you don't have a windows installation accessible from Wine, you perhaps forgot to create a [mci] section in system.ini print i 306 (I had indeed commented out the waveaudio entry in my system.ini -> fix user error and try again) winmm.mciSendString(cstr('play c:\\sound\\welcome.wav'),0,0,0) 0 (well, the mci call returns 0 - success - the sound is not played completely - but that's another story :-//) (.... 3. complete example of testing a gui function : TextOut) import windll cstr = windll.cstring gdi32 = windll.module ('gdi32') import wingdi import windc import winwin class test(winwin.python_window): style = winwin.WS_OVERLAPPEDWINDOW def WM_DESTROY (self, wparam, lparam): winwin.user32.PostQuitMessage (0) def WM_PAINT (self, wparam, lparam): dc = self.begin_paint() gdi32.TextOut(dc.handle,50,50,cstr("text output"),11) self.end_paint() if __name__ == '__main__': import msgloop w = test("test 1").create() w.show_window() msgloop.go() (in this example most of the code use calls to higher level functions hiding somewhat the Win32 Api, except the api call, that uses the 'handle' member of the dc object to access the Win32 object) There is a Python error message when the gui app terminates, however this is a problem with the python system (it shows the same under WinNT, for example) Note : don't begin command by spaces - Python interpreter don't like it. Also, Python don't care for case but Wine does, so writing 'mcisendstring' will fail, for example.

1 0

fixme:richedit:RICHED32_WindowProc Unknown message 129
by lawson_whitney＠juno.com 15 Jan '02

15 Jan '02

Good day! Thanks, Daniel Walker, for your work on riched32. I don't know what or why is richedit and I'm kind of GUI-challenged, or I'd have a go at implementing these myself, but I have an app that uses it, so if traces would help, just say which traces and if you want them for builtin or native riched32. The app fails with a bogus message box: "Insufficient memory or disk space" after these three fixme's with the builtin, so those traces should be pretty short, but maybe it would also be useful to try to use spy on the native riched32. If spying on msvcrt, mfc42, and/or the app's own dll's is likely to make noise, I can filter it out, but at this point I don't know. fixme:richedit:RICHED32_WindowProc Unknown message 129 fixme:richedit:RICHED32_WindowProc Unknown message 528 fixme:richedit:RICHED32_WindowProc Unknown message 130 Regards, Lawson

3 4

C testing framewok. Updated. SystemParametersInfo unit test.
by Andriy Palamarchuk 15 Jan '02

15 Jan '02

Attached are new version of the C testing framework. Changed SystemParametersInfo unit test to use this framework. Alexandre, I need to use a couple switches for the test application: - output verbosity level - die on failure indicator Can you suggest how to implement these switches - as command-line arguments or environment variables? Using environment variables is easier for me - I don't need to do parsing of 2 types of command line (main and WinMain formats), no need to force test developers to use function like start_test( args ) in the beginning of their tests. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

2 1

Re: What are you really aiming to do with winetest?
by Alexandre Julliard 15 Jan '02

15 Jan '02

Patrik Stridvall <ps(a)leissner.se> writes: > It would be nice if you commented on what you > think about my spec2pm script for automatically > generating Perl modules for calling the Windows API. Sure; I was looking into integrating it, but found some problems. I agree generating modules automatically is a good idea; the main problem right now is that we cannot get the return type of the functions, and this breaks functions returning a string. > Also, I'm not sure that you are trying to do: > The files generated by make_symbols are quite useless, > they just contain a lot of LOCAL variables. They seem to work just fine for me, but I'm no Perl expert, so if you think your approach is better I'll do it that way. -- Alexandre Julliard julliard(a)winehq.com

1 0

Sponsoring by IBM, lets get it done
by Roland 15 Jan '02

15 Jan '02

Hello, to put an end to this discussion, I will start trying to contact people at IBM for sponsoring, unless someone more qualified wants to do it. Anyone? Ok, so where do I start, can someone give me an email adress? I also wanted to know some technical terms: 1. How do you call the person who is TECHNICALLY responsible for a project, in this case, for the Linux stuff at IBM? 2. How do you call the person who is FINANCIALLY responsible for a project, in this case, for the Linux stuff at IBM? If someone can provide the answer to 1 and 2, it would help, the email adress I will figure out myself...if no one can provide one... Thanks...Roland

1 0

Listview Unicodification (take 3) (fwd)
by Dimitrie O. Paun 15 Jan '02

15 Jan '02

[once again, I attached the patch by mistake, and the mail did not go through...oh well, that happens if you don't sleep at night:) ] Hi folks, Here is the latest version of the Unicode ListView control: http://www.cs.toronto.edu/~dimi/listview-unicode-3.diff It fixes a silly (e.g. brown paper bag type of bug, really) pointed to me by Gerard (thanks!). It does fix a problem with the subitem handling (before, the subitems were simply ignored). Tested with the Common Control Spy Sample thingy from MS. I still could not get Gerard's examples going, and it seems I really need to test with those... If things look OK, I will forward it to Alexandre soon. -- Dimi.

1 0

Re: async_private + ReadFile() etc. immediate completion
by lawson_whitney＠juno.com 15 Jan '02

15 Jan '02

On Fri, 11 Jan 2002, Martin Wilck wrote: > > Here are 2 small patches. > Both apply on top of the patch I sent yesterday which started this > thread. > > 1) fixes a bug that I discovered myself, > 2) Adds TRACES to several functions to simplify debugging. > > 2) Is not meant for applying to CVS!!! > > However, Lawson it would be nice if you produce a new trace with these two > patches applied. > > start your app with --debugmsg trace+file,trace+thread,trace+comm. > > Regards, > Martin > The app works with those patches, so the trace is much bigger. The app also works with those patches, but without tracing (sometimes tracing might change an app's behavior). Disclaimer: juno 1.49 is _a_ brain-dead 16 bit comms app, but not the only brain-dead comms app. I can't promise all of them will work. I don't guess all of wine-devel wants the trace. Anybody who does may have it for the asking. Lawson ---oof

2 1

Re: DPA_LoadStream
by Uwe Bonnes 15 Jan '02

15 Jan '02

>>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: Aric> + if (streamData.dwItems > 536870911) Shouldn't have such a magic number either a comment or better be defined as a constant with some sensible name? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

2025

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