- Wine-devel - list.winehq.org

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 11:33 am, Patrik Stridvall wrote: > > Sure, but I have written the Perl code I know how ad hoc it is. > > It works under reasonable assumptions however beyond that... > > But we don't *want* Wine's sources to look beyond reasonable. > I see no problem. Even better, if this helps us detect unreasonable > looking sources... Well winapi_check already does that so no additional advantage...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> -----Original Message----- > From: Dimitrie O. Paun [mailto:dpaun(a)rogers.com] > Sent: Wednesday, September 11, 2002 5:37 PM > To: Patrik Stridvall; Francois Gouget > Cc: Wine Devel > Subject: Re: winebuild & (name, heap, init) > > > On September 11, 2002 11:24 am, Patrik Stridvall wrote: > > > BTW, how many are IO? I would suspect most are O only... > > > > For strings, not that many. Can't think of any right now. > > However there are quite a few LPDWORD that specifies the > > allocated length of the output buffer and the function > > is should write the used length (or needed length, > > if the function faild) in the pointed to DWORD. > > Dude, you're killing me! I often do that yet you still live. :-) > We care to distinguish I/O for strings _only_. And since we > don't have any, we have no problem!!! We have I found an example: LPTSTR PathAddBackslash(LPTSTR lpszPath); A few more of the Path functions are like that IIRC. Then there might be more function. The Windows API is larger we have only begun to implement it... > For LPDWORD, print them > always, they are fixed length, you (as the guy looking at the > traces) know if you care about them or not... True. How if you wish to automatically compare debug output diffs you have a problem. Sure pointer and such usually differs but that can be fixed with some sort of mapping table. However the value of unintialized variables are "random" or rather non-derministic since they might depend of subtle differences in the enviroment. But I do agree that strings is the larger problem...

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> Were we distinguishing IN/OUT and OUT before in the spec file? No. I suggest to Alexandre that we should add such information but he rejected my patch...

1 0

RE: winebuild & (name, heap, init)
by Jeff Smith 11 Sep '02

11 Sep '02

1 0

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 10:16 am, Patrik Stridvall wrote: > > #define HELPER(x,y,z) DWORD WINAPI x(y arg1, z *arg1) > > > > FOO(Bar, INT, HWND) { > > /* ... */ > > } > > > > But we don't need to support that. If it doesn't get recognized, > the function is not exported. You can manually look in the generated > spec file and see it's not there. > > I don't think we need to be too clever. Just get the 80% that can be > done with 20% of effort. Well as I said "winapi_extract --spec-files" works to some extent even now and getting it to work good enough might not be that much effort. However I'm worried about the "stabillity" of the result. > It's a temporaray solution anyway: we need > help from the compiler, writing a C parser (no, a gcc-C parser) is > a lot of work. Yes. I know I have tried. :-) > Mingw supports __declspec, Urlich, what would it take > for the regular gcc to support it under Linux/ELF? But what should it do? Just generate a special dllexport section that you can read with appropriate tools or what? > But beyond that, we can *today* compile Wine with Mingw as PE. So > what we need is a checkspec make target which would run your script, > compile Wine as PE, extract what needs extracting from there, and > compare results. This does not need to happen all the time, only > from time to time by some people that (1) have Mingw installed, > and (2) care to do it :). True. However I still a little worried about the "stabillity" of the solution.

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 05:48 am, Francois Gouget wrote: > > Hmm, for strings the spec files currently distinguish between input > > strings (str) and output strings (ptr). This cannot be > extracted from > > the source files... unless we start using IN/OUT macros everywhere? > > It's all in the types, dude... > > LPCSTR/LPCWSTR = IN, LPSTR/LPWSTR=IN/OUT. The is almost always correct. Unfortunately Microsoft is not consequent in the regard, but then I guess that we could modify the API slightly. If a WineLib application breaks, it was in some meaning broken anyway. However how do know whether it is IN/OUT or OUT? For debug messages that is quite important since the pointer in the OUT case might point to uninitialized memory which shouldn't be printed in the debug output...

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 06:18 am, Patrik Stridvall wrote: > > However I might be able to write a very specialized parser, that > > pipes the .c files through the C preprosessor, that work all of the > > time, but this is quite some work as well. > > But we shouldn't need that. Wine has a very good strucutre right now, > and were that's broken, we can fix... Sure. But what would tell you that it was broken? winapi_check currently, among other thing, compares the .spec files with the source code. When it reports something there are three possibillities 1. winapi_check is broken (because the code doesn't have good structure) 2. the .spec file is broken 3. the .c file is broken Currently I check manually and I try to make an educated guess of which is the cases and then fix it. If you extract the information from the source you don't have that luxury. If it misses a function or have some other bug you have no backup. Since the .spec files exists winapi_check knows what functions it is expected to find in the source code and if is doesn't it reports it. So if for example we have function Foo that looks like. #define HELPER(x,y,z) DWORD WINAPI x(y arg1, z *arg1) FOO(Bar, INT, HWND) { /* ... */ } winapi_check will miss it (since it in an ad hoc parser), but since Bar is declared in some .spec file it will complain that Bar was never found. Then I manually search the source, and try to fix the problem somehow. If you on the other hand extract the .spec files (of .def files) from the source the function Bar would be missed and you would never detect it... That is why the parser needs to be so good that it "always" works.

2 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 10, 2002 02:15 pm, Alexandre Julliard wrote: > > > Well, the problem is that the __declspec stuff is usually inside > > macros, so you have to run the code through the C > preprocessor to find > > them. It can be done, but it's not that trivial. Also one thing you > > need to extract is the relay debugging information (and for 16-bit > > code information for the relay routines), and this requires > a C parser > > (or some of Patrik's magic Perl stuff). > > I'm sure if we have the political will at the top, we'll find a > solution... :) Patrik, care to help us extract the required stuff > directly out of the source file? Sure. BTW winapi_extract can already do that: winapi_extract --spec-files This generates a .spec2 file that should hopefully be the same as the .spec file. It currently isn't (except for a few files) though but that can hopefully be fixed. Outputing in another format like .def files or whatever should be quite easy. However note that winapi_extract is quite ad hoc and specfic for parsing the Wine source tree. It is not a generalized C parser. I have begun with a generalized C parser in winapi_fixup however it doesn't quite work that good yet. Parsing generalized C is non trivial. > > A related idea I had is to store the relay debugging independently > > from the .spec file; you could then use it in other cases, notably > > with snoop debugging of native dlls. And then you no longer need a > > .spec, you can use a .def or directly extract the __declspecs, at > > least for Win32. This would also potentially allow more intelligent > > relay routines, maybe even per-dll relay code that knows > about the dll > > internal data structures; and hopefully also relay debugging of COM > > interfaces. > > Exactly! That's where I was driving at. But this depends on getting > stuff automatically out of .c file, because this way we can retain > the type information, which we now lose (except for strings). Once > we have the type information, the sky's the limit... But most > imprtantly, > we eliminate (1) a potential source of mistakes, (2) a barrier for > new commers (which are likely to be from the Windows world), and > (3) avoid maintenaning the 700KB of .specs!!! Agreed, but the script that does it is also a potential source of mistake and the current state of the winapi tools are that they work MOST of the time. However if we are to replace the .spec files it must work ALL the time. However I might be able to write a very specialized parser, that pipes the .c files through the C preprosessor, that work all of the time, but this is quite some work as well. Note however that piping every source file through the C prepropessor is VERY SLOW. That is one of the reason the winapi tools doesn't do that.

2 1

Re: wine/tools winemaker (1.49 - breaks winemaker)
by Martin Wilck 11 Sep '02

11 Sep '02

Am Mit, 2002-09-11 um 03.09 schrieb Alexandre Julliard: > ChangeSet ID: 1031706598725635746101947 Sorry, but this patch is severely broken - it introduces several regressions. > Log message: > Francois Gouget <fgouget(a)codeweavers.com> > Store the global settings in Make.rules.in instead of duplicating them > in each Makefile.in file. > Introduce generate_from_template which replaces generate_configure > and generate_generic > Simplify the wrapper generation by using generate_from_template. > Rename configure.in to configure.ac. Now works with autoconf 2.5x. This is what happened to me with a trivial winelib test setup: 1. winemaker doesn't even run - perl compilation error in generate_wrapper_file(). 2. After that's fixed, autoconf fails. Winemaker may now work with autoconf 2.5x, but is broken with 2.13. I wonder if this is intentional. If yes, I am against it - you cannot assume that all winelib developers have autoconf 2.5x. At the very least, it should be documented. 3. After that's fixed, configure fails with "Could not include the Wine headers (windef.h)". At this point I have stopped investigating further. Here is a quick fix for 1. and 2. - I will look into 3. and possible further problems later. Martin Index: winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.49 diff -u -r1.49 winemaker --- winemaker 11 Sep 2002 01:09:58 -0000 1.49 +++ winemaker 11 Sep 2002 09:52:51 -0000 @@ -1670,6 +1670,7 @@ { my $path=$_[0]; my $target=$_[1]; + my $app_name=@$target[$T_NAME]; return generate_from_template("wrapper.c","$path${app_name}_wrapper.c",[ ["APP_NAME",@$target[$T_NAME]], @@ -2069,7 +2070,7 @@ ["PROJECTS",join("\n",map { "@$_[$P_PATH]Makefile" } @projects)], ["SOURCE","$a_source_file"], ["NEEDS_MFC","$needs_mfc"]]); - system("autoconf"); + system("autoconf configure.ac > configure"); # Add execute permission to configure for whoever has the right to read it my @st=stat("configure"); -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 1

RE: winebuild & (name, heap, init)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On Wed, 11 Sep 2002, Dimitrie O. Paun wrote: > [...] > > Exactly! That's where I was driving at. But this depends on getting > > stuff automatically out of .c file, because this way we can retain > > the type information, which we now lose (except for strings). Once > > we have the type information, the sky's the limit... > > Hmm, for strings the spec files currently distinguish between input > strings (str) and output strings (ptr). This cannot be extracted from > the source files... unless we start using IN/OUT macros everywhere? Or we could do as winapi_{check,extract} already supports: BOOL WINAPI WaitCommEvent( HANDLE hFile, /* [in] handle of comm port to wait for */ LPDWORD lpdwEvents, /* [out] event(s) that were detected */ LPOVERLAPPED lpOverlapped) /* [in/out] for Asynchronous waiting */ { /* ... */ } Alexandre rejected having in/out markers in the .spec files so I never continued that project... > Anyway, where it would be most useful is for Winelib > applications. So if > we can support these then it would be great. Yes. > But it wouldn't it be > easier to hack the compiler? Maybe. :-) However the compiler must be really clever to determinte whether a pointer parameter is IN, OUT or IN/OUT. Futhermore it is logically impossible for stubbed functions and for stubbed functions it would be really nice to see the parameters wouldn't it? So I guess we have to put it in the source code somewhere. See my suggestion above.

1 0