Re: Fw: selinux in fedora 10 regarding text relocation in wine and mono.
Hi all, I had managed to fix my selinux/wine/mono problem in fedora 10... it is actually two issues, in fact: 1) fedora 10 ships some much stricter selinux policies (but make some exception for wine). 2) I have kernel support for miscellaneous binary formats enabled and have win32 PE registration in the kernel, and run win32 mono.exe (or other PE executables) direct from time to time. so wine [path]/mono.exe [.NET.exe] works within the restriction of f10 selinux policies, but [path]/mono.exe [.NET.exe] does not. I could either relax the execmod policy in selinux, if I want to run any PE .exe's wholesale; or I just need to remember always putting wine in front of PE .exe's I want to run... Sorry for the noise.
Fw: selinux in fedora 10 regarding text relocation in wine and mono.
I sent this a few days ago from my other e-mail alias and it hasn't come back, so it probably got lost in the spam-filtering - anybody has similiar issue? So I have upgraded to fedora 10... now when I run wine with mono for some .Net application I get selinux blocking it, saying: - The mscorsvw.exe application attempted to load /home/Hin-Tak/.wine/drive_c/windows/Microsoft.NET/Framework/v2.0.50727/mscorsvw.exe which requires text relocation. This is a potential security problem. Most libraries do not need this permission. Libraries are sometimes coded incorrectly and request this permission. -- And a few other similar errors. Should I file this with redhat with their shipped policy, wine or mono? I guess it should be with redhat, but somehow I have the impression that I might be asked to file this with wine-devel. Any thoughts on this?
Re: wine gdiplus - mono gdiplus wrapper
On Jan 3, 2008 4:42 AM, Ove Kaaven [EMAIL PROTECTED] wrote: Dan Kegel skrev: On Jan 2, 2008 2:57 PM, Reece Dunn [EMAIL PROTECTED] wrote: Are there any plans to use cairo in the Wine gdiplus implementation like mono does? Not that I know of. But I don't think that's a problem. I think a more interesting question is, when are we going to buckle down and implement a DIB engine? Maybe use cairo there... an advanced GDI-like DIB engine is part of it. It probably isn't pixel-for-pixel identical to the Windows GDI. Damjan
re: wine gdiplus - mono gdiplus wrapper
Jerome wrote: I wrote a little script in order to wrap gdiplus with the mono one; Here are the source file and the spec file (this one made with winedump), but I have no idea how to compile it and/or include it in the wine source tree. Could you tell me what you think about it ? And if it has some utility ? IIRC, the Mono gdiplus isn't so useful for us because it doesn't deal with GDI handles the way we need. That's one reason we have our own gdiplus now. It might be more useful if you would look at fixing bugs in our gdiplus rather than trying to wrap Mono's. - Dan
Re: wine gdiplus - mono gdiplus wrapper
On Jan 2, 2008 2:57 PM, Reece Dunn [EMAIL PROTECTED] wrote: Are there any plans to use cairo in the Wine gdiplus implementation like mono does? Not that I know of. But I don't think that's a problem. I think a more interesting question is, when are we going to buckle down and implement a DIB engine? - Dan
Re: wine gdiplus - mono gdiplus wrapper
Dan Kegel skrev: On Jan 2, 2008 2:57 PM, Reece Dunn [EMAIL PROTECTED] wrote: Are there any plans to use cairo in the Wine gdiplus implementation like mono does? Not that I know of. But I don't think that's a problem. I think a more interesting question is, when are we going to buckle down and implement a DIB engine? Maybe use cairo there... an advanced GDI-like DIB engine is part of it.
Re: Wine and Mono
Jonathan Ernst wrote: .exe files are often associated with Wine so that it's easy for users to double click a windows application and have it working like any native application. Wouldn't it be possible for Wine to detect .Net application and run them using mono (mono app.exe) instead of just failing ? According to an MSDN article ( http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx ), .NET executables are just PE executables that happen to be linked against MSCOREE.DLL. Perhaps Wine could detect an attempt to load that DLL and call Mono instead. In theory a program could execute arbitrary code first and then have too much state to pass to Mono safely, but if a lot of these applications are mechanically generated stubs it might not be a problem. If that's not wanted, would it be at least possible to issue a message to tell the user that the application he'is trying to run is a .Net application and that he should try running it using mono ? What are your opinions about the handling of .Net executables ? I tried running a .NET application the other day and it gave me a nice error-message (on the console) telling me that I needed to install .NET. Now that Wine is finally, officially, in a numbered release, it might be a good idea to reopen the question of Wine/Mono dynamic linking or other cooperation. For an example of the bad feelings that some .NET users have about WIne, take a look at the last post (the one dated 10-15-2005, 6:55) on http://community.sharpdevelop.net/forums/1310/ShowPost.aspx (note: SharpDevelop is an open-source .NET development environment.) -- DLL
Wine and Mono
Hi, .exe files are often associated with Wine so that it's easy for users to double click a windows application and have it working like any native application. Wouldn't it be possible for Wine to detect .Net application and run them using mono (mono app.exe) instead of just failing ? If that's not wanted, would it be at least possible to issue a message to tell the user that the application he'is trying to run is a .Net application and that he should try running it using mono ? What are your opinions about the handling of .Net executables ? Thanks. -- Jonathan Ernst [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
