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

Bug in MoveFileEx

by Gerhard W. Gruber

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. -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 31, 2002

Re: Bug in WritePrivateProfileSection

by Gerhard W. Gruber

On Thu, 31 Jan 2002 23:38:05 +0100, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: >On Thu, Jan 31, 2002 at 11:23:58PM +0100, Gerhard W. Gruber wrote: >> I just wrote a small up to test the behaviour of WritePrivateProfileSection. >> This confirmed my suspicion that the wine implementation is wrong because on >> Win98 I can create multiple keys with the same name when using this function, >> while wine always substitutes the new value if the key already exists. If >> nobody is working on that, then I'll fix this first before continuing with the >> boot process. >Yep, go ahead. >In case of questions with that boot stuff, just ask me. ok. -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 31, 2002

Re: DESTDIR support for make install

by Joerg Mayer

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 -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Joerg Mayer

Hmm, looks like after the failed attempt for a flame war on version numbering, you are trying to start one on mail clients 8-=) 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'd like to see properly labeled attachment types too, be they text/plain, mime, gzip or whatever. > I use Pine over a ssh connection to read wine-{devel,patches}, and I can > simply view the Text/PLAIN attachments, whereas I have to: Hmm, the problem you mentioned is one of the two major reasons that drove me away from pine towards mutt. I'm now running a (n almost) properly configured mutt and don't have these problems any more because app/o-s are just viewed with the text viewer after pressing v and selecting the attachment (which takes maybe 2 seconds). I don't like your idea of 1 patch per mail, as this would probably take me 2-3 additional seconds per mail (poor me). ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Jan. 31, 2002

Re: Bug in WritePrivateProfileSection

by Andreas Mohr

On Thu, Jan 31, 2002 at 11:23:58PM +0100, Gerhard W. Gruber wrote: > I just wrote a small up to test the behaviour of WritePrivateProfileSection. > This confirmed my suspicion that the wine implementation is wrong because on > Win98 I can create multiple keys with the same name when using this function, > while wine always substitutes the new value if the key already exists. If > nobody is working on that, then I'll fix this first before continuing with the > boot process. Yep, go ahead. In case of questions with that boot stuff, just ask me. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Jan. 31, 2002

Re: DESTDIR support for make install

by Alexandre Julliard

Joerg Mayer <jmayer(a)loplof.de> writes: > So changing prefix is not the way to go. DESTDIR allows to do the > install via "DESTDIR=/home/myaccount/rpms/tmp make install" instead > of doing all the steps from "make install" manually. 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. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: DESTDIR support for make install

by Joerg Mayer

On Thu, Jan 31, 2002 at 01:09:28PM -0800, Alexandre Julliard wrote: > > wine currently doesn't support the DESTDIR flag commonly used by > > packagers. The patch I've attached fixes this. > > Could you explain this a bit more? Why can't you use the existing > $prefix to do the same thing? When creating a spec file for rpms, you basically prepare the source (unpack, apply patches), then run configure, make and --->make install Because the result is intended not to be run but to be packaged, you don't install into e.g. /usr/local directly, but into something like /home/myaccount/rpms/tmp/usr/local. Later, when you *install* the package, you want the binaries to be installed into /usr/local and all paths compiled into the binaries to point to /usr/local/... too. So changing prefix is not the way to go. DESTDIR allows to do the install via "DESTDIR=/home/myaccount/rpms/tmp make install" instead of doing all the steps from "make install" manually. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.

Jan. 31, 2002

Bug in WritePrivateProfileSection

by Gerhard W. Gruber

I just wrote a small up to test the behaviour of WritePrivateProfileSection. This confirmed my suspicion that the wine implementation is wrong because on Win98 I can create multiple keys with the same name when using this function, while wine always substitutes the new value if the key already exists. If nobody is working on that, then I'll fix this first before continuing with the boot process. -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 31, 2002

Re: DESTDIR support for make install

by Daniel Sabo

On Thu, 31 Jan 2002 13:09:28 -0800, Alexandre Julliard wrote: > Bernhard Rosenkraenzer <bero(a)redhat.de> writes: > >> wine currently doesn't support the DESTDIR flag commonly used by >> packagers. The patch I've attached fixes this. > > Could you explain this a bit more? Why can't you use the existing > $prefix to do the same thing? > > $prefix changes the code, e.g. winelauncher sets it's directories based on $prefix. DESTDIR puts the files somewhere esle but writes the code like it was going in $prefix. So you could have $prefix=/usr and DESTDIR=/tmp/winepackage

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Francois Gouget

On Thu, 31 Jan 2002, Dimitrie O. Paun wrote: [...] > BTW, how do you fork the external pager? I just do '>', select the attachement and 'V'. I don't think I have any specific option. [...] > Me too! :) That is, I would like to know as well. > > I guess you can insert the patch in the body of the message using: > ^R - from Pico to "Read File" Maybe I'll try that. it should tae care of botht the MIME and base64 issues. Putting a patch directly inline worries me though. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Jan. 31, 2002

Re: Fix for MoveFileExA

by Gerhard W. Gruber

On Thu, 31 Jan 2002 15:36:55 -0600, Aric Stewart <aric(a)codeweavers.com> wrote: >Ok I interpret the MSDN paragraph differently. I read it as meaning that >the MoveFileEx function would FAIL. if used with that flag. And that it >was the Programs responsibility to write to the WinInit.ini file. In my You are right. I just looked up the MSDN paragraph and it says that this function is not supported on W95/98. >experience with installers this has been the case. So there is not alot >wine has to do, just do a version check and if in Windows 95/98 mode >fail. I dont think it is proper for the function to do the writing to >wininit.ini. I have a program "Thandor" which installer uses this function. I check if it creates the wininit.ini file manually. I only noticed the fixme message that told me to rename files manually and I thought that annyoing so I tried to fix it. At that time I didn't knew about that wininit.ini file so I didn't check if it exists. What I also noticed now is that there appears to be a difference between wine win98 and real win98. When I install this program under Win98 it simply installs and I can run it immediatly. When I install it under wine with --winver win98 at the end a dialog pops up that tells me if I want to reboot or not. Since I have only win98 and NT installed I can't check if this behaviour is under win95 but there is obviously something different here. >The problem is sort of two fold. >#1) this is not processing you want to have happen every time wine is >started. Only after a reboot or when signaled to do so. There is alot of >reboot / windows startup processing that happens (WinInit.ini, RunOnce >etc..) and it is best to keep all that processing together. So wine >startup starts to get bigger and messy. I already checked that file Andreas showed me and I'll work on this now instead. I agree that the code should be seperated as cleanly as possible so I have no problem with that. >Take a look at andreas' utility he sent out. It has alot it does but you >can see how the wininit.ini processing works. It is also a very easy >(maybe 1 hour) project to write up a smaller winelib/unix utility that >does the same if that is all you need for you particular situation. I don't want to do it for me specifically because I don't need that program to run under linux. If I work on it then I want it to be integrated in wine. I have no problem parsing the wininit.ini file myself, as this is a rather easy job, as you said. I think I already wrote some years ago a function that does this because windows wasn't so popular then. :) -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Dimitrie O. Paun

On Thu, 31 Jan 2002, Francois Gouget wrote: > Another issue which is dear to Alexandre :-) I wonder why?... :) > When I send a patch with netscape and then read the email in pine, I > see the email and the attachement right below it. When I send a patch > with pine, I have to use V, select the attachement and pine forks an > external pager (more/less/whatever). That's fine too but slightly less > practical. BTW, how do you fork the external pager? > So if anyone has tips for configuring pine so that it makes nicer > attachements... Me too! :) That is, I would like to know as well. I guess you can insert the patch in the body of the message using: ^R - from Pico to "Read File" or ^_ - to go to the alternate editor (vi) and do the dirty deed in there. -- Dimi.

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Dimitrie O. Paun

On Thu, 31 Jan 2002, Alexandre Julliard wrote: > I can't say I disagree with you, but I'll just note that all your > patches are base64 encoded, which is not really better <g> Oops <blush/> (but, ..., but, ... mine are Text/PLAIN at least :)) Sorry, I did not realise that. Speaking of which, I don't have the slightest idea how to force Pine not to do that. Maybe the only way is to actually _insert_ the text of the patch at the end of the message, but as far as I know, there are some broken versions of Pine out that will mangle the patch in sublte ways. > IMO any mail that cannot be piped straight into patch should be rejected Agreed. I am sorry I caused you grief by sending you base64 patches, from my mailer POV they seemed to be "in clear". > but I don't do it because it would take me more time to > explain that to people sending patches and keep track of it all than > it takes me to decode them. Maybe we should put an auto-rejecter of > mime crap on the wine-patches list.. Yeah, that would be good. Maybe include something into the documentation describing how to send the patch using various mailers? -- Dimi.

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Eric Pouech

> Maybe we should put an auto-rejecter of > mime crap on the wine-patches list.. or an automatic converter/inliner... A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 31, 2002

Re: treeview.c

by Aric Stewart

It doesn't really fail silently as one will see the visual error of the text string being empty. It does prevent the application from crashing so someone can investigate why the item is empty. Do you think there should be a warn or err message? I could add that but found it seemed to be messy. -aric Uwe Bonnes wrote: > > >>>>> "Aric" == Aric Stewart <aric(a)codeweavers.com> writes: > > Aric> This is a bit of a cover to help find other problems, but we would > Aric> crash if trying to sort a treeview with null strings in it. This > Aric> prevents this crash so that one can try to figure out why we have > Aric> empty strings. > > Aric> CHANGELOG: prevent crash on sorting treeview with null strings > > > Aric> - return strcasecmp(first->pszText, second->pszText); + if > Aric> (first->pszText && second->pszText) + return > Aric> strcasecmp(first->pszText, second->pszText); + else if > Aric> (first->pszText) + return -1; + else if (second->pszText) + return > Aric> 1; + else + return 0; } > > Should this fail silently? > > Bye > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Alexandre Julliard

"Dimitrie O. Paun" <dimi(a)cs.toronto.edu> writes: > For all these reasons (and more), I think Linus is right when he insists on: > -- ONE patch per email > -- ONLY Text/PLAIN attachments. I can't say I disagree with you, but I'll just note that all your patches are base64 encoded, which is not really better <g> IMO any mail that cannot be piped straight into patch should be rejected; but I don't do it because it would take me more time to explain that to people sending patches and keep track of it all than it takes me to decode them. Maybe we should put an auto-rejecter of mime crap on the wine-patches list.. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: Fix for MoveFileExA

by Aric Stewart

"Gerhard W. Gruber" wrote: > > On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart <aric(a)codeweavers.com> wrote: > > >Windows 95 and Windows 98: The MoveFileEx function is not supported. To rename or > >delete a file at reboot, use the following procedure. > > > > To rename or delete a file on Windows 95 and Windows 98 > >Check for the existence of the WININIT.INI file in the Windows directory. > >If WININIT.INI exists, open it and add new entries to the existing [rename] > >section. If the file does not exist, create the file and create a [rename] > >section. > >Add lines of the following format to the [rename] section: > >DestinationFileName=SourceFileName > > > >Both DestinationFileName and SourceFileName must be short filenames. To delete a > >file, use NUL as the value for DestinationFileName. > > > >The system processes WININIT.INI during system boot. After WININIT.INI has been > >processed, the system names it WININIT.BAK. > ><< > > > >So we have exactly what we should do. > > I didn't check the NT version, but I already investigated the W95/98 behaviour > and tried to implement it as described above. > > When I implemented it I noticed a problem with the WritePrivateProfileSection. > If I interpret the MSDN description correctly then this function should write > all the strings in the buffer to the specified section without doing much > processing. Therfore it is possible to create multiple key/value pairs with > the same keyname. This is neccessary in the case of wininit.init because the > files that are to be deleted all have the key NUL=value. With the current > implementation the function uses PROFILE_SetString whch checks for duplicate > keys and overwrites it if a key already exists. If I have time tomorrow I will > write a small test app for Windows to see how it really behaves, but I thin > kthat my interpretation is correct. Otherwise there would have to be some code > in windows that handles the wininit.ini file specifically in order to add the > same key more than once to the file. > Ok I interpret the MSDN paragraph differently. I read it as meaning that the MoveFileEx function would FAIL. if used with that flag. And that it was the Programs responsibility to write to the WinInit.ini file. In my experience with installers this has been the case. So there is not alot wine has to do, just do a version check and if in Windows 95/98 mode fail. I dont think it is proper for the function to do the writing to wininit.ini. > >This i have seen alot, andreas (and others) are working on a utility that will > >process this wininit file. I have talked to alexandre and we both agree that it is > >something that probably should not be in wine itself. > > Why not? In Win98 there is a Wininit.exe that surely will do this because > certain files can't be moved when windows is already running. Since Wine > doesn't have this restriction I added the code to process this in the startup > somewhere after "if(isbootthread)" because I thought it appropriate there. The problem is sort of two fold. #1) this is not processing you want to have happen every time wine is started. Only after a reboot or when signaled to do so. There is alot of reboot / windows startup processing that happens (WinInit.ini, RunOnce etc..) and it is best to keep all that processing together. So wine startup starts to get bigger and messy. #2) Wine does load a number of libraries on boot and if it is one of those libraries that is to be moved then MoveFile will fail. Additionally because the library has already loaded, even if you move the new library into place you would still be using the old version. This would be devastating for programs that run after an install to register new version of dlls. Take a look at andreas' utility he sent out. It has alot it does but you can see how the wininit.ini processing works. It is also a very easy (maybe 1 hour) project to write up a smaller winelib/unix utility that does the same if that is all you need for you particular situation. -aric

Jan. 31, 2002

Re: ROTD (Rant Of The Day): patches

by Francois Gouget

On Thu, 31 Jan 2002, Dimitrie O. Paun wrote: > Guys, > > I've come to _hate_ diffs attached as Application/OCTET-STREAM. Can you > please, Please, PLEASE, attach them as Text/PLAIN? Another issue which is dear to Alexandre :-) When I send a patch with netscape and then read the email in pine, I see the email and the attachement right below it. When I send a patch with pine, I have to use V, select the attachement and pine forks an external pager (more/less/whatever). That's fine too but slightly less practical. I am not sure what is the difference between the two. I believe it has to do with one being a MIME attachement while the other would be... I don't know what. And Alexandre once said he would like it if my attachements were more readily accessible (in emacs). So if anyone has tips for configuring pine so that it makes nicer attachements... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ It really galls me that most of the computer power in the world is wasted on screen savers. Chris Caldwell from the GIMPS project http://www.mersenne.org/prime.htm

Jan. 31, 2002

Re: Microsoft Visual C (MSVC) compabillity

by Francois Gouget

On 31 Jan 2002, Alexandre Julliard wrote: > Patrik Stridvall <ps(a)leissner.se> writes: > > > All of the forms: > > > > (1) void WINAPI (*foo)(void); > > (2) void (* WINAPI foo)(void); > > (3) void (WINAPI *foo)(void); > > > > Seems to work with gcc. Even with gcc 2.7.x. > > I believe the problems were rather with g++. In my 2.95.4 version, > case (2) still doesn't work (well it compiles but generates wrong > code). Case (3) works though, so that sounds like the way to go, I'll > apply your patch. Yes, g++ is the culprit here. IIRC I did some changes about one year ago because of g++ (maybe going to 1 or 2). But in any case I would consider it a bug with g++, hopefully they will fix it (either in 2.95.5 or 3.0.x). -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

Jan. 31, 2002

Re: DESTDIR support for make install

by Alexandre Julliard

Bernhard Rosenkraenzer <bero(a)redhat.de> writes: > wine currently doesn't support the DESTDIR flag commonly used by > packagers. The patch I've attached fixes this. Could you explain this a bit more? Why can't you use the existing $prefix to do the same thing? -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: Fix for MoveFileExA

by Gerhard W. Gruber

On Thu, 31 Jan 2002 20:25:32 +0100, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: >Please, please, please not even more duplication ! >I really don't want to know how many times wininit.ini stuff has been >implemented/semi-implemented/... I didn't knew that there is already something. >If you *really* want to do some stuff, then get >http://home.nexgo.de/andi.mohr/download/winebootup.tar.bz2 >and start improving its wininit.ini handling >(this needs improving, AFAIK). OK. I just downloaded it. I hope I know how to open bz2. :) >Questions ? Just ask. Why is the To: field or the Reply-To: not set to the mailinglist instead of the poster? -- Bye, Gerhard If you think education is expensive, try ignorance.

Jan. 31, 2002

Re: Microsoft Visual C (MSVC) compabillity

by Alexandre Julliard

Patrik Stridvall <ps(a)leissner.se> writes: > All of the forms: > > (1) void WINAPI (*foo)(void); > (2) void (* WINAPI foo)(void); > (3) void (WINAPI *foo)(void); > > Seems to work with gcc. Even with gcc 2.7.x. I believe the problems were rather with g++. In my 2.95.4 version, case (2) still doesn't work (well it compiles but generates wrong code). Case (3) works though, so that sounds like the way to go, I'll apply your patch. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

ROTD (Rant Of The Day): patches

by Dimitrie O. Paun

Guys, 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 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 -- exit Pine -- start vi to actually view the thing -- restart pine... Just to view a Application/OCTET-STREAM attachment. 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. -- Dimi.

Jan. 31, 2002

Re: Pajama Sam's unmanaged window

by Alexandre Julliard

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Hmm. I thought SetWindowLong worked differently than SetClassLong. Weird > stuff... Yes it does, you are right my explanation was more for SetClassLong than SetWindowLong. Basically SetClassLong will affect all windows created with a given class, SetWindowLong will affect a single window, and creating a new class + GetClassLong on the old one will affect all windows created with the new class but not those created with the old class. The nice thing with the Windows API is that everything is so straightforward... -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2002

Re: Pajama Sam's unmanaged window

by Ove Kaaven

On 31 Jan 2002, Alexandre Julliard wrote: > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > 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? > > That's if you want to subclass all windows of a given class. Hmm. I thought SetWindowLong worked differently than SetClassLong. Weird stuff...

Jan. 31, 2002