wine-devel

wine-devel@winehq.org

15 participants
84452 discussions

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@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

Commctrl updates
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

ChangeLog Add ImageList states (ILS_*) definitions. Index: include/commctrl.h =================================================================== RCS file: /var/cvs/wine/include/commctrl.h,v retrieving revision 1.93 diff -u -r1.93 commctrl.h --- include/commctrl.h 9 Sep 2002 19:19:50 -0000 1.93 +++ include/commctrl.h 10 Sep 2002 20:15:00 -0000 @@ -487,6 +487,11 @@ #define ILCF_MOVE (0x00000000) #define ILCF_SWAP (0x00000001) +#define ILS_NORMAL 0x0000 +#define ILS_GLOW 0x0001 +#define ILS_SHADOW 0x0002 +#define ILS_SATURATE 0x0004 +#define ILS_ALPHA 0x0008 typedef struct _IMAGEINFO {

1 0

Re: Duplicate: Listview update - LVM_GETITEMRECT
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > +#if !LISTVIEW_DEBUG > + if (infoPtr->clrBk != CLR_NONE) > +#endif > + { > + HBRUSH hBrush = CreateSolidBrush(clrbrsh); > + FillRect(hdc, rc, hBrush); > + DeleteObject(hBrush); > + } > +} I *really* don't like these #ifs. Do we really have to have them? listview.c is already such a big file, and it's not easy to work with. Let's not make it harder... -- Dimi.

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > Of course potentially all types could teoretically be used so that > > would be VERY ugly... > > In theory maybe, but in practice I think there are very few structures > where this would be a problem. Yes. None of the structures in mssip have this problem AFAICS. > So we can simply fix the alignment > explicitly in these structures, either with padding or with > __attribute__. Yes. Thinking again. You can IIRC apply __attribute__((aligned(n))) to a specific field, you doesn't need to do it per type. However the only easy way to dectect automatically where you should add it will be using something like below. > A nice thing to have would be a script that parses the headers and > generates code to dump the size of all structures and the offsets of > all their members. Then we can build that code under Windows and > Winelib and compare the results. It has been in my TODO list for quite some time. I just never got around to do it. > I'm sure it's a 10 minute hack for > you to extend winapi_check to do this <g> winapi_check can't currently parse data structures so I have to teach it that first. That will take a lot more time than 10 minutes...

1 0

RE: mssip.h trouble
by Patrik Stridvall 10 Sep '02

10 Sep '02

> Patrik Stridvall wrote: > > > So it seems that if we add a -malign-double to CFLAGS we can > > remove the warning in pshpack8.h since now it will hopefully > > work correctly. > > Yes. However, the -malign-double option obviously causes GCC > to produce code that in some cases does not conform to the > Linux/i386 ABI. So, if Wine were to call any standard > library routines whose ABI is affected by -malign-double > (because a parameter is a structure type which is layed > out differently), we'd have a problem here ... Arrgggghhhhhhhh!!! :-( The alternative would be to add an explict __attribute__((aligned(8))) to all types larger than 4 bytes that can be used by #pragma pack(8) aligned structures. Of course potentially all types could teoretically be used so that would be VERY ugly...

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel