August 2004 - Wine-Devel - list.winehq.org

Re: [wine] Re: config converting problem

by Vincent Béron

Le dim 15/08/2004 à 00:21, David Lee Lambert a écrit : > On Wed, Aug 11, 2004 at 04:45:20PM +0200, Henning Gerhardt wrote: > > Hi Mike, you wrote: > > > >I'm not sure what to do about this, except maybe to add back in support > > >for ${HOME} style vars. It's clear that people are "using" (at least, > > >installing) much older versions than we anticipated. > > > > Personally I would prefer to merge back the support for ${HOME} > > variables because I think many other people have the same problem > > if they want to upgrade wine. > > Not having totally grokked the code, I think this raises an important semantic > issue: if ~/.wine/dosdevices and the config-file's text conflict, which has > priority? Or should Wine read the config-file and then (effectively) overwrite the > settings with the contents of ~/.wine/dosdevices? This won't work if Wine > automatically builds ~/.dosdevices from scratch. Only ~/.wine/dosdevices is used now. The drive sections in the config is used to build dosdevices if it doesn't exist, then it is read back as if existed before. > > It seems that mapping one drive to the user's home directory is a common case, > since many organizations already do this for users via Samba or Netware. As > presently implemented, is there any reason a system administrator shouldn't do > > ( cd /etc/skel ; mkdir -p .wine/dosdevices ; cd .wine/dosdevices ; ln -s f: ../.. ) > > where f (for example) is the drive letter used for each user's home directory, and > then use a shell script to push the change out retroactively to existing accounts? That will probably cause some problems with the way we currently detect whether or not to lauch wineprefixcreate, which is the existence or not of ~/.wine. You should customize your version of wineprefixcreate if that's what you want to achieve (but it won't be applied to existing ~/.wine dirs, that'll need to be taken care of in another manner. Updates to ~/.wine between versions are not very well managed right now in Wine.). Vincent

Aug. 15, 2004

Re: Forcing 32 bit mode in configure

by Steven Edwards

Hi, --- Marcus Meissner <marcus(a)jet.franken.de> wrote: > > Does anybody know how to force gcc to compile in 32 bit mode on 64 > bit > > chips, and if so could they please write a patch? I've seen quite a > few > > posts to end user forums lately saying that people were trying to > compile > > Wine on AMD64 (and failing, obviously). > > I can try. It would be nice to have a configure option or something for 32 vs 64bit mode. I have been playing around with a native port to AMD64 on sourceforges compile farm and have quite a few patches for the headers and other stuff I was planing on cleaning up and submitting. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

Aug. 15, 2004

Re: More winecfg todos

by Mike Hearn

On Sun, 01 Aug 2004 11:12:52 -0400, Chris Morgan wrote: > Here is a patch that recreates the "Global settings" entry in the app defaults > tab if the user removes it. It also fixes some indenting and removes a > while() loop that was inside of another identical while(). > > Mike, it doesn't look like I'll have time test this and I've been sitting on > it for a couple of months. Feel free to do so and submit it to wine-patches. Why not simply prevent it being removed in the first place?

Aug. 15, 2004

Re: More winecfg todos

by Mike Hearn

I guess so - please send this patch to me ASAP as I was planning on hacking winecfg a bit next week (dunno if I'll have time but ...) so it'd be nice if I could work from latest sources. I'm not really convinced that being able to configure these paths is a useful thing but I guess if people want to use a real Windows drive it may be handy. thanks -mike On Sun, 15 Aug 2004 14:29:24 +0000, Jacek Caban wrote: > > You probably want to increase the size of the drive mappings list so it > > fills the tab, currently there is just a lot of empty space at the top of > > the pane now you removed the old stuff. > > I have almost ready patch. I've attached screenshot. Is it a good idea? > > Thanks, > Jacek

Aug. 15, 2004

RE: Windows Default Button Observations

by Zach Gorman

> Once you remembered the current (possibly inactive) default > button in DIALOGINFO, this should come for free. I hope at > most one button can be default in a dialog... In Windows, when you click & hold on a button, each button in the dialog gets sent a WM_GETDLGCODE, presumably to determine whether it is a DLGC_DEFPUSHBUTTON or a DLGC_UNDEFPUSHBUTTON. Any button that returns DLGC_DEFPUSHBUTTON is sent a BM_SETSTYLE to make it non-default (BS_PUSHBUTTON, not BS_DEFPUSHBUTTON). The main issue here seems to be separation of button code from dialog code. It would seem that the dialog code should be responsible for sending the WM_GETDLGCODE messages to the dialog's children, but how is the dialog code told to do this? The only messages the dialog itself receives in response to the LBUTTONDOWN on the button are WM_MOUSEACTIVATE, WM_SETCURSOR, and WM_CTLCOLORBTN. I don't think it is any of these messages that causes the dialog to start un-defaulting its child buttons. Zach

Aug. 15, 2004

Re: Forcing 32 bit mode in configure

by Marcus Meissner

On Sun, Aug 15, 2004 at 02:55:51PM +0100, Mike Hearn wrote: > Hi, > > Does anybody know how to force gcc to compile in 32 bit mode on 64 bit > chips, and if so could they please write a patch? I've seen quite a few > posts to end user forums lately saying that people were trying to compile > Wine on AMD64 (and failing, obviously). I can try. Ciao, Marcus

Aug. 15, 2004

Re: Forcing 32 bit mode in configure

by Adam Petaccia

Wouldn't passing -m32 (if I recall correctly) to gcc tell it to produce 32 bit code? On Sun, 2004-08-15 at 14:55 +0100, Mike Hearn wrote: > Hi, > > Does anybody know how to force gcc to compile in 32 bit mode on 64 bit > chips, and if so could they please write a patch? I've seen quite a few > posts to end user forums lately saying that people were trying to compile > Wine on AMD64 (and failing, obviously). > > thanks -mike > >

Aug. 15, 2004

Forcing 32 bit mode in configure

by Mike Hearn

Hi, Does anybody know how to force gcc to compile in 32 bit mode on 64 bit chips, and if so could they please write a patch? I've seen quite a few posts to end user forums lately saying that people were trying to compile Wine on AMD64 (and failing, obviously). thanks -mike

Aug. 15, 2004

Re: Large memory reporting

by Shachar Shemesh

Ivan Leo Puoti wrote: >Wine will have to unfortunately do the same to achieve 100% compatibility for >all the apps that work on windows only thanks to specific hacks. > > While you are, no doubt, correct that 100% windows compatibility means that we will have to, eventually, do that, I don't think the time is "now". We are not yet confronted with bugs that require detecting what application is currently running and hacking accordingly. >I'm not saying that it's a good solution in this case, but at some point this >sort of stuff will have to be done. > >Ivan. > > Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 15, 2004

dlls/commdlg/fontdlg.c regression

by Gerald Pfeifer

The following change to dlls/commdlg/fontdlg.c revision 1.70 date: 2004/08/14 00:42:35; author: julliard; state: Exp; lines: +2 -5 Jacek Caban <jack(a)itma.pwr.wroc.pl> Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand in FormatCharDlgProcW. causes the following warning with GCC 3.3.2 on FreeBSD 4.10: fontdlg.c:1161: warning: passing arg 4 of `CFn_WMCommand' from incompatible pointer type Would you mind fixing this? Thanks, Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

Aug. 15, 2004