On 23/10/2009 21:52, Steven Schveighoffer wrote:
On Fri, 23 Oct 2009 15:50:18 -0400, Walter Bright
<newshou...@digitalmars.com> wrote:
Yigal Chripun wrote:
Shared libraries are inherently not portable from system to system.
only if you consider dlls and so. Java jars are portable. so do .net
assemblies.
Jars and .nets are not executable code. Dlls and shared libraries are.
.net assemblies built by visual studio are packaged as dlls. Although I
don't know exactly how they are executed, I'm sure it's some sort of
bytecode.
Just saying...
-Steve
from wikipedia:
In the Microsoft .NET framework, an assembly is a partially compiled
code library for use in deployment, versioning and security. There are
two types: process assemblies (EXE) and library assemblies (DLL). A
process assembly represents a process which will use classes defined in
library assemblies. .NET assemblies contain code in CIL, which is
usually generated from .NET languages, and then compiled into machine
language at runtime by the CLR just-in-time compiler.
An assembly can consist of one or more files. Code files are called
modules. An assembly can contain more than one code module and since it
is possible to use different languages to create code modules it is
technically possible to use several different languages to create an
assembly.
I read somewhere (I can't seem to find the reference ATM) that if you
install a .net app with signed assemblies, the installer will compile
the assemblies into native executable code (ahead-of-time) and will
store them in a system cache.
all the system assemblies are pre-compiled like this.
