Re: Does .net replace win32?

From: Sven Groot (sveng3000_at_gmx.net)
Date: 05/03/04


Date: Mon, 3 May 2004 20:53:32 +0200

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

-- 
Sven Groot 


Relevant Pages

  • Re: Managed vs Unmanaged Bare Bones Performance Test
    ... One of the reasons that things like Virtual PC (which runs Windows on pre-Intel Macintoshes) and Rosetta work so well is that the programs being run spend very little time in the code that needs to be translated. ... If your code only spends 1% or less of its time executing the code you actually wrote, and the rest of its time either waiting on i/o or executing libraries in the operating system, then even if you have a 20X difference in performance, you're only really looking at a 20% cost in the "slower" environment. ... There are a few classes of applications where this sort of difference matters. ... The biggest thing I notice in my applications is start-up time, as the .NET Framework imposes a relatively large burden with respect to application initialization as compared to a straight Windows application. ...
    (microsoft.public.dotnet.framework)
  • Re: Windows 2000 hangs on Internet Explorer using .NET Framework 1.1
    ... be caused by a third party applications like Kernel level filter drivers, ... Windows NT/2000/2003 Cluster Technologies ... > I ran .NET Framework 1.0 with this and I could happily log on to the ... > internet using my internal modem. ...
    (microsoft.public.win2000.advanced_server)
  • Re: ASP.NET requirements? This CANT be true
    ... Deployment Guide for .NET Framework ... As long as you have a properly license copy of Windows and accept the EULA, ... ASP and ASP.NET are two different applications, ...
    (microsoft.public.dotnet.general)
  • Re: .NET Framework 2
    ... But if we look at which Windows version .NET is shipped with we can see that in last years .NET 2.0 ships with all new Windows versions. ... S> The .NET Framework is NOT part of the "Critical" updates. ... S> Most of the .NET applications that require the .NET Framework are ... Friedrich Nietzsche ...
    (microsoft.public.dotnet.faqs)
  • Re: Binding MFC dll onto .Net VC code because .net class never support
    ... ..NET *Compact* Framework is used on Windows Mobile and Windows CE devices, ... if you think about it; how big is the .NET Framework? ... Most of the Win32 API on Windows CE matches the Win32 API on the desktop. ... There's no way to 'bind MFC to managed code' and MFC is not a model for ...
    (microsoft.public.windowsce.embedded.vc)