> I have read threads here and there and I have looked at MS but I can not
get
a clear understanding of what .Net acutally is. I understand that C++ and
Vb and other languages are being out a .Net. I get some idea that it still
is OOP. I think it has different ways of managing the code. But what is it?
The closest thing that comes to .NET is Java. Although it is equivalent is
is not the same, there are some differences.
Basically it comes to this. C#, VB.NET and C++ (in managed mode) will create
an virtual assembler code called IL as executable (you won't notis this
since the executable is still called exe and an assembly called dll). The
moment that you double click on that .NET program then the .NET compiler
(CLR) compiles it to native processor instuctions to be executed. Only the
functions that are actually executed are compiled, not the unsed functions.
This is why starting up a .NET program seems to be so slow compared to
none-NET programs.
VC++.NET is a special breed, it can create pute .NET programs (aka managed
code), it can cerate pure old style executables not needing the .NET
framerwork (aka unmanaged code) or mix it. It is not a dirty trick, because
the CLR has this managed/unmanaged functionality implemented in it's core so
in theory even C# might create mixed code if the developers would like
that.But they don't want to implement this as far as I know.
Now what about the .NET framework. This is a set of libraries similar like
the Microsoft Foundation classes or the Visual Basic runtime library. It is
a rich set classes that does most things you ever need.
But you still have access to the conventional WINAPI functions in case if
you need exotic functionality or have access to your existing old dll's.
This is what they call INTEROP, access from managed code to a unmanaged
part. This trasition takes time so must be avoided if it is possible.
One interesting feature of the .NET is that it can also create COM objects
(ActiveX) so you can create a .NET libarary that can just be used in older
program languages that have no clue what .NET is.
Regarding to your OOP, .NET is basically a WINAPI wrapper in a pure object
oriented way (you can inherit, extend,... anything according to OOP
conventions). Unlike MFC that is a WINAPI wrapper in aan none-object
oriented way. (It looks like OOP but it is absolutely no OOP). You are
forced to program the OOP way, which is a good thing.
The nice thing about this OOP way of programming is that now, a dll created
by C# can be used in VB.NET without dirty tricks and that VB.NET can be used
in C# and C++, freely intermixed. With one exception that the dll writer
must not use case sensitivity otherwise VB.NET will have problems with it.
If you create big programs that you will see that a program will contain
mixed C++/C#/VB code all working happily together.
Another thing about .NET is security. This might be a problem for people
coming from none-NET since the learning curve is a litle bit high in order
to understand this. But basically it comes to this. 2 people must tell what
the progra is allowd to do. The programmer and the user/administrator where
the program will run. E.g. The programmer must decide if this program is
allowed to access the Internet or a networkdrive. Because default it does
only run on your local machine. And a stupid clock might not need to access
the internet. So it cannot be taken over by a worm/virus to send SPAM. But
imaging that thic clock does need internet for the about box to go to the
vendors URL, then user/admin of the machine where this program will run can
then restrict the access to none-Internet only. From IT point of view I
would trust .NET programs far more than none-.NET programs.
Another interesting feature if the .NET is regarding to memory cleanup. This
is also know as GC. Unlike conventional programming, you do not need to free
memory after you used the memory and have no need for it anymore. The GC
will fire up the moment you are tending to run out of memory and analyze
which memory blocks might be discarded. The GC is pretty advanced but so far
it works great. Only regarding to file closing and other windows resources,
could there be a problem. So you must not writer the file close in a
destructor otherwise you have no idea when the GC will close the file. It
becomes unpredictable.
It took a few years to understand this, I hope now you have a much clearer
view? ;-)