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

Mar 082017

Firefox ESR dark logo1.) The end is near for modern browsers on XP and Vista

After Google had stopped supporting Windows XP with Chromium 50.0 (Blink engine 537.36 & JavaScript V8 engine 5.0.71), I wondered for how much longer projects depending on it would last on the old OS. Unsurprisingly, they started dropping XP / XP x64 pretty quickly as well, like Vivaldi, Iron or the new Opera to name a few. Firefox kept support alive however, but of course, the end was looming over our (=XP users’) heads all that time, and now the decision finally has been made!

Mozilla Firefox will cease to support Windows XP, Windows XP x64 Edition and all editions of Windows Vista starting with version 53. If you’re still on 51.0.1, you’ll be provided with not just one, but two consecutive updates:


The reason for this is, that the first update just switches your update channel from “Release” to “ESR” (Extended Support Release). ESR versions are also typically present on Enterprise Linux systems like for instance RedHat Enterprise Linux 5 and 6, etc. After a quick restart, the browser will offer the real, final version for XP: Firefox 52.0 ESR.

After the update, the first thing you get to see is the notification of support ending for Windows XP and Windows Vista:

Firefox is notifying the user of how Vista & XP are no longer going to be supported

Firefox is notifying the user of how Vista & XP are no longer going to be supported (click to enlarge)

A quick check confirms it: This is now Firefox 52.0 ESR:

Firefox 52.0 ESR reporting is version

Firefox 52.0 ESR reporting is version (Click to enlarge)

According to the [Mozilla foundation], security updates will be provided for XP/Vista up until September 2017, and the actual, exact EOL date will be fixed mid-2017.

After that, there will no longer be any modern browser support for XP (NT 5.1), XP x64 & Server 2003 (NT 5.2) as well as Vista and the first edition of Server 2008 (NT 6.0). That is, unless somebody provides patched builds, but I don’t think that’s gonna happen…

2.) Electrolysis / e10s

On top of that, I have reevaluated the functionality of Mozillas’ multiprocessing technology on Windows XP x64 Edition. I tried that before with some 50.x version and failed to have Firefox spawn multiple processes for multiple tabs. This is a feature that makes Firefox more crash-proof and faster as well. I’m happy to announce that it does work with Firefox 52.0 ESR though!

Of course, this is not officially supported, not on XP / XP x64, nor on Vista. So force-enabling Electrolysis can only happen at your own risk! To enable the feature, open about:config, confirm the prompt, and then change the following properties as shown, create them manually if they don’t exist yet:

browser.tabs.remote.autostart     [boolean]   true
browser.tabs.remote.force-enable  [boolean]   true
extensions.e10sBloc­kedByAddons    [boolean]   false
extensions.e10sBloc­ksEnabling     [boolean]   false
dom.ipc.processCount              [integer]   16

You need to be a bit careful with dom.ipc.processCount however; Each Firefox process might consume hundreds of megabytes, and with that property set to 16, Firefox can spawn a total of 17 processes, 1 master process and 16 child processes (=tabs). So tune that value to something your machine can take! If you spawn to many processes on a machine with just 2GB or 4GB of memory, you might run into swapping rather quickly!

Also, you need to test this with your plugins and extensions! Not every plugin / extension will play nicely with e10s! In some cases the browser may even crash completely, or have individual tabs crash. You have been warned!

To test this, open about:support and look for Multiprocess Windows. Depending on how many browsers you have launched, it should show something like 1/1 (Enabled by user) or 2/2 (Enabled by user). Or, just open multiple tabs, load web sites in them (yes, you have to) and watch Firefox spawn additional processes in Task Manager:

Firefox spawning processes on XP x64 thanks to Electrolysis having been force-enabled

Firefox spawning processes on XP x64 thanks to Electrolysis having been force-enabled

And that’s it! Enjoy your security updates for a while longer, and then welcome Firefox into the mausoleum that is Windows XP! :) It might be the last browser you’ll ever use on that platform…

Feb 242017

Firefox + HTML5 + XP logo1.) Introduction & Explanation

This is one thing that has brought to me by two users ([SK1] on [Voodooalert]German flag and [liquidLD] who talked to me about this on IRC), and because I got a bit pissed off by it myself, I decided to look into the matter. Basically, HTML5 video on Windows XP / XP x64. But not just with webm (VP8/VP9), but also with H.264/AVC. Let’s face it, a lot of videos on the web rely on H.264 and sometimes you simply can’t watch certain videos or you won’t get all the available resolutions. Of course you could just rely on Adobe Flash, but since Google basically took over with their Pepperflash plugin and their Chrome browser no longer supports XP, it’s not the best move either. Especially when you think about Adobes’ history with critical security loopholes in Flash. HTML5 is just much, much safer, and free as well, and Firefox still supports XP.

Note that this guide is thus based on Firefox exclusively. Anything starting with version 47 should work, official support came in 49, and I’ll be using the current version, 51.0.1 at the time of writing.

So, why doesn’t it “just work” in the first place? It did a few years back, right? Because H.264 playback relies on a DRM plugin, on Linux it would be the Google Widevine plugin, on Windows it’s the Adobe Primetime plugin. So yes, Firefox does support DRM out of the box. But even if content isn’t signed and encrypted, the browser still relies on those plugins to play H.264. And the problem is, that Adobe found some problems with that plugin on XP, so they disabled support on the platform. Their version 17 plugin is still being rolled out with the browser however, and it is binary-compatible with XP, so let’s show you how to re-enable it!

2.) Making it work

On Windows XP and XP x64, the plugin should reside in the folder:

%USERPROFILE%\Application Data\Mozilla\Firefox\Profiles\<your profile folder>\gmp-eme-adobe\17\

That folder should contain the files eme-adobe.dll, and eme-adobe.voucher. If it doesn’t (maybe because you have a DRM-free version of Firefox), just create the folder structure yourself, get the necessary files from [here] and place them in that folder.

Having the files present won’t enable Adobe Primetime for you however as you can see on about:plugins (Note: The Cisco stuff you can see there is just for WebRTC, so it’s unusable for HTML5 <video>), we still need to tweak a few things on the about:config page of Firefox. Look for the following properties and set them to the values shown below. If a property doesn’t exist yet – media.gmp-eme-adobe.forceSupported most likely won’t – just create them yourself, all of them are boolean properties and all of them need to be set to true:

media.gmp-eme-adobe.enabled		true
media.gmp-eme-adobe.forceSupported	true
media.gmp-eme-adobe.visible		true
media.gmp.decoder.enabled		true
media.eme.enabled			true
media.mediasource.mp4.enabled		true
media.mp4.enabled			true

After making those changes, you’ll need to restart Firefox. Now you might already be good to go, but on some configurations, about:plugins might show something like this:

HTML5+H.264 on Firefox not yet working

Adobe Primetime seems enabled, but there is no file information? So it’s not actually loading the eme-adobe.dll yet (click to enlarge)

If that happens, open your preferences menu on the top right, click on “Add-ons”, then “Plugins” or just go to about:addons. What you should be seeing is this:


However, if Adobe Primetime shows a notice saying that it’s going to be “installed shortly”, forget it. Just do it manually on the plugins’ options page you can see on the right image. To do so, click “Check for Updates”. The warning should be gone momentarily. After that, re-check about:plugins, and you should be getting this:

Adobe Primetime fully enabled

Adobe Primetime fully enabled (click to enlarge)

3.) Testing

Now you can do a quick check on the [Youtube HTML5 page], and it should confirm that everything’s working:

Youtube confirming full HTML5 video support

Youtube confirming full HTML5 video support including H.264 and Media Source Extensions (click to enlarge)

With MSE, even Javascript players (like the Flowworks player) bytestreaming H.264 to Firefox should work! Of course, that’s not very thorough. What you’d want is a real playback test, since you can never be sure what you’re getting on Youtube without a bit of extra work. Decent playback tests are currently available on [Quirksmode], and it should look like this:

Firefox playing HTML5 H.264/AVC video in Firefox on Windows XP x64

Firefox playing HTML5 H.264/AVC video on Windows XP x64 (click to enlarge)

With this, even stuff like Netflix works, because you’re getting not just H.264 playback, but also DRM support. Now, whether DRM support is a good thing or not… You’ll have to decide that for yourself. I’m not supportive of DRM content on the web, but if you want to view or listen to such content, you can!

Just one last word of warning though: Adobe has ended their support for XP with a reason, as the Primetime content decryption plugin has shown problems and instabilities on XP! I’ve been using this for about a week now, and I’ve had one case of a video getting stuck, which is a typical symptom of Primetime throwing up on you. Don’t worry though, Firefox won’t crash. Just move the video slider a bit or restart the video, and it’ll work again! You don’t even need to restart the browser, and such occurrences seem to be quite rare, so I’m fine with it.

There you go!

4.) Thanks

Big thanks fly out to [the guys at MSFN] who came up with all of this. I basically got 100% of my information from them, so thank you! You rock! :)

Update: If you update your version of Firefox to the latest and final 52.0 ESR (extended support release), the last version which will be officially supported until 09-2017 for XP, you might notice that Adobe Primetime just disappeared after the update. That’s because the installer may delete the property media.gmp-eme-adobe.visible from your prefs.js. To reenable it, you’ll have to manually recreate the boolean property and set it to true:

media.gmp-eme-adobe.visible		true

Restart Firefox after the change, and the plugin should reappear on about:plugins and about:addons!

Nov 142016

HP/Compaq nx6310/nc6320 logoA good while back, I got a free notebook from [The_Plague]German flag, a HP/Compaq nx6310[1][2] which he kinda pulled out of the trash at his company. It’s not exactly “Thinkpad T23” material, but it’s a pretty solid, well-built machine with a good keyboard. I’ve been using the thing as an operating system testbed for a while (Linux, ReactOS, Haiku OS, OpenBSD, Dragonfly BSD, and finally: FreeBSD UNIX). After settling for FreeBSD the machine clearly showed its limitations though, the most problematic being imposed by the very low-end i940GML chipset. That one has limited the machine to a single processor core and a 533MHz data rate FSB.

I did give the machine a Core Duo T2450, but switching dual core on in the BIOS results in a lockup at POST time. Also, the chipset cannot use dual-channel DDR-II and limits the user to 2GiB of memory, making the use of a 64-bit processor rather pointless. Which turned out to be bad, because some code doesn’t even provide full functionality for 32-bit anymore, like x265, which dropped deep color support on 32-bit architectures.

But now, The_Plague pulled another one out of the trash, it’s basically the exact same machine, but a higher-end model, the nc6320. This one has an i945GM chipset, which means dual core support, FSB667 and 4GiB dual-channel RAM capability! It came with a Core 2 Duo T5600 @ 1.83GHz with 2MiB L2 cache. I ordered the largest possible chip for this box from ebay Hong Kong, so now it has a Core 2 Duo T7600 @ 2.33GHz with 4MiB L2 cache. Also, 2×2=4GiB of DDR-II/667 CL4 are on their way already, together with a 12-cell secondary monster battery!

And of course, FreeBSD UNIX again, in its brand new version 11.0-RELEASE:

HP/Compaq nc6320 running FreeBSD 11.0 UNIX

HP/Compaq nc6320 running FreeBSD 11.0 UNIX (click to enlarge)

The CPU upgrade is actually even noticeable when browsing the web, lots of resource-hungry Javascript and CSS3, you know. Luckily, Chromium supports hardware acceleration on the Intel GMA950 GPU on FreeBSD, as the OS comes with a kernel modesetting compliant driver for almost all integrated Intel graphics chips. It’s too slow to do the rasterization stage on the GPU, but it still helps.

Once again, it shall serve mostly as a meeting and sysadmin machine, with a little bit of private-use-fun added on top. Let’s have a look at the software! Oh and by the way, I decided to make the screenshots 8-bit .png images, so some of them will look a bit bad. But still better+smaller than JPEG for that purpose:

Running screenfetch on the nc6320

Running screenfetch on the nc6320 (click to enlarge)

$ screenfetch is showing us some details about the machine, which also makes it clear that everything is “Tokisaki Kurumi”-themed. Since there’s a lot of red color on that girls’ garments it seems at least somewhat fitting for a FreeBSD machine.

Chromium with FVD Speed Dial

Chromium with FVD Speed Dial (click to enlarge)

I’m a [Vivaldi] fan personally, but that browser isn’t available on any BSD yet, so I installed a few extensions to make Chromium work somewhat like Vivaldi; The most important part being the static FVD speed dial you can see above. What you can’t see here are the other extensions that followed it: AdBlockPlus and Ghostery. I hear there are better/faster solutions than ABP for ad blocking these days however, so maybe I’ll revise that.

IBM Lotus Notes via wine 1.8

IBM Lotus Notes 6.5.1 via 32-bit wine 1.8.4 (click to enlarge)

Also, for work I would sometimes need IBM Lotus Notes, as it’s our Universities’ groupware solution (think of that what you will). While I couldn’t get the Linux version to run, our Domino servers still accept connections from older clients, so it’s Lotus Notes 6.5.1 running under a 32-bit [wine], which is a solution IBM officially recommended for running the software on Linux/UNIX a few years ago. And yeah, it still works. And if you have Windows software wine can’t cope with?

XP x64 via VirtualBox on FreeBSD

XP x64 via VirtualBox on FreeBSD (click to enlarge)

For anything that wine can’t handle, the VirtualBox port kicks in, as we can see here. Together with the CPUs VT-x extension and the guest tools, virtualizing Windows on FreeBSD UNIX works relatively well. Not all features are there (like USB passthrough), but it works ok for me. Will need a Windows 7 VM as well I think.

More stuff:

Communicating on FreeBSD

Communicating on FreeBSD (parts are censored, click to enlarge)

One important part is communication! Luckily, there is a version of licq in the ports tree now. It builds well together with its Qt4 UI, so no complaints there. Hexchat for IRC access is also available, but the tricky part was Skype; Not that I really need it, but I wanted to have the linuxulator up and running as well! For those of you who don’t know what the “linuxulator” is: It’s a series of kernel modules that extend FreeBSDs kernel with parts of the Linux kernel interface. On top of that, you can pull parts of Fedora 10 or CentOS 6.8 or some CentOS 7 Linux userspace components from the package servers. Together with the kernel modules those form a kind of runtime environment for executing Linux programs – Skype 4.3 in this case! So I have both wine and linuxulator ready for action, and with it access to ICQ, Jabber, MSN, IRC and Skype. Now, what about multimedia?

Multimedia on FreeBSD

smplayer and xmms on FreeBSD, unfortunately the 8-bit color is a bit too noticeable for this screenshot, my apologies (click to enlarge)

This is a part where the upgraded processor also helps. Here we can see (s)mplayer play the last episode of the Anime Hanayamata in taxing 2.5Mbit H.265/HEVC encoding, paired with AAC-LC audio. The Core 2 Duo T5600 had some issues with this, but the faster T7600 shows now problems. Additionally, xmms is playing a Commodore 64 SID tune using libsidplay2 and the reSID engine. xmms comes with a lot of funny plugins from the FreeBSD ports tree for Gameboy tunes or NES tunes, but the C64 one you need to compile for yourself. Not too hard though, you can fetch libsidplay2 and reSID from packages beforehand to make things easier! What else?


ioquake3, a cleaned up version of the Quake III Arena source code, here in its 64-bit FreeBSD build (click to enlarge)

A pretty fun part: Playing the native Quake3 port [ioquake3] in 64-bit, for whenever you just need to shoot something to blow off some steam. ;) I have to say, I had to tweak it quite a bit to run fluently on the WVA 1400×1050 display of this book given the weak GMA950 GPU, but it runs “rather ok” now. ioquake3 is also available for Windows, OSX and Linux by the way, including a more advanced OpenGL 2 renderer, which gives users access to some advanced graphical effects. And if I get bored by that…

HakuNeko Manga ripper and qComicbook

HakuNeko Manga ripper and qComicbook showing some sweet girls love! (click to enlarge)

Once again, fixing up HakuNekos’ build system and C++ code to work with FreeBSD properly took some time. Unfortunately there is no port for it yet (and I’m too stupid/lazy to create one), so you have to fix it by hand. Lots of replacing sed invocations with gsed, find with gfind etc. and the OS #ifdef parts, which need to be changed in several .cpp files, here’s an example from MangaConnector.cpp:

  1. #ifdef __LINUX__
  2. wxString MCEntry::invalidFileCharacters = wxT("/\r\n\t");
  3. endif

Something like that needs to turn into this to compile on FreeBSD, otherwise you’ll end up with a HakuNeko that can’t do shit (it’ll still compile and run, but like I said, it’d be devoid of function):

  1. #if defined __LINUX__ || __FreeBSD__
  2. wxString MCEntry::invalidFileCharacters = wxT("/\r\n\t");
  3. endif

This is true for the latest version 1.4.1 as well. I guess the modifications should also apply to other operating systems by adding things like __OpenBSD__ or similar.

Now all that’s left is to wait for that massive 12C battery, the RAM capacity+speed upgrade and some FreeBSD case sticker that I ordered from [] (hint: That’s a referral URL, it’s supposed to give you some $5 coupon upon ordering, I hope it works). Upon my order, a small part was donated to the LLVM project – very fitting, given that I’ve used clang/llvm a lot to compile stuff on FreeBSD as of late. :)

FreeBSD case sticker (preview)

This is what it’s supposed to look like, and it’s going to replace the current Windows XP+Vista sticker

I hope it’ll look as good in real life! :) Ah, I think I’m gonna have a lot of fun with that old piece of junk. ;)

Ah, and thanks fly out to The_Plague, who saved this laptop from the trash bin and gave it to me for free! Prost!

Edit: And the memory is here, two G.Skill “performance” modules doing 4-4-4 latencies at 667MHz data rate, replacing a single Samsung module running 5-5-5. Now I was interested in how much going from single channel CL5 to dual channel CL4 would really affect performance. Let’s just say, it didn’t do too much for CPU processes. However, the effect on the integrated GMA950 GPU (using shared system memory!) was amazing. It seems the graphics chip was held back a lot by the memory interface! Let’s have a quick look at Quake III Arena performance using a quickly recorded demo just for this purpose (ioquake3 can’t play old Quake III Arena demos like the “001” demo):

  • ioquake3 1.36, single channel DDR-II/667 CL5:
  • 30.6fps
  • ioquake3 1.36, dual channel DDR-II/667 CL4:
  • 41.2fps

Roughly +35%!!

Tests were run three times, then three more times after a reboot. After that, an average was taken. For ioquake3 this wouldn’t even have been necessary though, as the results were extremely consistent. It’s amazing how much the added memory speed really affects the game engine! I rebooted and re-ran the tests several times because I couldn’t believe in that massive boost in performance, but it’s actually true and fully reproducible! This reminds me of how well modern AMD APU graphics chips scale with main memory speed and it explains why people were asking for quad-channel DDR4 on those Kaveri APU chips. Its built-in Radeons would’ve probably loved the added bandwidth!

I also kinda felt that browsing web sites got a lot more smooth using Chromium with most of its GPU acceleration turned on. So I tried the graphics-centric browser test [Motionmark] to put that to the test. Parts of the results were inconclusive, but let’s have a look first:

  • Motionmark 1.0 (medium screen profile), single channel DDR-II/667 CL5:
  • Overall result: 13.85 ±22.24%
  • Multiply: 119.26 ±2.95%
  • Canvas Arcs: 19.04 ±68.48%
  • Leaves: 3.00 ±133.33%
  • Paths: 85.30 ±6.57%
  • Canvas Lines: 1.00 ±0.00%
  • Focus: 1.76 ±5.22%
  • Images: 40.58 ±2.56%
  • Design: 18.89 ±8.00%
  • Suits: 24.00 ±37.50%
  • Motionmark 1.0 (medium screen profile), dual channel DDR-II/667 CL4:
  • Overall result: 22.47 ±15.93%
  • Multiply: 124.55 ±1.60%
  • Canvas Arcs: 26.00 ±138.46%
  • Leaves: 65.90 ±16.93%
  • Paths: 37.00 ±16.89%
  • Canvas Lines: 1.00 ±0.00%
  • Focus: 2.00 ±50.00%
  • Images: 41.58 ±3.59%
  • Design: 24.49 ±2.35%
  • Suits: 90.65 ±13.55%

Now first things first: This was just my first pick for any kind of graphics-heavy browser benchmark. I thought I needed something that would make the browser do a lot of stuff on the GPU, given that hardware acceleration was almost fully enabled on FreeBSD UNIX + Chromium + GMA950. However, after repeated runs it showed that the variance was just far too high on the following tests: Leaves, Paths, Suits. Those would also mess up the overall score. The ones that showed consistent performance were: Multiply, Canvas Arcs, Canvas Lines, Focus, Images, Design, so we should focus on those. Well, not all of those tests show promising results (Multiply, Canvas Lines), but some clearly do. It seems my feeling that parts of CSS3 etc. had gotten faster after the memory upgrade was spot-on!

Not bad, not bad at all! And tomorrow morning, the [x264 benchmark] will also have finished, showing how much a classic CPU-heavy task would profit from that upgrade (probably not much, but we’ll see tomorrow).

Edit 2: And here is the rest. Like I thought, the memory upgrade had only minimal impact on CPU performance:

  • x264 benchmark, single channel DDR-II/667 CL5:
  • Runtime: 04:40:08.621
  • x264 benchmark, dual channel DDR-II/667 CL4:
  • Runtime: 04:38:23.851

So yeah it’s faster. But only by a meager +0.62%. Completely negligible. But it’s still a good upgrade given the GPU performance boost and the fact that I can now use more memory for virtual machines. :)

Ah, and here’s the 12-cell ultra capacity battery, which gives me a total of 18 cells in conjunction with the 6-cell primary battery:

Nice hardware actually, you can check it’s charge (roughly) with a button and a 4-LED display, and it has it’s own charging plug. What surprised me most though was this:

$ hwstat | grep -i -e "serial number" -i -e battery
[ACPI Battery (sysctl)]
        Serial number:                  00411 2006/10/12
        Serial number:                  00001 2016/07/29

That probably explains how a still sealed battery could come with a ~25% pre-charge. Manufactured in July 2016, wow. And that for a notebook that’s 10 years old? Ok, it’s an aftermarket battery by [GRS], but that’s just damn fine still! With that I’ll surely have enough battery runtime to make it through longer meetings as well! :)

Edit 3: And today I used the notebook for a sysadmin task, helping our lead developer in debugging a weird problem in a Java-based student exam submission and evaluation system of ours at work. I suspected that the new CuPPIX (=KNOPPIX derivative) distribution I built for this was to blame, but it turned out to be a faulty Java library handling MySQL database access, hence crashing our server software under high parallel loads. In any case, I had the nc6320 with me during the entire morning up until 12:30 or so, walking away with a total charge of 49% left after the developer had fixed the problem. Not stellar given a total of 18 cells, but definitely good enough for me! :)

Edit 4: And my FreeBSD sticker from unixstickers is finally here! They even gave me a bunch of random free stickers to go with it! I gave those to some colleagues for their kids. ;) And here it is:

FreeBSD sticker from

There was a Windows Vista/XP sticker before, now it shows some UNIX love! (click to enlarge)

The sticker shows some pretty good quality as well, nice stuff! :)

Aug 052016

VirtualDimension logoShort story: It’s [VirtualDimension].

Long story… It’s most definitely not what Microsoft added in Windows 10. Besides it being limited to Windows 10, it just sucks for a multitude of reasons. And there I was, having hopes for it as well… If you’ve ever used multiple desktops on a graphical, X11-based Linux or UNIX window manager / desktop environment, you’d know what I’m talking about. Usually, what you’d get on those systems, whether KDE, Gnome, Xfce4, LXDE, or whatever is just one small, configurable panel which allows you to control multiple virtual desktops. On my Gnome 2 on CentOS 6.8 Linux, it looks like this (others are very similar):

Virtual desktops on Gnome 2

Virtual desktops on Gnome 2

The leftmost desktop is my usual “Internet” environment, here I chat, read emails, browse the web for anything work-related and so on. The second one is a Linux distribution development desktop. Here I’m building a derivative of Klaus Knoppers’ [Knoppix] distro. Then comes the testing environment for said distribution on desktop #3. Usually some shells and one VMware Player instance. Next to that are two more VM desktops for software testing and for writing user guides for software installation on different operating systems. At the moment that’s MacOS X and a Windows XP x64 software build VM. Usually there’s also a Windows 7 one. One is empty (for arbitrary stuff), then comes the server administration desktop with 9 open shells, one for each server. And the last one is my private desktop with yet another web browser, and some shells for spawning screen sessions for running software compilations, encoding runs and the likes.

Now, I have a 30″ screen both at home and at work, resolution is 2560×1600. But it’s just never enough screen real estate. So I wanted well-integrated virtual desktops for Windows as well, but last time I tried out some software, I couldn’t find a good one. Recently, I tried again for some reason, like “let’s give this one last shot”. And I tried a lot of programs!

Among the software tested were [Dexpot], [Finestra], [VirtuaWin], [WindowsPager], Xilisoft [Multiple Desktops] and the Windows PowerToy predecessor of [Desktops 2.0] written by Windows Hacker Mark Russinovich and Bryce Cogswell. And finally, [VirtualDimension]. Some of those are free and open source software, others are not.

One of my primary requirements was compatibility to Windows XP x64. Of course it’d be nice if it worked on Windows 10 as well. But most of the above had important features missing or severely misbehaving on XP. Some were just very, very sluggish when switching desktops. Others had missing features to begin with, like previews on the desktop tiles. A blank desktop tile doesn’t help at all, as I need to see roughly what’s running where at a glance.

I’m not gonna make this a lengthy top list or anything, I’m just gonna show you what the software of my choice – VirtualDimension – could do for me, let’s look at the tiles first:

VirtualDimension on XP x64

VirtualDimension on XP x64

We’ll start with my good old XP x64 first. Here you can see my system tray, and Miranda being open. VirtualDimension cannot be embedded into the taskbar properly (damn), but it has an “always on top” feature. Since the contact list in my docked and always-launched Miranda doesn’t go all the way down, there is free and unused space there. Perfect for VirtualDimension! And since it’s always on top, it doesn’t disappear when clicking on Miranda for chatting.

Given the source code is definitely coming from a UNIX or Linux user (given he built it with GCC/Mingw), some features immediately ring a bell. Like “mouse warp”, where you switch desktops by moving your mouse to the border of the screen. I disabled that, don’t like it. But yeah, it’s there.

Important: While it doesn’t give you live window geometry previews, it does give you iconized previews, so you can always identify any desktop quickly by seeing what’s running there. The desktops can also be named, and there is an OSD that you can have pop up on you when switching, like so:

VirtualDimension OSD

OSD showing right after a desktop switch

In this case I had just switched to desktop #2, which is for A/V processing exclusively. This is just the top left part of the screen, where one of my eight transcoding shells was running a x265 benchmark prototype test. Color, display duration, transparency to mouse clicks on the OSD part, font and size are configurable.

Also, you can freely define keyboard shortcuts for switching desktops as well. I chose CTRL+Shift+Right as well as CTRL+Shift+Left for switching desktops and Alt+Right / Alt+Left for pushing a window to the next/previous desktop as those don’t conflict with other shortcuts I’m using.

What else can it do? Let’s right click on one of the icons in the preview tiles:

VirtualDimension iconized window right click

Clicking on a program icon in VirtualDimensions’ preview tiles gives you this menu

The first five options from the top are global ones. However, the ones below are specific to the icon you right-clicked. With “Activate”, you’d switch to the target desktop and put focus on that programs’ window. The others are pretty self-explanatory as well I guess. We also get a graceful “Close” option, and a brutal “Kill” option that’s equivalent to murdering the process in task manager. Maybe useful since it’s faster that way.

And if we click on the free area?

VirtualDimension, right click on the free area of a preview tile

Right-clicking on the free area of a preview tile gives you a list of all programs on that desktop.

Ok, not sure how useful that is, but at least it may help with identifying the windows on a desktop in more detail, as you get the window titles here. For my encoding shells I could get very quick glance at the progress, but not exactly in great detail. So the helpfulness of this is limited.

What else?

Well, it’s extremely fast! That’s one major plus for VirtualDimension, as several of the other solutions (open source ones as well) were abysmally slow, at least on XP x64. But damn, VirtualDimension just flies! And its memory footprint is minimal. I saw less than 12MiB of consumption here. Even if you add a truckload of Desktops (there seems to be no upper limit), it just won’t slow down unless you spawn like 50 CPU intensive processes all over the place killing your CPU or maxing out your RAM. But that wouldn’t have been VirtualDimensions fault then. Its memory footprint will linearly grow by spawning more desktops, so with eight you may see around 20MiB. Still neat.

And what’s bad about it?

Well, sometimes, if you have a lot of windows on one desktop, the icons are’t cut off in the right spot at the bottom of the preview tile, so they overflow just a little bit. Just a cosmetic issue. Also, you should maybe deactivate the shell integration. With this, VirtualDimension hooks itself into all windows (such a DLL hook means entering another processes’ memory area). With that, you can get its functions via right clicking on a windows’ title bar, like on UNIX.

Nice, but dangerous! This can trigger anti-cheat systems in online games, because they really don’t like you stepping into their processes’ memory areas! That’s what cheating tools do to modify a games’ parameters on the fly as well. You don’t wanna be banned because of such a thing!

In my case, I managed to lock myself out of Mechwarrior Online because of this. I wasn’t banned, but the login process wouldn’t even let me launch its window. Disabling the feature, launching MWO, then re-enabling it and trying to log in caused a pretty abnormal process termination:

Mechwarrior Online really doesn't like VirtualDimensions' shell integration feature

Mechwarrior Online really doesn’t like VirtualDimensions’ shell integration feature! And no, there was no “update available”… (click to enlarge)

There is an exception list for this feature, and I added all of MWOs’ .exe files to it, to no avail. Better to stay away from this one.

Now, well, this otherwise beautiful piece of software was dropped by its developer around 2005. About the time my XP x64 came out. Latest alpha build is from some time in 2006. So this is ancient! It even supports Windows 98 and NT 4.0, I mean… So, how about Windows 10 then? I mean, Windows 10 doesn’t even have a GDI UI anymore, this is like one completely different world. Since I do have a Windows 10 machine (yeah, ew), let’s check it out:

VirtualDimension on Windows 10

VirtualDimension on Windows 10 – hey, it really works!?

Miranda seemingly can’t dock properly on Windows 10 anymore. It kinda… floats near the desktop border when docked. It’s strange and it wastes space, but well, I don’t know how to fix that yet. But anyway, I embedded VirtualDimension into Miranda (by just moving the window there, removing its title bar and resizing it properly again). And guess what?

It just works™!

I launched some Metro / Modern UI apps in a window as well, and while those aren’t shown in the preview tiles, they can be controlled with keyboard shortcuts, just like regular windows. Also, it’s just as blazing fast as it is on XP. Ah, and… yeah, it actually does work on all 64-bit x86 Windows versions it seems! It’s amazing, but an ancient piece of 32-bit software that does alter a Windows systems’ usage pattern quite fundamentally still works fine on Windows 10 64-bit. I gotta say, I’m pretty relieved, because Windows 10s’ own solution just sucks – where is my live preview? – and I don’t want to change my usage paradigm too much when switching operating systems (even from Linux/UNIX to Windows and back).

Some of the other solutions like Dexpot or Finestra may be faster on Windows 10 then they are on a just half-supported XP x64, but nah, don’t need them.

VirtualDimension is as perfect as it gets, despite its age! Or maybe because of it?

Still, anyone interested in picking up that [VirtualDimension project on SourceForge] and in continuing its development? ;) I guess I can’t touch that code, would probably just mess everything up. Ah, it’s C++ by the way…

A few things could use some fixing, like the icon overflowing issue, Modern UI window detection, certain, rare windows being sticky on all Desktops even if nobody told them to do so (Miranda, X-Chat DCC windows) and that exclusion list for the shell integration, which doesn’t hook into all windows properly when active either anyway.

Would be so nice if somebody could continue working this! :)

Until that happens (I know, it never will), I’ll just continue using v0.95 alpha. ;)

Jun 032016

H.265/HEVC logoAnd here’s another x265 build for Windows XP and Windows XP x64, following [1.9+141]. As usual, these work on modern versions of Windows just as well. Again, built with Microsoft Visual Studio 2010 SP1 and tested for correct encodes for 8-bit, 10-bit and 12-bit color depth. The 8-bit test has been done using the x86_32 version, the 10- & 12-bit tests has been done with the x86_64 version. I’m not running complicated test suits on this, just a simple encode with manual output checking.

Here is the software for 32-bit and 64-bit systems:

As usual, the builds depend on the Microsoft Visual C++ 2010 runtime which you can download from Microsoft [for 32-bit systems] and [for 64-bit systems] if you don’t have it already.

This time around, it’s a pure binary release, giving you the x265.exe and libx265.dll. I think I’m gonna keep it that way. It’s meant for users, not developers anyway.

I’m thinking I might create a project page for this, so that all releases get consolidated on a single spot, that’d probably better than creating a new post for each and every build I’m pushing out. If I’m gonna do that, links to it will be added to each post regarding information about how to build x265 for WinXP+, and also to all binary release posts.

Such a page could also give you an avconv release on the spot, so you can work with all kinds of video input to your liking, given that x265 can only accept raw YUV video by itself. Just need to build a 32-bit version of libav as well then.

Oh well, have fun! :)

Update: All x265 releases have now been consolidated on [this page]! All future XP- and XP x64-compatible releases of x265 plus a relatively recent version of avconv to act as a decoder for feeding x265 with any kind of input video streams will be posted there as well.

Apr 192016

H.265/HEVC logoLike I said, I’ll keep doing these. Following version [1.9+108], here comes another build of the x265 encoder for Windows XP+ and Windows XP x64/Server 2003 x64+, this time it’s version 1.9+141. I’m not sure for how long the developers at Multicoreware are going to keep up support for NT 5.1/5.2 based operating systems, but for as long as they do, I’ll keep releasing builds for the old MS operating systems. Just keep in mind that I’m not running automated build & test systems, so I’m going to release selected binaries every 1-2 months or so. If you need a specific version, please just request it (or try and build it yourself, see previous posts).

Whenever Multicoreware does drop support I’ll still continue as long as it’s easily patchable. We can’t be sure of anything though, they’ve dropped deep color support (10-bit/12-bit per color channel) on 32-bit x86 platforms before, so…

Well, here is 1.9+141:

Once more, this has been built with Microsofts’ VisualStudio 2010 SP1 + yasm 1.3.0, and tested doing a 2-pass encode & quick output video verification for all color depths. Requires the MS VC++ 2010 runtime, you can get it here: [32-bit version], [64-bit version].

Feb 122016

H.265/HEVC logo1.) Giving you the binaries:

Just recently I tried to give the x265 H.265/HEVC video encoder another chance to prove itself, because so far I’ve been using x264, so H.264/AVC. x264 does a really good job, but given that the marketing guys are talking about colossal efficiency/quality gains with H.265, I thought I’d put that to the test once again. It was quite easy to compile the software on my CentOS 6.7 Linux, but my old XP x64 machine proved to be a bit tricky.

But, after a bit of trial and error and getting used to the build toolchain, I managed to compile a seemingly stable version from the latest snapshot:

x265 cli, showing the version info

x265 cli, showing its version info.

Update 2: And here comes my first attempt to build an x86_64 multilib binary, that can encode H.265 at 8-bit, 10-bit and 12-bit per pixel color depths. You may wish to use this if you need more flexibility (like using 12-bit for PC only and 8- or 10-bit for a broader array of target systems like TVs, cellphones etc.). It’s currently still being tested for a short encoding run. You can specify the desired color depth with the parameter -D, like -D 8, -D 10 or -D 12:

Update: And here are the newer 1.9 versions, built from source code directly from the [MulticoreWare] (=the developers) servers. I haven’t tested these yet, but given that I configured & compiled them in the same way as before, they “should work™”:

And the old 1.7 versions from the Videolan servers:

So this has been built with MSVC10 and yasm 1.3.0 on Windows XP Pro x64 SP2, meaning this needs the Microsoft Visual C++ 2010 runtime. You can get it from Microsoft if you don’t have it yet: [32-bit version], [64-bit version]. v1.7 tested for basic functionality on XP 32-bit and tested for encoding on XP x64. The 32-bit version only supports 8-bit per pixel, which is default for x264 as well. The 64-bit versions support either 8-, 10- or 12 bits per pixel. Typically, higher internal precision per pixel results in finer gradients and less banding. 8-/10-bit is default for H.265/HEVC. 12-bit will likely not be supported by any hardware players, just as it was with 10-bit H.264/AVC before.

You may or may not know it, but as of now, x265 cannot be linked against either ffmpeg or libav, so it can only read raw input. To “feed” it properly you need either a frame server like [AviSynth] in combination with the pipe tool [Avs4x265], or a decoder that can pipe raw YUV to x265. I went for the latter version, because I already have libav+fdkaac compiled for Windows to get the avconv.exe binary. It’s quite similar to ffmpeg.

This I can only provide as a 64-bit binary, as I’m not going to build it for 32-bit Windows anytime soon I guess, so here you go:

This was compiled with GCC 4.9.2 and yasm 1.3.0 on CygWin x64. To use the two together, add the locations of your EXE files (avconv.exe and x265.exe) to your search path. Then, you can feed arbitrary video (VC1, H.264/AVC, MPEG-2, whatever) to x265. An example for a raw H.264/AVC input stream using the 64-bit versions of the software:

avconv -r 24000/1001 -i video-input.h264 -f yuv4mpegpipe -pix_fmt yuv420p - 2>NUL |^
 x265 - --wpp --y4m -D 12 -p slower --bframes 16 --bitrate 2000 --crf 18 --sar 1^
 --range full -o video-output.h265

Or another, reading some video stream from an MKV container, disabling audio and subtitles:

avconv -r 24000/1001 -i video-input.mkv -f yuv4mpegpipe -pix_fmt yuv420p -an -sn^
 - 2>NUL | x265 - --wpp --y4m -D 12 -p slower --bframes 16 --bitrate 2000 --crf 18^
 --sar 1 --range full -o video-output.h265

Just remove the carets and line breaks to make single-line commands out of those if preferred. To understand all the options, make yourself some readmes like this: avconv -h full > avconv-readme.txt and x265 --log-level full --help > x265-readme.txt or read the documentation online.

2.) How to compile by yourself:

2a.) Prerequisites:

I won’t describe how to build libav here, but just the x265 part. First of all, you need some software to be able to do this, some of it free, other not so much (unless you can swap MSVC with MSYS, I didn’t try that):

  • [cmake] (I used version 2.8.12 because that’s roughly what I have on Linux.)
  • [Mercurial] (Needed to fetch the latest version from x265′ versioning system. I used the latest Inno Setup installer.)
  • [yasm] (Put yasm.exe in your search path and you’re fine. This is optional, but you really want this for speed reasons.)
  • [Microsoft Visual Studio] (Use 2010 if you’re on Windows XP. Supported versions: 2008/VC9, 2010/VC10, 2012/VC11 & 2013/VC12)
  • [x265 source code] (Enter a target download path and use Mercurials hg.exe like hg clone to fetch it)

2b.) Preparation of the solution:

Usually, you would use cmake to have it compile your entire project, but in this case it’ll build Visual Studio project files and a solution file for us. To do this, enter the proper build path. In my case I’m using Visual Studio 2010, so VC10, and I’d like to build the 64-bit version, so with the unpacked x265 source, I’d enter its subdirectory build\vc10-x86_64\ and then run the generation script: .\make-solutions.bat:

make-solutions.bat preparing cmake for us

make-solutions.bat is preparing cmake for us.

There are several things you need to make sure here: First, if you’re on Windows XP or Windows Vista, you need to toggle the WINXP_SUPPORT flag. Also, if you’re compiling for a 64-bit target, you may wish to enable HIGH_BIT_DEPTH as well to get to either 10-bit or even 12-bit per pixel other than just 8. The 32-bit code doesn’t seem to support high bit dephts right now.

Then there is one more important thing; With CMAKE_CONFIGURATION_TYPES set to Debug;Release;MinSizeRel;RelWithDebInfo, my build was unstable, throwing errors during encoding, like x265 [error]: scaleChromaDist wrap detected dist: -2029735662 lambda: 256. Setting CMAKE_CONFIGURATION_TYPES to just Release solved that problem! So you may wish to do the same.

Make sure ENABLE_CLI and ENABLE_ASSEMBLY are checked as well, then click Configure. If you’re building with high bit depth support, you’ll be presented with another option, MAIN12. You should enable this to get Main12 profile support in case you’re planning to build a 12-bit encoder. If you don’t pick it, you’ll get a 10-bit version instead, staying within Blu-Ray 4K specifications. After that, click Configure again. Generally, you need to click Configure unless no more red stuff pops up, then click Generate.

2c.) Compiling and installing the solution:

Load the resulting solution file x265.sln into Microsoft Visual Studio, then right click ALL_BUILD and pick Build. This will compile x265. If you want to install it from the IDE as well, right click INSTALL and select Build. This will install x265 in %PROGRAMFILES%\x265\ with the binary sitting in %PROGRAMFILES%\x265\bin\:

Microsoft Visual Studio 2010, ready to compile the x265 solution generated by cmake

Microsoft Visual Studio 2010 with the x265 solution generated by cmake loaded, compiled and installed.

3.) Running it:

Now we can feed x265 some raw YUV files like this, after adding x265.exe to the search path:

x265 encoding a raw YUV file to H.265/HEVC

x265 encoding a raw YUV 4:2:0 file to H.265/HEVC (The options given to x265 may actually suck, I’m still in the learning process).

Or we can use a decoder to feed it arbitrary video formats, even from MKV containers, like shown in the beginning. ffmpeg or avconv can decode pretty much anything, and then pipe it into x265 as raw YUV 4:2:0:

x265 being fed a H.264/AVC bitstream by avconv

x265 being fed a H.264/AVC bitstream by avconv.

And that’s it! Now all I need is some 18-core beast processor to handle the extreme slowness of the encoder at such crazy settings. When going almost all-out, it’s easily 10 times as slow as x264 (at equally insane settings)! Or maybe I can get access to some rack server with tons of cores or something… :roll:

Update: All x265 releases have now been consolidated on [this page]! All future XP- and XP x64-compatible releases of x265 plus a relatively recent version of avconv to act as a decoder for feeding x265 with any kind of input video streams will be posted there as well.

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

Jun 272015

Corsair Logo #2This is just a minor update after [part 2], but anyway. My old workstation (the one I’m migrating away from) just broke down a few days ago, so I had to do something, and quickly. Since I still don’t have any disks for my new RAID-6, I had to pull the existing RAID array from my old box and attach it to my new workstation in a hurry. It does look quite ugly too, with the RAID lying around on the table beside an open Lian Li PC-A79B. This is not how it was supposed to be, but well… In the meantime I found out that it was my Tagan Piperock 1300W power supply which broke down (Built by Topower by the way). Sad, because I liked it for its sturdy metal screw-on modular plugs, but well. So the machine now sits in its final location, it just doesn’t look too good at the moment:

"Helios" RAID-6 array emergency migration

Now the new machine has to host the old “Helios” RAID-6 array. Not quite as planned (click to enlarge).

In any case, I wanted to play around with that new Corsair “Professional Series Platinum AX1200i” of mine, which is a fully digital power supply unit featuring an I²C port. With that, you can hook it up to Corsairs Link [Commander], or you can use the dongle provided with the unit and hook it up to an internal USB header on your mainboard. Here’s a crop of a photo previously shown, this is the dongle:

The Corsair Link dongle

The Corsair Link dongle.

Now what this actually is, is a [Silicon Labs] – or Silabs in short – I²C to [USBXPress] bridge chip. So it’s not using the same USB HID device class of the Link Commander, but a completely different protocol, which is also why we’re tied to using the Corsair Link software. The free software project [CorsairLinkPlusPlus] won’t work with it at all as it supports only the Link Commander itself.

Having said that, I can’t use the Corsair Link software – which uses .Net 4.5 – on XP x64, it just won’t work on the old OS. The drivers that come with the device though are from Silabs and DO support XP and XP x64. The USB vendor ID was changed from Silabs to Corsair though, so it’s not 10CE:1C00, but 1B1C:1C00, making it impossible to install original Silabs drivers. But that’s ok, what Corsair’s shipping with the power supply works just as well.

You may not wish to install the whole Corsair Link software on XP just to get the drivers though. So I have isolated the drivers from the package for you to install them separately. The Hydro water cooler driver is also provided, but you don’t need it if it’s just for a power supply like in my case:

But, while you can install the dongle, you can’t talk to it, lacking the userland software for that. Now when I said “how to run Corsair Link on XP x64” in the title, I have to admit I was lying a bit. Because what I did was to virtualize the dongle using Oracle VirtualBox 4.2.26 and then run the Corsair Link software on a Windows 7 x64 virtual machine. Now, before launching that, the XP x64 host systems device manager will show this:

Corsair/Silabs dongle installed on XP x64

Corsair/Silabs dongle installed on XP x64.

Just so it’s handled automatically for every boot of my Windows 7 VM, I created a USB device filter in the virtual machines’ settings:

VirtualBox Corsair Link Filter

VirtualBox USB filter for the Corsair Link dongle.

Now when you start up the VM, VirtualBox will grab the device and replace it with a device called “VirtualBox USB”, thus making it unavailable on the host machine. Just install Corsair Link in the VM, and everything will work nicely:

Corsair Link, virtualized

With the USBXPress dongle virtualized properly, we can run Corsair Link on a Windows 7 VM, controlling the host machines’ power supply (Click to enlarge).

Many have described the software as buggy and crappy, but for me it gets the job done. All I wanted was to change the behavior of the unit, disabling its passive mode at low loads. While a nice feature, the internal thermal probe reports temperatures of up to 60°C at 300W load with the fan sitting still, and I don’t quite like that. I don’t see why it is needed to artificially accelerate the aging process of the PSUs electrolytic capacitors like that, so I set the fan speed to 40%, resulting in slightly short of 800rpm. Very silent, and good enough even for high loads. I now get down to 28-35°C depending on ambient temperatures without perceiving any additional noise. It may reach 40°C on really hot days I guess, but that’s a lot better than 60°C.

Just sad that we can’t define a complete custom fan curve for this unit, based on load or temperature readings. It’s possible with system fans when working with the Link Commander, but not for this one.

Naturally, virtualization also works if you’re on Linux or BSD UNIX or Solaris or whatever. It’s cumbersome, yes, but if you need it only to tell the PSUs firmware to keep the fan spinning, it’s ok. You don’t need to keep the software running, that’s the sweet part. The settings will be stored in the power supplys’ firmware directly.

Only downside is: You need a Windows Vista/7 or newer license for that of course. But maybe we’ll see some free software in the future, people are working on it, that much’s for sure!

Now let’s hope part 4 of this log will be my new hard disks, because I’m really starting to run low on disk space already…

Edit: Part 4 should now be ready, because my new 6TB SAS drives are here. However, instead it turned out to be quite the disaster, which is why [it’s part 3½ instead]. There are some preliminary benchmarks for you to see however, at least something. ;)