Re: Mono?!?
On Fri, Jun 1, 2012 at 7:49 PM, Max TenEyck Woodbury wrote: > Microsoft does NOT > like the competition and has pulled stunts like their end-run to MosAid to > get around binding promises. Actually, I went to the MonoSpace conference last year, and guess where it was hosted: the MICROSOFT Nerd Center in Boston. There were also Microsoft employees in attendance, including the lead developer of the F# compiler, which by the way is a Microsoft technology that is free software and that actively tries to maintain compatibility with Mono. So, if Microsoft is unhappy about Mono as competition, they have a strange way of showing it. > Relying on ANY legal pronouncement by > Microsoft is even worse than relying on their technical pronouncements. I like how Wine is apparently OK in this regard, since Microsoft has made (to my knowledge) no statements regarding patents that they might control that would apply to Wine. If they promised not to sue us, then we'd really need to be worried.
Re: Mono?!?
On 06/01/2012 09:58 AM, Conan Kudo (ニール・ゴンパ) wrote: > On Fri, Jun 1, 2012 at 12:28 AM, Max TenEyck Woodbury > mailto:m...@mtew.isa-geek.net>> wrote: > > On 06/01/2012 12:40 AM, Conan Kudo (ニール・ゴンパ) wrote: > > > You realize that Microsoft has a legally binding irrevocable agreement > > to not assert patents on .NET implementations that comply with the > > standard, right? Mono falls under that. I wouldn't worry about patents > > when it comes to Mono. We're more likely to have problems on the Java > > side of things than with Mono. > > No, I do NOT 'realize' Microsoft has a legally binding irrevocable > agreement > > I have heard that such a thing exists, but with the recent debacle by > Oracle and tSCOg's treatment of 'irrevocable agreement"s, I do NOT > trust them to not find a way to get around such a pronouncement. > In fact I expect that they could simply ignore any such promise if they > found it convenient to do so and that they will do so eventually. > Further, there are enough weasel words in that pronouncement that I > think they plan to get nasty anyway. > > I realize ANYBODY can sue ANYBODY, but I prefer to stay clear of tar > pits like MONO when I can. > > (There is also an indication that .NET is a dead letter and MONO will > become unnecessary.) > > > Oracle could sue because its legal agreement for patents requires that > the implementation is derived from Oracle's completely and must be under > GPL. Other independent implementations are not protected. Microsoft's > protects all implementations that comply with published standards. You have that wrong. Google made no such agreements. Oracle sued anyway on the basis of copy right and patent infringement. They lost on BOTH counts, but it still cost Google tens of millions of dollars in legal fees and it still has a ways to run. I can't afford that. I suspect that anyone who is not operating on Google's scale can. Worse, Sun LIKED it that Google was trying for compatibility. Oracle bought Sun and the situation changed dramatically. Microsoft does NOT like the competition and has pulled stunts like their end-run to MosAid to get around binding promises. Relying on ANY legal pronouncement by Microsoft is even worse than relying on their technical pronouncements.
Re: Mono?!?
On Fri, 1 Jun 2012, Max TenEyck Woodbury wrote: [...] > (There is also an indication that .NET is a dead letter and MONO will > become unnecessary.) The impression I have been getting lately is that more and more Windows applications are using .Net in some way. Not that they are written from the ground up with .Net. But some business/productivity applications use it for addons or scripting and quite a few games use it for their launchers. So having a way to run these applications in Wine without requiring the users to first download and install Microsoft's .Net packages would be nice. This wine-mono package is a step in that direction. -- Francois Gouget http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
Re: [PATCH 1/4] server: Move completion from async object to async queue.
"Erich E. Hoover" writes: > Real Name: > Erich Hoover > > Description: > It seems that the completion information should be associated with > the async queue, rather than the async object, since the completion > information for a file handle can be updated after an async IO has > been queued. So, the attached patch moves the completion information > from the async object into the async queue so that we can properly > handle associating a completion with a file descriptor after an async > IO is queued (part 2). Does it even need to be stored in the queue then? Why not retrieve it from the fd when needed? -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
Alexandre Julliard wrote: > > What I have done is a comparison of screenshots of the affected application > > produced under Windows and Wine. If there will be a need in futher > > improvements > > I'll certainly have a look what can be enhanced. > > Once again, have you explicitly tested 32-pixel wide characters? > Obviously other sizes won't show the problem. No, I haven't specifically tested that case. I believe that I would have noticed a problem with the application I tested with. > >> > Besides, > >> > status of the patches was New, both for the test and this implementation. > >> > >> What has this got to do with anything? If your patch receives comments > >> you have to address them, I'm not going to review it if someone else > >> already did. > > > > Shouldn't the patch status reflect that? Or commenting on a patch > > automatically > > makes it rejected? > > It may or may not, depending on how you address the comments. Usually it > would become superseded once you send a fixed version. This clearly shows a lack of communication, which leads to dropping useful patches. Huw asked a question, I answered in belief that my response makes things clearer. Satus of the patch remained as 'New', which means "Patch not even looked at yet", 30 days have passed, the patch disappeared from the patch tracker. -- Dmitry.
Re: Mono?!?
On Fri, Jun 1, 2012 at 12:28 AM, Max TenEyck Woodbury wrote: > On 06/01/2012 12:40 AM, Conan Kudo (ニール・ゴンパ) wrote: > > > You realize that Microsoft has a legally binding irrevocable agreement > > to not assert patents on .NET implementations that comply with the > > standard, right? Mono falls under that. I wouldn't worry about patents > > when it comes to Mono. We're more likely to have problems on the Java > > side of things than with Mono. > > No, I do NOT 'realize' Microsoft has a legally binding irrevocable > agreement > > I have heard that such a thing exists, but with the recent debacle by > Oracle and > tSCOg's treatment of 'irrevocable agreement"s, I do NOT trust them to > not find a > way to get around such a pronouncement. In fact I expect that they > could simply > ignore any such promise if they found it convenient to do so and that > they will do so > eventually. Further, there are enough weasel words in that > pronouncement that I > think they plan to get nasty anyway. > > I realize ANYBODY can sue ANYBODY, but I prefer to stay clear of tar > pits like > MONO when I can. > > (There is also an indication that .NET is a dead letter and MONO will > become > unnecessary.) > Oracle could sue because its legal agreement for patents requires that the implementation is derived from Oracle's completely and must be under GPL. Other independent implementations are not protected. Microsoft's protects all implementations that comply with published standards.
Re: [PATCH 2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
Dmitry Timoshkov writes: >> Have you actually tested it with characters 32-pixel wide, and confirmed >> that Windows messes them up the same way? > > What I have done is a comparison of screenshots of the affected application > produced under Windows and Wine. If there will be a need in futher > improvements > I'll certainly have a look what can be enhanced. Once again, have you explicitly tested 32-pixel wide characters? Obviously other sizes won't show the problem. >> > Besides, >> > status of the patches was New, both for the test and this implementation. >> >> What has this got to do with anything? If your patch receives comments >> you have to address them, I'm not going to review it if someone else >> already did. > > Shouldn't the patch status reflect that? Or commenting on a patch > automatically > makes it rejected? It may or may not, depending on how you address the comments. Usually it would become superseded once you send a fixed version. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
Alexandre Julliard wrote: > >> You did get a comment from Huw that you need to allocate extra bytes, > >> you still haven't done that AFAICS. > > > > That was a just a question, to which I had answered. There are the tests, > > and the app which needs this functionality (and uses various fonts with > > different font sizes) works just fine with current approach. > > Have you actually tested it with characters 32-pixel wide, and confirmed > that Windows messes them up the same way? What I have done is a comparison of screenshots of the affected application produced under Windows and Wine. If there will be a need in futher improvements I'll certainly have a look what can be enhanced. > > Besides, > > status of the patches was New, both for the test and this implementation. > > What has this got to do with anything? If your patch receives comments > you have to address them, I'm not going to review it if someone else > already did. Shouldn't the patch status reflect that? Or commenting on a patch automatically makes it rejected? What about the test sent as 1/2? It has got no comments. -- Dmitry.
Re: [PATCH 2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
Dmitry Timoshkov writes: > Alexandre Julliard wrote: > >> > Any chance for at least a comment? >> >> You did get a comment from Huw that you need to allocate extra bytes, >> you still haven't done that AFAICS. > > That was a just a question, to which I had answered. There are the tests, > and the app which needs this functionality (and uses various fonts with > different font sizes) works just fine with current approach. Have you actually tested it with characters 32-pixel wide, and confirmed that Windows messes them up the same way? > Besides, > status of the patches was New, both for the test and this implementation. What has this got to do with anything? If your patch receives comments you have to address them, I'm not going to review it if someone else already did. -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
Alexandre Julliard wrote: > > Any chance for at least a comment? > > You did get a comment from Huw that you need to allocate extra bytes, > you still haven't done that AFAICS. That was a just a question, to which I had answered. There are the tests, and the app which needs this functionality (and uses various fonts with different font sizes) works just fine with current approach. Besides, status of the patches was New, both for the test and this implementation. -- Dmitry.
Re: [PATCH 2/2] gdi32: Add support for emulating bold faces of bitmap fonts. Take 2. Resend.
Dmitry Timoshkov writes: > Any chance for at least a comment? You did get a comment from Huw that you need to allocate extra bytes, you still haven't done that AFAICS. -- Alexandre Julliard julli...@winehq.org
size of wine packages
Hi, As we have crossed the 100MB installed size (stripped) for the Wine RPM packages (stripped), this makes a Wow64 capable installation taking around 200MB these days. Can we reduce this size? eg. kernel32.dll.so has 1.6MB of static data inside itself, which is puzzling me a bit. (winerror.res is 1.3MB, winerror.mc is 0.068 MB ... Huh? Translations blowing this up?) Out of 100MB /usr/lib/wine/, e.g. I have here 67 MB of .text (73MB on x86_64) 11 MB of .data (static data) Ciao, Marcus
