How Microsoft Dropped the Ball With Developers

cremou writes "As part of an Ars Technica series on how one developer migrated from Windows to OS X (and why), this second article concentrates on how Microsoft bungled the transition from XP to Vista. The author looks at some unfortunate decisions Microsoft made that have made Windows an unpleasant development platform. '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... 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 hard-coded locations, all sorts of things that it shouldn't do.'"

Comments

Long Answer?

[Jeremiah Cornelius]

Read the article.

Short answer?

Windows!

Re:Long Answer?

[denzacar]

Actually it is more like:

I hate Windows. It robs me of my creative juices.
Because I am creative, you know... man?
So I "Switched".
Now, I code for OS X and every day is a beautiful rainbow for me.

Re:Long Answer?

[Jeremiah Cornelius]

You gotta admit, he has a point and illustrates it pretty well.

Re:Long Answer?

[644bd346996]

Exactly. He illustrates it well. That's coming awfully close to being, you know, creative. And creativity is one of the well-known risk factors for becoming a Mac fanboy.

Re:Long Answer?

[RiotingPacifist]

Does he have a point though?
I think the giveaway is when he says a screen shot is worth a thousand words, then his screen shot is of vista with the taskbar at the top, Im not saying nobody has the taskbar at the top but its just one of many signs that hes a fan of apple.

Im no programmer but the article seams short on facts & details and high on ms bashing & skimming.
Is the article right or is it just well presented trolling?

Re:Long Answer?

[Winckle]

I have my taskbar at the top, because it effectively reverses the order of the start menu. This makes shutdown the bottom option, which is where it should be, as i use it precisely once per session.

Re:Long Answer?

[ldhertert]

This was modded as funny, but, as a .NET developer, I find it to be exceedingly true. I just made the switch to OSX, because I was unhappy with the stagnancy of windows. But, as we speak, I have windows running in a virtual machine almost solely for the purpose of running visual studio. I find the articles critiques very hard to swallow. The argument that .NET is limited by the attempt to be simplistic is asinine. Just like java, there are high level "simple" functions that may or may not suit your needs. If they don't you have the capability to dig down into much lower level functions to do what you need to do. He states several problems with the UI capabilities of .NET. Before I even get into the technical components of his argument, if he's trying to say that Java is better in this area, then he needs to get his eyes checked. Every single java app I've ever used is ugly as sin, and I've seen a lot. Sure, it's portable across environments, but that's not what .NET development is being used for. Aside from that...not happy with with the windows UI standards? Everyone else seems to be. You can write .NET apps that follow very closely to the common windows UI design standards. Not happy with the limitations on the UI? Write/use another UI implementation like GTK. And how do we not even mention that the UI layer has been completely overhauled with the advent of WCF? I can say with experience that .NET is very powerful and can be very pleasant to work with. The ability to move from desktop apps to web apps to mobile development with very little effort has been great for me and my career. I'm sure that Java does a lot of things right, but as someone who has seen a lot of the terrible things microsoft has done, I honestly think that .NET is a crowning achievement of theirs.

Re:Long Answer?

[murdocj]

He has an axe to grind, but I'm not sure he has a point. For example, he talks about how .Net was supposed to insulate you from the vagaries of the Win32 interface,but failed. Then he talks about how the Win32 API returns the length of a file as two 32 values that have to be combined, instead of a 64 bit value. The part he leaves out is that .Net's system.IO.FileInfo does exactly what he wants... it returns the file length as a long 64 bit value. So why bring up the old 32 bit interface when you don't have to deal with it anymore? If that's the best he can do, his argument is in trouble.

Re:Long Answer?

[lgw]

.NET is the first thing MS has done in 15 years that's not tied to Win32 backwards compatibility. It's a fresh attempt to do things well. It's certainly cleaner than Win32, but neither that nor OSX (however wonderful it may be) will mater to me: Win32 is my profession now.

I heartily encourage everyone else, especially all developers in low-income areas of the world, to Make the Switch ASAP. The less labor supply for these horrible, inconsistant Win32 APIs (really, it's like programming while your face is on fire), the better!

Re:Long Answer?

[Anonymous Coward]

Short answer?

Windows is bad for developers.

Long answer?

Windows is bad for developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers! Developers!

(The lameness filter complains about my Ballmer joke -- it must be detecting residual Microsoft lameness.)

Re:Long Answer?

[Merusdraconis]

FTA:

"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."

As we see from the Windows and Mac OS (pre-X) ecosystems, this is completely false. Developers are loathe to change custom-written code that they know works in order to implement some kind of link to the OS; and in many cases they'll let old versions of their program stop working when a new version comes out and replaces it.

Microsoft knew what they were getting into with Vista's backwards incompatibilities, and oh lordie how people complained. Consumers (and, it seems, developers, who should know better) often blame Microsoft when their new product breaks backwards compatibility, even if it's the program's fault for doing it the wrong way. For the most part, Windows developers are pragmatic, which is why they're working on Windows (the biggest install base), so whatever works is more or less good enough.

I will delight at what happens if Linux ever manages to get majority market share and it starts getting some of the less-skilled pragmatic developers.

Re:Long Answer?

[Anonymous Coward]

Screenshots are "creative"? Wow, I'm a potential Mac fanboy and didn't even know it. Now I just need to blog about how harrowing and exhilarating it is to give birth to my amazing screenshots.

Re:Long Answer?

[Anonymous Coward]

Then he talks about how the Win32 API returns the length of a file as two 32 values that have to be combined, instead of a 64 bit value. The part he leaves out is that .Net's system.IO.FileInfo does exactly what he wants This was a complaint about Win64. He had different specific complaints about .NET.

If that's the best he can do, his argument is in trouble. If you can't even read his argument without getting mixed up, then your future is in trouble. (OTOH you have a bright future as a Slashdot poster. Not reading TFA is henceforth passé; reading it and getting it entirely wrong is the new standard.)

Re:Long Answer?

[niko9]

Yup. But there's still one thing you can't do elegantly when programming for OSX

Re:Long Answer?

[dcam]

Everything I have read and heard about Microsoft suggests that they are cowboys.

Code first, design later. For example, I note with interest the amount of pain involved in trying to provide server protocol documentation for the EU. Some of the foot dragging is deliberate but some of it is that they don't have quality internal documentation.

There is a severe lack of direction and leadership at Microsoft. They are just not forward planning. As a result they are tearing themselves to pieces, doing the same work again and again.

Re:Long Answer?

[xazos79]

You use the start menu to shutdown? That's so '95.

Re:Long Answer?

[thetoadwarrior]

Im no programmer but the article seams short on facts & details and high on ms bashing & skimming. Is the article right or is it just well presented trolling? How can you say it seems to lack info when you're not even a programmer. For anyone who has done programming between good languages and MS languages will know he's spot on and it's been well documented that MS went back on their word to build a .Net based OS that started fresh.

The problem is they know a lot of people aren't happy with Windows but it runs all their programs. Once the scrap that backwards compatibility and build something solid, despite the fact it may be their best OS ever, it's on a level playing field with the rest which means people have to find an alternative to their old programs and they might just pick something that isn't Windows and MS isn't having that.

Re:Long Answer?

[CodeBuster]

The argument that .NET is limited by the attempt to be simplistic is asinine I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. He is the first person that I have heard accuse .NET of being "too simplistic". The .NET class library (and Java class library as well) is the definition of everything and the kitchen sink. These are extremly powerful languages and libraries that are if anything too complex.

Before I even get into the technical components of his argument, if he's trying to say that Java is better in this area, then he needs to get his eyes checked. Again, I totally agree. The .NET Framework class libraries and the C# language are the definition of "The Right Way" to organize and structure code. They are technically sophisticated, architecturally beautiful, and make use of all of the best ideas at the culmination of nearly three (3) decades of object oriented programming theory and software engineering. If he is going to criticize .NET for its "lack of capability" then he is basically saying that Java is crap too, because .NET borrowed heavily from Java which in turn borrowed heavily from C++, smalltalk, and all the way back through C to Algol 60.

portable across environments, but that's not what .NET development is being used for It is supported and in the future it will become more and more common. The great innovation on the part of .NET was the common runtime type description language and metadata in addition to the common language assembly. This is what allows different programming languages to fully share types across libraries compiled from different source languages (including cross langague debugging). This was the feature that Java was missing and this is a major reason why .NET is so popular, it has the potential to end the "my programming language is better than yours" debate because the common types and assembly make the argument irrelevant. Use C# or use VB.NET or use Eiffel or whatever other language you want.

I can say with experience that .NET is very powerful and can be very pleasant to work with. I have been using .NET for six (6) years now and I can honestly say that it has fulfilled all of my expectations with very few dissapointments and it is improving substantially with each subsequent version. I know that I sound like a hopeless fanboy, but .NET really is a pleasure to work with, especially given the breadth and depth of the libraries and languages with a tool for every job and every job done with the right tool.

I honestly think that .NET is a crowning achievement of theirs. Although it probably doesn't hold much water with the Slashdot crowd, I think that it is fair to say that .NET is the best thing ever to come out of Microsoft, even though it wasn't a completely original idea (but how many completely original ideas have there been in computer science anyway? Everyone benefits from the work of predecessors and ones who have come before us).

Re:Long Answer?

[try_anything]

He states several problems with the UI capabilities of .NET. Before I even get into the technical components of his argument, if he's trying to say that Java is better in this area He's not. He said that Java provides a better-designed API based on simpler, cleaner concepts that are easier to learn, whereas there's a bunch of .NET functionality that has funny exceptions because of Win32. Swing isn't pretty to look at, but he is correct that it has a clean conceptual foundation, even despite being built on top of an earlier, abortive attempt at a GUI API, AWT. As a Swing programmer, you don't have to deal with redundant Swing and AWT functionality. (It's there, but you can ignore it at no cost to your understanding.) The parts of AWT that are required for Swing are simple, easy to understand, and not redundant with Swing functionality.

not happy with with the windows UI standards? Everyone else seems to be. "Happy with" and "stuck with" are two different things. Microsoft is screwing itself with the lack of uniformity in Windows. Microsoft's second-best asset (after developers, developers, developers) is the tendency of first-generation computer users to shit their pants when presented with minor look and feel variations. After Microsoft conditions users to expect a different look and feel for every new application they learn, normal users will be capable of switching between platforms without any problem. Then it will be a lot easier for businesses to use open-source operating systems to save money or to take advantage of an application that isn't available on Windows.

Re:Long Answer?

[LaskoVortex]

Yup.

Your link is all the more profound when one realizes that 90% of the posts on this thread are from defensive windows programmers. So, my question is, whence the hostility, man? When mac users/programmers say "Our platform is great!", windows users/programmers don't say "Ours is too!", but rather insist on "No, you suck!". Its always the same story. Just thought I'd point it out. Here is what I say: "Get a friggin' life! If your OS is so great, then there is no reason to say how every one else sucks because they think theirs is too." Or do you have some deeper issues with your OS that we don't know about and this is the source of your hostility? Perhaps if you talk it through you will be happier. Or maybe you could switch to a good OS. Just a suggestion. No need to get defensive about it.

Re:Long Answer?

[dcam]

Yeah, I think that Vista really demonstrates the Microsoft of today. They have a number of problems:
1. They aren't attracting the kind of people they once were, and many of the very good people have left. This exacerbates their other problems.
2. They are still trying to develop the same way they used to (cowboy), but are now finding that it does not scale well for the size of projects.
3. There seems to be a lack of long term direction, planning and vision. And by long term I mean as short as 3 years from now. This might be a result of 1.

Re:Long Answer?

[Metasquares]

Couldn't they even keep backwards compatibility via virtualization? They can have all the new apps run natively, and run the old ones on a virtual OS. It would give new apps a nice degree of isolation from some of the old badness.

Re:Long Answer?

[KutuluWare]

You must have had access to the sooper sekrit article with all the illustrations in it. The Ars article I read a blatent Mac fanboy bragging about Cocoa, with an extra two tacked-on pages of hyperbole and baseless accusations about how much .NET sucks, backed up with exactly 1 concrete example: that you have to know which Windows Forms operations are thread-safe (hint: none of them). He even finishes that thought by pointing out that most other GUI frameworks have exactly the same problem. I can probably rattle two dozen cases from memory in the old Win32 API where MS made obviously retarded design choices, but he can't even come up with a single actual .NET class method that he doesn't like when he's writing an article about it?

I am in that third group of developers this article was supposedly written for. I absolutely abhor poorly written code, cheap workarounds, etc. And I make a living off .NET and I love it. I usually find that the Framework already does anything I'd expect a base class library to do and a bunch more. The code I write against it is way more elegant than what I typically see from, say, your random GTK app. Is that because .NET is inherently better than gtk, glib, glibc, etc? No, I don't sit around whining about how Microsoft "blew it with developers" because they didn't write all my code for me... I spend my time writing good code.

Re:Long Answer?

[Anonymous Coward]

Must not be Vista. Otherwise you would only use the shutdown button roughly 50% of the time, with the other 50% being the reset button. :)

Re:Long Answer?

[drew]

While I mostly agree with you, I have to say that not everything is sunshine and roses in .NET land. Certainly, I think that the class libraries and the C# language itself are exceptionally well done, and the CLR will do wonders for the field. But coming from more of a web development background than a desktop app background, Wow did Microsoft mess up ASP.NET. After all the thought that went into the language, and the runtime, sitting down with WebForms feels about like getting stabbed in the eye. I don't have much experience with Windows Forms, but to the extent that WebForms was based off of it, I really have no interest in even trying. (It's rather outside my field anyway, so it's not that I am actively avoiding it.) For all the appreciation that I have for the .NET runtime as a whole, my impression of ASP.NET in particular was excellently summed up by Douglas Adams: "it is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words... their fundamental design flaws are completely hidden by their superficial design flaws."

For as much as I like programming in C#, I just can't see myself using it very often, as it is just not very well suited to the kinds of work that I do most, particularly web development, where I use mostly JavaScript and whatever server side language happens to be convenient, and low level server architecture, which I mostly do in C and occasionally C++. (I have some hope for the latter at least - the biggest thing holding me back is the lack of high performance networking API's to work with in .NET. If they can add something along the lines of Java's NIO, I might be able to start doing at least some of that work in C#.)

Re:Long Answer?

[Doctor Faustus]

For anyone who has done programming between good languages and MS languages will know he's spot on
Well, sort-of. He concentrates way too much on the Win32 API, which not too many people are using directly. His big complaint about Windows Forms was threading, which doesn't seem like a big issue (you may have multiple threads once-in-a-while, but will you have more than one working with the UI?) -- otherwise he just kinda says it sucks without suggesting anything better (SWT might be a possible candidate. Swing is not.).

And the .Net libraries are far from perfect. There are weird versions of a lot of things left over for the VB6-VB.Net porting wizard to use. The selection of functions on the String class has some very strange ommissions (.Right(n) would be nice). The IO libraries need a smooth system to switch between strings and structured objects when dealing with paths and filenames. FTP is still way too difficult. If you don't want to deal with those infernal visual designers, ADO.Net seemed to take several of the bad parts of JDBC without the huge positive that Type 4 drivers let you avoid any local installations. The settings system they push doesn't work with multi-project solutions. Etc. But he lost any credibility trying to hold up Java as a better example.

Re:Long Answer?

[JebusIsLord]

My experience thus far has been with Java (fine unless you try to do some GUI work, then blech!) and .NET (much nicer, IMO - .NET 3.x and WPF go a long way to resolving Windows Forms issues like scaling, portability, and allows for easier implementation of the MVC design pattern.) Interop with win32 IS a pain, but you don't have to do it too often. If you consider modern Windows development as .NET development, I don't really see the big issue here. I do with win32 would go away for good, though.

Re:Long Answer?

[VGPowerlord]

Or you could, you know, press the power button.

Unless you set Windows to do something other than shut down when you press the power button that is.

Re:Long Answer?

[CodeBuster]

I will grant you that ASP.NET has been a sore point, but they are finally starting to see the light with the ASP.NET 3.5 Extensions and the Model View Controller option for ASP.NET development. Scott Gu has an entire blog article series (complete with example project) covering the ASP.NET MVC Framework and it really is going in the right direction. I know that the MVC idea is not original and it certainly wasn't invented at Microsoft, but immitation is the sincerst form of flattery as they say and Microsoft is finally seeing the light on this one.

For as much as I like programming in C#, I just can't see myself using it very often, as it is just not very well suited to the kinds of work that I do most, particularly web development, where I use mostly JavaScript and whatever server side language happens to be convenient The risk there is that you are reinventing the wheel with JavaScript DOM code and other plumbing that have been done thousands of times before by countless other developers and, lets face it, probably done better. I wouldn't trust myself to write the best general purpose JavaScript libraries either and I wouldn't try, especially when I know that someone else has already done that. A really great programming environment frees one from having to be concerned with plumbing issues, that while interesting on some level, are not generally directly relevant to the problems at hand (i.e. business logic and what the site should actually be doing).

and low level server architecture, which I mostly do in C and occasionally C++

Reminds me of the CGI days which were really quite primitive compared with web applications that can be built today with the much better tools. Perhaps you are one of the ellusive jedi masters of C and C++, but I think it is fair to say that C or C++ are really innapropriate choices for the majority of web developers these days.

As for the absolute performance of ASP.NET vs other possible approaches I am not surprised that ASP.NET doesn't win the speed race, but really, how many of us run sites like Yahoo where that last ounce of performance and speed is really worth the price in terms of low level complexity and micro optimization required to achieve it? ASP.NET is an appropriate and reasonable choice for the vast majority of web application projects that most developers will be asked to build.

Re:Long Answer?

[SanityInAnarchy]

I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. Well, certainly, one argument he makes seems to be both dated and out of touch:

the last group could use C++ or whatever beret-wearing funky scripting language was à la mode at the time. This all worked out fine, because one of the few nice things about Win32 is that it was designed for C. C is in many ways a very simple language, and it's also a ubiquitous language. As a consequence of this, pretty much every other programming language created in the last couple of decades can, one way or another, call C APIs.... .NET isn't like that. Although .NET can call C APIs (just like everything else can), the real objective is for all programming to reside in the .NET world. .NET is meant to be the entire platform, with all the different languages that people use living inside the .NET environment.... It's still possible to use different languages with .NET (in fact, it's easier than it was in the pre-.NET days). Just now, the different languages all use the common set of .NET APIs for drawing windows on screen, or saving files, or querying databases, and so on. Here's my take, as someone who pretty much hates MS, and would rather avoid .NET if possible... .NET is trying to be the new C.

All his support for C could apply to .NET, and all his criticisms of .NET as a platform for people to run whatever they want could easily have applied to C. The one difference is that C simply has more adoption now.

Certainly, because it's so trivial to call out to C from .NET, there's nothing to stop you from creating and distributing your own .NET library, just as people distribute C libraries now. If your library needs to talk to the system in a way you can't from within .NET, you call out to C -- just as, in a C program, if you need to do something you can't in C, you use ASM.

This frustration is exacerbated when it's compared to .NET's big competitor, Java. Java is no panacea; it too is aiming roughly at the middle kind of developer, which is understandable, as they're the most numerous. But Java's much more high-minded. It's much stronger on concepts, making it easier to learn. .NET can call to C absurdly more easily than Java can. And C# supports things like closures -- at least, that's what they look like -- I know of nothing similar for Java.

I can't speak to the criticisms of the actual API itself. But that would seem to be more a criticism of .NET as implemented on Windows -- as the successor to Win32 -- rather than a criticism of .NET vs Java, or of .NET vs win32.

Although, glancing over at some of these, like the passing of two ints for the size of a file -- even on 32-bit Windows, that's kind of stupid. 64-bit integers may not have been fast, but they were certainly possible.

Re:Long Answer?

[JoshHeitzman]

Sigh, here we go again with the multiple inheritence argument. Multiple inheritence was almost *always* abused in the C++ days whenever it showed up to innapropriately compose unrelated classes for the sake of convenience and the utter violation of abstraction. The few legitimate uses of multiple inheritence, which are rare enough that I cannot think of them off the top of my head, can almost certainly achieved by alternative object oriented means in both Java and .NET in ways which do not carry the same potential for abuse or ambiguity.

Hmm, maybe like interface implementation inheritance, as I already said. Mixins is another. Every general programming language has features that can be "abused" and crappy code can be written in any language and I've seen plenty of it in C# and VB as well as C and C++.

Name a feature of C++ templates (other than multiple inheritence) that cannot be done in .NET with generics. I really tried to think of one, but I couldn't come up with a meaningful example.

I named one in the quote your statement is a response to "policy based design". Another is metaprogramming. If I remember correctly you also can't even do single inheritance through generics (i.e. have a class with its base class being specified by one of its generic parameters).

Is that your own terminology?

Nope typo. Should have been RAII rather RIAA.

There is not a direct comparison because destructors in garbage collected languages, such as .NET languages and Java, do not serve the same purpose as they do in manual memory management languages such as C and C++. In .NET the destructor, if one is implemented, is compiled into the Finalize method which is called by the garbage collector and not manually by the programmer. It is pointless to argue that .NET and Java do not include a feature of manually managed memory languages which is not needed because garbage collection serves the same purpose by different means.

Sure there is. Memory is only one of many, many kinds of things that is acquired and released, and many of these things can not be allowed to hang around until the gc gets around to finalizing the instance then the client of the instance ends up having to Dispose or Close or whatever to get it done immediately after they are done using it.

Here it comes, the car analogy: Both a manual transmission and an automatic transmission both shift gears so does it really make sense to argue about the details of *how* that happens as long as the gears get shifted? In most cases the answer is no. nitpick .NET all you want, but name another platform besides Java which includes half as many features or has a standard library which is half as complete.

By platform I'll assume you mean the runtime since you also mentioned standard library. I'd say the python interpreter has half as many as the .Net runtime. As far as standard library completeness goes I'm not of the opinion that a standard library should be to choke full of features myself. The more important thing to me is what the libraries that are readily available for the language will let me do and the libraries that are readily available for python are quite broad.

Re:Long Answer?

[radio4fan]

Couldn't they even keep backwards compatibility via virtualization? Yes, that seems like the way to make real progress to me.

And it's exactly how Apple supported OS9 when OSX came out.

It worked very well for the vast majority of programs.

Re:Long Answer?

[arkhan_jg]

This is theoretically the plan with windows 7. A new, clean minimal and modular OS based on the server line, without binary compatibility for old apps, with a new API for the new OS. Instead, there will be a separate backwards compatible API for a set of monolithic libraries providing all the old functions - same principle as Classic on OSX. Old apps will run as before, but through a compatibility layer to the new OS, while apps can be recompiled to talk directly to the new API, and presumably take advantage.

IE's rendering engine can go in the legacy libraries for old apps, for example, while being a modular component that's fully removable in the new OS (thus keeping the EU competition comissioner happy)

That's the theory anyway. Whether MS manage to pull it off is another question.

Re:Long Answer?

[nguy]

it's been well documented that MS went back on their word to build a .Net based OS that started fresh.

And this is different from OS X... how? Apple has no intention of abandoning Carbon, its old, hairy Win32 equivalent. And Cocoa itself is just a slightly cleaned up NeXTStep. So, it's not like Apple has these magical, shiny, new APIs either.

Re:Long Answer?

[nguy]

If you can't even read his argument without getting mixed up, then your future is in trouble. (OTOH you have a bright future as a Slashdot poster. Not reading TFA is henceforth passé; reading it and getting it entirely wrong is the new standard.)

No, he is saying that the argument is confused because it mixes up Win32 and .NET. That's a problem with TFA.

If you want to compare Windows and OS X as modern platforms, you need to compare the modern APIs, that is, .NET against Cocoa, nothing else.

Re:Long Answer?

[Jesus_666]

Given that we're talking about Microsoft they will probably make the new API also point to the compatibility libraries because either they couldn't finish the new framework on time (see the Vista featureset) or it'd be too slow (see Vista being based on .NET).

They do have a chance of making Windows 7 great, but after seeing all their recent developments being neither the savior some anticipated, nor the devil incarnate others anticipated but instead solid mediocrity... Let's just say I think it's safe to assume more of the same for Windows 7.

Re:Long Answer?

[OeLeWaPpErKe]

So let's hear it ... is xcode a real competitor to visual studio ?

Because let's be honest, while I use linux all the time, and I contribute every now and then to a number of linux apps. But I don't kid myself that anything that can run on linux (whether kdevelop or eclipse, or *even* vim) is half as good as visual studio.

And it's still the only real dev platform for smartphones and pda's. I have a maemo device, which is nice. But developing for it is a bitch to say the very least.

Re:Long Answer?

[vipw]

Apple IS abandoning Carbon. There will be no 64-bit version of it http://arstechnica.com/staff/fatbits.ars/2008/04/02/rhapsody-and-blues, so no one is going to be using it before long. Compare this to the current state of .NET, where developers have to constantly mix in win32 calls to do anything but the most basic applications. My own personal experience with .NET is only a few months, but I have had to use Win32 API a lot.

And NeXTStep is a magical, shiny, new API compared to Win32, which is the biggest mess I've ever seen. Admittedly, I'm used to simpler systems like UNIX.

Re:Long Answer?

[hatchet]

I don't think Microsoft wanted to be backward compatible, people - users wanted backwards compatibility.

It was same thing with processor architectures amd (x64) vs intel (IA-64). Intel's IA-64 (Iteron) is FAR superior architecture (256 GPR, register rename, register splitting, multiplexed operations, etc...) with no 8, 16 and 32-bit register functions for backwards compatibility. (Usage of emulator or additional 32bit core can be used to overcome this)

While x64 was just extension over IA-32 and current processors (Intel or amd x64) still have 8 and 16bit support functions (add ax, bx).

It happened because of you - users, who wanted to run your current (old) applications on new platform. Everyone loses, because we're using inferior architecture that supports 30year old applications. (yes, x64 is backwards compatible with 8088 processor which is asinine)

Re:Long Answer?

[hey!]

I always say: a developer who doesn't hate a platform just doesn't know it well enough.

It follows that programmers that rush to the defense of a platform as being for practical purposes the ultimate one aren't worth listening to on that topic.

Re:Long Answer?

[ncryptd]

The dirty little secret of Windows is that they already are doing pretty much that. Windows XP/Vista make use of something called WOW, short for Windows on Windows -- a compatibility layer that allows 16-bit apps to run on the 32-bit versions of NT. Unfortunately, this layer doesn't exist in 64-bit Windows -- at least not in its current 16-bit-supporting form. Instead, WOW provides 32-bit app support.

Re:Long Answer?

[DrPizza]

No, he is saying that the argument is confused because it mixes up Win32 and .NET. That's a problem with TFA. But the article doesn't do that, except when describing how details of Win32 leak into .NET.

If you want to compare Windows and OS X as modern platforms, you need to compare the modern APIs, that is, .NET against Cocoa, nothing else. But you can't. MS has added new features to Win32 (and VC++/MFC), and MS is going to continue to do so in Windows Seven. For example, Vista has a new transacted (database-style ACID transactions, not just journalled) filesystem. .NET doesn't support it; you've got to use Win32 to use it. Even though .NET does have transaction support (for COM+ transactions and database transactions) it doesn't support TxNTFS. So you've gotta use Win32. Or how about an MS-supported ribbon control? You've got to use MFC, and in Windows Seven there should be a native code ribbon control as part of the OS proper. In both cases, no managed code.

Having to drop into Win32 to call some legacy thing that no-one should really be doing but which you have to do for backwards compatibility, that I could sort of understand. But having to drop into Win32 to call new features that have only just been added? Anyone saying "stop using Win32, just use .NET" doesn't know what they're talking about.

Re:Long Answer?

[mgblst]

You shutdown, that is so 2000.

Re:Long Answer?

[DrPizza]

I agree. It sounds to me like this guy used .NET for a year or so around 2002 when it was brand new and then left and hasn't looked again for the last six (6) years. He is the first person that I have heard accuse .NET of being "too simplistic". The .NET class library (and Java class library as well) is the definition of everything and the kitchen sink. These are extremly powerful languages and libraries that are if anything too complex.

You seem to be confused between broad (.NET supports a lot of things, like sockets and cryptography and distributed transactions and GUIs and XML and oh my!) and powerful.

.NET does a lot of different things, but .NET doesn't have the greatest underlying abstractions. For example, to name a few:

• IList requires integer indexing. This makes it unsuitable for some kinds of sequential collection such as linked lists, which have no acceptable way of implementing integer indexing. Consequence? IList, whose documentation proudly claims to be "the base interface of all generic lists" is not, in fact, "the base interface of all generic lists". LinkedList does not implement IList.
• IList has no ToArray, but List does. Sure, ICollection has Count/CopyTo, but if the convenience method is good enough for List, it's good enough for IList. OTOH, if the convenience method is unnecessary for IList, it's unnecessary for List.
• Except for to confuse me, why do ICollections have a Count, when arrays have a Length? What's the meaningful semantic distinction that I'm missing here?
• Why do arrays have LongLength but with no corresponding LongCount for ICollections (3.5 adds LongCount as an extension method, but that gives it inconsistent (method) syntax, and of course it can never work because even if the collection were extended to support long lengths, an extension method can never exploit that fact, because the extension just works on IEnumerable which supports only an int Count)?
• Why do arrays have LongLength, and not simply have Length be a long? It surely didn't take a whole lot of foresight to figure that one out, did it?
• Where do I find reverse iteration/enumeration?
• Where do I find bidirectional iteration/enumeration?
• Why does the LinkedList expose implementation details such as LinkedListNode to users?
• Why is there no generalized mechanism for storing my position in a container?
• Why does HashSet have no ISet interface?
• Why is there no SortedSet?
• Why is System.Collections.ObjectModel not System.Collections.Generic.ObjectModel given that it is, in fact, for generic collections?)
• Why are there no static type-inferencing factories for read-only collections or singleton collections? When you have generics, factory methods are good, because factory methods can infer. Don't make me type IList myReadOnlyList = new ReadOnlyCollection(myList); the double specification of the type is spurious.
• Why is it named ReadOnlyCollection when it is in fact a IList?
• Why is there no true ReadOnlyCollection (i.e. that is actually useful for collections)?
• Why is it named SynchronizedCollection when it is in fact an IList?
• Why is there no true SynchronizedCollection (i.e. that is actually useful for collections)?
• Why is there no deque class?
• Why is there no IStack?
• Why is there no IQueue?
• Why do Stack and Queue hardcode their backing store, even though the performance profile may be better off using e.g. a linked list, deque?
• Why is KeyedByTypeCollection so widely useful as to even exist?
• Where do I find an equivalent to java.util.concurrent? Anyone suggesting SynchronizedCollection, please punch yourself in the face right now.
• Why are there new (.NET 2.0) classes that use old (non-generic) types, e.g. System.Net.Mail.MailMessage.Headers, which uses NameValueCo

Re:Long Answer?

[jeremyp]

So let's hear it ... is xcode a real competitor to visual studio ?

No it's not. I've been using Xcode for several years and I still haven't figured out how to build a Windows application with it. Conversely, Visual Studio cannot be used to build a Macintosh application either. The two IDEs are used for different tasks so they can never be competitors.

Is Xcode as good for developing Mac applications as Visual Studio is for Windows applications. I think probably not. It has some superior features (NB the most recent version of VS I have used is 2005 so my knowledge may be out of date). It has some features I like better than VS but that''s probably because I prefer the Mac environment. It has some features that are worse than VS. The debugger is the worst of these IMHO.

On balance Visual Studio is a far better developer environment, but that counts for nothing if you are trying to write a Mac GUI application, in which case Xcode is the only game in town as far as I know.

Re:Long Answer?

[BasharTeg]

No, he doesn't. Read about how he claims that the form thread synchronization mechanism is broken in .NET and will sometimes lie to you about what thread you're in which will cause your application to crash. This of course is news to us .NET developers who use the form thread synchronization in all of our multi-threaded applications and don't experience the FCL "lying" to us and we don't experience crashes because of false impressions that we're in the form thread. This is the kind of bug report I'd expect from a first year computer science student learning how to do form thread synchronization for the first time. His statements are complete horseshit, and it shows that this retard can't even accomplish the most basic tasks in .NET. Therefore, I ask who the hell is he to write a review of .NET versus Cocoa?

I think we could easily make that a litmus test for writing an article comparing the .NET platform to any of the other great platforms out there like Java and Cocoa:

If you can't figure out how to do basic form thread synchronization to allow worker threads to safely update your form's controls without claiming there's a flaw in the foundation class library, you are not qualified to write an article about .NET programming.

I won't even start on his biased slamming of enterprise systems development. It's clear that his knowledge of software engineering is limited to applications and he should just keep all other software engineering topics out of his mouth.

I'm sure Cocoa is an awesome enough development platform without needing this dumb ass to promote it through FUD and lies. I'd like to see him actually back up his claimed flaws in .NET with real code samples demonstrating them so we can point out his obvious errors and what a tool he is.

Re:Long Answer?

[Fred_A]

I think the giveaway is when he says a screen shot is worth a thousand words, then his screen shot is of vista with the taskbar at the top, Im not saying nobody has the taskbar at the top but its just one of many signs that hes a fan of apple. Uh ? I thought that his wearing pants was a sure sign that he was a fan of apple.

(makes note to move the KDE kicker down to the middle of the screen so as not to be branded a fan of anything)

Re:Long Answer?

[asc99c]

You're missing the 20% 'why on earth is it shutting down now' times.

Re:Long Answer?

[Fred_A]

Code first, design later. For example, I note with interest the amount of pain involved in trying to provide server protocol documentation for the EU. Some of the foot dragging is deliberate but some of it is that they don't have quality internal documentation. IMO, at heart, Microsoft is still a hobbyist software company that has grown obese. You'll never find the proper documentation that a professional company such as IBM or Sun puts out. Either of those could have drowned the EU under tons of ad hoc docs if they had been in MS's shoes.

I too believe that Microsoft just doesn't have any docs, it's not in their culture. It feels like they're still a PC (as in "toy computer") company that hasn't upgraded their way of doing things. The others may have moved to the PC as serious platform but a lot came from the big iron or the workstation markets where that kind of sloppiness just wouldn't do.
It really showed when looking at their documentation site which regularly used to border on the surreal back when I had to use it. Supposedly it improved a bit, although I still believe that this opinion is from people who have never seen a properly documented environment (I might be wrong of course, I'm lucky enough to be able to stay away from MS stuff nowadays).

Re:Long Answer?

[DrPizza]

The article didn't actually describe any accurate parts of Win32 that leak into .NET, except that WinForms is based on the WinProc event model of GUI development. That's one of the many valid ways to implement GUIs, and there's no reasoning as to why this isn't a valid design decision for Microsoft to make.

Well, there is a good reason why it's not valid: because it makes .NET developers give a damn about HWNDs, message pumps, and the interactions between the two.

Other than that, he points out a bunch of flaws in Win32 and implies that they "leak into .NET" but he fails to actually demonstrate any of them.

Off the top of my head we have, for example:

• the entire crypto lib (including e.g. certificate handling as well as core crypto functions)
• SSL handling equally has Windows-specific portions
• SocketException (especially ErrorCode)
• Socket.UseOverlappedIO
• Socket.IOControl
• System.ServiceProcess.* (this stuff should be in Microsoft.whatever, not System!)
• System.Management.* (ditto)
• System.Data.SqlClient.*, System.Data.OracleClient.* ((a) the core interfaces should be better (b) the vendor-specific providers should not be in System)
• The "Handle" properties found in e.g. Socket, FileStream, and the aforementioned System.Windows.Forms
• Large tracts of System.EnterpriseServices

Win32isms are abundant.

Further, your arguments that somehow cutting edge enhancements like Vista's new TxNTFS should magically appear in .NET by now make no sense to me.

Let's just recap the argument, shall we?

1) Claim: Win32 is clunky and horrible

2) Response: Write in .NET

3) Claim: .NET can't do everything Win32 can do, forcing me to use Win32

4) Response: "your arguments [...] make no sense to me"

Look, if the argument is going to be "Don't use Win32, use .NET" then .NET has to do all the things that Win32 can do. So which is it?

Either I should be using .NET--in which case MS's failure to add new Win32 features to .NET is a problem--or I should be using Win32--in which case "use .NET" is not a suitable response to cited flaws with Win32. You can't have it both ways, so which is it to be?

Re:Long Answer?

[CastrTroy]

I guess what they need is WOWOW. Which would be Windows On Windows On Windows. Just run the WOW 32-16 bit layer one the WOW 64-32 bit layer, and all your problems are solved.

Re:Long Answer?

[dbIII]

what is this "shutdown" feature you speak of?

It's an easy command.

shutdown -y -g 0 -i 0 "Going down because UPS batteries only last 3 years and have to be changed"

Then you just turn off the main system, each disk case and all the tape drives when it gets to the "OK" prompt.

Oh - you mean a badly done Mac clone. Just turn it off. You've probably already been hacked by a few kinds of malware so a bit of filesystem corruption won't matter much.

Re:Long Answer?

[VoidEngineer]

I'm curious as to why you're using any Win32 calls at all. I've been developing in C# for about three years now, and I can't ever remember making a single Win32 call. And I've been developing some fairly robust applications... i.e. multithreaded, networked, double buffered graphics, disk io access, numerical optmization algorithms, etc. The closest I ever came was when I was trying to figure out the size of the desktop, but eventually I figured out how to do that inside of .Net also. Everything else has been somewhere inside of .Net. Granted, sometimes it's been difficult to track down where in the API to find a particular function; sometimes I've had to write some wrappers and funky helper methods; but, I've never had to resort to a Win32 call. At the same time, I've *decided* not to make any Win32 calls, for portability purposes (as I want my apps to eventually be Microsoft free and be able to run on Mono). So, whenever I run across a place where I *could* use a Win32 call, I sigh, and then start looking for another way to achieve the same task within the .Net framework. Takes longer, requires more research, but keeps the application all within my own namespace and maintains portability and independence from a single vendor. I mean this is just my two cents, but it sounds to me like you haven't made a design decision to NOT use Win32 calls; and thereby, when you run into a situation where you *could* make one, it's a valid option, and you use it. (On the other hand, you design goals could be more in keeping with systems programming than applications programing; in which case, I would say... well, what did you expect?)

Re:Long Answer?

[ckaminski]

I'll tell you this, if you don't run your work in a separate thread, you end up with unresponsive interfaces. You can do tricks like periodically stopping work and checkpointing. But if you run into a database deadlock, or some communications deadlock, or you have a developer on your team who doesn't know his code is going to be used in a UI, then your interface hangs.

Threading is almost mandatory in well behaved Windows Apps.

The promise was that .Net was going to be *NEW* It wasn't. It still suffers all the major failures of the Win32API - though it does bring ease of use. Microsoft has a habit of abandoning technologies they invent (MAPI, MMC, RDO).

Then again, Swing/SWT has 5+ years on .NET, so I'm being a bit unfair. I just don't see Windows making a clean break from the past - they abandon the only thing that keeps them dominant, backwards compatibility.

Re:Long Answer?

[vipw]

An example is making the sort arrow show up in a listview control. http://www.thebitguru.com/articles/16-How+to+Set+ListView+Column+Header+Sort+Icons+in+C%23

But I've had far more fun with PostMessage and friends.

Re:Long Answer?

[DuckDodgers]

Well, Java is a better example by virtue of not having the same backwards-compatibility cruft to deal with. Even if the language itself is two steps forward and two steps back (depending upon who you ask) from C++, it has no real equivalent to the legacy API layers and apps .NET has to deal with.

I don't get the Java hate anyway. Performance is quite good now, SWT and some other tools make GUI design less painful, and a lot of the uglier toolkits (Struts 1.x, EJB 2, etc...) have nice new open source replacements. The Java development tools are now GPL. Until companies start hiring more developers to to work on Haskell or Scala, Java pays the bills and I neither hate it nor love it.

Re:Long Answer?

[mcrbids]

The problem is they know a lot of people aren't happy with Windows but it runs all their programs. Once the scrap that backwards compatibility and build something solid, despite the fact it may be their best OS ever, it's on a level playing field with the rest which means people have to find an alternative to their old programs and they might just pick something that isn't Windows and MS isn't having that.

And that is the point of this article. What keeps Windows' market share is inertia, and not much else.

As a writer/purveyor of work flow management software fitting somewhere between 2 and 3 in their list of programmers, (I write "enterprise" software, I sure give a damn about quality, but I shy away from the cutting edge) I'm not interested in anything specific to either OSX or Windows. I will not adopt a technology that ties me to either. But I deal every day with companies that have XYZ custom program that's written in VB or something and when I mention Mac/Linux/Alternative the first thing from their mouth is "we're Windows-only because of XYZ" with a shrug.

Here's what Microsoft needs to do to stay relevant:

1) Be Microsoft. Be OK with design by committee that "mostly works" and embrace the mediocrity therefrom. We don't expect you to be stylish, we expect you to be practical and cheap.

2) Eat its own dogfood. Why does Microsoft have published UI conventions for Windows that they don't follow? If ".net" is the one true way, why aren't all their new applications not written in it?

3) Be open. If Microsoft has this handy-dandy ribbon interface, it should be accessible to developers. One of the classic beauties of Windows has been the COM interface. .NET kinda shot that in the foot, and unfortunately, with MS almost abandoning .net, developers don't trust them, anymore. Remember when Microsoft was ABOUT developers? Now it seems that they are ABOUT STEALING as much bread as possible from them!

4) Make decent products! Ever try to develop for IE in a standards-compliant way? Even IE 7 is riddled with gotchas! How is it that there are three browsers out there developed by little guys (Mozilla, Opera, and Safari) that manage to get it "right" (or at least "right-er") when the Bazillionaire has a product that sucks so badly?

Sigh.

The result is that evelopers hedge their best with cross-platform technologies to mitigate the threat of Microsoft as much as possible. No, we can't ignore them. But we sure don't have to bow to them, anymore.

Re:Long Answer?

[dossen]

Damn - what a list.

My own additions - from doing Sharepoint:
- Key classes (SPSite and SPWeb) that are IDisposable. That's not too much of a problem, except that the documentation is somewhat vague on how to handle them - calling some methods will e.g. initialize the RootWeb property of SPSite, which you have to dispose, despite never having called RootWeb yourself. And sometimes you have to take care _not_ to dispose, as you are handed a reference to a shared instance of an SPWeb or SPSite.
- Several nice components are sealed and/or internal - my current pet peeve is a webpart, which has its look and feel defined via XSLT-files (big poorly documented XSLT-files, that do a lot of scary things to dump a lot of ugly HTML), unfortunately these XSLT-files are used by several different webparts, and some of them have neither the ability to subclass the webpart to use another file, nor the option of configuring which file to use. The only way to change that look and feel is to change the standard files.
- Checking user permissions in some places requires you to call a boolean method and receive true for access (sounds good so far, right...) and an exception for access denied!
- Not only is the default rendering a load of IE specific crap, if you dig deep enough, you'll find hardcoded strings inside the core libraries that, to the best of my knowledge, are not valid HTML in any contemporary standard. And the only way to get rid of it is to capture the output stream and clean it up by hand, one string pattern at a time.
- And that reminds me of a .NET one - why can't I do regular expressions on StringBuilder objects? I have to convert one to an immutable string, do my replacement that results in another immutable string. Just seems like an awful lot of copying, if I'm doing a lot of editing.
- And another Sharepoint gripe - why are all the interesting parts of my code inheriting stuff, that makes unit testing a real pain (I tried to mock my way through it once or twice, but the amount of code needed to test without invoking the database backend is beyond what I could justify even trying).

Re:Long Answer?

[AndyCR]

But I don't kid myself that anything that can run on linux (whether kdevelop or eclipse, or *even* vim) is half as good as visual studio. I have tried to use Visual C++, and it used to be my IDE of choice, but after using Eclipse 3.3 (they improved the speed dramatically in 3.3, from unusable to usable) for a year or so I simply cannot bring myself to use anything else. I recently tested out Visual C++ 2008, and it really pales in comparison to what I love with Eclipse. About the only thing it did better was debugging, and I would gladly trade excellent debugging support for decent debugging support with SVN, Mylyn, Ctrl+Shift+R to open a resource,and IntelliSense that actually -works- without fail every time (Visual C++'s IntelliSense just fell over after about 2 hours of using it and never came back, and refused to give any information on any library - not even the standard C++ libraries.)

About the only thing I see VC++ having on Eclipse 3.3 for plain C++ development besides debugging is speed. Visual C++ is comparably fast, but Eclipse isn't slow in the "it takes a while to respond" sense, but rather in the "there is a 7 second splash screen when you start it" sense. I can live with that.
I was rather disappointed, really. I had thought that I had given up a great IDE (VC++) to go to a great OS (Linux) with a moderately decent IDE (Eclipse); in reality, looking back I have up a decent IDE to go to a great OS with a great IDE. A few years ago I loved Visual C++ 6, and I suppose I'm just sad to see its ancestor thwarted on my desktop so easily by a free program.

(Disclaimer: The statement above is merely my opinion. Your opinion may not match it.)

Re:Long Answer?

[VoidEngineer]

I'm not going to go through your entire to-do list, although I will answer a couple of your questions.

Except for to confuse me, why do ICollections have a Count, when arrays have a Length? What's the meaningful semantic distinction that I'm missing here? ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.

Why do arrays have LongLength but with no corresponding LongCount for ICollections (3.5 adds LongCount as an extension method, but that gives it inconsistent (method) syntax, and of course it can never work because even if the collection were extended to support long lengths, an extension method can never exploit that fact, because the extension just works on IEnumerable which supports only an int Count)?
Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.

Why do arrays have LongLength, and not simply have Length be a long? It surely didn't take a whole lot of foresight to figure that one out, did it?
Chunking. .NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.

Where do I find reverse iteration/enumeration? Where do I find bidirectional iteration/enumeration?
Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.

Why is there no generalized mechanism for storing my position in a container?
You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.

Why is there no SortedSet?
Probably implemented somewhere else.

Why are there no static type-inferencing factories for read-only collections or singleton collections? When you have generics, factory methods are good, because factory methods can infer. Don't make me type IList myReadOnlyList = new ReadOnlyCollection(myList); the double specification of the type is spurious.
You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, double specifying types is needed and a useful (if not critical) feature.

Why is it named ReadOnlyCollection when it is in fact a IList? Why is there no true ReadOnlyCollection (i.e. that is actually useful for collections)? Why is it na

Re:Long Answer?

[DrPizza]

ICollections implement an IEnumerator interface and have an Enumerator object which counts the objects in a collection. Think of an enumerator as an odometer (like the one in your car). If the object implements ICollection, then it has an odometer, which you can get the count from. Arrays just have size.

Count is not a method; it is not asking "Count how many things are in this object". It is a property, and as such an intrinsic feature of the object (that behind the scenes it might have to do the verb thing is beside the point--it's semantically a property, even if it's actually a verb). And even if one were a verb--why should be it?

Again, difference between an attribute and a verb. LongLength is an attribute of an object, such as height or width. Whereas Count is like an odometer in your car. Your question is kind of like asking why can you travel tens of thousands of miles along the US highway, but my odometer in my car only goes up to 1000. Well, that's just the way the odometer was made. Length of trip is distance, whereas your odometer is a counter and is only a *measure* of distance. It's simply a distinction the language makes.

Again, though, the language doesn't make the distinction you are making. Count is a property, just like Length. If Count were a method I could sort of understand the difference (I don't really agree with it, it seems spurious, but I could sort of understand it). But it's not; it's a property.

Chunking. .NET gets used on both 32 and 64 bit platforms, and the performance penalty for splitting a 64 bit word into two is greater than using two 32 bit words. In the first case, you still have to use 64 bit words, but you pad the first 32 bits with zeros, and convert to 32 bit words. Requires an extra pass through the processor to calculate, whereas adding two 32 bit words into a 64 bit word is trivial. I'm not explaining this concept well, but if you look it up you'll find more info on the question you're asking. The design decision was based on current market saturation of 32 bit processors, and the LongLength was an added conversion for the 64bit programmers.

But LongLength means we won't have a clean transition, because it means people will have to fix up APIs to take longs where they currently take ints; making everyone pay the price for longs might be a short-term cost (though not a great one), but it'll be a long-term gain.

Using the odometer analogy as above, the enumerator only goes forward; although you *can* reset it. If you want to do reverse iteration, copy your collection into a new collections backwards, and iterate over that new object. Alternatively, for most reverse or bidirectional iterations, you'll simply want to ditch the 'foreach' loops, and use a simple 'for' loop. Then you can start high and use decrement iterators to count down. I also like to use decrementor collections which get an object removed with each pass of the for loop.

That really doesn't answer the question. In both Java and C++ I have iterating objects (java.util.ListIterator, C++ bidi/random iterators) that can go forwards and backwards. I use these quite regularly; why can .NET not provide the same?

You need to get the IEnumerator object from the ICollection, using the GetEnumerator method. It will have a Position field.

Neither here: http://msdn.microsoft.com/en-us/library/system.collections.ienumerator.aspx Nor here: http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx So I'm not altogether sure what you mean.

Probably implemented somewhere else.

I don't understand what you mean.

You're splitting hairs here. It's a strongly typed language. It's meant to be explicit, not inferential. In other projects, besides yours, do

Re:Long Answer?

[jafac]

yeah.

Start->Run->/cygdrive/c/cygwin/bin/bash -c shutdown -s 00

With those arguements, any platform can suck

[dreamchaser]

"It passes bad parameters to API calls, uses memory that it has released, assumes that files live in particular hard-coded locations, all sorts of things that it shouldn't do."

Those are basically programming errors, not problems with the API. Don't get me wrong, I find Win32 to be a pain in the ass sometimes, but this article just reeks of flamebait.

Re:With those arguements, any platform can suck

[Ulfalizer]

I think you missed the point.

The problem is that many major legacy applications depend on undocumented behavior because they make sloppy use of the Windows API (e.g. by assuming that a particular function will not segfault when passed a bad argument). For those to keep working, newer revisions of the API implementation must have the same undocumented behavior, which causes a maintenance nightmare.

Re:With those arguements, any platform can suck

[0123456]

"Those are basically programming errors, not problems with the API."

I think you missed the point. For the sake of backwards compatibility, Microsoft supports applications which do all these things, and drags all the associated crap into future versions of Windows so they still run.

For that matter, so do hardware developers: back when I was writing drivers for Windows I had to deliberately put bugs in our code to support applications which only worked because of bugs in the Microsoft versions of the drivers and would crash if we didn't replicate those bugs ourselves. We also spent weeks working around abuse of the API by a certain big computer company that can't program PCs worth a damn (or even, apparently, read API documentation).

Re:With those arguements, any platform can suck

[dreamchaser]

No I didn't miss the point. Using an undocumented API is another example of bad programming. Yes, even HAVING undocumented API's is bad as well. Like I said, I was not excusing the mess that is Win32, I was just sayin'...

Re:With those arguements, any platform can suck

[0123456]

Pretty much; if they stop supporting old bugs, a lot of old software will break. I'm sure I found an old Windows 3.1 bug in XP some time back, but I can't remember what it was (something to do with driver installation, I think).

Linux, in comparison, provides a fair amount of backwards compatibility, but doesn't have to overly worry because most software comes in source form and can be fixed when a kernel or library change breaks it. Windows doesn't have that option.

Re:With those arguements, any platform can suck

[x00101010x]

At least with Windows7, the backwards compatibility nightmare will be over with virtualization similar to what Apple did.

Re:With those arguements, any platform can suck

[fimbulvetr]

Maybe the point was that MS fosters bad programming by keeping legacy API calls around indefintely, whilst other systems do not. I'm the last guy to ever go pro-apple on /., having "been there, done that", but he really does have a point. MS is afraid to deprecate bad ways in favor of keeping some minor share of customers happy.

While this has short term benefits, the long term imposes a hefty penalty, the same penalty MS (and some of its developers) is paying now.

Re:With those arguements, any platform can suck

[drinkypoo]

Yes, even HAVING undocumented API's is bad as well.

I thought we discussed this when Apple did it? Undocumented APIs are there for the use of operating system developers and other people who feel the need to tickle the operating system at a low enough level to fool it into doing things that it was never intended to do for you. This is your prerogative; it's possible to sniff through the structure of the binaries to find new functions, and it's possible to debug functions to see what they're calling, so no one can really stop you anyway.

At the same time, being upset when they stop functioning correctly is the mark of a whiny idiot, because let's face it, they're undocumented. If you want that functionality exposed, by all means, cry to the OS vendor. Or, you know, you could support open source and/or free software and work with an environment in which you have all the source code and can at least make relatively responsible use of the undocumented functions, and if you are feeling froggy, even submit patches which express this functionality consistently with a documented API.

Seriously though, undocumented functions are par for the course. If the functions are never intended to be used by anything other than the operating system, and the functionality is expressed through the OS in some fashion (use of undocumented APIs in Win32 has often been done to work around a bug) then there's really no problem. The portions of the OS that need to be changed when the libraries change can be changed in such a situation (and hopefully will fail tests if someone doesn't think to do it beforehand.)

Re:With those arguements, any platform can suck

[fractoid]

MS is afraid to deprecate bad ways in favor of keeping some minor share of customers happy. This is true, but remember that when you sum up the minor share of customers that's made happy by each of these legacy APIs, you end up with a large number of developers. A very large number.

Re:With those arguements, any platform can suck

[Spy der Mann]

But I hope we agree that having to use undocumented API calls because it's the only way is the fault of the OS manufacturer, yes? Conclusion: Microsoft's greedy and dirty tactics are the very cause of its doom.

Someone said once (I forgot who) that Bill Gates wasn't a programmer. He was a businessman, and his business was computer programming. A true programmer would of course care if unauthorized copies of his operating system would be one of the main causes for viruses, spyware, spam and whatnot. A true programmer would care about developers not following the design guidelines. A true programmer would care about the darn security holes.

But neither Gates or Ballmer care about this important stuff. They're not programmers, they're businessmen, and the only thing they care about is the f***ing money.

No wonder Windows users are in deep sh**. Fortunately for me, I'm using Linux.

Re:With those arguements, any platform can suck

[pimpimpim]

What's the use of legacy support anyway. If you have a windows 95 application, it will always have problems running under XP. If it needs to use special PC ports (e.g. access to serial connections) it will be hell to get it working.

I understand the need at some places to keep running the old software, I've seen spectrophotometers that had to be connected to an OS/2 program, just because the software was only written for OS/2, but those cases you should either use virtualization, or treasure your old hardware.

Re:With those arguements, any platform can suck

[Aceticon]

I remember when in Windows the only way for an application to receive a notification when a directory was change was using an undocumented API.

Interestingly enough, at the time all Microsoft applications (like Office Word) seemed to have this "feature" while Microsoft's own Knowledge Base explicitly stated that Microsoft had no intention of making that API public.

Some of Microsoft's undocumented API features were not there for the benefit of the OS developers, they were there to provide a competitive advantage to Microsoft's own in-house applications development teams.

Re:Yeah, yeah

[Jeremiah Cornelius]

Ad?

What is this "ad" of which you speak? Your words are strange to us, visitor.

DOS/Windows programming culture

[erroneus]

The culture of DOS programming was corrupted from the beginning and you can partly blame IBM for a crappy BIOS. Were it not for the crappy BIOS, programmers wouldn't have had to resort to writing directly to hardware to get an acceptable speed on the screen. And it just kept going on from there. And now when a developer wants more "something" from the OS than they can get naturally, they write VxDs to help gain an advantage.

The culture is all about writing code to get past deficiencies and shortcomings in DOS/Windows.

Windows programmers don't respect the rules... and if they do, they write what appears to be crappy software.

Re:DOS/Windows programming culture

[frank_adrian314159]

Yes, but making the hardware suck to scrape a couple of pennies off the price didn't help the BIOS. Actually, I blame IBM more for not choosing a better processor than the x86. There were sane architectures out there at the time (e.g., Motorola 68000). A lot of the craptacular nature of the BIOS (not to mention DOS and early Windows programming) came out of that particular decision. But, back then, IBM was a fairly craptacular company anyway. It seems to have improved a bit since then (although, it's hard to tell; with a company the size of IBM, you may be looking at the stern of the oil tanker and everything looks fine, while on the bow, fires are raging).

Re:DOS/Windows programming culture

[larry bagina]

My understanding was that they didn't expect much of the PC market, so they threw together a bunch of cheap parts from other vendors and stamped their name on it. Based on their Apple II CP/M card, they asked MicroSoft for an OS instead of buying or writing one.

Re:DOS/Windows programming culture

[Sentry21]

The Motorola 68k was their first choice, but unfortunately it wasn't ready in time for them to use it for their systems. Intel's 8086 processor was their unfortunate second choice.

Re:DOS/Windows programming culture

[MojoStan]

My understanding was that they didn't expect much of the PC market, so they threw together a bunch of cheap parts from other vendors and stamped their name on it. Triumph of the Nerds: The Transcripts, Part II

According to the guys that created the IBM PC (Bill Lowe and Jack Sams), they did it this way because they thought they were running out of time in an important new market (PCs). The Apple II had been introduced in 1977 and was a runaway success. IBM noticed Apple IIs being used in the engineering departments of their clients.

IBM's top management met in August 1979 to discuss their "PC crisis." In another year, the PC industry might be too big for even IBM to take on. IBM chairman Frank Carey knew that it took "four years and three hundred people to do anything" at IBM. Bill Lowe, who would lead the IBM PC development team, claimed that his team could provide their product in a year. Carey gave Lowe two weeks to set up a proposal. Two weeks later, Carey bought it.

From the transcript:

• [Cringely narrating] He knew the company was in a quandary. Wait another year and the PC industry would be too big even for IBM to take on. Chairman Frank Carey turned to the department heads and said HELP!!!

  Bill Lowe: Head, IBM IBM PC Development Team 1980: He kind of said well, what should we do, and I said well, we think we know what we would like to do if we were going to proceed with our own product and he said no, he said at IBM it would take four years and three hundred people to do anything, I mean it's just a fact of life. And I said no sir, we can provide with product in a year. And he abruptly ended the meeting, he said you're on Lowe, come back in two weeks and tell me what you need.

  [Cringely narrating] An IBM product in a year! Ridiculous! Down in the basement Bill still has the plan. To save time, instead of building a computer from scratch, they would buy components off the shelf and assemble them -- what in IBM speak was called 'open architecture.' IBM never did this. Two weeks later Bill proposed his heresy to the Chairman.

  Bill Lowe: And frankly this is it. The key decisions were to go with an open architecture, non IBM technology, non IBM software, non IBM sales and non IBM service. And we probably spent a full half of the presentation carrying the corporate management committee into this concept. Because this was a new concept for IBM at that point.

The documentary goes on to describe how Microsoft (a computer language company at the time) ended up providing the operating system after the company that should have provided the OS (Digital Research) blew it when they met with IBM. Interesting documentary with interviews with the key guys involved.

Re:DOS/Windows programming culture

[rs79]

I worked at a computer manufacturor in the late 70's and early 80s in LA and started on 8-bit micros and was there for ther introduction of 16 bit chips.

I was used to PDP-11s keep in mind.

The problem wasn't the 68000 wasn't ready, it was ready. There were just no support chips yet. Intel actually delivered a complete solution: CTC chips, PIC's, serial ports, dma controllers, i/o processors (that nobody but us used).

Motorola had a CPU and that's it. A vastly *superior* CPU, but the hardware guys wanted to build systems not wait for the rest of the stuff they needed. So we all held our noses and went x86. And bought Amigas as soon as they were out (I have serial #11. Still.)

This crap as all in one chip these days, but back then computers had several large black chips inside them.

Comment removed

[account_deleted]

Comment removed based on user account deletion

how much MS bashing can you fit in?

[timmarhy]

"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 hard-coded locations, all sorts of things that it shouldn't do.'"

and this has exactly what to do with MS? the coding habits of programmers has NOTHING to do with MS.

Re:how much MS bashing can you fit in?

[Adambomb]

well, it does indirectly but not as blatantly as the article would have one believe. Don't forget that if the API's were properly designed to begin with, it would have been impossible to give invalid parameters to the function or allow the use memory that has been released.

I have no idea what hes on about with the hard-pathed file references.

The problem is so many corporate coders back in the day (and still) would use whatever shortcuts they could within the api including "undocumented features" like the former two issues. If Microsoft were to fix these issues without compatibility for these "features", it would break tons of legacy applications. Therefore, ongoing developing must include these already-incorrectly-designed portions of the API as well as whatever they really want to be working on.

Just because a company does something poorly to begin with and people adapted to it, doesnt mean the company isnt to blame for the issues.

Course that doesnt make this article NOT a flaming pile of rhetoric, it just makes it slightly less than complete and utter bullshit.

Re:how much MS bashing can you fit in?

[glebd]

Windows includes myriads of patches to adapt to buggy third-party applications and just make them work. I don't know of any other OS that chooses to silently ignore application bugs or modifies API behaviour to avoid crashing defective applications. So if an application is used or manufactured by a major business entity and is buggy, unsupported, or programmed by lazy/incompetent developers, chances are MS has one or two fixes for its bugs _permanently_ built right into Windows. Because if old and unsupported applications stop working in the next version of Windows, chances are MS will lose customers to other platforms. Application compatibility is the only thing that ensures continuous market share of Windows. MS is prepared to break the OS to support buggy and old third-party code. Now tell me how does all this improve your confidence in the quality of the Windows platform.

Re:how much MS bashing can you fit in?

[timmarhy]

it's only just better then total bullshit though. using his own benchmarks linux is a piece of crap for dropping features, and we should bash it for each any every poorly coded OSS project (believe me there is a LOT)

Re:how much MS bashing can you fit in?

[techno-vampire]

I have no idea what hes on about with the hard-pathed file references.

This goes back even before Windows. I used to have some DOS programs that would only let you save a file to a floppy. Not just games, a poster-creating program had A:> built into the path for saving files, and there was no way to change it. Granted, even the most rabid Microsoft-basher can't blame that on them, but it's part of the way programs used to be written. It's the same type of mindset as caused game designers in the early DOS days to hardcode timing loops because, of course, the PC would always run at 4.77Mhz.

Re:how much MS bashing can you fit in?

[mdarksbane]

The difference is that Mac OS X was a cutoff line for all of that backwards compatible crap. A whole lot of stuff broke with Mac OS X, and it sucked for a while.

Then everyone started using the new shiny API's and it started getting a lot better.

He's complaining that the windows API's are still hauling along cruft and junk and nastiness from 15 years ago. It hurts MS's ability to improve them, it hurts developers ability to use them, because they have to wade through pages of deprecated functions to find the correct ones, or hit strange inconsistencies that have been hanging around for years. It's also just bad for the general consistency of the experience - see the comment about the system32 on Windows 64.

He knows that bad developers doing stupid things isn't Microsoft's fault. But how you react to bad developers is. It's a tough decision to make - do you slap the bad developers on the wrist and break things because *they* were doing something stupid, or do you keep letting them have their way until it's their decisions that rule the API and the platform?

Re:how much MS bashing can you fit in?

[jabjoe]

but it's part of the way programs used to be written. What's this use to be written?
We had a script kiddy here who made a horrid tangled mess, hard pathing everything, including to a directory called "Not_Used_Anymore". He didn't know better.
The horrors of hard pathing are alive and well.
Hard pathing is just coding in a path into your source like any other constant. Sometimes it makes sense to do it (small personal batch script for instance) and some will always do it where they shouldn't (in something compiled or large).

As a dev who makes his living writing for .Net...

[Anonymous Coward]

I am 'this' close to jumping ship. I use Ubuntu on machines at home and find it fast and clean, even on older hardware.

I have access to all MS software as our MSDN and Gold Certified Partner plan administrator. I have tried Vista on a couple machines. Even on a brand new Dell dual core laptop with 2 gigs of ram, it was sluggish and still could not use the full aero interface. Yet I installed Ubuntu on a 4 year old 600m with 512MB ram and got a full interface with snappy performance.

I don't need aero to develop code. The features I was most interested in all got cut from Vista... most notably the filesystem upgrades. Now add frequent updates to the framework that require $1200 software packages to use to the fullest extent. Then add the insane cost of a legit SQL Server license on which to deploy it. Plus as a domain admin, I find the administration to be a drag. And I still don't trust them for a second on security. It all adds up to a monumental drag.

I am a frustrated .Net developer. I don't know that it is that much better on the other side of the fence frankly, at least as far of the coding environments go. But I KNOW for a fact that I prefer linux to Windows.

Same techniques 15 years ago? Not just Windows...

[Goody]

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

Apparently the author never heard of vi and gcc on Linux...

But Don't You Mean...

[morari]

How Microsoft Dropped the Ball With... Developers Developers Developers *insert techno beat* Developers Developers Developers Developers Developers Developers Developers Developers Developers Developers?

Re:But Don't You Mean...

[ExploHD]

*dhut* *dhut* *dhut* The System is Down! The System is Down! The System is Down"! *dhut* *dhut* *dhut*

But give them credit where credit is due...

[crt]

Microsoft has dropped the ball in a number of areas, particularly with regard to user-interface APIs which this article focuses mostly on, but in other ways it is far and away the easiest platform to develop for - mainly because of the quality of their development tools. Having done lots of development across Windows, Mac, and Linux with all kinds of editors, IDEs and debuggers, nothing comes close to Visual Studio in terms of functionality, quality, and just being solid. It's not perfect, but it's way better than anything else out there. For that reason alone Microsoft deserves some kudos from developers.

Re:But give them credit where credit is due...

[pebs]

nothing comes close to Visual Studio in terms of functionality, quality, and just being solid

Are you using the same Visual Studio I am? Because the one I use may have some decent functionality that you'd expect from an IDE, despite being crippled by a lousy interface (with some exceptions, they do some things very nicely). But when you're used to using Eclipse, Visual Studio feels like a cheap, buggy toy. I use both at my day job. I would never use Visual Studio unless paid to do so. Eclipse I use for fun on my hobby projects.

Yes, there are much worse IDE's than Visual Studio, but that doesn't mean its good.

Re:But give them credit where credit is due...

[nojomofo]

Holy shit, you've got to be kidding me! Even VS 2008 needs Resharper to even be close to Eclipse in functionality. Have you ever used a different IDE?

Re:But give them credit where credit is due...

[HeroreV]

What languages do you use with Eclipse? Just Java? Because everything else I've tried with Eclipse totally sucked.

Re:But give them credit where credit is due...

[Mongoose Disciple]

I think it's just one of those personal preference things, honestly.

I used Eclipse for years (still do, when I'm on a Java project) and I generally hate it. I can't back that up with any kind of empirical reason for the dislike besides its resource-hogginess -- it's just designed in such a way that whatever feels like the intuitive way to do something to me is wrong. It's like I've stepped into a bizarro world where the knob marked 'H' in the shower makes cold water come out of the nozzle and the knob marked 'C' makes hot water come out, and no matter how many times I do it it always feels confusing and backwards to me. People whose opinions I greatly value think it's the best thing since sliced bread, and more power to them.

I can almost always get more done with less time with VS, even though I've done Java development and used Eclipse twice as long. Your mileage may (and clearly does) vary.

Re:But give them credit where credit is due...

[Vectronic]

People who haven't given Visual Studio much of a chance often think Visual Studio is a piece of crap.

"one developer"

[Whitemice]

"how one developer migrated from Windows to OS X"

That pretty much says it all: "one developer"

The argument about old krufty code in Windows and the Win32 API has been around since.... the Win16 API! It didn't really seem to slow down Win32.

On the flip side is the argument that the need for backwards compatibility is holding back Windows - yet developers complain about the migration from XP to Vista?

All smells like we-will-find-anyway-to-condemn-Windows to me. Note: I do all of my development on LINUX, so I'm not a Windows booster. I think lots about Windows just stinks but there is an issue of credibility here.

If you want a clean new coherent API and you want to develop on Windows Microsoft has provided an option: .NET

Re:"one developer"

[Drishmung]

From TFA, he claims that .NET is neither clean nor coherent, i.e., that MS squandered an opportunity.

Cult of Backward Compatibility

[clintp]

The False God of Backward Compatibility has Microsoft by the short hairs. Even new programming environments like .Net have Win32, Win16, and DOS lurking right around the corner. There's no fresh start anywhere in the Microsoft environment, everything reeks of DOS.

Which would have been find if DOS (Win16, Win32, etc..) were a multi-platform, extensible OS to begin with -- but it wasn't. It was a quick hack that lives on and on.

I'm a developer that works primarily in Windows, with 15 years of heavy-hitting Unix programming experience behind me.

Re:Cult of Backward Compatibility

[daemonenwind]

It's not a false god, not when you're coding for a business that has to meet both regulators and profitability expectations.

Code written for Windows 95/NT (back in 1996) still works today on the Windows platform. 12 years later.

Try that with System 7 code on OS X.

Yes, this is part of why writing business-logic code sucks. You seldom get to just re-write anything to be really, truly good instead of something perennially built-upon and increasingly hacked-together. No one will pay for a change that doesn't deliver "business value". (And no, greater stability/performance is almost never enough, as that argument usually demands an associated headcount reduction) But at least the app still works and can continue to deliver. And since some will doubt, yes, I do maintain/enhance such code.

The market speaks - this sort of backwards compatibility is a conscious choice by MS, and it does sell their OS. Not concidentially, it also sells mainframes and *UX systems. And I'm convinced it's one of the big reasons Apple isn't bigger in the corporate world. Steve's demands for newer/better/faster totally supplanting the old are well known, and rightly feared.

Glory days are here

[icepick72]

Despite what's underneath Windows, programming it through the .NET platform is very slick. Most of what had to classically be linked to in obscure ways is wrapped in the Framework Class Library. Most people complain it's large but after you learn the basic structure you can find immediately what you need using the documentation. Microsoft has also abstracted away the trickyness of DLLs and you can program against mostly any functionality using your language of choice.

When articles claim Microsoft dropped the ball I think it's more wishful thinking than anything, because Windows programmers are in their Enterprise glory days right now, no longer restricted to VB and half-assed object models. Not anymore. We now have full OO features and much much more, and Java is playing cathup feature-wise. It's nice for a change.

I don't care how messy Microsoft's underlying code is, as long as they've tested it and ensure it works enough for me to program against it. The Microsoft security updates help a lot too. They're very frequent which means there are a lot of security flaws but they take care of them quickly (I'm sure I will get numerous examples where they didn't take care of security quickly but if you're on Windows update you see them coming thought all the time).

Re:Glory days are here

[ronark]

Sorry, but I must disagree with you. I program daily with .NET at work, and the number of times a P/Invoke is required to get advanced functionality is simply shocking. Not to mention the fact that despite the claim of being purely an object oriented framework, many parts of its design spit in the face of OO. I'm not talking about rarely used classes either. File, Directory, Math, Convert, Encoding, to name a few major players, cannot be instanced as they are declared static. How this is different from a simple function in C is beyond me. .NET might have a few things going for it (though the more I use it the harder they are to remember), but slickness is not one of them. Microsoft dropped the ball with .NET.

Re:Glory days are here

[icepick72]

Because some classes are static or sealed does not mean the CLR doesn't support full OO features. I known you recognize that but some people reading your post might misinterpret it so I'm clarifying. What it means is some class designers made some arguably bad decisions about how to allow their classes to be used. Sometimes the class designer is Microsoft. But I'm there with you buddy. If only I could count the number of times I've cursed a class designer because they didn't let me instance it. In the cases you mentioned I noticed you didn't talk about System.IO.FileInfo or System.IO.DirectoryInfo classes which are the instanceable counterparts of the static System.IO.File or System.IO.Directory classes you listed. Use the static classes for speed against multiple files and directories but if you want an instance wrapper around a file or directory you can easily do that with those other classes. As for the P/Invokes, well... I don't have a great answer except it's not a perfect world ... yet. .NET is a strong leap towards there.

Re:Glory days are here

[Anonymous Coward]

>> How this is different from a simple function in C is beyond me

It's no different. But do you really need it to be different or you are just a blind OOP fanatic ?

Describe the sin function. Why the hell should it need an instanced class ? Takes a number, spit a number everytime with the same logic. No different than the - operator.

I find the static class choice makes much more sense than instanced objects. OOP is a tool and a solution.. not THE solution everytime.

MS should follow Apple?

[Anonymous Coward]

What exactly is this guy recommending? He trumpets Apple for overhauling their platform and releasing a rapid succession of new OSes in order to advance the platform, which retaining absolutely no backwards compatibility. Meanwhile, Microsoft releases new runtimes for it's existing platforms, not requiring the purchase of a new OS, meanwhile retaining nearly full legacy support. How many 10 year old applications can you run on a new Macintosh right now, without relying on third-party emulators? You can count them on no hands. However, you can run the majority of 10, 15 and 20 year old Windows applications on Windows Vista.

And to claim that .NET is hobbled due to Win32 is just silly. He targets WinForms specifically, which, sure, is a wrapper around Win32. But to claim that you need to know Win32 to program WinForms is just ludicrous. It makes me think that he's never programmed for either platform. WinForms hides the details of Win32 a great deal, and it's very rare to ever have to rely on platform invoke calls. And if WinForms is such a problem, why not use Gtk#? Or WPF? .NET is not one monotonous entity, and there are several UI libraries.

He complains that the Win32 API for finding a file size requires you to deal with two 32-bit values, stating that on Win64 that it should return a 64-bit value instead. Well, if he wasn't such an idiot, he could use the newer version of that same API which does return a 64-bit value, on Win32 and Win64.

All this dumb shit seems to do is claim that the platform should be constantly broken, because that would be the most convenient for him. If you think that the developer experience on Windows is bad then I posit that you've never programmed before, for any platform, ever. Either that or you are a fucking retard who has failed so badly as trying to hack together code that you're only possible saving grace is to write an inflammatory article and try to eek a living out of click ads.

It's actually kind of funny watching retards like this rant. They have no clue what they're talking about yet they are so sure that the problem must be something other than themselves. Fuckwits like this make it much easier for me to find work cleaning up after their garbage, and make a small fortune doing so.

Re:MS should follow Apple?

[Concerned Onlooker]

"He trumpets Apple for overhauling their platform and releasing a rapid succession of new OSes in order to advance the platform, which retaining absolutely no backwards compatibility."

This is a false statement. Or at best misleading. Yes, Apple did finally ditch OS 9 after many years of offering backwards compatibility. Their succession of OSes, or OS X as some of us call it, are all backward compatible. Unless I'm mistaking your definition of backward compatible.

Apple's decision to make a break with their old OS was a good one, and I'm sure just about anyone would agree with that. I liken it to when the camera manufacturer Canon abandoned their old twist-lock lens mounts in favor of the electro-mechanical mount. That allowed them to develop the best autofocus lenses on the market and to finally overtake Nikon in a big way, whom they'd been playing second fiddle to since forever.

Re:As a dev who makes his living writing for .Net.

[glassware]

I want to second this concept. Back in 1998, when I started a company of my own, I insisted that my partners and I purchase a $500 MSDN license so we could do current development on Microsoft platforms.

In 2004, when I joined a company that was well funded by venture capitalists, they required that I cost-justify the $2000 MSDN license cost. I argued that we were developing consumer applications and we needed the license.

In 2007, I can no longer justify $3500ish for MSDN. It just doesn't work anymore. They offer reduced versions of MSDN, each of which eliminates all the reasons why a person would subscribe to MSDN. They offer only 10 application installs for your $3500. They offer only a few OS installs. After you've installed a few, they stop letting you install more development copies and insist that you call them for more authorization. It just doesn't work anymore, and I'm sad because I really liked being able to develop code without artificial roadblocks in my path.

Author is misleading at best....

[TheNetAvenger]

No concept of what .NET really is, misleading users.

No mention or acknowledgement of WPF/WCF or the new APIs that are and 'set' to replace Win32/Win64

Completely misleads users about API concepts and features of OS X compared to Windows, for example XAML/XPS concepts compared to Display Postscript is a massive difference in display technologies that are part of the new Windows API sets, that Carbon or Cocoa cannot provide to developers. (Go to Channel 10 and watch videos on why XAML/XPS was created and how it trumps every aspect of other display/print technologies. - Let alone how it is an integrated aspect of the video API system in Vista, making programming freaky simple for advanced features and new UI platforms like 3D.)

The author then jumps into UI consistency with dialog wording, and doesn't mention OS Xs lack of keyboard support, consistency of delete/backspace or 100 other things more important than dialog wording which is also NOT PART of Win32 inherently.

Author doesn't realize Microsoft and IBM wrote most of the GUI and UI guidelines that OS X even uses today.

Office 2007 is a new direction in GUI paradigms, and is WELL accepted in the business world. Not something to make fun of when OS X is still using old MENU (textual word lists) concepts. Menus were a hack to make features available in a GUI context, but are a draw back to non-graphical UIs. Vista and Office 2007 moving away from word lists (MENUS) is the right direction, too bad Apple isn't innovating on UI and just keeps throwing the same UI slop at users and telling them it is good. (And don't even mention multi-touch UI, go watch the freaking TED conferences Apple ripped the ideas off from several years ago, let alone the MS multi-touch work that also preceded the TED conference. MS Research has and is doing more with UI than any other think tank in the world.)

Author also totally ignores Adobe not providing any 64bit support for OS X because Apple dropped the ball on Carbon x64bit support that has been promised forever from Apple. In contrast 64bit development on Windows in both Win32/Win64 and .NET/WPF is easy, transparent and has clear and easy paths for migration. (Let alone OS X is still a hybrid 64bit OS, using 32bit code throughout the OS, unlike Vista x64)

So for 'real developers' like Adobe (OS X) is a failure, and has failed paths. Which means if you want a 64bit version of Adobe products, you will have to move to Windows for the peformance and benefits. Oh, how brilliant Apple and OS X is...

This brings up the horrid Carbon/Cocoa platforms and migration paths, and even then not even touching on the development tool constrast between the two platforms.

I challenge Mr. Bright to a real debate on the topics covered, maybe he can try to justify some of his misleading and outrageous claims.

Re:Author is misleading at best....

[tclgeek]

You are correct and the parent is mistaken. Menus serve a very important function which is to allow the user to easily browse all the available functionality available to them. Note that menus are generally not the fastest way to perform a function, but as you said, it is the most unambiguous.

Re:Author is misleading at best....

[MechaBlue]

MS invents an idea, Apple profits from it. That demonstrates the difference between invention and innovation. MS spends way more than Apple on R&D and, somehow, Apple is able to seem more cutting edge and profits as a result. Marketing plays a role, of course, but it's not the whole story.

From my experience, .NET feels like a cheap knock off of Java. There are nifty things but API issues, missing features, etc. detract from the experience. Overall, I can sum up my feelings onC# and .NET as "I started with Java 8 years ago. Why do I want to learn it all over again?"

Mac OS X may not be the most pragmatic route but it is more fun than Windows. If I'm going to study a programming toolset on my own time, it needs to be fun. That's why OS X will draw more enthusiastic programmers than Windows. The only semi-exciting thing .NET has going for it is XNA.

Re:Author is misleading at best....

[dhavleak]

what is the problem with menus? ... unambiguous communication of options ... Menu's have their purpose and their limitations. As apps get more functionality, the choice-lists get longer and longer, you get more nesting of menus, sub-menus, sub-sub-menus, until finding stuff becomes hard. Cases in point: Photoshop (and cousins), and MS Office (and cousins). Another side-effect: most feature requests MS gets for Office, are for things that already exist - users just don't know they're there.

The ribbon is not a new paradigm but it is a significant evolution. Menus do exist in Office 2k7 but the ribbon works so well, you rarely use the menus (in my case, practically never), even for advanced functionality.

The grouping of functions is very obvious - your eye can pick out options faster. Icon sizes are dramatically larger (when necessary), and are designed to form a visual association with the picture and the action (this is always the idea - but it's embraced completely in the ribbon). Scrolling takes you back/forward through different sections of the ribbon -- so the entire UI is accessible without any clicks/sub-menus, and without taking over the whole screen.

Template icons are dynamic, making it easier to associate a choice with the effect it has on your doc. Depending on your template, the icons change to reflect the styles - so no guessing what a particular style looks like (this might sound confusing - but when you use it, it even passes the grandma test). When you hover over one of the styles, the active line in the doc changes to that style (just a preview - the change doesn't take effect until you click) - so its super-simple to see what different styles will look like by just moving your mouse over a few icons.

The idea is to enhance the visual association as much as possible, and to make the options as accessible as possible. Not so different from normal menu design, but (at least) I still experienced a very significant bump in efficiency, and reduction in menu item clicks and searching.

Re:Author is misleading at best....

[Homburg]

"Vista and Office 2007 moving away from word lists (MENUS) is the right direction."

Quite right. The last thing I want in my word processor is words.

Re:Author is misleading at best....

[TheNetAvenger]

Define "throughout the OS". In Leopard, almost all the libraries come in 32-bit and 64-bit forms; it's just the kernel and a lot of executables that come with the OS that are 32-bit only. 64-bit userland code can talk to 32-bit kernel code just fine.


Leopard's idea of 64bit is providing a 64bit version of Cocoa for applicaiton development. Like Tiger there are a few OS level 64bit pieces for addressing more RAM than 32bit, but the majority of the OS kernel itself is 32bit still. (Carbon was supposed to be moved to 64bit as well, but Apple gave up on it.)

So this is why you only get 32bit drivers with OS X, because that is what the OS is. Apple tries to use this as a marketing tool, from their own web site:

"Leopard is the first universal operating system to seamlessly support both 64-bit and 32-bit applications. There's no need to upgrade drivers, and you can even stick with your existing printers, storage devices, and PCI Express cards." http://www.apple.com/macpro/technology/leopard.html

However, because you there are areas where 64bits at the OS level DOES help that Apple is not using, it a hybrid at best and a 32bit OS with 64bit application support and a few kernel level *nix 64bit flags to be more generic.

For example, one area where Apple would benefit from full 64bits would be in Video Drivers, as shoving data to GPUs in 64bit chunks is much more efficient and faster. (There are other areas, that can be seen if you contrast Vista x64 vs Vista x32, as Vistax64 with 2GB of RAM runs even 32bit applications 5-15% faster, especially gaming applications because of the 64bit driver support.)

Unlike a lot of fanbois would like people to believe 64bit is not slower, even if it is allocating or shoving twice the bits around, as the other benefits of the 64bit CPUs of today more than make up for it, just like the process scheduler in the 386 was worth the 16-32bit jump, in addition to additional registers less internal tracking and paging, etc.

Re:Author is misleading at best....

[Guy Harris]

Leopard's idea of 64bit is providing a 64bit version of Cocoa for applicaiton development.

Leopard's idea of 64-bit is providing 64-bit versions of most frameworks and libraries for application development. The one big exception is Carbon, and, yes, that's a big exception, but it's not as if there's not much you can do in 64-bit mode (as was the case in Tiger).

Like Tiger there are a few OS level 64bit pieces for addressing more RAM than 32bit, but the majority of the OS kernel itself is 32bit still.

Yes, as I said in the posting to which you're replying. I also said, however, "64-bit userland code can talk to 32-bit kernel code just fine." There might be performance boosts from running in 64-bit mode in the kernel, but it's not as if you'd gain much in the way of application functionality, as opposed to application performance, from having a 64-bit kernel.

Re:Author is misleading at best....

[TheNetAvenger]

What is .NET? Every time I've looked it up I've gotten a different answer

I completely agree that Microsoft and the .NET naming period was insane and poor marketing. .NET is several things, from a managed framework to extended technology ideas, to even API sets.

Generally it is an application framework that is rich, managed (apps easier to write and won't suck memory as it cleans itself up), and programming agnostic. So if you write in C, C#, Pascal, VB, Python, even ASP or PHP, you can write .NET based applications that can be stand alone programs, web applications, HTML pre-processors, Games, virtually anything, even Silverlight is a variant of .NET technology. It is also highly extensive, as the Vista APIs were added to .NET seamlessly without even changing the core components of the .NET framework. This gave .NET the ability to do XAML, 3D, etc overnight.

It is kind of complex, so this is a very generic description, and hope it helps a bit. .NET has some advanced stuff no one else is doing, and there are also some things that suck like all platform/frameworks.

Windows programming

[buss_error]

Back before my current gig, I was a software developer for companies that hired me to do their work and for several packages I wrote for my own profit. This story comes from the programs I developed for my own profit.

Because the software I wrote was also licensed for source code if the user wanted it, I picked Visual Basic as the platform to use. I wanted to use Visual C, but you could more easly find programmers that could get by in Visual Basic than VC. I should have picked VC rather than VB for a lot of reasons, the main one being that if you had experience in VC, you were at least likely not to be a total idiot. Not so with VB. I found that VB programmers were idiots at the approximate rate of 7:10, while VC programmers were likely to be idiots at an estimated 1:10 ratio... which isn't to say that all VB programmers were idiots, only that they were cheaper labor, and therefore less likely to have a solid background in programming logic.

That said, we'll focus only on my own development problems, just so we are dealing with only one (possible) idiot... me. I started out with VB 2.x. The upgrade to 3.x went fine, with very few problems. When 4.0 came out, I found I had to rewrite about 20% of my code. Sure, there were conversion programs, but they didn't quite fit in with exactly what I wanted the program to do. It'd get it about 90% right, but then I'd have to slog through the rest of the automated code to correct that last 10%. It was faster to discard that code and re-write it.

Then 5.x came out. Only about 50% of my code still worked. And again, the automated process to "ease" transisition left something to be desired. When Visual Studio 6.0 came out, it was a nightmare. only 20% of the code ported. At that point, I sent the 5.x code out to all the people that bought the program (with source or not), and told them that the code was now moribund, I would not be maintaining it, and that I was releaseing the source code to the public domain (5 floppies included). As I recall, that was about 1998-1999 or so.

As late as March 2008, I've been contacted about the code. Of course, it's morphed far past anything I'd written, and I could only help with the general business case logic involved, not the actual code. But having to deal once again with Microsoft development tools, one would have to offer me far, far more money than it would be worth. No, I'm done with Microsoft "development" games. I'm done with school yard bullies trying to take my lunch money. I'm done, PERIOD, with closed source, whenever I have a choice.

Re:Windows programming

[Gazzonyx]

Just wondering... did your program interface a database at all? You should see the regressions with DAO/ADO/ODBC/JET/Etc. Now all you've got is ADO.NET, and from what I've seen the calls aren't the same as the calls for the pre-.net APIs.

The appalling GUI inconsistency

[Coryoth]

One of the nice things from this article was actually this nice screenshot of a selection of current versions of MS software running on Vista. The thing to notice is that not a single one of those applications has a GUI the same as any of the others. There are different toolkits, completely different look and feel, some have menus, some don't; it's a horrible, horrible mess. And yet despite that, we still get people complaining about GNOME vs. KDE and the clash of different toolkits and how that's what is holding Linux back. You can run GNOME and KDE apps side by side and, while they'll have differences, they'll sit together far more elegantly than the mishmash that is Windows. I think I'll have bookmark that screenshot so I can bring it up the next time a Windows fanboy starts decrying the excessive number of GUI toolkits on Linux.

Re:The appalling GUI inconsistency

[Nazlfrag]

Yeah, and they have a good point, while not perfect Apple makes an excellent GUI and actively promotes sane and pretty interfaces to third parties, and practices what it preaches. Sometimes they take their philosophy to the point of absurdity, like the single button fetish they still desperately cling to, but overall it's worked a charm.

A similar GUI could happen on linux, perhaps it hasn't happened due to the roll-your-own nature or independent streak among hackers, perhaps the abundant CLI use still prevalent among the developers, but I'd guess it's far more likely the fact that 99% of us geeks have terrible aesthetics.

not sure they have a choice

[abes]

I'm not big on the M$ love. I'm a mac/linux proponent. However, I think that M$'s current problem with a really horrible API (I'm saying this having programmed for win32, GTK, QT, WX, and Cocoa) isn't an easy to solve problem.

They could pull an Apple, and completely redo their windowing system. Apple benefited from using NeXT's system, which was well thought out, uses a language well suited to windowing systems (objective-c), and could be altered based on previous user experience.

However, in doing so they would lose all compatibility they current have. Keeping compatibility, even if it creates a developer's nightmare, is in the end what keeps them on top of the market.

That is not to say it's not impossible for them to do so. Apple did provide a virtual machine to run old OS9 software with the first releases of OS X. However, since both Mac and Linux machines also have the same options (currently running Parallels on my machine), it would still take the clear advantage M$ has in the market away.

It's not clear whether their bad API spells the eventual doom of the company. The more pragmatic developers will still value making products that more people can use over writing nice looking code. Additionally, wrapper libraries, such as WxWidgets or Qt can help hide much of the ugliness.

What part of "Undocumented" is hard to understand?

[WED Fan]

The problem is that many major legacy applications depend on undocumented behavior because they make sloppy use of the Windows API (e.g. by assuming that a particular function will not segfault when passed a bad argument). For those to keep working, newer revisions of the API implementation must have the same undocumented behavior, which causes a maintenance nightmare.

So, you problem is that programmers make use of undocumented API calls. While "undocumented" does not always equal "unsupported", using them is just plain stupid. Whether it is Windows, Linux, MS-DOS, DR-DOS, OSux using the system in an undocumented/unsupported way is well, U N S U P P O R T E D. Don't blame the OS or the those that coded it, blame those that wrote against the API in an unsupported way.

RTFA turns out to be a effort in slogging through another of the author's attempts to explain why anyone on Windows is just benighted. He blames HIS short comings on the OS.

Re:What part of "Undocumented" is hard to understa

[gfxguy]

Because programmers are, you know, just leaving the Windows platform in droves! Because it's annoying to develop on!

(sarcasm off)

Windows has always been annoying to develop on; when you've got the lions share of the market, and the customers want "windows," that where most programmers are, annoying or not.

So maybe they "dropped the ball," I say they never had the ball to drop, and they don't give a crap because if you want to make money, you work on Windows.

Now... how is this different than last year, or the year before, or ten years ago?

Re:So Microsoft has jumped the shark, then

[IdeaMan]

Same as when IBM jumped the shark...

When they tried to force a product down the consumers throat that there was no perceived need for, which could be replaced by products that were not IP locked.

For you younguns IBM's was called Microchannel.

Take a look at Windows' past to understand, people

[Opportunist]

"When you use undocumented API calls you're in the wrong".

So far, so right. In theory.

In practice, though, let's look back into the world of Windows at its beginning. We're in the middle of the 90s, Win95 is fresh out the door and you're supposed to write for it... erh ... well, if you can. There are a few API calls documented which will allow you to write a few cute Windows programs but they will invariably be unable to compete with programs developed by MS. Why? Because you have no access to API calls. API functions that make your programs faster, or easier to use, or simply allow you to do something at all. Especially graphics and network code was notorious for being impossible to implement sensibly without resorting to functions that were available only when you dug through disassembled DLLs and guessed what was expected from you.

So programmers faced the choice: Either write programs that cannot compete with programs written by MS (or companies that somehow got a hold of that information), or use calls where a few parameters are described as "set to NULL" or "unknown function".

MS has a history of releasing information about formats or calling parameters at trickling speed, at best. Anyone who ever wanted to get a hold on, say, the Office container format can vouch for that. It's not really a lot better for API documentation. Usually, you get it for a lot of money, if you are deemed "worthy" first of all.

Programmers don't let a company do that to them, though. They start figuring things out, reverse libraries and even existing program code to get the information they need. Of course, this results in the occasional mistake.

Jump into the present. The companies that created software back then don't exist anymore, blown up in the dot.com bubble. Their software, though, still exists. And companies now rely on this software. So MS has to maintain those "buggy" APIs, else companies running buggy software will refuse to upgrade.

Who is to blame? Basically, whoever decided that it's a smart idea to withhold the API documentation.

Author has narrow vision

[overbaud]

"If a company has some business-critical custom application written in Visual Basic 6, that company isn't going to roll out Linux to its desktops; it's trapped on Windows."

Actually they could host it within citrix or similiar and rollout to the desktops. They are not locked into windows on the desktop.

"They're too demanding anyway. They're the ones who care about their tools and get upset when an API is badly designed. They're the ones who notice the inconsistencies and omissions and gripe about them."

Or maybe they accept that there is no such thing as the perfect piece of software. Maybe they understand that the software in question a lot of the time is there to support business and sometimes business requirements out weigh technical 'perfection'. I accept it as a fact of life... like taxes blogging about it won't change a thing.

"For example, there's a function called OpenFile. OpenFile was a Win16 function. It opens files, obviously enough. In Win32 it was deprecated--kept in, to allow 16-bit apps to be ported to Win32 more easily, but deprecated all the same."

And as a good developer you won't use it. Maybe a bad developer will but a bad developer will write bad code regardless of how many things you put in place to stop them. A developer should be able to use his discretion as to using this or not, taking into account his particular circumstances. Maybe it should be used for a quick dirty port while version '2.0' is under development. 'Get it in, get it running, minimise the business impact and we'll address these issues next major release' is something that commonly gets thrown around in enterprise by management... you know they guys that are paying for your services.

But if you use the same API in 64-bit Windows, it still gives you the pair of numbers, rather than just a nice simple 64-bit number. While this made some kind of sense on 32-bit Windows, it makes no sense at all on 64-bit Windows, since 64-bit Windows can, by definition, use 64-bit numbers.

This and other points in the article are such small non issues and are just gripes. Would it be nice to get 1x64 number? Yes. Does it make no sense? No. Looking deeper at things like reducing time to port 32bit to 64bit and associated costs in developer time/money it makes sense. I can happily live with it.

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.

Again... you can't stop bad programmers (a lot being 3rd parties) from making dumb mistakes... but you can try and reduce the impact. You can bet there are those purists just like the article author inside MS that hate this as well. But in the interest of having this work a decision was made, and i suspect not for MS's benefit. Again just live with it.

For example, dialog boxes in Windows have traditionally been poorly designed, because their buttons are given generic labels like "Yes" and "No," or "OK" and "Cancel,"

Microsoft have been going on about this for ages since 2001 actually. http://msdn.microsoft.com/en-us/library/ms997506.aspx

If you take the ranting and raving out of the article it has very little of value. If Mac or *nix had greater market share then we would see more bad software and API's in those environments as well. As it is some of the open source code I have seen is terrible. There is no way to prevent these issues economically, good programmers just accept them, code around them and move forward.

Re:use the same techniques you learned 15 years ag

[644bd346996]

15 years ago, object oriented programming was still catching on, and the Pentium was brand-new. Computers were slow, people had about as much RAM as modern CPUs have cache. The Windows operating systems of the time were just starting to support 32-bit features. Pre-emptive multitasking was still 2 years away.

When it comes to using the extra power of modern hardware, it is easy to say "I want it to make everything 10 times faster". On the other hand, you could use that power to run a python interpreter, and make things 10 times easier for the programmer. Both are perfectly good uses of the more advanced hardware. But the latter is where you'll see the really innovative apps showing up. That's what Microsoft is missing out on when their platform still doesn't let you ignore the nitty-gritty details that you couldn't afford to ignore 15 years ago.

BIOS was only a small part of the picture

[EmbeddedJanitor]

In DOS days, there were often 3 ways of doing things. For example, take writing to the screen:
You could call the BIOS interrupt function.
You could call the MSDOS Interrupt function.
You could detect the hardware and write directly to the hardware address.

Both the BIOS and DOS mechanisms were slow and broken and did not follow the conventions of any programming language. For example terminating strings with the $ symbol, FFS.

All commercial programs (and most hobbiest ones) wrote directly to hardware for speed.

DOS was not really an OS at all. It did very rudimentary memory management. About the only thing you'd really use DOS for was disk access and application launching, otherwise DOS applications were basically "bare metal" applications that managed just about everything (screen, keyboard, serial ports, mouse,...) internally.

Re:What part of "Undocumented" is hard to understa

[rs79]

" They don't give a crap because if you want to make money, you work on Windows"

I learned to live without money instead. It was less painfull.

Re:As a dev who makes his living writing for .Net.

[GaryOlson]

Try VMware Worstation (or ESX if you have money to burn). Install OS in VM, register with MSDN. Snapshot; backup VM to media. Develop, restore snapshot.
And, you saved yourself the hassle of reinstalling the OS again.
And, you are assured of having the exact same development base OS every time.

Re:Inconsistencies

[icydog]

The author is not saying the third type of developer is unimportant; rather, he is saying the opposite. He downplays their importance in a tongue-in-cheek manner, mocking Microsoft. If the author were to categorize himself as one of the three types of developers, he would probably associate with the third type.

Re:Many languages, but really one...

[Anonymous Coward]

You have a lot of things wrong about .NET.

C++ is not a subset. You can take any C++ project that exists, flip a compiler flag, and it will be compiled for .NET. There are no limitations. The runtime permits the seamless integration of IL and native code. What can be compiled to IL will be compiled to IL and everything else will be native. Microsoft proved this back in 2003 when they took the public source for the Quake II engine and recompiled it in Managed C++, then added a .NET plugin model and a C# radar.

The CLR is fully capable of working with dynamic languages. There are quite a few that are already out and work fine. The DLR doesn't add anything new to the underlying runtime to better support dynamic languages. What the DLR strives to provide is a consistent pluggable API for hosting dynamic languages. Currently, if you wanted to host IronPython, IronRuby, Boo, PowerShell, JScript, etc., you would have to use a language specific host and bindings. The DLR will make it more predictable, like how CodeDom currently allows you to work with the various static languages by using the same object model.

The power is in the libraries, but the libraries are consumable by any CLI-compatible language, or any native language hosting the runtime.

The .NET runtime, from day one, was designed to be a very generic system. The one mistake was that generics was not in v1.0 and that led to a split between some portions of the runtime. That was the only time the underlying VM had to change. Every feature since has been nothing more than a library, or compiler candy. An example is that .NET 1.0 CIL had a tailcall opcode. Only functional languages that use recursion for looping would require such an opcode.

Re:You have got to be insane or Fanboi!

[TheNetAvenger]

OK, how may Microsoft applications use WPF/WCF ?

Several... Should we start with things like Silverlight, or go into the whole WDDM model of Vista that uses XAML from the composer to printing? You are trying to confuse .NET 3.0 applicaitons here, and you are off track.

Mac OS X's low level graphics APIs are called Quartz and OpenGL. Quartz is effectively Display PDF. Display Postscript sadly died in Apple's hands.

Ok, OpenGL is not Apple's any more than it is Microsoft's.

Display PDF is equivalent to GDI+ from Windows 2000, go look it up. Additionally, Apple's implementation of Display PDF even lacks the full specification, which is sadly dated anyway.

In terms of Alpha, transparency, layering, etc, Display PDF ends up rendering to a bitmap on complex drawings instead of being able to natively draw them using the language of Display PDF.

Go to Channel10, and watch the video of WHY XAML/XPS was developed, how it was created to specifically overcome the limitations and conceptual drawing limitations of Display PDF and Full PDF. (This is why Printing Press companies are starting to use XPS, because it can reproduce images at higher quality without having to full rasterize the image as many do now. i.e. A lot of PDF printing is rasterized and is nothing but a container for the bitmap because PDF cannot do the advanced drawing.)

Take a look at Core Image, Core Animation, and Quartz Composer, and even venerable Quicktime to see where MS got the ideas they imitated badly. Then look into Interface Builder nib files which have provided more than XAML capabilities (on the desk top) since October 1988. It took MS 20 years to copy that one.


First Apple's 'Core' crap is nothing like the new API features or architectual changes in Vista. Core is more about using SSE from the CPU and offers very little new features.

You also need to get out of 'fanboi' mode and check your timelines here a bit. You are trying to compare XML document structures with XAML that uses a XML structure. However, how XAML is stored is irrelevant, it is how it processes graphics, allows for advanced drawing capabilities, internal binding, animation properties, and 3D drawing - in addition to providing a new UI paradigm of control contexts. (Again you really don't know what you are talking about here.)

When you can take a text editor and write 10 lines of XML and create a 3D scene with a movie and UI controls on OS X get back to me, until then, Microsoft has set the stage for the next generation of development, especially when it comes to graphic designers becoming part of the design process.

Did you notice that Windows 95 GUI was a rip-off of the NeXTstep GUI but copied poorly. You have your history wrong.


Actually it wasn't, although many GUIs from this time frame shared a lot of ideas. Win95 was a small subset of Microsoft's development of the OS/2 Object based UI that goes back to 1987/1988.

But when I was talking about IBM and Microsoft writing UI guidelines, I was specifically talking about UI specifications and standardized UI guidelines that defined an era of UI for OSes. Go back and look at the UI guideline papers from OS/2 written by IBM and Microsoft in the 80s, and how even Windows stuck to a version of Common UI guidelines. Additionally, as Apple struggled to implement keyboard support, they took from these Common UI guildelines as well.

You are either too young to know this stuff or just too much of a Mac OMG person to even consider Apple didn't invent everything.

I'll ignore the rest of the nonsense. Suffice it to say that OS X runs 32 bit and 64 bit applications side by side. How does that work in 4 bit Windows?

Perfectly, in fact running Vista x64 on this 2005 laptop, and all my 32bit applications run fine, especially my games that get a punch up in performance because Vista has real x64 bit support and REAL 64bit Video drivers, unlike OS X.

Do you really think Vista x64 bit can't run 32bit applications? Are you that out of touch? Holy crap...

Half-baked article

[flnca]

I can only say the featured article appears half-baked to me, and it's comical how Apple users always bring up GUI design issues, as if that was the most important thing in the world.

I tried Apple's XCode IDE last year, and I was put off by it's total lack of good UI design. XCode's editor cannot be customized, has a hair-line thin text cursor that is barely visible and a weird keyboard layout that originated somewhere in the 80ies (on MacOS and Amiga systems), that is totally uncomfortable to use nowadays. No mention of this in the article.

Also, the article mentions minor aspects of perceived Win32 and .NET flaws, when in fact the flaws are much bigger, and the short examples only give the impression that he has looked at them briefly at best. No mention of the GetFileSizeEx() function, for instance. The old GetFileSize() API was for NT 4 and Windows 95 and previous OSes (note how the older OSes have already been dropped from the platform compatibility list). GetFileSizeEx() API was new for Windows 2000, which is already over 8 years old.

Also, as has already been mentioned here, the article omits WPF, which is a fairly important development by Microsoft. It enables programmers to create 3D applications in XML! I tried it a number of times and it seems pretty good to me.

But the core statements about .NET and Win32 in that article are true. The .NET framework has (or rather, had, because we're talking .NET Framework 3.5 now) some very weak concepts. Also, the documentation team is far behind with the documentation; there's a lot to be left desired in that area. The Win32 API is much better documented still. If you develop your own controls, you might run into problems with .NET, because native timers and carets are not directly supported, for instance (Win32 API calls are required for that).

I've been developing mostly for Windows in the past 13 years, with the occasional UN*X and OS/2 thrown in, and I still find that all of them lack some of the flexibility and power of an AmigaOS, which I used and programmed on from 1986 to 2001. THAT would be the ideal development platform, because it allows unrestricted programming; sadly, Commodore folded in 1994, and not much good happened since then. GUI and development guidelines were followed by Amiga programmers voluntarily, out of interoperability concerns. All major (and many minor) applications had an ARexx scripting interface, for instance. GUI guidelines were often followed also, because the guideline manual (or chapter, in the older RKMs) was thin and easy to read. BTW, the Tool Info feature of the Workbench is still unmatched today. A user could easily configure their applications to their desires, or even configure the entire user experience to their liking, booting up Commodities (which were similar to Windows Services, except they supported user interfaces) as needed, that even sometimes changed how individual controls behaved. Tools like MagicMenu changed the entire menu system for all applications, and so on. Virtual memory and memory protection could be added by the user, and so on. There's much that needs to be said about the Amiga platform, that made it ideal for developers. For instance, the non-copying message system that was easily used to communicate between threads, making multithreaded applications easy, and that also served as an IPC mechanism.

I can tell you: On all so-called "modern platforms", everything is much, much more complicated than it needs to be. OS implementors only have to look at the things that have already existed, instead of reinventing the triangle-shaped wheel over and over. ;-)

Right, so users are held hostage...

[Theatetus]

...by the crapware "enterprise" software industry that has succeeded mostly in just taking money from companies and giving them products that badly replicate where Lotus was 20 years ago. By itself, that would just be those companies' problems, but in the end other users and developers get held hostage by that same crapware because new versions of Windows have to keep supporting it.

Re:As a dev who makes his living writing for .Net.

[Silver Gryphon]

I agree, $3500 is insane for MSDN (I cap its value at $2,000), and I think the Premium Uber MSDN with Team System costs like $11,000. And the Express editions of Studio just don't cut it for a lot of people; no source control or unit testing, etc. Still, there's a middle ground:

Microsoft Certified Partners are entitled to a certain number of MSDN subscriptions and/or Visual Studio copies, depending on their partner level. Even as just a Registered Partner (anyone can get this simply by signing up for free), there's something called an Action Pack, I think, that includes enough licenses to get a small business running - server OS, SQL Server, etc. The Action Pack costs either $200 or $400, and I'm too lazy to verify that but here's the link if you're still interested:

http://partner.microsoft.com/

Getting Certified Partner status isn't a big hurdle; get some customer references and prove certain technologies are within your scope and you're well on your way.

Re:What part of "Undocumented" is hard to understa

[Foofoobar]

If you want to make money you work in Windows?? LOL! Hate to tell you this pal but I've been a web developer since I was at Amazon in 95 and I have never once stepped foot onto a Microsoft platform. And I have 3-4 times the output and twice the pay. :)

Re:What part of "Undocumented" is hard to understa

[gmack]

To make it more amusing those third party APIs slog through the win32 API hell so you don't have to.

I think that's why Microsoft is afraid of breaking the old APIs. Once you have to go through the pain of porting to a new API why not just go cross platform?

Re:What part of "Undocumented" is hard to understa

[HalAtWork]

Programmers were forced to take advantage of undocumented API calls in order to compete with the applications MS produced which used those. Also, a lot of API calls were not documented well enough such that the behavior was not questioned by the programmer and so the broken behavior was relied upon to make the application work.

Re:As a dev who makes his living writing for .Net.

[LordMyren]

Sure dude whatever.

First off, Microsoft never claimed .net was portable, just the CLR. And, for the record, the first reference implementation of the CLR -- Rotor -- was cross platform to BSD. Mono came along of its own volition and works independently of MS, and MS has never made any claims on their behalf. Mono has had very good 2.0 compliance for going on three now. Library support is excellent but not perfect, which makes sense given that the .Net library is a massive all encompassing + the kitchen sink beast and there will always be pieces no one has ported. That wont prevent 99.99% of apps from working.

Rather than FUD'ing around, I suggest downloading the Moma tool and which will check whether an application is compatible with Mono.

Mono supported the DLR by day five after release or something. C# 3.0 support is on the way, and, to my understanding, most of the pending work is still in LINQ re-implementation world. Given that it was released November 19, 2007 and that it requires implementing a huge AST, I wouldnt complain.

At its base, the CLR is a wonderful VM to implement and write to. The libraries built on CLR are give or take. For the most part, I prefer the non MS ones anyways.

Qt (& GNOME)

[scorp1us]

As someone who had to learn C++/CLI and writes code to allow legacy code to interop with C# at work, I have this to say.

If you are going to learn a new platform for a "modern" app or OS, then let it be one that allows you to target more than one platform. Seriously. Lets take a look at .NET:
- Everything in the library is new.
- You can only officially target one platform. (Mono not withstanding)
- You have to learn a new language to use it effectively.

Now look at Qt:
- New library
- Build onto same C++ compiler you've always used
- No messy COM, COM wrappers needed for introspection
- You can target any platform with a modern C++ compiler (VS6 and higher on win32, gcc on all platforms)
- Ground up C++, clean consistent API.
- Active development with binary compatibility within major releases.
- Python, ECMA scripting, (some C# support too!)
- Java version
- Meta-object compiler adds introspection. (no need to deal with COM)
- ActiveX interop in the commercial version (You can use Qt widgets in Winforms and vice-versa)

I don't know as much about GNOME, but it shares a lot with Qt, so should not be excluded.

About the only thing you miss out on is the automatic garbage collector. Qt emulates this to some degree by allowing every QObject to have a parent. Then the only thing missing is the ability to defragment memory in the heap. I've only heard about this being caused by lots of small memory allocations, but Qt block allocates so this isn't a problem. Also, many types are implicitly shared, meaning they are more like handles to the objects, meaning that 1) they can cross thread boundaries 2) they are references until they are modified.

All in all I see you only lose out on the memory defrag. But you don't need to learn C++/CLI or C#. (My opinion of C# is that if you're going to go that far, you might as well take the goals of the language to completion, in which case you end up with Python, oh yeah, there is a Python wrapper for Qt too)

The term you look for is "enabler"

[SuperKendall]

I too have "been there, done that" on a lot of platforms.

The term you are looking for is "enabler" - Microsoft is an Enabler for other applications to engage in bad practices, for users to engage in bad security.

As you say it makes a lot of people happy now, but look what else it has given us - lots of decrepit systems, and hundreds of thousands of zombies that make our lives miserable in other ways.

Sometimes even a business can't just be about making people happy, it has to be about moving the market as a whole to dry land when they see the flood coming.

Just like the Spiderman quote tells us.

Going where the money is

[SuperKendall]

So maybe they "dropped the ball," I say they never had the ball to drop, and they don't give a crap because if you want to make money, you work on Windows.

If you knew the demographics of the two systems you might think twice before saying that.

It's not like a cash register is ever going to buy anything I write, and it's not like a lot of actual PC users will ever do anything but pirate it.

There are a lot of Mac developers making a good living. And why not, when even though you have a smaller market you have less competition and users more willing to pay you.

Re:Same techniques 15 years ago? Not just Windows.

[Brandybuck]

Most of the flashy Microsoft tools are there to correct the horrible APIs they have. For example. it's nearly impossible to write MFC code without the Class Wizard. But with Qt all you need is a text editor and compiler. Your *choice* of text editor and compiler. Even Visual Studio.

I don't see it

[golodh]

Where exactly did Microsoft "drop the ball" with developers?

According to the article there are three types of developers: (I) the ones who bang Excel macros and Access databases together with VB (not very many), (II) in-house developers for large companies who program in whatever language is in demand (the vast majority), and (III) craftsmen-programmers who look for clean orthogonal programming tools and also program in their spare time (a few).

The article goes on to argue that Microsoft catered very well for categories (I) and (II), and not at all for category (III.)

Since I believe that the programmers who make stand-alone third-party applications mostly belong to category (II) I absolutely don't see how or why Microsoft supposedly "dropped the ball" for any developers except category (III). The article points to the messy API's of Win32 and the shadows that projects unto the .NET framework. Ok, fair enough, but who cares?

Not the end-users and not the managers. And they're the ones who determine where the money, and hence the bulk of the development effort goes. That means that what end-users actually see and care about, their _applications_ will continue to be in plentiful supply for MS-Windows.

Sorry, but the author will have to do a lot better to convince me that Microsoft shot itself in the foot as regards development effort. It's not the smartest thing that Microsoft could have done to alienate the craftsmen-programmers but I don't see how that puts a dent in their business.

Incredible...

[thesteef]

I really should leave this one alone, but I just can't. This article is so unbelievably biased, it is truly amazing that a site like ars allows a series like these to exist. The person who's written this series has obviously no real programming knowledge on any platform.
Moreover the way he drops in his little falsehoods borders on intent. Each and every paragraph contains one or more blatant falsehoods. Going through all of them would take way to much time.

Apparantly this Peter Bright's tried to build some winforms stuff (and failed) and he's tried to open a file (and failed somehow). These are his two major arguments against the platform.

Let's try to introduce some facts. First of all the winforms library is indeed not multithreaded. This goes for most windowing libraries. Swing is an example that springs to mind but there are many more. Making it totally thread safe would introduce a lot of overhead, making everything much slower than it needs to be. If you need to use additional threads, there are well documented ways to do this. Maybe Pater should try it... Second of all the winforms library is a very very small part of the total api. Just saying there's lot of little other things, without going into any detail is a cheap way of making a bad point. No API is perfect but I would say given the alternatives out there it's easily one of the cleanest and well thought out api's I've used in the last 6 years. Furthermore, it the author could get his head out of his nether regions he might look in to WPF, WCF, C# 3.0 etc etc. All technologies that put .NET lightyears ahead of the competition right now. Writing these little misinformed articles is not going to change that.

This person comes across as a total beginner. You know the type, probably programmed some stuff in c++ and now thinks he's a guru on everything. In reality he's an armchair programmer, writing knee yerk articles because he coulnd't get his file to open. A lot of programmers (myself included) go through a phase like this, most move on and start seeing the bigger picture. I guess some don't and just write articles about it.

I know the average slashdotter probably won't care about an anti-microsoft hit-piece but if you're confident about using linux or mac-osx (both of which I think are perfect alternatives btw) ask yourself, why would you need lies and falsehood's to attack the 'competition'.

I live here.

[kcdoodle]

Hurrah!

Make it buggy and as difficult as possible. That just gives me more work. I can always find a way to make my code work. Even if I have to write some assembly, or a port redirector. Call me a hacker - I don't care, that's a badge of honor.

If it were easy, anybody could do it. Keep it up Microsoft! You will keep me working and making a good wage for years to come. I like doing crossword puzzles too, and making things work on various Windows/Browsers/whatevers is just another puzzle people actually pay me to solve. It is all very cool. Just depends how you look at it.