6) Add support for multi-core processing, in a way that will get rid of the problems with multi-threading in the .Net framework. I mean the race conditions, the locks , and the mutexes problems. Make these problems disappear so we can debug our apps easily
and detect more cross thread problems easily.
You started that discussion already and proved that you don't have a clue in that area.
7) Add support for AES-128 bit and improve the Random class to use cryptographically generated random numbers.
Did you ever take a look at the respective namespace?
8) Add Memory space randomization. So that when your application starts its memory space fingerprint looks different than last time. Making it hard for exploit code to work in .NET framework applications (This should be supported by the runtime).
You don't understand the idea of a JIT and GC, either.
9) Make it easier to use IPv6 natively int he .NET framework for connected applications. (Set it and forget it approach).
It's as easy to use as IPv4.
12) Applications should be able to do self diagnostics and also be able to check their integrity on their own. The CLR should refuse to run applications whose compile time hash is different than their pre-runtime hash, or even during runtime hash. Find
a way to make the application self-aware of its integrity as part of the services provided by the CLR. the Strongname while good, its still a mess because malicous hackers can sign the assembly themselves and the modify it.
What the hell?
13) I wish that the .NET framework and the Runtime in general would encrypt in memeory strings by default. No one should see whats in memory except the application itself (perhapse symmetric crypto between memory space and application?).
Oh hell yea. It's not like there's no point in obfuscating all strings and that there might be a performance hit.
14) the compiler should be a smart compiler. Basically when you have repetitive code that is similar in manipulation of things, but is different in minor areas, that it groups the similar stuff together into new methods, and arrange for the flow to be
correct at the same time. This would result in small size product and efficent code.
And the point is? Saving a couple of kilobytes of memory just to make the CPU pipeline stall all the time?