June 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 5/5] d3dcompiler: Parse variable declarations.

by Matteo Bruni

2012/6/5 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am Montag, 4. Juni 2012, 17:58:24 schrieb Matteo Bruni: >> +struct hlsl_type >> +{ >> ... >> + unsigned int dimx; >> + unsigned int dimy; >> ... >> +}; > One thing I noticed when I wrote my compiler was that a float1x1 is not the > same as a float1 or float. I did not implement this difference nor do I know > if any games depend on it. > > (That's no reason to hold up this patch, just something to keep in mind for > further work) > Yeah, I noticed that too, but it doesn't seem to make much of a difference in practice. Of course, if later on it shows that it actually matters for something relevant, I'll change things accordingly.

June 5, 2012

Re: oleaut32: Add a test for BSTR cache. Take 3.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > That doesn't seem very useful. What use case would there be for an app > to rely on some random 75% of its strings to remain valid? Although the test is about statistics, my intention was to show that BSTR cache in Wine corrupts cached strings. I could try to figure out exact steps which lead to corruption of real strings the application cares about, but that's pretty hard to do, there are enourmous amount of lines in the log that are related to BSTR creation/destruction, and finally the string the app cares about and tries to use is corrupted. I thought that adding a statistical test would hint Jacek what might be wrong with current cache implementation. -- Dmitry.

June 5, 2012

Re: [PATCH 1/5] wined3d: Use NAN.

by Francois Gouget

On Mon, 4 Jun 2012, Ruslan Kabatsayev wrote: > Hello, > > This patch stops wine from building on my system with following errors: > > In file included from arb_program_shader.c:35:0: > wined3d_private.h: In function ‘float_16_to_32’: > wined3d_private.h:203:21: error: ‘NAN’ undeclared (first use in this function) > wined3d_private.h:203:21: note: each undeclared identifier is reported > only once for each function it appears in I sent a patch that should fix this. Did I miss some bit? commit 19ba80e7c2c9ef054ef5faa921616a5d43f6578d Author: Francois Gouget <fgouget(a)free.fr> Date: Fri Jun 1 16:56:21 2012 +0200 wined3d: We must include Wine's port.h before using NAN. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

June 5, 2012

Re: oleaut32: Add a test for BSTR cache. Take 3.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > + for (i = 0; i < sizeof(bstr)/sizeof(bstr[0]); i++) > + { > + INTERNAL_BSTR *data = Get(bstr[i]); > + > + for (j = 0; j < i; j++) str[j] = '0' + i % 10; > + > + if (data->dwLen == i * sizeof(WCHAR)) > + good_length_entries++; > + if (!memcmp(data->szString, str, i * sizeof(WCHAR))) > + good_string_entries++; > + } > + > + trace("good_length_entries %d, good_string_entries %d\n", good_length_entries, good_string_entries); > + ok(good_length_entries >= 95, "good_length_entries %d out of 256\n", good_length_entries); > +todo_wine > + ok(good_string_entries >= 190, "good_string_entries %d out of 256\n", good_string_entries); That doesn't seem very useful. What use case would there be for an app to rely on some random 75% of its strings to remain valid? -- Alexandre Julliard julliard(a)winehq.org

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Hin-Tak Leung

--- On Tue, 5/6/12, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: > The issue is access from linux native code to the .net > framework. <snipped> Please stop your anti-mono ranting. You have no idea what you are talking about. wine-mono is an modified version of a *win32* build of mono. wine-mono does not interact with linux native code at all. It is a win32 PE build of mono. Got it?

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Michael Stefaniuc

On 06/05/2012 08:53 AM, Max TenEyck Woodbury wrote: > The issue is access from linux native code to the .net > framework. That should require a specific decision on the > part of the system administrator to make it available. It is > that package that I believe is called 'mono'. I have taken > steps to assure that it never appears on the systems I run. > > Providing a .net framework to MSWindows platform applications > that I want to run on my systems is another mater. Wine > should provide that framework on demand but that is NOT > 'mono'. The Wine .net support does NOT make the .net > framework available to native linux application. (If it That's *exactly* what wine-mono *IS*. Unlike before this is the Windows version of mono and thus unusable from Linux. > IS provided a part of the wine migration library, I will > grumble but not scream about it.) bye michael

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Francois Gouget

On Mon, 4 Jun 2012, Max TenEyck Woodbury wrote: [...] > A native MSWindows application that wants .net support would either > connect to the installed dll that provides the required services or > install such a dll. It would know nothing about 'mono'. It is only > non-MSWindows platform programs that will try to link to the > non-MSWinows libraries in 'mono'. > > So an MSWindows executable looking for .net support needs .net support, > NOT mono. [...] You obviously have absolutely no idea what the wine-mono package is for. You should read up and apologize. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ question = ( to ) ? be : ! be; -- Wm. Shakespeare

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Max TenEyck Woodbury

On 06/05/2012 01:50 AM, Hin-Tak Leung wrote: > --- On Mon, 4/6/12, Max TenEyck Woodbury<max(a)mtew.isa-geek.net> wrote: > >> On 06/04/2012 03:05 AM, Frédéric >> Delanoy wrote: >>> On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegel<dank(a)kegel.com> >> wrote: >>>> On Sun, Jun 3, 2012 at 11:20 PM, Frédéric >> Delanoy >>>> <frederic.delanoy(a)gmail.com> >> wrote: >>>>> On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel<daniel.r.kegel(a)gmail.com> >> wrote: >>>>>> http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh >>>>>> now also installs mono. ... >>>>> >>>>> Wouldn't it be better (and more acceptable for >>>>> people disliking/wanting to avoid mono) to >>>>> - keep install-gecko.sh as is >>>>> - create install-mono.sh >>>>> - create wine-install-addons.sh calling the >>>>> former ? >>>> >>>> The point of this script is to make life easier for >>>> me and for the average user. It's not to make life >>>> easier for people who don't like mono, mostly >>>> because I doubt there are many of them. >>> My comment was not only meant for "mono-haters", but it >>> can also be useful IMHO to split e.g. to limit download >>> size when one doesn't even need mono, and it maybe >>> clearer as well ("addons" is pretty generic). >>> >>> Frédéric >>> >>> >> >> Actually, it really is the name that matters. 'mono' >> is a lightning rod for a lot of political history. >> If you were to integrate the same functions into >> Wine itself, and hopefully avoid tripping over the >> stinking Microsoft patents, that set of problems can be >> avoided, >> >> A native MSWindows application that wants .net support would >> either connect to the installed dll that provides the >> required services or install such a dll. It would know >> nothing about 'mono'. It is only non-MSWindows platform >> programs that will try to link to the non-MSWinows >> libraries in 'mono'. >> >> So an MSWindows executable looking for .net support needs >> .net support, NOT mono. We can and should provide such >> executables the services they need. However we should >> NOT make it easy for programs from other platforms to >> fall into the stinking Microsoft Patent trap. That >> gateway to hell is called 'mono' and we should NOT open it. > > This is irrational bias against mono. The fact is that, > since Vista, .Net Framework runtime is shipped as standard > in windows. Therefore any windows application has a > reasonable expectation of assuming .Net runtime to be > around, and not prompt the user to go and download the > .net runtime from microsoft. Athough some application does >explicitly test for the presence of .net runtime and make >the user go and download it from microsoft when it cannot >detect such or when the version of net runtime is too low >(i.e. if the user tries to install such software on XP). > > Granted the authentic MS .net runtime can be installed and >works well enough under wine; but would you rather the >user goes and download genuine MS .net and install it on >wine? If you say downloading .net runtime and using that on >linux is preferable from your point of view, I have nothing >more to say... > The issue is access from linux native code to the .net framework. That should require a specific decision on the part of the system administrator to make it available. It is that package that I believe is called 'mono'. I have taken steps to assure that it never appears on the systems I run. Providing a .net framework to MSWindows platform applications that I want to run on my systems is another mater. Wine should provide that framework on demand but that is NOT 'mono'. The Wine .net support does NOT make the .net framework available to native linux application. (If it IS provided a part of the wine migration library, I will grumble but not scream about it.) The problem is the lawyers and senior management at Microsoft. They have been caught laying traps for anything competitive with their products. There are 'markers' that they use to make springing their trap easier. One of those markers is the name 'mono'. The people who built the original 'mono' have been identified as Microsoft shills. They have NOT kept their development environment clean. It is known to be contaminated with Microsoft's 'IP'. Wine, on the other hand, has tried quite hard to prevent contamination by Microsoft 'IP'. I am seriously concerned that accepting anything with the name 'mono' on it will have the appearance of being contaminated, and even more important, might cause some developers to relax their standards and inadvertently accept pieces from the 'mono' project instead of doing a clean re-implementation.

June 5, 2012

Re: [PATCH 5/5] d3dcompiler: Parse variable declarations.

by Stefan Dösinger

Am Montag, 4. Juni 2012, 17:58:24 schrieb Matteo Bruni: > +struct hlsl_type > +{ > ... > + unsigned int dimx; > + unsigned int dimy; > ... > +}; One thing I noticed when I wrote my compiler was that a float1x1 is not the same as a float1 or float. I did not implement this difference nor do I know if any games depend on it. (That's no reason to hold up this patch, just something to keep in mind for further work)

June 5, 2012

Re: http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh also installs mono

by Hin-Tak Leung

--- On Mon, 4/6/12, Max TenEyck Woodbury <max(a)mtew.isa-geek.net> wrote: > On 06/04/2012 03:05 AM, Frédéric > Delanoy wrote: > > On Mon, Jun 4, 2012 at 8:35 AM, Dan Kegel<dank(a)kegel.com> > wrote: > >> On Sun, Jun 3, 2012 at 11:20 PM, Frédéric > Delanoy > >> <frederic.delanoy(a)gmail.com> > wrote: > >>> On Sun, Jun 3, 2012 at 7:02 PM, Dan Kegel<daniel.r.kegel(a)gmail.com> > wrote: > >>>> http://winetricks.googlecode.com/svn/trunk/src/install-gecko.sh > now > >>>> also installs mono. ... > >>> > >>> Wouldn't it be better (and more acceptable for > people > >>> disliking/wanting to avoid mono) to > >>> - keep install-gecko.sh as is > >>> - create install-mono.sh > >>> - create wine-install-addons.sh calling the > former > >>> ? > >> > >> The point of this script is to make life easier for > me and > >> for the average user. It's not to make life > easier for > >> people who don't like mono, mostly because I doubt > >> there are many of them. > > > > My comment was not only meant for "mono-haters", but it > can also be > > useful IMHO to split e.g. to limit download size.when > one doesn't even > > need mono, and it maybe clearer as well ("addons" is > pretty generic). > > > > Frédéric > > > > > > Actually, it really is the name that matters. 'mono' > is a lightning > rod for a lot of political history. If you were to > integrate the same > functions into Wine itself, and hopefully avoid tripping > over the > stinking Microsoft patents, that set of problems can be > avoided, > > A native MSWindows application that wants .net support would > either > connect to the installed dll that provides the required > services or > install such a dll. It would know nothing about > 'mono'. It is only > non-MSWindows platform programs that will try to link to > the > non-MSWinows libraries in 'mono'. > > So an MSWindows executable looking for .net support needs > .net support, > NOT mono. We can and should provide such executables > the services they > need. However we should NOT make it easy for programs > from other > platforms to fall into the stinking Microsoft Patent > trap. That > gateway to hell is called 'mono' and we should NOT open it. This is irrational bias against mono. The fact is that, since Vista, .Net Framework runtime is shipped as standard in windows. Therefore any windows application has a reasonable expectation of assuming .Net runtime to be around, and not prompt the user to go and download the .net runtime from microsoft. Athough some application does explicitly test for the presence of .net runtime and make the user go and download it from microsoft when it cannot detect such or when the version of net runtime is too low (i.e. if the user tries to install such software on XP). Granted the authentic MS .net runtime can be installed and works well enough under wine; but would you rather the user goes and download genuine MS .net and install it on wine? If you say downloading .net runtime and using that on linux is preferable from your point of view, I have nothing more to say...

June 5, 2012