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

how to unsubscribe?

by Ludootje

Hello, First of all I'd like to say I'm sorry to both you people with this. I tried some stuff to unsubscribe by going to the default urls of sourceforge lists etc, but that didn't helped. I went to wine.sf.net, but didn't found any public mailing list, and I can't remember where I subscribed to this list. The reason I want to unsubsribe (temporariliy) is that I'm off for vacation, and don't feel like reading tons of wine-devel mails when I'm back ;-) So, where can I unsubscribe, and resubscribe (for when I'm back)? Or even better, is there an option like with sourceforge lists where I just edit my preferences and check the box which says I don't want to receive any mails anymore temporarily? Thanks in advance, Ludootje --- Linux: because rebooting is for adding hardware. M$: because choices are confusing.

March 29, 2002

problems with the alt button and window switching

by Rizsanyi Zsolt

Hi! If I change the window with keyboard (eg with ALT-TAB), then when I switch back to the wine window wine still thinks that the ALT button is depressed. I happens, because the key event of pressing ALT arrives to the wine window before the switch. And I see in the console (with --debugmsg +key) the next lines: trace:key:X11DRV_KeyEvent state = 10 trace:key:X11DRV_KeyEvent KeyPress : keysym=FFE9 (Alt_L), ascii chars=0 / 0 / '' trace:key:X11DRV_KeyEvent keycode 0x40 converted to vkey 0x12 trace:key:X11DRV_KeyEvent bScan = 0x38. trace:key:queue_kbd_event wParam=0012, lParam=20380001, InputKeyState=81 trace:key:TranslateMessage (WM_SYSKEYDOWN, 0012, 20380001) trace:key:TranslateMessage Translating key VK_MENU (0012), scancode 38 trace:key:X11DRV_ToUnicode (0012, 2038) : faked state = 10 trace:key:X11DRV_ToUnicode ToUnicode about to return 0 with char bbc6 trace:key:queue_kbd_event wParam=0012, lParam=c0000001, InputKeyState=1 That is the key state has been changed. And when I return to the wine window (by keyboard or mouse) it acts like if the ALT button were depressed. The solution is that the key states should be reset when the wine gets back the focus or loses the focus. That is more exactly in windows/winpos.c in the function WINPOS_SetActiveWindow when the hWnd is NULL ! That is the case when switching from a wine window to an non-wine window. So I have found the place :), just I dont know whats the preferred way to reset all the key states to not pressed. I have added the next few lines: --- oldwinpos.c Fri Mar 29 16:54:59 2002 +++ winpos.c Fri Mar 29 16:55:08 2002 @@ -1217,6 +1217,12 @@ if ((wndPtr = WIN_FindWndPtr(hWnd))) hWnd = wndPtr->hwndSelf; /* make it a full handle */ + /* reset key states when switching to a non-wine window */ + if (hWnd == 0) + { + InputKeyStateTable[VK_MENU] &= ~0x80; + goto CLEANUP_END; + } + /* paranoid checks */ if( hWnd == GetDesktopWindow() || (bRet = (hWnd == hwndActive)) ) goto CLEANUP_END; And now my problem is fixed. But I have experienced the same problem with the Control button (altough it is harder to reproduce). So maybe all the key states should be reset. So I would like to have this patch or something similar in wine. Best regards Zsolt Rizsanyi

March 29, 2002

RE: Improving the regression testing infrastructure

by Geoffrey Hausheer

> > True. So what we need is to add a function in the > testing framework > > so that tests can get argc/argv/envp. Seems like a > reasonable approach. > I was more thinking adding some wt_argc and wt_argv, with init in main > so that we don't have to deal with the portability issues of > the __argc, > __ ARGC... Is there a reason we can't just use environment variables rather than argc/argv? I would think that would be less of a hassle than using argc/argv. .Geoff ----------------------------------------------------- Protect yourself from spam, use http://sneakemail.com

March 29, 2002

Re: Improving the regression testing infrastructure

by Eric Pouech

> at least until I can find a good way to test > CreateProcess... a bit out of topic (from the question), but I have an embryonic CreateProcess test, so don't bother with that (and there is a lot to test here)

March 29, 2002

Re: small comm patch

by Dimitrie O. Paun

On March 29, 2002 01:01 pm, Andreas Mohr wrote: > Hi all, > > - add verbose messages for "no serial support" issues > - minor fixes > + ERR("no OS support for CLRRTS !\n"); > + ERR("no OS support for CLRDTR !\n"); ... > + ERR("no OS support for SETDTR !\n"); ^^^ These should be a MESSAGE (as it's intended as info for the user), or a WARN (resource problem), but not an ERR which should signal an internal Wine problem. -- Dimi.

March 29, 2002

Re: Improving the regression testing infrastructure

by Andreas Mohr

On Fri, Mar 29, 2002 at 11:21:23AM -0000, Geoffrey Hausheer wrote: > I know regression testing isn't as interesting as > doing real development, and so I appologize with once > again spamming the list with regression questions... NP. I'm sure it helps :) [...] > So does anyone thing that creating a easily > parsable list with the state of the current tests is this > a reasonable thing to do, and would creating a simple > file in each /tests directory with the information be > good enough? If so, I can add one to my next test, and > update it with what I've done so far. I don't think you want a separate list for each test. Hmm, or OTOH, if you want that, then make sure to have a unique file name, e.g. mytest.testlist. Then you could simply do find . -name "*.testlist"|xargs grep "TESTS: MyFunc" to search *all* list files check whether a particular function is being tested already. > In general, while Francois' presentation is a > good place to get started, I think it'd be a lot easier > if there was a document off of winehq with > recommendations on how to build, test, and document > tests. Lowering the difficulty threshold, is more likely > to draw more people to do so. Definitely. Creating such a document is on my ToDo list, but let me alter winebootup first to make it submittable ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.arcor.de/andi.mohr/

March 29, 2002

Re: wineinstall patch

by Urivan Saaib

Hi Chris, > This patch has some significant changes to wineinstall, the most notable > being that we no longer let the user run wineinstall as root user and that we > use su -c"command" to run 'make install' and to modify the users > /etc/ld.so.conf file if necessary. I wanted to get feedback from people on > these changes. Great ! a couple of the guys from our linux user group are talking about CW's wine and as they are experimenting with WineHQ, the installation is always a big issue (for those who work kind of all day don't want to spend much time figuring out the installation procedure). Yes, they should read the README but ... I'm continuing testing those of the top-10 most popular software from the download archives sites, and will post soon the results. Regards, _______________________________________________________ Urivan Saaib Vice-President Open Source Communications http://www.osocomm.com Email: saaib(a)osocomm.com

March 29, 2002

Improving the regression testing infrastructure

by Geoffrey Hausheer

I know regression testing isn't as interesting as doing real development, and so I appologize with once again spamming the list with regression questions... As I've been writing tests (only for the last week or so), I realized that as we get a lot more tests, it will be very difficult to keep track of what is being tested, and what is not. I'd like to propose a list of which functions for each DLL are being tested, which file tests it, as well as any comments on the current tests. Currently, there is no great way to do this. I may use several functions in a directed test which I am not actually testing (for instance I've found it necessary to retrieve the page-size using GetSystemInfo, but my tests have nothing to do with this function, and so writing a directed test for it is a task for another day). Thus just grepping for which functions are used in a test is not sufficient. Also, I have found that some functions, or even specific task functions are very difficult to test, and so I've been leaving these out so that perhaps people ore skilled than myself could take a crack at them late (A good example is testing inheritance with CreateThread. It is a task that is beyond my capabilities at the moment, at least until I can find a good way to test CreateProcess...this would be much easier if Windows had something equivalent to 'fork'). In any case, I've tried to be thorough about commenting what I do and don't test, but it would be a lot more convenient if this information was more easily parsed than trying to find my comments intersperesed through the tests. So does anyone thing that creating a easily parsable list with the state of the current tests is this a reasonable thing to do, and would creating a simple file in each /tests directory with the information be good enough? If so, I can add one to my next test, and update it with what I've done so far. In general, while Francois' presentation is a good place to get started, I think it'd be a lot easier if there was a document off of winehq with recommendations on how to build, test, and document tests. Lowering the difficulty threshold, is more likely to draw more people to do so. Thanks, .Geoff

March 29, 2002

Re: make test leaves 2 wine processes running

by Sylvain Petreolle

> Aha, this error is interesting. I'm not the only > one getting this > kind of error then. And I bet that your kernel is > >2.4.5, and most > likely >=2.4.9. I'm running 2.4.9-31 on RH 7.2. > -- > Francois Gouget fgouget(a)free.fr > http://fgouget.free.fr/ > The software said it requires Win95 or better, > so I installed Linux. Pretty good fortune :) ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

March 29, 2002

Re: Help me to resolve undefined reference

by Francois Gouget

On Thu, 28 Mar 2002, Ku Cheng wrote: > Andriy, > > After putting the prototype of DisconnectNamedPipe( ) in the winbase.h > file, finally my program can link successfully. Previously I put "extern > bool DsiconnnecrNamedPipe ..." in my source file to avoid compilation > error. But it still failed at linking phase. What is the difference of > putting the declaration in winbase.h and in my local file? How is the > winbase.h used in "winemaker" and "configure"? Is there any documentation > explaining this? This is a regular C vs. C++ issue, not specific to Winelib. When you put it in your source file you were probably missing the "C" in extern "C" ... In winebase.h all function declarations are enclosed with: #ifdef __cplusplus extern "C" { #endif ... #ifdef __cplusplus } #endif So because "C" was missing, the compiler assumed it was a C++ function and mangled the name. Then at link time there was no function by that (mangled) name. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

March 29, 2002