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

Re: Allow enabling/disabling Direct3D usage of GLSL in Winecfg + update Czech locales for Winecfg

by Tom Wickline

On 3/29/07, H. Verbeet <hverbeet(a)gmail.com> wrote: > On 29/03/07, Ivan Gyurdiev <ivg231(a)gmail.com> wrote: > > Do you want to make it easy to configure GLSL, or make it easy to enable > > GLSL? > > In other words, can you enumerate the cases where one would disable GLSL? > > Should those be in a document somewhere on the wiki as blockers to 1.0 > > (since GLSL default was pointed out as a 1.0 requirement)? > > Do we expect this option to be around for a long time? > > > > I don't see consensus to add these options in the referenced thread - if > > more testing exposure is needed, why not just enable this by default? > > > IMO the only reasons for having this option would be for specifically > testing the ARB backend, or working around broken drivers. I don't > think either warrants an option in winecfg. I agree, if you add GLSL why not add everything? DirectDrawRenderer, RenderTargetLockMode, Nonpower2Mode, OffscreenRenderingMode and have a D3D tab? Why not take this a step further and add the ability to force drawStridedFast instead of drawStridedSlow ? This would be really nice :) http://www.winehq.org/pipermail/wine-devel/2007-March/055419.html IMHO if we add one of the many options that are available we should add all of them... > > The video memory setting could be useful though, since I don't think > we're going to solve that soon. > > > -- Tom Wickline Respectable computing - Linux/FOSS

March 29, 2007

Re: Excluding a Windows version from the tests

by Robert Shearman

Alexandre Julliard wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > >> yesterday a patch of mine was committed to test more profile stuff >> from kernel32. When I have a look now at test.winehq.org I see that >> some test(s) crash on win98 but not on others. >> >> Although I could use a if(0) construction (as is done in several other >> tests), I'm wondering if we should just not run specific tests on >> specific Windows versions. It's a shame that one OS version blocks the >> running of several other tests. >> > > In general, if a feature crashes on Windows it's unlikely that an app > would depend on it, so it's not a problem to disable or remove the > test. > Unfortunately, these days apps are coded for NT only and I would expect new applications to only be supported on XP upwards. However, I guess until we see a real application that confirms this, it is all hand-waving theory. -- Rob Shearman

March 29, 2007

Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.

by Sasan Iman

Thank you all for your replies. First of all, my conspiracy accusation was meant more as a joke than a real belief. Being a hardcore engineer myself, albeit not in your domain, I appreciate the hard work and dedication that goes into these types of projects. Second, the explanation about running Office requiring special hacks makes a lot of sense so from a technical point of view, I understand the reason for having a side release (through Codeweaver) for running Office. But third, I must say that even though I agree with your general comments that Wine is not targeted to an application but is meant to be a core implementation, but I think having the top most used windows software working on Wine out of the box will do wonders for its popularity (I have no proof for this other than the fact that I personally don't run wine because I can't run Office and I have tried 6-7 times in the last 3 years every time hoping the new release will do the trick). I don't know how much effort it would take to get Office working on Wine but if getting it to work out-of-the-box means putting it on many more systems (leading to more people getting interested, more mileage leading to more bug reports, more people finding reason to get involved to fix bugs, etc.) then the extra effort may well be worth it. And let me say that Office alternatives on linux are not really a solution at this point. For example, even though OpenOffice is good for writing documents from scratch, documents' look and feel is different in OpenOffice than Word and that just forces me to find a Windows machine every time I need to open a Word document. I don't really know how many people like me are out there. If I am the only one, then I am wasting your times. But if there are many others like me, then I don't think any of you will argue against the benefits and the priority of having Office work in the stock release. Maybe a good way to approach this is to put up a survey or a poll on WineHQ and ask people if they'd use Wine if software X and Y and Z was running out-of-the-box? That way you'd also find out how many non-technical people are following Wine to solve their computing needs. Thanks again for your hard works. I've been cheering you guys on for a few years and will continue to do so. Sasan Brian Vincent wrote: > On 3/28/07, Sasan Iman <iman(a)simantis.com> wrote: >> I know that if you fiddle around with the stock release long enough you >> can get MS Office working on Wine as I have on a number of occasions, >> but shouldn't making this work for everyone be the highest priority for >> getting Wine to be adopted more widely?! Or is Wine more targeted to >> gamers which is mostly what I read about on WineHQ? > > CodeWeavers isn't Evil. I think everyone involved in Wine would agree > with that. There is absolutely no question that without their > involvement several core pieces of Wine probably wouldn't exist. For > example, MSI, COM, MSHTML, etc. We'd probably still have a good > Direct3D implementation though because Stefan is sick like that. > > As far as getting Office to work, you and everyone else are more than > welcome to work on that. We even have a free graphical regression > testing system (cxtest) that CodeWeavers developed that could help you > maintain that. Personally, I'd be ecstatic if you'd be willing to > work on that. > > Finally, I wouldn't exactly say Wine is targeted at gamers any more > than anything else. > > -Brian

March 29, 2007

Re: Is Wine a platform for Codeweaver to make money?! Please help me understand.

by Brian Vincent

On 3/28/07, Sasan Iman <iman(a)simantis.com> wrote: > I know that if you fiddle around with the stock release long enough you > can get MS Office working on Wine as I have on a number of occasions, > but shouldn't making this work for everyone be the highest priority for > getting Wine to be adopted more widely?! Or is Wine more targeted to > gamers which is mostly what I read about on WineHQ? CodeWeavers isn't Evil. I think everyone involved in Wine would agree with that. There is absolutely no question that without their involvement several core pieces of Wine probably wouldn't exist. For example, MSI, COM, MSHTML, etc. We'd probably still have a good Direct3D implementation though because Stefan is sick like that. As far as getting Office to work, you and everyone else are more than welcome to work on that. We even have a free graphical regression testing system (cxtest) that CodeWeavers developed that could help you maintain that. Personally, I'd be ecstatic if you'd be willing to work on that. Finally, I wouldn't exactly say Wine is targeted at gamers any more than anything else. -Brian

March 29, 2007

Re: extracting info from a minidump via winedbg

by Dennis Schridde

Am Donnerstag, 29. März 2007 schrieb Eric Pouech: > Dennis Schridde a écrit : > > Hello Wine users! > > > > I've got a minidump from a ("real") Windows user of our game and would > > like to extract information from it using winedbg. > > > > > > The information winedbg gives me by default, is this: > > > > [...] > > > > Which is pretty rare. > > Via addr2line I can translate the backtrace to possibly valid locations > > in our sourcefiles. > > > > > > My questions are: > > - Why doesn't winedbg extract the sourcecode locations itself? > > because it needs the original PE files (.exe, .dll) to get to the debug > information > those files must be seated in directories listed in the _NT_SYMBOL_PATH > environment variable Maybe I am just doing it wrong, but _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp doesn't change anything... (Even supplying the full path doesn't.) The exe (not all dlls, because I don't have a copy of the user's system) is of course in the working directory. > > - Why doesn't winedbg show me the other information included in the > > minidump, like the loaded modules, commandline options or version > > information? > > 'info share' should do part of it... winedbg doesn't show the command > line info nor options That only shows me the memory ranges of some modules. The minidump includes more info, like the paths to dlls and similar. I am not sure whether it includes version information, but it certainly contains the commandline used to start the app. > other thing you can do is to use winedump (man winedump) How do I do this? And what will it provide? I tried winedump -G warzone2100.exe but I have no idea what I shall do with that tremedously long and cryptic list. > > - How can I get the parameters to the last called function(s)? > > see above for debug info If the general debug info worked, that would also show me the function parameters? --Dennis

March 29, 2007

Re: Excluding a Windows version from the tests

by Stefan Dösinger

> Sure; the thing we want to avoid is version checks in tests, because > then things don't get tested on Wine when the version is changed. But > as long as win98 is detected by its missing features then skipping > things is fine. Shouldn't then the wine code do a version check too and behave differently if the winver is set to win98?

March 29, 2007

Re: Excluding a Windows version from the tests

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > So if we only have crashes on win9x we don't care. If we can avoid > crashes/failures on win9x (by skip or other means) we don't run them > on win9x. And if they crash on something higher then win9x we disable > them totally. > > Does that make sense? Sure; the thing we want to avoid is version checks in tests, because then things don't get tested on Wine when the version is changed. But as long as win98 is detected by its missing features then skipping things is fine. -- Alexandre Julliard julliard(a)winehq.org

March 29, 2007

Re: Excluding a Windows version from the tests

by Paul Vriens

Alexandre Julliard wrote: > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > >> But in this case we're dealing with win98 which new apps will not support anymore! > > Of course the alternative is to simply stop worrying about test > failures on win98... > I agree with that one. So if we only have crashes on win9x we don't care. If we can avoid crashes/failures on win9x (by skip or other means) we don't run them on win9x. And if they crash on something higher then win9x we disable them totally. Does that make sense? Cheers, Paul.

March 29, 2007

Re: extracting info from a minidump via winedbg

by Eric Pouech

Dennis Schridde a écrit : > Hello Wine users! > > I've got a minidump from a ("real") Windows user of our game and would like to > extract information from it using winedbg. > > > The information winedbg gives me by default, is this: > > WineDbg starting on minidump on pid 068c > warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) > Register dump: > CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS:0000 > EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) > EAX:c7b054d8 EBX:19ff502e ECX:00000040 EDX:0000000f > ESI:02010101 EDI:00000000 > Stack dump: > 0x0022f844: 00000000 00000000 00000000 3f800000 > 0x0022f854: 00000000 0022f8c8 0050e796 19ff502e > 0x0022f864: 3f800000 00000000 00000000 00000000 > 0x0022f874: 00000000 00000000 00000000 ff4a4a4a > 0x0022f884: 00000005 02010101 00000000 00000000 > 0x0022f894: 00000000 0022f8c8 00000000 00000000 > Backtrace: > =>1 0x0051008b (0x0022f858) > 2 0x0050e796 (0x0022f8c8) > 3 0x00410c3b (0x0022f948) > 4 0x0041172d (0x0022f9c8) > 5 0x004b2272 (0x0022f9d8) > 6 0x004aa97b (0x0022f9f8) > 7 0x004b615a (0x0022fab8) > 8 0x004b663f (0x0022fad8) > 9 0x004b67e1 (0x0022faf8) > 10 0x0041e39e (0x0022fb28) > 11 0x00459d3e (0x0022fb58) > 12 0x0045b2ee (0x0022fca8) > 13 0x0055e77b (0x0022fcf8) > 14 0x0055e932 (0x0022fef8) > 15 0x0055e483 (0x0022fff0) > 16 0x00000000 (0x00000000) > WineDbg starting on pid 068c > > > Which is pretty rare. > Via addr2line I can translate the backtrace to possibly valid locations in our > sourcefiles. > > > My questions are: > - Why doesn't winedbg extract the sourcecode locations itself? > because it needs the original PE files (.exe, .dll) to get to the debug information those files must be seated in directories listed in the _NT_SYMBOL_PATH environment variable > - Why doesn't winedbg show me the other information included in the minidump, > like the loaded modules, commandline options or version information? > 'info share' should do part of it... winedbg doesn't show the command line info nor options other thing you can do is to use winedump (man winedump) > - How can I get the parameters to the last called function(s)? > see above for debug info A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

March 29, 2007

Re: Excluding a Windows version from the tests

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > But in this case we're dealing with win98 which new apps will not support anymore! Of course the alternative is to simply stop worrying about test failures on win98... -- Alexandre Julliard julliard(a)winehq.org

March 29, 2007