dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: [DotGNU]The Mingw32 ilrun seems to run


From: Simon Guindon
Subject: Re: FW: [DotGNU]The Mingw32 ilrun seems to run
Date: Mon, 2 Dec 2002 16:01:05 -0500

Yes but it is a problem for people who are deploying applications that
aren't dependant on a CLR/CLI implementation.

I could deploy say a service that some people may use on .NET or Mono or
PNET, so if I create the shortcut normally, on a PNET system this will fail.
If you create a shortcut based on PNET and ilrun, this will fail on other
platforms.

I think its a bad idea to tie developers and end users to one runtime,
saying "if your going to use this, you must use pnet instead of .NET".

I'm thinking from a application developers stand point where my target
audience might be using several CLR/CLI implementations.  What about using
the mscoree.dll only if it doesn't exist?  So if the newer OS's do have it
(which they will) it won't overwrite, and if your on an older OS or one that
doesn't have it in the future for some odd reason, it'll bind normally.

And if in the situation you want both, well your a more advanced user
anyways, and PNET will leave MS's implementation as-is and let you do what
you want with it, as is the case now.

I do definately agree with your statements here, as I had not thought of
that situation.  But I still think deployment of applications is important,
not just the deployment of PNET.

Take care,
Simon

----- Original Message -----
From: "Rhys Weatherley" <address@hidden>
To: <address@hidden>
Sent: Monday, December 02, 2002 3:56 PM
Subject: Re: FW: [DotGNU]The Mingw32 ilrun seems to run


> Simon Guindon wrote:
>
> > If they choose pnet, then we overwrite the mscoree.dll, if not, we leave
it.
> > To even further extend it, make a backup of mscoree.dll and have a
toggle
> > app that allows you to switch it back and forth from pnet/.NET
>
> It's not just an issue of "Choose pnet or .NET Framework".  Future
> versions of Windows will ship with MS'es CLR as standard.  Replacing
> "mscoree.dll" globally is likely to break everything, resulting in
> Windows itself ceasing to function.  If you think that pulling IE's
> tentacles out of Windows is hard, then you ain't seen nothing yet. :-)
>
> I'm starting to regret suggesting this ...
>
> I think people are misunderstanding a little what the role of MS'es
> "mscoree.dll" is.  It's not just a clever way to launch the CLR.
> It _is_ the CLR.  That dll exports a lot more than just "_CorExeMain".
> It also exports COM interfaces to the engine, metadata routines, etc.
>
> There are native unmanaged tools that depend upon this API.  Needless
> to say, building some kind of "chaining" system that wraps through to
> the real "mscoree.dll" will be next to impossible to implement.
>
> I was suggesting a quick and dirty hack that will work only if the
> user sets up their PATH correctly and does not use any MS application
> that may depend upon their CLR.  Providing the user a transparent
> way to flip engines is not possible with this mechanism.
>
> Yhe Windows desire to "just click on it" is nonsense anyway.  Users
> don't click on .exe files.  They click on icons or menu options.
> It is pretty easy to associate an icon with "clrwrap blah.exe" and
> make it so transparent that the user is none the wiser.  It's only
> a problem for people who run Windows apps from the command-line,
> which is mercifully a very small set.
>
> Cheers,
>
> Rhys.
> _______________________________________________
> Developers mailing list
> address@hidden
> http://www.dotgnu.org/mailman/listinfo/developers
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]