Sign in to follow this  

.Net replaces what?

This topic is 4856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I have been thinkin... What exactly is .NET going to replace? Is ActiveX going to be affected? Is this a valid alternative to Java, now that we know it is being ported via mono to other platforms? How about certain API extenders, such as MFC and OWL, and even raw API calls? In future versions of Windows, are you going to have .net commands accessable from the console, via batch files or other scripting languages? I'm sorry if much of this has already been posted, but I am yet to find a clear answer.

Share this post


Link to post
Share on other sites
.NET will eventually replace the programming class library and API you use ... currently just the programming library ...

AND also, the mechanism you use to distribute / publish components (instead of the COM registry system, .NET uses side-by-side self describing components, or the GAC).

The most immediate difference for current C++ writers is that .NET completely replaces the need for MFC ... thank god.

Share this post


Link to post
Share on other sites
.NET could be considered a replacement for Java, actually it's more of a competitor. Depending on what platforms you are targeting it is becomming a more viable alternative. But don't forget that Java also works on things like mobile phones and embeded devices.
For GUI program on windows .NET is probably going to replace everything else, starting with Windows Longhorn .NET will be the base windows API instead of win32api.
You can use a .NET language, for example C#, as a scripting language. Not sure whether you can do it directly from the console, but a program to do that would be very easy.

Share this post


Link to post
Share on other sites
There are also ways in which .NET replaces the API, such as GDI+ (GDI+ is an extended graphical drawing API, but as far as I know, they haven't provided the strait Win32 API mechanism to use it without .NET), but in most cases people will use .NET classes where they add functionality you want, and Win32 API calls when you want that level of control. Games written in .NET still use DirectX and other COM/ActiveX controls, and .NET can easily load any COM/ActiveX control, but Microsoft is rapidly writing managed wrappers (.net classes) around the most important COm based systems such as DirectX so that .NET coders can have a cleaner, .NET feeling client instead of coding through the com interfaces. They released the first DirectX Managed classes as part of the Summer 2003 update of the DirectX 9 SDK.

Really .NET is almost directly a replacement for ActiveX, as ActiveX defined a means of coding classes, rules for how the binary must look, methods to register them with the client's computer, and means to find and load them. .NET provides all of that (as well as garbage collection and many many standard classes wrapping common and API functionality).

Share this post


Link to post
Share on other sites
.NET doesn't replace anything. It's a new alternative to existing options, on every level.

On the language level, the .NET runtime is an alternative to the Java Virtual Machine. Not quite as portable as yet, but with the potential to get there.

On the Windows level, the .NET framework is a subsystem alternative to Win32, much like the POSIX layer - for NT-based OSes. Pre-NT OSes being an abomination anyway, I can safely say that .NET is a subsystem alternative to Win32. See my journal for details.

On the object technology level, .NET isn't even a competitor to OLE/COM/ActiveX/whatever-they're-calling-it-this-week. .NET components are a logical extension of ActiveX technology, and provide limited interoperability.

Hope that helped.

Share this post


Link to post
Share on other sites
.NET is also a runtime, much like the Java Virtual Machine, that provides the component loading feature mentioned above ... so unlike pure compiled C++, any .NET program is going to have run-time type information for all of it's classes, and JIT loading of it's components (no .NET dlls are stataically loaded, it is all pure dynamic loading). So .NET programs are pretty much guaranteed to have a larger memory footprint than C/C++ (because information about types and stuff much be stored in memory while running), but they ship really small, unlike MFC programs, because the 20MB download that microsoft ships to customers as the .NET framework already includes the runtime and all of the built in classes (which provide most functionality), so a "hello world" type form would only have 1 class in it, compiled into an EXE, and all the drawing code and helper libraries would be already on the client's computer in their .NET framework. (Kinda like if people shipped the C++ library as a .dll in the Windows directory and everyone shared it - which doesn't work too well with templates :).

Share this post


Link to post
Share on other sites
I hope that .NET doesn't replace traditional API. I prefer that personally. If I was looking to do a GUI intensive app, I might use .NET for that.

Share this post


Link to post
Share on other sites
One could also make the claim that .NET replaces COFF, OMF, and the like.

.NET assemblies are fully self-contained and self-describing. Unlike .LIB and native .DLLs, headers are completely unneccessary.

Quote:
Original post by Maega
I hope that .NET doesn't replace traditional API.
What technical benefit does a "traditional" interface offer? .NET assemblies can trivially link to "traditional" DLLs and use whatever functionality they offer, but the reverse is quite a bit more work.

Share this post


Link to post
Share on other sites
Ok, I think I am starting to get it now. But are programs you write in .net languages actually compiled, or are they just turned into byte code like java?

And if the later is the case, how will this affect the speed of games. I'm not talking about graphics, per se, but in general?

//I am going to assume that graphics are still going to be able to access lower levels of abstraction, like how you can go around the GDI by using DirectX.

Is this XNA thing I keep hearing about going to be a subset of .net or something?

Share this post


Link to post
Share on other sites
Quote:
Original post by PnP Bios
Ok, I think I am starting to get it now. But are programs you write in .net languages actually compiled, or are they just turned into byte code like java?
It's precisely the same as Java. The compiler emits an intermediate form which is converted to native machine code at runtime.
Quote:
And if the later is the case, how will this affect the speed of games. I'm not talking about graphics, per se, but in general?
It costs you a few percentage points. Nothing to cry about. Bear in mind that .NET achieves this level of performance despite being relatively young.
Quote:
//I am going to assume that graphics are still going to be able to access lower levels of abstraction, like how you can go around the GDI by using DirectX.
Yup. DirectX can already be accessed directly from .NET. (either through COM, or, more recently, managed DirectX)

Share this post


Link to post
Share on other sites

This topic is 4856 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this