wine-devel

wine-devel@winehq.org

84471 discussions

RE: wstr vs ptr in spec files
by Patrik Stridvall 12 Sep '02

12 Sep '02

> When should I use wstr and when ptr for wide strings > in the spec files functions specification? > > Looking at existing files I see that LPCWSTR type is > usually mapped to wstr, It should almost always map to wstr. > but LPWSTR is sometimes mapped > to ptr, sometimes to wstr. As the general rule it depends on whether the parameter is IN, OUT or IN/OUT. IN: wstr OUT: ptr IN/OUT: wstr PS. It is for debug messages. If the parameter is OUT it might not be initialized as thus it should not be printed as a string (in this case a wide string).

1 0

Unicode functions
by steve.lustbader＠philips.com 12 Sep '02

12 Sep '02

Are _tprintf and it's related functions (_ftprintf, _stprintf) implemented? I found a tchar.h in the source tree that defines these functions, but it wasn't in my /usr/local/include/wine directory. These functions aren't important for wine, since they're simply defined as the ASCII or Unicode version, but they are important for WineLib. What is the overall status of using Unicode with WineLib? What needs to be defined and what headers need to be included to get the functionality from Windows' tchar.h (_T(), TCHAR, the above functions, etc)? -Steve

3 2

wstr vs ptr in spec files
by Andriy Palamarchuk 12 Sep '02

12 Sep '02

When should I use wstr and when ptr for wide strings in the spec files functions specification? Looking at existing files I see that LPCWSTR type is usually mapped to wstr, but LPWSTR is sometimes mapped to ptr, sometimes to wstr. Andriy Boston, MA, USA As an employee of an oil company, let me assure you that nothing, and I mean NOTHING scares a big company more than a noisy, smelly, obnoxious, disaffected pressure group. Now go away and chain yourself to someone important's front door. TheRegister. Unknown __________________________________________________ Do you Yahoo!? Yahoo! News - Today's headlines http://news.yahoo.com

1 0

RE: Patch - Fix typo
by Patrik Stridvall 12 Sep '02

12 Sep '02

> On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > > I noticed this when adapting WINE code for ReactOS > [...] > > > > - * DialogBoxIndirectParam (USER.240) > > > - * DialogBoxIndirectParam16 (USER32.@) > > > + * DialogBoxIndirectParam16 (USER.240) > > > + * DialogBoxIndirectParam (USER32.@) > > > */ > > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > > HANDLE16 dlgTemplate, > > > HWND16 owner16, > > > DLGPROC16 dlgProc, > > > > No this is correct. > > > > The 16 bit function's external name is DialogBoxIndirectParam > > The 32 bit function's external name is DialogBoxIndirectParam16 > Then maybe add a comment instead: > "(yep, 16/32 naming is correct)" Well, it quite common in the core DLLs that the naming is done that way so it would be quite a lot of IMHO unnessary comments. PS. winapi_check automatically finds functions that are wrong so the Wine sourc eis currrently 100% correct (save bugs in winapi_check of course) as far as the issue above in documentation header is concerned.

1 0

Re: Patch - Fix typo
by Andreas Mohr 12 Sep '02

12 Sep '02

On Wed, Sep 11, 2002 at 10:27:50PM +0200, Patrik Stridvall wrote: > > I noticed this when adapting WINE code for ReactOS [...] > > - * DialogBoxIndirectParam (USER.240) > > - * DialogBoxIndirectParam16 (USER32.@) > > + * DialogBoxIndirectParam16 (USER.240) > > + * DialogBoxIndirectParam (USER32.@) > > */ > > INT16 WINAPI DialogBoxIndirectParam16( HINSTANCE16 hInst, > > HANDLE16 dlgTemplate, > > HWND16 owner16, > > DLGPROC16 dlgProc, > > No this is correct. > > The 16 bit function's external name is DialogBoxIndirectParam > The 32 bit function's external name is DialogBoxIndirectParam16 Then maybe add a comment instead: "(yep, 16/32 naming is correct)" -- The Declaration of Software Freedom: http://freedevelopers.net/freedomdec/index.php

1 0

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

12 Sep '02

On September 10, 2002 10:26 pm, Guy L. Albertelli wrote: > Alexandre: Is this format any better. I am worried about line end > characters and line wrapping. I like this format a lot better! But I'm no Alexandre... :) > This is built on top of CVS of yesterday (9/9/02) but will probably > conflict with Dimi's latest patch. Can you please rediff against the current tree? TIA, Dimi.

3 5

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

12 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > 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. > > Sure, the idea of a cleanup tool is a good thing, it just should only > do the cleanups that we all agree on. Myself I'm especially interested > in an automatic cleanup of C++ comments... Already on my TODO list. BTW. How do you want multiliners like // XXX // YYY // ZZZ to look like? Like this /* XXX * YYY * ZZZ */ or like this /* * XXX * YYY * ZZZ */ or perhaps in some other way? One liners like // XXX should simply look like /* XXX */ Or would you prefer it some other way?

2 1

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

11 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > > 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. > > Well, the idea would be not to depend on compiler support for the > __declspec keyword itself, but more to have some clever macro > replacements that output stuff in a special ELF section or something > like that. This could then hopefully be made to work on most > compilers. But I'm not sure if there's a good way to do that at all. It might work, but then it might not. > > 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. > > I think most of all it needs to be simple. My idea is to run through > the preprocessor, This will be VERY slow. > find the __declspec, and locate the corresponding > function name, or die if there's anything it cannot parse. This should > be reasonably foolproof. A naive idea would be search for __declspec while keeping track of the nesting level (that is how many (, [, { that have not been closed). If the nesting level goes from 1 to 0 before finding the __declspec set a mark. When __declspec is found search backward to mark until you find ; at nesting level 0 or the mark then skip forward any white space. This is extremely likely to be the beginning of a function. Then search forward until { or ; is found when nesting level is 0. Then skip any whitespace backwards. You now know where a __declspec function begins and ends. This reduces the problem to the parsing of a function declaration. The rest is left as an exersize to the reader. :-) The problem is that this might work or it might not. You have no real guarante that it will. > And IMO it shouldn't be in Perl, it should be > part of winebuild. That will not make things easier.

3 2

Strange CVS problem (help!!!)
by Dimitrie O. Paun 11 Sep '02

11 Sep '02

Folks, Up until a few days ago, I was able to do this: # vim some/wine/file.c # cvs diff some/wine/file.c > file.diff # mail wine-patches(a)winehq.com < file.diff # sleep <until Alexandre commited the patch> # cvs up At this point, CVS would figure out that the changes in file.c in my tree are the same as the ones on the server, will give a message to that effect, and update the file. As of lately, this no longer happens: I get a big fat conflic for all the changes I submit! This is *very* annoying. Anyone knows how to fix this behaviour? Alexandre, are you doing anything different? -- Dimi.

7 20

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

11 Sep '02

> Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > 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 ;-) > > Well, no, if not everybody does it you can't do it either, otherwise > it will create huge differences. I don't want to receive a patch that > is 10% code and 90% whitespace changes just because the guy who edited > the file before you didn't cleanup the spaces. Well, either you remove trailing whitespaces from patches or you don't. If you do than "the guy who edited the file before you didn't cleanup the spaces" case can't happend, can it?

1 0

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

11 Sep '02

> > You have the case: > > void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) > > __attribute__((noreturn)) { } > > > > Sure you can have an exception if the name seems to be > __attribute__ but > > then where might be other exceptions. > > Yes, but a few preprocessor defines can get rid of that. Well. You want to read the __attribute__ to know if the function should be stdcall or cdecl don't you? The there might be cases I haven't though of. > > > The only problem is if you want to find > > > the number of args for stdcall decoration, but we should > be able to do > > > without it. > > > > That is not a problem. If you find the opening ( before the > function name, > > it would be the number of , at nesting level 1 plus one > with the special > > case of void between the parantesis which means 0. > > Except for 64-bit data types... And data structures. Forgot about that. > > Perhaps. You will easily reach 99% correctness. However > beyond that it > > is hard without a real C parser. > > Well it's clear you can't get 100%, the thing is to make sure it fails > in a reasonable way, not just silently breaks. Agreed. > I think it is feasible; Maybe. > whether it is worth the effort is an entirely different question... It is MANY hours of work. Work I'm not going to be able to motivate myself to do especially not if you want it in C. The last time years ago I did parsing and string handling in C was a horrible experience one I'm not eager to experience again, especially since other tools (read: Perl) exists. PS. I do agree it should be done in C though.

1 0

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

11 Sep '02

> Patrik Stridvall <ps(a)leissner.se> writes: > > > This will be VERY slow. > > I don't think it will be really different than duplicating all the > work the preprocessor is doing inside the parser itself. Of course you > want to use the Wine preprocessor, not fork+exec gcc for each file. OK. I was mainly refering to fork+exec gcc. > But yes parsing all the files is of course slower than having all the > info in the .spec, there's no way around that. Of course. > > You now know where a __declspec function begins and ends. > > This reduces the problem to the parsing of a function declaration. > > The rest is left as an exersize to the reader. :-) > > All you really need is the function name, which should be the last > token before the opening '('. Yes, but which opening? There might be several at nesting level 0. And searching backward to find the matching ( from the last ) might not be always correct either. You have the case: void __declspec(dllexport) __attribute__((__stdcall__)) Foo(void) __attribute__((noreturn)) { } Sure you can have an exception if the name seems to be __attribute__ but then where might be other exceptions. > The only problem is if you want to find > the number of args for stdcall decoration, but we should be able to do > without it. That is not a problem. If you find the opening ( before the function name, it would be the number of , at nesting level 1 plus one with the special case of void between the parantesis which means 0. > > The problem is that this might work or it might not. You > have no real > > guarante that it will. > > Well the thing is if you find a declspec you output what you think is > the function name. If you get it wrong and output 'WINAPI' or 'char*' > instead you'll notice it at build time. Perhaps. You will easily reach 99% correctness. However beyond that it is hard without a real C parser. It easy to do that for reasonable functions but for ALL function is much harder. For example you have the special case of a function that returns a function pointer. Not even all C compilers gets that one right, so it normally done with a helping typedef...

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel