How Microsoft Dropped the Ball With Developers 814
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.'"
As a dev who makes his living writing for .Net... (Score:5, Interesting)
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
But give them credit where credit is due... (Score:5, Interesting)
"one developer" (Score:5, Interesting)
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:
Re:"one developer" (Score:3, Interesting)
Re:how much MS bashing can you fit in? (Score:5, Interesting)
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.
Glory days are here (Score:5, Interesting)
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:DOS/Windows programming culture (Score:5, Interesting)
Re:how much MS bashing can you fit in? (Score:2, Interesting)
Author is misleading at best.... (Score:4, Interesting)
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
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:how much MS bashing can you fit in? (Score:3, Interesting)
Re:Glory days are here (Score:3, Interesting)
Re:What part of "Undocumented" is hard to understa (Score:5, Interesting)
(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:Author is misleading at best.... (Score:2, Interesting)
BIOS was only a small part of the picture (Score:5, Interesting)
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:Long Answer? (Score:5, Interesting)
Re:Author is misleading at best.... (Score:2, Interesting)
From my experience,
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
Re:Author is misleading at best.... (Score:3, Interesting)
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:how much MS bashing can you fit in? (Score:4, Interesting)
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:DOS/Windows programming culture (Score:3, Interesting)
Right, so users are held hostage... (Score:3, Interesting)
Re:DOS/Windows programming culture (Score:5, Interesting)
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!!!
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.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.
Re:But give them credit where credit is due... (Score:3, Interesting)
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:The appalling GUI inconsistency (Score:3, Interesting)
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.
Re:What part of "Undocumented" is hard to understa (Score:4, Interesting)
Re:Long Answer? (Score:5, Interesting)
Re:Long Answer? (Score:3, Interesting)
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
Re:Long Answer? (Score:5, Interesting)
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
Re:Long Answer? (Score:3, Interesting)
Re:Long Answer? (Score:4, Interesting)
Unless you set Windows to do something other than shut down when you press the power button that is.
Re:Long Answer? (Score:1, Interesting)
If open-source software ever does make deep inroads into the market for casual users, I think it will be very interesting to see those "less-skilled pragmatic developers" learn that they can't rely on the revenue stream from releasing some binary-only application that only works on one platform.
(So many half-assed "business logic" applications have been doing this for years on Windows, it's a huge waste of resources to try and interoperate with any of them, and it's simply due to the fact that so few software purchasers realize the importance of source code.)
When customers expect to be able to get the code for your application, but will pay you to support it with bug-fixes and ports to new platforms, you can't get away with that stuff anymore. I will delight in what happens when we're no longer stuck with crappy applications written by "less-skilled pragmatic developers" because businesses can hire any sharp coder off the street to fix them
Going where the money is (Score:3, Interesting)
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:With those arguements, any platform can suck (Score:3, Interesting)
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:Long Answer? (Score:2, Interesting)
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
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
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
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
Re:use the same techniques you learned 15 years ag (Score:1, Interesting)
15 years ago, I was programming with Turbo Vision/TASM/TP7/TC++. We did clipper, and DBASE IV. Direct hardware access, still mostly in dos (lots were using dos extenders), with computers ranging from 386's to early P1's. Back then (1993), very few people even heard about the internet...
Now, we're doing WPF apps whose interface was made part in a 3D CAD program, part in illustrator, which is talking to server middleware with a n-tier architecture (with a RDBMS back end), over web services, using WCF. Lots of networked systems are involved. We're also doing web apps, and apps for mobile devices. We're often using things like LINQ and OR/M's, code generation tools and what not... And we're moving to parallel processing for a lot of things. Oh, and there is not one win32 API call in sight in our code base.
It's radically different than it used to be. If anything, it's changing TOO FAST, it's very hard to keep up with it all.
Re:Long Answer? (Score:5, Interesting)
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? (Score:3, Interesting)
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? (Score:5, Interesting)
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:
Re:Long Answer? (Score:3, Interesting)
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? (Score:3, Interesting)
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.
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? (Score:5, Interesting)
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
- 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? (Score:5, Interesting)
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? (Score:4, Interesting)
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 [microsoft.com] Nor here: http://msdn.microsoft.com/en-us/library/78dfe2yb.aspx [microsoft.com] 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