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

[BUG1001]: please update comments

by Vijay Kiran Kamuju

Hi, for BUG 1001, please update the comments with the following link, http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q113996 I am unable to update via bugzilla, my id is infyquest, its giving me error that the short_id_desc is missing. Thanks, Vijay

Aug. 28, 2005

Re: old version freetype installed warning

by Yuri Kozlov

2005/8/27, Dmitry Timoshkov <dmitry(a)baikal.ru>: > "Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > > > changelog: > > gdi: old version freetype installed warning added > > > --- wine/dlls/gdi/freetype.c 2005-08-20 08:33:00.000000000 +0400 > > +++ bwine/dlls/gdi/freetype.c 2005-08-27 16:05:47.000000000 +0400 > > @@ -438,6 +438,7 @@ > > /* There are too many bugs in FreeType < 2.1.9 for bitmap font support */ > > if(!FT_IS_SCALABLE(ft_face) && FT_SimpleVersion < ((2 << 16) | (1 << 8) | (9 << 0))) { > > pFT_Done_Face(ft_face); > > + WARN("Please, update FreeType library (>=2.1.9) -- font %s will not be load\n", debugstr_a(file)); > > If it's supposed to be a user visible message then it should use MESSAGE > instead of a WARN. > Yes, I think MESSAGE is more correct. -- Regards, Yuri Kozlov

Aug. 28, 2005

Re: [COMCTL32] Set default size in ToolBar.SetBitmapSize

by Yuri Kozlov

2005/8/27, Dmitry Timoshkov <dmitry(a)baikal.ru>: > "Yuri Kozlov" <kozlov.y(a)gmail.com> wrote: > > > changelog: > > [COMCTL32] set default size for toolbar bitmap if not specified > > > --- wine/dlls/comctl32/toolbar.c 2005-08-16 19:25:16.000000000 +0400 > > +++ bwine/dlls/comctl32/toolbar.c 2005-08-27 13:12:46.000000000 +0400 > > @@ -4719,7 +4719,7 @@ > > FIXME("wParam is %d. Perhaps image list index?\n", wParam); > > > > if ((LOWORD(lParam) <= 0) || (HIWORD(lParam)<=0)) > > - return FALSE; > > + lParam = MAKELONG(16, 15); > > Better use MAKELPARAM here since it's a 64-bit entity in Win64. Ok. Fixed path sended. -- Regards, Yuri Kozlov

Aug. 28, 2005

Question: Wine "Administrator" mode for multi-user "Windows * [Professional/Enterprise/...]" edition reference...

by Belxjander Serechai

Ive seen this on the mailinglists once before about installing wine and windows binaries into wine once... amongst several users... on smaller shared server setups this may be easier to achieve if there was some way to identify a single username/usergroup outside wine as "admin" equivalent within wine... Im curious... would an /etc/wine existing with username/usergroup markings other than "root:root" for owner:group be usable for indicating a "common" install setup... when "root" runs "winecfg" and also usable for "templating" when a user runs wine for themselves for the first time... I know there are pet hates and things to like about any given software but I am personally most irked by needing to fully install several copies of the same settings and program suite under each user... just making a template and copying it all doesnt always work, (maybe I just deal with too many computer illiterate users...) just wondering what if anything is in the current and mapped goals Jeremy Send instant messages to your online friends http://au.messenger.yahoo.com

Aug. 28, 2005

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

by Jesse Allen

On 8/27/05, Walt Ogburn <reuben(a)ugcs.caltech.edu> wrote: > Hi guys, Hi > The other possibility is to have something in wineserver update the > dosdevices symlinks when volumes are mounted. That would also be a > significant amount of new stuff in wineserver. > > Without doing anything to wine itself, there's one other option: set up a > HAL front-end like ivman (http://ivman.sourceforge.net/) to update the > dosdevices symlinks when volumes are mounted. This might be the right > aswer. A distro like SuSE that wants to use HAL and have things mounted > in different places can include ivman scripts in its wine package to > automatically do the right thing with the dosdevices links, and then > there's no problem. Or wine could check for ivman at the same time it > creates .wine, and set up appropriate ivman scripts if it finds it. > > - Walter I do agree better drive detection is needed, but I don't agree that the mount point should be found through the d:: type symlink. Better to have something like Ivman call out a wine helper script to read /etc/fstab and make the changes on the fly. Wineserver could check /etc/fstab on start up too. The check on start can be controlled by a setting. Drive letters that are created on the fly are temporary while wineserver is running. The drive letters set up through winecfg or ~/.wine/dosdevices are permament as long as the devices or filesystems do exist.

Aug. 28, 2005

Re: IDA Pro Regression

by James Liggett

Hi, A week or so ago I reported some regressions running IDA pro on wine. I've done some regression testing and I have found the patches that were causing the problems. The first problem I noticed were the large edit boxes in the General Registers window in IDA's debugger. It was caused by this edit control theming patch: http://cvs.winehq.org/patch.py?id=19554. I also noted a crash after setting the debugger's process options. I found that this problem was also caused by a theming patch, this time for comboboxes: http://cvs.winehq.org/patch.py?id=19604 Since I'm really not too familiar with these areas of wine, perhaps someone with a little more experience with these patches can take a look at them so that they can be fixed. Thanks, James

Aug. 28, 2005

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

by Walt Ogburn

Hi guys, Sorry if I started a contentious discussion. I have looked into it a little more and found some useful information. There was a discussion on wine-devel about this topic back in March, which I had forgotten. You can find a summary in the Wine newsletter from that month: http://www.winehq.org/?issue=265#Drive%20Management What I had in mind was not to break the current system, but to allow an optional alternative method of mapping the drives, e.g. if you have d: -> /mnt/cdrom d:: -> /dev/hdc everything will work like now, and if you only have d:: -> /dev/hdc wine will figure out where hdc is mounted and map DOS to Unix filenames accordingly. Looking at the code, though, that doesn't fit in very naturally with the way wine actually does things. What I hadn't understood is that the mapping of DOS to Unix filenames is purely an operation on strings, with no disk access needed: Q:\foo\bar is translated to ~/.wine/dosdevices/q:/foo/bar regardless of whether ~/.wine/dosdevices/q: points to anything meaningful or exists at all. This current system is very neat and simple, and doing anything different would mean introducing a significant amount of extra complication. The other possibility is to have something in wineserver update the dosdevices symlinks when volumes are mounted. That would also be a significant amount of new stuff in wineserver. Without doing anything to wine itself, there's one other option: set up a HAL front-end like ivman (http://ivman.sourceforge.net/) to update the dosdevices symlinks when volumes are mounted. This might be the right aswer. A distro like SuSE that wants to use HAL and have things mounted in different places can include ivman scripts in its wine package to automatically do the right thing with the dosdevices links, and then there's no problem. Or wine could check for ivman at the same time it creates .wine, and set up appropriate ivman scripts if it finds it. - Walter On Sun, 28 Aug 2005, Detlef Riekenberg wrote: > Am Samstag, den 27.08.2005, 14:38 -0700 schrieb Hiji: > > > It might be the ugly way, but it is the official way. > > That's because many Applications are unable to handle it yet. > > > This is definately *not* a Wine issue because it > > affects any application which relies on have a static > > name for the drive - let's make sure we're clear on > > that. ;) > No! > This is not only a Wine issue, it's an issue of all applications which > relies on static names. > The big mistake: The Volume-Label is optional. > > It's possible on windows (since w2k) to work without a Driveletter for > your CDROM, ("%SYSTEMROOT%\mountpoint") but they made the same mistake: > Using a mountpoint (junction) is optional. > When they used the mountpoint-method as default and the > driveletter-method as optional fallback for old applications, then all > important software would work today without an extra driveletter for > removeable media. > > It's time to be more flexible. freedesktop.org did a step in the > direction, now the applications must follow! > > > I suspect this "mounting by volume label" > > won't last past Suse 9.3 since > > .. and go backwards? No way! > > > I haven't read anyone > > praise this "feature" anywhere. > > That's the same when /dev/cdrom or /cdrom comes up as a link to the real > device. It doesn't matter, on which controller, port and id your drive > is connected; it just works. > The link comes up and step by step more applications using this. > > And think about logical-volumes. > Go backwards, because the admin will define on his own, which physical > drive is used and mounted to a specific location? > Logical volumes are present for ages in Novell Netware and other > systems, arrived Windows since w2k and are working in linux for some > years now. > > > -- > By By ... > ... Detlef > >

Aug. 27, 2005

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

by Detlef Riekenberg

Am Samstag, den 27.08.2005, 14:38 -0700 schrieb Hiji: > It might be the ugly way, but it is the official way. That's because many Applications are unable to handle it yet. > This is definately *not* a Wine issue because it > affects any application which relies on have a static > name for the drive - let's make sure we're clear on > that. ;) No! This is not only a Wine issue, it's an issue of all applications which relies on static names. The big mistake: The Volume-Label is optional. It's possible on windows (since w2k) to work without a Driveletter for your CDROM, ("%SYSTEMROOT%\mountpoint") but they made the same mistake: Using a mountpoint (junction) is optional. When they used the mountpoint-method as default and the driveletter-method as optional fallback for old applications, then all important software would work today without an extra driveletter for removeable media. It's time to be more flexible. freedesktop.org did a step in the direction, now the applications must follow! > I suspect this "mounting by volume label" > won't last past Suse 9.3 since .. and go backwards? No way! > I haven't read anyone > praise this "feature" anywhere. That's the same when /dev/cdrom or /cdrom comes up as a link to the real device. It doesn't matter, on which controller, port and id your drive is connected; it just works. The link comes up and step by step more applications using this. And think about logical-volumes. Go backwards, because the admin will define on his own, which physical drive is used and mounted to a specific location? Logical volumes are present for ages in Novell Netware and other systems, arrived Windows since w2k and are working in linux for some years now. -- By By ... ... Detlef

Aug. 27, 2005

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

by Jesse Allen

On 8/27/05, Hiji <hijinio(a)yahoo.com> wrote: > > > Thanks for the link to the xml hack, it may come in > > useful one day. > > Glad I could help; here are my comments to this thread > in wine-users: > "It might be the ugly way, but it is the official way. > > This is definately *not* a Wine issue because it > affects any application which relies on have a static > name for the drive - let's make sure we're clear on > that. ;) I suspect this "mounting by volume label" > won't last past Suse 9.3 since I haven't read anyone > praise this "feature" anywhere." > > Have a great day! :) > Hiji > > Why can't SuSE create first, a mount point that corresponds with device, like /dev/hdc and /mnt/hdc, and then when a disc is inserted create a /mnt/$DISKLABEL symlink to /mnt/hdc ? Solves problems with apps that require a fixed path. ....Oh, then no one will use the label! That's why. =p

Aug. 27, 2005

Re: [Wine]Softlinking to a dvd-drive with inconsistent mount points? => HAL-Support

by Hiji

> Thanks for the link to the xml hack, it may come in > useful one day. Glad I could help; here are my comments to this thread in wine-users: "It might be the ugly way, but it is the official way. This is definately *not* a Wine issue because it affects any application which relies on have a static name for the drive - let's make sure we're clear on that. ;) I suspect this "mounting by volume label" won't last past Suse 9.3 since I haven't read anyone praise this "feature" anywhere." Have a great day! :) Hiji ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

Aug. 27, 2005