[newbie] Why is .Net so big? Why no linker?

  • Thread starter Thread starter Luke Skywalker
  • Start date Start date
L

Luke Skywalker

Hi,

While I'm learning more about how to develop under Delphi,
which, was some of you know, built by the same person who architected
..Net... I was wondering ...

1. why is the .Net framework so big, while the object layer on which
Delphi runs lets you build stand-alone EXEs with something like a
300KB fixed cost?

What can possibly require 100MB once the .Net framework is installed
that couldn't be done like Delphi does?

2. since MS obviously doesn't want developers to write
platform-independent apps since that would reduce the lock-in and
recuring revenues it enjoys with Windows... why bother with bytecode
with JIT, instead of providing compile-time machine-code and a linker,
so that, like Delphi or C, developers are free to choose to distribute
run-times either as stand-alone files, or as libraries linked into the
EXE?

Thank you
Luke.
 
The questions you asked have been beaten to death so many times here and
elsewhere. Some one may want to answer one more time. Just a correction: The
..NET Framework is anout 20MB, not 100MB.The 100MB+ in .NET SDK, witch, of
course, includes the Framework. You only need to install SDK if you want to
develop on .NET, the users, only the Framework is needed if they want to run
..NET app on their computers.
 
The questions you asked have been beaten to death so many times here and
elsewhere.
Click to expand...

OK, I'll check around see what I find. Sorry about that.
The .NET Framework is anout 20MB, not 100MB
Click to expand...

Are you sure? The install program is 25MB, but once it's installed,
it's much bigger than this. At any rate, is so much bigger than
run-times used by other tools like VB, Delphi or VC++, that I wondered
what it can possibly include that those other tools didn't, and
whether there was no other, lighter way to offer some
language-agnostic OO layer to the Win32 API.

Luke.
 
"At any rate, is so much bigger than run-times used by other tools like VB,
Delphi or VC++"

The files that you are installing aren't just a run-time. They are all the
files that are needed to run all programs made in .Net. The idea is that I
can make a program and send it to a machine running .NET and I don't have to
worry is ABC.dll going to be on that machine or not or what version of
winsock are they running. .Net takes care of this for you. You aren't
comparing Apple to Apple when you talk about VB6 runtime and .Net framework
install.

Chris
 
The files that you are installing aren't just a run-time. They are all the
files that are needed to run all programs made in .Net. The idea is that I
can make a program and send it to a machine running .NET and I don't have to
worry is ABC.dll going to be on that machine or not or what version of
winsock are they running. .Net takes care of this for you. You aren't
comparing Apple to Apple when you talk about VB6 runtime and .Net framework
install.
Click to expand...

Mmm... OK, so what can that huge .Net framework contain that would
explain its size, and that programs written with the traditional tools
like VB or Delphi didn't need, and would justify having to dump them
to use that new (?) technology? I don't need much to run a VB or
Delphi app on Windows, and certainly no need to provide a 25MB add-on.

I know this looks like a troll, but it really isn't. I just don't know
enough about the nuts and bolts of run-times and .Net to judge whether
it was really technically necessary to generate that humongous layer
between apps and Windows, considering that current tools managed to
offer an OO model that seems just as productive without that big fixed
cost. Are people more productive in .Net than they are in, say,
Python, Delphi, or VB Classic?

Also, why did MS decide that .Net programs should be compiled to
bytecode instead of native code? It made sense for Java since the goal
was to make apps run on any platform with no recompiling*, but MS
obviously doesn't want to make .Net apps OS-agnostic since this is the
only product (with Office) that makes money.

So what's the point of the IL bytecode? Why no compiling to native
code?

Thank you
Luke.

* a strange idea if you ask me, considering the negligeable cost of
compilation to native code, and the required JVM to run
 
Also, why did MS decide that .Net programs should be compiled to
bytecode instead of native code? It made sense for Java since the goal
was to make apps run on any platform with no recompiling*, but MS
obviously doesn't want to make .Net apps OS-agnostic since this is the
only product (with Office) that makes money.

So what's the point of the IL bytecode? Why no compiling to native
code?
Click to expand...

It's not a case of making it OS-agnostic, it's a case of making it CPU-
agnostic. Think about 64-bit CPUs - a 64-bit JIT can no doubt produce
much more efficient code than using plain 32-bit instructions emitted
by a normal compiler.
 
It's not a case of making it OS-agnostic, it's a case of making it CPU-
agnostic. Think about 64-bit CPUs - a 64-bit JIT can no doubt produce
much more efficient code than using plain 32-bit instructions emitted
by a normal compiler.
Click to expand...

Ah ok, makes sense.

As for the size of the .Net framework, I'm beginning to wonder if it
includes a whole bunch of stuff that non-Net apps must install
separately like ADO, etc.

Thx
Luke.
 
Why no linker? One acronym, CAS (Code Access Security). I don't know if you
are aware of this, so basically this is the means by which trusted libraries
can be used by untrusted programs without opening up massive security holes.
If you don't trust the libraries, how can you trust the code that uses them?
..NET wraps up the Windows API, and various COM interfaces in trusted
libraries, and then relys on those libraries to ensure that they aren't
abused by untrusted code. If a program wants to do something nasty, it can
try to do it through the libraries. However, if the program is not trusted,
then the libraries won't allow this. If said program tries to avoid the
libraries, it's going to have to go through COM Interop or PInvoke (or use
unsafe code), which untrusted code isn't allowed to do.

Statically linking the libraries into the program would by definition mean
that the library code would have the same trust as the program, which in
turn would mean that all calls that the libraries made through interop would
have to be blocked as well. Therefore untrusted code wouldn't be allowed to
do anything that went through interop, which pretty much means it wouldn't
be allowed to do anything at all. The alternatives are to make all code
trusted to some degree or another, or drop CAS, neither of which is
appealing from a security perspective.

Think about this, download a Delphi program from the net and run it. It
could be happily modifying files in you My Documents folder, sending out
your secrets, blocking your network connection, installing rootkits and
you'd have no idea. Now, run a .NET program from the net and, since it's
untrusted, it wouldn't be able to do any of those things, even if you ran it
with Administrator privileges.
 
Also, why did MS decide that .Net programs should be compiled to
bytecode instead of native code? It made sense for Java since the goal
was to make apps run on any platform with no recompiling*, but MS
obviously doesn't want to make .Net apps OS-agnostic since this is the
only product (with Office) that makes money.

So what's the point of the IL bytecode? Why no compiling to native
code?
Click to expand...

I don't buy the lock-in argument; there's no reason that the framework can't
be implemented on other platforms (check out Mono, for example). As Jon
says, using bytecode allows optimizations specific to a machine (consider
the fact that most compilers have options to optimize for specific
processors).

Steve
 
Luke,

One a discussion about low level programming some days ago came this message
in the language.vb newsgroup
-------------------------------------------------------------------------------------------
One thing that's not been discussed here is that LOW LEVEL was different
on every CPU/Hardware type. I use to write code for the 1802, Z80, 8085,
8088, 68000, 68010, 6502, 8086, 80286, and then stopped when it got to
the 386 stage. I was in heaven when Assemblers came out so that you
didn't have to code in Hex and remember that a jump was X-1 on some
CPU's it was X, and that BSL,BSR sometimes didn't move anything in to
the carry/overflow positions....
 
Luke Skywalker said:
Ah ok, makes sense.

As for the size of the .Net framework, I'm beginning to wonder if it
includes a whole bunch of stuff that non-Net apps must install
separately like ADO, etc.
Click to expand...

Yes. The framework includes ADO.NET(~5 meg), ASP.NET(both the runtime and
web control libraries, which is another 10 meg easily), compilers(atleast it
will in 2.0, I forget if it does in 1.1), the runtime itself(GC, JIT, and
the rest, which is about 10-15 meg of the installed size), a full XML
stack(no reliance on MSXML), Windows forms(mostly wrappers around Win32 and
ActiveX, but some stuff is written from scratch), a GDI+ wrapper, the core
libraries, and a vb compatiblity library(if memory serves, anyway).

There is quite alot there. And any app which does not directly access COM or
PInvoke is self contained within the framework, its own code, and any third
party libraries(and what they access, of course).

I think the framework may also install MDAC, but I'm not sure on that last
point.
 
Luke Skywalker said:
Hi,

While I'm learning more about how to develop under Delphi,
which, was some of you know, built by the same person who architected
..Net... I was wondering ...

1. why is the .Net framework so big, while the object layer on which
Delphi runs lets you build stand-alone EXEs with something like a
300KB fixed cost?

What can possibly require 100MB once the .Net framework is installed
that couldn't be done like Delphi does?

2. since MS obviously doesn't want developers to write
platform-independent apps since that would reduce the lock-in and
recuring revenues it enjoys with Windows... why bother with bytecode
with JIT, instead of providing compile-time machine-code and a linker,
so that, like Delphi or C, developers are free to choose to distribute
run-times either as stand-alone files, or as libraries linked into the
EXE?

Thank you
Luke.
Click to expand...
 
Eh dude what's the deal here? You trying to build a web server? You're
really worried about just 100 megs!!!??? Well I, on the other hand, have
nearly 600 gigs in my hard drive memory with a pentium4 muliprocesser w/
hyper-threading at 3.4 Ghz each, so naturally, I woudn't worry. I don't know
what you have, but I suggest you that you need to dump all this Microsoft
shit ESPECAILY INTERNET EXPLORER (expcept when you need to run Windows Update
unless you just all together "send it to the shaft") and at
"http://ptech.wsj.com/archive/ptech-20041230.html", they will tell more. But
anyway, you may still need to have your .NET frameworking, but all you need
to do is install it and thats it, don't **** with it anymore, it'll configure
its self. All you need it for is so your computer can entigrate to a .com or
..net URL. Mabey be you can still use it if you want, but why **** with this
backward shit?? I have a totally better solution for you if that is a web
server you are trying to configure. If you want, you should go to my website
at "http://punkrok77comp1.thecartel.net/ and you will find a FREE download
for the AnalogX SimpleServer. And very simple it is!!! It's not even a half a
megabyte in size, yet it is a very powerful, hardy little server that doesn't
use a lot of resources, and sits and runs as a small icon in your task bar.
There is more instructions that come with it and on my website too that you
must READ FIRST before configure this thing. Who knows where you are at, but
this web server stands a test to itself if can "log on to my website" and
"download off it" because this is what I use to serve my webpage!! So, yeah,
I hope this was something you were looking for, if not it's still a very good
tool for you to have-thank you.
 
Back
Top