February 2002 - Wine-Devel - list.winehq.org

Re: CreateProcess API - undocumented use

by Andreas Mohr

On Fri, Feb 01, 2002 at 10:22:40AM -0200, Ricardo wrote: > > just for understanding, what do you actually pass in dwFillAttribute ? > > (I assume it's the number '1' in your example, and then pgm2 recreates > > the name with a template like file%lu.dat) > > > > another point, if you do what Andi suggested, then please also code what > dwFillAttribute is meant for: > > - setting the default color attribute for a console program > (dwFillAttribute is not meant for passing values between programs) > > You're rigth, dwFillAttribute is not meant for passing values between > programs, but tell the programers. The've coded like this, not my fault, > it's not a console program either. What happens to the file: it contents > some values that I need in the second program. I'll see if i can get the > code. > Let's freeze this topic. Nope. Either you implement it (which might be useful in order to get a grasp of what Wine is all about) or if nobody else wants to implement it, then I'll certainly do it (should be a quick thing anyway). Raising a tempest in a teapot and then saying "let's freeze it" won't do much good ;-) -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Feb. 1, 2002

Re: CreateProcess API - undocumented use

by Ricardo

> just for understanding, what do you actually pass in dwFillAttribute ? > (I assume it's the number '1' in your example, and then pgm2 recreates > the name with a template like file%lu.dat) > > another point, if you do what Andi suggested, then please also code what dwFillAttribute is meant for: > - setting the default color attribute for a console program (dwFillAttribute is not meant for passing values between programs) You're rigth, dwFillAttribute is not meant for passing values between programs, but tell the programers. The've coded like this, not my fault, it's not a console program either. What happens to the file: it contents some values that I need in the second program. I'll see if i can get the code. Let's freeze this topic. Thanks Ricardo.

Feb. 1, 2002

Re: CreateProcess API - undocumented use

by Eric Pouech

> The file1.dat is passed as a parameter using the dwFillAttribute of the > pgm2. just for understanding, what do you actually pass in dwFillAttribute ? (I assume it's the number '1' in your example, and then pgm2 recreates the name with a template like file%lu.dat) another point, if you do what Andi suggested, then please also code what dwFillAttribute is meant for: - setting the default color attribute for a console program (dwFillAttribute is not meant for passing values between programs) A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle ____________________________________________________________ Faites un voeu et puis Voila ! www.voila.fr Avec Voila Mail, consultez vos e-mails sur votre mobile Wap.

Feb. 1, 2002

Re: Bug in MoveFileEx

by Marcus Meissner

On Fri, Feb 01, 2002 at 11:58:51AM +0100, Gerhard W. Gruber wrote: > David Elliott wrote: > > > Okay, so wine supplies the MoveFileEx function (like NT) for all > > versions. If you had read the archives you'd know that the chances of > > hell freezing over are greater than the chances of version specific > > behavior being added to Wine. > > Is this a principle decision for wine or is this just resignation that > it would be almost impossible to promise such a thing? I think this may This is a principle decision. Adding version checks leads to certain madness and insanity, and creates undebuggable problems. > be also a philosophical question but I think that wine tries to emulate > windows. This means to me that we should emulate windows where we know > how it is to be done. Of course there will be a great many places where > this is not the case, but this should be considered a bug IMO. I didn't > read the archives, because it's quite some text to read, so if you could > be a more specific if this has already been decided on, then I would > appreciate a pointer. Apply common sense and clean implementation first. Use version checks only when absolutely needed. Ciao, Marcus

Feb. 1, 2002

Re: CreateProcess API - undocumented use

by Andreas Mohr

On Fri, Feb 01, 2002 at 08:26:52AM -0200, Ricardo wrote: > > Well, show us how the second program is supposed to get at that data, > > and we'll show you what doesn't work at the moment. > > I'm still a bit ignorant about how exactly your programs do that data > > transfer (especially on the "client" side), thus please show us how > > this is supposed to be done. > > Thanks for helping me! I'll show how the program work: > > I have 2 programs, let's call them pgm1 and pgm2. These programs have common > data that pgm1 have to set on pgm2. > To set pgm2 data we write a file with a random name (actually we start with > a name, but if already exists we add 1 until we can create a new file) using > pgm1, let's cal this file file1.dat. > So, graphically it'll be: > > data ---------------->data > | | > | | > pgm1--> file1.dat--> pgm2 > > The file1.dat is passed as a parameter using the dwFillAttribute of the > pgm2. > > Hope it was what you were expecting. Hmm, no, sorry, it's not. I was asking to get more details on the client side, i.e. how the program *actually* gets hold of the STARTUPINFO.dwFillAttribute content that the parent passes via CreateProcess. AFAICS you haven't mentioned that in any of your mails. CreateProcess stuff can be found in loader/module.c, scheduler/process.c and server/process.c, in case you want to investigate that path. Ah, damn, forgot about GetStartupInfo(). That's probably how it's done. You should really have mentioned it by now, though. (been asking about three times now) In this case memory/environ.c would also be relevant. Oh, now I see. The only problem right now is that dwFillAttribute simply doesn't get passed at all to the wineserver and back. It simply gets omitted. scheduler/process.c/PROCESS_Create() would have to pass dwFillAttribute to the new_process request, and scheduler/process.c/PROCESS_Init() would have to get dwFillAttribute added at the init_process request in order to retrieve its value for the client program. And the stuff in server/ (structs mainly) would have to get enhanced to support this additional field. Could you take care of this ? And, even better, could you make sure all other relevant additional fields in STARTUPINFO are being copied from parent to server to client, too ? -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Feb. 1, 2002

Re: CreateProcess API - undocumented use

by Ricardo

> Well, show us how the second program is supposed to get at that data, > and we'll show you what doesn't work at the moment. > I'm still a bit ignorant about how exactly your programs do that data > transfer (especially on the "client" side), thus please show us how > this is supposed to be done. Sorry, the post was sent wrong. Here's it right. I have 2 programs, let's call them pgm1 and pgm2. These programs have common data that pgm1 have to set on pgm2. To set pgm2 data we write a file with a random name (actually we start with a name, but if already exists we add 1 until we can create a new file) using pgm1, let's cal this file file1.dat. So, graphically it'll be: data ---------------->data | | | | pgm1--> file1.dat--> pgm2 The file1.dat is passed as a parameter using the CreateProcessA.dwFillAttribute of the pgm1. Pgm2 get file1.dat with the GetStartupInfoA API. Hope it was what you were expecting. Thank you Ricardo.

Feb. 1, 2002

Re: Bug in MoveFileEx

by Gerhard W. Gruber

David Elliott wrote: > Okay, so wine supplies the MoveFileEx function (like NT) for all > versions. If you had read the archives you'd know that the chances of > hell freezing over are greater than the chances of version specific > behavior being added to Wine. Is this a principle decision for wine or is this just resignation that it would be almost impossible to promise such a thing? I think this may be also a philosophical question but I think that wine tries to emulate windows. This means to me that we should emulate windows where we know how it is to be done. Of course there will be a great many places where this is not the case, but this should be considered a bug IMO. I didn't read the archives, because it's quite some text to read, so if you could be a more specific if this has already been decided on, then I would appreciate a pointer. > If MoveFileEx actually works and puts the info in the registry the NT way, > then the only problem you'd have is if an application happened to actually > check the windows version and use that to decide if it should call > MoveFileEx or write to WININIT.INI directly. On the other hand, if we know that MoveFileEx exhibits a certain behaviour then we should do it as it is implemented in the real thing, because you can never know what else may depend on it. I think it is much harder to trakc such a bug down, when it is "fixed" wrongly but everyone thinks it is good enough. Especially since we have to implement both ways anyway, it doesn't hurt and will improve compatibillity, which I think should be the goal of wine. If it's just enough to satsify one application then my first approach works as good as any other, even if it is ugly. But I don't want to get my specific app running just to try a few months later another app and it has to start all over again. Analyze the problem and realize that it is the same thing that would have been fixed if it were done properly the first time. Especially since we know that the behaviour should be different. > I suspect that most applications are going to behave like you suggest. > That is that they will call MoveFileEx and if it succeeds then they will > assume the file is going to get replaced (which see below for how Wine > will do that). If MoveFileEx fails then they will add an entry to > wininit.ini. That's not a problem because Wine's call should always > succeed. In that particular case, but MoveFileEx has more features and I don't think that you can say for sure that there is not quite a number of applications that will crash or destroy something because it doesn't work as it should. > Now, for the latter case where the app checks the windows version. Well, > if it happens to write directly to WININT.INI instead of calling > MoveFileEx, then no big deal. We will have code that reads both > WININIT.INI and the NT-style registry entries. Right. > Considering that on Windows 9x/ME the WININIT.EXE program takes care of > this, might I suggest that we create a winelib application (placed in the > programs/ directory of the sourcetree) that reads in the registry entries > and the WININIT.INI flle and process the entries and deletes them. Such a > program I think would be aptly named simply "wininit". The sources, that Andreas provided are more or less that. > Now the trick is to somehow actually get the user to run the wininit > winelib program when needed. Personally I feel that this is secondary. > It could simply be accomplished by a wrapper shell script. The important > thing is to get the functionality described above implemented, and That's what I try to do. :)

Feb. 1, 2002

Re: treeview2.c

by Huw D M Davies

On Thu, Jan 31, 2002 at 03:40:04PM -0600, Aric Stewart wrote: > Why where we setting the items text to NULL on GetItemW. > > This appears to implement what the person was trying to do within the if > 0 block. > > Changelog: fix to GetItemW to stop whipping out the items text > > -aric > Index: dlls/comctl32/treeview.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/treeview.c,v > retrieving revision 1.95 > diff -u -u -r1.95 treeview.c > --- dlls/comctl32/treeview.c 2001/12/11 00:15:11 1.95 > +++ dlls/comctl32/treeview.c 2002/01/31 19:38:37 > @@ -1970,18 +1970,19 @@ ... > + MultiByteToWideChar(CP_ACP, 0, wineItem->pszText, > + strlen(wineItem->pszText), tvItem->pszText, > + tvItem->cchTextMax); Hi Aric, This won't copy the terminating '\0'. It'd be better to use -1 instead of the strlen. Huw.

Feb. 1, 2002

Re: Fix for MoveFileExA

by Andreas Mohr

On Thu, Jan 31, 2002 at 10:21:34PM -0500, David Elliott wrote: > On 2002.01.31 16:02 Gerhard W. Gruber wrote: > [snip] > > OK. I just downloaded it. I hope I know how to open bz2. :) > > > I assume that was a joke. > > [snip] > > > > Why is the To: field or the Reply-To: not set to the mailinglist instead > > of > > the poster? > > > hehehee.... READ THE ARCHIVES! > > We need to have an FAQ on this somewhere on the website. OK, added to www.winehq.com/FAQ Unfortunately checking my WD archive did NOT help. I know that there's been a rather longish thread about this, but grepping for e.g. list.*Reply-To Reply-To.*list Reply-To " Reply-To" reply.*list list.*reply " reply" yielded - you guessed it - nothing. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Feb. 1, 2002

Re: CreateProcess API - undocumented use

by Ricardo

> Well, show us how the second program is supposed to get at that data, > and we'll show you what doesn't work at the moment. > I'm still a bit ignorant about how exactly your programs do that data > transfer (especially on the "client" side), thus please show us how > this is supposed to be done. Thanks for helping me! I'll show how the program work: I have 2 programs, let's call them pgm1 and pgm2. These programs have common data that pgm1 have to set on pgm2. To set pgm2 data we write a file with a random name (actually we start with a name, but if already exists we add 1 until we can create a new file) using pgm1, let's cal this file file1.dat. So, graphically it'll be: data ---------------->data | | | | pgm1--> file1.dat--> pgm2 The file1.dat is passed as a parameter using the dwFillAttribute of the pgm2. Hope it was what you were expecting. Thanks Ricardo.

Feb. 1, 2002