wine-devel December 2008

wine-devel@winehq.org

150 participants
305 discussions

Better user feedback and better user experience (idea)
by Sander Devrieze 19 Dec '08

19 Dec '08

Hi, One of the reasons why Linux distributions do not want to include Wine by default is because compatibility issues may result a bad impression of the quality of the OS. Users think Linux sucks because their Windows application does not run (as good) under Wine as it does under Windows. Problem: Windows applications ran by Wine do not always run without issues and the user does not know why. Hence, (s)he will think this is because Linux is less stable than Windows. What do Wine coders think about solving the issue by adding a user feedback interface to Wine? It may for instance work like this: * By default open a user feedback dialog after the application is closed (or crashes). In this dialog, the user will be explained why this dialog is shown, and why he might have experienced bugs or crashes in the Windows application. The user also can provide text feedback and other types of feedback (e.g. a checkbox saying "The application crashed"). * The user has the option to send this information to the Wine project by hitting a button. Gathered information will be integrated in the Wine application database and can be helpful for Wine coders and users. Advantages: * Users will better understand why their application did not run as well on Linux as on Windows. * Wine will become more interesting to be actively supported by Linux distributors. * Users will feel they easily can contribute to the Wine project. * The Wine project will receive more feedback. Other subidea: Create a database with hashes of .exe files. Wine can consult this database *before* it executes a Windows binary and provide the user with feedback like this: "Remark that 60% of users were not satisfied when running this application in this Wine version. Do you want to proceed?" Or like this: "This application has these issues: ... Do you want to proceed?" -- Kind Regards, Sander Devrieze.

6 9

implicit declaration of function '_mkdir'
by Gerald Pfeifer 18 Dec '08

18 Dec '08

I am mostly offline (2s ping times) for another two weeks, but noticed the following starting a couple of days ago on my nightly FreeBSD 6.4 tester: server.c:755: warning: implicit declaration of function '_mkdir' shellpath.c:2163: warning: implicit declaration of function '_mkdir' shfldr_unixfs.c:1745: warning: implicit declaration of function '_mkdir' xdg.c:253: warning: implicit declaration of function '_mkdir' theme.c:966: warning: implicit declaration of function '_mkdir' winemenubuilder.c:707: warning: implicit declaration of function '_mkdir' fd.c:1562: warning: implicit declaration of function '_mkdir' request.c:530: warning: implicit declaration of function '_mkdir' Perhaps one of you has an idea where this might come from and how to avoid it? Gerald

3 2

Re: winecfg volume serial number
by James Hawkins 18 Dec '08

18 Dec '08

On Thu, Dec 18, 2008 at 3:07 PM, Michael Ost <most(a)museresearch.com> wrote: > Michael Karcher wrote: >> >> Am Donnerstag, den 18.12.2008, 14:53 -0800 schrieb James Hawkins: >>> >>> I don't understand the problem. If you have the proper permissions, >>> wine should be able to read the volume name and everything should just >>> work. What does volname give you for the network-mounted image? >> >> He is not mounting an image, but a mounted CD-ROM drive. > > Right. > > [most@Deceptor ~]$ mount > (snip) > //x.y.z.w/remotex on /home/most/.wine/drive_x type cifs (rw,mand) > > [most@Deceptor ~]$ ll ~/.wine/dosdevices/ > total 0 > lrwxrwxrwx 1 most most 10 2008-12-18 11:56 c: -> ../drive_c > lrwxrwxrwx 1 most most 10 2008-12-17 11:34 x: -> ../drive_x > > GetVolumeInformation's CreateFile("\\\\.\\X:") call fails with status > c0000034. So it tries get_filesystem_label, which tries to read > "//x.y.z.w/remotex/.windows-label" via the symlinks. > > I can't write a file there so I can't fake in the label. > > My thought was to store the label in the registry and use that as a fallback > if there is no .windows-label file. I'm all ears for alternate approaches > though.... mo > Have you tried setting the drive type to CD in winecfg? -- James Hawkins

1 0

Re: ntdll: fix a compiler warning on PC-BSD
by Austin English 18 Dec '08

18 Dec '08

2008/12/18 Austin English <austinenglish(a)gmail.com>: > -- > -Austin > Ignore this patch, there are a few more I didn't notice. I'll update and resend. -- -Austin

1 0

Re: winecfg volume serial number
by Michael Ost 18 Dec '08

18 Dec '08

wine-devel-request(a)winehq.org wrote: > Date: Tue, 16 Dec 2008 13:52:00 +0100 From: "Hoehle, Joerg-Cyril" > <Joerg-Cyril.Hoehle(a)t-systems.com> Subject: winecfg volume serial > number To: <wine-devel(a)winehq.org> Message-ID: > <47CC5ABB01651443A88DB8EC5B4D657B01C8FD22(a)S4DE8PSAANK.mitte.t-com.de> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > I just sent a bug-fix to wine-patches to prevent a crash in winecfg > when editing the volume serial number input field, together with some > unrelated thoughts about winecfg and the device/volume serial number > handling. Then I realized that wine-patches is not a good place for > discussion. So here are the ideas about winecfg's GUI: It doesn't make sense to me to rely on writing to a file to set the windows serial number or label. What about readonly disks? I think those values should be in the registry. Or at least check the registry should be a fallback if .windows-serial or .windows-label does not exist. I am stuck now because an installer program is looking for a CD of a certain label. I can't fudge in the label because it's a CD that I can't write to. Is anyone working on this issue, or agree/disagree? ... mo

2 3

Re: jscript: Do not call memcpy() with a NULL pointer argument
by James Hawkins 18 Dec '08

18 Dec '08

On Thu, Dec 18, 2008 at 2:21 PM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > Changelog: > jscript: Do not call memcpy() with NULL pointer argument. > > diff --git a/dlls/jscript/string.c b/dlls/jscript/string.c > index eeceb1f..b49d3b3 100644 > --- a/dlls/jscript/string.c > +++ b/dlls/jscript/string.c > @@ -1395,8 +1395,12 @@ HRESULT create_string(script_ctx_t *ctx, const WCHAR *str, DWORD len, DispatchEx > return E_OUTOFMEMORY; > } > > - memcpy(string->str, str, len*sizeof(WCHAR)); > - string->str[len] = 0; > + if (str) { > + memcpy(string->str, str, len*sizeof(WCHAR)); > + string->str[len] = 0; > + }else { > + string->str[0] = 0; > + } > > *ret = &string->dispex; > return S_OK; > I didn't write jscript, so I'm not the expert, but create_string is internal, so we should probably crash if str is NULL instead of hiding the error. What is this patch for? -- James Hawkins

1 0

Re: [msvfw32/tests] Fix a test failure on W2K3
by Christian Costa 18 Dec '08

18 Dec '08

Hi Paul, You forgot to update the error messages. Christian Paul Vriens a écrit : > Hi, > > Pick a compressor that's available on all platforms for this > compressor type. > Ideally we would use ICInfo to enumerate and pick one that's available > but I > think that's a bit too much for now. > > (This is the last one to fix the regressions in the > conformance/regressions > tests on my boxes from the last commit round ;) ) > > Changelog > Fix a test failure on W2K3 > > ------------------------------------------------------------------------ > >

1 0

Unused vtables and debug channels
by Andrew Talbot 18 Dec '08

18 Dec '08

It appears that the following vtables and Wine debug channels are not being used, so I am considering removing them. Please let me know, therefore, if you have plans for any of them and want them kept. Vtables: IDirectXFileBinary_Vtbl d3dxof/d3dxof.c IDirectXFileObject_Vtbl d3dxof/d3dxof.c IDirectXFileSaveObject_Vtbl d3dxof/d3dxof.c DirectMusicPortDownload_Vtbl dmusic/portdownload.c DirectMusicThru_Vtbl dmusic/thru.c DirectMusicSegment8_Segment_Vtbl dswave/dswave.c AssemblyCacheItemVtbl fusion/asmcache.c AssemblyEnumVtbl fusion/asmcache.c InkCollectorVtbl inkobj/inkcollector.c HTMLInputTextElementVtbl mshtml/htmlinput.c MemInputPin_Vtbl quartz/nullrenderer.c OutputPin_Vtbl* quartz/pin.c InputPin_Vtbl* quartz/pin.c PullPin_Vtbl* quartz/pin.c MemInputPin_Vtbl quartz/transform.c MemInputPin_Vtbl quartz/videorenderer.c *Shadow variable(s) present. Wine debug channels in: comctl32/theme_button.c d3drm/math.c d3dx8/mesh.c d3dx9_24/d3dx9_24_main.c d3dx9_25/d3dx9_25_main.c d3dx9_26/d3dx9_26_main.c d3dx9_27/d3dx9_27_main.c d3dx9_28/d3dx9_28_main.c d3dx9_30/d3dx9_30_main.c d3dx9_31/d3dx9_31_main.c d3dx9_32/d3dx9_32_main.c d3dx9_33/d3dx9_33_main.c d3dx9_34/d3dx9_34_main.c d3dx9_35/d3dx9_35_main.c d3dx9_36/d3dx9_36_main.c d3dx9_37/d3dx9_37_main.c dmime/dmutils.c dmstyle/dmutils.c jscript/parser.tab.c kernel32/fiber.c kernel32/relay16.c msvcr71/msvcr71.c msvcrt40/msvcrt40.c ole32/oleproxy.c riched20/table.c secur32/schannel.c sxs/sxs.c winealsa.drv/waveinit.c winecoreaudio.drv/audiounit.c winecoreaudio.drv/coremidi.c Thanks, -- Andy.

7 15

WineD3D: add some new GL extensions
by Roderick Colenbrander 18 Dec '08

18 Dec '08

Hi, Add some new GL extensions which are needed for better d3d9 floating point support for R32F/RG32F and friends. Roderick -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a

2 2

Re: Better user feedback and better user experience (idea)
by Sander Devrieze 18 Dec '08

18 Dec '08

2008/12/18 Ben Klein <shacklein(a)gmail.com>: > 2008/12/18 Sander Devrieze <s.devrieze(a)linux.be>: >> 2008/12/17 Scott Ritchie <scott(a)open-vote.org>: >> <snip> >>> If it's that users blame the distro when it's a Wine problem, then we >>> can present them with some sort of information before installing (or >>> perhaps running) Wine. After that we should get out of the way and let >>> them use Wine as normal. > > Is it a goal for Wine to be included as standard in distros? I'd say > not. The correct solution is *nix-native applications. E.g., how many > people use utorrent in Wine when they could use Deluge or > Transmission? Sure, Wine's goal should include support for apps like > utorrent (in that Wine's goal is to run as many Windows apps as > possible), but they shouldn't be prefered over *nix-native apps. > >> Wine should go out of way when the Windows application is known to run >> very well under Wine or when the user submitted feedback for this >> application in the past. Also, the user easily can skip the dialog. > > Known by whom? Are you suggesting appdb scraping? No, I was thinking about including a list of hashes for the applications that are officially supported in the Wine distribution. >>> If the problem is that we're not getting enough feedback, then a default >>> feedback nag might not be the best answer either. >> >>> Writing an elaborate >>> system to tell us about known problems isn't particularly helpful; >> >> It shouldn't be an elaborate system: it can be as easy as asking the >> user to click on a button to send a list of API calls, used DLLs, a >> hash of the .exe binary, some critical information of his system, >> amongst others to the Wine project. User based input in the feedback >> form may or may not be a good thing; I just gave this as an example; >> it is no necessary element in what I am proposing. > > Sounds elaborate to me :) Though the winewatson sounds like it could > handle this sort of thing. > >> I guess this kind of feedback can be very powerful to Wine coders to >> create statistics like these: >> * Most popular API calls >> * Least popular API calls >> * Most common API calls that make applications fail >> * Unimplemented features used by very uncommon software (e.g. >> custom-built applications within companies) >> * Predicting the likelihood that a specific API call will be used when >> another API call is used in an application >> >> Maybe this information can be useful to detect which applications are >> affected by a bug in Wine. When this is known, testers can verify in >> multiple applications if the bug really is fixed in all applications. > > From what I've seen, most bugs in Wine aren't detectable by software - > it THINKS it's working fine, but the user can tell it's not :) In any > case, this would require a potentially large database of known bugs > and their symptoms ... I meant that this database can be used to see if a *manually* reported bug may also affect other applications. So, developers and testers can get a list of software that can be used to see if the bug is fixed. >>> reports from stable or nonlatest versions would be largely ignored, and >>> users of the latest beta can be asked to contribute in other ways, such >>> as on the download page itself. >>> >>> Remember, it doesn't take much work for us to know that an application >>> doesn't work - a single bug report can do that. Once we have that, we >>> don't need to ask a million other users (literally) for confirmation. >> >> Only geeks file good bug reports. Normal people don't care and will >> not spend energy on this. > > There's been a lot of talk recently about targeting Wine towards > end-users, e.g. the redesign of the website. It sounds like a great > idea, but Wine is still very much a developer's tool. It's not > user-friendly, and it won't be for a very long time, if ever. Most end-users primarily don't report bugs because they don't want to spend time on this. > winewatson sounds like a developer's debugging tool, but it could > prove useful for improving bad bug reports. > > Note that Microsoft has a system where any old application crash can > send a bug report to Microsoft. It's basically spamming yourself :) -- Mvg, Sander Devrieze.

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
31
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2008