From Win32 to Cocoa: a Windows user’s conversion to Mac OS X
[Quote:]
So Windows is just a disaster to write programs for. It’s miserable. It’s quite nice if you want to use the same techniques you learned 15 years ago and not bother to change how you do, well, anything, but for anyone else it’s all pain. I thought before that Microsoft cared about people like me. But it doesn’t. And it makes programming on Windows painful. Microsoft is great at backwards compatibility—you can take really old programs and compile and run them on a brand new Windows—but terrible at design and terrible at providing a good experience.
And it’s not just third parties who suffer. It causes trouble for Microsoft, too. The code isn’t just inconsistent and ugly on the outside; it’s that way on the inside, too. There’s a lot of software for Windows, a lot of business-critical software, that’s not maintained any more. And that software is usually buggy. It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hardcoded locations, all sorts of things that it shouldn’t do. If the OS changes underneath—to prohibit the reuse of freed memory, to more aggressively validate parameters, to stick more closely to the documentation without making extra assumptions or causing special side-effects—then these programs break.
So Windows has all sorts of bits of code which are there to provide compatibility with these broken applications. It’s hard for MS to maintain and fix this code, because it means the code no longer does what it’s documented to do; it does that plus some other stuff. It’s hard to test, because there’s no knowing exactly what broken things programs are going to try to do. And it makes things more expensive; Microsoft has all sorts of special behaviours it needs to preserve. This means that not only can it not make the API better—it can’t even easily make the API’s implementation better. It’s all too fragile.
This gives rise to particularly stupid things like the name of the “system” folder, where all the Windows libraries and programs are kept. In 16-bit Windows, it was called system. In 32-bit Windows, it was called system32. In 64-bit Windows it’s called, er, system32 again. Because although there’s an API call that programs can make to find out the name of the folder, there are enough programs that don’t bother using it and just blindly assume that it’s called system32 (even when compiled as 64-bit) that it was better for backwards compatibility to leave it, even though it’s chock full of 64-bit files.
32-bit files in turn go into a directory named syswow64. Right, it has 64 in the name, because it contains 32-bit libraries. Make sense? Only in Redmond. All these strange behaviors and clumsy APIs that they’ve built up over the years have just been plonked wholesale into 64-bit Windows. There’s no escape from them.
[..]
Third-party applications very much seem to follow suit. There might not be as much third-party software for Mac OS X as there is for Windows (a pleasing operating environment can only do so much to mitigate a 3 percent market share), but the quality of the applications is a great deal better. Third-party developers on Mac OS X strive to make applications that work in a way that’s consistent with the OS itself, with first-party applications, and even with each other.
These factors tend to reinforce each other. A good API makes it easier to write high-quality applications. High-quality, first-party applications set the standard by which third-party apps are judged and ensure that users have high expectations of the software they run. This in turn means that there is much more competition among third parties to produce something that’s great rather than merely acceptable. Regular updates to the OS keep developers on the upgrade treadmill; they work to make their applications fit in with the latest and greatest release, leveraging whatever new bells and whistles it provides, further improving the software ecosystem.
Um, no one has used the win32 API since 2003. Windows development is primarily done with .net which is very simple and easy to use. Certainly easier than Cocoa. I am a professional developer who has used both, and quite honestly cocoa is coveluted and still uses some features inherited from Pascal. The event handling model is horible and its generally over complicated.
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.
Um, no one has used the win32 API since 2003.
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.
They are sort of breaking with backward compatibility in Windows 7, or what will be the name. I am curious, that would be a big change, and the way the plan to do it will actually make Windows faster.
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.
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.
Developers have a choice–if they have existing Win32 code
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.