What is your prediction for .NET framework 4.0?

Chadk wrote:



SecretSoftware wrote:What do you think is missing from 3.0 and should be in 4.0? What are your expectations for C# 4.0? It should be interesting to see what others think about what should be in 4.0 and what is missing that would make life easier for devs. Thanks

Wow wow, calm down.
3.0 recently shipped. Let see what good stuff is comming to us in 3.5 first, shall we?

3.0 is out the door. So its always good to keep future tech trends in mind as you design future projects.

Harlequin wrote:



SecretSoftware wrote:What do you think is missing from 3.0 and should be in 4.0? What are your expectations for C# 4.0?

No more starting threads like this unless you give input of your own on your own question

Well there are some things and improvements I want to see.

1) Change the way loops like while are implemented so that the evaluated expression is always checked while in iteration

2) I want to do this :

s = new Socket (), rather than Socket s = new Socket (),

I know var kinda does this,but I want a variable to hold multiple types  in the course of execution. so I can set s = null, and assign it to a new instance of another object

3) Make it easier to deploy applications than already is. This means that the installer will check itself if its the same since it was compiled (Self Signature verification). Puls improve ClickOnce perfomance and ease.

4) perhapse the most important feature: integrate obfuscation into the compiler, so when you release your application, you dont have to use a 3rd party tool to obfuscate your code. Even better, make reverse engineering a .NET application very hard (Perhapse use technologies like that of AACS or others to make the .NET framework support encrypted assemblies, between VS and the runtime, so that all assemblies are encrypted and only MS has the encryption key that is guarded  (or find some other way to prevent code being disassembled).

5) Add support for devices natively in the .NET framework classes. So you can tap your hardware and extract data from data buffers. Basically integrate .NET with Directx libraries, so you can use them natively in the .NET framework and leverage these right there into your applications. There is a gab here between .NET and being able to read data from say Mics or Cameras or other devices. (make the assembly requirement easier )

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.

7) Add support for AES-128 bit and improve the Random class to use cryptographically generated random numbers. Improve cryptography easiely. (Add generic certificate generator that assume the server is the CA easily (Crypto.GenerateCert() or something along that).

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).

9) Make it easier to use IPv6 natively int he .NET framework for connected applications. (Set it and forget it approach).

10) Allow a way for Applications targetting vista to be able to use the Voice commands with in the application (more intimate interaction with a given .NET application).

11) Prevent Dll Injection into .NET applications by malicious software.

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.

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?).

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.

15) Visual Studio should be better than what it is now. Code analysis tools should be integrated and improved upon in the IDE.

There are others but I will not bore you with them.

littleguru wrote:



SecretSoftware wrote:2) I want to do this : s = new Socket (), rather than Socket s = new Socket (), I know var kinda does this,but I want a variable to hold multiple types  in the course of execution. so I can set s = null, and assign it to a new instance of another object

aaaah! I can already see the mess. s being Socket then Form then Foo then DateTime... Please no!

Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking.

littleguru wrote:



SecretSoftware wrote:Basically integrate .NET with Directx libraries, so you can use them natively in the .NET framework and leverage these right there into your applications.

Isn't that WPF?

WPF is cool and all, but its not as rich as having Directx stuff in. There are things in Directx that are cool and should be there.

littleguru wrote:



SecretSoftware wrote: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.

Is already there and called "strong name".

As I already pointed out, Strong Name fails in its goal. Hackers can change the code and resign it again. So its useless. Strong name can protect against average users who no nothing in computers than just to move the mouse around.

We need something more reliable than this. Something that will really raise the bar too high.

littleguru wrote:



SecretSoftware wrote: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?).

Damn that gets slow... Next everybody would cry that .NET is so slow... Should be only optional and disabled by default (to avoid the crying)

With multi-cores , I doubt this will be a problem. Slow is a thing of the past and let the Ghzs do background crypto stuff through some abstraction layer in the runtime. Plus symmetric crypto is faster.

littleguru wrote:



SecretSoftware wrote: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.

The MSIL code you see when looking at it with ILDASM is the real code that gets executed... The runtime is inlining and removing vtables etc. (the jitter and managed runtime is also here for something). That happens all behind the scenes. The runtime does already a lot to make code faster and remove duplicate stuff.

I wouldn't like the compiler to remove a piece of code an call another method that does the same, just because he thinks so. That's weird if you do performance checking etc. It looks non deterministic to the user. The developer might also have thought a little bit when putting the code not in the other method, when having it in two methods... Performance, for example, could be a reason.

It's better to educate the developers to write better code then having the compiler to do it!

Suppose you have

void string Method1 {
   Do X manipulation
   Then do Y1 manipulation

}

void string Method2 {
    Do Z manipulation
    Then Do Y1' manipulation (very similar in technical implementation to Y1
}

So compiler sees this, and seperates  Y1' and Y1 into new method that supports the manipulations required by Method1 and Method2

This can be extended to all code base. So similar stuff can be grouped together and so on.


Devs can write good code but still they would have some repeating stuff that on first sight of code you see that they are different but in reality they are not that different. So precompile code analysis would detect this and the compiler should be enough to do stuff like this.