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

Full screen, always on top window doesn't get keyboard input

by Ori Pessach

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

Jan. 19, 2002

WinProc recursion

by Niclas Carlsson

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)

Jan. 19, 2002

Re: common controls updown patch

by David Elliott

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

Jan. 19, 2002

Re: common controls updown patch

by Shane Shields

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? > 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 ;-) > has several GUI toolkits. I think the default toolkit is Tk (yuk) but what do you think of QT (KDE's gui) > 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) ;-) > > 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!) Shane _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

Jan. 19, 2002

Re: _UNICODE vs UNICODE

by Andriy Palamarchuk

Francois Gouget wrote: > 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. I came across this problem when I found out that _T("sss") preprocesses to "sss" in both - Unicode (should be L"sss") and ANSI modes. The change in winnt.h fixed it. I assumed that the same problem was in other places. Andriy Palamarchuk

Jan. 18, 2002

Re: _UNICODE vs UNICODE

by Francois Gouget

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

Jan. 18, 2002

Re: common controls updown patch

by David Elliott

On 2002.01.18 00:57 Shane Shields wrote: > 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 hmm... VB... yeah.. BASIC in general tends to lend itself to crappy programs, always has, always will. However BASIC on a PCjr was my first language, so I guess it was okay to start with. Except for the fact that BASIC is so screwed up it screws with your mind and it takes a long time to realize that almost no other programming language does things like BASIC. Might I suggest Python if you are in the process of learning programming. Python is an extremely elegant language, interfaces well with C code, and has several GUI toolkits. I think the default toolkit is Tk (yuk) but wxWindows has a python version you may want to check out. The real wxWindows (C++) is just amazing for ease of GUI programming, I assume the Python version is probably easy to use too. > 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. > As Dimitrie said, that means if delta is negative then 1, if positive or 0 then -1. The general form is booleanexpression?then:else > Shane > > 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. -Dave

Jan. 18, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Dimitrie O. Paun

On Fri, 18 Jan 2002, Andriy Palamarchuk wrote: > You definitely need #ifdefs or just unicode > conditional block around explicit calls of xxxW > functions. Otherwise these functions will be called on > platforms which do not support Unicode, even if test > application is compiled in ANSI mode. Fine, you have a point. Just do: if (UNICODE) { <W explicit code> } instead. I hate #ifdefs! If we do that, we can use the tests to also determine the performance difference between A & W, which is great 'cause it will give us an idea of the penalty for all those string translations and memory allocations. (I think this can be added to the 'Advantages' section of my previous mail, :) ) > In general I like your idea. Thanks. -- Dimi.

Jan. 18, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

--- "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > On Thu, 17 Jan 2002, Alexandre Julliard wrote: > -- if explicit A or W handling is required, simply > use the xxxA or xxxW > without any #ifdefs You definitely need #ifdefs or just unicode conditional block around explicit calls of xxxW functions. Otherwise these functions will be called on platforms which do not support Unicode, even if test application is compiled in ANSI mode. In general I like your idea. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 18, 2002

Re: wine-patches@winehq.com

by Alexandre Julliard

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

Jan. 18, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Dimitrie O. Paun

On Thu, 17 Jan 2002, Alexandre Julliard wrote: > ...and makes sure that the W functions are never actually tested with > Unicode input. 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. > The functions *are* really different and have different testing > requirements. OK, this is good point. But the truth of the matter is that the semantics of 99.99% of the functions should be encoding independent, because the documentation from MS is, the way you are supposed to write your code is, etc. On the other hand, as you pointed out, we would really want to test all the special handling for the Unicode cases. I think these two requirements will in fact push us to a better sollution. As you well pointed out, when we do write tests, we want to test a lot of things: W->A->W conversions, surrogate handling, non-spacing chars, etc. With the current compiler support, and the current developer knowladge, I am afraid we will only see tests like this: WCHAR teststr[] = { 'U', 'n', 'i', 'c', 'o', 'd', 'e', '\0' }; which tests nothing of the interesting cases you mentioned, and we will endup with twice as much code foolishly. My proposal: -- abstract away the generation of test strings (more of this later) -- write mosts tests in an encoding independent manner -- if explicit A or W handling is required, simply use the xxxA or xxxW without any #ifdefs -- always compile and run the tests two times for ANSI/UNICODE The code will look as such: TCSTR str = TSC_RAND; while ( (str = teststr(str) ) { <your test which uses 'str' goes here> } The TSC_XXX set of constants (TSC stands for Test String Class), identifies a class of strings (such as, 3 charactes long, etc.). The teststr() iterates though those strings. It has the following prototype: TCSTR teststr(TCSTR); And it should be fairly simple to implement (I can provide code, if people are interested). Advantages: -- we can pass in one for the ANSI case, but a few for the Unicode case where we want to test various things. -- for regular unit testing, we may want to return only one representative string for ANSI, and one complicated string for Unicode, but from time to time we may want to run the tests over a large number of test strings. -- the tests so writen can be used to identify and test performance problems, by simply returning a lot more strings, and by logging how long it took to run the test. -- we have a clean way to abstract the testing string, and so most of the test can be written in an encoding independent way. -- it makes it no harder, in _any_ way, to write encoding specific tests. In fact, one can use the teststrA/teststrW versions for their encoding specific tests to get the above mentioned benefits. -- it should be trivial to instrument the Makefiles to compile the tests twice, and thus we should test both the ANSII and the Unicode cases all the time. (that is, this should not be an Alexandre only task :)) Comments? -- Dimi.

Jan. 18, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

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/

Jan. 18, 2002

XP registry

by Eric Pouech

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.

Jan. 18, 2002

Re: Wine "Please Report" Error

by Andreas Mohr

On Fri, Jan 18, 2002 at 04:07:41AM -0500, Scott Sipe wrote: > 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(a)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? Nothing ;-) I already updated this, it will be in my next "docu" patch. (it's some unknown Win XP registry node ID) If anyone has further info on what 0x686c is: tell us. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 18, 2002

Wine "Please Report" Error

by Scott Sipe

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(a)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

Jan. 18, 2002

Re: common controls updown patch

by Shane Shields

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/

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Andriy Palamarchuk

Francois Gouget wrote: > The only issue I see is if the xxxA is implemented but xxxW is not or > reciprocally. Then we have a test that fails but cannot really be put as > a TODO since xxxA works. the right way to fix this is to implement the > function that is missing. Another way to handle this issue is to also > have a 'TODOA' and a 'TODOW'. Oh, that's an easy one :-) : #ifdef _UNICODE TODO(xxxW) #else xxxA #endif Andriy Palamarchuk

Jan. 17, 2002

Re: License problem with files in dlls/icmp/

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > Cool. Can you provide a URL that documents this? It'd be handy > for a lot of projects that use BSD code but still think they > need to credit UCB. The official document is here: ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change It has also been discussed on slashdot: http://slashdot.org/articles/99/09/02/189210.shtml -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2002

Re: License problem with files in dlls/icmp/

by Dan Kegel

Alexandre Julliard wrote: > > Ilja Kamps <ikarus(a)ikarus.ath.cx> writes: > > > 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. > > UC Berkeley has announced some time ago that the advertising clause on > their code can be considered null and void and removed, so that's not > really a problem. We could probably remove the clause to make it > clear. Cool. Can you provide a URL that documents this? It'd be handy for a lot of projects that use BSD code but still think they need to credit UCB. - Dan

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > And having a single test that can be used to test both A and W > reduces code duplication, which helps maintainability and reduces the > amount of work we have to do. ...and makes sure that the W functions are never actually tested with Unicode input. 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. The functions *are* really different and have different testing requirements. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Francois Gouget

On 17 Jan 2002, Alexandre Julliard wrote: [...] > What's ugly is that you don't compile what you write. This is the most > sure recipe to make sure the code doesn't compile. People will test > code in ASCII mode, and when some poor soul (like me ;-) tries to > compile in Unicode mode to run regression tests it won't work because > nobody ever tried to compile it that way. Or worse it will compile but > not do what was intended because someone has been mixing char and > tchar or whatever. I would call it part of normal test debugging. You could also reject tests that don't work in both modes. We could also have a Mr 'Unicode' whose work would be to make sure tests work in Unicode and fix them if necessary. > xxxA and xxxW are different functions (and in fact do not necessarily > behave the same way for all inputs), and they need to be tested > independently. Most of the time they behave the same way, and in the few cases where they don't, one can still call xxxA and xxxW. And having a single test that can be used to test both A and W reduces code duplication, which helps maintainability and reduces the amount of work we have to do. The only issue I see is if the xxxA is implemented but xxxW is not or reciprocally. Then we have a test that fails but cannot really be put as a TODO since xxxA works. the right way to fix this is to implement the function that is missing. Another way to handle this issue is to also have a 'TODOA' and a 'TODOW'. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > The Win32 API is meant to be used that way, and so we should test it. > Besides, I don't see why they are so ugly. Writing xxx instead of xxxA or > xxxW is not ugly in any stretch of the word. What's ugly is that you don't compile what you write. This is the most sure recipe to make sure the code doesn't compile. People will test code in ASCII mode, and when some poor soul (like me ;-) tries to compile in Unicode mode to run regression tests it won't work because nobody ever tried to compile it that way. Or worse it will compile but not do what was intended because someone has been mixing char and tchar or whatever. xxxA and xxxW are different functions (and in fact do not necessarily behave the same way for all inputs), and they need to be tested independently. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2002

Re: What are you really aiming to do with winetest?

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > 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. Let's leave it that way for now. > 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. Definitely in the test itself, and with a different name. We want GlobalGetAtomNameA to call the corresponding kernel function directly, not have some kind of hidden wrapper that transforms arguments; this would make it impossible to find out what's going on. -- Alexandre Julliard julliard(a)winehq.com

Jan. 17, 2002

Re: C testing framewok. Updated. SystemParametersInfo unit test.

by Dimitrie O. Paun

On Thu, 17 Jan 2002, Alexandre Julliard wrote: > No, *please* don't do that. These Unicode macros are an ugliness that > we should stay away from; in fact we probably want to make it > impossible to use them, just like we do inside Wine itself. Please > write tests to call both A and W functions explicitly; it really isn't > much more work than testing a single variant anyway. But Alexandre, The Win32 API is meant to be used that way, and so we should test it. Besides, I don't see why they are so ugly. Writing xxx instead of xxxA or xxxW is not ugly in any stretch of the word. Moreover, you have to realize that writing tests is _boring_ code. A test may take 20-30 lines of code or more, asking someone to duplicate all that crap (and maintain, when things break!!!) is simply unreasonable, when it's really dubious what you get out of all that additional effort. Incidentally, I just started working (a few month ago) for a company that's big on XP, and so we write tests for everything we do, so I know what I'm talking about when I say writing tests is a chore! :))) -- Dimi.

Jan. 17, 2002

Re: [PATCH] Overlapped recv(), WSARecv()

by lawson_whitney＠juno.com

Thought I sent that before, but it seems I forgot. Lawson

Jan. 17, 2002