The Old New Thing

$@#! dlls!!!  Don't get them started on that subject Raymond. ;-)

Does Microsoft publish a list of DLLs that they guarantee will be present in a Windows system? I'm wondering if there's an easy check I can set up such that these dodgy binaries don't make it past automated QA; alternatively, is there an easy way to identify DLLs that I should ship?

Speaking of MFC dlls, I've come across a few MFC based applications that install debug versions of the MFC dlls OR depend on them being present.  Once I even discovered a $25,000+ engineering simulation package that installed all the app's symbol files too.

The former's always fun when you've got Visual Studio on your system.  It sure makes it easy to poke around in someone elses application.  When you get the latter though it's like solid gold icing on the cake.  What a blast and what a load of laughs.

What are these companies thinking (who do they have building their applications)?

Another way to look at it is the Redist list that comes with VS says that if you use a dll that is in the Redist list then you are required to install that file for your application to work.

>> What are these companies thinking (who do they have building their applications)?

Probably because it makes debugging issues in the retail version easier when performance doesn't matter much.

One the user-side, the most annoying aspect of this is the lack of CRT v8 (VS2005's C Run-Time Library) on a freshly-installed windows XP.

It seems that every computer I run into has not the redistributables installed yet.

One may wonder why the VS2005 Redistributables are not distributed as critical update, while something as unfriendly as Internet Explorer 7 (and let's NOT talk about the WGA notification "tool") was...

Software licensing agreements are evil, and so are the corporations that use them (I just wanted someone to satisfy your prediction, and it might as well be me).  

The remainder of your blog is irrelevant. Completely. Who cares about MFC? MFC is dead....

>>Probably because it makes debugging issues in the retail version easier when performance doesn't matter much.

Ok, that may explain why some distribute the debug dlls (in violation of their licensing agreement I might add - since it's forbidden).

I worked with a developer who made the mistake of depending on the Kodak image controls.

When the client upgraded to XP and his code stopped working he sent them the Kodak DLLs and told them to push them onto 500+ desktops!

Needless to say, the license for those DLLs is now owned by some 3rd party, who might have been interested in the £200,000+ in license fees they were due :)

The really bad thing is there was only a small part of his ActiveX control that depended on the Kodak Dlls, and he could have made a simple code change instead. The client didn't/doesn't know that those DLLs are unlicensed :(

>>Medinoc - One may wonder why the VS2005 Redistributables are not distributed as critical update

Ummm, how about for the reason Raymond mentions in the article and its title - Windows is not an MFC delivery channel.  Every computer doesn't need those, else they'd be a part of windows and not redistributables that YOU are suppost to redistribute with your app IF it requires them.

To Jack Mathews and Thom: there's no reason why you can't have symbol files for release builds. And you don't have to put these symbol files on the production system in order to have easier debugging facilities. Of course, that means you have to change some of VS' default project settings for release builds but no-one ever claimed that the default settings are the best. Would be a nice subject for one of Raymond's blogs...

@bigfoot

'MFC is dead'? What are you? a VB programmer? Go shoot yourself in the (big)foot somewhere else.

MFC is a bunch of classes to ease the programming in VC++ which is pretty much the only tool for somebody wanting/needing better and finer control of their application development. As long as something better doesn't come along, VC++ will be alive and so will be MFC.

I hate worrying about whether a customer has a DLL or not. I statically link as much as I can into the application. I hate shipping unnecessary DLLs, because people can and will lose parts of your application if they know enough to be dangerous. Static linking is considered quaint by many, but it does ease deployment.

(Yes, I know, I can't get security updates automatically when dependent libraries update themselves. I'll live.)

This is one of many reasons why I static link to MFC whenever it is pratical to do so.

Simon Farnsworth has a point, I don't know of any list that tells me whether the seemingly random dlls dropped into C:\Windows\System32 (for example) are part of the "contract" or just left there to die by a third party. The intermingling of OS components with third-party files is a mess.

"People go scrounging around the binaries that come with Windows looking for something they can remora"???

Well, a remora is a type of fish noted for attaching itself to surfaces, commonly known as a suckerfish.

So to translate, this means "something they can suckerfish".  Or maybe something they can attach to.

www.m-w.com gives synonyms of "hindrance" and "drag".  

"People go scrounging around the binaries that come with Windows looking for something they can drag or hinder".

Thanks for the new word, Raymond!

To address the posting itself...

Yes, the the DLLs that appear in C:\Windows\System32 (or wherever) are merely "implementation details", and not part of ANY contract.

The implied contract says that Windows will operate.  It doesn't say how Windows will operate, or how many or which specific DLLs will be present in order to make Windows operate.  

In a perfect world, you wouldn't concern yourself with the contents of C:\Windows, or even have cause to look in there.

Microsoft could decide to rename every single DLL or combine them all into one, or into two, or something, if they chose to, and as long as Windows still operated (including the published APIs that are covered by any consent decrees) the contract would be fulfilled.

Wow.

> One the user-side, the most annoying aspect

> of this is the lack of CRT v8 (VS2005's C

> Run-Time Library) on a freshly-installed

> windows XP.

> It seems that every computer I run into has

> not the redistributables installed yet.

Maybe because it's the programmer's job to make sure their installer has everything it needs to install the program? Isn't this one of those "taxes" Raymond's always talking about in this blog?

> One may wonder why the VS2005

> Redistributables are not distributed as

> critical update, while something as

> unfriendly as Internet Explorer 7 (and let's

> NOT talk about the WGA notification "tool")

> was...

Maybe because the VS2005 Redistributables are not a critical update? I mean... duh! How many XP computers do you think run software that requires it, but that software didn't put it there when it was installed? If that sentence makes sense.

IE7, on the other hand, introduces gobs of security-related features and protections that are obviously apparent to Joe Sixpack. It arguably might not be a "critical update" since IE6 is still supported for security issues, but I have no problem with Microsoft on this one.

And if you don't like WGA, well, then eventually you get to the point where you stop griping and use another OS. Microsoft's free to do what they want with Windows; if you don't like it, run something else.

Is the point that the Fax Viewer was written incorrectly and shouldn't have placed mfc into Windows\System?

Inre Simon Farsworth and Dave, in a previous life I spent a lot of time with installers.  Understanding what is and is not a guaranteed part of Windows can be quite a headache, especially for small companies.  There is of course the DLL Database at http://support.microsoft.com/dllhelp, but to use it effectively you need to know and understand the delivery vehicle for every binary that your application depends on.

Alos, the problem is less pronounced now, but early on, you couldn't guarantee that people would "follow the rules" for shared items in Sys32...uninstalling some downloaded game could take MFC with it and wipe out your app...things have come a long way since then (details better left for linking to many articles Raymond has written or posted on the topic.)

I learned early on - your installer is the first program that you write that your customers will run.  Problems there do not set good expectations for the rest of your applications.  As such, it requires planning and testing.  Virtualization is a huge help for checking that your installer will work on pristine versions of an OS (as well as ones with "reduced functionality" that occurs when someone deselects items that are present in "Typical" installations.)

It's interesting the different approaches different OSes take to the issue of common libraries.  VMS, for example, was the distribution channel for the run-time libraries for all of the languages supported by DEC compilers.

Maybe it's apocryphal, but an old DEC guy told me that the marketers wanted developers to redistribute the necessary libraries, but the OS engineers were against that, as it would have contributed to problems we now call DLL Hell.  To block the marketers, the OS engineers wrote bits of VMS in all of the supported languages (BASIC, Bliss, C, Cobol, Fortran, Pascal, PL/1, etc.).  This made the OS dependent on all of the run-time libraries, and thus the libraries had to be distributed with the OS, and reduced the tax on all of the third-party developers shipping software for VAX/VMS.

Granted, MFC is more of a framework than a run-time library for language support, so something like that might not have been included.

This issue circles the question of what is and what is not part of the Windows operating system.  Since there does not seem to be an official list of binaries, where does one look?  The Windows directory and its sub-directories? MSDN? The PATH environment variable?  The progressive lockdown of the Windows directory in recent versions of Windows goes a long way towards answering the question though.

Seth: Not sure I follow you. On my machine, the default VS config for release builds is to build the symbol file as a separate .pdb. This seems ideal to me: The developer keeps the .pdb for the exact released version of code. If a user has a crash (and you capture a stack trace + load addresses on it), it should be easy for the devloper to figure out exact location by loading that .pdb.

What other settings would be better?

>> To Jack Mathews and Thom: there's no reason why you can't have symbol files for release builds. And you don't have to put these symbol files on the production system in order to have easier debugging facilities. Of course, that means you have to change some of VS' default project settings for release builds but no-one ever claimed that the default settings are the best. Would be a nice subject for one of Raymond's blogs... <<

The debug MFC doesn't just give you symbology, you also get asserts and mostly valid local variables in the debugger for your application.

Mind you, I'm not advocating shipping this way, but at the same time, the implication was that people were shipping this way out of sheer ignorance and I just wanted to bring up alternatives.

The mixing of 'windows' components and ap'redistributable' components somewhat randomly in the system32 directory has been a cause of pain for me lately.  We've been trying to ensure that all code we have linked in at runtime is signed.  This is great until some other group somehow manages to load a stray copy of the VC runtime from the system32 directory that isn't signed because it was dragged onto the system by some other 3rd party.  Sure that other group should just fix their component to be more specific about what DLL it is loading (it does install a private copy that is signed), but that is easier said than done in any organization larger than 5 people.

However Windows clearly *is* a .NET delivery channel (okay, seems to be, look at all these updates it's pushing on you). All libraries are equal but some are more equal than others?

Bigfoot, MFC is not dead and thousands of current applications still use it, for better or worse. I'm no fan of MFC myself but even I still use it when I want to throw together a quick and simple C++ GUI app.

Even if MFC were obsolete it would not make Raymond's post irrelevant.

Despite the title mentioning MFC, the moral of the story is that you can't depend on the DLLs that happen to be on the HDD in one install of Windows being there in another. That issue may never go away and is independent of MFC, Kodak Image Viewer and so on.

Maybe you'd prefer articles titled things like "Windows is not a $product_name delivery channel", but if you can't generalise the message from a couple of specific examples then I doubt there's much hope for you.

Seth, the debug version executables and the ones with symbol files I was referring to came from outside our company.  In the latter case we had purchased a $25,000 license for a piece of specialized engineering software.  It was a low volume, high price, market with only a couple competitors to their product.  What they delivered to us as a "retail" product was a debug build complete with symbol files.  

If you're writing and selling software in a market where you can easily command that kind of price for a license would you ship all your customers a debug build complete with symbol files?  

It'd sure make easier for a customer or current or future competitor to reverse engineer your software.  That might be all the edge they need to eliminate a need for you or to gain an edge and push you out of the market.  If nothing else it'd ease the process of patching your executable to eliminate its serial number/licensing/fob detection/validation routines - then your $25k software ends up readily available on the net and there goes your future customer base.

Windows *is* an MFC delivery channel. MFC42.DLL is under System File Protection from Windows 2000 onwards, although I'm not sure if it's still there on Windows Vista. If not, a lot of people's installer logic is probably broken.

The 'merge module bugs' page at http://www.installsite.org/pages/en/bugs_msi.htm#wimsm lists the conditions that should have been set in the VS6 merge modules to avoid System File Protection problems. Ultimately that's probably a bug in Windows Installer - it should have used the query function SfcIsFileProtected to skip files that are protected.

@Avidgator: I'm not sure if anyone's maintaining the DLL Help database. It was good when it was new, but recently it seems to not contain newer products, and the amount of duplication is horrendous. It needs to only have one row per version of each DLL and be kept up to date with every public hotfix, if possible.

"

Another way to look at it is the Redist list that comes with VS says that if you use a dll that is in the Redist list then you are required to install that file for your application to work.

"

So what do you do if you develop with something other than VS?

The best strategy is just to redist everything possible, but that leads to problems: Is it really reasonable to expect the user to download a 200MB installer that includes every dependency (many/most of which they probably already have) for my 5MB app?

In other words, this isn't just a "developer tax" it leads to a *user* tax: Either the user has to know which runtime libraries they have/don't have, or they have to download vastly inflated install packages.

User taxes are evil.

The only way around this is to use an installer, detects what dependencies the user doesn't already have and downloads them as necessary.

Then what happens when the user copies the installer to a computer without internet access?

What happens when they try to install an out-of-date version?

Do I have to maintain a server containing the dependencies of every version ever released?

Even MS doesn't do this. It's more-or-less impossible to get the IE4 desktop update for W95/NT4 these days (esp. NT4) because the download servers no longer have them.

I don't understand what a handful have a problem with here.  The documentation tells you what you need to redistribute if you link to MFC or other Microsoft libraries that aren't a standard part of windows.   These all come with a list of redistributable files and frequently their own installer.   If you link to third party libraries or controls that you've purchased the right to use then their documentation also tells you what files to include with your app.  

The only time I've ever seen anyone make this mistake is when they failed to read the documentation or they went willy-nilly adding every activex control on their system into their project as if it were a part of windows they had the right to use.

Learn to read your documentation!

Nice to know that bit of information 12 years after Windows 95 was released to the market :) Point being: MS need to cleary document these things, otherwise no one could ever guess which one of the hundreds of files are there for what reason.

Another approach could have been to define some easy to understand (for developers/users) rules, to decide which .dll belong to "core" Windows, which to Windows "options" and which ones were installed by 3rd party applications. Such a simple rule could have been to have let's say three different folders for .dlls (core, options, apps). Or another even more clean solution could have been to install this fax application into a completely separate dir somewhere, along with it's private .dll dependencies. To make the situation even cleaner, MS could have been avoiding using elements which require such "3rd party" .dlls.

I think it all comes down to the chaotic way the Windows OS folder structure, OS file names, components are organized. Or in fact, not organized at all. Not even in Vista.

The same problem existed with ATL.DLL and MSVBVM60.DLL. With ATL.DLL you could statically link and MSVBVM60.DLL was almost always present anyway in System32 due to its popularity.

But as commenter Wesha says above, Vista *is* a delivery channel for the .NET Framework version 3.0. So that means that a future Service Pack for Vista should include the next version .NET Framework (I'm just wildly guessing that version will be 7.0).

To Mike Dimmick: the reason that MFC42.DLL is under the SFP umbrella I believe is because Wordpad.exe is a Windows component. Perhaps you can say MFC42.DLL is another instance of the fax viewer syndrome :-)

in reply to early comments (not the article)

As far as I know, you don't have the right to distribute the debug version of MFC or C-Run Time.  But the majority of programmers are not very smart. Even in a smart company, often a third party utility or pet project is compiled in debug, and then the guy that handles the setup adds that debug dll to the setup.  Setup is often given to juniors and an afterthough.

Installing these in the window directory is disastrous, since debug versions of DLLs are not guaranteed to binary compatible between minor updates, and often aren't.  

"Microsoft could decide to rename every single DLL or ..."

Not happening, because every EXE file has import table entries referencing the system DLLs by NAME. Not backward compatible.

Speaking of the XP Picture Viewer, MS should'nt've killed it in Vista. The Photo Gallery isn't as fast as XP's Viewer even on my Core 2 Quad Extreme, neither is the browsing of photos fast enough. People liked XP's Viewer for its sheer speed.

Maybe if MS documented this stuff we wouldn't have to guess.

But!  It should not come as a surprise to anyone when things change in future versions of Windows. Sure, we may not like the changes or agree with the changes, but things change.  Even in the same version of Windows, thanks to Windows Update, changing drivers, new types of hardware, etc.

When it comes to application compatibility, you have to stay on top of things and be ready to work around things and make changes at any time.  This is just the way things are.

Btw @someone, you're right.  The XP Picture Viewer was WAY better than Vista's Photo Gallery.  I mean come on, they couldn't even implement scroll bars??  Maybe MS felt they needed to do a favor to the third party folks who write image viewers.

Microsoft does document this stuff.  

Check the readme files on any Visual Studio distribution and you'll find a list or redistributable files.  Non-Microsoft compiler?  Same deal.

Check the readme files on any (DAO, OleDB, OpenGL,DirectX, etc.) Microsoft package or library and you'll find a list of redistributable files.  

Open the MSDN help pages for a library or function and you're never too far away from discovering where they reside and whether that package is a core part of windows or something with files you need to redistribute.

Guess what, one of the key words to watch for is "redistributable."  Find it and you'll find something telling you what files are needed and redistributable or what what files aren't (maybe some of both).

Read, read, read, read, read, read, read.

How would any compiler documentation document the fact wether any common .dlls found in a Windows install are "officially" redistributed along Windows, or just sitting there by mere coincidence? Such a list used to indicate that these libs can be legally redistributed by 3rd parties, no more.

Problem is: MS never defined the boundaries of its tools and parts, and failed to properly separate components. %windir% is essentially a mishmash of different files (binaries) created by different parts of MS, without any noticable coordination or system.

Good news for those who worry, separation of components seems to be an important development goal for the next Windows version. Maybe they can find some time to cleanup the file/folder layout too.

You're right.  The redist notes, when they exist, often do give some information about this.  But they don't always exist, and even when they do exist they don't always have all of the necessary information.  It seems like they are an afterthought in many cases.  It's a good thing we have blogs and forums and Google to help find answers to our questions.

I'm pretty sure a lot of these things are well documented, so whoever claimed it wasn't is insane.  I know that in InstallShield they give you a list of merge modules that you should be reviewing.  You can also have it automagically check for other installed apps if you're relying on some other application's DLL that isn't in a merge module.  The bottom line is that this is elementary installer stuff.

As to what is "officially" distributed, it should be pretty obvious.  If you're reading MSDN it should be a few short clicks to figure it out.

My guess at what is guaranteed to be part of Windows would be that anything documented in Windows SDK is going to be there, every single function/interface/etc has a list of Windows systems that support it. If you reverse engineer a DLL that happens to be in %SystemRoot%\system32, or just see one that you're using and don't check to see if the functionality it exports is part of Windows, you're on your own. Just because the default setup of most Linux distributions installs the whole X-Window system it's not guaranteed to be there. The kernel is, the rest isn't.

Now the problem is that the Windows SDK documentation does include .Net framework and even IIS documentation - listing for example that ISAPI extensions require Windows XP Professional, Windows 2000 Professional, or Windows NT Workstation 4.0 and Windows Server 2003, Windows 2000 Server, or Windows NT Server 4.0. The product linked under that documentation lists that:

IIS 6.0 is included with Windows Server™ 2003 and is installable via the Add or Remove Programs item in the Control Panel. IIS 6.0 installs in a highly secure state, serving only static HTML content until other features and file types (such as ASP and ISAPI) are enabled.

IIS 5.1 comes with Windows XP Professional and is installable via the Add or Remove Programs item in the Control Panel.

IIS 5.0 comes with Windows 2000 Server and is installed by default. It also comes with Windows 2000 Professional and is installable via the Add or Remove Programs item in the Control Panel.

IIS is also available as a separate product for previous versions of the Windows operating systems, but this SDK covers only versions 5.0, 5.1, and 6.0, with some limited information for IIS 4.0.

The information is out there, just RTFM.

AsmGuru62: It's been done before, actually. In Windows 1.0 there was a DLL called KERNEL.EXE. Later there was also KRNL286.EXE and KRNL386.EXE, which were used when running in protected mode, and in 3.1 since real mode wasn't supported any more KERNEL.EXE went away. Programs would still import from "KERNEL" but they would actually be importing from one of the new files.

Microsoft could document this from here to Tuesday, it wouldn't make a difference. The world is full of Windows programmers who don't even understand what it means for a function to be in a DLL.

@vsz - of course no compiler or library documents the files in the windows directory. You don't care what's in the windows directory.  Repeat after me - I WON'T LOOK IN THE WINDOWS DIRECTORY FOR LIBRARIES AND CONTROLS TO USE AND I WON'T USE DEPENDS.EXE TO GENERATE THE LIST OF DLLS MY APPLICATION USES, IT'S ONLY FOR QUICK CHECKS OR CONFIRMING THAT I DIDN'T MAKE A MISTAKE AND MISS SOMETHING.

When YOU wrote your program you KNEW what libraries and controls YOU CHOSE to link to.  You make a list of those and then you check the documentation for each to discover what files need to be redistributed.  Some may have come with your compiler. Some may have come as seperate SDKs from Microsoft.  Some may have come from third parties.   Whatever the case if you look in their documentation you will find your answer.

The SDK and MSDN documentation tells you the core libraries, the shell, etc.  MFC, the other assorted Microsoft SDKs and packages, and third party libraries all list their files.  If you're trying to utilize functions in a library or control that's in the system directory but isn't documented in the SDK or other then you can bet it isn't a core Windows component or that you shouldn't be using it.

Certainly there are instances where a dll will be mistakenly be left out of documentation or something will change between Windows versions but it doesn't take long before those are found and documented in the KB or on a supplier's site.

"Since there does not seem to be an official list of binaries, where does one look?  The Windows directory and its sub-directories? MSDN? The PATH environment variable?  The progressive lockdown of the Windows directory in recent versions of Windows goes a long way towards answering the question though."

If by "answering" you mean "creating another thing for devs to misread as official Microsoft policy" then yes.

Every Windows API function on MSDN has a section identifying the DLL it resides in and operating system versions that support it. Every single one.

MFC is not documented in the Windows API section of MSDN. It's in the Visual Studio section. Some developers understand what this means. Most probably don't.

Correction: MSDN identifies the library file, not the DLL. Which just goes to show that a "list of DLLs" is the wrong thing to ask for.

someone wrote:

>Speaking of the XP Picture Viewer, MS should'nt've killed it in Vista. The Photo Gallery isn't as fast as XP's Viewer even on my Core 2 Quad Extreme, neither is the browsing of photos fast enough. People liked XP's Viewer for its sheer speed.

Actually I preferred the Kodak image viewer to the XP viewer for its functionality.

Reading the comments, I see static linking as a solution. It is not.

Do you keep track of all the MS updates, test and publish patches for your application if some library changes?

I hope you don't get to see what happens if a security update is released for the library you are using, and your application is the one causing some billion dollar losses to your customers.

(and don't start a flame war here, it was a long one few weeks ago on a newsgroup, look for it)

Since this blog is probably going to be used as "official documentation" by clueless developers, here's the link to the official Microsoft instructions for redistributing MFC: http://msdn2.microsoft.com/en-us/library/ms235264.aspx

Interesting read...

Is there a reason MFC30.DLL was in the system32 directory, instead of the Fax Viewer directory?

Anonymous Coward: I think the company can still use the Kodak imaging files as long as they purchase WinXP upgrade (instead of full version) and continue to own Win2k license. I seen somewhere that you're permitted to continue use it if it's a "WinXP on top of Win2k" system. (And it's logical to allow this too.)

What I dont get is why various versions of the .NET runtime (both full installs and service packs) are available over Windows Update/Microsoft Update (as optional installs) yet the Visual C++ dll redist and the DirectX redist (d3dx.dll etc) are not available at all. Anyone know whats different between the .net runtime and the other stuff?

Jonathan Wilson: Size perhaps? The VC++ redist is quite small, and it's not a big deal for developers to include it as well. But the .NET framework is quite large, so requiring developers to include it with their own software might be a bit much.

Just a guess...

Thom: The fact that the program you needed cost $25k doesn''t mean it'll be the best well-written program ever.

I have personally found that the more expensive the software, the lousier the quality in every which way (e.g., UI, oddities, bugs, etc), mostly because of the limited market. Limited market means a very niche program, and there will be few competitors, so there's no need to do a lot of "spit and polish". A $25 application, may be used by a lot of people and if it sucks, people will make lots of noises.

An engineer, though, is a very limited market and they'll put up with lousy tools (face it - how many of us complain about Visual Studio's oddities yet live with them rather than using a competing product?).

Also, I bet that application had very specific requirements - change one variable and oddball things broke (which may require a complete reformat and reinstall). Price is no indicator of quality, and specialized software is probably the worst offender of all.

I also wouldn't be surprised if the reason that $25000 program shipped as a debug build was because it won't run in a retail build. (We all had that happen). The people who test the thing are probably engineers and not programmers - they know how to test for correctness, but best practices and what not, not so much. They tried a retail build, found all sorts of wierd issues and decided that since they don't know why it broke, they'll ship the debug build instead, since it works. (I bet their code probably has stuff like uninitialized variables and such, and in the debug builds. memory is often zeroed for you, and uninitialized variables... are initialized.)

Truth is, these engineers behind the program probably came from a more UNIX like background, and made a Windows version because it is the predominant version. Of course, they may understand UNIX and such builds very well, but things like Windows UI guidelines, what files to ship, etc are foreign concepts. Also, to do a lot of Windows stuff, they probably hired some cheap co-ops to do a lot of the work, concentrating more on the engineering than the UI fluff.

"For example, one customer had reverse-engineered the Kodak image viewer in Windows 2000 and wanted to keep using it in Windows XP. But those components are not included in Windows XP; the Kodak image viewer was merely a stopgap solution until the Windows XP fax and image viewer came along."

And it sucked from the perspective of not being able to display embedded TIF files.

Stopped a 15000+ seat WinXP deployment cold.

Microsoft provided us with an WinXP installable version of the Kodak image viewer, free.

Thom: I have no personal problem idenfying a given .dll or look it up even in 3-4 different places to decide about its status. But let's face it, this problem is far from obvious (and just one of the many), documentation is huge, ppl won't fully read it, which means: out of 1000000 developers, say 200000 will get it wrong. All I'm saying is that with _some_ (relatively marginal) effort on part of MS, all these problems could easily be _avoided_ in the first place. In other words, a system based, designed and implemented upon clear rules is much better than a well(ish) documented chaos.

@Worf - I agree with much of what you say but still argue that none of that justifies the stupidity of distributing software ripe for reverse engineering.  Whether a $25k piece of software with a few hundred licenses sold or a $25 piece with a few hundred thousand it's a bad deal for you if you do it.  

@vsz - I'm assuming that you're not new to Raymond's blog in which case I'll point out that Raymond frequently discusses cases where clear rules are specified and yet they are missed, ignored, or worked around causing chaos of their own.  I agree that things could be easier, but they can't change overnight on a platform as diverse as Windows where you have to maintain backward compatibility.  If you can document a way to make the changes you suggest without breaking everything else I'm positive you can demand MULTI-MILLIONS of dollars from Microsoft and get it.

> Read, read, read, read, read, read, read.

Building an app is hard. (I know you want the next line to be "Let's go shopping" but stay with me.) Building an installer for an app is a nightmare.

My app probably isn't that unusual. I *do* look at the documentation but I also include third-party software. Seems to run fine on my dev box. Seems to run fine on a few beta tester systems. Then I try on a bare XP SP2 setup and get a missing DLL.

Did I miss the tool that Microsoft ships to see what you link to and make sure that it's either a standard part of Windows or warn you that it needs to be in the setup package? Am I the only person who's built an app on XP, then sent it to a Windows 2000 tester who reports a missing DLL entry point? YES, IT'S DOCUMENTED. But I would appreciate a tool that let me know I was linking to an XP-or-later entry point.

@edinoc

I did a fresh install of XP SP2 yesterday and there was no IE7 offered on WU at all...It wasn't even present as an optional update (unlike Windows Media Player 11). I had to go fetch it myself from the IE7 website.

How naive to assume files in the system(32) folder are system components.

And microsoft's own deployment tools doesn't include such files in the msi package when automatically generating dependencies. How about fixing this before complaining about your customers?

@RichB: "Is the point that the Fax Viewer was written incorrectly and shouldn't have placed mfc into Windows\System?"

Not when 1GB hard drives were a luxury to have.

@Sam: "Not sure I follow you. On my machine, the default VS config for release builds is to build the symbol file as a separate .pdb. This seems ideal to me..."

It also places the path to the PDB file in the executable.  Just wait until someone discovers a program with the following string embedded in it:  "C:\Source\RipOffOfCompetitorProduct\ripoff.pdb"

Lorn horn: You must be new here. Raymond works on the shell, he doesn't work on any "deployment tools". Why don't you complain to the right people next time?

MFC8.0 SP1 fixed some bugs in MFC8.0 RTM but MS did not put MFC8.0 SP1 onto Windows Update, even in non-critical section. Why?

I've got the point, but MFC is a bad example. It would be better for all if MS delivered MFC via Windows Update.

There are a lot of Windows programmers who don't even understand what it means for a function to be in a DLL...

And the debug MFC doesn't just give you symbology, you also get asserts and mostly valid local variables in the debugger for your application.

I would like to know about msvcrt.dll mess. It is changing with every Windows version and corresponds to different VC runtime versions (and seems to differ with actual msvcrXX), with different functions. Why such decision was made? Is it a load of compatibility problems?

@Dave: the tool you require is in the development system. Set the macro WINVER to 0x0500, and the compiler won't even let you compile any code that depends on features added after Windows 2000.

For a more comprehensive discussion see Raymond's post on the topic: http://blogs.msdn.com/oldnewthing/archive/2007/04/11/2079137.aspx.

If you aren't explicitly setting WINVER your environment is setting it for you somewhere.

@Mark K

"It also places the path to the PDB file in the executable.  Just wait until someone discovers a program with the following string embedded in it:  "C:\Source\RipOffOfCompetitorProduct\ripoff.pdb""

Errm. So what? You don't distribute the pdb file, you keep it for yourself for debugging.

@scorpion007:

"Errm. So what? You don't distribute the pdb file, you keep it for yourself for debugging."

Read what you quoted again.  It doesn't matter that you don't distribute the PDB; the name and path of that PDB is embedded in the EXE.  So if the path itself contains something you don't want people to see....

If you bundle applications with your OS, don't be surprised when people assume that they and their components are part of that OS. After all, isn't that what MS has been saying for years?

"After all, isn't that what MS has been saying for years?"

There is a difference between bundling applications and the IMPLEMENTATION of those applications.

People don't complain that byte 0x001823 in kernel32.dll (or whatever) changed from one version of Windows to the next: that's an implementation detail.

In the same way, the exact number and names of DLLs in the System32 folder is an implementation detail, subject to change. The only thing you can rely on is what is documented.

gkdata:

Never been a vb programmer, though I did start out using raw basic many years ago. I use assembly, C, C++, and C#, and dabble in others (learning Erlang). As to your comment...there are many other frameworks out today that are far superior to MFC, the leading contenders being .NET and Java. MFC was worth using when it was released but that was a long time ago; now it is obsolete.

Sure, some people are still developing MFC apps, but that's like some people kept developing 16 bit apps when 32 bit first became available. In the long run, 16 bit programming is dead, and so is MFC.

Leo:

When I want to throw together a quick app I find that .NET is far better than MFC.

I think Raymond is correct in the low-level details but incorrect in his assumptions.

Since MFC is a MSFT product, essentially an application platform, the distinction RC makes is a very fine one, and one I disagree with. For all intents and purposes, MFC has effectively become part of the system platform, and we would all have been better off had it been treated that way. Pointing out the fine print in the contract may work for lawyers, but as time has shown, developers are too busy writing code people want to use then to stop and read the fine print.

I agree that this problem is not limited to MFC but MFC has a special responsibility to get it right because it is a platform used by many apps, not a specific fatture set of limited appeal, and because it is an official MSFT product. MSFT must keep in mind the unstated assumptions that the ISV community is likely to make. It's easy to say that Windows and MFC are not synonomous, but in practice they are, and should have been handled that way.

James Schend wrote:

"Maybe because the VS2005 Redistributables are not a critical update? I mean... duh! How many XP computers do you think run software that requires it, but that software didn't put it there when it was installed?"

In my experience: Almost all XP computers since many, many software don't come with VS2005 redistribuables.

This means that, every time you set up a new XP computer, the first time you install a VS2005 application, you get an error.

In my opinion, providing the most commonly used runtime librairies such as Visual Basic, Microsoft Visual C++, MFC, and maybe libraries of third parties such as Borland's libraries, would solve some of the DLL hell problems. (This doesn't invalidate Raymond's statements).

@Sam: Sorry. I was referring to VS 2003 that didn't have very good default settings for a release build. Since then, things have gotten better.

Monday, January 14, 2008 5:41 AM by dalevine

As to your comment...there are many other frameworks out today that are far superior to MFC, the leading contenders being .NET and Java.

.NET and Java have their own set of problems, see http://blogs.technet.com/markrussinovich/archive/2005/04/16/the-coming-net-world-i-m-scared.aspx.

>> dalevine - When I want to throw together a quick app I find that .NET is far better than MFC.

Arrrghhh, so you are one of those are you?  Build a small, quick, application and use one or two .NET functions then force every one of your users to download a minimum 20MB .NET runtime that takes up 100+MB (reported by windows) on the hard drive.  

I run XPSP2.  To this day I still don't have any version of the .NET runtime on my home systems and my work system only has it because Visual Studio installed it.  

My Samsung LCD monitor tried to install one version for its tiny little resolution tweaking utility that wouldn't take a 20k executable using Windows API only.  F-You Samsung, fire your moron programmer, I'll use the standard Windows dialogs and never buy another Samsung monitor.

The, thankfully small, number of programs I've used that have tried to force huge .NET libraries on me to use their pitance of features are uninstalled, tossed, sent back, etc.  

.NET won't make it onto my home PC until I install an application that I'm confident absolutely needed it.

"

Arrrghhh, so you are one of those are you?  Build a small, quick, application and use one or two .NET functions then force every one of your users to download a minimum 20MB .NET runtime that takes up 100+MB (reported by windows) on the hard drive.  

"

+ takes hours to launch.

+ be very unreactive and slow.

+ eat so much RAM that your background applications are "swapped" out to the disk.

+ require that you install IE 6 (slowing down your explorer) if you're running Windows 98 SE or lower.

Yes, Windows 98 SE, is still a good OS for old computers.

Worst: The .NET 3.0 framework seems to require Windows XP or higher!

.NET applications are low-quality software written by lazy programmers.

I'm happy that people are still using the blazingly fast MFC.

@Marc K

this is how most applications are distributed: we just don't ship the .pdb of the release version of the app.  It doesn't matter that the path to it is in the executable, it's harmless.  

The reasons is that you make a release build, then test that build, and you have the debug symbols in the .pdb to debug any problem.  When that build is validated, you ship it: you don't re-build again with the PDB generation off, because they would create another build that could contain new bugs.  Basically, we don't care about the few extra Kilobytes for the path of the PDBs.

"Just wait until someone discovers a program with the following string embedded in it: "C:\Source\RipOffOfCompetitorProduct\ripoff.pdb"

never happened, doesn't matter and it's childish. Look around at commericial apps, that's how it's done. It's very common on Unix as well to have all the source file names found in the executables.

Having PDBs for a release build is pretty damn essential in real life.  When we get a .dmp file from a client, we can easily check where it crashed by loading it and the PDBs in VC++.

If the price is the file path to the .pdb in the .dlls and .exe, so be it.

Richy: I've written plenty of MFC apps. And raw 'C' apps and low-level kernel-mode code too.

MFC was a step forward over the way I used to write applications because it handled a lot of the low-level grunge work that was needed when I wrote my apps in C (and later, C++), and it allowed me to work at a higher level of abstraction. .NET takes that even further and better - it is far more productive for most apps than using MFC.

All things have an effective lifetime and MFC is no different than any other software creature; it started small, became a big beast, turned into a dinosaur, and gradually will become extinct. When I hear your "arrrrrrrrrrrrrrrrrrrrrrrrrrgh" it sounds like a Peridactyl looking for a brontosaurus. It's not that there is no development being done using it, but there are fewer and fewer such efforts, and eventually it will mostly go away (not completely, but mostly). And for lots of good reasons.

A 20M download for the .NET runtime is trivial. And it's C++ that you like, then C++/CLI may be your cup of developer tea.

.NET is not the final answer, but it's a lot better than any previous answer I've seen from MSFT for building applications.

Raymond, I never said that MSFT should distribute "all popular official Microsoft products". The distinction you are making may be obvious from someone from the inside like yourself, but from my perspective there's not a lot of difference between the OS DLLs and the DLL's that are used by MFC that the applications require. To me, they are as much a part of the platform as is user32.dll, because I need both for my MFC app to run.

.NET does not make this distinction, or at least not so that it is apparent. The runtime and the BCL are intertwined. By managing these assemblies for us they have saved us from everyone trying to install/uninstall the same shared components and getting it wrong.

PingBack from http://lonesysadmin.net/2008/01/15/links-for-2008-01-15/

Why do I have to read the documentation? Why can't Microsoft adjust itself to my assumptions? I don't understand.

> There is a difference between bundling applications and the IMPLEMENTATION of those applications

They are not separate applications, they are part of the OS. MS tells us so.

"They are not separate applications"

Read my comment again: I didn't say what you think I said.

RC: "[Does this mean that, in your ideal world, Windows Vista would still include a copy of MFC30.DLL? <snip>..."

If an application required it and if such an application was installed on the Vista machine, then a means of installing, managing, and uninstalling system DLLs (i.e. MFC30.DLL) should be handled by the OS. What's missing is a sound versioning and deployment strategy; this is not a failure on the part of the application or the ISV.

I remember back when there were 3rd party memory managers, disk caches, TCP stacks, etc., and I remember that whenever MSFT bundled one of these features into the OS the argument made was that this was functionality that SHOULD be handled by the OS. There was lots of screaming from the companies that were put out of business but IMO it was the correct decision - it benefited all users of the OS.

I believe that managing the MFC DLLs (or more generally, files that wind up in SYSTEM32 or are system files) should also be the responsibility of the OS. This is one of those mundane, but incredibly difficult to get right, chores that ought to be handled by the OS.

Think of this as an opportunity to provide another service that will make Windows indispensable.

DileVine: "A 20M download for the .NET runtime is trivial."

NO, IT IS NOT TRIVIAL.  Your statement is a statement that ONLY a FOOL would make.  I don't care if every person in the world had 1.5TB download speeds - forcing the download of a 20MB runtime that eats 100MB of hard drive space for an application that could be contained in a 20KB-200KB-2MB executable is downright stupid.  

Please tell me what company you work for so I can direct my purchasing department to stay away from your products.  Attitudes like yours are why so many applications come with multi 100MB installs to support feature sets that are little or no more feature rich than Win98 versions that took less than 1MB of space.

Ah, I see that people are still struggling to get their heads around the IE integration thing.

It's been what, 10 years? and you still haven't figured it out?

"NO, IT IS NOT TRIVIAL.  Your statement is a statement that ONLY a FOOL would make. "

Indeed not. The good thing is that the .NET runtime (or any other runtime for that matter) is shared across all apps, so only have to be downloaded once per computer, regardless of how many .NET apps exists on your computer. Still, it would be nice if the .NET Framework is componented so only the needed parts are downloaded. For example, most users do not need the compilers. Sun is doing this with Java.

"Please tell me what company you work for so I can direct my purchasing department to stay away from your products."

I would not go that far.

Although I think Richy went a little overboard in expressing his opinion I'd have to side with him on this one.  His points are reasonably accurate and are valid despite their delivery.

It's not really true that it only needs be downloaded once per computer, in fact it's blatantly false.  First there are multiple versions so many users have downloaded or installed more than one.  Second every .NET app delivered over the web either has to deliver .NET in order to ensure it's there.

Sure, companies can develop installers that check for the presense of the required .NET runtime and install only their app or the app and runtime, but this sure complicates things and costs more money.  Worse yet, it doesn't always work if someone's .NET install is damaged or incomplete and that's a hard thing to troubleshoot.  That's why a great many companies deliver the entire kit and kaboodle in one huge download or force their less than savy users to download it manually if things don't go well.

.NET has its place but there are such things as misapplication and misuse and .NET is very widely misapplied and misused.

"NO, IT IS NOT TRIVIAL.  Your statement is a statement that ONLY a FOOL would make. "

Richy: What an ignorant response. Do you really think that SHOUTING makes you correct?

Really, if the statements I made are wrong then all it takes is a single, correctly reasoned rebuttal that proves it wrong, then presto - it is wrong. SHOUTING adds to the noise level but not to anyone's level of understanding.

Unless there is some reason why the footprint is too large for the target, then a 20M download is inconsequential. Sure, it takes time, and that's why .NET will be distributed with the OS, so that the download time you are upset about does not factor in at all.

If you are writing embedded apps then it matters, and componentized versions will be very important. .NET is not the best answer for all apps, but the arguments I've heard here against it are simply wrong.

As to the code bloat....this has been argued about for years, going all the way back to 16 bit windows (and probably way before). The bottom line...if you want functionality then you pay for it with larger binaries. I heard the same code-bloat arguments used against MFC. Perhaps we should all go back to writing DOS TSRs.

Thom: As to the versioning and deployment aspects of .NET; not all apps need to download it, and they certainly do not need to do it during every download, and they do not need to worry about how to version it. e.g. click-once.

There's also a runtime unification policy (here: http://msdn2.microsoft.com/en-us/library/9h55zhet(vs.71).aspx) that addresses side-by-side and versioning issues across multiple platforms.

Raymond: I've heard and read about fusion/side-by-side for unmanaged DLLs but I've not used it. I am more familiar with .NET fusion behavior.

I really should said once per version per computer, but that does not affect my point.

You are right that sometimes damaged .NET installs are hard to troubleshoot. The good thing is there is often a simple way to solve the problem, and as a last resort just uninstall the .NET Framework.

"

The bottom line...if you want functionality then you pay for it with larger binaries.

"

Simple .NET applications don't have more functionality than simple MFC applications.

They're just much slower and unreactive (these points, IMO, are more serious than the 20 megabytes of framework to download).

The initial statement was:

"

When I want to throw together a quick app I find that .NET is far better than MFC.

"

Moore's law has been beaten by slow applications!

http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

The bad news is that Office is one of the most optimized office environment on the market. e.g. OpenOffice is 10 times slower than Microsoft Office.

dalevine and Bao:  My point was as follows.

The only way you can be certain that your .NET app runs on your customer's computer is to ensure that it's installed.  That goes for every company distributing a .NET application.

How do they do that?  A significant number of companies choose to do that by including the .NET runtime in their default download package because, aside from bandwidth costs, it's the least expensive most customer friendly option...  i.e. minimal support costs.

This means that I, as a user of numerous software products, end up paying that 20MB+ runtime download multiple times - once for each .NET product I download and install - rather than your theoretical once.  If I download updates or new versions often times those too come a full installs complete with the .NET runtime rather than patches or minimal updates.  

If you build a full featured application that really utilizes .NET that's fine, I have no qualms with that.  If you build a miniscule application where you chose .NET simply because it's "the new thing", because it was the default, or because it had one or two library routines that saved you 30 minutes of reading or coding then I have a lot of problems with that.

I'm wondering if your prediction sentence is included in the "last two sentences"?  Is this like "Number of FAX pages, including this page"?

So Windows is a delivery channel for .NET but not MFC?

"How do they do that?  A significant number of companies choose to do that by including the .NET runtime in their default download package because, aside from bandwidth costs, it's the least expensive most customer friendly option...  i.e. minimal support costs."

No, that would be "most support friendly".  "Most customer friendly" would be not forcing people to download the .NET runtime more than once.

And guess what: they don't.  I have downloaded quite a large number of .NET apps (and written a few myself), and I can't think of a single one that has bundled the .NET runtime in the main installer.

Some will detect it and download it if not present; others will report it as an error and wait for you to download and install it yourself.  (And the badly-written ones don't even check and will just fail mysteriously if the runtime isn't installed.  But that sort of failure isn't specific to .NET.)

Occasionally the runtime will be included in a downloadable package as an alternative download (when you know you don't already have it), but that's fairly rare.  And the only time that I've ever seen a single version of the install that embedded the .NET install as well was when the install was on a CD anyway so it didn't make any difference.

(Now, if you're downloading CD images then it might get you.  But the cost of the runtime vs. the rest of the image is minimal anyway.)

It sounds like you are arguing out of prejudice more than knowledge.

@Miral:

First, I agree that there are some good .Net applications out there (an example off the top of my head could be SimPE game modding tool for Sims 2 game).

Unfortunately, that is where the agreement stops.

Take a look at Company X display drivers for example -- their Product Y REQUIRES .Net. That is not user friendly for several reasons:

1. You need to download and install .Net runtime (only once but still it is a PITA if you have dial-up which you would be surprised how many people still have)

2. .Net wastes a lot of HDD space (compared to the application size and featureset)

3. It has a shedload of small files taking a lot of time to install on older hardware and adding to the disk space fragmentation (and defragmentation) problem considerably

4. It generates binaries during install taking 100% of the CPU time preventing you from doing any other usefull work while it installs

5. It adds its own service contributing to the useless¹ resource consumption. That service is a proof that .Net is a bloatware otherwise it wouldn't require it in the first place.

6. It was meant to be a solution to the versioning problem but from the user standpoint it didn't solve that problem -- I still have to install .Net 1.1, .Net 2.0, .Net 3.0 and all the service packs and hotfixes to be able to use all .Net applications out there. So from 100+ MB we now come to 1+ GB of wasted space, 2+ services and counting.

Finally, there is no way that you can convice me (or anyone else who is sane and rational) that the functionality .Net offers you as a developer doesn't exist in other languages/APIs with a considerably smaller footprint.

In my opinion (both as a user and as a developer), using .Net is just a lame excuse for lazyness.

As for .Net being offered through the Windows Update -- as far as I know Windows or any of its components does not depend on .Net (or else .Net would come preinstalled) so I don't understand² why it getting different treatment than say DirectX, VC2005 runtime, and MFC.

--

¹ - Useless for the user who is not using only .Net applications all of the time he spends in front of his computer

² - Actually I do understand -- it is because Microsoft is pushing it as a preferred development platform. Speculation as to why they are doing it would lead down the conspiracy theory lane and I won't be the one to start it, I am just giving you some food for thought

@Miral: "It sounds like you are arguing out of prejudice more than knowledge."

That's funny Miral because I would have say the same about you.  Perhaps the reality is that you and I have completely different computers, different interests, and different download experiences.  Regardless of your experience, the fact is that I have downloaded several applications that used AND bundled .NET.  

I distinctly remember such applications because, for most, the minute I realized they installed .NET I immediately uninstalled them from my system.  I did keep a few, notably DVD and video editing packages, around for a bit to check their features and usability but they very quickly went away too.  Why?  Because their 150-200MB .NET application offered a pittance of features over, and a fraction the performance of, their 10-20MB non .NET applications of a year or two earlier.  Thank goodness for oldversion(dot)com.

Also, thanks much to Igor for reminding me of video drivers.  I have, sitting on my hard drive, the updated drivers I downloaded for my XYZ card.  It is a single file over 50MB in size and includes the .NET framework.  Their current download is only 31MB in size though and requires the user to have .NET pre-installed.  They apparently responded to the myriad of complaints about their 50+MB downloads that they moved .NET out of the install.  Thank goodness they also offer a minimal driver that comes in around 8MB and doesn't use .NET.  Only the poor saps who like to use Product Y to change resolutions and color depths need that extra 40MB+ combination of .NET app and .NET runtime.

@dalevine: "The bottom line...if you want functionality then you pay for it with larger binaries"

I would say more than that, it's if you want faster and cheaper development, you pay for it with larger binaries. You can have some damn impressive apps in small spaces if you want. But, someone using Windows Forms will very possibly get the job done faster than someone using MFC, especially for something UI-heavy.

It's unfortunate that .NET is a bit heavyweight for a lot of applications. I had a fun time trying to get software for a camera running on a semi-embedded computer when the camera software used .NET. I say "semi-embedded" because it was a PC architecture, but a very low-resource one. The most pressing thing was it had 384 MB of flash and no other stable storage. Getting Windows XP (Embedded) + .NET + camera software onto that was... an experience.

But, I don't think it's particularly slow, I think the 20M download and hard drive concerns are overstated above (admittedly I have an obscene amount of hard drive space, but just a standard DSL line). Maybe Yuhong Bao's idea to only install what is needed is best. And it really is a nice development platform. If I didn't need to worry about cross-platform compatibility, I'd usually take C# and .NET over MFC and C++ or Java or pretty much anything else I know in an instant. And with Mono, even if cross-platformness was a concern, it would still be worth considering at least a little. (But then MFC and the WinAPI are not options either.)

"It adds its own service contributing to the useless resource consumption."

That service is set to "Manual" meaning it only runs when it has to. It *has* to be a service because it must be run with administrator privileges (in order to compile code in the GAC). But it doesn't "contribut[e] to the useless resource consumption" because most of the time, it's not running.

"the functionality .Net offers you as a developer doesn't exist in other languages/APIs with a considerably smaller footprint"

You don't seem to realise the difference between a "feature" and the development effort required to *use* that feature. Obviously, everything .NET can do, any other turning-complete development environment could do. That doesn't mean you're not going to be spending 10 times more effort getting it to work in the native API than the .NET API.

As an example, I'm sure you could implement the remoting feature of .NET using named pipes or something in native code. But I pity the developer tasked with having to do it...

@Igor Levicki: I feel your complaint about used space is more due to the feeling of what space .NET SHOULD use (i.e. no more than a few megabytes) and not really the harm done by the cost of this disk space.

I'm also annoyed when I see a 4 op calculator less reactive on a 2Ghz computer, than the standard calculator was on a Macintosh Plus. But the frustration comes more from the fact that the application shouldn't use so much resources than from its poor usability.

Since you're counting .NET 3.0 in the hard disk used, I'm assuming you're thinking about Windows XP SP2 & higher machines.

Most Windows XP SP2 machines have HD with more than 20GiB of disk space.

1GiB isn't at all negligible, but far from being awful.

"

3. It has a shedload of small files taking a lot of time to install on older hardware and adding to the disk space fragmentation (and defragmentation) problem considerably

"

There are also indexing/searching and backuping issues. That's a annoying, but not awful.

"

4. It generates binaries during install taking 100% of the CPU time preventing you from doing any other usefull work while it installs

"

Well, it doesn't take years either.

"

6. It was meant to be a solution to the versioning problem but from the user standpoint it didn't solve that problem

"

Good point.

"

That service is set to "Manual" meaning it only runs when it has to. It *has* to be a service because it must be run with administrator privileges (in order to compile code in the GAC). But it doesn't "contribut[e] to the useless resource consumption" because most of the time, it's not running.

"

The fact that .NET requires admin privileges to be installed is also a factor that prevents me from using .NET applications at university.

"

You don't seem to realise the difference between a "feature" and the development effort required to *use* that feature. Obviously, everything .NET can do, any other turning-complete development environment could do. That doesn't mean you're not going to be spending 10 times more effort getting it to work in the native API than the .NET API.

"

That's true from a developer point of view, but from a user point of view, that's called "developer lazyiness". Something that saves precious time to developers, but reduce software quality.

... Since you develop software 10 times faster, which I don't doubt, why don't you sell your software 10 times cheaper? Or maybe you add more features to your application? Well, I find that .NET applications don't have more features than good old C and C++ applications.

Or develop 10 different .NET apps? I mean that the .NET Framework only have to be installed once per version per PC and then all .NET apps can use it.

It looks so nice at first.