A wine-gecko package would be very useful.
Wine-mono on the other hand is probably premature. How many apps are helped at the moment by winetricks mono12 ? I don't think it's a large number.
The wine-gecko package should just be a repackaging of the same blob that is normally downloaded, at least until we figure out how to do a proper cross-build.
Dan Kegel wrote:
A wine-gecko package would be very useful.
Wine-mono on the other hand is probably premature. How many apps are helped at the moment by winetricks mono12 ? I don't think it's a large number.
Honestly I don't know. Is this due to inadequacies in the current mono, or inadequacies in Wine?
Either way, Mono 2.0 will finally come out around the same time as Wine 1.0 (quarter 2 of 2008), and I suspect the number of applications Mono helps will greatly improve by then.
The wine-gecko package should just be a repackaging of the same blob that is normally downloaded, at least until we figure out how to do a proper cross-build.
Agreed. The one tricky thing here is making a proper "source" package. There is some precedent for source packages that don't actually build on the architecture they're for. The ia32-libs package, for instance, contains both binary and source versions of the 32 bit libraries since it's solely for 64 bit arches, however to build those binaries requires use of a 32 bit system.
Similarly, we can ship a wine-gecko "source" package which includes binary and source, with the readme detailing how to actually build the binary from the source (ie, use Windows). Meanwhile the source package "builds" by just copying the binary into the right place (much like how ia32-libs builds).
Thanks, Scott Ritchie
On Thu, Apr 10, 2008 at 7:40 PM, Scott Ritchie scott@open-vote.org wrote:
Wine-mono on the other hand is probably premature. How many apps are helped at the moment by winetricks mono12 ? I don't think it's a large number.
Honestly I don't know. Is this due to inadequacies in the current mono, or inadequacies in Wine?
Mono doesn't even try to handle mixed-mode assemblies (i.e. ones that contain some native code). And by gum, every .net app built by Microsoft tools seems to include some native code for some odd reason. Go figure!
Either way, Mono 2.0 will finally come out around the same time as Wine 1.0 (quarter 2 of 2008), and I suspect the number of applications Mono helps will greatly improve by then.
Maybe, but only apps that have been properly cleaned of native code. - Dan
Dan Kegel wrote:
On Thu, Apr 10, 2008 at 7:40 PM, Scott Ritchie scott@open-vote.org wrote:
Wine-mono on the other hand is probably premature. How many apps are helped at the moment by winetricks mono12 ? I don't think it's a large number.
Honestly I don't know. Is this due to inadequacies in the current mono, or inadequacies in Wine?
Mono doesn't even try to handle mixed-mode assemblies (i.e. ones that contain some native code). And by gum, every .net app built by Microsoft tools seems to include some native code for some odd reason. Go figure!
Is this true even for the Windows version of Mono? If Mono is supposed to be a replacement for what the .net framework provides, then it seems like duplicating this functionality on Windows (and therefore Wine) would be part of it.
I did some searching as for why this is the case. This link: http://www.jprl.com/Blog/archive/development/mono/2008/Jan-27.html indicates that the main issue is the loader supporting PE files, which is what Wine already does.
Either way, Mono 2.0 will finally come out around the same time as Wine 1.0 (quarter 2 of 2008), and I suspect the number of applications Mono helps will greatly improve by then.
Maybe, but only apps that have been properly cleaned of native code.
- Dan
Hmm...it seems like gluing Mono and Wine together would require a bit more collaboration than the two projects have.
Thanks, Scott Ritchie
Dan Kegel wrote:
On Thu, Apr 10, 2008 at 7:40 PM, Scott Ritchie scott@open-vote.org
wrote:
Wine-mono on the other hand is probably premature. How many apps are helped at the moment by winetricks mono12 ? I don't think it's a large number.
Honestly I don't know. Is this due to inadequacies in the current
mono,
or inadequacies in Wine?
Mono doesn't even try to handle mixed-mode assemblies (i.e. ones that contain some native code). And by gum, every .net app built by Microsoft tools seems to include some native code for some odd reason. Go figure!
Is this true even for the Windows version of Mono? If Mono is supposed to be a replacement for what the .net framework provides, then it seems like duplicating this functionality on Windows (and therefore Wine) would be part of it.
I did some searching as for why this is the case. This link: http://www.jprl.com/Blog/archive/development/mono/2008/Jan-27.html indicates that the main issue is the loader supporting PE files, which is what Wine already does.
Either way, Mono 2.0 will finally come out around the same time as
Wine
1.0 (quarter 2 of 2008), and I suspect the number of applications Mono helps will greatly improve by then.
Maybe, but only apps that have been properly cleaned of native code.
- Dan
Hmm...it seems like gluing Mono and Wine together would require a bit more collaboration than the two projects have.
Thanks, Scott Ritchie
For a part the issue is that lots of programs are hybrid ones. Some of them behave 'nicely' in the way they just call a few functions from a native win32 dll. I think apps that embed COM objects (like a Word viewer, ..) are worse as mono doesn't offer this at all. The most problematic thing is that mono's windows.forms is fully managed while microsoft just layered it on top of gdi32/gdiplus/user32. This allows you to use standard win32 apis on most windows.forms controls to override behavior. A lot of apps do this, so even if you could access native win32 dlls, magic like this won't work at all. Second COM objects might also rely on evil win32 magic.
All in all mono only works on a few well behaved apps and most don't behave well. PersonallY I think a win32 mono package for wine is nearly useless.
Roderick
On Fri, Apr 11, 2008 at 8:50 AM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
For a part the issue is that lots of programs are hybrid ones. Some of them behave 'nicely' in the way they just call a few functions from a native win32 dll. I think apps that embed COM objects (like a Word viewer, ..) are worse as mono doesn't offer this at all. The most problematic thing is that mono's windows.forms is fully managed while microsoft just layered it on top of gdi32/gdiplus/user32. This allows you to use standard win32 apis on most windows.forms controls to override behavior. A lot of apps do this, so even if you could access native win32 dlls, magic like this won't work at all. Second COM objects might also rely on evil win32 magic.
Rather than ignoring mono these issues make it sound like Wine and mono should try to work together again. The EULA for the .NET runtime prohibits distributing it and using it on non-windows licensed systems so we are in much the same legal situation with IE where we have to have a replacement.
On Sun, Apr 13, 2008 at 10:11 AM, Steven Edwards winehacker@gmail.com wrote:
Rather than ignoring mono these issues make it sound like Wine and mono should try to work together again. The EULA for the .NET runtime prohibits distributing it and using it on non-windows licensed systems so we are in much the same legal situation with IE where we have to have a replacement.
Yes, exactly. I've been discussing this a bit on the mono list.
There are two big pieces of work needed: 1) support for mixed assemblies in Mono for Windows 2) porting Mono's WinForms on top of Wine gdiplus instead of Mono gdiplus (and making it more win32-ish as a result)
This would be a fine summer project for somebody properly motivated.
There will be more incentive to do this as we get Microsoft .NET working better, and it becomes clearer just how many applications need one or the other of the two items above to run.
In short: I think the path to Mono+Wine nivana at the moment leads directly through enemy territory: we have to get MS .net working better first before it's clear it'll be worth it. - Dan
Hi,
- support for mixed assemblies in Mono for Windows
I'm trying to do some work on that.
- porting Mono's WinForms on top of Wine gdiplus
instead of Mono gdiplus (and making it more win32-ish as a result)
Mono is using MS GDI+ on Windows since it uses GDI+. Mono's libgdiplus is only used on non-Windows platforms. If Wine's GDI+ is not supported by Mono (I haven't tried) it's Wine's GDI+ that has to be fixed because Mono works perfectly with MS GDI+.
I also suggested on mono-devel-list that process creation and module loading for managed modules should be supported by ntdll.dll via callbacks to mscoree.dll as described in http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027491.html
Kornél
On Sun, Apr 13, 2008 at 12:55 PM, Kornél Pál kornelpal@gmail.com wrote:
- support for mixed assemblies in Mono for Windows
I'm trying to do some work on that.
Cool!
- porting Mono's WinForms on top of Wine gdiplus
instead of Mono gdiplus (and making it more win32-ish as a result)
Mono is using MS GDI+ on Windows since it uses GDI+. Mono's libgdiplus is only used on non-Windows platforms.
I guess I assumed that Mono used native WinForms on Windows, and that its winforms code was only used on Linux. I clearly don't know enough about Mono to discuss it intelligently :-)
I also suggested on mono-devel-list that process creation and module loading for managed modules should be supported by ntdll.dll via callbacks to mscoree.dll as described in http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027491.html
That's interesting info, thanks.
At the moment you seem to be taking the lead on these issues. Please let us know how it goes. - Dan
--- On Sun, 13/4/08, Dan Kegel dank@kegel.com wrote: <snipped>
- porting Mono's WinForms on top of Wine
gdiplus
instead of Mono gdiplus (and making it more
win32-ish as
a result)
Mono is using MS GDI+ on Windows since it uses GDI+.
Mono's libgdiplus is
only used on non-Windows platforms.
I guess I assumed that Mono used native WinForms on Windows, and that its winforms code was only used on Linux. I clearly don't know enough about Mono to discuss it intelligently :-)
<snipped>
I can't comment on anything else, but after trying to get a .NET WinForms application (mentioned in some of the bugs I filed) for a few months under the 3 options of native linux mono, wine+.NET and wine+mono, I can say that win32 mono uses P/Invoke *differently* from how .NET2 does it, and the missing APIs required to get an application to work with the wine + win32 mono and wine +MS.NET combo is different. So some part of the applications runs better with wine + win32 mono and some better with wine + MS.NET ... win32 mono and MS.NET just seems to have different native code dependencies.
___________________________________________________________ Yahoo! For Good helps you make a difference
Hi,
From: "Hin-Tak Leung" htl10@users.sourceforge.net I can't comment on anything else, but after trying to get a .NET WinForms application (mentioned in some of the bugs I filed) for a few months under the 3 options of native linux mono, wine+.NET and wine+mono, I can say that win32 mono uses P/Invoke *differently* from how .NET2 does it, and the missing APIs required to get an application to work with the wine + win32 mono and wine +MS.NET combo is different. So some part of the applications runs better with wine + win32 mono and some better with wine + MS.NET ... win32 mono and MS.NET just seems to have different native code dependencies.
The only major difference I know is that Mono uses UTF-8 instead of ACP for ANSI functions. If you know some serious issues please feel free to file bug report(s) at Mono's Bugzilla.
From: "Dan Kegel" dank@kegel.com
http://lists.ximian.com/pipermail/mono-devel-list/2008-April/027491.html
That's interesting info, thanks.
At the moment you seem to be taking the lead on these issues. Please let us know how it goes.
I have made some progess and now I am able to call unmanaged methods from managed methods and also implemented some mscoree.dll hacks that make possible to use the NT loader (LoadLibrary). Unfortunately the loader uses mscoree.dll located in system32 anyway so I had to modify it's export address table in memory. And I also had to implement base relocation and import adress table processing for EXE modules because that is not done by NT. Processes could only be created from managed EXE files with some more intrusive mscoree.dll hacks (mscoree.dll file or registy modifications).
Kornél
"Kornél Pál" kornelpal@gmail.com wrote:
The only major difference I know is that Mono uses UTF-8 instead of ACP for ANSI functions.
UTF-8 will break most of Windows applications since they don't expect to see strings in a multibyte encoding.
The only major difference I know is that Mono uses UTF-8 instead of ACP for ANSI functions.
UTF-8 will break most of Windows applications since they don't expect to see strings in a multibyte encoding.
I know that. And the problem is that there is a mess of ACP and UTF-8 inside native code of Mono. I tried to change things several times but none of them were accepted.
Kornél
On Sun, Apr 13, 2008 at 10:11 AM, Steven Edwards winehacker@gmail.com wrote:
Rather than ignoring mono these issues make it sound like Wine and mono should try to work together again. The EULA for the .NET runtime prohibits distributing it and using it on non-windows licensed systems so we are in much the same legal situation with IE where we have to have a replacement.
Yes, exactly. I've been discussing this a bit on the mono list.
There are two big pieces of work needed:
- support for mixed assemblies in Mono for Windows
- porting Mono's WinForms on top of Wine gdiplus
instead of Mono gdiplus (and making it more win32-ish as a result)
This would be a fine summer project for somebody properly motivated.
There will be more incentive to do this as we get Microsoft .NET working better, and it becomes clearer just how many applications need one or the other of the two items above to run.
In short: I think the path to Mono+Wine nivana at the moment leads directly through enemy territory: we have to get MS .net working better first before it's clear it'll be worth it.
- Dan
What we really need is mono's windows.forms to be layered on top of gdi32 and user32 for windows controls like buttons, textboxes and so on .. As lots of programs do overrides using native dlls on them, so that's why it should be real windows controls with a wndproc.
Ironically the current situation is for a part our own issue. Years ago Mono's windows.forms used winelib. They moved to a managed implementation because they had wine integration issues and we weren't that cooperative. Further they didn't like the 2d performance much (likely due to the lack of a dib engine ..). They might be reluctant to Wine.
Roderick
On Sun, Apr 13, 2008 at 11:14 PM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
What we really need is mono's windows.forms to be layered on top of gdi32 and user32 for windows controls like buttons, textboxes and so on .. As lots of programs do overrides using native dlls on them, so that's why it should be real windows controls with a wndproc.
Ironically the current situation is for a part our own issue. Years ago Mono's windows.forms used winelib. They moved to a managed implementation because they had wine integration issues and we weren't that cooperative. Further they didn't like the 2d performance much (likely due to the lack of a dib engine ..). They might be reluctant to Wine.
Yup. We have to really get our act together, then undoing the fork might make sense.
Hi,
I am almost complete with implementing mixed-mode support for Mono only some code cleanup is remaining. Note that however this still will not support MSVCRT becuase that assumes that is running on .NET Framework. Also note that applications using unmanaged API (COM interfaces and DLL exports) of .NET Framework will not be compatible with Mono because those APIs are not implemented by Mono.
If my patch will be accepted you will see the changes in SVN trunk of Mono.
From: "Dan Kegel" dank@kegel.com
On Sun, Apr 13, 2008 at 11:14 PM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
What we really need is mono's windows.forms to be layered on top of gdi32 and user32 for windows controls like buttons, textboxes and so on .. As lots of programs do overrides using native dlls on them, so that's why it should be real windows controls with a wndproc.
Ironically the current situation is for a part our own issue. Years ago Mono's windows.forms used winelib. They moved to a managed implementation because they had wine integration issues and we weren't that cooperative. Further they didn't like the 2d performance much (likely due to the lack of a dib engine ..). They might be reluctant to Wine.
Yup. We have to really get our act together, then undoing the fork might make sense.
Undoing the fork is not that easy because the current System.Windows.Forms uses it's own rendering engine and low level parts have been completely rewritten to support platform independent rendering and message processing. It supports low level WndProc functionality but I don't know how much is it compatible with Microsoft's implementation.
Kornél
Scott Ritchie skrev:
Agreed. The one tricky thing here is making a proper "source" package. There is some precedent for source packages that don't actually build on the architecture they're for. The ia32-libs package, for instance, contains both binary and source versions of the 32 bit libraries since it's solely for 64 bit arches, however to build those binaries requires use of a 32 bit system.
Similarly, we can ship a wine-gecko "source" package which includes binary and source, with the readme detailing how to actually build the binary from the source (ie, use Windows). Meanwhile the source package "builds" by just copying the binary into the right place (much like how ia32-libs builds).
Debian would not accept this into main. Perhaps into contrib, maybe. For example, DFSG-free Java programs that must be compiled with a non-free Java compiler (because the free compilers aren't good enough) goes into contrib, not main (though even here, it should be possible to auto-rebuild the package).
Debian's ia32-libs package isn't an example of a whole lot. It grabs compiled binaries from the official Debian archive, and nowhere else. It isn't built on a 32-bit system. If ia32-libs had contained binaries that could not be built 100% automatically using Debian's official archive (and only the official archive), it probably wouldn't have gotten into Debian. Besides, ia32-libs is not meant to be a long-lived package, it'll go away eventually.
Ove Kaaven wrote:
Debian's ia32-libs package isn't an example of a whole lot. It grabs compiled binaries from the official Debian archive, and nowhere else. It isn't built on a 32-bit system. If ia32-libs had contained binaries that could not be built 100% automatically using Debian's official archive (and only the official archive), it probably wouldn't have gotten into Debian. Besides, ia32-libs is not meant to be a long-lived package, it'll go away eventually.
We've been saying that for 3 years now, and we've only become MORE dependent on ia32-libs in the process. The chief culprit, of course, is Wine, and Wine's need to run 32 bit applications isn't going away soon.
Really, what Debian (and Ubuntu) need is to replace the contents of the ia32-libs package with proper 32 versions of package (sorta like how lib32asound and lib32z1 are now). Fixing that, however, is a bit beyond the scope of the wine-devel list ;)
Thanks, Scott Ritchie
On Wed, 16 Apr 2008 06:52:49 -0700 Scott Ritchie scott@open-vote.org wrote:
Ove Kaaven wrote:
Debian's ia32-libs package isn't an example of a whole lot. It grabs compiled binaries from the official Debian archive, and nowhere else. It isn't built on a 32-bit system. If ia32-libs had contained binaries that could not be built 100% automatically using Debian's official archive (and only the official archive), it probably wouldn't have gotten into Debian. Besides, ia32-libs is not meant to be a long-lived package, it'll go away eventually.
We've been saying that for 3 years now, and we've only become MORE dependent on ia32-libs in the process. The chief culprit, of course, is Wine, and Wine's need to run 32 bit applications isn't going away soon.
Really, what Debian (and Ubuntu) need is to replace the contents of the ia32-libs package with proper 32 versions of package (sorta like how lib32asound and lib32z1 are now). Fixing that, however, is a bit beyond the scope of the wine-devel list ;)
The real problem with multi-arch libs is, that it's hard to maintain inside debian packages at all...not that it's difficult to compile on amd64 with -m32 , but regarding the different ways of debian/rules writing with all different maintainer ways to write Makefiles for accomplishing this tasks is the most difficult thing.
When there are people interested in going a hard way of fixing todays situation in debian/ubuntu and other distris, please let's do it , sane and with a plan.
Regards, \sh
Stephan Hermann skrev:
When there are people interested in going a hard way of fixing todays situation in debian/ubuntu and other distris, please let's do it , sane and with a plan.
There's already work going on to try to get a better solution into Debian lenny. There's a new "ia32-libs-tools" package about to enter Debian unstable, which would make it possible to replace the big ia32-libs package with more fine-grained individual ia32-lib* packages. (It may not be true multiarch, but still a lot better than the current situation.)
-
Dan Kegel -
Dmitry Timoshkov -
Hin-Tak Leung -
Kornél Pál -
Ove Kaaven -
Roderick Colenbrander -
Scott Ritchie -
Stephan Hermann -
Steven Edwards