September 2002 - Wine-devel

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