What captured my attention is when Anders spoke about elegance, taste and
simplicity in writing software. I can not count how many times applying simplicity to problem, instead making wild ideas that compound complexity have paid off in long run.
Taste, for me at least is being able to evaluate various approaches, and selecting one that is most elegant and cleanest. Unfortunely I see the opposite in code written by others, who suffer the consequences of their clumsy (kludgy) actions.
So native code is also good because it's an added layer of protection against reverse engineering.
Beer28 raises very important point. Many companies want to protect their intellectual property (resources and time) that they put into making a software product, and it is a big issue, knowing that someone can take .NET DLL or EXE and quite easily decompile.
I know there are tools that "obfuscate" the MSIL, but do not come close to ASM native image.
I am not with the latest buzz, but I would hope that next version of VS 2005 would have much better NGEN that not only could put .NET Native Image into GAC, but also produce standalone app, that could only be run on target platform that has compatible .NET
Porting back Avalon to Windows XP/2003 is misguided attempt. Even though would be "available" for download, few would choose to download and install it. And thus, it would only be guaranteed that Longhorn users can run Avalon applications.
For example look at .NET Framework 1.0/1.1, few average users have it on their computers, and it has been "available" for few years now.
Besides, Avalon would need powerful machine, and graphics capabilities, which most XP machines (including those bought in 2001 when XP came out) do not have the muscle to make Avalon shine.
Indigo on XP/2003 is good idea, as a common communication infrastructure across all windows machines, but Avalon on XP/2003, big mistake. It will only add to complexity and consume time and resources from other more important developments.
I am questioning how many people would benefit from Avalon on Windows XP? Yes, there maybe
some now saying “cool”, but two years from now – hardware will change, and many probably will get new PC with Longhorn in the box.
As for Avalon on Server (2003), it is not that essential. Probably if you got Server 2003, one is using not for the esthetic looks, but rather for hosting varies services. If someone wants full power of Avalon (mostly power-users) then they would get Longhorn.
I am looking forward to updating all of my home computers (both new and old) to SP2 as soon I can get my hands on it. Although I am concern how well will SP2 perform on older computers that lay on the borderline of system requirements? (E.g. 300MHz, 128MB)
I know that SP2 is mostly about security, but have there been tests/efforts done that show improvements/effects to... (tests on both new and old computers)
- Faster boot time
- Better CPU utilization
- Smaller memory footprint
I hope that SP2 will not slowdown already slow and low on resources computer.
Another advantage of MC++/CLR that Kang mention in another video is optimization that C++ team made on CLR compiled code. Thus, it should not be surprising to see MC++ outperform equivalent C# code (or VB.NET for that manner).
I have enormous appreciation for MC++. The ability to bridge managed and unmanaged code is so powerful. It takes a lot of smarts to allow for such seamless Interoperability and optimization work that VC++ team has made, with each product release. Congratulations!
My wish would only be if MC++ could be possible on the .NET Compact Framework. As on the desktop, the embedded type devices (Windows CE base) have system level features only exposed thru native API. P/Invoke is too limiting and primitive comparing to the
power and flexibility of MC++.
Is it feasible to have MC++ on Compact Framework in the near future? (I am sure that VC++ team does not shy away from a challenge)