[Mono-devel-list] Re: [Gtk-sharp-list] kernel support.

[Carlos Perelló Marín]

--=-UVe4UyGHzjYJ9JW3CkP5
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable

El mi=E9, 18-06-2003 a las 11:29, Dag Wieers escribi=F3:
> On 18 Jun 2003, Carlos [ISO-8859-1] Perell=F3 Mar=EDn wrote:
>=20
> > El mar, 17-06-2003 a las 23:46, Dag Wieers escribi=F3:
> > > Ok, now try to convince Red Hat, SuSE, TurboLinux, Mandrake, Lindows =
to=20
> > > fix their packages and release updates to their wine package now.=20
> > >=20
> > > And I'm sure you can overwrite what other packages do, but that's not=
 a=20
> > > real clean solution and you may not have control what an upgrade will=
 do.
> > >=20
> >=20
> > I think that the solution does not change wine files, as you can read
> > with the attached file, it's only a modification inside binfmt-support
>=20
> I didn't say it changes wine files.
>=20
> Ok. Red Hat uses sysv files currently to make sure wine is started when a=
=20
> Windows binary is run. How would you add your wrapper to binfmt_misc ? As=
=20
> a sysv-script ? Would your script undo what the wine-package does ? Make=20
> sure it does work after an upgrade of a wine package ? If you have=20
> multiple entries, it's undetermined what exactly happens afaik (I've seen=
=20
> strange things here, while testing)
>=20

One note, this script/program is not mine.

I don't know how RedHat solve the "problem" I was just pointing the best
solution (for me). Perhaps you can just ask the RedHat's maintainer if
he/she will accept a patch before supposing that it will not work ever
with RedHat/Mandrake, etc...

>=20
> > > "It works" doesn't necessarily make it the best solution. A shell wra=
pper=20
> > > works too.
> >=20
> > It works for all .net executables and the user does not need to know
> > that she needs a wrapper to execute a mono program.
>=20
> That's not why I said that. The user doesn't know it's starting a=20
> shell-wrapper either, so it's transparant to the user and works on _all_=20
> systems, not only those that have shipped the binary wrapper.
>=20
> BTW I made that comment because "a shell wrapper works too" but is=20
> clearly not a prefered solution either. It would be a temporary solution=20
> that works everywhere.
>=20

True

>=20
> > I think it's the best option :-P
>=20
> I think a binfmt_exe kernel module would be the best option. Transparant,=
=20
> can't be undone by binfmt_misc, and works just the same way as other file=
s=20
> are made to work that can't take advantage of binfmt_misc.

If you look at the kernel development you will see that binfmt was moved
from a concrete binary submodules to a general support so user-space
applications could plug any support without the need of kernel
recompilation.

>=20
> Of course, it hasn't been written yet.

I doubt it will be ever written as a kernel module and if someone does
that, I doubt that it enters inside the official Linux Kernel

Btw, I don't know if *BSD or MacOS have something like binfmt, so
perhaps the "wrapper" you are talking is a better global solution...=20

Cheers.

>=20
> --   dag wieers,  dag@wieers.com,  http://dag.wieers.com/   --
> [Any errors in spelling, tact or fact are transmission errors]
>=20
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
--=20
Carlos Perell=F3 Mar=EDn
Debian GNU/Linux Sid (PowerPC)
Linux Registered User #121232
mailto:carlos@pemas.net || mailto:carlos@gnome.org
http://carlos.pemas.net
Valencia - Spain

--=-UVe4UyGHzjYJ9JW3CkP5
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada
	digitalmente

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA+8KcqEuPMamD5V9cRApDyAJ9EN5NI2WknEG6kHfERCFW2LKe0ugCdGR8E
2NCT1+j4V+MoE5JMMM59XCE=
=4UGI
-----END PGP SIGNATURE-----

--=-UVe4UyGHzjYJ9JW3CkP5--