- wine-devel - winehq.org

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > Not quite. If you run the tool on every commit (which is in > effect what's > > happening now), you almost guarantee that many people > contributing code > > will experience conflicts on a *daily* basis. If you run > the tool once > > once a year, I will experience the conflict only then. And > I will be so > > much happy. > > Well yes, that's what I meant by saying that the tool is "useless". If > I'm the only one who can use it, and then only once a year, we don't > really need it. As I can see it either we enforce no trailing whitespace or we do not. I can't see any reasonable middle ground. I'm of course for no trailing whitespace. :-) However I'm not going to start a new flamewar other it... > And in fact we should probably remove it so that other > people are not tempted to use it... The orginal reason for winapi_cleanup was to convert the \r\n that I got while editing in Micrsoft Developer studio to \n. But I can modify it the so it only does that. It should probably remove trailing whitespace at lines ending in \ though since some compilers choke on that.

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> On September 11, 2002 01:51 pm, Alexandre Julliard wrote: > > And in fact we should probably remove it so that other > > people are not tempted to use it... > > As long as I don't have to deal with the conflicts. I had > only grief from removing the whitespace, and NO benefit. > For me, the choice is clear. Have you tried to run winapi_cleanup before submitting the patch or alternatively before running "cvs update"?

1 0

OfficeXP/IE and latest CVS wine
by Boris 11 Sep '02

11 Sep '02

I downloaded the latest wine cvs [09-11-2002] and not using any windows files. I tried installing OfficeXP and only when I set the OS to Winme, It continues the farthest until it starts installing and then it says the setup files are corrupted. I looked at my status window and it says fixme:advapi:SetThreadToken((nil_,cafe): stub (NT impl. only) fixme:setupapi:SetupIterateCabinetA not implemented (setupapi.dll) Ive noticed even when trying to install IE5 or 6 without any hacks, it seems that their are *alot* of things not implimented in the setupapi. It would be nice to get install IE 5 or 6 off a clean wine installation without hacking the configs or creating any extra directories.

2 1

RE: Strange CVS problem (help!!!)
by Patrik Stridvall 11 Sep '02

11 Sep '02

> --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > On September 11, 2002 12:58 pm, Alexandre Julliard > > wrote: > > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > > > Well, I'm happy to turn it off if people consider > > it to be a problem. > > > > I think it should be turned off. It causes a lot of > > grief, for very little > > gain, if any. Moreover, now you have a tool in the > > tree that does that > > automatically, and cleverly. > > > > If you think whitespaces are a problem, *you* apply > > it say, once a year. > > Or every 5 years, I don't care. > > I (personally) like to keep it the way it is. > If the submitter is worried about the spaces he can > run the whitespaces cleaning tool himself before > submitting the patch (hint, hint ;-) Exactly. :-)

1 0

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

11 Sep '02

> On September 11, 2002 11:07 am, Patrik Stridvall wrote: > > > Well as I said a lot of API use LPSTR when it really should > > use LPCSTR so the potential IO/OUT cases are quite a few. > > I don't think it's "lot". Can you give a count where LPSTR/LPWSTR > is used for a IN parameter only? I don't know how to do that automatically. You will have to look in the documentation and sometimes the documention is wrong... > And those we can fix in our > sources, as you said. Yes. > > You mean just add a OUT before the type. That is quite easy > to parse. > > Even better -- encode it in the typeinfo. > > /* M = modifiable */ > typedef LPSTR LPMSTR; > typedef LPWSTR LPMWSTR; > > Use LPM{,W}STR instead of LP{,W}STR where the parameter is an IO one. > The type are equivalent, so no one will notice a difference except > our parsing tool. I personally like the OUT better since it is official defined by Microsoft. > 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. Other than that it is quite uncommon IIRC.

3 2

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

11 Sep '02

> On Wed, 11 Sep 2002, Patrik Stridvall wrote: > [...] > > > Of course having an imperfect parser also means we cannot > use it for > > > the export info, because unlike relay debugging it needs > to be 100% > > > correct. So we either need compiler declspec support, > > > > That will leave us dependent on compilers that support it. > > I agree that Wine should not depend on hacked compilers. However it > would be nice to have anyway for Winelib. There should be an > alternative > but if it saves 'big' Winelib developpers from having to > write huge spec > files by hand then it would definitely be a plus. For Winelib sure that would be a good idea. > I'm not saying that you, Patrik, should do it. I just don't want > potential contributers to think that this is not something > that would be > useful to Wine/Winelib. OK. For the record I see absolutely nothing wrong GNU C handles __declspec(dll{import,export}) and just put useful information in some aproprietely named section. After all you can always strip the section if don't want it and BTW if why don't want it why use __declspec(dll{import,export}) at all...

1 0

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

11 Sep '02

> The parser shouldn't require any modification > to the source, and should work on any Windows source, not only the > Wine ones. This means there are basically two approaches: > > 1. write a full C compiler This isn't happening soon. Definitely not within the coming months and not likely this year and more likely than not neither the coming year. > 2. use Patrik's Perl stuff to generate the initial info as best as we > can and then update it by hand. > > IMO #2 is the way to go, because no matter how clever a parser you > write it won't be able to extract semantics information; and that > would be the main advantage of doing a better relay debugger. Imagine > dumping structure contents, flags, following list pointers, etc. We > shouldn't limit ourselves to what can be extracted automatically from > the source. Agreed. I can write code if you, Dimitrie or whomever specify the output format... > Of course having an imperfect parser also means we cannot use it for > the export info, because unlike relay debugging it needs to be 100% > correct. So we either need compiler declspec support, That will leave us dependent on compilers that support it. > or we need a > specialized tool to extract the declspec info in a way that is > guaranteed to not miss anything. This isn't happend soon either. It might not be THAT difficult, however the code need not just work it needs be well structured and organized as well if any reasonable guarantees of correctness can be made.

3 2

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

11 Sep '02

> Steven Edwards <steven_ed4153(a)yahoo.com> writes: > > > I thought the WINE tree and regression suite would try and > move away from a perl dependancy? > > How is all of this going to effect building on > Windows/ReactOS with Mingw? I have had a bitch of a > > time getting Mingw+MSYS+Perl working and would hate to see > it become a bigger requirement. If > > -mno-cygwin worked right I dont guess it would be as big of > a deal because then we could still > > build WINE-Mingw under cyg but atm some import is still > hosing things up and forcing importation > > of cygwin1.dll so the recommended setup is just Mingw+MSYS. > > Yes, we should try to move away from the Perl requirement for > regression tests. It was considered OK to depend on it because the > framework itself was based on Perl, but now that all tests are done in > C anyway we should probably get rid of it. I see no reason to get rid of it. If people doesn't have Perl installed just don't run them. But then most people probabably have Perl installed anyway...

2 1

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

11 Sep '02

> On September 11, 2002 10:23 am, Patrik Stridvall wrote: > > However how do know whether it is IN/OUT or OUT? > > Excellent point. There aren't that many IN/OUT cases anyway > (can you produce a count?), Well as I said a lot of API use LPSTR when it really should use LPCSTR so the potential IO/OUT cases are quite a few. > but we would need to add some > metainfo at the source level. No big deal, really... You mean just add a OUT before the type. That is quite easy to parse.

3 4

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

11 Sep '02

> --- Patrik Stridvall <ps(a)leissner.se> wrote: > > > > > 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. > > > > > > Why? This is as good of a verification method (no, even > better) than > > > what we have today. > > > > Sure, but I have written the Perl code I know how ad hoc it is. > > It works under reasonable assumptions however beyond that... > > > > But I'm not really against it, I'm just pointing out > > potential problems... > > I thought the WINE tree and regression suite would try and > move away from a perl dependancy? It is not really dependent on Perl. Of course you can't run regression test written in Perl without Perl... > How is all of this going to effect building on > Windows/ReactOS with Mingw? I have had a bitch of a > time getting Mingw+MSYS+Perl working and would hate to see it > become a bigger requirement. If > -mno-cygwin worked right I dont guess it would be as big of a > deal because then we could still > build WINE-Mingw under cyg but atm some import is still > hosing things up and forcing importation > of cygwin1.dll so the recommended setup is just Mingw+MSYS. I understand. On the other hand we can't hold back "progress" just because of difficulties of installing certains tools on certain platforms. But judging from Alexandres message it won't be happing anytime soon... > Note: even using perl on cygwin is still borked atm for the > regression suite and I havent even > tried winapi_check. another option may be to look at active > perl for windows but I really dont > like that idea. ActivePython for Windows works nicely. Haven't tested ActivePerl...

1 0

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

11 Sep '02

> > > 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. > > Why? This is as good of a verification method (no, even better) than > what we have today. Sure, but I have written the Perl code I know how ad hoc it is. It works under reasonable assumptions however beyond that... But I'm not really against it, I'm just pointing out potential problems...

4 3

Standard controls
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

And since I feel frisky lately, I want to run another idea by you guys. We have the standard controls bundled with USER, just like Windows. In fact, it seems XP bundles them with the common control, but that's another story. My point is, that there's no logical reason they should be in USER. In fact, in the future we may want to provide other implementations which integrate better with GNOME and/or KDE. So what about moving them to a separate DLL, say winectrl? -- Dimi.

2 2

winebuild & (name, heap, init)
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

Alexandre, Why don't we take the following directives: name, heap, init out of the .spec file, and put them in the Makefile (transfered to winebuild through command line args)? Some of them are supported in .DEF file as well, but all of them are supported as arguments to LINK. I think it will gain us flexibility if we also support them as command line arguments. With that in mind, it would be neat if we could specify a flag at configure time to build most of Wine as PE with a cross mingw. It would be way cool if I could take the same comctl32.dll I have on Linux, copy it on my Windows machine, and test it out... Anyway, what about a patch to at least support all of this as command line options as well? -- Dimi.

4 7

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

Brazilian ABNT-2 Keyboard - DeadKeys not operates properly
by Salatiel-Robson Oliveira 10 Sep '02

10 Sep '02

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 10 Sep '02

10 Sep '02

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 10 Sep '02

10 Sep '02

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

Re: patches policy
by Jeff Smith 10 Sep '02

10 Sep '02

I prefer the attaching text method, to be *sure* the patch is not mangled, but that *anyone* can read it (e.g. I may want to review a patch from a location that does not offer me gzip or whatever the compression scheme de jour is). Also, have you tried adjusting the "Screen Width" settings in "General Preferences" in Yahoo Mail? -- Jeff S >From: Andriy Palamarchuk <apa3a(a)yahoo.com> >To: dimi(a)bigfoot.com, Wine Devel <wine-devel(a)winehq.com> >Subject: Re: patches policy >Date: Mon, 9 Sep 2002 11:30:37 -0700 (PDT) > >--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > Hi all, > > > > There is something concerning submitting patches > > that bothers me > > to no end: inlining vs. attaching them. >[skipped] > >I have to attach the patches :-( because I use Yahoo >online mail client and it wraps long lines. >I also usually compress patches with size >= 20-30kb >to save everybody's bandwith. > >It is good idea to add these recommendations to the >Starter's guide, even if we are not going to enforce >them. > >Andriy, >Boston, MA _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com

2 1

[PATCH] winemaker: fix catch() and throw() in winelib DLLs
by Martin Wilck 10 Sep '02

10 Sep '02

Patch: winemaker-wrapper.diff Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> Patch against: CVS 2002-09-10 Modified files: - tools: winemaker * A wrapper binary should not be linked to any library passed with "-l". [ I am forwarding this to wine-devel because the problem may be deeper than I think, see below ]. Rationale: This fixes a delicate problem with catch() and throw() in a DLL used by a winelib application that has a wrapper app. I have written this small, hopefully self-explaining, shell script that demonstrates the problem. (Note that my previous winemaker patches are necessary otherwise there'll be other errors before this one comes into play). #! /bin/sh # throwtest.sh - test winemaker with catch()/throw() in a DLL # Change this to the location of your wine installation (DLL will also be installed there) WINEDIR=$HOME/exp # Extra winemaker options to build EXE: CORE DUMP with --wrap, fine without EXEOPTS="--wrap" # Extra winemaker options to build DLL DLLOPTS="" errexit () { echo "** Error $1 !! **" >&2 exit 1 } export PATH=$WINEDIR/bin:$PATH export LD_LIBRARY_PATH=$WINEDIR/lib:$LD_LIBRARY_PATH echo "Building library ..." >&2 mkdir -p trylib cd trylib rm -f * # BEWARE !!! cat > trylib.cpp <<EOF int do_try (void) { int ret = 0; try { throw(1); } catch (int e) { ret = e; } return ret; } EOF winemaker --dll $DLLOPTS . > winemaker.out 2>&1 || errexit "running winemaker for library" ## remove the "init DllMain" declaration winemaker generates echo "" >libtrylib.spec ./configure --with-wine=$WINEDIR --prefix=$WINEDIR > conf.log 2>&1 || errexit "during library configure" make >make.log 2>&1 || errexit "building library" make install >>make.log 2>&1 || errexit "installing library" cd .. echo "Building program ..." >&2 mkdir -p tryexe cd tryexe rm -f * # BEWARE !!! cat > tryexe.cpp <<EOF #include <stdio.h> extern int do_try (void); void main (void) { printf ("Result: %d\n", do_try()); } EOF winemaker --cuiexe $EXEOPTS -ltrylib . > winemaker.out 2>&1 || errexit "running winemaker for program" ./configure --with-wine=$WINEDIR --prefix=$WINEDIR > conf.log 2>&1 || errexit "during program configure" make >make.log 2>&1 || errexit "building program" echo "Running program ..." >&2 ./tryexe >run.out 2>&1 || errexit "running program" echo "** Success !! **" >&2 # EOF throwtest.sh On my system, this yields the following output: Building library ... Building program ... Running program ... throwtest.sh: line 65: 14430 Aborted (core dumped) ./tryexe >run.out 2>&1 ** Error running program !! ** The reason is that "-ltrylib" becomes part of the DLL_LINK make variable and the wrapper app is thus linked with "libtrylink.so". If my analysis is correct, this leads to a situation where the gcc-generated exception code for throw() jumps into the wrapper app rather than into the wrapped app - i.e. to nowhere. IMO it makes no sense to include any additional libraries in the link list for the wrapper app (=> patch). If this isn't done, the test runs fine. This may point to a conceptual problem with the wrapper app approach, but at least it seems to run fine with the patch below. Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.47 diff -u -r1.47 winemaker --- tools/winemaker 10 Sep 2002 00:42:43 -0000 1.47 +++ tools/winemaker 10 Sep 2002 18:21:57 -0000 @@ -1993,7 +1993,11 @@ } else { print FILEO "\t\$(LDSHARED)"; } - print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(DLL_LINK) \$(LIBS)\n"; + if (@$target[$T_FLAGS] & $TF_WRAPPER) { + print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(WRAPPER_DLL_LINK) \$(LIBS)\n"; + } else { + print FILEO " \$(LDDLLFLAGS) -o \$\@ \$(${canon}_OBJS) \$(${canon}_SPEC_SRCS:.spec=.spec.o) \$(${canon}_LIBRARY_PATH) \$(${canon}_LIBRARIES:%=-l%) \$(DLL_LINK) \$(LIBS)\n"; + } if (@$target[$T_TYPE] ne $TT_DLL) { print FILEO "\ttest -f @$target[$T_NAME] || \$(INSTALL_SCRIPT) wineapploader @$target[$T_NAME]\n"; } @@ -3043,6 +3047,7 @@ ALLCFLAGS = $(CFLAGS) $(CEXTRA) $(OPTIONS) $(ALLFLAGS) ALLCXXFLAGS=$(CXXFLAGS) $(CXXEXTRA) $(OPTIONS) $(ALLFLAGS) ALLWRCFLAGS=$(WRCFLAGS) $(WRCEXTRA) $(OPTIONS) $(ALLFLAGS) +WRAPPER_DLL_LINK = $(LIBRARY_PATH) $(WINE_LIBRARY_PATH) -lwine -lwine_unicode -lwine_uuid DLL_LINK = $(LIBRARY_PATH) $(LIBRARIES:%=-l%) $(WINE_LIBRARY_PATH) -lwine -lwine_unicode -lwine_uuid LDCOMBINE = ld -r LDSHARED = @LDSHARED@ -- 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 0

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

10 Sep '02

> Patrik Stridvall wrote: > > > On MSVC it does matter in the following example whether n is 4 or 8. > > Or 16 for that matter eventhough that gives the same result as 8. > > > > #ifdef _MSC_VER > > typedef __int64 longlong_t; > > #else > > typedef long long longlong_t; > > #endif > > > > #pragma pack(n) > > typedef struct { > > char x; > > longlong_t y; /* offset is 4 if n = 4, but is 8 if n = > 8 or n = 16*/ > > } longlong_n; > > #pragma pack() > > I would assume that MSVC and GCC use different structure > layouts even without any #pragma pack(), because the > default aligment of 8-byte data types is different. > > As I mentioned in my other mail, GCC should use the same > layout as MSVC if you compile with -malign-double. As I mention in my other mail you are absolutely correct. :-) 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.

2 1

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

10 Sep '02

> Ah, I guess I see the problem: it doesn't really have > anything to do with #pragma pack(), but with the default > alignment of the 'long long' data type itself. > > GCC uses a default alignment of 4 bytes for 'long long', > so, if MSVC uses a default alignment of 8, that would be > the problem. You seem to be correct. With this code: #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef __attribute__((aligned (8))) long long longlong_t; #endif GNU C now works the same as with MSVC. > However, I think you can get GCC on i386 to use a default > alignment of 8 for 8-byte sized types, by specifying the > compiler option -malign-double. Yes, that works with GNU C as well. Even without my hack above. > (Then you'll probably > have to use -mpreferred-stack-boundary=3 instead of > -mpreferred-stack-boundary=2 as well.) It doesn't seem to do any difference in my simple example either with -mpreferred-stack-boundary=2 or -mpreferred-stack-boundary=3. The only thing that matters is whether -malign-double is set.

1 0

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

10 Sep '02

> Patrik Stridvall wrote: > > > - No GNU C compiler not even 3.1 support #pragma pack(8) nor > > does it support #pragma pack(16). It doesn't even give a warning. > > Well, GCC does support #pragma pack(8) and #pragma pack(16). > They just don't do anything on i386, because they don't need to. > > What #pragma pack(N) means is: if any structure member would > require a default alignment > N according to the normal rules, > reduce that alignment to N. > > As on i386 no structure member ever requires a default alignment > of > 8, #pragma pack(8) never needs to do anything. > > You appear to think that #pragma pack(N) should sometimes > *increase* some alignment requirement -- but it never does. That sound reasonable. However Microsoft doesn't seem to be reasonable. :-) > Under what circumstances do you think it should? Actually I don't think anything. I have tested what different compilers does. :-) As I explain in my latest mail (that perhaps you didn't read since it was only 5 minutes between the mails :-). On MSVC it does matter in the following example whether n is 4 or 8. Or 16 for that matter eventhough that gives the same result as 8. #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef long long longlong_t; #endif #pragma pack(n) typedef struct { char x; longlong_t y; /* offset is 4 if n = 4, but is 8 if n = 8 or n = 16*/ } longlong_n; #pragma pack()

2 1

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

10 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > I'm totally at loss as to what to do. Not that it currently > matters since > > the data structures isn't currently used but someday > somebody will... > > Well, we need to add explicit padding in the structures to respect the > alignment that MSVC uses. That should only be required at the end of > the structures I think, so it's not too bad. Unfortunately its a little more complicated than that, it effects the internal offset of fields as well in some case. In the normal case below it doesn't matter whether n is 4 or 8. #pragma pack(n) typedef struct { char x; long y; /* offset is 4 both for n = 4 and n = 8 */ } long_n; #pragma pack() However is the case below is does matter whether n is 4 or 8: #ifdef _MSC_VER typedef __int64 longlong_t; #else typedef long long longlong_t; #endif #pragma pack(n) typedef struct { char x; longlong_t y; /* offset is 4 if n = 4, but is 8 if n = 8 */ } longlong_n; #pragma pack() In short, if the size of a field is larger than 4 it matters internally whether alignment is 4 or 8. Now in the case of mssip.h, I can't see any fields that have sizes larger than 4 so we could easily handle that special case as you suggested. However in general we can not...

2 1

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

10 Sep '02

> On Tue, 10 Sep 2002, Patrik Stridvall wrote: > > > > While compiling the latest tree, I get this: > > > > > > [dimi@dimi wine]$ make -s > > > In file included from ../../include/mssip.h:49, > > > from main.c:22: > > > ../../include/pshpack8.h:47:6: warning: #warning "8 as > > > alignment is not supported" > [...] > > It seems that gcc or at least a previous versions of GCC > > didn't support it since somebody (Alexandre?) added a > > warning in pshpack8.h. > > It may have been me. I think at the time it was only meant for gcc, > which was the only things you could compile Wine with anyway. > The specific version of gcc is 2.95, and but I'm really not sure the > situation has changed. It hasn't. GCC 3.1 has the same problem. > > Futhermore Micrsoft C/C++ (or at least later version of it) > > contrary to the claim of pshpack8.h support it so it > > wrong at the point at least AFAIK. > > Yes, Visual C++ supports alignment 8 which is the problem (so that > defined(_MSC_VER) should have been moved elsewhere, just to avoid the > warning in fact). > > How we can handle such alignment issues in Wine whn compiled with gcc > I'm not sure. Neither am I. I have tested the alignment with various compiler and got the follow result: - No GNU C compiler not even 3.1 support #pragma pack(8) nor does it support #pragma pack(16). It doesn't even give a warning. - MSVC 6.0 support #pragma pack(8) but not #pragma pack(16) - The Solaris compiler (old version) doesn't even support #pragma pack(4), but then 4 is the default so it doesn't really matter that much (except for a warning). It support #pragma pack(1) and #pragma pack(2) though. So the conclusion is that only MSVC support #pragma pack(8), nothing else. I'm totally at loss as to what to do. Not that it currently matters since the data structures isn't currently used but someday somebody will... PS. I can't understand why GNU C doesn't support it, it can't be that difficult to implement can it? Nether the less that fact that it doesn't warn about it is even worse. That certainly can't be difficult to implement.

5 4

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

10 Sep '02

> While compiling the latest tree, I get this: > > [dimi@dimi wine]$ make -s > In file included from ../../include/mssip.h:49, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:80, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:88, > from main.c:22: > ./../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:97, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:109, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:123, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" > In file included from ../../include/mssip.h:140, > from main.c:22: > ../../include/pshpack8.h:47:6: warning: #warning "8 as > alignment is not supported" Ah, yes. I forgot to investigate that issue further. Sorry. First of all I want so say that the warning in itself is harmless. However anything using data structures from the header might not work correctly, but then currently only stub functions use it so it doesn't really matter. The problem is that mssip.h needs 8 as alignement for its data structures. It seems that gcc or at least a previous versions of GCC didn't support it since somebody (Alexandre?) added a warning in pshpack8.h. Futhermore Micrsoft C/C++ (or at least later version of it) contrary to the claim of pshpack8.h support it so it wrong at the point at least AFAIK. The big question is how should the following lines look like: # if defined(__GNUC__) || defined(__SUNPRO_C) || defined(__SUNPRO_CC) || defined(_MSC_VER) # pragma pack(8) # warning "8 as alignment is not supported" # elif !defined(RC_INVOKED) # error "Adjusting the alignment is not supported with this compiler" # endif Or perhaps phrased in another way: What compiler and specifically what versions or the compiler supports and handles #pragma pack(8) correctly? Note that just because it compiles without warning (or error) doesn't mean that it supports it correctly.

2 1

patches policy
by Dimitrie O. Paun 10 Sep '02

10 Sep '02

Hi all, There is something concerning submitting patches that bothers me to no end: inlining vs. attaching them. I don't know about others, but for me 99/1 rule applies: I at least skim over 99% of the patches inlines in the message, whereas I bother to read at most 1% of the ones attached/tar.gzed/ziped. Maybe I'm an extreme case, but there's got to be more to it than my personal quirks. If a patch is sent to wine-patches, it's sent there for peer review. If you don't want the review, send it to Alexandre directly, even though I suggest this is avoided as much as possible. However, it you do send it to wine-patches, please, *please* inline it! What about a nice patch submission policy: -- unified diff only (required) -- have a decent subject (recommended) -- a long description (optional, if the change warrants it) -- a meaningful ChangeLog entry (required) -- new files, if any, included in patch, diffed against /dev/null (required) -- patch inlined at the end of the message (required) -- one changeset per message Most of these things are already followed by most people, with the exception of the inlining bit. Alexandre, what about you reject patches that aren't in this format with a pointer to these rules? All this is a matter of habit, and I think we'll all benefit if these rules are followed. -- Dimi.

9 12

mssip.h trouble
by Dimitrie O. Paun 10 Sep '02

10 Sep '02

While compiling the latest tree, I get this: [dimi@dimi wine]$ make -s In file included from ../../include/mssip.h:49, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:80, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:88, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:97, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:109, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:123, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" In file included from ../../include/mssip.h:140, from main.c:22: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" nm: devenum.dll.tmp.o: no symbols nm: dplay.dll.tmp.o: no symbols -- Dimi.

1 0

Re: winedbg: enhancing symbol lookup
by Alexandre Julliard 10 Sep '02

10 Sep '02

Eric Pouech <eric.pouech(a)wanadoo.fr> writes: > --- debugger/break.c 30 Jul 2002 00:06:34 -0000 1.35 > +++ debugger/break.c 2 Sep 2002 19:39:59 -0000 > @@ -421,10 +421,15 @@ > DBG_VALUE value; > int i; > > - if (DEBUG_GetSymbolValue(name, lineno, &value, TRUE)) > + switch (DEBUG_GetSymbolValue(name, lineno, &value, TRUE)) > { > + case TRUE: > DEBUG_AddBreakpoint(&value, NULL, TRUE); > return; > + case FALSE: > + break; > + case ABORT: /* user aborted symbol lookup */ > + return; > } Please don't invent a third boolean state. A boolean is either TRUE or FALSE; if you need more than that you should define a new enum type with meaningful names. Reusing TRUE and FALSE will cause major confusion. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: winemaker: wineapploader generation
by Alexandre Julliard 10 Sep '02

10 Sep '02

Francois Gouget <fgouget(a)codeweavers.com> writes: > * tools/winemaker > Generate wineapploader using autoconf rather than from the Makefile Actually it's better to generate this kind of file from the Makefile; this way you can change things without having to re-run configure (by passing the values directly to make). For that reason the autoconf guidelines state that configure should only generate makefiles, not other files. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: patches policy
by Patrik Stridvall 09 Sep '02

09 Sep '02

> There is something concerning submitting patches that bothers me > to no end: inlining vs. attaching them. Yes!!! Finally. Another flamewar. :-) I will mainly comment how I submit my patches. I don't personally care that much what others do. However if Alexandre finds some way more convenient I can certain change... > I don't know about others, but for me 99/1 rule applies: I at least > skim over 99% of the patches inlines in the message, whereas > I bother to read at most 1% of the ones attached/tar.gzed/ziped. > Maybe I'm an extreme case, but there's got to be more to it than > my personal quirks. > > If a patch is sent to wine-patches, it's sent there for peer review. > If you don't want the review, send it to Alexandre directly, even > though I suggest this is avoided as much as possible. However, > it you do send it to wine-patches, please, *please* inline it! > > What about a nice patch submission policy: > -- unified diff only (required) Agreed (if the file already exists). > -- have a decent subject (recommended) Agreed. > -- a long description (optional, if the change warrants it) Agreed. > -- a meaningful ChangeLog entry (required) Agreed. > -- new files, if any, included in patch, diffed against > /dev/null (required) I currently use .tar files since it handles the case that Uwe was talking about that is new directories. But then, I use a script to generate my patches, so I can make the normal case (no new directory) as a diff against /dev/null. > -- patch inlined at the end of the message (required) If it is inlined at all it should certainly be at the end, agreed. > -- one changeset per message What about dependent changesets? Or changeset that are otherwise logically dependent (even if not syntactically or semantically)? I guess they could be perhaps is multiple messages like: Subject: Fix various bugs (part 1 of 3) Subject: Fix various bugs (part 2 of 3) Subject: Fix various bugs (part 3 of 3) I currently mail all my patches from Windows (Outlook) just out of habit I guess since it is where I send my other mail so that would require manual work. However I guess I could mail them directly from my Linux box using another script...

3 2

re: RFC: 'test' bugzilla keyword
by Dan Kegel 09 Sep '02

09 Sep '02

Francois Gouget wrote: > if we make it easy to track > conformance test issues in Bugzilla, we may get new contributers (sure I > realize it's not a magic bullet either). Thus I propose to add a 'test' > keyword to make it easy to find such issues in bugzilla for people > specifically interested in conformance tests. Excellent idea. The keyword 'test' might be a bit confusing -- some bug tracking systems use that word as a state. How about something short that has very few hits on Google? Like, um, "apifail" or "unitfail"? - Dan

4 6

[PATCH] winemaker fixes
by Martin Wilck 09 Sep '02

09 Sep '02

Hi, the patch below fixes a few things in winemaker. It seems to work with my app, but needs more testing, especially for MFC apps. Modified files: tools: winemaker documentation: winemaker.man Changelog: - adapt winemaker to the new way winebuild handles imports. - fix crashes due to winemaker-generated wrapper app closing libraries (is this one correct??) - Fix some minor bugs in the wrapper.c template. - change semantics of --nomfc option such that it overrides automatic setting of --mfc if stdafx.h or stdafx.cpp are found. (this may cause problems to some people. For me the old behaviour was a pain in the neck, because VC++ generates stdafx.h always, even for pure C projects). Feedback, please ! - Add --nodlls option to suppress auto-generated import list for simple apps. - Adapt man page. -- 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 Index: tools/winemaker =================================================================== RCS file: /home/wine/wine/tools/winemaker,v retrieving revision 1.39 diff -u -r1.39 winemaker --- tools/winemaker 14 Apr 2002 19:31:23 -0000 1.39 +++ tools/winemaker 22 May 2002 16:49:18 -0000 @@ -233,6 +233,14 @@ my $TF_MFC=4; ## +# User has specified --nomfc option for this target or globally +my $TF_NOMFC=8; + +## +# --nodlls option: Do not use standard DLL set +my $TF_NODLLS=16; + +## # Initialize a target: # - set the target type to TT_SETTINGS, i.e. no real target will # be generated. @@ -435,23 +443,37 @@ push @{@$target[$T_LIBRARY_PATH]},$option; } elsif ($option =~ /^-l/) { push @{@$target[$T_LIBRARIES]},"$'"; - } elsif (@$target[$T_TYPE] != $TT_DLL and $option =~ /^--wrap/) { - @$target[$T_FLAGS]|=$TF_WRAP; - } elsif (@$target[$T_TYPE] != $TT_DLL and $option =~ /^--nowrap/) { - @$target[$T_FLAGS]&=~$TF_WRAP; - } elsif ($option =~ /^--mfc/) { - @$target[$T_FLAGS]|=$TF_MFC; + } elsif ($option =~ /^--wrap/) { if (@$target[$T_TYPE] != $TT_DLL) { @$target[$T_FLAGS]|=$TF_WRAP; + } else { + print STDERR "warning: option --wrap is illegal for DLLs - ignoring"; + }; + } elsif ($option =~ /^--nowrap/) { + if (@$target[$T_TYPE] != $TT_DLL) { + @$target[$T_FLAGS]&=~$TF_WRAP; + } else { + print STDERR "warning: option --nowrap is illegal for DLLs - ignoring"; } + } elsif ($option =~ /^--mfc/) { + @$target[$T_FLAGS]|=$TF_MFC; + @$target[$T_FLAGS]&=~$TF_NOMFC; } elsif ($option =~ /^--nomfc/) { @$target[$T_FLAGS]&=~$TF_MFC; - @$target[$T_FLAGS]&=~($TF_MFC|$TF_WRAP); + @$target[$T_FLAGS]|=$TF_NOMFC; + } elsif ($option =~ /^--nodlls/) { + @$target[$T_FLAGS]|=$TF_NODLLS; } else { print STDERR "error: unknown option \"$option\"\n"; return 0; } } + if (@$target[$T_TYPE] != $TT_DLL && + @$target[$T_FLAGS] & $TF_MFC && + !(@$target[$T_FLAGS] & $TF_WRAP)) { + print STDERR "info: option --mfc requires --wrap"; + @$target[$T_FLAGS]|=$TF_WRAP; + } return 1; } @@ -541,7 +563,7 @@ } elsif ($dentry =~ /\.c$/i and $dentry !~ /\.spec\.c$/) { push @sources_c,"$dentry"; } elsif ($dentry =~ /\.(cpp|cxx)$/i) { - if ($dentry =~ /^stdafx.cpp$/i) { + if ($dentry =~ /^stdafx.cpp$/i && !(@$project_settings[$T_FLAGS] & $TF_NOMFC)) { push @sources_misc,"$dentry"; @$project_settings[$T_FLAGS]|=$TF_MFC; } else { @@ -551,7 +573,7 @@ push @sources_rc,"$dentry"; } elsif ($dentry =~ /\.(h|hxx|hpp|inl|rc2|dlg)$/i) { push @sources_misc,"$dentry"; - if ($dentry =~ /^stdafx.h$/i) { + if ($dentry =~ /^stdafx.h$/i && !(@$project_settings[$T_FLAGS] & $TF_NOMFC)) { @$project_settings[$T_FLAGS]|=$TF_MFC; } } elsif ($dentry =~ /\.dsp$/i) { @@ -774,10 +796,13 @@ push @exe_list,$target; } # This is the default link list of Visual Studio, except odbccp32 - # which we don't have in Wine. Also I add ntdll which seems - # necessary for Winelib. - my @std_dlls=qw(advapi32.dll comdlg32.dll gdi32.dll kernel32.dll ntdll.dll odbc32.dll ole32.dll oleaut32.dll shell32.dll user32.dll winspool.drv); - @$target[$T_DLLS]=\@std_dlls; + # which we don't have in Wine. + my @std_dlls=qw(advapi32.dll comdlg32.dll gdi32.dll kernel32.dll odbc32.dll ole32.dll oleaut32.dll shell32.dll user32.dll winspool.drv); + if (@$target[$T_FLAGS] & $TF_NODLLS == 0) { + @$target[$T_DLLS]=\@std_dlls; + } else { + $target[$T_DLLS]=[]; + } push @{@$project[$P_TARGETS]},$target; # Ask for target-specific options @@ -982,7 +1007,8 @@ @$wrapper[$T_TYPE]=@$target[$T_TYPE]; @$wrapper[$T_INIT]=get_default_init(@$target[$T_TYPE]); @$wrapper[$T_FLAGS]=$TF_WRAPPER | (@$target[$T_FLAGS] & $TF_MFC); - @$wrapper[$T_DLLS]=[ "kernel32.dll", "ntdll.dll", "user32.dll" ]; + @$wrapper[$T_DLLS]=[ "kernel32.dll", "user32.dll" ]; + push @{@$wrapper[$T_LIBRARIES]}, "dl"; push @{@$wrapper[$T_SOURCES_C]},"@$wrapper[$T_NAME]_wrapper.c"; my $index=bsearch(@$target[$T_SOURCES_C],"@$wrapper[$T_NAME]_wrapper.c"); @@ -1634,32 +1660,10 @@ $rcname =~ s+([^/\w])+\\$1+g; print FILEO "rsrc $rcname.res\n"; } - print FILEO "\n"; - my %dlls; - foreach $dll (@{$global_settings[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } - if (defined $project_settings) { - foreach $dll (@{@$project_settings[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } - } - foreach $dll (@{@$target[$T_DLLS]}) { - if (!defined $dlls{$dll}) { - print FILEO "import $dll\n"; - $dlls{$dll}=1; - } - } # Don't forget to export the 'Main' function for wrapped executables, # except for MFC ones! - if (@$target[$T_FLAGS] == $TF_WRAP) { + if ((@$target[$T_FLAGS]&($TF_WRAP|$TF_WRAPPER|$TF_MFC)) == $TF_WRAP) { if (@$target[$T_TYPE] == $TT_GUIEXE) { print FILEO "\n@ stdcall @$target[$T_INIT](long long ptr long) @$target[$T_INIT]\n"; } elsif (@$target[$T_TYPE] == $TT_CUIEXE) { @@ -1867,6 +1871,7 @@ generate_list("${canon}_LIBRARY_PATH",1,@$target[$T_LIBRARY_PATH]); generate_list("${canon}_LIBRARIES",1,@$target[$T_LIBRARIES]); generate_list("${canon}_DEPENDS",1,@$target[$T_DEPENDS]); + generate_list("${canon}_IMPORTS",1,@$target[$T_DLLS]); print FILEO "\n"; generate_list("${canon}_OBJS",1,["\$(${canon}_C_SRCS:.c=.o)","\$(${canon}_CXX_SRCS:.cpp=.o)","\$(EXTRA_OBJS)"]); print FILEO "\n\n\n"; @@ -1952,7 +1957,7 @@ print FILEO "\t-\$(STRIP) \$(STRIPFLAGS) \$\@\n"; print FILEO "\n"; print FILEO "\$(${canon}_SPEC_SRCS:.spec=.spec.c): \$(${canon}_SPEC_SRCS) \$(${canon}_SPEC_SRCS:.spec=.tmp.o) \$(${canon}_RC_SRCS:.rc=.res)\n"; - print FILEO "\t\$(LD_PATH) \$(WINEBUILD) -fPIC \$(${canon}_DLL_PATH) \$(WINE_DLL_PATH) -sym \$(${canon}_SPEC_SRCS:.spec=.tmp.o) -o \$\@ -spec \$(SRCDIR)/\$(${canon}_SPEC_SRCS)\n"; + print FILEO "\t\$(LD_PATH) \$(WINEBUILD) -fPIC \$(${canon}_DLL_PATH) \$(WINE_DLL_PATH) -sym \$(${canon}_SPEC_SRCS:.spec=.tmp.o) -o \$\@ -spec \$(SRCDIR)/\$(${canon}_SPEC_SRCS) \$(${canon}_IMPORTS:%=-l%)\n"; print FILEO "\n"; my $t_name=@$target[$T_NAME]; if (@$target[$T_TYPE]!=$TT_DLL) { @@ -2168,7 +2173,7 @@ print STDERR "Usage: winemaker [--nobanner] [--backup|--nobackup] [--nosource-fix]\n"; print STDERR " [--lower-none|--lower-all|--lower-uppercase]\n"; print STDERR " [--lower-include|--nolower-include]\n"; - print STDERR " [--guiexe|--windows|--cuiexe|--console|--dll]\n"; + print STDERR " [--guiexe|--windows|--cuiexe|--console|--dll|--nodlls]\n"; print STDERR " [--wrap|--nowrap] [--mfc|--nomfc]\n"; print STDERR " [-Dmacro[=defn]] [-Idir] [-Pdir] [-idll] [-Ldir] [-llibrary]\n"; print STDERR " [--interactive] [--single-target name]\n"; @@ -2181,9 +2186,6 @@ exit (2); } - -project_init(\@main_project,""); - while (@ARGV>0) { my $arg=shift @ARGV; # General options @@ -2244,11 +2246,13 @@ $opt_flags&=~$TF_WRAP; } elsif ($arg eq "--mfc") { $opt_flags|=$TF_MFC; - $opt_flags|=$TF_MFC|$TF_WRAP; $needs_mfc=1; } elsif ($arg eq "--nomfc") { - $opt_flags&=~($TF_MFC|$TF_WRAP); + $opt_flags&=~$TF_MFC; + $opt_flags|=$TF_NOMFC; $needs_mfc=0; + } elsif ($arg eq "--nodlls") { + $opt_flags|=$TF_NODLLS; # Catch errors } else { @@ -2263,6 +2267,11 @@ usage(); } } + + if ($opt_flags & $TF_MFC && $opt_target_type != $TT_DLL) { + print STDERR "info: option --mfc requires --wrap\n"; + $opt_flags |= $TF_WRAP; + }; } if (!defined $opt_work_dir) { @@ -2278,6 +2287,8 @@ print_banner(); } +project_init(\@main_project,""); + # Fix the file and directory names fix_file_and_directory_names("."); @@ -3094,6 +3105,8 @@ * This is either CUIEXE for a console based application or * GUIEXE for a regular windows application. */ +#define GUIEXE 0 +#define CUIEXE 1 #define APP_TYPE ##WINEMAKER_APP_TYPE## /** @@ -3138,11 +3151,11 @@ int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) #else -int WINAPI Main(int argc, char** argv, char** envp) +int WINAPI main(int argc, char** argv, char** envp) #endif { void* appLibrary; - HINSTANCE hApp,hMFC,hMain; + HINSTANCE hApp = 0, hMFC = 0, hMain = 0; void* appMain; char* libName; int retcode; @@ -3212,7 +3225,7 @@ } /* Get the address of the application's entry point */ - appMain=(WinMainFunc*)GetProcAddress(hMain, appInit); + appMain=GetProcAddress(hMain, appInit); if (appMain==NULL) { char format[]="Could not get the address of %s (%d)"; char* msg; @@ -3232,11 +3245,6 @@ #endif /* Cleanup and done */ - FreeLibrary(hApp); - if (hMFC!=NULL) { - FreeLibrary(hMFC); - } - dlclose(appLibrary); free(libName); return retcode; Index: documentation/winemaker.man =================================================================== RCS file: /home/wine/wine/documentation/winemaker.man,v retrieving revision 1.5 diff -u -r1.5 winemaker.man --- documentation/winemaker.man 2 Oct 2001 17:47:34 -0000 1.5 +++ documentation/winemaker.man 22 May 2002 16:49:19 -0000 @@ -17,7 +17,7 @@ ] .br [ -.IR "--guiexe " "| " "--windows " "| " "--cuiexe " "| " "--console " "| " "--dll " +.IR "--guiexe " "| " "--windows " "| " "--cuiexe " "| " "--console " "| " "--dll " "| " "--nodlls " ] .br [ @@ -121,6 +121,14 @@ i.e. for which it does not know whether it is an executable or a library, it should assume it is a library. .TP +.I --nodlls +This option tells winemaker not to use the standard set of winelib libraries +for imports. That is, any DLL your code uses must be explicitly passed to +winemaker with -i options. +The standard set of libraries is: advapi32.dll, comdlg32.dll, gdi32.dll, +kernel32.dll, odbc32.dll, ole32.dll, oleaut32.dll, shell32.dll, user32.dll, +winspool.drv. +.TP .I --wrap Specifies that executable targets should be built as libraries and a small executable wrapper generated for them. This technique is sometimes required @@ -137,7 +145,9 @@ generates wrappers for these targets that are executables. .TP .I --nomfc -Specifies that targets are not MFC-based. This is the default. +Specifies that targets are not MFC-based. This option disables use of MFC libraries +even if winemaker encounters files "stdafx.cpp" or "stdafx.h" that would cause it +to enable MFC automatically if neither --nomfc nor --mfc was specified. .TP .I -Dmacro[=defn] Adds the specified macro definition to the global list of macro definitions. @@ -149,8 +159,7 @@ Appends the specified directory to the global library path. .TP .I -idll -Adds the Winelib library to the global list of Winelib libraries to import -in the spec file. +Adds the Winelib library to the global list of Winelib libraries to import. .TP .I -llibrary Adds the specified library to the global list of libraries to link with.

2 5

Recent change causes bad QuickBooks behaviour(?)
by Carl Sopchak 09 Sep '02

09 Sep '02

I have been using Wine to run QuickBooks fairly successfully for several months now. However, I frequently do CVS updates because I'm also trying to run Quicken, and there are several issues that I'm hoping will get fixed this way. (I have fixed a few of them myself, and am working on one now, but my time [like everyone else's, I'm sure] is limited...) It's been a few weeks since I've run QuickBooks (8/19 was my last transaction date, so it'd be somewhere around there...). When I went to run it today (after several CVS updates on wine, including "moments ago"), after the company data file is opened, the main menu bar goes away. This was definately NOT a problem the last time I ran QuickBooks, so I surmise that it is the result of a change committed to CVS within the past two to three weeks that is causing this behaviour. It happens in both managed and unmanaged window mode. Basically, the main menu bar should be at the top of the window, but the configurable taskbar / buttonbar is displayed "over" it. The accellerator keys for the menu bar are no longer recognised (the program beeps if you try to use <alt>f [for example] to get to the File menu). I am more than willing to try to debug this. I'd really rather not go back to Windows to run QuickBooks, but I HAVE TO HAVE it (for running my company's finances!) But, before I spend days trying to find out what changed in the past few weeks, I was wondering (no, hoping, really) if anyone might recognize this problem as being a possible result of a recent CVS committed change. Well, in the mean time, I guess I'll look through the CVS commits from the past few weeks (arghhh!)... Any help would be greatly appreciated... Thanks, Carl

3 6

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> > Yes. I have submitted most of my changes of that kind to the > > CVS so the current status of that is quite good. > > What is the status of WINE under MS_VC? I ask because I dont > have a copy of MS_VC and I would like > to see if there is anything that builds right with it but not > with Mingw/Cygwin. What > dlls/programs can you build atm? The compile status in general is quite good. The link status however is not. A lot more work remains.

1 0

RE: Wine DLLs compiled under Visual C
by Patrik Stridvall 09 Sep '02

09 Sep '02

> I want to get some comments about how others here try to get the DLLs > compiled > under Visual C. I went ahead and tried to do this for > shell32.dll and after > a > little work it went so far fine. However after creating a > config.h file for > Visual C with a few definitions such as for inline, I had to > make some minor > changes to some of the c source files such as adding an > #include "config.h" > and sometimes #include "wine/port.h" to the beginning. Yes. I have submitted most of my changes of that kind to the CVS so the current status of that is quite good. > Is this the recommended way of doing things or is there a reason that > "config.h" > shouldn't be included in some of the dll source files? I ask because I > noticed > that in a few of the shell32 files it is included but in the > several of them > it wasn't and in a few it doesn't (yet) need to be. Use msvcmaker. It generates Visual Studio 6.0 .dsw and .dsp files as well as an include/config.h file. cd wine ./tools/winapi/msvcmaker Then open wine.dsw in Visual Studio. PS. Note that msvcmaker only runs under Unix. I use Samba to export the directory to Windows.

2 1

Re: Trying to debug Paradise Poker client
by Per Nystrom 09 Sep '02

09 Sep '02

Ok, these are the lines that concern me when I'm running it with the builtin advapi32 dll: 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,00000000,00000001,f0000000) ret=40cc424b 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc424b 080995d0:Call advapi32.CryptAcquireContextA(41ee6570,00000000,40d0e840 "Intel Hardware Cryptographic Service Provider",00000016,00000000) ret=40cc429c 080995d0:Ret advapi32.CryptAcquireContextA() retval=00000000 ret=40cc429c What can be done to fix it? Thanks, Per Nystrom

2 1

Wine DLLs compiled under Visual C
by Rolf Kalbermatter 09 Sep '02

09 Sep '02

I want to get some comments about how others here try to get the DLLs compiled under Visual C. I went ahead and tried to do this for shell32.dll and after a little work it went so far fine. However after creating a config.h file for Visual C with a few definitions such as for inline, I had to make some minor changes to some of the c source files such as adding an #include "config.h" and sometimes #include "wine/port.h" to the beginning. Is this the recommended way of doing things or is there a reason that "config.h" shouldn't be included in some of the dll source files? I ask because I noticed that in a few of the shell32 files it is included but in the several of them it wasn't and in a few it doesn't (yet) need to be. Rolf Kalbermatter

1 0

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