Re: Bug in MoveFileEx
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
Re: Bug in MoveFileEx
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. > > > >
Re: DESTDIR support for make install
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
Re: Fix for MoveFileExA
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
Re: Pajama Sam's unmanaged window
"Ove Kaaven" <[EMAIL PROTECTED]> 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.
Re: ROTD (Rant Of The Day): patches
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
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 GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
msg07362/pgp0.pgp
Description: PGP signature
Bug in MoveFileEx
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.
Re: Bug in WritePrivateProfileSection
On Thu, 31 Jan 2002 23:38:05 +0100, Andreas Mohr <[EMAIL PROTECTED]> 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.
Re: DESTDIR support for make install
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 <[EMAIL PROTECTED]> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Re: ROTD (Rant Of The Day): patches
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 <[EMAIL PROTECTED]>
I found out that "pro" means "instead of" (as in proconsul). Now I know
what proactive means.
Re: Bug in WritePrivateProfileSection
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 MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: DESTDIR support for make install
On Thu, 31 Jan 2002 13:09:28 -0800, Alexandre Julliard wrote: > Bernhard Rosenkraenzer <[EMAIL PROTECTED]> 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
Re: DESTDIR support for make install
Joerg Mayer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: DESTDIR support for make install
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 <[EMAIL PROTECTED]> I found out that "pro" means "instead of" (as in proconsul). Now I know what proactive means.
Re: Fix for MoveFileExA
On Thu, 31 Jan 2002 15:36:55 -0600, Aric Stewart <[EMAIL PROTECTED]> 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.
Bug in WritePrivateProfileSection
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.
Re: Fix for MoveFileExA
On Thu, 31 Jan 2002 20:25:32 +0100, Andreas Mohr <[EMAIL PROTECTED]> 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.
Re: ROTD (Rant Of The Day): patches
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 Oops (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.
Re: ROTD (Rant Of The Day): patches
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 [EMAIL PROTECTED]http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.
Re: ROTD (Rant Of The Day): patches
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.
Re: ROTD (Rant Of The Day): patches
> 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
Re: ROTD (Rant Of The Day): patches
"Dimitrie O. Paun" <[EMAIL PROTECTED]> 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 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 [EMAIL PROTECTED]
Re: ROTD (Rant Of The Day): patches
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 [EMAIL PROTECTED]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
Re: treeview.c
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 <[EMAIL PROTECTED]> 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[EMAIL PROTECTED] > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > - Tel. 06151 162516 Fax. 06151 164321 --
Re: Microsoft Visual C (MSVC) compabillity
On 31 Jan 2002, Alexandre Julliard wrote: > Patrik Stridvall <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Re: Fix for MoveFileExA
"Gerhard W. Gruber" wrote: > > On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart <[EMAIL PROTECTED]> 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
Re: DESTDIR support for make install
Bernhard Rosenkraenzer <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: Microsoft Visual C (MSVC) compabillity
Patrik Stridvall <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
ROTD (Rant Of The Day): patches
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.
Re: Pajama Sam's unmanaged window
Ove Kaaven <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: Pajama Sam's unmanaged window
On 31 Jan 2002, Alexandre Julliard wrote: > Ove Kaaven <[EMAIL PROTECTED]> 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...
Re: Pajama Sam's unmanaged window
Ove Kaaven <[EMAIL PROTECTED]> 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. If you just want to create your own menu windows but not change the existing menus, you would create a new class with a new name, and then chain down to the menu window proc for any unhandled message. -- Alexandre Julliard [EMAIL PROTECTED]
Re: SetupAPI (dll)
Dear Andreas, > So just go ahead immediately :) I'm right on it. A Simple stupid question. Is there a simple way to read a line from a HANDLE or a unixhandle? I've looked a bit at ReadFile (file/file.c) but I'm lazy, so if there is a better way :) /Stefan
Re: mingw32 port and cygwin
"Steven Edwards" <[EMAIL PROTECTED]> writes: > The last major thing will be the spec and def differences. Because we > are compiling with mingw and making windows dlls using dlltool, we need > to easily convert from specs to defs. I was going to write a shell > script or a simple c program that did this but if anyone has a more > elegant solution please feel free to suggest one. I'd suggest making winebuild generate the .defs; this way you don't need to write a new .spec file parser. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Pajama Sam's unmanaged window
On Fri, 1 Feb 2002, Dmitry Timoshkov wrote: > "Ori Pessach" <[EMAIL PROTECTED]> 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?
Re: CreateProcess API - undocumented use
On Thu, Jan 31, 2002 at 04:54:55PM -0200, Ricardo wrote: > > Hmm, so you mean some program launches another program, passing a value > > in STARTUPINFO.dwFillAttribute, right ? > > If so, how does the launched process retrieve the STARTUPINFO content > > in your case ? > > It's writen a file with a random name that's read by the second program. > > > Wine certainly doesn't pass the STARTUPINFO strut content to program > > space yet; it's simply being used for initializing certain aspects of > > the new program. > > What I saw was that I run the first program, it write the file and wine > closes, then it restart with the other program, but it can't read the file > because it lost the file name, isn't it? It's the same error I get when I > run the second program alone. 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 ! -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Fix for MoveFileExA
On Thu, Jan 31, 2002 at 07:50:53PM +0100, Gerhard W. Gruber wrote: > On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart <[EMAIL PROTECTED]> wrote: > >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. 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/... 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). Questions ? Just ask. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Fix for MoveFileExA
On Thu, 31 Jan 2002 07:52:55 -0600, Aric Stewart <[EMAIL PROTECTED]> 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. >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. -- Bye, Gerhard If you think education is expensive, try ignorance.
Re: CreateProcess API - undocumented use
> Hmm, so you mean some program launches another program, passing a value > in STARTUPINFO.dwFillAttribute, right ? > If so, how does the launched process retrieve the STARTUPINFO content > in your case ? It's writen a file with a random name that's read by the second program. > Wine certainly doesn't pass the STARTUPINFO strut content to program > space yet; it's simply being used for initializing certain aspects of > the new program. What I saw was that I run the first program, it write the file and wine closes, then it restart with the other program, but it can't read the file because it lost the file name, isn't it? It's the same error I get when I run the second program alone. thanks for the help Ricardo
Re: CreateProcess API - undocumented use
On Thu, Jan 31, 2002 at 02:55:28PM -0200, Ricardo wrote:
> > There is no such thing as a dwFileAttribute of CreateProcess.
> > Which parameter are you talking of ?
>
> CreateProcessA has a parameter called dwFillAtribute, not dwFileAttribute,
> sorry, and I saw at the Wine docs
> (http://www.winehq.com/WineAPI/CreateProcessA.html) that it's not
> implemented yet.
Well, your info is confusing. dwFillAttribute is not a CreateProcess
parameter. Instead it's a variable inside the lpStartupInfo struct,
which is a CreateProcess parameter.
Wine readily says:
if (lpStartupInfo->dwFlags & STARTF_USEFILLATTRIBUTE)
FIXME("(%s,...): STARTF_USEFILLATTRIBUTE %lx ignored\n",
name, lpStartupInfo->dwFillAttribute);
> ps.: Is WineAPI updated? if not where can i get it updated? Thanks
I don't think it's updated.
Hmm, so you mean some program launches another program, passing a value
in STARTUPINFO.dwFillAttribute, right ?
If so, how does the launched process retrieve the STARTUPINFO content
in your case ?
Wine certainly doesn't pass the STARTUPINFO strut content to program
space yet; it's simply being used for initializing certain aspects of
the new program.
--
Andreas MohrStauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Pajama Sam's unmanaged window
"Ori Pessach" <[EMAIL PROTECTED]> 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. -- Dmitry.
Re: mingw32 port and cygwin
"Steven Edwards" <[EMAIL PROTECTED]> wrote: > Ok, well the first problem might just be an issue with me, due to a lack > of experience with autoconf and automake. I'm using msys and mingw to > try and ./configure wine. I can run ./configure with some other software > so I think I have everything setup right but I seem to be missing > something. Here is the ./configure output. > > sh-2.04$ ./configure > : command not found > : command not found > : command not found > : command not found > : command not found > '/configure: line 71: syntax error near unexpected token `do > '/configure: line 71: `do > sh-2.04$ > > It seems like this is some sort of bashism because it works fine if I > use bash from cygwin under my msys install. The error above looks very familiar for me from my early experience with Wine. It seems like an \r\n vs. \n EOLs issue. -- Dmitry.
Re: Compilation errors for Freetype support
"Huw D M Davies" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Thu, Jan 31, 2002 at 04:34:02PM +, Huw D M Davies wrote: > > I'll add a configure test for the trig functions and disable FreeType > > support if they're not present - there are other issues with 2.0.1 > > that make it unusable anyway. > > How does this look? > > Huw. > Seems reasonable to me (but I count myself as a total newbie in all this autoconf stuff)(Heck, I'm still a newbie in all this Linux stuff). Bill
Re: Compilation errors for Freetype support
On Thu, Jan 31, 2002 at 04:34:02PM +, Huw D M Davies wrote: > I'll add a configure test for the trig functions and disable FreeType > support if they're not present - there are other issues with 2.0.1 > that make it unusable anyway. How does this look? Huw. Index: configure.in === RCS file: /home/wine/wine/configure.in,v retrieving revision 1.253 diff -u -r1.253 configure.in --- configure.in2002/01/29 18:09:47 1.253 +++ configure.in2002/01/31 15:24:05 @@ -420,11 +420,13 @@ freetype/internal/sfnt.h) AC_TRY_CPP([#include #include ], -AC_DEFINE(HAVE_FREETYPE_FTTRIGON_H, 1, - [Define if you have the header file.])) +[AC_DEFINE(HAVE_FREETYPE_FTTRIGON_H, 1, + [Define if you have the header file.]) +wine_cv_fttrigon=yes], +wine_cv_fttrigon=no) CPPFLAGS="$ac_save_CPPFLAGS" dnl Check that we have at least freetype/freetype.h - if test "$ac_cv_header_freetype_freetype_h" = "yes" + if test "$ac_cv_header_freetype_freetype_h" = "yes" -a "$wine_cv_fttrigon" = +"yes" then AC_DEFINE(HAVE_FREETYPE, 1, [Define if FreeType 2 is installed]) wine_cv_msg_freetype=no @@ -1435,10 +1437,11 @@ then echo echo "*** Note: Your system appears to have the FreeType 2 runtime libraries" - echo "*** installed, but either 'freetype-config' is not in your PATH or" - echo "*** you do not have the FreeType include files. Install the" - echo "*** freetype-devel package (or its equivalent on your distribution) to" - echo "*** enable Wine to use TrueType fonts." + echo "*** installed, but either 'freetype-config' is not in your PATH," + echo "*** you do not have the FreeType include files or you have a version" + echo "*** of FreeType lower than 2.0.3. Install the freetype-devel package" + echo "*** (or its equivalent on your distribution) to enable Wine to use" + echo "*** TrueType fonts." fi echo
Re: CreateProcess API - undocumented use
> There is no such thing as a dwFileAttribute of CreateProcess. > Which parameter are you talking of ? CreateProcessA has a parameter called dwFillAtribute, not dwFileAttribute, sorry, and I saw at the Wine docs (http://www.winehq.com/WineAPI/CreateProcessA.html) that it's not implemented yet. Thanks, Ricardo ps.: Is WineAPI updated? if not where can i get it updated? Thanks
Re: treeview.c
> "Aric" == Aric Stewart <[EMAIL PROTECTED]> 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[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: CreateProcess API - undocumented use
> Run with debugmsg and show us what you think is going on. > > Bye > -- > Uwe Bonnes[EMAIL PROTECTED] > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > - Tel. 06151 162516 Fax. 06151 164321 -- Sorry, I've attached it now. There's 2 fies - wine.log and wine2.log. The 1th one is the main program, the one that calls the other. As wine close and start over to run the other program, i've run the second program alone. The point is that: 1. when wine closes it loose the configuration; or 2. the use of that API is not well documented and was not ported The main program is a logon screen. it gets the password, compare with an MS-SQL database and writes a file that have the parameters needed to the other program start - as the evaluation period. The second program is just an interface to call other programs. Thanks Ricardo ps.: I don't matter if I have to read the fonts, but I'm not a programer so if anyone have a clue... begin 666 w.tgz M'XL(`!$I63P``^U]:V_;N-)P/Y]?P6>Q0%J@#219DF4?] '27-K@R29%DFZW M0(% UB75J6,9LM.F[Z]_25THRJ(DWBPY/39PSB:I.3,DAW/C<.9GM @.Y_'] MBRU^-%W3;--\H66?ZG\-:VSJ\.>Q:=B&,3(U`WY?AS^\`-HVB2H^CZNUFP#P M(HGC==OWNO[]F7[6B>L%TS":!].S\XO3NY/X:ADLSN#O( GN#WUW#:[.[JY/ MCT[0?V\^'%V?WAU?_?7QZ!;\BV$LVN'\>P^Q_PB_^3Y8_Y7^A+YWZ3X$1^!? M/]UD08=SD ,Z`(MX#<+X<>&#. &K;VX2+>[!CRB>N^LH7K2 >)F#>#6%5*T? MDP5X"SZD7SJ]OKZZ!D&2Q,E;8'232]/+T^OSX^SU4LQ9NN7K>;'T\N[TW_.;V[/+]^#*O*/IW<7 ML>N?/[CW`9C#G]!K!*O`!U@T"%>;Y?83>X53X)YG$.W1GC)PQ&&[I>4FP8- M.&+WNWDT2]SD5\K[D(<7:W\^/X3_2QEP9.O62$.T63Z+>&$[.']=G7R")Q2. M1T?O*O&#!**/OZ/IA5#D'$^__H3#5[]6Z^#AZ]7)N^.1<7AR<:$(_7VPOH.+ M>9=./TZQKP(W\;XA_ <9N@,0+<#1Z.R[X !O^ &6 M6^E>OP8>5 'KMT8WS\3^S(,S()C&<3W(-)87UIB&3MM%E:;&!2I(I$'NB1T? MPF2]RF;;"S_F^+; D NHSG] ,0&W[:!QC@=-JKAQA&)=S+CZ[TK4LHV\#@S>,[!BEM#Z M016\A<'[&+SC"J\-J?<1>*R>;;0)FRLOH?D1\+ $3C$K9#0_XF8-0[8^PW/5G"VJL#U$CB6"F-3BYFCQ(5Z"D00%? MD@LX"&>2;(69,^.H!F]Y-TZ,V7UBR+7-3XP!Y2TZ,6%=];,Z\4V;A]>.`GMG MMG*TBUMI=6_EO5_=1SU,@S%CW1UHK3%!Y4*GM QZ9EKX<5 &8&!,MPH@4YI#R$!N-1(ZQ)29N7=0S<# QN.=9.-!],+[ MDQH/5Y3[KIXMNO2%[M#')/:"U>IHO7:];^!E2<]K[4E_!=Z F]NCZUO&T>7- MF,AHK'.[!Y\OHC6*)!)C/EY?'9_>W-P=W=X>'7\H0!P?;88!-R&4][X-(*Y/ M;S]=7P)==!:GER?M%!"K)CD)Q_743**^D4VSJ(\EA+ (%Y!R4F1\:7:)C,;& MN\A@TL@6&4\:PQQGH#*,E8.P9/K@+OQYH-O@9:8)7O$%?;XGB_G(L0^#IZ"7 M*$^.3SH^F-$&IUV+PA S:@J[=*S9SKA.38J[I)^8+'WC*VNU87R1*Y41H.EZ M<%B%IF=.S"I6O],@!G*,MU"N+L#V]UK>YQ4$]> M`9[G,(TUSP_W<]S/\;>9X\\EA+#BM(^R0;THB S5%A5$CN#9*HBV#6Q3$,7" MY@K"Z31Q' $3Q^$W<> 037/J0<9&3F\*AM$`ZW8]P-)\A"9C30O8`&M.?:=V MG6)G5REN" 0$CJ)H!LTE[0QH5/Q@N9 &NI55,Q.:<]XYDS(&",&I.C;H-F"(G8)^_K.#9UX<'J_3[?8$W&Z/U>W>;C+Z.K*"=IP:V@Y0>7AR'*"'&-LHIP@ MQ[%5Y 019Z\@L05R7=67XU^_7$3S5XP74,2P#7V/H;1<0/&)O@S7%'QV4[=H M"OX\.;_Y>''T!?QPD\B=P46)[A=Q$OBOP>,J%8%3[5 [`*MEX$5A!-<.RBPO M7H31??K\@T^L^]%J.7=_]2W%<[1;M$0*#,]*9I>&2$X^OQV"5S8W0X).,R00 M,$."#C.$:L.GPJ'Q1'%:\;2C73/D^]GN1BG5X+*=)4&00TT7C8PC[DCW MYB5D@UW;A(XCI.2%AJG/MKP`G_D70)=8@,^\"V T63F\?++_UDY]JR&BJ/F* M(HKU3*/.R$@EN8D[56?H/-#)OZ!],4W-X.GU>K[\[$;KLS@Y3J)U! _A3?ZX ML7CDF%K(H6_X&O@C6<\/O2E8!C-HX7C?_P`_X5BPCAY0/8W']6MT*#.3Y*6M M(0BO0+AZJQEZ(>OK[XNO+L\O_ZR^)2Y^^7Q]?GM:>UE,_)Y]@?K4F(;HZM/M MGTJ MX?L/,-1PYFT'+I.WB3S]B3S$">^J68BE%S"SGD0*:R2T[!'BJ91SZI5 M8'K5&/7PJQ?/XN7ZT OOV]_82S%KF>!Z^P%!8_#U6G)N&V"T+C M<[:-EK*" M&[EQ F\0,X(!?T`+Q\?W$*#"8=DR;B2LVL M%#7EA83LPH2RVT1X57*T9+Z>%"V$.2*[1-\$:84JC M)$$"OJ46/K!-5!YC!06U!KY%]]_@?^(DNH^@E4D.OH:6;5J:$WX_+9PVL[VQ M1OYFF2!=)!Z4NN'P(K4V0S%6!QNC/DQ"X;DHK`]GO2JGVGVN9]2Q/T>LA^HR:8BW$ MC4QU:,>+Q\"[#L+C]&YF8UB2_WT*&O: '$J<,W)DPUS)D23SDT.-[J&D1TX. MG0CL^,FI@AW?!-*ZXV?SQ]4W>(HAW2L`'AW\,U MD$0PD;J;R/U 94EK#V&TB(;(64L1;[^B*6VJ;>5,:=_G,M%%XY!-M+:&)/FR M]H@%2*G,8;W[='X!:1\9=_X\7@8+X+D+U"XC_?EP%8-Y-$LY)R^'!S"<*?JG M[+=5/*V,0RTVT+7/[#_0W$OG.@67,5@]0D64^AAIGDT"_S%.?G',;16_*=*M MV&9'AW;F0AI\M!^(.QLRK4J(_\[;?&A/N:UG-+'0YMDXTRS[\.3HMH<[+"KJ MR'_:$FIZ0,71^&(X3AH+&7NZKP%+-XH(AS-F#N&,;3Z,\/L8(PKZ\&,LYZAK MALD]S710@=5V!L'J_?=@'6O\6/EYMX+2$6 E0S/9`I 95FUFS5Q/WY@J,S.5 MAT8?\1P;B'9DA-[&=+5>HY&;4&YT9_S/$"8,E9 MFS2-DV\T:AI';+G!5,.V MM <=]5R_OLE^% PZHJ$XZ)C^D(:3TEBA?-A13R-194BSWA="(O"(H)1M(6C M^?LVE'$V! ;'V6PJZ0,&V@2B0_T0UEFFSAJ"JJXR=8,0Q5"F;LP"?B/ URSV MJG*#.5<'`^ *[9'C)%Y!<*[\9H H&-5>?8J&!*D+H2IO:=M6EH YV8KRK_C$*,4]&B Y"F=<$84)](116*6S$Q4F:C@.56, ME_G,_!YXV4]K_V=UB)/*J4[1`,F3JFN<"A4-D#ZK_ *_,E7ALZH4+\>9^1WP M"9=$;=X&=TQ#L0A0,PU(%.HNF;*U.6]EI>D7/O#@'"&&UGO/0"@Q]VZ&&+PF@6%*FR$&KY-B:-)F2#E/ M=O5(3E7T"*G%RVX._!9XN\P0R@DRASN\9O^G=\2F!LNE'AGRIY?7<3$M7C93]%O@7?<'K3?L=([EMAIL PROTECTED]@15:EYXA MGE0E%ZL4G"R!E'FV.5XT75MFNC(!'^'I\F]NCA=-5R)ECM6$+]$V6O B^8$# MI"3^%C>KNSK3D:&SJ:/G/U5=M]@.ZDY/5=D5_:XH[=_K6\S;P>#X:,9D,*<+ MX>[=ZS)Y-;E)O[K17'9U:O(:2R8]9L*%4^!*P6PP6K0)NQ>B%*_++ I_$[P4 ME=-QAD;]O[DBT]2RI<^OQ1NIL>CW%5PXF#G.T>^! ME]VYD])#%:0S$:7 [E&:V*/] M&3<00VUJ$V[,FRX\%^8R_<<:C5B=S=SRT""N$,JMB56B9F=M*1$MRMH6\TWK M)EZTTC*L76(VQXZA\>(.9%B[Q#T:C2<&+VH9UB:FS':GBBB2RS M.N7HB3"TK-AB1ZHJ@C/2!1+6Y6XI.%"JNRW@0JHJ9L^#5%GDG >I5!Z(*%)E MHI"*E)JN=O).&QD3DY(FUWM^'TD*>XY?\P2J;G-S2MWF8S:DSF:FE^G@?$%- M6N1Z/W _<#]P]P?
Re: Pajama Sam's unmanaged window
On Wednesday 30 January 2002 17:39, Ove Kaaven wrote: > On Mon, 28 Jan 2002, Ori Pessach wrote: > > - Changed is_window_managed()'s default return value to TRUE > > Perhaps remove the cruft this leaves behind, then. Of course. > > - In tooltips.c, TOOLTIPS_NCCreate(), I set the WS_EX_TOOLWINDOW bit in > > the tooltip's dwExStyle field. This, I believe, is the right thing to do > > Then I suggest you submit this piece of the patch to wine-patches > independently of the rest of this. Will do. > 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. -Ori Pessach _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Compilation errors for Freetype support
On Thu, Jan 31, 2002 at 07:32:53AM -0800, Bill Medland wrote: > So what ought to be done in the code? > 1. #else #error "This requires freetype 2.0.3 or later" > 2. #else zero degrees> #endif > 3. ifdefs around the use of FT_Angle etc to provide an alternative method of > achieving it or not supporting ot. > > I am interested because I am still trying to get a feel for the typical > thinking in Linux development where there are more independent libraries and > they tend to change more frequently, adding support as they go. Firstly sorry about the delay in replying to these problems; I've had problems with my subscription to wine-devel, things seem to be back to normal now though (thanks Andi!). I'll add a configure test for the trig functions and disable FreeType support if they're not present - there are other issues with 2.0.1 that make it unusable anyway. If you're upgrading then go straight to 2.0.6 - there's a bug in earlier versions that messes up inter-character spacing. Huw.
Re: CreateProcess API - undocumented use
Hi ! On Wed, Jan 30, 2002 at 04:35:56PM -0200, Ricardo wrote: > hi, > I have a program that use the CreateProcess API with dwFileAttribute as a > parameter. But not to use in the command line. It's used to write some data > into a file and then another program read that file. But this isn't working. > I'm not a programmer, I'm just testing the program. Does anybody know how > can the program be changed, or wine patched, to solve this? > thanks, > Ricardo There is no such thing as a dwFileAttribute of CreateProcess. Which parameter are you talking of ? If this is a problem (and it probably is), then *of course* Wine has to be fixed, not the program. -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Compilation errors for Freetype support
> So what ought to be done in the code? > 1. #else #error "This requires freetype 2.0.3 or later" > 2. #else zero degrees> #endif > 3. ifdefs around the use of FT_Angle etc to provide an alternative method of > achieving it or not supporting ot. Do autoconf checks for the presence of these functions. If they can be implemented (or stubbed) easily, add a stub/implementation between ifndefs. If not, do not compile in the feature at all. Ciao, Marcus
Re: SetupAPI (dll)
On Thu, Jan 31, 2002 at 03:39:11PM +0100, Stefan Görling wrote: > Hi everybody, > > Is anyone working on implementation of SetupAPI? Otherwise I'm thinking > about taking a look at it... Not at the moment. I used to implement some parts of SETUPX (and thus some SETUPAPI stuff, too), but I don't have time for "real" stuff right now. So just go ahead immediately :) -- Andreas MohrStauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604http://home.nexgo.de/andi.mohr/
Re: Compilation errors for Freetype support
"Andriy Palamarchuk" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Trying to compile today's Wine I get errors: > > freetype.c: In function `WineEngGetGlyphOutline': > freetype.c:947: `FT_Angle' undeclared (first use in > this function) > freetype.c:947: (Each undeclared identifier is > reported only once > freetype.c:947: for each function it appears in.) > freetype.c:947: parse error before `angle' > freetype.c:993: `angle' undeclared (first use in this > function) > freetype.c:1003: warning: implicit declaration of > function `FT_Vector_Rotate' > freetype.c:1059: warning: implicit declaration of > function `FT_Cos' > freetype.c:1060: warning: implicit declaration of > function `FT_Sin' > > Huw, > these functions calls were introduced to the file by > your patch, applyed on Jan 29, 2002. > > I believe the problems are because of differences > between freetype versions. The problem occurs on > freetype 2.0.1, but according to thread "Prob with > freetype..." is fixed after upgrading to 2.0.3. > > Regards, > Andriy Palamarchuk > > __ > Do You Yahoo!? > Great stuff seeking new owners in Yahoo! Auctions! > http://auctions.yahoo.com > > > So what ought to be done in the code? 1. #else #error "This requires freetype 2.0.3 or later" 2. #else #endif 3. ifdefs around the use of FT_Angle etc to provide an alternative method of achieving it or not supporting ot. I am interested because I am still trying to get a feel for the typical thinking in Linux development where there are more independent libraries and they tend to change more frequently, adding support as they go. Bill
SetupAPI (dll)
Hi everybody, Is anyone working on implementation of SetupAPI? Otherwise I'm thinking about taking a look at it... Best Regards, Stefan Görling
Compilation errors for Freetype support
Trying to compile today's Wine I get errors: freetype.c: In function `WineEngGetGlyphOutline': freetype.c:947: `FT_Angle' undeclared (first use in this function) freetype.c:947: (Each undeclared identifier is reported only once freetype.c:947: for each function it appears in.) freetype.c:947: parse error before `angle' freetype.c:993: `angle' undeclared (first use in this function) freetype.c:1003: warning: implicit declaration of function `FT_Vector_Rotate' freetype.c:1059: warning: implicit declaration of function `FT_Cos' freetype.c:1060: warning: implicit declaration of function `FT_Sin' Huw, these functions calls were introduced to the file by your patch, applyed on Jan 29, 2002. I believe the problems are because of differences between freetype versions. The problem occurs on freetype 2.0.1, but according to thread "Prob with freetype..." is fixed after upgrading to 2.0.3. Regards, Andriy Palamarchuk __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com
Re: Fix for MoveFileExA
My turn to chime in, I have done a fair bit of reboot processing stuff.. first here is what msdn says >> If the dwFlags parameter specifies MOVEFILE_DELAY_UNTIL_REBOOT, MoveFileEx stores the locations of the files to be renamed at reboot in the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations The function fails if it cannot access the registry. The PendingFileRenameOperations value is of type REG_MULTI_SZ. Each rename operation stores a pair of NULL-terminated strings. The system uses these registry entries to complete the operations at reboot in the same order that they were issued. For example, the following code fragment creates registry entries that delete szDstFile and rename szSrcFile to be szDstFile at reboot: MoveFileEx(szDstFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT); MoveFileEx(szSrcFile, szDstFile, MOVEFILE_DELAY_UNTIL_REBOOT); The system stores the following entries in PendingFileRenameOperations: szDstFile\0\0 szSrcFile\0szDstFile\0\0 Because the actual move and deletion operations specified with the MOVEFILE_DELAY_UNTIL_REBOOT flag take place after the calling application has ceased running, the return value cannot reflect success or failure in moving or deleting the file. Rather, it reflects success or failure in placing the appropriate entries into the registry. The system deletes a directory tagged for deletion with the MOVEFILE_DELAY_UNTIL_REBOOT flag only if it is empty. To ensure deletion of directories, move or delete all files from the directory before attempting to delete it. Files may be in the directory at boot time, but they must be deleted or moved before the system can delete the directory. 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. 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. -aric Malte Starostik wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Am Wednesday 30 January 2002 21:41 schrieb Uwe Bonnes: > > > "Francois" == Francois Gouget <[EMAIL PROTECTED]> writes: > > > > Francois> On Wed, 30 Jan 2002, Gerhard W. Gruber wrote: > > ... > > Francois>I believe that Windows stores the list of files to > > Francois> move/delete somewhere in the registry. We should probably do > > Francois> the same... It seems that adding keys in the registry would > > be Francois> better than creating new files in any case. > > > > At least Win95 and decendants store the file in /wininit.ini. > Yes, because registry access isn't available yet when wininit.ini is > handled during booting. That's what happens during the > "Configuration files are being updated" > ... > "Done" > (roughly translated from German, guess you know what I mean) while the > boot logo is displayed. BTW, no idea why they call it "configuration files" :) > Imagine kernel32, advapi or something else is being replaced...can't use the > registry for it. The format of wininit.ini is pretty simple: ever line is like > newname=oldname > and causes the file named oldname to be renamed to newname. If newname > is nul, the file is deleted. > - -- > Malte Starostik > PGP: 1024D/D2F3C787 [C138 2121 FAF3 410A 1C2A 27CD 5431 7745 D2F3 C787] > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8WJWMVDF3RdLzx4cRApncAKCFLIv32C+97uaTRq4UfXpFYFBASQCfezGw > R80SYovvkyrywtu94xj+PnU= > =NmRY > -END PGP SIGNATURE-
