Microsoft Trick

[Rick Brewster]

Umm, ok whatever man. There is no conspiracy, you can safely remove your tinfoil hat.

[Rick Brewster]

Paint.NET uses the .NET Framework extensively. It's basically a large library of functionality for everything from drawing to file I/O, mathematics, and anything else.

Asking "can you do without it?" is like asking the author of a C++ application if they could do without C++ or the C++ Standard Library. Well the answer is no, because by definition a C++ application must make use of these things. It's not like .NET is only benefiting us in some small way that can be "optimized away."

You seem to be misunderstanding the purpose of the .NET Framework. It is something that applications are built on top of, and is not something that runs except when something uses it. It doesn't stick around after you close .NET-based applications. It is not a service, it is a framework -- basically a collection of DLL's.

[Rick Brewster]

.NET is more than "just a DLL" though.

First off, its DLL's have to be installed and registered in a certain way for reasons related to versioning, performance, and security. It used to be that to install a library DLL you would either just toss it in to C:\Windows\System32 or you'd store a private copy in your application directory.

The first method is really bad because then there's the possibility that you're copying an older version over a newer version. There's also the fact that behavior between DLL versions changes (some bugs get fixed, some bugs get added). If I wrote my app for version 1.1 of some DLL, and suddenly I start getting linked to version 1.2, things could be different and my app might crash (or worse!) now.

The second method, that of having a private copy in the application's directory, is bad for a couple of reasons. The first one is performance. If ten applications have their own private copy of the same DLL, you 1. use more disk space (although who really cares nowadays at 50 cents per gigabyte), and 2. you can't share the DLL's memory use between those 10 apps. So if the DLL is 2 MB then you end up using 2 MB per application instead of 2 MB total for the whole system. The second reason is for security.

If there's a security hole in some DLL, it's really easy to update with the first method. You just copy the fixed DLL in to C:\Windows\System32. In the second method, it's not really possible to do that. So .NET tries to fix these problems by providing a way for applications to get the version of a DLL they that want, and also a way to provide critical updates for those DLL's on a version-by-version basis.

Anyway, even if there was a way to just include the DLL's that were necessary, there still wouldn't be the runtime components that are required to execute those DLL's. This is because .NET is a framework and a runtime. The .NET runtime loads and executes .NET DLL's (called 'assemblies') and executables and manages all the hairy stuff noted above for versioning and updating, as well as other facilities (like "garbage collection").

So yes, blah blah blah etc. etc., I'm a bit long winded here. We can't "just include the DLL" because there's way more to .NET than just a DLL. But again, it doesn't sit there and take up memory or CPU time when you're not using a .NET-based application. The only thing it uses is something like 100mb of disk space. Which, at 50 cents (U.S.) per gigabyte, amounts to about 5 cents. I think I lost more than that the last time I did laundry and forgot to empty my pants pockets.

[aatwo]

just download the framework you slappywag. I'm sure its not going to make your computer explode.