- Wine-devel - list.winehq.org

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