Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
From: "guenter strubinsky" <strubinsky AT acm DOT org>
To: "'ML CygWIN'" <cygwin AT cygwin DOT com>
Subject: RE: mixing MSVC++ and gcc C++ libs/dlls ?
Date: Thu, 23 Oct 2003 20:49:25 -0500
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAzKqZwgE0Ekq6HjOKEbfGv8KAAAAQAAAAK90qAzl2p0mTmTD6s3hdJwEAAAAA@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
In-Reply-To: <BAY2-DAV11YJoqCO3vJ00001bff@hotmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h9O1oOCj023472

>8p	!!!!

Are there any thoughts about the cil issue in regards to cygwin? If cygwin
would have (in the future) have a cil version, merging would not be an
issue.

Will longhorn and derivatives contain a 'native' box -like the dos box-? Any
'normal' software would otherwise become completely useless. Either they
keep two environments running more or less synchroniously and keep
synchronizing both, or there would be sever (even more than now) security
issues (HAL, system calls, etc.).

The concept as such is great and naturally not an MS innovation (see java
VM, or win system call interpreters as Wine (http://www.winehq.com/), the
commercial 'netraverse' (http://www.netraverse.com/ ) et al.).

You could build software on a virtual machine with features that aren't even
implemented yet in any hardware. Just write the byecode interpreter for the
native cpu (like java) and the software can run on a vax, an s/390, an
as/400, a cray... you get the drift. If cygwin would go that way, it would
allow NIX to run on virtually any hardware. I think that could be a nice
dissertation for some IS graduates ?!?!?!

There are naturally performance penalties (again see java); The optimization
however could run on two planes. Firstly the byte compiler, secondly the
bytecode interpreter. - Aaawwwhhh! Just dreaming ;) -

with kind regards
 
günter strubinsky
 <strubinsky AT acm DOT org>
<www.itcons.us>

> -----Original Message-----
> From: cygwin-owner AT cygwin DOT com [mailto:cygwin-owner AT cygwin DOT com] On Behalf
> Of Gareth Pearce
> Sent: Thursday, 23 October, 2003 18:39
> To: 'ML CygWIN'
> Subject: RE: mixing MSVC++ and gcc C++ libs/dlls ?
> 
> >
> > I doubt that. If I am not completely wrong, .net uses bytecode (like
> Java)
> > aka. CIL (Common Intermediary Language).
> > (http://www.msdnaa.net/Resources/Display.aspx?ResID=373 )
> >
> > I would not know how you can combine cil code with obj. files. If
> somebody
> > knows more I would love to read about it. It is one of the (many)
> reasons
> > I
> > don't -and have advised others- to jump on the .net bandwagon. I know
> for
> > sure that the Javascript (in M$ language Jscript) development part of
> VS7
> > can not be used for developing real ecmascript applications
> 
> Ms visual studio .net is still capable of making native
> executables/libraries despite its .net branding.  It needs to be until
> Microsoft are finished porting the windows source code to use cygwin.
> 
> ;)
> 
> Gareth
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Problem reports:       http://cygwin.com/problems.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/