Learning .NET Win32 way

[MrBeans]

Hello,
I come from MFC/Win32 background and would like to learn .NET the Win32 way. I have not been to go any step closer to this objective. I have done some analysis.

I believe that .NET is a new platform something like Win32 was when released. Is this true? If so is .NET execuable totally unrelated to Win32 executable, do .NET executable have relation to user32.dll, gdi32.dll etc?

What are these .NET dll's like the system.windows.forms.dll? These dll's do not seem to export any functions to the outside world so how do they communicate with an executable?

What kind of structure do .NET executable follow in terms of handling events, messages? Is it the same as that for Win32 executable?

[Arjay]

Hello,
I come from MFC/Win32 background and would like to learn .NET the Win32 way. I have not been to go any step closer to this objective. I have done some analysis.

Not sure what you mean here.

I believe that .NET is a new platform something like Win32 was when released. Is this true?

Kind of. In many cases .Net simply wraps Win32 functionality. In other cases, functionality is built from the ground up (without using Win32).

If so is .NET execuable totally unrelated to Win32 executable, do .NET executable have relation to user32.dll, gdi32.dll etc?

While there are exe's and dll's in .net, they are not interchangeable with the Win32 counterparts. On the other hand, in most cases, the original system dll's (user32.dll, etc.) are loaded in the process space (when the .net functionality wraps Win32 api's anyway). You can verify this by starting a .net app and running tasklist /m.
[/QUOTE]

What are these .NET dll's like the system.windows.forms.dll? These dll's do not seem to export any functions to the outside world so how do they communicate with an executable?

Dll's in .net are called assemblies. As such, they don't expose functions as a Win32 dll does.

What kind of structure do .NET executable follow in terms of handling events, messages? Is it the same as that for Win32 executable?

Not really. Win32 really isn't consistent either and depends on the functionality you are using.

Probably the best thing you could do is start reading up about coding in .net (C#) and trying out samples. There are some QuickStart samples that are a good place to begin.

[ovidiucucu]

Hmmm... sounds like
"I was a Java programmer for many years but now I have to learn MFC. How can achieve this faster given my solid Java knowledges?"

Well, the answer for that is:
"The fastest way is to forget Java just for a while".

[MrBeans]

Not sure what you mean here.

Not important here anyway .

Kind of. In many cases .Net simply wraps Win32 functionality. (when the .net functionality wraps Win32 api's anyway). You can verify this by starting a .net app and running tasklist /m.

That is Good news

"The fastest way is to forget Java just for a while".

Great suggestion there Ovidiu, but unfortunately that would mean 4 years of my experience in Win32 programming going straight down the gutter. Also for me programming is not just about programming but a passion, to know about the internals of what I am working on and what is going on under the hood which I seem to know in Win32 but not in .NET
Also please explain this

These dll's do not seem to export / import any functions to / from the outside world so how do they communicate with an executable?

[darwen]

to know about the internals of what I am working on and what is going on under the hood

Just because you know how to fix a car engine, doesn't mean you can drive it or that knowledge will help you learn to drive.

I learned C# from the top down i.e. started writing simple windows forms applications and then moved into doing advanced stuff.

To me it is about priorities : how I write dialogs etc is much more important than knowing how to interop with dlls etc.

OV's advice is good : treat C# as a new language to start off with and as you gradually learn you'll soon learn how it fits in with Win32.

Darwen.

[Arjay]

You guys are right. When I started learning C# back in 1.0 or 1.1 timeframe, I wondered why there wasn't a mapping between the Win32 way of doing things and the new way. It was a bit frustrating because at that time not everything was wrapped or replicated with .net.

Now, with 2.0 and 3.0 it's much better, so the advice of forgetting the Win32 approach for a short time is a good one.

Start with some quickstarts and samples, get a beginning book and have at it.

It's really worth the trek.

[kirants]

mean 4 years of my experience in Win32 programming going straight down the gutter.

Not necessarily. You would still use those concepts for a while. You may still have to call into "old-style" dlls and COM components, which are invoked PInvoke style.

Also for me programming is not just about programming but a passion, to know about the internals of what I am working on and what is going on under the hood which I seem to know in Win32 but not in .NET
Also please explain this

Good. In that case, you are not talking about the language then, but, more on the architecture and the nuts and bolts.

.Net assemblies are still PE style dlls/exes. They have information in their PE data structures to indicate they are .Net assemblies. The loader on .Net supported OSes are different too. They are written to look for this information. When they come across .Net information in the assemblies ( regular dlls and exes for these loaders ), the loader immediately loads a CLR dll and executes some code that loads in the metadata from the executable. From here on, it is all managed code and hence you don't have concepts of exported functions etc.

Please read up on this excellent article:
http://www.devx.com/assets/summitdays/2679.pdf

This is the beauty of the PE file format.

[gstercken]

A very good introduction to .NET, especially regarding the differences between native / managed code, and how .NET assemblies related to native executables and DLLs can be found in "Introducing .NET (3rd ed.)" by David S. Platt (Microsoft Press 2003).