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

Re: wave tests patch

by Francois Gouget

On Sun, 15 Aug 2004, Eric Pouech wrote: [...] > 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. In the end I just factored the code between the waveout and wavein code in each driver. So the TIME_SMPTE is still duplicated in each driver. The problem with sharing this code in winmm.c is that we need to know what's the device format and I'm not sure how to do that from winmm.c. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

Aug. 16, 2004

Re: More winecfg todos

by Jacek Caban

Alexandre Julliard wrote: >Mike Hearn <mike(a)navi.cx> writes: > > > >>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. >> >> > >No, I don't think we want to make the paths configurable that way. At >least for the windows and system dirs, they will most likely be >embedded in the registry somewhere so you can't change them without >reinstalling everything; and there's no real reason to anyway. What we >should have is a "import real Windows drive" button that lets you >point to a Windows partition and set things up properly based on >that. > > > But PATH and temp directory are useful and can be configured this way. Maby we could add this two options? Thanks, Jacek

Aug. 16, 2004

Re: Delorme Street Atlas 2004 - Sooo Close...

by Michael H. Warfield

Minor typos... On Mon, Aug 16, 2004 at 10:49:25AM -0400, Michael H. Warfield wrote: > Hey all, > So this is my first post to the list in several years... > I've tried several version so Delorme's Street Atlas under of > many many versions of Wine over the years. Most of the time, I haven't > even been able to get it to install. One version, in the way WAY distant > past, did install and I had problems with the serial port and port naming > conventions that, IIRC, resulted in some patches to Wine. But all recent > versions have been major headaches. > I recently tried the 20040716 version of Wine and, just now, the > 20040713 version. I was able to install Street Atlas 2004 under that 20040813 - Duh... > previous version! Yeah! Some problems with things like checkboxes > in install shield not being visible (but could be checked if you guessed > right where the check box was under the image that was obscuring it) > but it did install. Sorry about that. : Mike -- Michael H. Warfield | (770) 985-6132 | mhw(a)WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

Aug. 16, 2004

Delorme Street Atlas 2004 - Sooo Close...

by Michael H. Warfield

Hey all, So this is my first post to the list in several years... I've tried several version so Delorme's Street Atlas under many many versions of Wine over the years. Most of the time, I haven't even been able to get it to install. One version, in the way WAY distant past, did install and I had problems with the serial port and port naming conventions that, IIRC, resulted in some patches to Wine. But all recent versions have been major headaches. I recently tried the 20040716 version of Wine and, just now, the 20040713 version. I was able to install Street Atlas 2004 under that previous version! Yeah! Some problems with things like checkboxes in install shield not being visible (but could be checked if you guessed right where the check box was under the image that was obscuring it) but it did install. Running it becomes another matter. If the data CD is in the CD-Rom drive, I get the modal welcome splash window up but then I get the following errors: [mhw(a)canyon mhw]$ wine .wine/drive_c/Program\ Files/Street\ Atlas\ USA\ 2004/SA2004.exe fixme:ole:CoCreateInstance no classfactory created for CLSID {ebbd44c6-6b55-4aa8-8a22-ceac2ede660f}, hres is 0x80040154 Fatal Error at file , line 0, char 0 Message: err:seh:setup_exception stack overflow 236 bytes in thread 0009 eip 3545a7ab esp 17840f14 stack 0x17840000-0x17940000 Now, the first one doesn't seem to be "fatal". If I don't have the CD in the CD-Rom drive, I still get that error but it come to a dialog box asking if I want to run without the databases or if I want to browse for them. If I then insert the CD and hit browse and browse over to the CD-Rom, it then hits the fatal error as before. The second error seems to be really bad juju. The splash screen just stays on top of everthing else and the whole thing seems hung. I can (and have to) Cntrl-C the application in the terminal window and then the splash screen goes away as the app terminates. This is one Fedora Core 2 with 2.6.7 kernel. Any thoughts or suggestions? Since it's a "stack overflow" (which tend to be pretty damn serious) I figured I would raise this issue on the developers list, rather than the users list. Oh... I also used the winetools package to install things like fonts and MS-installer and VBS runtimes, if that makes a difference. I was unable to install the VC++ runtime, though (didn't try that on 0813 version though). Any recommendations on debugging it further? Regards Mike -- Michael H. Warfield | (770) 985-6132 | mhw(a)WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

Aug. 16, 2004

Re: [lostwages] Add WBL 3.0 (RHEL 3.0 compatible) to the list of RH distros

by Vincent Béron

Le lun 16/08/2004 à 03:48, Andreas Mohr a écrit : > Hi, > > On Sat, Aug 14, 2004 at 09:14:58PM -0400, Vincent Béron wrote: > > Since I finally had the time to install it, lets provide Wine binaries > > for it (it's been asked in the past). > > > > Changelog: > > Add WBL 3.0 (RHEL 3.0 compatible) to the list of RH distros. > This is not really correct. > Google "RHEL WBEL" vs. "RHEL WBL" shows an overwhelmingly clear result, > and whiteboxlinux.org also refers to itself as White Box Enterprise Linux > in the page title (plus it mentions WBEL on the home page!). > It does list White Box Linux, however (although, as mentioned before, > this is much less common). Right, I (wrongly) based it on their website name (whiteboxlinux.org) I'll send an updated patch shortly. Vincent

Aug. 16, 2004

Re: Adventures in serial port.

by Steven Edwards

Hi, --- Boaz Harrosh <boaz(a)hishome.net> wrote: > One way I know is to wrap the .Lib in a .DLL on windows with MSVC or > MinGW. Than use the DLL in your winelib. > On the winelib side you have to make a .SPEC file for your windows > DLL. > Look in previous threads and in winelib documentation for how to > make a > .spec file of your dll, and how to link to it. The mingw-utils package has a tool called reimp that allows you to convert a MS_VC style *.lib in to a *.a file. Just run reimp file.lib. At some point we should add support for reading .lib files like mingw has. Thanks Steven __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

Aug. 16, 2004

Re: Removed slovenian translation

by Jacek Caban

Marcelo Duarte wrote: > Use diff -u Si.rc /dev/null > > Jacek Caban wrote: > >> I found that slovenian translation is incomplete and not translated, >> so I removed this from winecfg.rc. Si.rc should be remove too, but >> I don't know how to do this in patch. >> >> Changelog: >> Removed slovenian translation >> >> Index: programs/winecfg/winecfg.rc >> =================================================================== >> RCS file: /home/wine/wine/programs/winecfg/winecfg.rc,v >> retrieving revision 1.10 >> diff -u -r1.10 winecfg.rc >> --- programs/winecfg/winecfg.rc 22 Jul 2004 19:45:00 -0000 1.10 >> +++ programs/winecfg/winecfg.rc 16 Aug 2004 19:23:12 -0000 >> @@ -32,7 +32,6 @@ >> #include "It.rc" >> #include "Pt.rc" >> #include "Ru.rc" >> -#include "Si.rc" >> >> LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL >> >> Thanks for advice. I thought it'll make empty file.

Aug. 16, 2004

Re: Added path settings to winecfg

by Jacek Caban

Marcelo Duarte wrote: > Hi, > I think that you do not need to modify the .rc files from languages > other than En.rc and your native language. If you do not translate, it > will more easy to us to known that it is wrong and needs to be > translated. This is my position in relation to Pt.rc. > Thank you. > > Jacek Caban wrote: > >> Changelog: >> Added path settings to winecfg. >> >> I agree with you in case when I create new dialog. Then WINE, if doesn't exist in current language, uses dialog from default language. But when I only modify an existing dialog, I have to modify all .rc files. It's my opinion. Am it wrong? Thanks, Jacek

Aug. 16, 2004

Re: update the faq take 2 : faq-2.diff

by Tom

Andreas Mohr wrote: > Hmm... > Rewind is an important part for companies who choose to not publish > all of their source under the (L)GPL (but hopefully do publish smaller > utilities not essential to their core business :-). > As such it might be useful to keep the reference. Hello Andi, Many people release there code as X11/LGPL but the project at http://rewind.sourceforge.net/ is for the most part dead! If the tree was kept upto date and X11 patches were merged in I could see why some would want to keep a reference to it, but its just not that way. So in reality all were doing by providing this reference is sending people to two year old code that is missing *many* X11 patches that have been sent to wine-patches. > (to such companies at least ;-) > Are there any "GPL-unencumbered" (ugh, gotta hate that word ;) > alternatives? I don't know of any, so... Are there any upto date, maintained X11 projects? I don't know of any, so........ Cheers, Tom Who feels his patch is correct. > > Greetings, > > Andreas Mohr > (who certainly would not be too unaffected by the non-availability > of a rewind tree ;-) > > >

Aug. 16, 2004

Re: [Wine]faking network shares

by Mike Hearn

Fergal Daly wrote: > The message I was getting was > > fixme:file:wine_nt_to_unix_file_name UNC name L"\\??\\UNC\\machine\path" > > so I had a look in the code and found the relevant place, added a few > printfs and found that that > > \\machine\path > > maps to > > .wine/dosdevices/unc/MACHINE/PATH > > so it is supported, it just doesn't seem to be documented anywhere that I > could find. Everything is working nicely now. > > I'll write a quick FAQ entry if I get time today. Thanks, Cool! You're right, this does appear to be totally undocumented, I had no idea about this. It should probably go into winecfg and the man pages.

Aug. 16, 2004

WWN 235

by Tom

Sorry my bad :) as it is now correct Tom

Aug. 16, 2004

WWN 235 went from bad to worse!

by Tom

Hello, In reference to Winehq frontpage error..... Now it looks like : c:\\windows is not accessible Error (con't) Tom

Aug. 16, 2004

Re: Adventures in serial port.

by Boaz Harrosh

Scott Snell wrote: > However I have struck a problem. My windows program >code links in a .lib file that is provided by a third party. Can I link >this library file into my winelib project, and if so how? I cant seem to >find any recent discussion on this topic > > One way I know is to wrap the .Lib in a .DLL on windows with MSVC or MinGW. Than use the DLL in your winelib. On the winelib side you have to make a .SPEC file for your windows DLL. Look in previous threads and in winelib documentation for how to make a .spec file of your dll, and how to link to it. If you use MSVC do use a .DEF file because winebuild used to have problems with "__declspec(export)" functions exported from DLLS. (maybe it was fixed I'm not really up to date) Free Life Boaz

Aug. 16, 2004

Re: update the faq take 2 : faq-2.diff

by Andreas Mohr

Hi, On Sun, Aug 15, 2004 at 06:23:05AM -0400, Tom wrote: > > Hello, > > change dll's back to dlls > > Tom > > Changelog: > remove rewind section due to lack of updates Hmm... Rewind is an important part for companies who choose to not publish all of their source under the (L)GPL (but hopefully do publish smaller utilities not essential to their core business :-). As such it might be useful to keep the reference. (to such companies at least ;-) Are there any "GPL-unencumbered" (ugh, gotta hate that word ;) alternatives? I don't know of any, so... Greetings, Andreas Mohr (who certainly would not be too unaffected by the non-availability of a rewind tree ;-)

Aug. 16, 2004

Re: [Wine]faking network shares

by Fergal Daly

The message I was getting was fixme:file:wine_nt_to_unix_file_name UNC name L"\\??\\UNC\\machine\path" so I had a look in the code and found the relevant place, added a few printfs and found that that \\machine\path maps to .wine/dosdevices/unc/MACHINE/PATH so it is supported, it just doesn't seem to be documented anywhere that I could find. Everything is working nicely now. I'll write a quick FAQ entry if I get time today. Thanks, F On Sun, Aug 15, 2004 at 01:16:59AM -0400, David Lee Lambert wrote: > 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. 16, 2004

Adventures in serial port.

by Scott Snell

Hi All, I have been trying for several weeks to transfer our product to linux using wine. I am so close it hurts! The only issue has been the serial ports. Threads, sockets, and timers appear to be working as advertised (an impressive feat of wine as it is!). However the serial port has failed me. I have used versions 20040716 and 20040505 both as RPM's and source code (with various patches applied to the source). The major issue is reliability. I can successfully get test programs to echo back a character received on the serial port. However when I use the port in anger it often drops bytes. Calls to ReadFile will drop the last byte when the packet size is 30 bytes, and up to the last 5 bytes when the packet size is 200+ bytes. After a while calls to WriteFile will actually stop sending bytes even though it returns successfully. The program has several threads but I have modified it so that the calls to ReadFile/Writfile are in the same thread inside a loop. I set the timeout parameters to return immediately from a ReadFile with any available bytes. If you are interested I can post the shell of my code. Unfortunately the sands of time keep flowing and I am under pressure to find a solution. I have decided to use winelib to build our program that uses the serial port and write native code to read/write to the serial port. The rest of the suite I will continue to use with wine. This has gone well so far and again I am suprised at how smoothly I can do things, this time with winelib/winemaker. However I have struck a problem. My windows program code links in a .lib file that is provided by a third party. Can I link this library file into my winelib project, and if so how? I cant seem to find any recent discussion on this topic so if you could point me to some I would be very grateful. regards, scott.

Aug. 16, 2004

Re: [Wine]faking network shares

by Mike Hearn

This support was removed as it really has to be done kernel-side, but as to the state of integration now you'd have to ask Alexandre or Mike I suspect. David Lee Lambert wrote: > 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.) >

Aug. 16, 2004

Re: [lostwages] Add WBL 3.0 (RHEL 3.0 compatible) to the list of RH distros

by Andreas Mohr

Hi, On Sat, Aug 14, 2004 at 09:14:58PM -0400, Vincent Béron wrote: > Since I finally had the time to install it, lets provide Wine binaries > for it (it's been asked in the past). > > Changelog: > Add WBL 3.0 (RHEL 3.0 compatible) to the list of RH distros. This is not really correct. Google "RHEL WBEL" vs. "RHEL WBL" shows an overwhelmingly clear result, and whiteboxlinux.org also refers to itself as White Box Enterprise Linux in the page title (plus it mentions WBEL on the home page!). It does list White Box Linux, however (although, as mentioned before, this is much less common). Andreas Mohr

Aug. 16, 2004

Re: wine/dlls/commdlg fontdlg.c

by Dmitry Timoshkov

"Jacek Caban" <jack(a)itma.pwr.wroc.pl> wrote: > case WM_COMMAND: > - return CFn_WMCommand(hDlg, wParam, lParam, (LPCHOOSEFONTW)lpcf32w); > + return CFn_WMCommand(hDlg, wParam, lParam, (LPCHOOSEFONTA)lpcf32w); No, that's not enough. As Vincent pointed out CFn_WMCommand accesses structure dependent fields and you need to convert the structure in order to make it work. -- Dmitry.

Aug. 16, 2004

provider type of Microsoft Base Cryptographic Provider v1.0

by James Hawkins

Hi, If you run regedit in wine and view the following key: HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Defaults\Provider Types\Type 001 Type 001 does not have a "TypeName" value. Should Type 001 have a "TypeName" value? CryptEnumProviderTypes calls RegQueryValueEx on this value to see what the provider type is, but fails (but not in an obvious way). Should RegQueryValueEx return an error code describing that there is no such value? If so, what is the error code/name? -- James Hawkins

Aug. 15, 2004

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