April 2010 - Wine-Devel - list.winehq.org

Re: Another proposal for your critique: improving .NET 3.5

by Roderick Colenbrander

On Thu, Apr 1, 2010 at 7:24 PM, Vincent Povirk <madewokherd+8cd9(a)gmail.com> wrote: >> If you want to do something in the .NET area perhaps some work can be >> done on Mono integration (see the mono topic Vincent started) and the >> wiki (http://wiki.winehq.org/Mono) > > While this has the advantage of being an area where no one has done > any serious work yet (and therefore, there is likely low-hanging > fruit), I don't know how you could focus this so that the scope is > clear and it is easily quantified. > > I also don't have a sense yet of what working on Mono in Wine is like. > I'm still a Mono noob, as I've done no real development there. > > I think that something useful could come out of such a project, but I > cannot predict what. > Perhaps there are some apps which mix .NET and win32 (I mean mixing in a nice way and not overriding wndproc and evil stuff). Years ago Paint.NET was ported over to Mono. I don't remember what they did but I guess they mainly removed some win32isms. The code to paint.net used to be available (I think the 3.0 source still is). You could check if it is a well behaving .NET app which uses win32. Getting Paint.NET working on mono+wine could be a good test case. Note since both of you are in MSP that might have advantages as well. Roderick

April 1, 2010

Re: winedump: code cleanup

by Alexandre Julliard

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > Hello, > > Could you clear a little what do you mean under "stop abusing"? > I've removed incorrect usage of constness in declaration for the > variable that is changed for sure. > I've send "try 2" patch with additional correction and extended log > message. I mean your new origProtoRef variable (which BTW uses a completely different naming convention from the rest of the function) to work around the fact that the argument is modified. Much better to use a properly named local variable to store results and not modify the argument. -- Alexandre Julliard julliard(a)winehq.org

April 1, 2010

Re: Another proposal for your critique: improving .NET 3.5

by Vincent Povirk

> If you want to do something in the .NET area perhaps some work can be > done on Mono integration (see the mono topic Vincent started) and the > wiki (http://wiki.winehq.org/Mono) While this has the advantage of being an area where no one has done any serious work yet (and therefore, there is likely low-hanging fruit), I don't know how you could focus this so that the scope is clear and it is easily quantified. I also don't have a sense yet of what working on Mono in Wine is like. I'm still a Mono noob, as I've done no real development there. I think that something useful could come out of such a project, but I cannot predict what.

April 1, 2010

Re: Mono integration

by Vincent Povirk

> AFAIK mono doesn't implement WPF, so any .NET app that uses it is likely to > fail in mono. Correct me if i'm wrong This is true, and according to http://www.mono-project.com/Compatibility they have no plans to implement it. But someone could, and even if the mono project doesn't want it, it would be useful for Wine.

April 1, 2010

Re: Mono integration

by Louis Lenders

> > > The compatibility information basically indicates that Mono can substitute > > for .NET below version 3.0. 3.0 and higher still needs Microsoft's > > implementation. > > How would you handle hybridizing Mono with Microsoft's framework? > > You would need different wine prefixes if you want to use both at once. > > What is the problem with 3.0, and can't it be fixed? > > AFAIK mono doesn't implement WPF, so any .NET app that uses it is likely to fail in mono. Correct me if i'm wrong Vincent Povirk <madewokherd+8cd9 <at> gmail.com> writes:

April 1, 2010

Re: Mono integration

by Vincent Povirk

> The compatibility information basically indicates that Mono can substitute > for .NET below version 3.0. 3.0 and higher still needs Microsoft's > implementation. > How would you handle hybridizing Mono with Microsoft's framework? You would need different wine prefixes if you want to use both at once. What is the problem with 3.0, and can't it be fixed?

April 1, 2010

Re: Another proposal for your critique: improving .NET 3.5

by Roderick Colenbrander

On Thu, Apr 1, 2010 at 6:31 PM, John Koelndorfer <jkoelndorfer(a)gmail.com> wrote: >> This is not something within GSOC scope in my opinion, I expect you will >> need 6 weeks alone to get up to speed with the concepts of msi and patching. >> >> In general I think it's better to identify a small set of APIs to implement >> or improve instead of aiming for a broad goal like "improving .net 3.5", >> which is hard to quantify and more likely to fail. >> >> -Hans > > Thanks for the input, Hans. Looking back at previous GSOC proposals, > many of them were "Improve x" (see > http://wiki.winehq.org/SummerOfCode/PreviousProjects) > > As far as the issue of quantification, I think it's pretty easy to say > "if .NET 3.5 installs, that's a success. If applications that require > .NET 3.5 run (or aren't blocked by anything .NET), that's a success." > Hell, even if I don't get .NET to install -- so long as I've made > progress on it and it makes it that much easier for another developer, > I'd call that a success. > > The issue of difficulty is something I've thought about. As I've > mentioned, I don't have any Wine-specific experience so I am not well > able to gauge how reasonable a given project is. > > I'm hearing very mixed opinions on some of them so I think at this > point my best bet is to submit several proposals for projects I'm > interested in and then do my best to see whichever is accepted through > (if it is even accepted). I remember reading somewhere that as long as > I work hard, not completely meeting my goals would not be an issue. > Given that, I'd rather set the bar high as I think that would be > better motivation. > > Again, thanks to everyone for their input. I will submit the proposals > I have written and will probably write/submit a few more. > > If you want to do something in the .NET area perhaps some work can be done on Mono integration (see the mono topic Vincent started) and the wiki (http://wiki.winehq.org/Mono) Roderick

April 1, 2010

Re: Mono integration

by Sir Gallantmon (ニール・ゴンパ)

On Thu, Apr 1, 2010 at 11:27 AM, Vincent Povirk <madewokherd+8cd9(a)gmail.com<madewokherd%2B8cd9(a)gmail.com> > wrote: > >> * If an installer for something other than .NET tries to install .NET, > >> file a bug for that with the dotnet keyword. > > > > For any .Net version (1.1, 2.0, 3.5)? Does that also count for service > > packs? I take it your recent work on mscoree should fake a dotnet > > installation? > > Any .NET version. Mono 2.6 supports all of those (see > http://www.mono-project.com/Compatibility) > > My work on mscoree so far has done basically nothing. There is a > Dotnet section in wine.inf that installs some registry keys that > satisfy some installers. > > >> * Someone other than me, please try to make a Windows build of Mono > >> and run the Mono test suite under Wine. I want to make sure that the > >> instructions make sense and that someone other than me can do this. > > > > I'll try to do that this in the next few days/weekend. > > Thanks. > > > The compatibility information basically indicates that Mono can substitute for .NET below version 3.0. 3.0 and higher still needs Microsoft's implementation. How would you handle hybridizing Mono with Microsoft's framework?

April 1, 2010

Re: Another proposal for your critique: improving .NET 3.5

by John Koelndorfer

> This is not something within GSOC scope in my opinion, I expect you will > need 6 weeks alone to get up to speed with the concepts of msi and patching. > > In general I think it's better to identify a small set of APIs to implement > or improve instead of aiming for a broad goal like "improving .net 3.5", > which is hard to quantify and more likely to fail. > > -Hans Thanks for the input, Hans. Looking back at previous GSOC proposals, many of them were "Improve x" (see http://wiki.winehq.org/SummerOfCode/PreviousProjects) As far as the issue of quantification, I think it's pretty easy to say "if .NET 3.5 installs, that's a success. If applications that require .NET 3.5 run (or aren't blocked by anything .NET), that's a success." Hell, even if I don't get .NET to install -- so long as I've made progress on it and it makes it that much easier for another developer, I'd call that a success. The issue of difficulty is something I've thought about. As I've mentioned, I don't have any Wine-specific experience so I am not well able to gauge how reasonable a given project is. I'm hearing very mixed opinions on some of them so I think at this point my best bet is to submit several proposals for projects I'm interested in and then do my best to see whichever is accepted through (if it is even accepted). I remember reading somewhere that as long as I work hard, not completely meeting my goals would not be an issue. Given that, I'd rather set the bar high as I think that would be better motivation. Again, thanks to everyone for their input. I will submit the proposals I have written and will probably write/submit a few more.

April 1, 2010

Re: Mono integration

by Vincent Povirk

>> * If an installer for something other than .NET tries to install .NET, >> file a bug for that with the dotnet keyword. > > For any .Net version (1.1, 2.0, 3.5)? Does that also count for service > packs? I take it your recent work on mscoree should fake a dotnet > installation? Any .NET version. Mono 2.6 supports all of those (see http://www.mono-project.com/Compatibility) My work on mscoree so far has done basically nothing. There is a Dotnet section in wine.inf that installs some registry keys that satisfy some installers. >> * Someone other than me, please try to make a Windows build of Mono >> and run the Mono test suite under Wine. I want to make sure that the >> instructions make sense and that someone other than me can do this. > > I'll try to do that this in the next few days/weekend. Thanks.

April 1, 2010