This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: mixing MSVC++ and gcc C++ libs/dlls ?

>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

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 (, the
commercial 'netraverse' ( ) 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

> -----Original Message-----
> From: [] 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).
> > ( )
> >
> > 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:
> Problem reports:
> Documentation:
> FAQ:         

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]