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

Some questions about TB_REPLACEBITMAP

by Marco Bizzarri

Hi all. I'm trying to implement the TB_REPLACEBITMAP message in the comctrl32, and I would like to have some advice about the ImageList structure. The TB_REPLACEBITMAP provides (via the hInst, nID pair) the handle to the old bitmap and the handle to the new bitmap, as well as the number of button in the new bitmap. I think I could use the ImageList_Replace to actually replace the bitmaps. However, the ImageList_Replace function requires a number, which is the first bitmap to be replaced. How can I retrieve this information? For what I can see, once a bitmap has been added to the imagelist, no information about is is stored. I'm doing some tests, using a value (like 0) as the bitmap index, but this is of little help, of course. Any help will be appreciated. Bye Marco

Aug. 3, 2001

Re: Switching threads in winedbg

by eric pouech

Francois Gouget wrote: > > Is it possible to switch threads in winedbg? > I can use 'walk thread' to see a list of the threads of my > application but I could not find how to get a backtrace of one of these > other threads. It's not in the Wine Developper's Guide and I could not > find it from the source. this is not currently supported. but it seems feasible to extend the bt function with something like bt threadID. I'll have a look at it. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 3, 2001

Re: Dose wine people hate Solaris?

by eric pouech

> gcc -c -I. -I. -I../include -I../include -g -O2 -Wall -mpreferred-stack-bou > ndary=2 -fPIC -DSTRICT -D_REENTRANT -I/usr/openwin/include -o stabs.o > stabs.c > stabs.c:1271: warning: `struct r_debug' declared inside parameter list > stabs.c:1271: warning: its scope is only this definition or declaration, > which is probably not what you want. > stabs.c: In function `DEBUG_WalkList': > stabs.c:1274: storage size of `lm' isn't known > stabs.c:1284: dereferencing pointer to incomplete type > stabs.c:1274: warning: unused variable `lm' > stabs.c:1273: warning: `lm_addr' might be used uninitialized in this > function > stabs.c: In function `DEBUG_RescanElf': > stabs.c:1302: storage size of `dbg_hdr' isn't known > stabs.c:1309: `RT_CONSISTENT' undeclared (first use in this function) > stabs.c:1309: (Each undeclared identifier is reported only once > stabs.c:1309: for each function it appears in.) > stabs.c:1313: `RT_ADD' undeclared (first use in this function) > stabs.c:1315: `RT_DELETE' undeclared (first use in this function) > stabs.c:1310: warning: unreachable code at beginning of switch statement > stabs.c:1302: warning: unused variable `dbg_hdr' > stabs.c: In function `DEBUG_ReadExecutableDbgInfo': > stabs.c:1324: `Elf32_Dyn' undeclared (first use in this function) > stabs.c:1324: parse error before `dyn' > stabs.c:1325: storage size of `dbg_hdr' isn't known > stabs.c:1336: `dyn' undeclared (first use in this function) > stabs.c:1339: `DT_DEBUG' undeclared (first use in this function) > stabs.c:1339: `DT_NULL' undeclared (first use in this function) > stabs.c:1325: warning: unused variable `dbg_hdr' > make[1]: *** [stabs.o] Error 1 > make[1]: Leaving directory `/export/home/system/wine-20010629/debugger' > make: *** [debugger/winedbg] Error 2 > > Compilation failed, aborting install. > > Any idea? this is due to the differences in ELF symbol loading between Linux/BSD and Solaris. This has to be fixed, some day. One simple fix would be to turn off manually the ELF definition at the top of the debugger/stabs.c file. If you're still around in the next day, I may send you some fixes to test if they work on Solaris (this is the part to be removed) #if defined(__svr4__) || defined(__sun) #define __ELF__ #endif A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 3, 2001

Re: CS_PARENTDC with WS_CLIPSIBLINGS

by Ladislav Sladecek

Alexandre Julliard wrote: > > Yes, there were a number of problems with the flags handling in > GetDCEx. I think the behavior with the current CVS should now be > correct in all cases; please give it a try. Thank you for the fix. The example works fine but the original app ( 16 bit _prowin.exe from Progress RDBMS] ceased to work at all. After the menu is drawn, the application stops responding and complains about some illegal string operations and then about unknown driver ,, in GetDCA. err:string:lstrcpyA (0x40a2e75e, (nil)): page fault occurred ! Caused by bug ? err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, err:dc:CreateDCA no driver found for ,, device:,, I tried also --debugmsg +all; several houndreds lines of the trace are attached. I do not know if the problem is somewhat connected with your fix or is created by some other patch. Ladislav Sladecek

Aug. 2, 2001

Re: Documenting functions

by Alexandre Julliard

"Bill Medland" <medbi01(a)accpac.com> writes: > Ay, there's the rub. It isn't our function. It';s Microsoft's function. > Now was it Holub or McConnell that complains about functions having weird > behaviour on certain inputs. IMO Microsoft functions need less documentation than internal ones, since there is MSDN and other countless books about Windows. You can assume that people reading your code already know what the various APIs are supposed to do. > The biggest problem, I believe, is the functions that take flags. Bear in > mind that a single DWORD argument used for flags is equivalent to up to 32 > boolean arguments. Documenting the relationship between those is a pain > but it needs to be done if we expect compatibility. This is clearly something that is best documented with code, not with text. You may need pages of text to describe the flags behavior in English, while with code it's usually only a few lines, plus a few comments here and there. This doesn't mean it wouldn't be a good thing to also have the full description in English; but in a separate document, not in the code. -- Alexandre Julliard julliard(a)winehq.com

Aug. 2, 2001

Re: Prevent excessive clipping in SysListView32

by Bill Medland

Bill Medland <medbi01(a)accpac.com> wrote in article <01c1194f$025f5f00$6f0c10ac(a)medbi01>... > Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> wrote in article > <200107301823.UAA01150(a)faui11.informatik.uni-erlangen.de>... > > > > Bill Medland wrote: > > > > > Ulrich Weigand <weigand(a)immd1.informatik.uni-erlangen.de> wrote in > article > > > <200107262124.XAA25786(a)faui11.informatik.uni-erlangen.de>... > > > > No, 'inline' must not change the semantics of the routine in any way, > > > > including static variables. > > > > > > > > If the app behaves differently when 'perfect_graphics' is inlined, > this > > > > is a compiler bug. Which compiler version are you using? > > > > > > Excuse my ignorance. rpm says it is 2.96-81. How do I ask gcc what > > > version IT thinks it is? > > > (Running on RH7.1; how do I get the kernel version? rpm says 2.4.2-2) > > > > gcc 2.96 is the version RedHat is currently using; it is not an > > 'official' version supported by the gcc folks ... > > > > However, RedHat has been fixing quite a bunch of bugs in their > > compiler; it might be worthwhile to check whether this inlining > > bug is fixed in the most recent RedHat update. (Check the RPM > > sublevel to find out whether you have the most recent update, > > that's the -81 in your case. AFAIK, bugfix updates can be > > downloaded from the RedHat FTP site ...) > > > > Bye, > > Ulrich > > Thanks; I'll try that when I have a moment. Well, I found a moment. The problem is still there with 2.96-85 which is what is currently available from RedHat. Maybe sometime I'll take a look at the difference in the generated assembler code, unless someone else is interested. Bill

Aug. 2, 2001

Re: Documenting functions

by Alexandre Julliard

Jeremy White <jwhite(a)codeweavers.com> writes: > I would say that I would rather have 100% of the effort a > particular developer *wants* to put in, rather than only > have his/her coding efforts. Absolutely; I'm not going to discourage anybody from writing doc if they feel like it. But I don't want anyone to feel somehow obliged to spend time on the doc if they'd rather be writing code, which I expect is the case with most developers... > However, I think that there should be a standard function > header, with a standard place to put notes and comments > in general about a function. I don't see a need to standardize anything. If you want to add a comment before a function just do it, there is no need for a standard format, plain text works just as well. > I have been trained, and I suspect that many of us have > been trained, to look at a function header for general > tips and tricks before diving into the code. I know > this is sacriledge to you, Alexandre, but there are some > of us who like to quickly look at a function, rather than > always reading the code to understand it completely. I think you misunderstand my position; I'm not opposed to having a comment at the start of the function explaining the general goal and the non-obvious things going on. But if you need more than a couple of paragraphs to do this, then either there are too many non-obvious things going on in your function, or you are wasting space explaining the obvious. I do strongly think that the goal should be to write code that doesn't require documentation in order to be understood. Of course adding a small amount of comments is a good idea; but when you start having more lines of documentation than lines of code, something is very wrong IMO. But this is mainly a matter of personal taste, and except in extreme cases I'm not going to reject code because it has too much (or not enough) documentation. It may happen that some of your beloved horizontal lines get lost during the cvs commit though ;-) -- Alexandre Julliard julliard(a)winehq.com

Aug. 2, 2001

Re: Documenting functions

by Bill Medland

Alexandre Julliard <julliard(a)winehq.com> wrote in article <87zo9iwdnt.fsf(a)mail.wine.dyndns.org>... > Jeremy White <jwhite(a)codeweavers.com> writes: > > > I would say that I would rather have 100% of the effort a > > particular developer *wants* to put in, rather than only > > have his/her coding efforts. > > Absolutely; I'm not going to discourage anybody from writing doc if > they feel like it. But I don't want anyone to feel somehow obliged to > spend time on the doc if they'd rather be writing code, which I expect > is the case with most developers... > > > However, I think that there should be a standard function > > header, with a standard place to put notes and comments > > in general about a function. > > I don't see a need to standardize anything. If you want to add a > comment before a function just do it, there is no need for a standard > format, plain text works just as well. > > > I have been trained, and I suspect that many of us have > > been trained, to look at a function header for general > > tips and tricks before diving into the code. I know > > this is sacriledge to you, Alexandre, but there are some > > of us who like to quickly look at a function, rather than > > always reading the code to understand it completely. > > I think you misunderstand my position; I'm not opposed to having a > comment at the start of the function explaining the general goal and > the non-obvious things going on. But if you need more than a couple of > paragraphs to do this, then either there are too many non-obvious > things going on in your function, or you are wasting space explaining > the obvious. Ay, there's the rub. It isn't our function. It';s Microsoft's function. Now was it Holub or McConnell that complains about functions having weird behaviour on certain inputs. The biggest problem, I believe, is the functions that take flags. Bear in mind that a single DWORD argument used for flags is equivalent to up to 32 boolean arguments. Documenting the relationship between those is a pain but it needs to be done if we expect compatibility. The next worst is handles or pointers to complex structures. What aspects of the object are relevant? And on the subject of non-obvious..The usual claim is 1. A comment should not state the obvious 2. If the converse of a statement in a comment is obvious then don't bother with it. In my experience these are both true but with provisos. 1 What is obvious to you today is probably not going to be obvious to you in 6 months 2. What is obvious to you is possibly not obvious to everyone else 3. The converse of a statement may be obvious to you. It may also be obvious to someone else. The question is "is it the same for both people" > > I do strongly think that the goal should be to write code that doesn't > require documentation in order to be understood. Of course adding a > small amount of comments is a good idea; but when you start having > more lines of documentation than lines of code, something is very > wrong IMO. And this is where I started getting overjoyed by the capabilities of SGML and the like. I agree wholeheartedly that too much documentation is a bad thing. Which is why I think there is a need for documentation outside the code, epecially in a networked shape (e.g. html/sgml) that can be referenced. > > But this is mainly a matter of personal taste, and except in extreme > cases I'm not going to reject code because it has too much (or not > enough) documentation. It may happen that some of your beloved > horizontal lines get lost during the cvs commit though ;-) > Bill

Aug. 2, 2001

Re: Dont allow SetSelectorBase to change into an kernel region

by Alexandre Julliard

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > If I only allow to set the selector base when (selector base + selector > limit) is smaller than 0x8000000, the application goes on and lets me read > an eprom plugged into the Galep3 Programmer. Is the appended fix a right > acceptable? No, it's legal to have selectors covering the entire address space. I'm afraid there is no good solution to this kind of problem. What does the app do under NT or with -winver nt40? -- Alexandre Julliard julliard(a)winehq.com

Aug. 2, 2001

Re: Documenting functions

by Jeremy White

[Resend due to exim crash; thanks Ove] >> I'd much rather have developers spend their time writing code. Making >> them duplicate the whole MSDN documentation would be a huge waste of >> their time. Our resources are not infinite, and it's much more useful >> to have 100% API coverage with no docs at all than 50% coverage and >> tons of docs. I think this is a dangerous attitude to take. I think that you cannot (and should not) attempt to force volunteer developers to add documentation to code. However, there are some few of us, who don't feel that the job is satisfactorily done until the documentation reflects important things that we've learned. I would say that I would rather have 100% of the effort a particular developer *wants* to put in, rather than only have his/her coding efforts. If I, like Bill, spend 24 hours ripping my hair out to learn some oddball things, I want a place to put those things. I want someone else (or an older version of me) to have a chance to not have to learn those things the hard way. Please don't misunderstand me. I agree that we shouldn't try to replicate MSDN. I'm not even sure we should provide minimal documentation like parameter lists and return values. Further, I agree that where it makes sense, the best place for comments is inline with the relevant code. However, I think that there should be a standard function header, with a standard place to put notes and comments in general about a function. I have been trained, and I suspect that many of us have been trained, to look at a function header for general tips and tricks before diving into the code. I know this is sacriledge to you, Alexandre, but there are some of us who like to quickly look at a function, rather than always reading the code to understand it completely. <in joke> Finally, I think all the code would be dramatically improved, in fact, I bet we'd be at Wine 1.0 by now, if there were nice big horizontal separator lines everywhere. </in joke>

Aug. 2, 2001

Re: Documenting functions

by Bill Medland

Alexandre Julliard <julliard(a)winehq.com> wrote in article <878zh3y8e0.fsf(a)mail.wine.dyndns.org>... > Francois Gouget <fgouget(a)free.fr> writes: > > > So I think the functions implemented in Wine should be fully > > documented. And the only place to do that is in the code source because > > this is the only place where they have a remote chance of staying up to > > date (and also where it's most practical to have it). > > I have to disagree here. Yes it would be nice to have a free Win API > documentation, but it definitely doesn't belong inside the Wine > source. First it would be a huge bloat in the source; and more > importantly the Wine source doesn't define the Windows API, it is > defined by Microsoft. I agree that bloat is a serious danger. To me the issue is that the full documentation is just too big and actually belongs in a decent documentation management environment. To be honest since Wine is a re-engineering of an existing product I actually expect that the full documentation is many times larger than the source, once we start considering the scraps of paper on which we jot down the results of random experiments and the programs written for them. All Microsoft need are the change requests, specs and design docs. We need more. > > > Of course developpers are very well-known for hating to document > > stuff so it's going to be pretty hard to get proper documentation. But > > we should encourage all Wine developpers to write good documentation for > > the functions they implement/fix, not dissuade them to do so. > > I'd much rather have developers spend their time writing code. Making > them duplicate the whole MSDN documentation would be a huge waste of > their time. Our resources are not infinite, and it's much more useful > to have 100% API coverage with no docs at all than 50% coverage and > tons of docs. Yes I am happy with that view. However when I spend four days writing test code and experimenting to find out how 24 different flags interact and proving that the weird code IS wrong. I would like to know where I should put that information. > > > Also I agree with you that the strict minimum is to at least document > > all the undocumented/weird behaviors. Especially since without some sort > > of documentation the next developper may be tempted to remove what looks > > like unnecessarily convoluted/obviously wrong code. > > That should be done with comments inside the code itself. And in many > cases it would actually be better to comment the places where the > behavior is not right. What I mean is, instead of adding a comment on > every line stating "yes this is what Windows does", I'd prefer adding > a comment/FIXME to mark the lines that have been written without > checking whether Windows really does it this way. > Bill

Aug. 2, 2001

Switching threads in winedbg

by Francois Gouget

Is it possible to switch threads in winedbg? I can use 'walk thread' to see a list of the threads of my application but I could not find how to get a backtrace of one of these other threads. It's not in the Wine Developper's Guide and I could not find it from the source. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

Aug. 1, 2001

Re: Documenting functions

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So I think the functions implemented in Wine should be fully > documented. And the only place to do that is in the code source because > this is the only place where they have a remote chance of staying up to > date (and also where it's most practical to have it). I have to disagree here. Yes it would be nice to have a free Win API documentation, but it definitely doesn't belong inside the Wine source. First it would be a huge bloat in the source; and more importantly the Wine source doesn't define the Windows API, it is defined by Microsoft. > Of course developpers are very well-known for hating to document > stuff so it's going to be pretty hard to get proper documentation. But > we should encourage all Wine developpers to write good documentation for > the functions they implement/fix, not dissuade them to do so. I'd much rather have developers spend their time writing code. Making them duplicate the whole MSDN documentation would be a huge waste of their time. Our resources are not infinite, and it's much more useful to have 100% API coverage with no docs at all than 50% coverage and tons of docs. > Also I agree with you that the strict minimum is to at least document > all the undocumented/weird behaviors. Especially since without some sort > of documentation the next developper may be tempted to remove what looks > like unnecessarily convoluted/obviously wrong code. That should be done with comments inside the code itself. And in many cases it would actually be better to comment the places where the behavior is not right. What I mean is, instead of adding a comment on every line stating "yes this is what Windows does", I'd prefer adding a comment/FIXME to mark the lines that have been written without checking whether Windows really does it this way. -- Alexandre Julliard julliard(a)winehq.com

Aug. 1, 2001

Re: Dont allow SetSelectorBase to change into an kernel region

by Uwe Bonnes

>>>>> "Uwe" == Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: Uwe> Hallo, galep3 crashes with following sequence: 096c7b38:Call Uwe> KERNEL.189: SETSELECTORLIMIT(0x0d87,0x0000045f) ret=02e7:6fb5 Uwe> ds=099f 096c7b38:Ret KERNEL.189: SETSELECTORLIMIT() retval=0x0d87 Uwe> ret=02e7:6fb5 ds=099f 096c7b38:Call KERNEL.187: Uwe> SETSELECTORBASE(0x0d87,0xc02924e0) ret=02e7:6fc1 ds=099f Uwe> 096c7b38:Ret KERNEL.187: SETSELECTORBASE() retval=0x0d87 Uwe> ret=02e7:6fc1 ds=099f ... Unhandled exception: page fault on read Uwe> access to 0xc0292545 Uwe> Obviously the application trys to reach some kernel memory. Uwe> If I only allow to set the selector base when (selector base + Uwe> selector limit) is smaller than 0x8000000, the application goes on Uwe> and lets me read an eprom plugged into the Galep3 Programmer. Is Uwe> the appended fix a right acceptable? Obviously not modifying the base in that case lets me save and exit too Index: wine/memory/selector.c =================================================================== RCS file: /home/wine/wine/memory/selector.c,v retrieving revision 1.39 diff -u -r1.39 selector.c --- wine/memory/selector.c 19 Jul 2001 00:39:10 -0000 1.39 +++ wine/memory/selector.c 1 Aug 2001 17:42:53 -0000 @@ -326,8 +326,15 @@ { LDT_ENTRY entry; wine_ldt_get_entry( sel, &entry ); - wine_ldt_set_base( &entry, DOSMEM_MapDosToLinear(base) ); - wine_ldt_set_entry( sel, &entry ); + if ((base + wine_ldt_copy.limit[sel >> __AHSHIFT]) > 0x8000000) + { + FIXME("Illegal region base %lx limit %lx\n", base,wine_ldt_copy.limit[sel >> __AHSHIFT]); + } + else + { + wine_ldt_set_base( &entry, DOSMEM_MapDosToLinear(base) ); + wine_ldt_set_entry( sel, &entry ); + } return sel; } -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 1, 2001

Dont allow SetSelectorBase to change into an kernel region

by Uwe Bonnes

Hallo, galep3 crashes with following sequence: 096c7b38:Call KERNEL.189: SETSELECTORLIMIT(0x0d87,0x0000045f) ret=02e7:6fb5 ds=099f 096c7b38:Ret KERNEL.189: SETSELECTORLIMIT() retval=0x0d87 ret=02e7:6fb5 ds=099f 096c7b38:Call KERNEL.187: SETSELECTORBASE(0x0d87,0xc02924e0) ret=02e7:6fc1 ds=099f 096c7b38:Ret KERNEL.187: SETSELECTORBASE() retval=0x0d87 ret=02e7:6fc1 ds=099f ... Unhandled exception: page fault on read access to 0xc0292545 Obviously the application trys to reach some kernel memory. If I only allow to set the selector base when (selector base + selector limit) is smaller than 0x8000000, the application goes on and lets me read an eprom plugged into the Galep3 Programmer. Is the appended fix a right acceptable? Index: wine/memory/selector.c =================================================================== RCS file: /home/wine/wine/memory/selector.c,v retrieving revision 1.39 diff -u -r1.39 selector.c --- wine/memory/selector.c 19 Jul 2001 00:39:10 -0000 1.39 +++ wine/memory/selector.c 1 Aug 2001 17:30:48 -0000 @@ -327,7 +327,12 @@ LDT_ENTRY entry; wine_ldt_get_entry( sel, &entry ); wine_ldt_set_base( &entry, DOSMEM_MapDosToLinear(base) ); - wine_ldt_set_entry( sel, &entry ); + if ((base + wine_ldt_copy.limit[sel >> __AHSHIFT]) > 0x8000000) + { + FIXME("Illegal region base %lx limit %lx\n", base,wine_ldt_copy.limit[sel >> __AHSHIFT]); + } + else + wine_ldt_set_entry( sel, &entry ); return sel; } Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 1, 2001

Strange window handle in the trace

by Marco Bizzarri <m.bizzarri＠icube.it>

Hi all. I'm working on a no-windows installation. The system is a RH 6.2 system, upgraded to the latest patches. I've installed XFree4 and KDE 2.1 I'm experiencing an unhandled exception when I try to a VC application. The application works (almost) fine until it opens a selection dialog, with a list on it. As you can see from the trace, it is trying to do an RDW_UpdateRgns with a wndPtr of 0xffff Unhandled exception: page fault on read access to 0x08fd506b in 32-bit code (0x406d1771). In 32-bit mode. Symbol h_errno is invalid Symbol hack_digit is invalid 0x406d1771 (RDW_UpdateRgns+0x3c9 [painting.c:720] in libuser32.so): testb $ 0x10,0x6b(%esi) 720 if( wnd->dwStyle & WS_VISIBLE ) Wine-dbg>bt Backtrace: =>0 0x406d1771 (RDW_UpdateRgns+0x3c9(wndPtr=0xffff, hRgn=0x0, flags=0x180, firstRecursLevel=0x0) [painting.c:720] in libuser32.so) (ebp=405b1bc4) 1 0x406d1787 (RDW_UpdateRgns+0x3df(wndPtr=0x40377824, hRgn=0x0, flags=0x180, firstRecursLevel=0x0) [painting.c:721] in libuser32.so) (ebp=405b1c20) 2 0x406d1787 (RDW_UpdateRgns+0x3df(wndPtr=0x40377538, hRgn=0x0, flags=0x180, firstRecursLevel=0x1) [painting.c:721] in libuser32.so) (ebp=405b1c7c) 3 0x406d1e08 (RedrawWindow+0x38c(hwnd=0x43f0, rectUpdate=0x0, hrgnUpdate=0x0, flags=0x180) [painting.c:982] in libuser32.so) (ebp=405b1cd4) 4 0x406d1f1d (UpdateWindow+0x21(hwnd=0x43f0) [painting.c:1015] in libuser32.so) (ebp=405b1cf0) 5 0x0043df7a (<Debugged process>.EntryPoint+0x13625 in <Debugged process>) (ebp=0046e660) 6 0x00000623 (ebp=000044e4) Just for "fun", I've tryied to add checks for 0xffff, but it crashes when it enters non Wine DLL (actually they are Spread dlls from Farpoint) Any clue? Thanks you all in advance Bye Marco -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

Aug. 1, 2001

CloseHandle with 0xffffffff parameter

by Marco Bizzarri

Hi All. While trying to make an application working under wine, I've stumped into the following trace fragment, obtained with --debugmsg +relay: 081612c8:Call kernel32.CreateFileA(405f6454 "c:\\rs\\project\\apitest\\vc\\32\\apitestvc60\\debug\\ret_dll.pdb",80000000,00000001,00000000,00000003,00000080,00000000) ret=404aa001 081612c8:Ret kernel32.CreateFileA() retval=ffffffff ret=404aa001 081612c8:Call kernel32.CloseHandle(ffffffff) ret=404aa0bd 081612c8:Ret kernel32.CloseHandle() retval=00000000 ret=404aa0bd As you can see, the program is trying to open a file, which is not found. An invalid handle (ffffffff) is returned. The program however closes the handle. My question is: is this correct? Should the CloseHandle check to see if it is a correct handle? Thank you all in advance Marco Bizzarri -- Marco Bizzarri - Responsabile Tecnico - Icube S.r.l. Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia E-mail: m.bizzarri(a)icube.it WWW: www.icube.it Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588

Aug. 1, 2001

Re: Documenting functions

by Uwe Bonnes

>>>>> "Francois" == Francois Gouget <fgouget(a)free.fr> writes: Francois> Well, let me offer a different opinion. Francois> Wine is an open-source reimplementation of the Win32 Francois> API. You can use it to run existing Windows applications and Francois> to recompile or develop Win32 applications using Winelib. Francois> Now, for me an open-source project that implements an API for Francois> which there is no open-source documentation is not Francois> complete. Especially for Winelib where the API is part of what Francois> we provide to the user, i.e. to programmers using Winelib. Francois> And currently the only documentation of the Win32 API is Francois> available from Microsoft as part of the MSDN. I see many Hallo, while this doesn't answer many question, I think it is worth knowing: Javob Navia has achieved the explicit right to distribute the win32 help files with his lcc-win32. You can download lcc-win32 and win32help for free at http://www.cs.virginia.edu/~lcc-win32/ Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 1, 2001

Re: Documenting functions

by Francois Gouget

On Tue, 31 Jul 2001, Andreas Mohr wrote: > On Tue, Jul 31, 2001 at 04:33:06PM +0000, Bill Medland wrote: > > Getting back to what we are and are not allowed to do.. > > > > Suppose I am looking at a low-level function that I believe is only > > 75%-complete (the most important 75% of course and no disrespect meant to > > those who have got it that far). > > > > One of the problems with it is it is not totally clear EXACTLY what the > > function should do in some of its more esoteric modes. > > > > To me the first task is to define what it should do and that should be part > > of the documentation of the function. > IMNSHO full documentation should *not* be included in the Wine tree. > Instead, we should rely on MSDN documented stuff wherever possible > and only explain quirks/undocumented behaviour/whatever isn't documented. > > Having full docu inside the source tree simply bloats it too much IMHO. Well, let me offer a different opinion. Wine is an open-source reimplementation of the Win32 API. You can use it to run existing Windows applications and to recompile or develop Win32 applications using Winelib. Now, for me an open-source project that implements an API for which there is no open-source documentation is not complete. Especially for Winelib where the API is part of what we provide to the user, i.e. to programmers using Winelib. And currently the only documentation of the Win32 API is available from Microsoft as part of the MSDN. I see many problems with that: * it's not open-source (of course). This means we cannot distribute it with Winelib, we cannot generate man pages from it, you cannot generate a winelib-doc package that would contain the man pages of all the Winelib API. * MSDN documentation comes... and goes. Find me the documentation of 16bit functions. The current MSDN versions have eradicated the documentation of all 16 bit APIs. There are tons of aspects of the Win16 environment for which we no longer have any documentation. Then when someone comes to modify some piece of code which is shared between Win16 and Win32 you have no idea if the fix you made for Win32 is not going to break Win16. If Wine had had good independent documentation of the API from the start developpers could refer to this documentation to know whether a change is going to break Win16 or not. * MSDN documentation is often incomplete / slightly incorrect (though people working on Wine should maybe look at it a bit more). So what you propose is that this be *the* documentation for the Win32 API. I think Wine developpers and Winelib users deserve better. And no one using Winelib as a development platform would want to have to go to two places to find documentation. * The MSDN documentation is currently freely available on the Web. Tomorrow it could very well not be the case anymore. Or Microsoft could come up with some sort of click-through license agreement that would make it unsuitable for us. Then Wine and Winelib will be left without any usable documentation. So I think the functions implemented in Wine should be fully documented. And the only place to do that is in the code source because this is the only place where they have a remote chance of staying up to date (and also where it's most practical to have it). Of course developpers are very well-known for hating to document stuff so it's going to be pretty hard to get proper documentation. But we should encourage all Wine developpers to write good documentation for the functions they implement/fix, not dissuade them to do so. Also I agree with you that the strict minimum is to at least document all the undocumented/weird behaviors. Especially since without some sort of documentation the next developper may be tempted to remove what looks like unnecessarily convoluted/obviously wrong code. Then come the open questions: * How do we get people motivated to write documentation? Maybe people writing tests (as in using programs/winetest) should/could write documentation. After all to write proper tests you have to understand the API well enough to know what are the corner cases. So you might as well document the functions you test while you're at it. Then people doing the first non-stub implementation of an API would be in a good position to document it. After all if you implement an API aren't you supposed to know how it works? I certainly don't think we should bar code (implementation or tests) that comes with no documentation from getting into CVS. But maybe we could gently ask as a reminder if the submitter could write some doc too. * Is the current format the most appropriate one? Well, it's just that I'm a fan of JavaDoc-like formats and that I've always been a bit skeptical of the current system (c2man). Does it still work btw? Is http://www.winehq.com/WineAPI/ up to date? Also it seems we should have documentation on what messages do, especially for things like LVM_XXX. Maybe these could be documented with ListView_XXX macros so that searching for either will return the right page. Similarly there should be a policy wrt. documenting xxxA and/or xxxW. It seems like they should end up being documented on the same (man) page and that obviously we don't want to duplicate the documentation in the source. But there does not seem to be anything in place currently. It would probably be a good idea to also have a general way to group related functions together (e.g. all the MSVCRT execXXX variants). Did I say yet that I think a testing framework with many tests would be a great boon for Wine? No! Well, I'm going to stop there anyway. Lucky you :-) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Stolen from an Internet user: "f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng !"

Aug. 1, 2001