6 ms·

Ironically, his writing is mostly about an easy kind of Windows development. Web apps behind IIS? Not that hard, really. Try building an installable desktop so

by lhorn 18y ago

Ironically, his writing is mostly about an easy kind of Windows development. Web apps behind IIS? Not that hard, really. 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.

visitor4rmindia 18y ago
That's an interesting perspective. I'm primarily a windows developer with little exposure to linux/mac and I've always found the windows API simple and pretty intuitive. But I have nothing to compare it with so I'd really like to know more. What does the desktop SDK do badly? How is this handled in linux/mac?
- mseebach 18y ago
  I know it's not completely what you asked, but I'm with the OP - the one thing I missed the most in my one year in Windows-land last year, was the command-line shell. Everything you can do on a Linux machine, you can do in the shell 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.
  - visitor4rmindia 18y ago
    Good example. I don't dispute the fact that the command line makes it easier to do some tasks. I've had cygwin installed for a while now and I use the command line a lot but its power on native linux may be much more. 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).
    - krschultz 18y ago
      The inconsistancy in the API is one of the major complaints. 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-learn-from-apple.ars/3 http://arstechnica.com/articles/culture/what-microsoft-could... http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.ars/1 http://arstechnica.com/articles/culture/microsoft-learn-from...
      - visitor4rmindia 18y ago
        Thanks - the articles are interesting. 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.
    - mseebach 18y ago
      I'd say, it's not so much the API itself, as much is there is just ONE API - POSIX. Files, processes and signals. This it the root of a very simple design philosophy, that much *NIX software adheres to. 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.
jd 18y ago
Building an installer isn't so difficult anymore. NSIS and similar installer builders are really easy to learn and very stable. Windows has many flaws, but the whole install/uninstall system works remarkably well in practice. 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.
- pchristensen 18y ago
  I don't know about the percentage but Carl Franklin said that Visual Studio has over 50 people on the installer team. Granted, that's probably one of the heaviest installs out there.
  - DanielBMarkham 18y ago
    Last install I did for a Windows product took all of 5 minutes. Then I decided I wanted to do some complicated stuff, so I spent another 2-3 hours on it. Worked like a charm.
  - thorax 18y ago
    Do you remember where he said this? I'm looking for the reference but can't find it on his blog. (Thanks in advance.)
    - pchristensen 18y ago
      It was in an episode of .Net Rocks! but I can't remember which one.
- LogicHoleFlaw 18y ago
  I've done some RPM packaging and it's actually pretty straightforward. The LSB hammered out most of the individual differences between distros from an installation standpoint. And once you set it up you get all of the benefits of robust package management.
- lhorn 18y ago
  The problem isn't getting your files in the right place, the problem lies in how inter-connected and "integrated" everything is on Windows. There are many examples: "Internet Settings", for instance, from the control panel, while they seem to be IE's settings, actually affect how some Windows Internet-family API functions behave. Then there is a big hairy mess called COM/ActiveX: you can't parse XML without it, yet there will be computers, be it one out of 100, with broken XML parser COM registration. Same applies to various "shell services" which are essential to desktop integration. 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.

by lhorn 18y ago

visitor4rmindia 18y ago

That's an interesting perspective. I'm primarily a windows developer with little exposure to linux/mac and I've always found the windows API simple and pretty intuitive. But I have nothing to compare it with so I'd really like to know more. What does the desktop SDK do badly? How is this handled in linux/mac?

mseebach 18y ago
I know it's not completely what you asked, but I'm with the OP - the one thing I missed the most in my one year in Windows-land last year, was the command-line shell. Everything you can do on a Linux machine, you can do in the shell 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.
- visitor4rmindia 18y ago
  Good example. I don't dispute the fact that the command line makes it easier to do some tasks. I've had cygwin installed for a while now and I use the command line a lot but its power on native linux may be much more. 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).
  - krschultz 18y ago
    The inconsistancy in the API is one of the major complaints. 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-learn-from-apple.ars/3 http://arstechnica.com/articles/culture/what-microsoft-could... http://arstechnica.com/articles/culture/microsoft-learn-from-apple-II.ars/1 http://arstechnica.com/articles/culture/microsoft-learn-from...
    - visitor4rmindia 18y ago
      Thanks - the articles are interesting. 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.
  - mseebach 18y ago
    I'd say, it's not so much the API itself, as much is there is just ONE API - POSIX. Files, processes and signals. This it the root of a very simple design philosophy, that much *NIX software adheres to. 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.

jd 18y ago

Building an installer isn't so difficult anymore. NSIS and similar installer builders are really easy to learn and very stable. Windows has many flaws, but the whole install/uninstall system works remarkably well in practice. 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.

pchristensen 18y ago
I don't know about the percentage but Carl Franklin said that Visual Studio has over 50 people on the installer team. Granted, that's probably one of the heaviest installs out there.
- DanielBMarkham 18y ago
  Last install I did for a Windows product took all of 5 minutes. Then I decided I wanted to do some complicated stuff, so I spent another 2-3 hours on it. Worked like a charm.
- thorax 18y ago
  Do you remember where he said this? I'm looking for the reference but can't find it on his blog. (Thanks in advance.)
  - pchristensen 18y ago
    It was in an episode of .Net Rocks! but I can't remember which one.
LogicHoleFlaw 18y ago
I've done some RPM packaging and it's actually pretty straightforward. The LSB hammered out most of the individual differences between distros from an installation standpoint. And once you set it up you get all of the benefits of robust package management.
lhorn 18y ago
The problem isn't getting your files in the right place, the problem lies in how inter-connected and "integrated" everything is on Windows. There are many examples: "Internet Settings", for instance, from the control panel, while they seem to be IE's settings, actually affect how some Windows Internet-family API functions behave. Then there is a big hairy mess called COM/ActiveX: you can't parse XML without it, yet there will be computers, be it one out of 100, with broken XML parser COM registration. Same applies to various "shell services" which are essential to desktop integration. 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.