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

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

Re: Windows Default Button Observations

by Ferenc Wagner

Mike Hearn <mike(a)navi.cx> writes: > On Sun, 15 Aug 2004 11:23:07 +0200, Ferenc Wagner wrote: > >> 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... > > http://weblogs.asp.net/oldnewthing/archive/2004/08/02/205624.aspx > > I'm afraid it's possible for dialogs to have more than one > default button. No, there is no hope. :( This fancy feature is definitely worth supporting in Wine. Thanks for the correction. -- Cheers, Feri.

Aug. 15, 2004

Re: Windows Default Button Observations

by Mike Hearn

On Sun, 15 Aug 2004 11:23:07 +0200, Ferenc Wagner wrote: > 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... http://weblogs.asp.net/oldnewthing/archive/2004/08/02/205624.aspx I'm afraid it's possible for dialogs to have more than one default button. That is a good post on management of default buttons in dialog boxes, here's another related to focus: http://weblogs.asp.net/oldnewthing/archive/2004/08/04/208005.aspx#FeedBack thanks -mike

Aug. 15, 2004

Large memory reporting

by Ivan Leo Puoti

> /* work around for broken photoshop 4 installer */ You may have to consider handling this like Microsoft does. If you read trough m$ blogs, you'll find that what microsoft usually does is have all sort of workarounds for broken apps, without them lots of stuff would not run on window xp. To work like windows, wine will have to do the same. For example, at some point m$ found that a game called "The sims" didn't work on recent versions of windows, because it freed some heap memory, and then immediately tried to access it. The M$ guys had to reverse engineering the game to find this out, and then introduced a hack that would make windows compensate for the apps bug. The game did work on previous versions of windows. M$ has it's code full of this stuff, they give priority to m$ apps, followed by stuff from big vendors like IBM, adobe, macomedia and so on. 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. 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.

Aug. 15, 2004

Re: Large memory reporting

by Dmitry Timoshkov

"Shachar Shemesh" <wine-devel(a)shemesh.biz> wrote: > If so, is there a way for me, when at the heap.c code, to know whether > that flag was set on loading the current process? (copied from dlls/ntdll/loader.c): PEB *peb = NtCurrentTeb()->Peb; IMAGE_NT_HEADERS *nt = RtlImageNtHeader( peb->ImageBaseAddress ); if (nt->FileHeader.Characteristics & IMAGE_FILE_LARGE_ADDRESS_AWARE) { return full_address_range_of_the_application; } else return 2Gb_of_adderess_space; or even better reimplement GlobalMemoryStatus via VirtualQuery and leave all system dependent code to ntdll.NtQueryVirtualMemory. -- Dmitry.

Aug. 15, 2004

Re: Windows Default Button Observations

by Ferenc Wagner

"Zach Gorman" <zach(a)archetypeauction.com> writes: > My impression is that (1) could be handled by remembering > the default button (which, as Krishna Murthy has shown, is > not the same as the default button id) in the DIALOGINFO > structure. > > Number (2), however, is more difficult. When a button > receives the capture, it can send a BM_SETSTATE to itself > easily enough to make itself a DEFPUSHBUTTON, but how does > it determine which other buttons to query and make > non-default as necessary? 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... -- Feri.

Aug. 15, 2004

Large memory reporting

by Shachar Shemesh

Hi list, I have a Windows program that tries to find out how much memory it has at its disposal using "GlobalMemoryStatus". The machine has 4GB of physical memory and about 100MB of swap. GlobalMemoryStatus returns 2GB of physical memory and 0 available swap. It seems the problem is at dlls/kernel/heap.c, around lines 1150. First we make sure we never report more than 2GB of total or available memory, and then we make sure that we never report more than 2GB combined available physical+swap memory (which effectively zeros the available swap if there is more than 2GB of available memory). The comment next to this is: /* work around for broken photoshop 4 installer */ While I understand the need for the workaround, this significantly reduces the usefulness of the whole function. My question: Can we make these two rounding conditional on the application not wishing to work with more than 2GB? I.e. - can we let applications that were linked with LARGEADDRESSAWARE see the true state of the machine? If so, is there a way for me, when at the heap.c code, to know whether that flag was set on loading the current process? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 15, 2004

Re: console message encoding

by Eric Pouech

Vitaly Lipatov a écrit : > Is it known that console message printed to output in wine > internal encoding (OEM?), not in locale encoding. Is it bug or > just needed coding right behavior? > For example, I have koi8-r as locale encoding, cp866 as OEM CP > and cp1251 as ANSI CP. In windows, the default CP for consoles is OEM. This can be changed. The CP you described are windows' or Linux ones ? A+

Aug. 15, 2004

Re: Debugger crash

by Eric Pouech

Mike Hearn a écrit : > Hi, [snip] > Eric, any ideas? I don't understand what this code is doing. I think that Dimitry's patch fixed it, doesn't it. A+

Aug. 15, 2004

Re: wave tests patch

by Eric Pouech

Francois Gouget a écrit : > Francois Gouget wrote: > [...] > >> Anyway, assuming that we need to round up I propose to modify the >> implementation as in the attached patch. The advantage is that it does >> not rely on ceil(). In fact it doesn't even use floating point >> arithmetic so we cannot get any rounding error. > > > The code that performs TIME_SMPTE calculations is the same for all > drivers. It is even the same for the input and output devices (assuming > the SMPTE rounding is the same for both) which means it is currently > duplicated 12 times. > > Would it be better to have waveOutGetPosition() in winmm.c simply query > either the TIME_MS from the underlying driver and then perform the > conversion? This would be something like: > > ... > if (lpTime->wType==TIME_SMPTE) > { > LPMMTIME myTime; > myTime.wType=TIME_MS; > rc=MMDRV_Message(wmld, WODM_GETPOS, (DWORD_PTR)&myTime, > sizeof(myTime), TRUE); > if (rc!=TIME_SAMPLES) > return rc; > { > ms_to_smpte(myTime.u.ms,lpTime); > return TIME_SMPTE; > } > } > return MMDRV_Message(wmld, WODM_GETPOS, (DWORD_PTR)lpTime, > uSize, TRUE); > } > > Then we can move the SMPTE calculation to the ms_to_smpte() helper > function in winmm.c. The only drawback is performing SMPTE starting from > the TIME_MS data which may have been rounded down a bit. We could > eliminate this problem if we had access to the driver's wwo->format > data. And then we could also move the TIME_MS calculation to winmm.c and > even the TIME_SAMPLES one. Is there any (potential) driver for which > this calculation would not work? > > lpTime->u.sample = bytes / (wwo->format.wBitsPerSample / 8 * > wwo->format.wf.nChannels); > > coming back from vacation, and starting browsing thru the pile of e-mail (I'm not sure of the final output of this discussion). How about, letting the drivers decide which format they support (in ???_GETPOS message handling) and have the fallback code in winmm.c ? This would help the factorisation of the code. A+

Aug. 15, 2004

Re: More winecfg todos

by Jacek Caban

> 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: [Wine]faking network shares

by David Lee Lambert

On Thu, Aug 12, 2004 at 12:42:08PM +0100, Fergal Daly wrote: > I have an app that wants to read from \\server\directory\file.ini and I > don't have an easy way of changing this, so I want to tell wine that > \\server\directory is available in /mnt/smb/server/directory. Is this > possible? What do I need to do? If you try to read from a path starting "\\.\" in Wine (in some versions), you'll get a message saying something like "Fixme: UNC name (%s) not supported.", but there is basic support for Wine to read from a file directly over an SMB link for paths that start with "\\" up until Wine-20040505. It identifies itself as a WfW server and doesn't attempt to provide a username or password, as far as I can tell. It looks like the relevant functions were deleted before 20040615. In principle, Wine could probably provide UNC-name support by calling 'smbclient', or by parsing /etc/mtab for 'smbfs' mountpoints and trying to access them like any other file. Another alternative would be a configuration-file override to alias an arbitrary UNC path as some file, just like the old [Drive X] mappings. In your case, would it be acceptable to have a local, static copy of the .ini file, and just point Wine at that somehow? (Forwarding to the developer's list, since it looks like this is a useful feature that was removed because no one was finishing it.) -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 15, 2004

Re: [wine] Re: config converting problem

by David Lee Lambert

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. 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? -- resume at http://www.cse.msu.edu/~lamber45/resume.htm PGP key at http://www.cse.msu.edu/~lamber45/newmail.htm#GPGKey

Aug. 15, 2004

Windows Default Button Observations

by Zach Gorman

While fixing some compatibility problems in Wine relating to my app, I had the opportunity to compare how Wine handles default buttons to how Windows handles them. [Definition: Default buttons have the BS_DEFPUSHBUTTON style, are drawn with an extra-thick border, and are the buttons chosen when the user types Enter.] I fixed a couple problems today, but there are more issues left: ------- (1) Windows: When a dialog is deactivated in Windows, all buttons are made non-default. When it is activated again, Windows remembers which button was last the default button and makes it default again. It does all this by means of BM_SETSTATE messages. Wine: Default buttons are unaffected by activation/de-activation of their parent dialogs. (2) Windows: When the user clicks and holds on a button, then moves the mouse off that button before releasing it, the button is made default and receives the focus. The existing default button is made non-default. Wine: The button receives the focus but is not made default. -------- My impression is that (1) could be handled by remembering the default button (which, as Krishna Murthy has shown, is not the same as the default button id) in the DIALOGINFO structure. Number (2), however, is more difficult. When a button receives the capture, it can send a BM_SETSTATE to itself easily enough to make itself a DEFPUSHBUTTON, but how does it determine which other buttons to query and make non-default as necessary? It could simply query all its sibling controls, but this wouldn't work if it was contained within a sub-window in the dialog box. How can it determine how far up the hierarchy it needs to go? Any comments would be welcomed. Thanks, Zach

Aug. 15, 2004

Re: wine/dlls/commdlg fontdlg.c

by Jacek Caban

Vincent Béron wrote: >Le ven 13/08/2004 à 20:42, Alexandre Julliard a écrit : > > >>ChangeSet ID: 13294 >>CVSROOT: /opt/cvs-commit >>Module name: wine >>Changes by: julliard(a)wine.codeweavers.com 2004/08/13 19:42:35 >> >>Modified files: >> dlls/commdlg : fontdlg.c >> >>Log message: >> Jacek Caban <jack(a)itma.pwr.wroc.pl> >> Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand >> in FormatCharDlgProcW. >> >>Patch: http://cvs.winehq.org/patch.py?id=13294 >> >>Old revision New revision Changes Path >> 1.69 1.70 +2 -5 wine/dlls/commdlg/fontdlg.c >> >> > >At least the last part of this patch looks wrong. > >- return CFn_WMCommand(hDlg, wParam, lParam, lpcf32a); >+ return CFn_WMCommand(hDlg, wParam, lParam, >(LPCHOOSEFONTW)lpcf32w); > >This cast is absolutely non-sense, as lpcf32w is already a >LPCHOOSEFONTW. Aslo, CFn_WMCommand expects a LPCHOOSEFONTA as its fourth >parameter, not a LPCHOOSEFONTW. > > It should be LPCHOOSEFONTA. Sory for that. >Maybe just changing the cast to LPCHOOSEFONTA would work, but a quick >glance in CFn_WMCommand told me it uses some A fields of that structure, >so maybe it's not enough and we'll need to actually do a conversion (or >transform CFn_WMCommand to expect a LPCHOOSEFONTW). > > I've tested this usng notepad and it works fine. Absolutely non-sense was cast that my patch changes. It didn't work without my patch. Applications failed with segmentation fault. >Vincent > > > I've attached patch. Thanks, Jacek

Aug. 15, 2004

Re: wine/dlls/commdlg fontdlg.c

by Vincent Béron

Le ven 13/08/2004 à 20:42, Alexandre Julliard a écrit : > ChangeSet ID: 13294 > CVSROOT: /opt/cvs-commit > Module name: wine > Changes by: julliard(a)wine.codeweavers.com 2004/08/13 19:42:35 > > Modified files: > dlls/commdlg : fontdlg.c > > Log message: > Jacek Caban <jack(a)itma.pwr.wroc.pl> > Fix a bug in passing parameters to CFn_WMInitDialog and CFn_WMCommand > in FormatCharDlgProcW. > > Patch: http://cvs.winehq.org/patch.py?id=13294 > > Old revision New revision Changes Path > 1.69 1.70 +2 -5 wine/dlls/commdlg/fontdlg.c At least the last part of this patch looks wrong. - return CFn_WMCommand(hDlg, wParam, lParam, lpcf32a); + return CFn_WMCommand(hDlg, wParam, lParam, (LPCHOOSEFONTW)lpcf32w); This cast is absolutely non-sense, as lpcf32w is already a LPCHOOSEFONTW. Aslo, CFn_WMCommand expects a LPCHOOSEFONTA as its fourth parameter, not a LPCHOOSEFONTW. Maybe just changing the cast to LPCHOOSEFONTA would work, but a quick glance in CFn_WMCommand told me it uses some A fields of that structure, so maybe it's not enough and we'll need to actually do a conversion (or transform CFn_WMCommand to expect a LPCHOOSEFONTW). Vincent

Aug. 14, 2004

Re: [QUARTZ] Some pins bug fixes

by Christian Costa

Robert Shearman wrote: > Christian Costa wrote: > >> Hi, >> >> Changelog: >> Don't fail a connection because an input pin does not expose the >> IMemInputPin interface (pull pins typically). > > > > This seems wrong. The FileAsyncReaderPin (and any other output pin > that connects to a pull pin) should override the pConnectSpecific > function so that it doesn't query for IMemInputPin. I can't explain > why this isn't currently done. You're simply right. This is wrong. Ok, I will resent a patch without this change for the moment. > > > I don't really like the (%p/%p)->... notation, but if it helps you in > debugging then it's fine. Well, I won't repeat what Lionel said but this has been very usefull for debugging the quartz code. Christian

Aug. 14, 2004

Re: [QUARTZ] Some bug fixes

by Christian Costa

> > >> Avoid indefinite wait when calling GetOverlappedResult. > > > This shouldn't happen. GetOverlappedResult should do a wait on the > event object, just like the wait above that succeeds (and > GetOverlappedResult is called) or times out (and GetOverlappedResult > is not called). I suspect that the bug is elsewhere, perhaps an event > should be created for each request and then WaitForMultipleObjects used. > BTW, I meant infinite wait... Well, some lines above the GetOverlappedResult, there is a WaitForSingleObject on the event and since the event is resetted automatically there (the event is not manual) GetOverlappedResult will wait forever. There is no bug elsewhere its a rather simple win32 related problem. Anyway, we may make use of a manual event for real asynchronous requests. The avi splitter don't do that at the moment so the current implementation is enough. Thanks for the comments. :-) Christian

Aug. 14, 2004

Re: [QUARTZ] Some bug fixes

by Robert Shearman

Christian Costa wrote: >> >>> Avoid indefinite wait when calling GetOverlappedResult. >> >> >> This shouldn't happen. GetOverlappedResult should do a wait on the >> event object, just like the wait above that succeeds (and >> GetOverlappedResult is called) or times out (and GetOverlappedResult >> is not called). I suspect that the bug is elsewhere, perhaps an event >> should be created for each request and then WaitForMultipleObjects used. >> > BTW, I meant infinite wait... > > Well, some lines above the GetOverlappedResult, there is a > WaitForSingleObject on the event and since the event is resetted > automatically there (the event is not manual) GetOverlappedResult will > wait forever. > There is no bug elsewhere its a rather simple win32 related problem. > Anyway, we may make use of a manual event for real asynchronous requests. > The avi splitter don't do that at the moment so the current > implementation is enough. Ah, yes. In that case the patch is correct. > Thanks for the comments. :-) You're welcome. Rob

Aug. 14, 2004

Re: [QUARTZ] Some pins bug fixes

by Lionel Ulmer

> I don't really like the (%p/%p)->... notation, but if it helps you in > debugging then it's fine. Well, I introduced this notation in the D3D code to log both the interface given by the application AND the 'base' object from the Wine side. Which is sometimes useful to debug when we get problems with object version mismatch. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 14, 2004

Re: [QUARTZ] Some pins bug fixes

by Robert Shearman

Christian Costa wrote: > Hi, > > Changelog: > Don't fail a connection because an input pin does not expose the > IMemInputPin interface (pull pins typically). This seems wrong. The FileAsyncReaderPin (and any other output pin that connects to a pull pin) should override the pConnectSpecific function so that it doesn't query for IMemInputPin. I can't explain why this isn't currently done. > Fixed a bug that made the connection possible whereas no suitable > media type has be found during the negociation. Good catch. > Fixed the release of the media sample in PullPin_Thread_Process. Again, good catch. I see now that without this fix we would have leaked ref counts on the IMediaSample object. > Added and fixed a lot of traces. I don't really like the (%p/%p)->... notation, but if it helps you in debugging then it's fine. Rob

Aug. 14, 2004