@Luna: "I meanwhat do you want to know? The real internals that are not visible to the outside?"
Loading user information from Channel 9
Something went wrong getting user information from Channel 9
Loading user information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
@Larry Osterman:With all due respect, I think quite the opposite. Interacting with the runtime in plain C or with some lightweight C++ library (WRL) is not only really fun but also the only way to start understanding how the runtime works. It is obviously a poor choice to write any real world applications (hence the C++ projection) but as I said I'm not an application developer and WinRT is at the top of my abstraction stack.
I might be the exception but I'm much more interested in the Runtime itself than in the language projections.
I suppose language projections are great for application and language developers but as a system guy I'm glad to have API and libraries that allow me to interact directly with the runtime.
Let's hope we'll see more content related to the internals of the runtime (as we already have excellent technical books about Windows and COM).
BTW, Windows Internals 6th edition Part1 is available since last week, no video this time?
Comparing a few lines of code is meaningless, we should at least compare simple programs as we do not design and write native and managed code the same way (yes this is not about C++ vs C# but about native vs managed code).
What I would like to do with you is to continue what Raymond Chen and Rico Mariani started a few years ago when Raymond decided to write a Chinese/English dictionary reader in C++ and Rico did the same in C#.
The problem is quite simple: given a Chinese-English dictionary file (Big5 format), the application should load its content in an appropriate data structure.
The dictionary contains a list of entries (one per line), each entry consists of the chinese word, the pronounciation and the translation.
Comments (starting with the pound sign) should be ignored.
The dictionary file can be downloaded here: http://www.mdbg.net/chindict/export/cedict/cedict_1_0_t_big5_mdbg.zip
We want our application to:
- execute as fast as possible
- consume as little memory (private bytes) as possible
Here is my first version, written in C++ (not much optimized and no intrinsics nor inline assembly code at this point).
VS2010 project: http://demo.ovh.com/download/0d17ff4700d84bad6ad7d8aa0019a53c/Dictionnary.zip
If you agree to play with me, you are welcome to write a C# (or with any other managed language) version and to compare it with the native version.
Process Explorer will tell us a lot about memory consumption and I think the Visual Studio instrumentation features can be useful to see how long it takes to execute the applications.
What do you think?
The CRT talk with Mahmoud Saleh is really interesting, and it looks like we could spend an entire hour (or even more) talking about the design and the possibilities of the CRT. Charles, any thoughts on a lecture series or a GD episode on the subject?
Getting a separate product (e.g. not integrated in VS) for C++ would be an interesting idea as a lot of developers (including myself) seem to miss the VC6 days in terms of performance and reactivity of the environment. The IDE used to be blazing fast, would love to get that feeling back!
I'm using C and C++ for system and application developement (both client and server) and here is what I would really like to get in the future:
- a modern UI library based on DirectX/Direct2D with some tooling support inside VS and the ability to run applications based on this library out-of-the-box on every version of Windows (just like with MFC).
- a C++ layer on top of the Windows Web Services API to get more functionnalities and improve productivity, the ability to run applications based on these APIs out-of-the-box on every version of Windows. On the server side, IIS support would be great (easy deployment of services) as well as a mini-framework with some core features like caching, session management, database access and so forth (no need for something as rich as asp.net).
- some improvements in terms of application architecture and deployment (COM is huge but it has not been evolving recently) with appropriate support inside VS. The ability to build and deploy seamlessly the components of a stand-alone application.
Besides, I have a tremendous amount of C/C++ code that I would love to run on the phone and on the Xbox, but that's another story