April 2009 - Wine-devel - list.winehq.org

Re: NTFS filesystem features -> WONTFIX?
by James Mckenzie 07 Apr '09

07 Apr '09

Kai Blin <kai.blin(a)gmail.com> wrote on April 7th: >Subject: Re: NTFS filesystem features -> WONTFIX? > >On Tuesday 07 April 2009 04:21:37 Vitaliy Margolen wrote: > >> - Implement missing functionality - will most likely be nearly impossible >> without driver support for special features. Or have to be emulated by Wine >> (then why not for any other FS?) > >We can probably get away with 80% of the apps only using 20% of the features, >as usual. I guess that apps are mostly interested in ACLs, which could be >mapped to POSIX acls, stored in file attributes or some database or simply >faked. Samba does this, I don't see why we couldn't. > Can we use Samba code in Wine to make this a reality? James McKenzie

3 2

Single login for Wine sites?
by David Gerard 07 Apr '09

07 Apr '09

What's standing in the way of unified login for the various Wine sites (appdb, wiki, Bugzilla)? Is there anyone running any of these sites who doesn't consider single unified login a good idea? - d.

5 6

Status of "USB device support in wine"
by Uwe Bonnes 07 Apr '09

07 Apr '09

Hello, Alexander Morozov <amorozov(a)etersoft.ru> did a large redesign after Alexandre's remarks from 07 October 2008. What is still needed to include this functionality? Thanks -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: [3/3] wined3d: Free allocated strings for driver and description
by Henri Verbeet 07 Apr '09

07 Apr '09

2009/4/7 John Whitlock <John-Whitlock(a)ieee.org>: > + HeapFree(GetProcessHeap(), 0, wined3d_settings.video_driver); > + HeapFree(GetProcessHeap(), 0, wined3d_settings.video_description); This should be part of the first patch. (And if you're going to resend anyway, I think it makes more sense to do the autodetection first, and the registry override afterwards).

2 1

Re: [2/5] resend ws2_32/tests: add tests for Inet_Ntop and inet_ntoa
by Alexandre Julliard 07 Apr '09

07 Apr '09

Jeff Latimer <lats(a)yless4u.com.au> writes: > @@ -55,6 +55,9 @@ > ok ( cond tmp, msg, GetCurrentThreadId(), err); \ > } while (0); > > +/* Function pointers */ > +static HMODULE hws2_32 = 0; > +static PCTSTR (WINAPI *pInetNtop)(int,LPVOID,LPTSTR,size_t) = 0; You can't use TCHAR types in tests. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/3] wined3d: Registry override for driver and description.
by Roderick Colenbrander 07 Apr '09

07 Apr '09

Hi John, Some suggestions (I think I also told Mirek at the time). Initialize the strings to NULL in wined3d_main.c where the wined3d_settings struct is initialized. Roderick On Tue, Apr 7, 2009 at 8:02 AM, John Whitlock <John-Whitlock(a)ieee.org>wrote: > This patch is from Mirek Slugen <thunder.m(a)email.cz>. See > http://www.winehq.org/pipermail/wine-patches/2009-March/070766.html > > This patch set is for bug 15839 > > > > > > > > >

1 0

Re: [2/3] wined3d: Use OpenGL for default description and OpenGL vendor for driver.
by Roderick Colenbrander 07 Apr '09

07 Apr '09

Hi John, Unfortunately this patch isn't correct. If we report a different string we have to report the right strings like in case of the vendor the right driver name e.g. for Nvidia that is 'nv4_disp.dll'. In case of the board name we also need to report the right string (the name of the board we emulate). It is quite a bit more work to get this all right. Roderick

1 0

Re: wined3d: Defaults and overrides for driver and description (bug #15839)
by Austin English 07 Apr '09

07 Apr '09

On Tue, Apr 7, 2009 at 12:13 AM, John Whitlock <John-Whitlock(a)ieee.org> wrote: > wined3d: Defaults and overrides for driver and description > > Use the OpenGL renderer for the default adapter description and the OpenGL > vendor to create the default adapter driver. Allow overriding both from > registry values. > > This fixes bug 15839. Please only one patch per e-mail. > The first patch should be credited to Mirek Slugeň (thunder.m(a)email.cz) Change the patch itself to have that contact information. -- -Austin

1 0

Re: [2/3] ntdll: don't treat DOS paths starting with / as Unix paths
by Alexandre Julliard 07 Apr '09

07 Apr '09

Vincent Povirk <madewokherd+8cd9(a)gmail.com> writes: > This patchset should fix bug 15883. Support for Unix paths is a useful feature, you can't just remove it. -- Alexandre Julliard julliard(a)winehq.org

5 7

winemenubuilder: disable debug output for .desktop files
by Joerg-Cyril.Hoehle＠t-systems.com 06 Apr '09

06 Apr '09

Hi, Austin English wrote: >> I don't think it's safe to assume that stderr will be lost if the >> program was started from a .desktop file. >The majority of users are double clicking .desktop files to start >their applications. Where do you see stderr going to in this case? It is centralised to $HOME/.xsession-errors (in Ubuntu at least). You can tell users to look there when their app crashes. The only bug IMHO -- and it's not in wine -- is that some entity in Gnome or KDE limits output to 200KB and I found no way to reset that. I.e. once this file has grown that large, output is lost until you log out. Obviously this mechanism was not expected to receive as many output as *some* wine apps produce. Alternatively, with your desktop's icon/menu editor, you can have a terminal window created for the application when it starts. Then debug output goes there. I once did that for one application which crashed at start from times to times, to get visual feedback. >Converting the fixme's to trace's/warn's may be a viable option. I think it would be good if there were semantics behind fixme & warn that users and developers can rely upon. Random conversion just to quiet messages is not nice when trying to make apps run. Of course, the pragmatics already lead to the (useful) FIXME once idiom. This winemenubuilder distinction seems superfluous. All it seemingly boils do is that some people plead for a change of wine behaviour to "by default, produce zero output. If you want some, set $WINEDEBUG (since you're in a shell anyway), because the majority of users doesn't care". I don't vote for that, since I value post-mortem analysis. Yet I admit I've been thinking myself about using WINEDEBUG=-xyz for *some* verbose apps which nevertheless work fine: once you've seen the output once, further runs are not interesting anymore. Regards, Jörg Höhle

2 1