December 2001 - Wine-Devel - list.winehq.org

Re: We *really* need a development model change !

by Andriy Palamarchuk

--- Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > On Wed, Dec 26, 2001 at 10:07:20AM -0800, Andriy > Palamarchuk wrote: > > Andreas Mohr wrote: [... skipped ...] > > - it would be better if the suite print summary > > information and information about failed tests > only > Yep. Current output is something like: > WINETEST:test:Loader_16:LoadModule:FAILED:01:[retval] > WINETEST:test:Loader_16:LoadModule:FAILED:12:[retval] > WINETEST:test:Loader_16:LoadModule:FAILED:13:[retval] > > or, in case of success, only: > WINETEST:test:Loader_16:LoadModule:OK I mean something like: =================== Run: 1234 tests Failed: 2 Errors: 1 Fail 1: <....> Fail 2: <....> Error 1: <....> =================== In the example above failture means condition check failure, Error - exception. I suggest to print nothing for successfull tests. At least this is the way I am accustomed with JUnit. We are not interested in successfull tests, are we? ;-) > This output is pretty useful, I think: > It can be parsed *very* easily, and grepping for > regressions is also pretty > easy. > > "WINETEST" exists to be able to distinguish this > output from bogus Wine > messages, > "test" indicates that this is a test line output > versus a warning message or > similar output, > "Loader_16" indicates testing of 16bit loader > functionality, > "LoadModule" - well... ;-) > "FAILED" - obvious > "01" - test number 01 failed. > "[retval]" - contains the (wrong) return value of > the function, if applicable. Looks simple and the output is really useful. I just don't see any reason to show information about successfull tests. At least we can get short form of the output by clipping all "Ok" messages from your suggested form. > BTW, I think having a test suite wouldn't be about > hunting regressions > at first: just look at my LoadModule16 example and > you'll see that we're > still quite far from hunting regressions *only*. > My guess is that we'll be shocked at how many > functions fail in how many ways. Agree, agree, agree... We can even use eXtreme Programming approaches :-) See http://xprogramming.com/ and other sites on the subj. I also like this article: http://members.pingnet.ch/gamma/junit.htm I use JUnit extensively and like the whole idea. > > - make the test suite more "visible" for existing > > developers. Ask them to run the test suite before > > submitting a patch? > No, I don't think so. > I think it suffices if Alexandre runs the test suite > before or after every > large commit cycle. > That way he'd be able to back out problematic > patches. > Asking developers to run the *whole* test suite for > each patch could be > pretty painful. I don't see why running the unit tests is paintful. I'd estimate that it would not take more then 5 minutes to test all 12000 W32 functions. We also can keep tests for slow/rarely changed areas of API in separate "complete" suite. I think the test suite is for developers, not for Alexandre (I meas as a team leader :-) or QA. This is why I want to increase "visibility" of unit tests. Again, the developers will more likely to contribute to the suite if they will remember about it. I do not suggest to enforce the unit test usage because we'll always have developers/companies who don't want to do that. It would suffice to recomment before submitting a patch to check that we have the same (accidentally - less :-) number of failures as we had before or report any new bugs introduced. It is even Ok to have increased number of issues as soon as developer consiously makes decision to break something. Compact tests output I describe above also will help to quicky identify any changes in unit tests output. > We'd also need to pass a winver value to the test > suite via command line > in order to let the test app adapt to different > windows environments > (and thus also to different wine --winver settings > !). Sounds good. > > - it would be greate to have functionality to > support > > output comparison? For some functionality it is > easier > > to write tests to compare output instead of doing > > explicit checks (e.g. tests, involving a few > > processes). The output can be redirected to file > and > > files compared. If we use files we need to store > files > > for Wine and a few versions of Windows :-( > Hmm, I don't quite get what exactly you're talking > about. Example: I have pretty big unit test for SystemParametersInfo function. Part of the test is to insure that WM_SETTINGCHANGE window message is fired when necessary. I have simple handler for the message which prints confirmation when the message received. I save output when I run tests under Windows and Wine and compare the output. Advantages - 1) simplicity, 2) I can see contents of the failure. To do explicit check I need to set up some communication (common variable, step counter etc) between the message handler and testing code. If these 2 code snippets are in different processes I need to use IPC to do explicit check? Ideally I'd like to pring nothing to the screen - developer does not need to see all this information. The information can be saved to file, and I need to keep separate files for Wine, (a few versions of ?) Windows. > > - what about running the suite weekly (or daily) > > automatically and publishing the results to > > wine-devel? > Good idea ! Might prove worthwhile. For this feature compact output is useful too. > > - most developers on this list have access to one > > version of Windows. Is it difficult to create > "testing > > farm" with remote access to a few versions of > windows? > > This would help developers to test their code on a > few > > platforms. Existing environments in the companies, > > involved in the project can be used. > Hmm, why ? > The idea is that hundreds (or hopefully thousands ?) > of volunteer Windows > developers create bazillions of test functions for > specific API functions. > That will happen on specific Windows version only, > of course. > Now we have a test framework for a specific API > function on a specific > Windows version. > Now if there are behavioral conflicts on different > Windows versions > (functions behave differently), then I guess people > will notice immediately > and fix the test function immediately to support > different behaviour of > different windows versions. > --> no problem at all. I was thinking not about unit tests only. Sometimes I'd like to know how different version of Windows behaves. The only option I have is to ask somebody who has such version to run a test (honestly - up to now I was lazy to ask anybody :-). But you are right - it is not a big issue. > > - I remember long time ago there was a post on > > wine-devel about using Perl or Perl-like language > for > > unit testing. > > What is current status of that project? > Hmm. That'd be programs/winetest/, right ? Lazy me ;-) Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 26, 2001

Re: Cooperation between Odin & Wine

by Sander van Leeuwen

On Wed, 26 Dec 2001 17:25:50 +0100, Rein Klazes wrote: >> For more information about Odin you can visit http://odin.netlabs.org (some information is outdated though). >> There you can find out where to download the sources (cvs). >I have one silly question about this. The cvs server address is >guest(a)www.netlabs.org:d:/netlabs.src/odin32, but the current version >of the linux cvs client is rejecting the DOS drivespec in it: First of all, the path is incorrect. I thought this was updated, but apparently not. The current path is e:/netlabs.cvs/odin32 >| cvs login: CVSROOT (":pserver:guest(a)www.netlabs.org:d:/netlabs.src/odin32") >| cvs login: may only specify a positive, non-zero, integer port (not "d:"). >| cvs login: perhaps you entered a relative pathname? > > and I have not been able to find a way to make it accept it. >Is there a way to use linux cvs client with Odin's server? Sorry, I can't help you with that. I never tried this with a linux cvs client. Sander

Dec. 26, 2001

Re: We *really* need a development model change !

by Andreas Mohr

On Wed, Dec 26, 2001 at 10:07:20AM -0800, Andriy Palamarchuk wrote: > Andreas Mohr wrote: > > I guess we really should change our development > model from trying tons of > > programs to *systematically* testing functions and > Windows mechanisms now. > > If we can show everyone where stuff is failing, it > might be a lot easier > > to attract new people. > > I *completely* support this idea. Benefits of such > test suite are enormous. Existing developers can > contribute a lot by adding test snippets for the > functions they create. Now they create such snippets > anyway and throw them away. Ah, good ! :-) Exactly. A lot of people create test code e.g. for undocumented functions etc. By adding a *slight* bit more work, they'd have a test for this function. > Comments: > - Don't want to reinvent the weel. Is there any > existing test suite framework we can use? Sorry, I > can't suggest any for C but I'm very impressed with > JUnit in Java. It is even Ok if the framework is GPLed > or LGPLed - I don't think any company will make > buziness based on the test suite. Hmm, good question. I don't know of any, but we should probably do some more research. After all it's about 12000 functions, so we should get it right. > - I /personally/ prefer CL interface only for such > suite Yes, yes, yes. *Much* easier to use. That's why I did exactly that kind of thing. > - it would be better if the suite print summary > information and information about failed tests only Yep. Current output is something like: WINETEST:test:Loader_16:LoadModule:FAILED:01:[retval] WINETEST:test:Loader_16:LoadModule:FAILED:12:[retval] WINETEST:test:Loader_16:LoadModule:FAILED:13:[retval] or, in case of success, only: WINETEST:test:Loader_16:LoadModule:OK (yeah, I know, wishful thinking ;-) This output is pretty useful, I think: It can be parsed *very* easily, and grepping for regressions is also pretty easy. "WINETEST" exists to be able to distinguish this output from bogus Wine messages, "test" indicates that this is a test line output versus a warning message or similar output, "Loader_16" indicates testing of 16bit loader functionality, "LoadModule" - well... ;-) "FAILED" - obvious "01" - test number 01 failed. "[retval]" - contains the (wrong) return value of the function, if applicable. BTW, I think having a test suite wouldn't be about hunting regressions at first: just look at my LoadModule16 example and you'll see that we're still quite far from hunting regressions *only*. My guess is that we'll be shocked at how many functions fail in how many ways. > - make the test suite more "visible" for existing > developers. Ask them to run the test suite before > submitting a patch? No, I don't think so. I think it suffices if Alexandre runs the test suite before or after every large commit cycle. That way he'd be able to back out problematic patches. Asking developers to run the *whole* test suite for each patch could be pretty painful. > - I think the suite test will consist from a few > separate applications because different tests may have > different requirements to GUI configuration, > processes, etc. We need a way to run all the > applications in one batch. Exactly. Which is why I really prefer simple text output. IMHO it's the only way to go. > - define variable which indicates whether the suite > runs under Wine. Such indicator can be used for Wine > "white-box" testing. Hmm, yes, that might be useful. We'd also need to pass a winver value to the test suite via command line in order to let the test app adapt to different windows environments (and thus also to different wine --winver settings !). > - it would be greate to have functionality to support > output comparison? For some functionality it is easier > to write tests to compare output instead of doing > explicit checks (e.g. tests, involving a few > processes). The output can be redirected to file and > files compared. If we use files we need to store files > for Wine and a few versions of Windows :-( Hmm, I don't quite get what exactly you're talking about. > - the suite applications size will be pretty big. Is > it better to move it to separate CVS tree? Yep, I'd say so. There definitely is no business for it to reside in the main Wine tree. > - what about running the suite weekly (or daily) > automatically and publishing the results to > wine-devel? Good idea ! Might prove worthwhile. > - most developers on this list have access to one > version of Windows. Is it difficult to create "testing > farm" with remote access to a few versions of windows? > This would help developers to test their code on a few > platforms. Existing environments in the companies, > involved in the project can be used. Hmm, why ? The idea is that hundreds (or hopefully thousands ?) of volunteer Windows developers create bazillions of test functions for specific API functions. That will happen on specific Windows version only, of course. Now we have a test framework for a specific API function on a specific Windows version. Now if there are behavioral conflicts on different Windows versions (functions behave differently), then I guess people will notice immediately and fix the test function immediately to support different behaviour of different windows versions. --> no problem at all. > - I remember long time ago there was a post on > wine-devel about using Perl or Perl-like language for > unit testing. > What is current status of that project? Hmm. That'd be programs/winetest/, right ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 26, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

C Unit test frameworks I found after a quick search: http://check.sourceforge.net/ http://people.codefactory.se/~spotty/cunit/ http://freshmeat.net/projects/autounit/ C++: http://sourceforge.net/projects/cppunit/ Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 26, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

Andreas Mohr wrote: > I guess we really should change our development model from trying tons of > programs to *systematically* testing functions and Windows mechanisms now. > If we can show everyone where stuff is failing, it might be a lot easier > to attract new people. I *completely* support this idea. Benefits of such test suite are enormous. Existing developers can contribute a lot by adding test snippets for the functions they create. Now they create such snippets anyway and throw them away. > I attached a preview of the posting I intend to post on *tons* of Windows > devel newsgroups ("Call For Volunteers"). That way we might actually get > hold of hundreds of Windows developers helping us implement a complete > test suite (complete tests of up to 12000 Windows functions). > Not to mention the additional PR we might get out of this... Lets ask for help only after the suite structure is more/less defined and we'll be able to give people something to work on. Comments: - Don't want to reinvent the weel. Is there any existing test suite framework we can use? Sorry, I can't suggest any for C but I'm very impressed with JUnit in Java. It is even Ok if the framework is GPLed or LGPLed - I don't think any company will make buziness based on the test suite. - I /personally/ prefer CL interface only for such suite - it would be better if the suite print summary information and information about failed tests only - make the test suite more "visible" for existing developers. Ask them to run the test suite before submitting a patch? - I think the suite test will consist from a few separate applications because different tests may have different requirements to GUI configuration, processes, etc. We need a way to run all the applications in one batch. - define variable which indicates whether the suite runs under Wine. Such indicator can be used for Wine "white-box" testing. - it would be greate to have functionality to support output comparison? For some functionality it is easier to write tests to compare output instead of doing explicit checks (e.g. tests, involving a few processes). The output can be redirected to file and files compared. If we use files we need to store files for Wine and a few versions of Windows :-( - the suite applications size will be pretty big. Is it better to move it to separate CVS tree? - what about running the suite weekly (or daily) automatically and publishing the results to wine-devel? - most developers on this list have access to one version of Windows. Is it difficult to create "testing farm" with remote access to a few versions of windows? This would help developers to test their code on a few platforms. Existing environments in the companies, involved in the project can be used. - I remember long time ago there was a post on wine-devel about using Perl or Perl-like language for unit testing. What is current status of that project? Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 26, 2001

Re: Cooperation between Odin & Wine

by Rein Klazes

On Wed, 26 Dec 2001 12:28:09 +0100 (CET), you wrote: > For more information about Odin you can visit http://odin.netlabs.org (some information is outdated though). > There you can find out where to download the sources (cvs). I have one silly question about this. The cvs server address is guest(a)www.netlabs.org:d:/netlabs.src/odin32, but the current version of the linux cvs client is rejecting the DOS drivespec in it: | cvs login: CVSROOT (":pserver:guest(a)www.netlabs.org:d:/netlabs.src/odin32") | cvs login: may only specify a positive, non-zero, integer port (not "d:"). | cvs login: perhaps you entered a relative pathname? and I have not been able to find a way to make it accept it. Is there a way to use linux cvs client with Odin's server? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 26, 2001

Re: CVS server

by Jan Dvorak

On Sun, Dec 23, 2001 at 12:11:25PM -0500, Dimitrie O. Paun wrote: > It looks like we're running an old version of CVS on the server, as it > complains it does not understand > > #cvs up -C > [johnydog(a)napalm wine]# cat CVS/Root :pserver:cvs(a)cvs.winehq.com:/home/wine [johnydog(a)napalm wine]# cvs update -d -P -C (Locally modified Make.rules.in moved to .#Make.rules.in.1.95) ... Works fine for me. > is it possible to upgrade it? That would be a good idea irrespective of > the -C problem, as the new versions fixed quite a few (nasty) bugs. > The rule is: never change a working system. If you are able to address/trigger any bugs than yes, it's neccessary. And, you know, in every project, most of the bugs fixed in latest release was introduced in just previous version. > -- > Dimi. > Jan Dvorak <johnydog(a)go.cz>

Dec. 26, 2001

Re: Wine Tasklist (UNC)

by Andreas Mohr

On Wed, Dec 26, 2001 at 12:08:46PM +1000, Mike McCormack wrote: > > Hi Francois, > > I think the best way to handle UNC pathes is to do it properly; Wine > should talk SMB/NBT directly to other machines on the network, not > through Linux's VFS layer. > > This approach would give high level of flexability to Wine. We could: Yep. Actually I've never understood why one would go through mount points for *dynamic* host paths ! In short: do it once, do it *right*. Don't go for a weak compromise. That's why I'm strongly in favour of high Samba integration. Wine really needs this functionality, AFAICS. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 26, 2001

err:heap:HEAP_CreateSystemHeap system heap base address 0x65430000 not available

by Rein Klazes

Date: Wed, 26 Dec 2001 12:51:22 +0100 X-Agent-Group: X-Agent-Format: 0 0 0 0 0 500000 0 0 1 0 "*" 0 Hi, This patch makes a two of my programs fail with the subject error message: | ChangeSet ID: 1008789390367047399282455 | CVSROOT: /opt/cvs-commit | Module name: wine | Changes by: julliard(a)wine2. 01/12/19 14:16:30 | | Modified files: | dlls/kernel : kernel32.spec | dlls/ntdll : Makefile.in debugtools.c ntdll.spec rtl.c | dlls/ole32 : ifs.c | graphics/win16drv: font.c | include : heap.h ntddk.h winbase.h winnt.h | memory : heap.c selector.c | Added files: | dlls/ntdll : heap.c | | Log message: | Moved heap functions to ntdll. | Got rid of internal heap flags. | Reimplemented MapLS to not depend on the segptr heap. Both programs use native win98 commctrl,comctl32 dll's. One of them is CDmage, available at http://cdmage.cjb.net Any suggestions? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Dec. 26, 2001

Re: Bulletproof the debugger.

by Michael Stefaniuc

Hello, please do not apply the previous patch, i did something very stupid. Use the attached patch instead (makes also better use of the C99 style return value). bye michael On Wed, Dec 26, 2001 at 01:09:06AM +0100, Michael Stefaniuc wrote: [snip] > I did a short check with > camus:~/work/wine$ grep -r -I -C snprintf ./ | less > and this is what I found: > - most of the time the return value of *snprintf isn't checked > - if the return value is checked it's mostly checked for C89 and C99 > style > - the attached patch should fix all the remaining cases. > Changelog: Michael Stefaniuc <mstefani(a)redhat.com> check the return value of *snprintf for C99 style overflow reporting -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 26, 2001

Patches for several bugs

by Sander van Leeuwen

Hi, Here are the bug fixes I promised. There are more, but I can post those at a later time. - controls\button.c CB_Paint, line 806 hBrush = SendMessageW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); if (!hBrush) /* did the app forget to call defwindowproc ? */ hBrush = DefWindowProcW( GetParent(hwnd), WM_CTLCOLORSTATIC, hDC, (LPARAM)hwnd ); -> (Auto)Check, (Auto)Radio & (Auto)3State buttons send WM_CTLCOLORSTATIC instead of WM_CTLCOLORBTN (verified in NT4) (fixes opening dialog buttons in Opera 6 (choose interface)) - dll\user32\text.c TEXT_GrayString, line 499 if(!hdc) { DeleteDC(memdc); return FALSE; } -> DC leak - COMCTL32: Comboex, rebar, tooltips, toolbar: NEVER delete the font object received by WM_SETFONT -> See attached diff files for comboex, rebar & toolbar. Our tooltips has too many differences for diff to produce usable output, but the changes are similar to the other three. - COMCTL32: Tooltips: wrong COMCTL32_Free calls -> 4 calls with wrong pointer: COMCTL32_Free(&lpttsi); should be COMCTL32_Free(lpttsi); - user32: frame tracking * - Only draw changed track frame instead of clearing the old one and * drawing the new one (less flickering) * - Send WM_MOVING when moving a window * - Send WM_SIZING only when sizing a window * - Fixed handling of rectangles changed by WM_SIZING/MOVING -> Can't easily produce diff file. Too many changes. (check src\user32\wintrack.cpp in our CVS tree) - USER32: groupbox redrawing fixes -> I am not 100% sure the same happens in Wine, but it looks like that. When an application changes the font or the text of a groupbox (smaller font or fewer characters), then the old text has to be erase properly or else you'll still see part of it. If I remember correctly, that could be seen in Opera 5.12 (property dialogs) -> Again, too many changes to produce a diff file. (check src\user32\button.cpp, BUTTON_SetText & BUTTON_SetFont) - USER32: static control -> our version supports more styles (SS_CENTERIMAGE, SS_REALSIZEIMAGE) and features (SS_ENHMETAFILE) (src\user32\static.cpp) Sander

Dec. 26, 2001

Cooperation between Odin & Wine

by Sander van Leeuwen

Hi, As some of you might remember I'm the lead developer of the Odin project. (project for OS/2 with the same goals as Wine). Odin is partly based on Wine code. The core dlls (gdi32, user32, kernel32) + some special dlls (winmm, directx, winsock) use some Wine code, but is basically incompatible with Wine for obvious reasons. Most of the remaining dlls are based entirely on Wine code. The last few years there has been little cooperation between both projects for several reasons. One of them is that we have far fewer active developers and cooperation sometimes proved to be difficult. Some source files of the two project had grown apart since changes were never merged back into Wine. Now, I'm trying to change this situation, but am wondering how to proceed. I can post bug fixes to this list, but it will be difficult for me to actually test these changes in Wine itself. (too time consuming) Posting diff files is not always possible due to the major differences between source files. Merging changes from Wine into our source tree is no problem. We can do that ourselves. However, it would be nice if compiler incompatibilites (we use IBM VisualAge C++, not GCC) could be resolved. There aren't many, but the IBM compiler is not always as flexible as GCC and of course doesn't understand any GCC extensions. It would be a big help if incompatible code could be changed. Switching compilers is not an option for us. I can post a (small) list of changes we had to make. The license of our project is not compatible with Wine, but the dlls that are largely based on Wine (such as comctl32, shell32, ole) are an exception to the project license. The sources of those dlls are released under the Wine license. In case there is ever interest in the other sources, then you can just ask me. I'd be happy to 'donate' them to Wine. For more information about Odin you can visit http://odin.netlabs.org (some information is outdated though). There you can find out where to download the sources (cvs). The next post from me will contains some patches for bugs in Wine that I've recently found. Sander

Dec. 26, 2001

Re: Wine Tasklist (UNC)

by Mike McCormack

Hi Francois, I think the best way to handle UNC pathes is to do it properly; Wine should talk SMB/NBT directly to other machines on the network, not through Linux's VFS layer. This approach would give high level of flexability to Wine. We could: * support NetDDE and DCOM with a common code base * use Windows file permissions and security properly * support unicode share names properly * support named pipes, etc across the network * eliminate SMB<->VFS<->SMB problems eg. parsing /etc/fstab There's three options: 1) write our own SMB code (wineserver talks NetBIOS/SMB) i have a short snippet of code to resolve NetBIOS names in CreateFile, but that is only the beginning of the effort. 2) link with a LGPL'ed CIFS implementation. http://www.ubiqx.org/libcifs/ (very incomplete, but maybe possible later, may still have threading issues) 3) get Samba to provide us with a Unix domain socket to talk with. (SambaTNG looks like the best bet there.) i have experimented with linking Wine to samba's libsmbclient and use it to open files. That works (i have a test patch), has threading and licensing issues (it's GPL). This would be alot of work, but i think it's the only way to do it properly. Mike > * UNC path handling > - for drives '\\.\e:', devices > - for network paths > - there's been a patch related to this recently but I believe it does > not cover all cases > - integrate with Samba to handle network UNC paths > - provide a way to mount/unmount drives at runtime, especially > network drives. One should be able to disable this in the config > file (for security reasons). > - Support for 'persistent' mounts... will require modifying the way w > specify which drives are mounted where. > - provide an applet to mount/unmount drives while Wine is running. ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

Dec. 26, 2001

Re: Bulletproof the debugger.

by Michael Stefaniuc

On Tue, Dec 25, 2001 at 01:38:26PM -0800, Francois Gouget wrote: > On Fri, 21 Dec 2001, Michael Stefaniuc wrote: > > > On Fri, Dec 21, 2001 at 01:52:12PM -0800, Medland, Bill wrote: > > > Bill Medland (medbi01(a)accpac.com) > > > Don't ask me why but on my setup vsnprintf returned a value greater than > > This is the new and correct behavior according to the C99 standard. All > > snprintf function should return in error case the number of characters > > that would have been written to the buffer if the size of buffer would > > have been big enough. > > This change while usefull will brake a lot of things. IMO the glibc is > > still using the old behavior. I was wrong, it's using the C99 behaviour (at least on Red Hat Linux 7.x) > By the way did someone do a systematic check for this problem? > Might be worth it... I did a short check with camus:~/work/wine$ grep -r -I -C snprintf ./ | less and this is what I found: - most of the time the return value of *snprintf isn't checked - if the return value is checked it's mostly checked for C89 and C99 style - the attached patch should fix all the remaining cases. Changelog: Michael Stefaniuc <mstefani(a)redhat.com> check the return value of *snprintf for C99 style bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Dec. 26, 2001

We *really* need a development model change !

by Andreas Mohr

Hi all, due to the number of regressions I found few days ago, it occurred to me that we really need an API test suite now. Thus I went ahead and implemented a test functionality for LoadModule16(). The result: 7 of the 21 tests that I implemented were FAILING !! That's ONE THIRD. And that for such a highly basic function as LoadModule16(). That's quite incredible. I guess we really should change our development model from trying tons of programs to *systematically* testing functions and Windows mechanisms now. If we can show everyone where stuff is failing, it might be a lot easier to attract new people. I attached a preview of the posting I intend to post on *tons* of Windows devel newsgroups ("Call For Volunteers"). That way we might actually get hold of hundreds of Windows developers helping us implement a complete test suite (complete tests of up to 12000 Windows functions). Not to mention the additional PR we might get out of this... If this works, then we'd need someone in charge of managing the assignment of specific windows functions to specific programmers. I won't do that (very limited time). Anyone from Codeweavers up to the task ? Or maybe someone non-developer and rather foreign to the Wine devel could do that task ? About the program: My goal was to get a program with very easy parsing interface: fields separated by colons, nothing fancy and difficult to implement, ... A .exe can be found at: http://home.nexgo.de/andi.mohr/download/wt_ldr16.exe Please comment on both my intended posting and the way I programmed the first version of the test suite (I'm not extremely happy with the current program; if you have any improvements, then get them here ASAP !). As 12000 Windows functions is an enormous number, I think we should really start doing this NOW instead of years later once Wine really needs this. Wine does not extremely need this yet, but we're getting pretty damn close to that already. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

Dec. 25, 2001

Re: Bulletproof the debugger.

by Francois Gouget

On Fri, 21 Dec 2001, Michael Stefaniuc wrote: > On Fri, Dec 21, 2001 at 01:52:12PM -0800, Medland, Bill wrote: > > Bill Medland (medbi01(a)accpac.com) > > Don't ask me why but on my setup vsnprintf returned a value greater than > This is the new and correct behavior according to the C99 standard. All > snprintf function should return in error case the number of characters > that would have been written to the buffer if the size of buffer would > have been big enough. > This change while usefull will brake a lot of things. IMO the glibc is > still using the old behavior. By the way did someone do a systematic check for this problem? Might be worth it... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ "Utilisateur" (nom commun) : Mot utilisé par les informaticiens en lieu et place d'"idiot".

Dec. 25, 2001

Re: DOS packing patch (fix)

by Lionel Ulmer

Hi all, I am a bit worried by this patch : I looked at how "pshpack1.h" works, and it uses the '#pragma pack(1)' method when compiling with GCC. > +/* WARNING: one byte packed structs from here !! (i.e. not DWORD aligned) */ > +#include "pshpack1.h" > + And I wonder if this really works as with the latest versions of GCC (2.95.3 onwards AFAIK), '#pragma pack(1)' is ignored (at least on my self-compiled GCC :-) ) and you need to use the '__attribute((__packed__))' construction after each structure. But well, I may say completely stupid things as otherwise a lot of bugs would exist in Wine... Lionel PS: Merry Christmas all :-) -- Lionel Ulmer - http://www.bbrox.org/

Dec. 25, 2001

Re: [Shrinker] Another landmine

by Robert Baruch

On Mon, 24 Dec 2001 16:51:30 -0500 "Dimitrie O. Paun" <dimi(a)cs.toronto.edu> wrote: > Yes, but can't we write a trivial wrapper in assembly that simply calls an > internal function (written in C) which does the actual work? (laughing) You spoke too soon, see my just-posted message. --Rob

Dec. 24, 2001

Re: [Shrinker] Another landmine

by Robert Baruch

On 24 Dec 2001 12:33:50 -0800 Alexandre Julliard <julliard(a)winehq.com> wrote: > > Instead, it finds an unimplemented procedure in Wine. So now I will look > > at LdrAccessResource (and friends) to see what's involved in implementing > > it, whatever it is. > > Sounds much more problematic. LdrAccessResource itself is not too > hard, but I doubt you'll get gcc to generate exactly the above code; > and writing LdrAccessResource in assembly is not really an option. Well, Shrinker is getting kind of ridiculous with its required checks for the genuine Microsoft NTDLL.DLL. Also I can't find LdrAccessResource documented anywhere. Smacks of anticompetitiveness and monopolistic intentions to me :) Is there a book on undocumented NT/2000? I looked at the assembly of LdrAccessResource. All it is is push four args onto the stack, call an internal function, and return. That internal function is more complicated, but it looks like it is getting a pointer to the RESOURCE entry of an image -- there are calls to RtlImageNtHeader and RtlImageDirectoryEntryToData. So anyway, if we implemented this internal function (in C), then in theory it wouldn't be much of a big deal to code LdrAccessResource in assembly. Although it will raise a few eyebrows, we can always put in a comment similar to the one that will go in the assembler-coded EXC_CallHandler, that this code is required by Shrinker. For those who are interested, here's the pseudo-code I've come up with for LdrAccessResource. The only missing piece is "call77F89D5F", and the exception clause -- I haven't traced those yet. BOOL LdrAccessResource(arg1, arg2, hModule, arg4, arg5, arg6) { return _LdrAccessResource(hModule, arg4, arg5, arg6) } BOOL _LdrAccessResource(hModule, arg2, arg3, arg4) { try { DWORD size; PIMAGE_RESOURCE_DIRECTORY *entry; PIMAGE_NT_HEADERS *ntheader; MEMORY_BASIC_INFORMATION meminfo; DWORD regionSize; void *ptr = 0; void *addr = 0; entry = RtlImageDirectoryEntryToData( hModule, 1, IMAGE_DIRECTORY_ENTRY_RESOURCE, &size); if (!entry) throw STATUS_RESOURCE_DATA_NOT_FOUND; if (arg2 < entry) hModule = LdrLoadAlternateResourceModule( hModule, 0); else { ntheader = RtlImageNtHeader(hModule&0xFFFFFFFE); if (ntheader) { if (!hModule & 0x01) regionSize = ntheader->OptionalHeader.SizeOfImage; else { ptr = ZwQueryVirtualMemory( -1, hModule&0xFFFFFFFE, 0, &meminfo, sizeof(meminfo), 0); regionSize = ptr<0 ? 0 : meminfo.RegionSize; } if (arg2 < regionSize || arg2 >= regionSize + hModule&0xFFFFFFFE) hModule = LdrLoadAlternateResourceModule( hModule, 0); } } if (!hModule) throw STATUS_RESOURCE_DATA_NOT_FOUND; entry = RtlImageDirectoryEntryToData( hModule, 1, IMAGE_DIRECTORY_ENTRY_RESOURCE, &size); if (!entry) throw STATUS_RESOURCE_DATA_NOT_FOUND; if (hModule & 0x01) { hModule &= 0xFFFFFFFE; ntheader = RtlImageNtHeader(hModule); if (ntheader->OptionalHeader.Magic == 0x10B) addr = ntheader->OptionalHeader.DataDirectory[2].VirtualAddress; else if (ntheader->OptionalHeader.Magic == 0x20B) addr = ntheader->OptionalHeader.DataDirectory[4].VirtualAddress; else addr = 0; if (!addr) throw STATUS_RESOURCE_DATA_NOT_FOUND; ptr = hModule + (addr - entry); if (!(section = RtlImageRvaToSection(ntheader, hModule, addr))) throw STATUS_RESOURCE_DATA_NOT_FOUND; if (*arg2 > *(section+2)) { section2 = RtlImageRvaToSection(ntheader, hModule, *arg2); rtn = call77F89D5F(ntheader, hModule, *(section2+3)); ptr += *(section2+3) - *(section+3) - rtn; } } if (arg3) *arg3 = hModule + (*arg2 - ptr); if (arg4) *arg4 = *(arg2+1); return 0; } catch { // exception clause here } } --Rob

Dec. 24, 2001

Re: [Shrinker] Another landmine

by Dimitrie O. Paun

On Mon, 24 Dec 2001, Alexandre Julliard wrote: > hard, but I doubt you'll get gcc to generate exactly the above code; > and writing LdrAccessResource in assembly is not really an option. Yes, but can't we write a trivial wrapper in assembly that simply calls an internal function (written in C) which does the actual work? -- Dimi.

Dec. 24, 2001

Re: 16 bit comm issue

by Alexandre Julliard

Mike McCormack <mike_mccormack(a)start.com.au> writes: > I have a patch for this problem which puts an alertable wait in > GetMessage(16), which i posted in October. > > What is the problem with this method, and is there a better solution > to the problem? Sorry, must have missed this patch. The method seems reasonable; you probably want to do the same thing at least in PeekMessage16, and maybe add some global flag to only do it when comm functions are actually in use, so that other apps don't have to do an extra server call on each message. -- Alexandre Julliard julliard(a)winehq.com

Dec. 24, 2001

Re: DOS stuff pretty much broken [Re: wine/ dlls/kernel/kernel_main.c dlls/kernel/wp ...]

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > This is rather fatal IMHO, especially in the case of List Of Lists, which > is a pretty important structure with lots of information that some Win 3.x > programs might rely on. > Thus DOS stuff should be reorganized somehow. > > Any suggestions ? > > IMHO probably winedos should get loaded as soon as DOS3Call() gets called even > once. That's probably a bit too much, but yes DOS calls that somehow need data structures created in winedos should load it. And in fact more of the DOS structures stuff should be moved there, so that well-behaved applications don't incur the cost of setting it up. -- Alexandre Julliard julliard(a)winehq.com

Dec. 24, 2001

Re: [Shrinker] Another landmine

by Alexandre Julliard

Robert Baruch <autophile(a)starband.net> writes: > More stepping through the code, comparing Windbg to gdb, and I found > another landmine. Shrinker gets the address of the NTDLL procedure > LdrAccessResource, and looks for this code: > > FF74XXXX push [esp+X] > E8XXXXXXXX call .... > > Instead, it finds an unimplemented procedure in Wine. So now I will look > at LdrAccessResource (and friends) to see what's involved in implementing > it, whatever it is. Sounds much more problematic. LdrAccessResource itself is not too hard, but I doubt you'll get gcc to generate exactly the above code; and writing LdrAccessResource in assembly is not really an option. -- Alexandre Julliard julliard(a)winehq.com

Dec. 24, 2001

Re: fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > This has been discussed before, most recently on wine-users, I > think... Are you running in managed mode? Then try this patch: > http://www.winehq.com/hypermail/wine-patches/2001/11/0126.html > > (Hey, Alexandre, is there a reason you haven't applied that yet, anyway?) Was I supposed to? it doesn't really looks to be ready to commit; at least the #ifdefs should be replaced by a run-time option. And I'm not convinced making menus and similar windows managed is really a good idea, so it probably needs more intelligence in this area. -- Alexandre Julliard julliard(a)winehq.com

Dec. 24, 2001

Terrible bug: WinExec16, DOS programs

by Andreas Mohr

Hi all, I just found out that WinExec16 doesn't even support starting DOS programs. Whereas LoadModule16 doesn't seem to support loading DOS programs (error 22, which is not documented for LoadModule16), WinExec16 definitely does launch command.com on Win98SE. Not so when using Wine. What to do about that ? More specifically, which functions to change how exactly to support this ? (the whole interoperation between WinExec, WinExec16, LoadModule*, LoadLibrary*,CreateProcess etc. is highly problematic). This thing makes me get slightly worried about our Win16/DOS compatibility as a whole... :-\ -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 24, 2001