Mar 132017

puTTY logoAnyone who has logged in to a UNIX or Linux machine remotely coming from a Windows box probably knows puTTY, which is practically “the” SSH and telnet client for Windows. In conjunction with a small X11 server like Xming you can even do Remote X. To my surprise, a new version has been released just last month, as a colleague told me! So there is version 0.68 now, and it comes in both a 32-bit and a 64-bit flavor.

Of course I had to try the 64-bit version on XP x64, and it did fail to execute:

64-bit puTTY failure on XP x64

A classic: 64-bit puTTY failure on XP x64, because it’s “not a valid Win32 application”

Out of curiosity, I fetched the puTTY source code from [here], because I thought I could just compile & link it myself. Building for 32-bit proved to be relatively easy; Just load the corresponding solution file into Microsoft Visual Studio 2010, build the whole project, done. But I wanted 64-bit! So I created a x64 build target and gave it a shot, but it couldn’t find the _addcarry_u64 intrinsic.

After a bit of searching on the web, it became clear that the intrinsics header of Visual Studio didn’t provide it. It’s too old, you need Visual Studio 2013 or newer for that. Funny part is, puTTY only comes with project files for 2010 and 2012, how are they building their x64 version? No idea. Maybe they’re linking against a different library version or something.

One attempt that I was going to make (build it with VS2013, linking against an older platform SDK) isn’t done yet, because I need to prepare my Windows 7 VM for it. I did manage to compile and run puTTY as 64-bit code on XP x64 by hacking up their program though! In the unpacked source tree, open sshbn.h and take a look at line #70:

expand/collapse source code
  1. #elif defined _MSC_VER && defined _M_AMD64
  3.   /*
  4.    * 64-bit BignumInt, using Visual Studio x86-64 compiler intrinsics.
  5.    *
  6.    * 64-bit Visual Studio doesn't provide very much in the way of help
  7.    * here: there's no int128 type, and also no inline assembler giving
  8.    * us direct access to the x86-64 MUL or ADC instructions. However,
  9.    * there are compiler intrinsics giving us that access, so we can
  10.    * use those - though it turns out we have to be a little careful,
  11.    * since they seem to generate wrong code if their pointer-typed
  12.    * output parameters alias their inputs. Hence all the internal temp
  13.    * variables inside the macros.
  14.    */
  16.   #include 
  17.   typedef unsigned char BignumCarry; /* the type _addcarry_u64 likes to use */
  18.   typedef unsigned __int64 BignumInt;
  19.   #define BIGNUM_INT_BITS 64
  20.   #define BignumADC(ret, retc, a, b, c) do                \
  21.       {                                                   \
  22.           BignumInt ADC_tmp;                              \
  23.           (retc) = _addcarry_u64(c, a, b, &ADC_tmp);      \
  24.           (ret) = ADC_tmp;                                \
  25.       } while (0)
  26.   #define BignumMUL(rh, rl, a, b) do              \
  27.       {                                           \
  28.           BignumInt MULADD_hi;                    \
  29.           (rl) = _umul128(a, b, &MULADD_hi);      \
  30.           (rh) = MULADD_hi;                       \
  31.       } while (0)
  32.   #define BignumMULADD(rh, rl, a, b, addend) do                           \
  33.       {                                                                   \
  34.           BignumInt MULADD_lo, MULADD_hi;                                 \
  35.           MULADD_lo = _umul128(a, b, &MULADD_hi);                         \
  36.           MULADD_hi += _addcarry_u64(0, MULADD_lo, (addend), &(rl));     \
  37.           (rh) = MULADD_hi;                                               \
  38.       } while (0)
  39.   #define BignumMULADD2(rh, rl, a, b, addend1, addend2) do                \
  40.       {                                                                   \
  41.           BignumInt MULADD_lo1, MULADD_lo2, MULADD_hi;                    \
  42.           MULADD_lo1 = _umul128(a, b, &MULADD_hi);                        \
  43.           MULADD_hi += _addcarry_u64(0, MULADD_lo1, (addend1), &MULADD_lo2); \
  44.           MULADD_hi += _addcarry_u64(0, MULADD_lo2, (addend2), &(rl));    \
  45.           (rh) = MULADD_hi;                                               \
  46.       } while (0)

I just commented out the entire codeblock using that modern _addcarry_u64 intrinsic, and replaced it with the code being used for the 32-bit version:

  1. #elif defined _MSC_VER && defined _M_AMD64
  3.   /* 32-bit BignumInt, using Visual Studio __int64 as BignumDblInt 
  4.    * This is compatible with VS2010 & VS2012 for building a x86_64
  5.    * version of puTTY (no __int128 with those compilers).
  6.    */
  8.   typedef unsigned int BignumInt;
  9.   #define BIGNUM_INT_BITS  32
  10.   #define DEFINE_BIGNUMDBLINT typedef unsigned __int64 BignumDblInt

I built that and it works, even though I keep thinking I should be using a wide 128-bit data type here (just like the original x64 code), but then we don’t have __int128 in MSVC before 2013, and I’m on 2010. And I don’t know how to use SSE registers in that context with things like __m128, which is why I left it alone. Looking good anyway:

puTTY 64-bit XP x64 version logged in to Windows 2000

puTTY 64-bit XP x64 version logged in to Windows 2000 using a modern SSH server (click to enlarge)


puTTY 64-bit XP x64 version logged in to FreeBSD 10.3 UNIX

puTTY 64-bit XP x64 version logged in to FreeBSD 10.3 UNIX (click to enlarge)

In any case, here is a complete 64-bit build of puTTY that works on NT5.2 operating systems like Windows XP Professional x64 Edition or Windows Server 2003 x64:

  • [puTTY 0.68][1] (x64 version for NT5.2, portable without installer)

Maybe I’ll try to build a version with VS2013 on Windows 7 for the same platform target, we’ll see. But at least this works!

Oh and… No, I don’t really think anyone actually needs a 64-bit version of puTTY ;). Plus the 32-bit one works just fine on XP x64 / Server 2003 out-of-the-box anyway. But hey… You know… :roll:

[1] puTTY is © 1997-2017 Simon Tatham and is licensed under the MIT license

Jul 152015

XP x64 is dead logo[1] Update 2: It’s not looking good. At all. I (and some other users) have been playing around with Windows Storage Server 2003 systems (see the first update below), and while the OEMs are supposed to uphold support for the system, it seems they just don’t care. Two distributions have been inspected, one from Dell and one from Hewlett Packard. The latter actually does feature an updating software, that will however ignore all newer Microsoft security fixes. It just doesn’t do anything useful at all it seems.

For now, I am not even sure whether Microsoft truly ships any updates to the OEMs for rollout to customers, or whether they’ve just abandoned WSS03 completely, making their lifecycle statements regarding the operating system an empty promise, as no OEM could patch the OS itself like Microsoft can. It looks like we’re not getting anywhere with this. If you are a Windows Storage Server 2003 operator and you know more about this, or if you actually do have access to WSS03 Windows updates from after 2015-07-14, please do let me know in the comments! Thank you.

Update: While I’m not completely sure about it, it might be the case that we can disregard the text below this paragraph. A user that goes by the name of [tagg] pointed me towards a comment in the RyanVM forums, where 5eraph is releasing his XP x64 update packs. It seems that a special version of Windows Server 2003 called the “Windows Storage Server 2003” is actually supported until [October of 2016], which could mean that XP x64 could get yet another extension to its lifetime. I’m currently inspecting the operating system and methods to extract full update installers out of it to see whether it can truly be done. If yes, there might be life in the old dog yet!

The dark ages have finally arrived – for XP x64 users, that is. Yesterday, Microsofts extended support for Windows Server 2003 has ended, and with it also my [unofficial XP x64 update] project. There won’t be any more updates for Windows XP Professional x64 Edition SP2 and its on-board components from this day on. And while the regular 32-bit version with its older NT 5.1 kernel will live on until 2019 due to the [POSReady2009 hack], XP x64 will not, as there is no 64-bit embedded POSReady version of XP naturally, given that point-of-service systems like ticketing machines or airport terminals don’t need 64-bit address spaces.

So, as said on the update page, if you’re going to keep using XP x64, you’re doing so at your own risk. And you should really be knowing what you’re doing too, or you may not only put yourself at risk, but also other users on the web, should your machine become compromised. But given that XP x64 users I’ve encountered recently are also often freaks and avid Linux/UNIX users as well, I think the danger is much lower than with 32-bit XP.

Well that’s it. From the Microsoft side of things, this is pretty much where XP x64 ends.

It’s a bit sad that there is no free kernel API extension to make newer software run on the old system, like there is for Win9x with [KernelEx]. Software built with modern Microsoft development environments (Visual Studio 2013+) and in certain cases older ones will likely work on XP less and less from now on. People will no longer care so much for linking against the old platform SDKs and compiling for the v110_xp platform target.

Several free software projects (like FileZilla to name just one of many) have already ceased to support NT5.x even before the end of Server 2003. It’s even worse for commercial applications of course. Then there are others which still care to keep the platform supported, like the x265/HEVC encoder or closed software like AnyDVD HD.

But one thing’s for sure.

From this day on, it’ll only get darker and colder for those who decide to stay on this ship!

[1] Original image is © 2015 Windows 8 Wallpapers