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

Re: RtlpWaitForCriticalSection?

by Alexandre Julliard

Christian Costa <titan.costa(a)wanadoo.fr> writes: > In this case, CRITICAL_SECTION_INIT should be update, at least to have > the line number. :-) > > So, if everyone agree. That 's fine for me. :-) > Would you submit a patch that handle that ? As discussed recently, CRITICAL_SECTION_INIT should be removed since it's not in the standard headers. So you probably don't want to start changing it now... -- Alexandre Julliard julliard(a)winehq.com

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Dan Kegel

Christian Costa wrote: >>>>> In that case our InitializeCriticalSection macro would have one >>>>> more parameter (the name) than the real function. >>>> >>>> Nope. It wouldn't. We would construct the name from __FILE__ and >>>> __LINE__. >> It would have the filename and line number as the name... that >> would be enough to let you distinguish between locks. ... >> The chief advantage, though, is that it gets us automatically >> generated names with no source changes, at least for static calls... > > In this case, CRITICAL_SECTION_INIT should be update, at least to have > the line number. :-) > > So, if everyone agree. That 's fine for me. :-) > Would you submit a patch that handle that ? I will give it a try. Then people can pass judgement on whether it's a good idea. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: Windows API database

by Dan Kegel

Oh, ok. Cross-referencing DLL imports and exports. Yeah, that sounds like a job for a simple perl script. All you need to output is DLL name and what DLLs it imports from. Just generate a flat text file for starters, then later postprocess that into an ascii tree or graph. It's going to be a messy little graph, I bet. - Dan Dave Miller wrote: > The project I am considering is mentioned on the contributing page here: > http://fgouget.free.fr/wine/contributing-en.shtml. (Build a database of > Windows APIs and dependencies) It sounds like less work to simply create > text files containing the imports and exports, although I think the point is > partially for the results to be easily cross referenced by developers. > Hence the suggestion of a database of some kind. I've considered scanning > applications as well. If I have any success with the Windows APIs I may try > tackling that at some point as well. > > ----- Original Message ----- > From: "Dan Kegel" <dank(a)kegel.com> > To: "David Miller" <compsol(a)ptd.net> > Cc: <wine-devel(a)winehq.com> > Sent: Thursday, January 23, 2003 3:38 PM > Subject: Re: Windows API database > > > >>David Miller wrote: >> >>>I would be interested in knowing more about the goals of this project. >>>Don't consider me officially working on such a thing just yet. I have >>>no real perl experience, but would like to learn. First I'd like to >>>know more about what I'm up against. >> >>I'm not sure what project you're talking about, but I can make a few >>wild guesses... >> >> >>>1. Is there a specific set of dll's and exe's we want included in the >>>database or does it need to scan and gather a list of all dll and exe >>>files? That would suggest a clean OS install is necessary. >> >>Sure, a clean OS install is probably good. Many of the >>APIs exposed by even the clean OS install may not be >>needed if no application calls them, but it's hard to know >>that in advance. >> >>We might want to also scan applications to see what APIs >>they actually use, but that's real hard. >> >> >>>2. What information should be in the database? (OS ver, name of dll or >>>exe, name of imported dll, APIs and whether they are imported or >>>exported, etc.) >> >>Maybe use the same format as we use in the souce tree? e.g. >>scanning advapi32.dll should produce something that looks very >>much like > > http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 > >>>3. Will a single MySQL table do or does it need to be a relational >>>database with multiple tables? >> >>IMHO no SQL is needed. The database should be plain text >>files checked into CVS. >> >> >>>4. Anything else you can tell me about this task? >> >>Compare with other standards which provide lists of API's, for example: >>http://www.linuxbase.org/spec/ >>http://www.unix.org/ >>http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM >>to get some ideas. Of course, these are formatted all fancily, >>and cover different operating systems, but the goal is similar: >>to provide an authoritative list of APIs. >>Ideally, the result could be part of a submission to a >>standards body. >>(See also http://www.kegel.com/remedy/remedy2.html#fix.info ) >>- Dan >> >>-- >>Dan Kegel >>http://www.kegel.com >>http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 >> >> >> > > > > -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Christian Costa

Dan Kegel wrote: > Christian Costa wrote: > >>>> In that case our InitializeCriticalSection macro would have one >>>> more parameter (the name) than the real function. >>> >>> >>> Nope. It wouldn't. We would construct the name from __FILE__ and >>> __LINE__. >>> >> So you suggest to not set a name ? >> What happened if there are two or more critical sections in the same >> source file, a file that has changed. >> Having no name make things harder to distinguish them in a log. >> OK, it is a little paranoid. :-) > > > It would have the filename and line number as the name... that > would be enough to let you distinguish between locks. > And it even lets you know if you have the right sources, > 'cause otherwise the line number won't match :-) > > The chief advantage, though, is that it gets us automatically > generated names with no source changes, at least for static calls. > (Won't help with ones done via GetProcAddr, but that's ok.) Is there any calls done via GetProcAddr in wine sources ? I guess not. In this case, CRITICAL_SECTION_INIT should be update, at least to have the line number. :-) So, if everyone agree. That 's fine for me. :-) Would you submit a patch that handle that ? > > - Dan >

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Dan Kegel

Christian Costa wrote: >>> In that case our InitializeCriticalSection macro would have one more >>> parameter (the name) than the real function. >> >> Nope. It wouldn't. We would construct the name from __FILE__ and >> __LINE__. >> > So you suggest to not set a name ? > What happened if there are two or more critical sections in the same > source file, a file that has changed. > Having no name make things harder to distinguish them in a log. > OK, it is a little paranoid. :-) It would have the filename and line number as the name... that would be enough to let you distinguish between locks. And it even lets you know if you have the right sources, 'cause otherwise the line number won't match :-) The chief advantage, though, is that it gets us automatically generated names with no source changes, at least for static calls. (Won't help with ones done via GetProcAddr, but that's ok.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: Windows API database

by Dave Miller

The project I am considering is mentioned on the contributing page here: http://fgouget.free.fr/wine/contributing-en.shtml. (Build a database of Windows APIs and dependencies) It sounds like less work to simply create text files containing the imports and exports, although I think the point is partially for the results to be easily cross referenced by developers. Hence the suggestion of a database of some kind. I've considered scanning applications as well. If I have any success with the Windows APIs I may try tackling that at some point as well. ----- Original Message ----- From: "Dan Kegel" <dank(a)kegel.com> To: "David Miller" <compsol(a)ptd.net> Cc: <wine-devel(a)winehq.com> Sent: Thursday, January 23, 2003 3:38 PM Subject: Re: Windows API database > David Miller wrote: > > I would be interested in knowing more about the goals of this project. > > Don't consider me officially working on such a thing just yet. I have > > no real perl experience, but would like to learn. First I'd like to > > know more about what I'm up against. > > I'm not sure what project you're talking about, but I can make a few > wild guesses... > > > 1. Is there a specific set of dll's and exe's we want included in the > > database or does it need to scan and gather a list of all dll and exe > > files? That would suggest a clean OS install is necessary. > > Sure, a clean OS install is probably good. Many of the > APIs exposed by even the clean OS install may not be > needed if no application calls them, but it's hard to know > that in advance. > > We might want to also scan applications to see what APIs > they actually use, but that's real hard. > > > 2. What information should be in the database? (OS ver, name of dll or > > exe, name of imported dll, APIs and whether they are imported or > > exported, etc.) > > Maybe use the same format as we use in the souce tree? e.g. > scanning advapi32.dll should produce something that looks very > much like http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 > > > 3. Will a single MySQL table do or does it need to be a relational > > database with multiple tables? > > IMHO no SQL is needed. The database should be plain text > files checked into CVS. > > > 4. Anything else you can tell me about this task? > > Compare with other standards which provide lists of API's, for example: > http://www.linuxbase.org/spec/ > http://www.unix.org/ > http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM > to get some ideas. Of course, these are formatted all fancily, > and cover different operating systems, but the goal is similar: > to provide an authoritative list of APIs. > Ideally, the result could be part of a submission to a > standards body. > (See also http://www.kegel.com/remedy/remedy2.html#fix.info ) > - Dan > > -- > Dan Kegel > http://www.kegel.com > http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 > > >

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Christian Costa

Dan Kegel wrote: > Christian Costa wrote: > >>> Hmm. Seems to be the Wine DLL sources should try >>> to avoid stuff that doesn't compile under Windows. >>> That said, we could provide a header file that >>> defined SET_CRITICAL_SECTION_NAME in Windows, and >>> made it do nothing. >> >> >> If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ? > > > It doesn't compile under MSVC, I bet. But I haven't tried it, > perhaps it does. > >>> Furthermore, we could be real sneaky, and make that header file turn >>> InitializeCriticalSection into a macro >>> that called the real InitializeCriticalSection, >>> then called SET_CRITICAL_SECTION_NAME, >>> so no source changes would be needed to get the name in there, maybe. >> >> >> In that case our InitializeCriticalSection macro would have one more >> parameter (the name) than the real function. > > > Nope. It wouldn't. We would construct the name from __FILE__ and > __LINE__. > - Dan > So you suggest to not set a name ? What happened if there are two or more critical sections in the same source file, a file that has changed. Having no name make things harder to distinguish them in a log. OK, it is a little paranoid. :-) Christian

Jan. 23, 2003

Re: RtlpWaitForCriticalSection?

by Dan Kegel

Christian Costa wrote: >> Hmm. Seems to be the Wine DLL sources should try >> to avoid stuff that doesn't compile under Windows. >> That said, we could provide a header file that >> defined SET_CRITICAL_SECTION_NAME in Windows, and >> made it do nothing. > > If CRITICAL_SECTION_INIT compiles why not SET_CRITICAL_SECTION_NAME ? It doesn't compile under MSVC, I bet. But I haven't tried it, perhaps it does. >> Furthermore, we could be real sneaky, and make that header file turn >> InitializeCriticalSection into a macro >> that called the real InitializeCriticalSection, >> then called SET_CRITICAL_SECTION_NAME, >> so no source changes would be needed to get the name in there, maybe. > > In that case our InitializeCriticalSection macro would have one more > parameter (the name) than the real function. Nope. It wouldn't. We would construct the name from __FILE__ and __LINE__. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: Windows API database

by Dan Kegel

David Miller wrote: > I would be interested in knowing more about the goals of this project. > Don't consider me officially working on such a thing just yet. I have > no real perl experience, but would like to learn. First I'd like to > know more about what I'm up against. I'm not sure what project you're talking about, but I can make a few wild guesses... > 1. Is there a specific set of dll's and exe's we want included in the > database or does it need to scan and gather a list of all dll and exe > files? That would suggest a clean OS install is necessary. Sure, a clean OS install is probably good. Many of the APIs exposed by even the clean OS install may not be needed if no application calls them, but it's hard to know that in advance. We might want to also scan applications to see what APIs they actually use, but that's real hard. > 2. What information should be in the database? (OS ver, name of dll or > exe, name of imported dll, APIs and whether they are imported or > exported, etc.) Maybe use the same format as we use in the souce tree? e.g. scanning advapi32.dll should produce something that looks very much like http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 > 3. Will a single MySQL table do or does it need to be a relational > database with multiple tables? IMHO no SQL is needed. The database should be plain text files checked into CVS. > 4. Anything else you can tell me about this task? Compare with other standards which provide lists of API's, for example: http://www.linuxbase.org/spec/ http://www.unix.org/ http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM to get some ideas. Of course, these are formatted all fancily, and cover different operating systems, but the goal is similar: to provide an authoritative list of APIs. Ideally, the result could be part of a submission to a standards body. (See also http://www.kegel.com/remedy/remedy2.html#fix.info ) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 23, 2003

Re: dos4gw stub exec failed

by Enrico Horn

On Wednesday 22 January 2003 19:16, Jukka Heinonen wrote: > > If you get those games to work under dos32a you will probably find out > that Wine SVGA support is lacking. That is something I have considered > to fix if I can find the time to do it. Hmm, I considered doing VGA and SVGA stuff for some time but I lack meaningful doc(about vga and svga stuff) and a place to start. If you could provide both maybe I could do some bits of it. Ciao Enrico farmboy1(a)subdimension.com

Jan. 23, 2003