An
Insight into Common Language Runtime
Host: Tarun Anand - .NET Evangelist, Microsoft India
June
6, 2002
KunalS_MS: Hello and Good Afternoon to all of you
KunalS_MS: Welcome to MSDN India Expert Chat session
KunalS_MS: Today's topic of chat is - An Insight into Common Language
Runtime
KunalS_MS: and our expert of the day is Tarun Anand - .NET Evangelist,
Microsoft India
KunalS_MS: Please share all you doubts and queries on Common Language
Runtime with Tarun
TarunA_MS: Hello
Guest: (Kumar) Under .NET, threads are run under an AppDomain, a given
physical process can have more than one appdomains; also, each appdomain
could be having multiple threads.
Guest: (Kumar) If we assume this is how things are in .NET, then how
does thread scheduling occurs in .NET when the main physical process
is single threaded?
Guest: (Kumar) Afterall, .NET has logical threads, and not physical
ones. Please comment.
TarunA_MS: Actually, the main process consists of several
logical processes called "appdomains" If there are several threads
in an appdomain then by definition the process is not single threaded
TarunA_MS: the scheduling is done as per the OS rules
only because these .NET thread == os thread in version 1
TarunA_MS: Each logical thread == physical thread in
version 1 - but the architecture of clr allows this restriction to
go away in the next version
Guest: (Kumar) Then how do we differentiate between a standard win32
thread and a .NET thread?
TarunA_MS: no difference in version 1, except threadpools
- .NET threadpool is better
Guest: (netj2ee) How is CLR different and better than JVM?
TarunA_MS: it is faster, cheaper and stronger...
TarunA_MS: cheaper because it is part of the .NET framework
which is the appserver for .NET and is free. Other appservers cost
you an arm and a leg.
TarunA_MS: faster because asp.NET is much faster than
jsp and part of it is because of CLR
TarunA_MS: better because it is built for multiple languages
including java
TarunA_MS: better because remoting is way superior than
RMI or DCOM
TarunA_MS: better because its JIT Compiler rocks.
TarunA_MS: better because its security model is uniform
across the device, desktop and server
Guest: (xtreme) Can we have 16 bit apps running using CLR .NET?
TarunA_MS: I am not sure what the question entails; 16
bit apps are legacy apps, you can call them using p/invoke but that
does not mean its "running" on CLR.
TarunA_MS: It’s using the windows thunking layer
Guest: (Kumar) How's the .NET threadpooling better than Win32's? Assuming
we are on a Win2K or later OS.
TarunA_MS: it manages the creation of the threadpool
better, also there are certain scenarios in which if all the threads
are doing work, then the threadpool cannot grow and do more work,
however, since the threads in .NET are managed by CLR, it can interrupt
them
TarunA_MS: and do some more work
Guest: (netj2ee) Is CLR available on Unix platforms like IBM AIX,
Solaris, Hp-UX, Linux?
TarunA_MS: yes but in managed code, you have fully interruptible
code because GC can happen anytime
TarunA_MS: CLR is available on FreeBSD, and a company
called Ximian is working on one for Linux
Guest: (Vyas/Manish_MVP): How does CLR JIT compiler different from
Java JIT? / How is CLR's GC better than GC in Java?
TarunA_MS: clr's jit compiler is just a better implementation,
it is difficult to describe because this is a lot of compiler code
but a few simple things that it does better is detection of garbage
early on, and inlining for better performance
Guest: (Kumar) If a .NET thread == a win32 thread; in that case, will
the standard ToolHelp API enumerate .NET threads as win32 threads?
And if we do a Win32 TerminateThread on a "represented" .NET thread,
will it affect the appdomain of which it is a part of?
TarunA_MS: Yes both are true.
Guest: (Kumar) How much is the CLR bound with the internals of Windows
operating systems?
TarunA_MS: Very much. CLR is MS implementation of CLI.
Don't confuse the two, if you have to port you have to implement the
CLI spec.
Guest: (pdsingh) Does compiling in CLR generate Byte Code?
TarunA_MS: If you mean java byte code, NO!!!! it generates
MS IL which is much superior than java bytecode and to answer a followup
question - it is superior because it has hints for JIT, and is closer
to assembler than java byte code that is targeted towards
TarunA_MS: Interpreters
Guest: (Kumar) If that is so, then how does a developer benefit from
the concept of platform independence?
TarunA_MS: Any implementation of CLI will be bound to
the platform that it is built on, developers don't have to worry about
it as long as it is "CLI" compliant, their apps will be portable
Guest: (netj2ee) Are the primitive sizes fixed in .NET languages.
What is the size of an int? This is regarding 16 bit apps.
TarunA_MS: if you use windows specific features on Microsoft
via P/invoke then you are out of luck.
TarunA_MS: Primitive sizes are fixed according to CTS
the common type system.. an int in VB.NET == an int in C#... 16 bit
apps are not applicable to .NET, you can call them but they won't
run under CLR
Guest: (Vyas) Is the Windows Forms CLI compliant?
TarunA_MS: windows forms is not a part of CLR or CLI
compliant, it sits on top of them
Guest: (Kumar) Assuming an application reads its settings from the
registry, which is present on Windows and not Unix, the application
will not have platform independence. Kindly comment.
TarunA_MS: Yes, but reading from the registry is not
recommended in .NET anyways...
Guest: (Kumar) Then what do you suggest?
TarunA_MS: read from a xml based config file, the OS
version can be got from the framework APIs not the registry
Guest: (Vyas) Are there any future enhancements planned for the CLR
in terms of new features or optimization ?
TarunA_MS: Yes
TarunA_MS: generics == templates will be supported in
the next release
TarunA_MS: also edit and continue support for all languages
will be supported a la vb of old
Guest: (Manish_MVP) Templates? for all languages viz C#, VB.NET
TarunA_MS: Yes
Guest: (Condi) What advantage has the CLR have over the current built
applications when it comes to security?
TarunA_MS: it allows for code access security that allows
semi trusted code to be run in a safe manner, in earlier apps this
was missing, instead it asked user to make choices about security,
or ran semi trusted code like full trusted code
Guest: (Kumar) Could you explain how CLR manages memory used by unsafe
code? Suppose, an application uses unsafe code, and then exits without
releasing the corresponding memory, how will CLR handle that?
TarunA_MS: if you are using unsafe code then you are
doing unsafe things, there are no guarantees that CLR will provide,
if you leave some unmanaged memory then it will remain till the process
shuts down.
TarunA_MS: Use unsafe code only if you have no choice
and be careful
Guest: (Kumar) So, that means, unsafe code could possibly endup crashing
the runtime? Isn't that too big a loop hole to be left out by Microsoft?
TarunA_MS: Nope. You could as well do a p/invoke and
leave the memory allocated there. There are many ways to leak memory
once you are in the unmanaged world
Guest: (Praneesh) Mono will have CLR too right. Will the Mono CLR
be written using C# as well?
TarunA_MS: Most implementations (including MS CLR) are
a mixture of c++/asm for the core clr parts , like GC, threading,
etc and the rest is written in some high level languages.
TarunA_MS: like c# for the class libraries,
TarunA_MS: the c# compiler is different from CLR. Don't
confuse the two, you can develop the 2 independently.
TarunA_MS: Most compilers are again written in c++/asm
or another high level language... you do sometimes have the chicken
and egg problem but that can be solved by writing a few pieces in
asm, using that to compile another more complex part, using that to
compile
TarunA_MS: another more complex part and so on.
Guest: (BhuvanMisra) We used to have MASM to write x86 compatible
code. Why does VS.NET not have similar features for writing IL. Any
MASM equivalent tool to write IL?
TarunA_MS: Not yet. But someone on the communities suggested
one. I want to know in which scenarios will this be useful.
KunalS_MS: We have come to end of today's session on CLR
