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