Windows is a Ghetto
brandonbyars.com
brandonbyars.com
Try building an installable desktop software for Windows. That's where real fun begins. It is quite common for teams doing Windows work to dedicate as much as 20% of available manpower to the installer alone (!). I've been coding Windows desktop in C++ since graduation in 98 and has always looked down on web programmers since they had it so easy. But once I got older I realized that all my Windows-fighting instincts and in-memory database of gotchas are nothing to be proud of: most of my career I was boxing against the platform I was working on, while some were having fun building the actual software.
The irony of it is that once upon a time Microsoft was kinda cool. I was a teenager but I still remember those "good&old" days of snobby IBM/Sun/Oracle salespeople with their super-expensive software, hardware, development tools and even documentation (you could sell your car for a full copy of OS/2 SDK). And then there was Microsoft and Borland, giving their tools and docs basically for free.
What does the desktop SDK do badly? How is this handled in linux/mac?
Two days ago I was handed a CD with some fonts on it, and needed to get an overview of them - two lines of commands, right in the shell, took me maybe 20 minutes, to generate a HTML page with a PNG sample of each font.
As you said though, it doesn't really answer my question. I'd genuinely like to know what is poor at API level.
For example, I could easily write a small utility that would display all the fonts on the CD. It would take an hour or so but the API's should let me do that (disclaimer: haven't tried it).
Most thirdparty libraries provide a C-library that can be linked to an application - but it also provides a small tool that implements all functionality. Input values aren't "resources" or instances of this or that object. They are one of: Strings on the commandline, a piped stream or a file. And most often, all are possible. Output is a integer return value (typically just true or false), another stream or another file.
Windows does not have that single, simple API that everything adheres to, so there's no one culture of Windows development. Many of the APIs that exist in the Windows ecosystem, e.g. WMI, that I've been using to script IIS control, is perfectly well equipped to become a "POSIX-killer" - if it would just become pervasive. WMI is next to worthless when I can use it to control IIS, but not some other feature, and I can straight away forget about talking to the Win32 API altogether from Windows Script Host, and even in C#.net it's unnecessarily difficult.
From your answer and krshultz's below I think I see the complaint. While parts of the windows API are written well, they do not have an overreaching unifying framework. Such a framework would make it easier for developers to follow guidelines and pick up new API's.
I think that's a pretty reasonable complaint. I take it for granted that I have to read MSDN carefully for every API I use, but maybe in Linux/Mac I wouldn't have to. Interesting.
Here is a good explanation. I can't say I have dealt with most of it since I haven't done Windows development since pre-.NET, but I am significantly happier now that I don't.
http://arstechnica.com/articles/culture/what-microsoft-could...
http://arstechnica.com/articles/culture/microsoft-learn-from...
Windows has always felt to me like the work of several teams, each in its own area. I never considered this a weakness because that's "just the way it is". However, this thread has helped me see that it could be.
I'll consider taking up some linux programming when I get some free time to get a feel of the difference.
Windows has PowerShell, which is pretty good: http://www.microsoft.com/windowsserver2003/technologies/mana...
It's far more difficult to create RedHat RPM packages and Debian packages and so forth.
But 20% of all manpower? That seems a bit much.
Then there are cases when other applications break your code: Symantec used to install their own version of MFC DLL right into System32. Then there are super-aggressive anti-spyare/anti-virus/anti-whatever packages that are basically hacks breaking all kinds of legit software. Windows encourages this style of development: when an application essentially becomes a collection of COM servers scattered across your hard drive, hooked into your system via complex mesh of registry settings. And there is no way around it: this is what MSDN tells you to do.
Then you'll have users complaining that when they launch your RSS reading software (or whatever you do), they get a popup that says "Windows Installer: configuring Microsoft Office" that disappears after about a minute of "collecting system information". And users will tell you that everything worked great for 2 months but then "computer did something" and this popup started appearing.
And they keep adding more shit on top of existing shit. Now, in addition to COM and MSI and registry you get this "side-by-side execution" bullshit, when you can't even tell which version of a DLL is being loaded and Windows Explorer essentially hides fucking files from you so even locating a misbehaving DLL becomes a debugging session on its own, where you'll need to decode cryptic hidden directory names and extract a manifest from some executable's resources to see which DLL it actually wants. When they rolled that out I felt sick for a while.
And finally, there is no such thing as "Windows API" anymore. XP machine connected to a domain controller/AD is a very different beast than XP home or Win2K. I'm not even mentioning Vista here.
For my last Windows project I went for "xcopy deployment" with one single fat executable statically linked to everything it needed to run with some help from open source libraries, essentially very similarly to how Firefox does it. But this style of development isn't really for "Windows Platform", this way you're targeting a "sane subset" of Windows platform.
Then I decided I wanted to do some complicated stuff, so I spent another 2-3 hours on it.
Worked like a charm.
"I have absolutely no clue what error 0×00001ad59add means, and I am the goddamned system administrator I’m supposed to contact"
It sucked the life out of me.
.NET is the clean-up of windows, I suppose.
Or is this that definition of "Linux" that people love these days, which is "whatever free software operating system distribution I happen to be most annoyed with this week"?
I was doing Win32 development for 5 years and concluded the .NET development is the best way to go (Only if you can convince the marketing guy to include the 20MB runtime installer in the package)
In any event, you'll find Gemstone's kit more than accounts for .NET (and Java, for that matter) in the trade/financial space.
A great piece of MS terminology, apparently the result of inter-developer conflict...
http://blogs.msdn.com/oldnewthing/archive/2003/08/08/54618.a...
I had to write lots of irrational workaround wrapper code for iPlanet and IIS plugins because they are proprietary.
And debugging this code was a big PITA.
With Apache there were no issues because I could always step-into Apache code with GDB.
So, he doesn't know about PowerShell.
Now whether that level is where people want to go-- well, that's hard to say. It's difficult to judge "success" for this sort of a thing. How much usage is because MS is pushing it and how much is because it scratches some itches?
For me, it's slow to start up, and not overly useful for my everyday tasks. Still, most of the demos are impressive and the idea of piping objects around rather than raw text/files seems like an idea with a lot of potential.
Object piping does sound interesting.
I've had a PC running Vista for a while now (it was cheaper than XP and I need Windows for music software) and I couldn't even tell you how to start PowerShell. I don't even know if PowerShell is different from the old Start->Run->cmd. That one looks the same as it ever did.
To be honest, the thought of poking around in PowerShell never even occurred to me because the Windows command line has never been of much use in the past. That's likely part of the problem. The inferiority of the Windows command line is very deeply ingrained in users. Still, even if a user does bother to figure it out it's still very clear that pointing and clicking is heavily favored over typing commands on a Windows system.
As far as I can tell PowerShell seems much more geared for sys admins creating scripts that run automatically than for user interaction. Based on what I've read about PowerShell, I would consider it to be more similar to something like Perl than a bash shell.
Care to explain that some? I've only poked around a little with PowerShell, but it freaking looks like it could do anything. It's modular, extensible, threaded, and has this huge library base.
I'm not defending -- I don't know that much about it except my initial impressions. Just curious as to why you would say that.
As a shell, it's stuck in the same old Windows command line window that command prompt has always been, with all the problems that entails - no real resizing or decent mouse selection/copy and paste and so on.
As a shell, you want terse and concise hacking, it should be optimised for finger friendliness and oneliners that you aren't going to come back to. Powershell is not. It's wordy and verbose, C# style. It makes things complex because it's not easy to find what you're looking for. Object piping might be nice, but not when you have to get all files and pipe them into a get-modified-date thing and pipe the date objects into a date-to-text object instead of ls -...
As a programming language, it's seriously ugly. It could have been VBScript slid towards Python, instead it's C# slid towards Perl. See: http://blogs.msdn.com/powershell/archive/2008/10/18/emit-xml... from the official powershell blog from the main man behind powershell. $Ugh -*!
See also this discussion from November last year: "What's MS thinking with Powershell?" at Arstechnica: http://episteme.arstechnica.com/eve/forums/a/tpc/f/12009443/...