Wednesday, April 9, 2014

XP Support ended Yesterday : What changes?

For many people nothing changes, the day Microsoft says they won't patch XP anymore.  However, if some major virus spreads like wildfire throughout the remaining XP system population on the internet, you can be Microsoft will release a "free" out of band patch for that vulnerability. It would be impossible for them not to.

For some people, and for some industries, XP really is dead.  My employer works in the healthcare market.  I believe that to operate a Windows XP machine in a healthcare setting, whether in a hospital, or a private clinic, would be tantamount to malpractice.  In the USA, and in Canada, there are laws about the steps you need to take to protect the privacy of your information.  You can not patch XP yourself, and you have no promises from Microsoft to ever patch any vulnerabilities in XP.  So, use of XP in a professional setting, especially in healthcare, would be, in my view, irresponsible at the least, and perhaps a violation of the law, in your country, if your laws protect patient privacy and hold those who fail to act responsibly to protect patients.  I am not saying anything bad WILL happen, but that something bad COULD happen, and it would be irresponsible for you to pretend that it couldn't.

XP really was a great operating system.  It was the first version of Windows that I really grew to like. The funny thing is that I can't stand operating on it any more.  I find it incredibly quirky and broken. I never liked Vista, and I loved Windows 7.  I know some people will think I'm crazy but I actually LIKE Windows 8.1 now. There are still some stupid things about it. The start "screen" and "metro" are stupid, and I hate them, but aside from the glaring stupidity of the metro crap,  Windows 8.1 is a pretty decent operating system.  I use it all day every day at work, and I like it.  I like client Hyper-V.  I like the responsiveness and overall speed of the system. When 8.1 Update 1 brings back a reasonable facsimile of the Windows 7 era start menu (non-full screen), I think many people will at last be willing to switch up from Windows 7.

As a Delphi developer,  I'm not sad to see XP go away.  It was a fantastic piece of technology in 2002, but like the machines that it ran in 2002, it belongs in a museum, not as a primary operating system on your home or work computer.  

XP introduced the desktop and home user to a fully Unicode compliant API, but true global Unicode features and functionality required installing a separate language pack for far-east language support.  XP introduced a fairly robust protected mode kernel, but ran your video drivers in ring zero, meaning that video card bugs would blue screen your system.   XP was actually really crappy, by comparison to windows 7, and in my opinion, windows 8.1 is just a tuned up kernel revision on windows 7, with a rather shabby new start menu, and a lame-duck "app store".   But below that lame layer, beats the heart of a pretty good operating system.   I find building apps in a modern Delphi version (XE5) on Windows 8.1 is pretty nice.  I like making my apps look like they belong on a modern computer in 2014.  Here are a few things I think need to die along with Windows XP:

- 16 x 16 toolbar icons.  This was a sensible choice when your laptop screen was 640x480. No more.

- Flat gray everywhere.  Give the clBtnFace look a rest, okay?

- Those stock bitmaps that shipped with Delphi 3.  Invest in some real art and icons, okay?

I suggest you celebrate the death of XP by moving your apps beyond that ancient classic windows look and feel, and into the 21st century.  XP is dead, long live Windows.

How are you all feeling about XP? Nostalgic? Still in love? Glad to see it go?  Planning to go down with the ship?



14 comments:

  1. The only issue with XP are:
    1) Hardware (often expensive) without drivers working on later operating systems - and no update available. Some of that hw may also be medical systems... I've seen some still running older system than XP as well.
    2) Bad applications written by developers who never learnt to code past Windows 3.x. They may not work properly on later operating systems - if you can't replace them easily it's a problem (same is true for some bad applications written in Java that refuses to work but with very old JREs). It's not a problem of look&feel, most users won't care, it's a problem of bad coding practices. Again, some of these may be in the medical sector too.
    You can't rely on MS releasing patches even if a big issue is discovered. I guess it won't but for paying customers. The product is EOL - does Embarcadero releases patches for its EOLed products even if big bugs are discovered? And XP was supported for 13 years and after four new OS releases, not six months.
    That said, there are ways to isolate enough machines still needing to run XP and protect them even if no more patches are available, but that requires a good machine/network setup and policies to use them only in a safe way. For example:
    1) Isolate XP machine in their own network segment or VLAN. Use a FW between this segment and other segments, and allow for only needed traffic from/to allowed endpoints.
    2) Use IPSec to allow for only communications between approved machine
    3) Don't allow internet access. If needed, use a proxy with a whitelist of approved addresses only. Require proxy authentication. Use an IDS also
    4) Put them in their own domain, if possible, and use proper group policies to enforce stong polices on administrative accesses. Force user to use non-privileged users (but again, crappy apps may need too much privileges). Limit logon hours, if possibile. Require strong password, and expire them at least every 60 days. If possibile, use smartcard/tokens for access. Disable unused services.
    5) Enable auditing. Ship logs to another machine, and use some correlator/alerting system to spot anomalies.
    6) Plan to upgrade, choose better alternatives to bad applications, train your developers to write proper code that will work on newer OSes. Choose dev tools developed properly also...

    ReplyDelete
  2. Just a comment on using Windows (any kind) as OS on an equipment for healthcare.

    To me it seems as a bad choice in the first place.
    I guess both the hardware and the software for the application is certified in one way or another. A change in the underlaying OS may put the apparatus in an uncertified state, so the only way is to manage these updates from the producer.

    Now this is often in conflict with the users IT policy (which in many cases is outsourced to a 3rd party). Since this is a contradiction of interest a possible liability question,

    I would avoid using windows as OS in this scenario, or other similar applications where software and hardware is certified for use.

    How is this handled in your case?

    ReplyDelete
    Replies
    1. And which OS would you use? Linux? Which changes faster than Windows, and often in incompatible ways? Unless you can manage your own distro is not a better choice than Windows. An embedded OS? Which can become vulnerable as well? There are embedded versions of Windows also, which are far more modular to reduce the attack surface.
      Often here we're talking about "UI machines", those displaying the user the results of the device operations, often requiring pretty complex and advanced interfaces, which should be also user-friendly.
      It's the very idea of certification that has to be changed, because today "old and certified" means often also "unsecure and risky". It's not nice excuse "sorry, you're died because someone hacked our systems, but we are certified so you can't complain!"
      Often the idea of "certification" is just a marketing way to make you pay more, and a lame excuse for IT departments to avoid to mantain systems.

      Delete
    2. You appear to be considering only the OS in an embedded environment, as for example, might occur with a gig machine, such as an MRI. However, I would seriously doubt that Windows is in direct control of any processes which can have direct impact on patient (mal)treatment. Instead, these machines are generally based on conventional embedded systems with Windows consoles as the user interface.

      And as to the Linux alternative, not only does it pose risks for all the reasons given by kmorwath, but also requires a different level of IT support, less readily available in many areas than Windows people.

      Delete
    3. Linux or Windows share the same problem. Yes there are embedded versions of both of them that are slightly better in terms of security/stability and the update process.
      I would not rely on such an instrument monitoring the heart rate in an intensive care environment though.
      But there are probably applications for analysis of cardiograms that are not bound to a real-time analysis, that very well can live in a Windows or Linux environment, so it all depends on the application.
      To pick a suitable OS for real-time operations, there are some choices in the embedded world. Most of them embed the OS and the application in one package.
      We are working with a true RTOS that is partly win32 compatible (using Delphi or Visual Studio), that avoids common hacker attacks through the internet. All drivers and application parts are compiled into a single source. The GUI part is different from a normal windows environment, but complex dialogs,presentations etc is doable.
      As for claiming certification as a market gimmic, we all have to live with it. In our line of business (not medical), we are excluded in the bidding process without certification.

      Delete
  3. Professionals, business, healthcare and many other industries, depend on commercial software that does not exist on Linux. Linux is useful in certain cases, primarily for engineering, for web servers, and so on. It is not useful in the majority of business and professional computing uses (including healthcare) in which Windows-based machines are prevalent. If you're not aware of that, then you need to wake up a bit.

    I'm a big Linux fan, but I don't try to pretend it is something that it's not.

    ReplyDelete
  4. I won't shed any tears for XP evening though I have one machine with XP that I still rely on.

    However, I am tearing my hair out at the moment over BTree Filer. Your XE2 port worked in XE4 (Thank you!) but now XE6 is strangely even pickier about Unicode stuff. My first attempt at changing the code for XE6 has failed. Do you have any plans to try it in XE6?

    I'm going to keep trying to get BTree Filer running in XE6 becauses I have thousands of folks who'd like to read their legacy data with the upcoming FireMonkey version of my app. Bugs in XE4's font rendering are forcing me to move to XE6.

    - Mike

    ReplyDelete
  5. BTreeFiler should be possible to move up to XE6. Keep an eye out for additional casts required in Win32 API calls (those which are in windows.pas), usually requiring explicit cast to Pointer() for things like raw Win32 CreateFile calls and so on.

    ReplyDelete
  6. Thanks, Warren. Those are exactly the things I'm up against. Evidently Windows.pas has become Winapi.Windows and CreateFile() as an alias switched from CreateFileA() to CreateFileW() or... something. I had no idea what was going on until I asked for help on the support boards.

    ReplyDelete
  7. ...and I failed again. Here are the changes I tried on the second attempt:

    After the changes below, opening an existing database gives error 10140.

    ============================================================================

    in BTFileIO changed line 864

    aHandle := CreateFile(aName,
    aHandle := CreateFileA(aName,

    line 917

    if not MoveFile(aName, aNewName) then
    if not MoveFileA(aName, aNewName) then

    line 930

    if not Windows.SetEndOfFile(aHandle) then
    if not Winapi.Windows.SetEndOfFile(aHandle) then

    line 547

    if not btfDeleteFile(F.Name) then begin
    if not btfDeleteFile(@F.Name) then begin

    line 772

    if not btfRenameFile(F.Name, NameZ) then begin
    if not btfRenameFile(@F.Name, @NameZ) then begin

    line 797

    if not btfOpenFile(F.Name, OpenMode, ShareMode,
    if not btfOpenFile(@F.Name, OpenMode, ShareMode,

    BTISBase

    line 817

    if not btfOpenFile(F.Name, bomReadWrite, bsmExclusive,
    if not btfOpenFile(@F.Name, bomReadWrite, bsmExclusive,

    IsamBase.inc

    line 112

    FName [0] := Char (Pred (SizeOf (IsamFileName)));
    FName [0] := AnsiChar (Pred (SizeOf (IsamFileName)));

    line 114

    FName [0] := Char (Pred (Pos (#0, FName)));
    FName [0] := AnsiChar (Pred (Pos (#0, FName)));

    Filer.CFG

    changed from Const to Var

    DatExtension : String [3] = 'DAT';
    IxExtension : String [3] = 'IX';
    DiaExtension : String [3] = 'DIA';
    SavExtension : String [3] = 'SAV';
    MsgExtension : String [3] = 'MSG';
    {-Extensions for data, index, dialog, save, and message file}

    BufRecIO.pas

    line 140

    // Const

    ReplyDelete
  8. Ouch dude. Blog comments are not the right place to cover whether you have understood and correctly applied your changes. It looks to me like a random pile of pointer de-reference "hail mary" changes. ;-)

    ReplyDelete
  9. Sorry about posting in the wrong place. I've just had no luck in any other online venue. I searched for a solution for more than six months before I stumbled on your bitbucket back when I moved to XE4.

    They are indeed "hail mary" changes because I don't understand the differences between XE4 and XE6. At least they differ from my first round of "hail mary" changes. :)

    Feel free to delete my blog comment. I just wanted you to have the changes I tried if you ever update that bitbucket - for which I'd be extremely grateful all over again.

    - Mike

    ReplyDelete
  10. My suggestion is clone my repo, make your changes, and push them to your own public bitbucket. Then you can report issues on my bitbucket site.

    ReplyDelete