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

Re: Bug in MoveFileEx

by lawson_whitney＠juno.com

On Fri, 1 Feb 2002, Gerhard W. Gruber wrote: > I just played around with Thandor trying to install it and see what the > differences are between Win98 and Wine because I noticed a slightly different > behaviour. Now I discovered that MoveFileEx is not even available in Windows > 98 but wine supplies it nevertheless. I suspect that the Setup doesn't check > the windows version, but rather calls MoveFileEx and if that fails with not > implemented returncode continues with other code to supply the functionality. > I wrote a small test app to confirm this and this returns an error code when > calling MoveFileEx on a native win98 whiel wine executes it. > > How shall I fix this? Shall I simply call GetVersion() to determine if > MoveFileEx should be allowed or is there a different way with wine to > determine which functions are available for which version (a global variable > or such)? I looked through the sources but I couldn't find anywhere something > where a versioncheck has been used to switch code but then again I don't know > much functions where I know for sure that they are available in one version > and not in the other. > Why is it a problem? There is no guarantee Wine will be run with the same --winver next time, so the "boot" utility or startup code has to handle both idiotic mechanisms. It is not important to _me_ that Wine should be exactly as Windows, only that it should work well. If an app that people find useful refuses to work at all if it finds functions that it thinks should not be there, I guess we might have to cater for it, but I'd rather not. Lawson

Feb. 1, 2002

Re: Bug in MoveFileEx

by David Elliott

On 2002.01.31 18:37 Gerhard W. Gruber wrote: > I just played around with Thandor trying to install it and see what the > differences are between Win98 and Wine because I noticed a slightly > different > behaviour. Now I discovered that MoveFileEx is not even available in > Windows > 98 but wine supplies it nevertheless. I suspect that the Setup doesn't > check > the windows version, but rather calls MoveFileEx and if that fails with > not > implemented returncode continues with other code to supply the > functionality. > I wrote a small test app to confirm this and this returns an error code > when > calling MoveFileEx on a native win98 whiel wine executes it. > 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. 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. 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. 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. 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". 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 document that when an installer asks for a reboot you should close all wine applications and run the wininit command to cause the files to be copied. Of course with Wine more than likely you will not need to close anything and can simply run wininit while other unrelated processes are still running. I assume whatever Andi's program does would probably be similar to what I am describing. -Dave > How shall I fix this? Shall I simply call GetVersion() to determine if > MoveFileEx should be allowed or is there a different way with wine to > determine which functions are available for which version (a global > variable > or such)? I looked through the sources but I couldn't find anywhere > something > where a versioncheck has been used to switch code but then again I don't > know > much functions where I know for sure that they are available in one > version > and not in the other. > > -- > Bye, > Gerhard > If you think education is expensive, try ignorance. > > > >

Feb. 1, 2002

Re: DESTDIR support for make install

by David Elliott

On 2002.01.31 17:52 Joerg Mayer wrote: > On Thu, Jan 31, 2002 at 02:33:53PM -0800, Alexandre Julliard wrote: > > But "make install prefix=/home/myaccount/rpms/tmp" should do exactly > > the same thing, unless I missed something. You can run make with one > > prefix and make install with another one, that's a feature. > > I didn't know about this feature, but it works fine :) Thanks! > > Ciao > Jörg > You're still missing out on even more features though. The newer versions of RPM have configure and make install macros. When you use the configure macro it calls ./configure with a bunch of predefined parameters like the prefix and the etc directory and the manpages and info directories and so on. You then run make (usually wouldn't need any parameters.. although in wine's case don't forget to make depend before a make). Then when that is all said and done you use the makeinstall macro which runs make install with those parameters from the configure macro set with the RPM BuildRoot before them all. I believe Wine's makefiles should already be well behaved enough to handle that. Only issue I can remember is that a few weeks ago I grabbed wine out of CVS and compiled it on my work box and I could have sworn that when I did a make install that it compiled wineconsole again during that. I think that only happened during the first build of the tree (which is always going to be the case for an RPM). So you might want to look into that. Fortunately, this was not for an RPM, simply build as myself and install as myself into the /opt/wine-cvs directory which I own. -Dave

Feb. 1, 2002

Re: Fix for MoveFileExA

by David Elliott

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. -Dave

Feb. 1, 2002

Re: Pajama Sam's unmanaged window

by Dmitry Timoshkov

"Ove Kaaven" <ovehk(a)ping.uio.no> wrote: > > > > Since this is probably not the case, perhaps it's better to check for the > > > > popup menu class in is_window_managed(), something like > > > > > > > > if (GetClassLongA(win->hwndSelf, GCW_ATOM) == POPUPMENU_CLASS_ATOM) return > > > > FALSE; > > > > > > Ah ha! Exactly what I had in mind. After thinking about this, it seemed to me > > > that is_window_managed() should examine the window's class, as well as its > > > style bits, since the class will give a more accurate indication of what kind > > > of window we're dealing with than just the style bits. > > > > Unfortunately this aproach does not work well in all cases, especially in > > the case of subclassed windows. > > Do you have any examples where it might not work... window subclassing is > the act of using SetWindowLong to replace the window procedure, which does > not change the class atom, as far as I know? Here is what I did for testing a progress bar control: GetClassInfo(0, "msctls_progress32", &wnd_class); old_ProgressProc = wnd_class.lpfnWndProc; wnd_class.lpfnWndProc = my_ProgressProc; wnd_class.lpszClassName = "my_progress32"; RegisterClass(&wnd_class); my_ProgressProc just logs all received messages and then calls an old window procedure: CallWindowProc(old_ProgressProc, hWnd, uMsg, wParam, lParam); -- Dmitry.

Feb. 1, 2002

Re: ROTD (Rant Of The Day): patches

by Michael Stefaniuc

On Thu, Jan 31, 2002 at 03:52:19PM -0500, Dimitrie O. Paun wrote: > I've come to _hate_ diffs attached as Application/OCTET-STREAM. Can you > please, Please, PLEASE, attach them as Text/PLAIN? > > I use Pine over a ssh connection to read wine-{devel,patches}, and I can Use a better mailer like mutt ;) ? > simply view the Text/PLAIN attachments, whereas I have to: > -- press V to view the list of attachments > -- select the attachment I want to view > -- press S to save it to disk This is what have todo with mutt too, but I don't have to save. I press <Enter> to display the message. mutt complains about not having an appropiate method for the mime type and displays it in it's internal pager. I suspect this should work in pine too. > -- exit Pine > -- start vi to actually view the thing > -- restart pine... Uuuh ... this is like rebooting. Has pine a "pipe" function (it's long ago when I saw The Light and switched to mutt)? That's what i do in mutt wenn I get an gzip'ed patch: go to the list of attachments, select the attachment and pipe it through zless. So no need to leave the mailer. > Just to view a Application/OCTET-STREAM attachment. They don't annoy me too much, but the extra key strokes I need to view them will get me the carpal tunnel syndrome. bye michael P.S.: sorry, couldn't resist > Which means 2 things: > -- I get frustrated (and look what happens when I do:)) > -- I simply ignore those patches > > For all these reasons (and more), I think Linus is right when he insists on: > -- ONE patch per email > -- ONLY Text/PLAIN attachments. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.de Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Feb. 1, 2002