Slashdot Mirror
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.'"
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.
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.
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'...
"When you use undocumented API calls you're in the wrong".
... 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 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
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Good, inexpensive web hosting
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.
What is .NET? Every time I've looked it up I've gotten a different answer
.NET naming period was insane and poor marketing. .NET is several things, from a managed framework to extended technology ideas, to even API sets.
.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.
.NET has some advanced stuff no one else is doing, and there are also some things that suck like all platform/frameworks.
I completely agree that Microsoft and the
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
It is kind of complex, so this is a very generic description, and hope it helps a bit.
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.
.NET:
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
- 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)
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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.
Remember kids, it's all fun and games until someone commits wholesale galactic genocide.
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.
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.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
I'm not going to go through your entire to-do list, although I will answer a couple of your questions.
.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.
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.
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