At my current job we deal every now and then with clients that have weird setups. Sometimes they don't even have an IT department, sometimes they do. In both cases, this is terrible: either they don't block anything, or they block too much - way too much.
Recently I've had a discussion with my boss regarding a client that still uses Windows XP SP3. Yes, XP. Our system is essentially web, but one quite specific part requires access to a hardware token for data encryption and signing. We used to this through a Java applet, which makes me wanna vomit, but we eventually gave up due to many reasons, being the main one that we can't deal with Chrome properly anymore. Also, the latest Java update broke the whole thing, so there's that.
Anyway, we need access to such hardware, and therefore we wrote ("we" as in "I did the whole thing") a small application which runs on the client's system to access it. I wrote it in C# for .NET Framework 4.0. It works pretty well, considering the crazy bugs I've been having. I've even tested it on Windows 7, 8.1 and 10! But, yes, someone wanted to run it on Windows XP, and this is an issue - a big issue.
Windows XP has reached the famous "end of support" more than one year ago. This means it won't receive updates anymore and it's considered an obsolete system, just like your Windows 98. This essentially means "shit is old" - too old. Coding for such platform means going backwards in terms of technology and support, and it also makes everything harder to study (APIs, documentations, etc) and debug. It also means that I can't do anything cool with it. It sucks.
So, our test guy connected remotely to the client's computer and started the installation. Everything was fine there, but the application didn't run: the machine didn't have the .NET Framework 4.0. I explained and showed how to install it. This is the first weird thing: that should be an update on Windows XP. It's an optional one (I've checked on a VM), but I thought users installed optional updates. Silly me.
A few minutes later the guy complained to me that the installation was giving errors with "something called cert-whatever". Ironically, he ignored such errors the first time (fail). He actually meant
certutil, a command-line tool for managing certificates on the system. I use it to install our root certificate, required to use the application (don't ask). I considered that a really weird issue, since all versions of Windows I've tried have such tool. Turns out my tests were completely wrong: I've been testing Windows versions that were way too recent. XP don't have such tool! Well, that sucks. Also, the alternative,
certmgr, is part of Windows SDK. So, either the user upgrades the OS, or installs the whole SDK on system. No redistributable packages for that as well, so legally putting that file on the installation is tricky. Also, different versions of Windows require different versions of such tools (XP vs. the rest, I believe). Solution? I'll create my own application to install and remove certificates from the system using .NET's API for X.509 certificates. Should work just fine.. except for one thing: I have no idea if my certificates will work on such an old system. XP didn't have support for some newer stuff in such area, so things might get tricky.. and (even more) insecure. :-(
I raised the following question to my boss: "why would someone use such an old and obsolete version of Windows? Why not upgrade?!". He replied what I expected: "you just don't change anything that is working just fine". If the machine is working and the user can do everything with it, you just don't change it. And that's true, most companies don't really upgrade their software that easy. A few weeks ago I was reading why would people still use Visual Studio 2010 (so do we, btw), since it's a quite old version nowadays. Well, they have a license for it and it provides everything they need right now. I understand that, and I also play by such rules (except with Windows 10, which I went full retarded and upgraded ASAP). It makes sense. But now think with me: why would you have such an obsolete operating system within your company? A system that is vulnerable to attacks, insecure and that won't be fixed? A system that you can easily (probably) replace by a newer version? I've been thinking about that and discussing with colleagues, and here's what we got so far for possible reasons:
- Hardware - if you have really old hardware, you can't easily upgrade your system. This is not the case (as far as I remember), but still is something to consider. In times of Windows Vista, I was using Windows XP on my Pentium III 450 MHz, so I get it. But it's not that.
- Legacy software - maybe you have some really old application that doesn't run on anything over Windows XP? Well, that's why I have VMs. But ok, simple users don't understand that. Fair enough.
- Laziness - not having an IT department or having a really bad one might explain such old systems. That sucks (for the company and for us coders).
- Money - new licenses cost money for the company. I don't think this is an issue for them though. At least not for one machine.
One of my colleagues even said "it might be easier to ask them to upgrade than to fix everything for XP". That might actually be true depending on what happens in the next days, when I'll start working on that to see how far can I get on XP. But according to my boss, I need to support XP, so I don't really have an option...
I believe having an obsolete OS on your network might be good to you to keep your stuff working, but it's really bad for security and overall system stability. It's also bad if you want to run anything new (coded in the last years), since some APIs aren't available. It's bad for bugs, since they won't get fixed at all. It's bad if you need help with. It's bad for my sanity.
And now it's time to go back to installing Windows XP SP3 and running Windows Update on a VM... :-(
PS: I know a company that still runs their 16-bit main control software on a Windows 3.11 machine, but I won't tell. That's too crazy and funny to believe.