October 2007 - Wine-Devel - list.winehq.org

Re: [Bug 9962] wine ntfs-3g segfaults

by Kai Blin

On Wednesday 10 October 2007 12:47:16 Szabolcs Szakacsits wrote: > On Wed, 10 Oct 2007, Kai Blin wrote: > > Szabolcs, the biggest reason why we don't tell people to run applications > > from an NTFS partition is not strictly a technical one but just the fact > > that people then try to run applications they installed under windows. > > This will fail for almost every application that depends on certain > > registry entries being created by the install process. > > Thank you for the explanation. > > Could the windows registry entries be mapped to the one wine needs? > I guess nobody expects instant 100% success but if the most important > ones could cover over 90% of the apps then that could be a decent start > and worth improving and maintaining in the future. Well, reading the registry is not that much of a problem. For all I know the Wine registry is 100% compatible with the Windows one. > Unfortunately the only feedback which arrives to us is that wine users are > annoyed/confused by the separate installation for wine. Apparently this is > a major wine usability and adaption problem. Think of this as "sharing one registry between different versions of Windows". It is likely doing this will screw up one of your Windows installs, so you're better off not doing this at all. I don't think this is a problem Wine can fix. People need to start realizing that a different WINEPREFIX install is like a separate operating system install for all the applications would care. I don't think there's much of an issue with the WINEPREFIX directory being located on an external disk drive that contains an NTFS file system. However, that is different from running the applications you installed under Windows. Similar things would apply if I mounted my ext2 hdd from Windows and tried running an application that was installed in Wine under Windows. I agree that we probably shouldn't segfault in that case. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Oct. 10, 2007

Re: setupapi(1/16): Test SetupDiInstallClass

by Alexandre Julliard

"Juan Lang" <juan.lang(a)gmail.com> writes: > From e3c4fd59e419c74431a7062228d023a9513a5af1 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Mon, 8 Oct 2007 17:06:41 -0700 > Subject: [PATCH] Test SetupDiInstallClass > > --- > dlls/setupapi/tests/devinst.c | 36 ++++++++++++++++++++++++++++++++++++ > 1 files changed, 36 insertions(+), 0 deletions(-) This fails here: ../../../tools/runtest -q -P wine -M setupapi.dll -T ../../.. -p setupapi_test.exe.so devinst.c && touch devinst.ok devinst.c:173: Test failed: SetupDiInstallClassA failed: 00000002 make[2]: *** [devinst.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007

Re: kernel32/locale.c: partially implement GetUserGeoID()

by Alexandre Julliard

EA Durbin <ead1234(a)hotmail.com> writes: > + if(!(hkey = create_registry_key())) return ret; > + hSubkey = NLS_RegOpenSubKey( hkey, geoW ); > + count = sizeof(bufferW); > + > + switch( GeoClass ){ > + case GEOCLASS_NATION: > + NtQueryValueKey(hSubkey, &keyW, KeyValuePartialInformation, (LPBYTE)bufferW, count, &count); > + retID = strtolW( (LPCWSTR)info->Data, &end, 10 ); You need some error checking in there, the key and/or value may not exist. > + case GEOCLASS_REGION: > + /* GetUserGeoID returns a GEOID from the table listed here > + http://msdn2.microsoft.com/en-us/library/ms776390.aspx > + Default windows behavior is to post this code to the Geo/Nation Key during SetUserGeoID(), not sure how the region request is handled */ Please don't put URLs in the code, particularly not from MSDN since they change all the time. -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007

Re: [Bug 9962] wine ntfs-3g segfaults

by Szabolcs Szakacsits

On Wed, 10 Oct 2007, Kai Blin wrote: > > Szabolcs, the biggest reason why we don't tell people to run applications > from an NTFS partition is not strictly a technical one but just the fact > that people then try to run applications they installed under windows. > This will fail for almost every application that depends on certain > registry entries being created by the install process. Thank you for the explanation. Could the windows registry entries be mapped to the one wine needs? I guess nobody expects instant 100% success but if the most important ones could cover over 90% of the apps then that could be a decent start and worth improving and maintaining in the future. Unfortunately the only feedback which arrives to us is that wine users are annoyed/confused by the separate installation for wine. Apparently this is a major wine usability and adaption problem. Best regards, Szaka -- NTFS-3G Lead Developer: http://ntfs-3g.org

Oct. 10, 2007

Re: d3dx8: patch 2; Implement D3DXVec2LengthSq

by Alexandre Julliard

David.Adam(a)math.cnrs.fr writes: > diff --git a/dlls/d3dx8/d3dx8.spec b/dlls/d3dx8/d3dx8.spec > index 3293614..325d0a5 100644 > --- a/dlls/d3dx8/d3dx8.spec > +++ b/dlls/d3dx8/d3dx8.spec > @@ -1,4 +1,5 @@ > @ stub D3DXVec2Normalize > +@ stdcall D3DXVec2LengthSq(ptr) The function is not stdcall, and AFAICS it's supposed to be inline, not exported by the dll. -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007

Re: PulseAudio as a sound output?

by Maarten Lankhorst

Hello Dave, Dave Phillips schreef: > I'm not a Wine devel, but I am closely allied with the Linux audio > community (yes, there is such a thing) and I use Wine frequently for > running Windows ASIO-based music and sound apps. I use Robert Reif's > wineasio driver, which basically does what Maarten would like to see. > > IMO the Wine/Linux audio problem stems from the very different primary > uses of sound: normal audio/video playback (CD, DVD, streaming A/V, > etc), games, and desktop/studio audio production. Each of these uses has > its own needs and expectations. Normal playback and game use wants > surround and 3D sound support, along with the ability to not interfere > with other audio processes (software mixing). Pro-audio usage needs > low-latency and zero dropouts. > Games do too, however it stays a compromise between low latency and a risk of dropouts. The dropouts are caused by the kernel, you could slightly tweak it, and get it down to ~70ms, but more isn't possible without tweaking dmix to use 512 frames in a period instead of 1024, or direct hardware access. > JACK would seem to be the best-case solution (wineasio depends on it), > but I fear it's overkill for the normal user. Also, it's not a default > feature in most Linux distros (excepting of course the > multimedia-optimized ones such as 64 Studio, JAD, Planet CCRMA, Musix, > dynebolic, etc). The esd and artsd servers are not designed for > low-latency and other pro-audio specs, so while they'll work for normal > use they are unsuitable for serious production. So yes, there's a > problem. Can there be a one-size-fits-all solution ? > > Well, first I'd suggest simply supporting ALSA as thoroughly as > necessary or possible. It is the default kernel sound system, Wine may > as well incorporate it as well as it can. Supporting the deprecated OSS > API might be a good idea too, through ALSA's OSS-compatibility layer. As > one devel noted, it may be a good idea to forego further development of > things like the NAS and ESD servers until a more solid basis exists for > ALSA/OSS. > That's what I've been trying, I hope I succeeded. There are still some problems with directsound, but there are few things left I can do about those. > I also urge any Wine audio development to stay in touch with general > developments in Linux audio. The wineasio driver is already good enough > to draw some Windows users into the fold. That driver gives them ´ > low-latency close to native performance (i.e. with ASIO), and a variety > of Windows sound and music apps can now be run in a production capacity. > I have nothing against incorporating wineasio, as long as you can get someone to maintain it once it's in, rather then let it slowly bitrot away, but if wineasio and winejack do the same, it would make sense to make 1 of the 2 go. > The issue of VST support is a show-stopper for many musicians who would > like to switch platforms. For a while, the FST project provided a nice > bridge that allowed running VST/VSTi plugins as standalone programs, but > a long-standing X-related bug (since at least the 0.9.3x series) has > gutted FST's capability. So at this time, if a user wants to use VST > plugs he can either use FST with an older Wine, or he can use a new > version with the wineasio driver. Btw, both solutions depend on JACK. > Have you considered filing a bug report, and do a regression test? It's easy to do and would allow you to find the exact cause of the glitch, and if it's obvious you could even fix it yourself. > A bit of a ramble, but I hope I've made my point. Sound support in Wine > is an important aspect of its development, and many users are currently > thwarted in their attempts to leave Windows simply because their > favorite sound-apps can't be run in Wine. I don't expect to see Cubase > or Logic running under the system any time soon, but it would be a cool > thing to look forward to eventually happening. :) > I agree. Cheers, Maarten

Oct. 10, 2007

Re: mshtml #3: Added support for installing Gecko from the local file.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > WINE_DEFAULT_DEBUG_CHANNEL(mshtml); > > +#define GECKO_FILE_NAME "wine_gecko-" GECKO_VERSION ".cab" > +#define DEFAULT_CAB_FILE_NAME "/usr/share/wine/gecko/" GECKO_FILE_NAME You need to use wine_get_data_dir() instead of hardcoding the path. -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007

Re: What happened to the Wine Newsletters?

by Francois Gouget

On Sun, 7 Oct 2007, Martin Bosner wrote: [...] > There are just not enough human resources fot that... But the > releasenews for each new wine version should cover most interesting > things that had happened. The short way. I guess this was mostly humorous, but still, I feel compelled to say that: The release news are no substitute for the Wine Weekly News. They are not even close. They are just one-line summaries of the top-5 changes in the release. Besides the other 5 top-10 items they miss, they don't mention any of the discussions happening on wine-devel, nor any of the talk about Wine in the news, or upcoming WineConfs, application database improvements, etc. The WWN was really nice. I fear that without it the wider community and outsiders mostly see the 5 lines release news and think that not much is happening (or think that we only work on obscure/useless stuff due to lack of context), or at least have pretty much no idea what is going on. WWN provided a very useful service to Wine by letting them get a glimpse of the life of the project. Unfortunately, not having the skills or the time required, I can only hope that some kind soul can fill that void soon. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

Oct. 10, 2007

Re: [Bug 9962] wine ntfs-3g segfaults

by Kai Blin

On Wednesday 10 October 2007 11:34:55 wine-bugs(a)winehq.org wrote: Taking this to the mailing list, as it shouldn't be discussed on the bug. > Vitaliy: what functionality specifically do you need from ntfs-3g? Shared > writable mmap support indeed needs an extra kernel patch which is not in > mainline yet but we are not aware of any other widely needed feature. We're > developing ntfs-3g, so people can run application directly from NTFS using > wine. Szabolcs, the biggest reason why we don't tell people to run applications from an NTFS partition is not strictly a technical one but just the fact that people then try to run applications they installed under windows. This will fail for almost every application that depends on certain registry entries being created by the install process. I don't know what other features Vitaly was talking about. Perhaps you can elaborate on that here, Vitaly? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Oct. 10, 2007

Re: ftp.c: skip tests if we can't connect to ftp.winehq.org

by Alexandre Julliard

Dimi Paun <dimi(a)lattica.com> writes: > diff --git a/dlls/wininet/tests/ftp.c b/dlls/wininet/tests/ftp.c This doesn't work for me: ../../../tools/runtest -q -P wine -M wininet.dll -T ../../.. -p wininet_test.exe.so ftp.c && touch ftp.ok ftp.c:790: Test failed: InternetConnect failed : 12015 wine: Unhandled page fault on read access to 0x0067006e at address 0x60568d4e (thread 0009), starting debugger... WineDbg starting on pid 0008 Unhandled exception: page fault on read access to 0x0067006e in 32-bit code (0x60568d4e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:60568d4e ESP:0033fd30 EBP:0033fd68 EFLAGS:00010206( - 00 - RIP1) EAX:0067006e EBX:60580718 ECX:60586ca0 EDX:60586ca4 ESI:00670046 EDI:00126320 Stack dump: 0x0033fd30: 001100b8 60580718 0033fd68 60568190 0x0033fd40: 60586ca0 00000000 0033fd58 60586ca0 0x0033fd50: 00125558 00000000 00125528 60580718 0x0033fd60: 00000001 6052d1d2 0033fd98 6056a8df 0x0033fd70: 00000001 00000000 00000000 00000000 0x0033fd80: 6052d201 6052d1d2 00000000 6053815c Backtrace: =>1 0x60568d4e WININET_FreeHandle+0xbe(hinternet=0x1) [/home/julliard/wine/wine/dlls/wininet/internet.c:222] in wininet (0x0033fd68) 2 0x6056a8df InternetCloseHandle+0x3f(hInternet=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/wininet/internet.c:1021] in wininet (0x0033fd98) 3 0x60514dea func_ftp+0x19fa() [/home/julliard/wine/wine/dlls/wininet/tests/ftp.c:860] in wininet_test (0x0033fe58) 4 0x6052c938 run_test+0x128(name=0x1103e8) [/home/julliard/wine/wine/dlls/wininet/tests/../../../include/wine/test.h:389] in wininet_test (0x0033fea8) 5 0x6052cfcd main+0x14d(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/wininet/tests/../../../include/wine/test.h:437] in wininet_test (0x0033fed8) 6 0x6052d09b __wine_spec_exe_entry+0x5b(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in wininet_test (0x0033ff08) 7 0x7b8746ce start_process+0xee(arg=0x0) [/home/julliard/wine/wine/dlls/kernel32/process.c:839] in kernel32 (0x0033ffe8) 8 0x600289a7 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x60568d4e WININET_FreeHandle+0xbe [/home/julliard/wine/wine/dlls/wininet/internet.c:222] in wininet: movl 0x28(%esi),%edx 222 LIST_FOR_EACH_ENTRY_SAFE( child, next, &info->children, WININETHANDLEHEADER, entry ) Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

Oct. 10, 2007