WineHQ css; binfmt && Mono && wine
Something broke on WineHQ. For some reason <br /> tags aren't getting parsed right - see this week's WWN for an example. It's displaying "<BR>". I haven't looked into it at all, but I figured someone (Dimi?) might remember messing with this stuff recently. Also, anyone happen to know if Wine can be used in conjunction with binfmt alongside Mono? Are there any unique C# identifiers in the first 128 bits of a .Net executable that could identify it? It appears the Mono guys recommend looking for the magic MZ bytes, which is exactly what Wine requires also. We can't look for "PE" since binfmt can only look at the first 127 bytes of a file. -Brian
fre, 20,.05.2005 kl. 00.35 -0600, skrev Brian Vincent:
Also, anyone happen to know if Wine can be used in conjunction with binfmt alongside Mono? Are there any unique C# identifiers in the first 128 bits of a .Net executable that could identify it? It appears the Mono guys recommend looking for the magic MZ bytes, which is exactly what Wine requires also. We can't look for "PE" since binfmt can only look at the first 127 bytes of a file.
A technique once proposed for the Debian packages is to make binfmt start a wrapper program, which further examines the file, then launches Wine or Mono as appropriate. If implemented, this would be handled by the distro, not by Wine itself, but it's up to you what you like...
On Fri, 20 May 2005 08:32:28 -0400, Ove Kaaven wrote:
A technique once proposed for the Debian packages is to make binfmt start a wrapper program, which further examines the file, then launches Wine or Mono as appropriate. If implemented, this would be handled by the distro, not by Wine itself, but it's up to you what you like...
It'd be better to have this as a separate mini upstream project hosted at SourceForge or the like, rather than a custom distro hack. I think I've seen such wrappers before, we really just need to get them more organised. thanks -mike
IMO, the right way to make it work is to enable closer integration of the two projects. We tried Mono using Wine, and that failed, but Wine has so far not tried using Mono. How about asking the Mono project to seperate their mono/io-layer Win32 implementation into a shared library, rather than statically linking it as they do in Mono 1.0.2 (ok, maybe be a litle old), then have a Wine implementation of mscoree.dll load libmono.so? Probably not as simple as that, but maybe there's a way forward? Mike
On Sat, 2005-05-21 at 00:43 +0900, Mike McCormack wrote:
IMO, the right way to make it work is to enable closer integration of the two projects. We tried Mono using Wine, and that failed, but Wine has so far not tried using Mono.
That's a big failure on our part (as well as theirs). Doing it the other way around is not scalable, there are many projects that can potentially use Wine. We need to fix this properly. The problem is that the only "official" way we support usage of Winelib is to require that the app using Wine becomes a Winelib application. I can easily see how this is not acceptable in a lot of instances. Now our reasoning for doing so is simple: if you use Winelib on i386, you probably want to make use of native DLLs, which means you need to set up the process binary environment appropriately, and hence you need to make your app a Winelib app. This however places a hard dependency on Wine, and who will accept that? Let's face it, we're not there yet, and even if we were it's still conceptually problematic. What people really want is to able to simply do: $CC -o myapp -lwine or even better: ... void *wine = dlopen("wine"); if (wine) { ... } This is what we need to provide. You see, right now we offer the most functionally reach Winelib, but at a high usage point. I can image lots of use cases where people would go for a bit less functionality (say no native DLLs) if they could use Winelib as described above. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
On Sat, 21 May 2005 07:07:53 -0400, Dimi Paun wrote:
On Sat, 2005-05-21 at 00:43 +0900, Mike McCormack wrote:
IMO, the right way to make it work is to enable closer integration of the two projects. We tried Mono using Wine, and that failed, but Wine has so far not tried using Mono.
That's a big failure on our part (as well as theirs). Doing it the other way around is not scalable, there are many projects that can potentially use Wine. We need to fix this properly.
Wine using Mono could work, but I'm not sure people really want to have both installed (and we don't want Wine and Mono fighting over EXE file associations!). The simplest solution is just to pull Debians helper thingy upstream and recommend packagers depend on that in their packages, IMHO. Wine may need to use Mono at some point but it's been years and not many apps have a heavy .NET dependency yet. thanks -mike
On Sat, 2005-05-21 at 12:18 +0100, Mike Hearn wrote:
The simplest solution is just to pull Debians helper thingy upstream and recommend packagers depend on that in their packages, IMHO. Wine may need to use Mono at some point but it's been years and not many apps have a heavy .NET dependency yet.
The problem is that Mono really needs Wine to be able to do a good job. But because we didn't provide a workable solution they went ahead and redid the GDI, controls, you name it. This is just wasted effort. They will probably get "close", but will never be "good enough". They just fail to understand that. Nevertheless, a lot of effort will be wasted, and we as a community will be years behind providing a good solution. Sigh. Not to mention that we (the Wine project) lost a huge contributor. If only a fraction of that effort would have been put into improving the controls say, we would have been in a much better place. I really think we need to put more effort in addressing this properly. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
Dimi Paun wrote:
This is just wasted effort. They will probably get "close", but will never be "good enough". They just fail to understand that. Nevertheless, a lot of effort will be wasted, and we as a community will be years behind providing a good solution. Sigh.
Not to mention that we (the Wine project) lost a huge contributor. If only a fraction of that effort would have been put into improving the controls say, we would have been in a much better place.
I really think we need to put more effort in addressing this properly.
Hear, hear! //Jakob
Dimi Paun <dimi(a)lattica.com> writes:
What people really want is to able to simply do: $CC -o myapp -lwine or even better: ... void *wine = dlopen("wine"); if (wine) { ... } This is what we need to provide.
You see, right now we offer the most functionally reach Winelib, but at a high usage point. I can image lots of use cases where people would go for a bit less functionality (say no native DLLs) if they could use Winelib as described above.
IMO the no native DLLs bit kills 99% of the potential uses of the feature. The reason people want to dlopen libwine is so that they can do everything in Unix except occasionally load some Windows driver or DLL for which they need to load Wine on the fly. If the app itself is using the Windows API then I don't see why making it a Winelib app is a problem. -- Alexandre Julliard julliard(a)winehq.org
On Sat, 2005-05-21 at 13:22 +0200, Alexandre Julliard wrote:
IMO the no native DLLs bit kills 99% of the potential uses of the feature. The reason people want to dlopen libwine is so that they can do everything in Unix except occasionally load some Windows driver or DLL for which they need to load Wine on the fly.
Well, even if it is so, we have a problem. We have very poor support for this use case. People don't want to turn their app into a Winelib app for some occasional need of a Win32 PE DLL. Maybe we could provide some sort of static lib that they can link with (effectively turning their app into a Winelib app, but that's another story), so that their app would be able to use Wine is available on the user's system, and degrade gracefully if it is not present. And while we're at it, we need to get rid of the startup script. People really hate that (I'm not debating whether this is a rational hate, it's just an observation). -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.
Odd that it broken in this issue and not previous issues. Not matter, I found a fix for the parser. Should be good until the next one. ;-) On Fri, 2005-05-20 at 00:35 -0600, Brian Vincent wrote:
Something broke on WineHQ. For some reason <br /> tags aren't getting parsed right - see this week's WWN for an example. It's displaying "<BR>". I haven't looked into it at all, but I figured someone (Dimi?) might remember messing with this stuff recently.
participants (8)
-
Alexandre Julliard -
Brian Vincent -
Dimi Paun -
Jakob Eriksson -
Jeremy Newman -
Mike Hearn -
Mike McCormack -
Ove Kaaven