Dan said:
Okay...one last question. I've pretty much spent the weekend reading
up on .Net, Soap, web services and enough three letter acronyms to
feed the world alphabet soup.
Is it a fair and mostly true statement to say that when programming
Visual C++ using .Net, the .Net stuff basically replaces the Win32
API? I know you can still make a call back to win32 if need be, but
the general idea I gather is that .Net is the new "platform" to sit
ontop of windows for general applications, with Windows Forms
replacing MFC, etc...
For the moment at least, .Net doesn't replace Win32, only augment it. The
basic idea behind it all is that the Win32 API is 11 years old, and that's
only if you discount the legacy it has on Win16, if you include that it's
even older. In those days, C was the most used language for client
applications, so the Win32 API is built with C programmers in mind. Because
of it's age, it lacks some of the niceties new technologies can offer, and
has become rather large, inconsistent, and has some really convoluted naming
schemes because there are no namespaces
(CoMarshalInterThreadInterfaceInStream anyone?)
The .Net Framework was a chance to start all over, using modern design
paradigms and technologies such as component based software engineering.
This makes the .Net Framework cleaner, nicer, easier to use, etc. And
because of the managed code thing, it's also safer and more secure, and
prevents certain types of programmer errors.
..Net is the future. Right now, programmers that write end-user apps are
hesitant to use the .Net Framework, mainly because they don't want a
dependency on something that is a rather large download if you don't have it
yet. But that will change. More and more people will have the .Net
Framework, as more and more applications require it. I know I never install
computers for anyone without putting the Framework on it. More and more
people having it, will cause more applications using, which will cause more
people having it, etc. Windows Server 2003 is the first Windows version to
include the .Net Framework, and in Windows codename Longhorn .Net will be
such an integral part of the OS that it is not only included, some of
Longhorn's new features are actually built on .Net.
..Net is the future. For server side applications the near future, for client
side applications the slightly further future, but the future nontheless.
The Win32 API won't go away for a long time though, and it's existing
application base (and more important, developer base) will make sure it
keeps being developed too, for years to come probably. And there will always
be a applications where managed code is not appropriate, and Win32, MFC,
ATL, etc. will be there for them. And as an added bonus, the possibilities
for interop between managed and unmanaged code will keep getting better too.
But in the years to come, you'll see it'll be more and more .Net that
dictates the pace on the Windows platform.
That at least is my take on things.
