Developers don’t have a choice if they have existing win32 code, that’s the whole problem. Microsoft should start the gnashing of teeth of these developers (or rather, their pointy haired bosses), just like Apple did with Classic and Carbon. Many applications were available for classic Mac OS, OS X on PowerPC and are now on OS X on Intel, without Apple having a messy OS that has kludges up the wazoo to support the old way of doing things. And I bet an Apple developer that started out on classic Mac OS would likely continue to code new applications against that API, because that what he knows and is familiar with, instead of switching to cacao and objective-c. But he can’t, because Apple made a choice that Microsoft seems unable to make.

I don’t follow your logic here, John. Even if all new applications were written using .NET after 2003, Msft still could not throw away the old API support, because they want to support existing binaries. But the continuing availability of Win32 entry points doesn’t complicate new app development based on .NET.

Developers have a choice–if they have existing Win32 code, Msft does its best to keep those APIs working and keep binaries running; if they want a legacy-free dev environment, they can get that too.

There will be some backward compatibility changes. Maybe Transport Tycoon won’t run on it - MS implemented an “if TransportTycoon calls this” part, so it will be able to run after Win98 if I remember the version well, and tell me MS does not care about people - but well, such is life.

They tried to accomodate too many different needs, too many people.

I agree that regular updates and breaks keep developers on their toes, but unfortunately that’s not what companies who buy the enterprise softwares want. The relatively low quality of Windows based business applications is partly the result of the problems described above, but mostly the general business requirements:
1) Stupid and inplausible deadlines
2) Developers working on 23 projects where the priority changes every minute
3) Bad, really bad software development habits - except for the ISO, everyone is perfect on paper
4) The myth of efficiency - with 100% efficiency, if there is no time to improve, you will do what you always did.

and so on.

And when these same companies develop for Linux they got the same quality, so it is not about the Windows.
Does the fact that Windows keeps some outdated techniques alive contribute to this? Sure.
But not by preventing improvement, but by letting people skip improvement.

It is not the developers who need to be kept on the upgrade treadmills, it is the management who needs to be persuaded to pay for the reinvention of the wheel time and again.
And that is a hard task.

That’s the problem right there: if your statement were true, the win32 API would not work any longer. Yet it does, for the simple reason that people do use it - if you don’t, congratulations to you. The problem is that Microsoft cannot remove it, and that is causing a lot of people a lot of problems. You are lucky that you don’t have them.

In fact the article that you link to is about why .net was needed. So what is the point of picking out this quote to illustrate a completely outdated point.