September 2002 - Wine-Devel

RE: winebuild & (name, heap, init)
by Patrik Stridvall Sept. 11, 2002

Sept. 11, 2002

> 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 Sept. 11, 2002

Sept. 11, 2002

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 Sept. 11, 2002

Sept. 11, 2002

> 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 Sept. 11, 2002

Sept. 11, 2002

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 Sept. 11, 2002

Sept. 11, 2002

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 Sept. 10, 2002

Sept. 10, 2002

> 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 Sept. 10, 2002

Sept. 10, 2002

> 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

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira Sept. 10, 2002

Sept. 10, 2002

Francois, I am using the last version --> Wine-20020904 (Setember) and unfortunately the problem continues. What can we to change in the file keyboard.c to solve this problem? Thank you for attention!!! Salatiel Robson Francois Gouget Para: Salatiel-Robson Oliveira <fgouget(a)free.fr> <salatiel-robson.oliveira(a)serpro.gov.br> 10/09/2002 16:49 cc: wine-devel(a)winehq.com Assunto: Re: Brazilian ABNT-2 Keyboard - DeadKeys not operates properly - On Tue, 10 Sep 2002, Salatiel-Robson Oliveira wrote: > > Hi !!! > > For start, I want to say that I'm Brazilian and my english is terrible. > Excuse me for mistakes. > > My question: > > I have a keyboard Brazilian-ABNT2, the WINE recognize the layout perfectly, > but the "DeadKeys" doesn't operates properly. > > For example: I want that appear à ã â á , but appear `a ~a ^a ´a Dead-key support is relatively recent (2 months, maybe 3). Which version of Wine are you using? If it's more than a month old I would recommend upgrading to the latest version. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

1 0

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira Sept. 10, 2002

Sept. 10, 2002

Hi !!! For start, I want to say that I'm Brazilian and my english is terrible. Excuse me for mistakes. My question: I have a keyboard Brazilian-ABNT2, the WINE recognize the layout perfectly, but the "DeadKeys" doesn't operates properly. For example: I want that appear à ã â á , but appear `a ~a ^a ´a Do you understand? Can you help me!!! Thanks!!! (See attached file: keyboard.c) Salatiel Robson

2 1

unhandled exception does not longer raise the winedbg
by Stefan Leichter Sept. 10, 2002

Sept. 10, 2002

Hello, i have posted this message to cemw before, but the message appeared only partly there (checked on google) and this mailing list might be the better place for the problem. Here is my problem: In the past when i ran Paintshop Pro 5/6 in wine a wineconsole had opened with the debugger after an unhandled exception. This is broken for me in the current release (20020904). The exception occures but the debugger does not start as you can see in the attached trace. Does anyone else have this problem or know a fix? After i have noticed the problem i rebuilt the previous release (20020804) from scratch again to be sure that this is not a problem of my installation and winedbg appears as expected. Thanks for answer Stefan PS: for the record System is SuSE Linux 7.3 wine 20020904 build from source, updated by the patch file from the tiger.informatik.hu-berlin.de mailing list

1 0