The GAT at XIN.at – GrandAdmiralThrawns technology (or whatever this is right now) weblog at XIN.at. Incompatibility is weakness!

Tag folders by right clicking with a cascaded context menu on Windows (XP, too)

Media, Scripting, Windows No Responses »

Sep 222017

[1] 1. Introduction

Note: A more step-by-step guide is to be found farther below, see point 5.!

Recently, [Umlüx] has reminded me of his idea to be able to (visually) tag folders on Windows for specific purposes. For convenience, it’s supposed to work by right-clicking a folder in Windows Explorer, opening a submenu from the context menu, and then by picking the proper tag. After that, the folder icon should change, indicating that something’s special about this one. Windows can actually do the “tagging” part by itself using desktop.ini files, but manually writing them is a pain of course, hence the right-click idea.

The thing is, there already are tools to address folder tagging on Windows, but they’re often not feature complete, have limited XP compatibility or they lack very important features like timestamp preservation. Others have that last part, but only in paid versions of their software. So, time to do it by ourselves!

I picked his Powershell code up, and while it would run on my ancient XP x64 machines, implementing the required menu structure proved to be impossible, especially the cascading part. Ah, let me just show you the final product first, so you know what it was that I wanted (in my case, it’s meant for tagging media folders):

“Changeicon” context menu (click to enlarge)

2. Creating the menu structure (XP + Vista compatible)

Starting with Windows 7, Microsoft introduced a new way to create submenus in the context menu, including icons, all in the Windows Registry. Older versions of Windows like Vista or XP however can’t do that, and I wanted a solution that works on all of them, from XP to Win10. So how can programs like 7-zip create such Explorer submenus with icons on legacy systems? They do so by injecting a COM .dll into the graphical shell, extending its capabilities. Typically, those are written in C++, and that’s not something I want to or can even do.

Luckily, we don’t have to develop that by ourselves, as somebody has already done it: Meet the [KuShellExtension]!

KuShellExtension – or KuShellExt in short – is a set of two library files, KuShellExtension.dll as well as KuShellExtension64.dll, the latter being meant for 64-bit Vista machines. It’s compiled for NT 5.2 though, so it’ll also work on XP x64 and Server 2003 x64. On top of that, it still works even on Windows 10! With the libraries comes an XML configuration file and some simple installer/uninstaller shell scripts.

In the example we’ve seen in the screenshot above, the respective configuration in config.xml would look like this:

expand/collapse source code

```
<?xml version="1.0" encoding="utf-8"?>
```
```
<config version="1">
```
```
 
```
```
  
```
```
  <var name="LEGACY_STYLE">false</var>
```
```
  <var name="HIDE_MISSING">false</var>
```

  <var name="ICON_DIR">${var:APPDATA}\changeicon\icons\</var>

  <var name="INSTALL_DIR">${var:APPDATA}\changeicon\bin\</var>

```
 
```
```
  
```
```
 
```

  <menu name="Tag Folder" class="folder" icon="${var:ICON_DIR}MainIcon.ico">

```
    
```

    <menuitem name="Tag as &quot;Currently watching&quot;" class="folder" icon="${var:ICON_DIR}CurrentlyWatching.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;CurrentlyWatching&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Ongoing release&quot;" class="folder" icon="${var:ICON_DIR}WorkInProgress.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;WorkInProgress&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Freshly completed&quot;" class="folder" icon="${var:ICON_DIR}NewlyCompleted.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;NewlyCompleted&quot;

```
    </menuitem>
```

    <menuitem name="----"></menuitem> <!-- Separator -->

    <menuitem name="Tag as &quot;Favorite&quot;" class="folder" icon="${var:ICON_DIR}Favorite.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;Favorite&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Top series&quot;" class="folder" icon="${var:ICON_DIR}Star.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;Star&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Keep an Eye on for later (High priority)&quot;" class="folder" icon="${var:ICON_DIR}KeepAnEyeOnHighPrio.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;KeepAnEyeOnHighPrio&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Keep an Eye on for later&quot;" class="folder" icon="${var:ICON_DIR}KeepAnEyeOn.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;KeepAnEyeOn&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Keep an Eye on for later (Low priority)&quot;" class="folder" icon="${var:ICON_DIR}KeepAnEyeOnLowPrio.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;KeepAnEyeOnLowPrio&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Not interested&quot;" class="folder" icon="${var:ICON_DIR}NotInterested.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;NotInterested&quot;

```
    </menuitem>
```

    <menuitem name="----"></menuitem> <!-- Separator -->

    <menuitem name="Tag as &quot;Fluff&quot;" class="folder" icon="${var:ICON_DIR}SweetFluff.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;SweetFluff&quot;

```
    </menuitem>
```

    <menuitem name="Tag as &quot;Sweet, sweet Yuri!&quot;" class="folder" icon="${var:ICON_DIR}Yuri.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;Yuri&quot;

```
    </menuitem>
```

    <menuitem name="----"></menuitem> <!-- Separator -->

    <menuitem name="Tag as &quot;A/V main folder&quot;" class="folder" icon="${var:ICON_DIR}AVMain.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;AVMain&quot;

```
    </menuitem>
```
```
    <menuitem name="----"></menuitem>
```

    <menuitem name="Remove tag" class="folder" icon="X:\icons\Trash.ico" action="execute" console="false" multiple="N" workdir="C:\">

      wscript &quot;//B&quot; &quot;//Nologo&quot; &quot;${var:INSTALL_DIR}changeicon.vbs&quot; &quot;%1&quot; &quot;del&quot;

```
    </menuitem>
```
```
  </menu>
```
```
</config>
```

As you can see, it defines the main menu with its icon and then several submenu entries with their own icons. Also, it’s not calling my modified version of Umlüx’ Powershell script, but a Visual Basic Script instead. The reason for this shall be explained in point 4., for now we only care about the menu structure.

Looking at the variables defined on top of the XML data, ICON_DIR and INSTALL_DIR, they reference an icon folder and a program folder, both in %APPDATA%\changeicon\, so I put that into the current users’ profile folder. The icons to be used have to be put into the ICON_DIR, the scripts and an unlocker program are to be put into INSTALL_DIR. That doesn’t affect KuShellExt itself though, you can install that anywhere.

Note that while KuShellExt is loaded, you can edit its configuration on the fly. The library will detect changes made to it, and reload the updated configuration automatically, so you don’t have to unload and load the .dll when making changes to the menus or icon names.

Now, we still need the scripts and [Unlocker 1.9.2] (this is just the .exe, without the adware that usually comes with version 1.9.2). As to why Unlocker is required, well, let’s talk about that and also give you the first script:

3. The timestamp issue and the Powershell script that does the tagging

Note: Windows XP or Vista users may have to install the Windows Management Framework Core package (including Powershell 2.0) first.

This whole solution will alter folder appearances by placing hidden desktop.ini files into them. Writing such a file will alter the folders’ modification time though, or in short it’s “mtime”. And that’s bad if you have software that relies on that piece of meta data. One typical example would be backup software, that decides whether files have to be backupped based on the mtime.

In my own case, the backup problem applies to my rsync backup system, but there’s even more; I’ve written myself a Perl script that walks through my entire video folder, generating an HTML report out of the data, sorted by “latest first”. That way, I can see what movies or series have been added or modified recently. That script also depends on the mtime, so having it change when tagging folders is not acceptable!

Time to look at Umlüx’ script, or rather my modified version of it, changeicon.ps1:

changeicon.ps1, expand/collapse source code

# Change Icon v0.815 Karl Veratschnig 2017

```
# Modified by Michael Lackner
```
```
#
```

# Licensed under the GNU General Public license version 3.0 with express

```
# permission by Karl Veratschnig.
```
```
#
```
```
# usage: 
```
```
# .\changeicon.ps1 *dir_path* *icon*
```

# i.e. ./changeicon.ps1 c:\testfolder Favorite

```
#
```
```
# run from anywhere:
```

# Powershell.exe set-executionpolicy remotesigned -File "path to ps1"

```
#
```

# use "del" icon to revert folder to normal

```
 
```
```
###
```

# Update-ExplorerIcon refreshes icons in Windows Explorer by rebuilding its icon cache

```
# Written by Idera,
```

# http://community.idera.com/powershell/powertips/b/tips/posts/refreshing-icon-cache

```
###
```
```
function Update-ExplorerIcon {
```
```
  [CmdletBinding()]
```
```
  param()
```
```
 
```
```
  $code = @'
```

  private static readonly IntPtr HWND_BROADCAST = new IntPtr(0xffff);

  private const int WM_SETTINGCHANGE = 0x1a;

  private const int SMTO_ABORTIFHUNG = 0x0002;

```
 
```

  [System.Runtime.InteropServices.DllImport("user32.dll", SetLastError=true, CharSet=CharSet.Auto)]

  static extern bool SendNotifyMessage(IntPtr hWnd, uint Msg, UIntPtr wParam,IntPtr lParam);

```
 
```

  [System.Runtime.InteropServices.DllImport("user32.dll", SetLastError = true)]

  private static extern IntPtr SendMessageTimeout ( IntPtr hWnd, int Msg, IntPtr wParam, string lParam, uint fuFlags, uint uTimeout, IntPtr lpdwResult );

```
 
```

  [System.Runtime.InteropServices.DllImport("Shell32.dll")]

  private static extern int SHChangeNotify(int eventId, int flags, IntPtr item1, IntPtr item2);

```
 
```
```
  public static void Refresh() {
```

    SHChangeNotify(0x8000000, 0x1000, IntPtr.Zero, IntPtr.Zero);

    SendMessageTimeout(HWND_BROADCAST, WM_SETTINGCHANGE, IntPtr.Zero, null, SMTO_ABORTIFHUNG, 100, IntPtr.Zero);

```
  }
```
```
'@
```

  Add-Type -MemberDefinition $code -Namespace MyWinAPI -Name Explorer

```
  [MyWinAPI.Explorer]::Refresh()
```
```
}
```
```
 
```
```
###
```
```
# User-configurable block
```
```
###
```

$iconpath = "$env:APPDATA\icons\"           # Where icon files reside

$installpath = "$env:APPDATA\bin\"          # Where scripts & binaries reside

$unlocker = "unlocker.exe"                  # Name of the handle unlocker to use

$ulparams = "/S"                            # Unlock parameter to supply to the unlocker

```
 
```
```
###
```

# Non-user-configurable block / main program

```
###
```

$folder = Get-Item $args[0]                 # Get folder from arguments

& $installpath$unlocker "$folder" $ulparams # Remove open handles from folder

                                            # WARNING: If files inside *are* open in

                                            # other programs, their behavior might

                                            # become unstable. Data loss is possible!

$icon = $args[1]                            # Get icon name from arguments

$olddate = $folder.LastWriteTime            # Get modification time stamp (mtime)

$folder.attributes="Normal"                 # Reset folder attributes

if (Test-Path "$folder\desktop.ini") {      # Check for existing desktop.ini

  & $installpath$unlocker "$folder\desktop.ini" $ulparams # Unlock it, just to make sure

  Remove-Item "$folder\desktop.ini" -Force    # Delete it if present

```
}
```

if($icon -ne "del") {                       # If op is to tag, not to delete...

  $stream = [System.IO.StreamWriter] "$folder\desktop.ini" #... build new desktop.ini

  $stream.WriteLine("[.ShellClassInfo]")            # Category

  $stream.WriteLine("IconFile=$iconpath\$icon.ico") # Icon file

  $stream.WriteLine("IconIndex=0")                  # Icon #0 in file

  $stream.WriteLine("Infotip=$icon")                # Info tip set to icon name

  $stream.WriteLine("ConfirmFileOp=0")              # Disable special folder handling

  $stream.WriteLine("TimeStamp=$olddate")           # Remark time stamp in the file for

                                                    # safety/recovery purposes

  $stream.close()                                   # Close file

  $folder.attributes="ReadOnly"                     # Set folder to RO to enable special

                                                    # desktop.ini handling

  (Get-Item "$folder\desktop.ini").attributes = "Hidden,System" # Set desktop.ini

                                                    # attributes to Hidden+System, also

                                                    # to enable special folder handling

} else {                                    # If op is to delete, not to tag...

  if (Test-Path "$folder\desktop.ini") {      # Check whether desktop.ini really exists

    & $installpath$unlocker "$folder\desktop.ini" $ulparams # Unlock it, just to make sure

    Remove-Item "$folder\desktop.ini" -Force    # Delete it if present

```
  }
```
```
}
```
```
 
```

Update-ExplorerIcon # Rebuild Windows Explorers' icon cache

```
 
```

Start-Sleep -s 2    # This is to work around a race condition against writes/flushes on

                    # some systems, so we give the system a little bit of time for its

                    # "beauty sleep" before resetting the mtime.

```
 
```

$folder.LastWriteTime = Get-Date $olddate   # Reset original mtime stamp

As you can see, the mtime is first being read from the folder by using $folder.LastWriteTime, and then reset to that value after writing the desktop.ini to the target directory. Also, it calls unlocker.exe /S on that folder to unlock it first, no matter whether there are open files within that folder or anything. This is done to avoid the dangerous situation, where the code would write the desktop.ini, but would then fail to update the folders’ timestamp due to open handles on the directory. Often this would also be caused by Windows Explorer itself, especially if you have open subfolders when tagging.

Forcefully unlocking the folder first deals with that problem. Please keep in mind that doing this may make programs relying on their open handles to behave in an undefined way however. Loss of data in that folder could be possible, e.g. if a text editor loses its handle for writing to a file in that folder.

In case something still goes wrong, the mtime is also being remarked in the desktop.ini file, in the value TimeStamp.

Here’s a sample .ini, as generated by changeicon, the format of the timestamp depends on your locale:

```
[.ShellClassInfo]
```

IconFile=C:\Documents and Settings\USERNAME\Application Data\changeicon\icons\WorkInProgress.ico

```
IconIndex=0
```
```
Infotip=WorkInProgress
```
```
ConfirmFileOp=0
```
```
TimeStamp=09/22/2017 08:59:08
```

Now, there is one cosmetic issue left here…

4. Hiding that ugly terminal window

You can try to hide the window that pops up when calling a Powershell script, but it never really works reliably. So, are we going to tolerate that thing popping up every time we tag a folder? As if! That’s where the VBScript code comes in. This is an old trick I’ve used to run cmd batch scripts in a hidden way before, and this also works for calling Powershell scripts. I call this changeicon.vbs:

changeicon.vbs, expand/collapse source code

' Declare variables and create shell object:

Dim AppData, WinDir, PowerShell, arg0, arg1

Set WshShell = Wscript.CreateObject("WScript.Shell")

```
 
```
```
'''
```

' User-configurable part (file/folder locations)

```
'''
```

AppData = wshShell.ExpandEnvironmentStrings("%APPDATA%")

WinDir = wshShell.ExpandEnvironmentStrings("%WINDIR%")

PowerShell = WinDir & "\system32\WindowsPowerShell\v1.0\powershell.exe"

```
 
```
```
'''
```
```
' Non-user-configurable part
```
```
'''
```

' Pull command line arguments into variables:

```
arg0 = WScript.Arguments.Item(0)
```
```
arg1 = WScript.Arguments.Item(1)
```
```
' Execute program:
```

WshShell.Run """" & PowerShell & """ """ & "-File" & """ """ & AppData & "\changeicon\bin\changeicon.ps1" & """ """ & arg0 & """ """ & arg1 & """", 0

```
Set WshShell = Nothing
```

5. Actually running that Frankenstein solution

In essence, you need to do the following:

Pick a folder for changeicon.ps1, changeicon.vbs and unlocker.exe, and put those three files into it.
Pick a folder for your icons, and place all your desired icons into it, no subfolders!
Edit changeicon.ps1 and changeicon.vbs and change the install/icon paths.
Install KuShellExtension and run its DLL hook script install.cmd.
Edit KuShellExts’ settings.xml to reflect your menu structure and the corresponding menu icons and commands to execute. Better don’t delete all the comments in that file, the documentation can be pretty helpful at times.

Unfortunately I can’t share the icons I’ve created because they’re based on Microsofts’ icons, but you can easily find icons online or make your own with Microangelo or IcoFX. Both are commercial software for Windows, but you could also use the Gimp for that.

6. Enjoy tagging folders

Folders tagged with changeicon

With that, it’s much, much easier to keep track of things and to not forget what kind of stuff (*cough* tons of Anime *cough*) I still need to watch or keep an eye on for later.

But it’s not limited to that; You could use tagged folders for pretty much anything, like designating them to specific purposes or use them for document or work classification, whatever.

It’s interesting that even Windows 10 still can’t do that via the GUI by default by now…

Anyway, thanks fly out to [Umlüx] for writing the most important part at the core of this mess, the Powershell script, and also to [Idera] for the icon refreshing code I grabbed from their site! Also, if you want Umlüx’ modern solution for Windows 7+, which is based on pure Powershell code and Registry entries, you’d need to contact him directly. You may wish to do so, if you don’t need XP or Vista, because then you wouldn’t need to rely on the KuShellExtension anymore.

Happy tagging!

[1] Logo based on the Windows 10 Custom Folder Icons Pack made by Terraromaster

How to unlock the full GPU & 3D potential of Adobe Photoshop CS6 Extended under Windows XP x64

Graphics Cards, Powerful Tools, Windows 4 Responses »

Aug 182017

1. Introduction

While I’ve been a Corel Photopaint user for about 20 years now (!), I’ve recently bought myself a license for Adobe Photoshop CS6 Extended, simply because I’ve hit some memory and stability limitations with Corel’s solution when working with very large files (A0 @ 300dpi) and lots of objects (=”layers”), sometimes hundreds of them. Generally, Photopaint tends to become unstable as you keep working with very large files, and things like masks or object copies start failing silently even well before its 32-bit address space is exhausted. Well, Adobe Photoshop CS6 was the last standalone version without relying on the “Creative Cloud” and the last that would work on Windows XP / XP x64, even in its 64-bit version on the latter. So there you have it. I was thinking of migrating.

2. Licensing woes

The first thing that really got on my nerves was Adobes’ licensing system. In my version of CS6, Adobes’ application manager just wouldn’t talk to the activation servers anymore and offline activation is broken as well, as the tool won’t generate any request codes for you (the option just isn’t there anymore). Why is this? During testing I found that Microsofts’ ancient Internet Explorer 8 – the latest on XP – can’t talk to certain activation servers via encrypted connections any longer. I guess Adobe upgraded SSL on some of their servers.

My assumption is that the Adobe application manager uses IEs’ browsing engine to connect to those servers via HTTPS, which fails on anything that isn’t Vista+ with a more modern version of Internet Explorer.

So? I was sitting there with a valid license, but unable to activate the software with it. It’s sad, but in the end, I had to crack Photoshop, which is the one thing I didn’t want to do. Even though Photoshop CS6 officially supported XP, it can no longer be activated on such old operating systems, and nobody cares as it’s all deprecated anyway. It’s annoying, but there was no other choice but to remove the copy protection. But hey, my conscience is clean, I did buy it after all.

3. Language woes

Well, I bought a German version of Photoshop. Which I thought was ok, as Adobe would never do something as stupid as to region-lock their licenses, right? Riiight? [Wrong]. You have to download the [correct version] for your region, or the license won’t work. I mean, German is my native language, but I’m using operating systems and software almost exclusively in English, so that was unacceptable. Thankfully, there is an easy fix for that.

First: Close Photoshop. Then, let’s assume you’ve installed it in the default location. If so, enter the folder %PROGRAMFILES%\Adobe\Adobe Photoshop CS6 (64 Bit)\Locales\de_DE\Support Files\ (swap the de_DE\ part with your locale, you’ll find it in that Locales\ folder). There you’ll find a .dat file, in my case it was called tw10428.dat. Rename it to something like tw10428.dat-backup. Relaunch Photoshop. It’ll be English from now on[1]!

4. The hardware I used for testing

This is important, as some features do depend on certain hardware specifications, like 512MiB of VRAM on the graphics card or certain levels of OpenGL and OpenCL support, those kinds of things. So here’s the hardware, which should be modern enough for CS6:

Intel Xeon X5690 3.46GHz hexcore with HT (Westmere architecture, think “Core i7 990X”)
48GiB of RAM
nVidia GeForce GTX Titan Black 6GiB (Kepler architecture, somewhat similar to a GeForce GTX 780Ti)

Also, the driver used for the Titan Black is the latest and last one available for XP, 368.81. It even gives you modern things like OpenGL 4.5, OpenCL 1.2 and CUDA 8.0:

nVidia control panel for driver 368.81 on XP x64

5. What it looks like without any compatibility hacks

However, even though the 64-bit version of Photoshop CS6 runs on Windows XP x64 (when cracked ), a few things are missing regarding GPU support and 2D/3D acceleration. Let’s launch the application:

Photoshop CS6 Extended on Windows XP x64 without any modifications (click to enlarge)

What we can see immediately is that the 3D menu is missing from the menu bar. This is because Adobe generally forbids the use of extended 3D features (import and rendering of 3D models) on all XP systems. There was an explanation about that on the Adobe labs pages, but that link is dead by now, so I can’t be sure why it was originally disabled. I’ll talk about that stuff later. First, we’ll look at the hardware we do get to use for now, this can be found under Edit \ Preferences \ Performance...:

: Photoshop CS6 RAM settings on Windows XP x64 (click to enlarge)

: Photoshop CS6 graphics settings on Windows XP x64 (click to enlarge)

Well, we do get to use a ton of memory, but as you can see, my relatively powerful GTX Titan Black is not being used. Strangely, it says it’s because of me not running the Extended version of Photoshop CS6, but that’s not quite correct:

Photoshop CS6 Extended splash screen

I’m not actually sure whether it always said that, as I’ve been messing with Photoshop for a while now, so maybe there was a different message there at first. But it doesn’t matter. The bottom line is, we’re not getting anything out of that GPU!

And we’re gonna fix that.

6. Getting 2D and OpenCL GPU acceleration to work

This is actually easy. We’ll fool Photoshop CS6 into thinking that my GTX Titan Black (which is newer than the software) is an “old GPU”. You can tell Photoshop to still do its stuff on older, slower GPUs despite them not being officially supported. And when that switch is flipped, it seems to apply to all unknown GPUs and graphics drivers, no matter what. Check out the following registry hack:

```
Windows Registry Editor Version 5.00
```
```
 
```

[HKEY_CURRENT_USER\Software\Adobe\Photoshop\60.0]

```
"AllowOldGPUS"=dword:00000001
```

Save that text into a .reg file, for instance AllowOldGPUS-in-Photoshop-CS6.reg. Close Photoshop, then double-click on that file, and it’ll create that dword value AllowOldGPUS for you and set it to 1[2].

Note that the registry path will be different for older versions of Photoshop, so the last part might not be 60.0 but something else, like 11.0 in such a case. Just check first if you have to, by launching Windows’ Regedit tool and navigating to that part of your user registry.

After that, launch Photoshop, and again look at Edit \ Preferences \ Performance...:

Graphics settings when “AllowOldGPUS” is enabled

Aha! Looking better. But if you click on that “Advanced Settings…” button, you get this:

Advanced gaphics settings with “AllowOldGPUS” enabled

Almost everything checks out – even OpenCL – but we still don’t get to use the advanced OpenGL rendering mode that is supposed to make things even faster. But most of the GPU accelerated 2D functionality is there now, it’s just not working at maximum performance, at least according to Adobe. You’ll get to use stuff like Oil Paint and Scrubby Zoom etc. now though.

But, the 3D stuff that’s been disabled on XP is still missing entirely. And we’ll get to that final part now!

7. Getting 3D and the advanced level of OpenGL 2D acceleration to work

This is a bit more tricky. This stuff is blocked by Photoshops’ operating system detection routines. You can check their results by clicking on Help \ System Info... and looking at the top part of that report:

Adobe Photoshop Version: 13.0.1 (13.0.1.3 20131024.r.34 2013/10/24:21:00:00) x64
Operating System: Windows XP Professional 64-bit
Version: 5.2 Service Pack 2

So we have to fool it into thinking that it’s sitting on a more modern operating system. The tool for the job is Microsofts’ own [Application Verifier]. It’s a software testing tool meant to be used during testing phases of a software development process. It’ll do just what we need though. Download the 64-bit edition (32-bit one is included in that as well, you can ignore that for our purpose), and run it.

Microsofts’ Application Verifier

Right click into its Applications pane, and add two applications that you can find in your Photoshop installation directory, Photoshop.exe and sniffer_gpu.exe. The latter is a command line tool that detects GPU VRAM, driver version, OpenGL / OpenCL versions etc. You can launch that on a terminal window as well, it outputs everything right to stdout, so you can see what it’s reporting right on the terminal. This program is launched by Photoshop every time during startup to determine GPU and graphics driver+API capabilities.

Well, uncheck everything in the Tests pane, and check just Compatibility \ HighVersionLie. Right-click it, and pick Properties and enter the following[3]:

Faking Windows 7 SP2

So we’re reporting an NT 6.1 kernel (Windows 7) with build number 7601 and service pack 2, which would be current as of today. Keep it like that, and launch Photoshop. You’ll see this:

Photoshop CS6s’ full functionality, ready to be used? (Click to enlarge)

And there we go, our 3D menu is active on top, right between the “Filter” and “View” menus. But that doesn’t mean that it’s tools are really working… Anyway, the System Info will now report a different operating system:

Adobe Photoshop Version: 13.0.1 (13.0.1.3 20131024.r.34 2013/10/24:21:00:00) x64
Operating System: Windows 7 64-bit
Version: 6.1

Oddly enough, the service pack 2 part is missing, but who cares. Let’s take a look at the graphics settings!

Advanced graphics settings, revisited

Alright, we can use advanced OpenGL effects after applying our Windows 7 fake! Very good. That means all 2D OpenGL / OpenCL accelerated parts are working at maximum performance now! And as a first indicator of 3D also working, we can now access the 3D settings as well, look at this:

3D settings, even the full 6GB VRAM minus some 32MiB of reserved memory have been detected (click to enlarge)

For the 3D test, I decided to download a 3DStudioMax sample model from GrabCAD, [here] (that website requires registration). A complete render of that model can also be seen there, looks like this:

It’s called “Chainmail maelstrom unit”

So, let’s create a new document, import that model via 3D \ New 3D Layer from File... and switch to Photoshops’ 3D view! And…

OpenGL accelerated 3D preview (click to enlarge)

It’s totally working! Strangely you don’t get anti-aliasing even though the card can do it, but at least it’s something. I’m almost feeling like sitting in front of some kind of CAD software now, with all that realtime 3D rendering. Photoshop does interpret the material properties a bit weirdly however, so it’s not glossy enough and the color is wrong for something that’s supposed to be “steel”. I didn’t fix it up though, just left it as-is and clicked “render”! Then, after lots of waiting, you get some nicer output:

Final render (click to enlarge)

Please note that the above screenshots are 8-bit PNG, so they’re not true representations of the source at all. Still, should be good enough.

One disappointing part is, that the final render – or rather raytracing output – isn’t being crunched on the GPU. Instead, it’s using a lot of CPU cores. In this case, my hexcore Xeon with 12 threads was loaded up to 70-90%. But it would still be a lot faster if done by an OpenCL or CUDA raytracer on the GPU. I will need to check whether there are any plugins for that.

Anyway, this means that the full potential of Adobe Photoshop CS6 Extended can be unlocked on Windows XP Professional x64 Edition SP2! Cheers!

8. What about Windows XP 32-bit?

No idea. I haven’t tested it. According to users on the web, the OpenCL part wouldn’t work on 32-bit at all, no matter which operating system. It’s supposed to be “by design” for whatever reason. I’m not sure if its just disabled like with 3D, or whether the libraries using it are really not there for the 32-bit version of Photoshop CS6. You would need to test that by yourself, but I wouldn’t get my hopes up with that. At least the other parts should be doable, including 3D.

Now, all that remains is to learn how to actually use Photoshop CS6. It’s probably going to be a bit painful coming from the Corel side of things…

[1] Adobe Photoshop CS6 – Change language to English, Tim Barrett, 2014-08-17 on Youtube

[2] Enable GPU Acceleration in x64 XP, op2rules, 2009-12-11 on Youtube

[3] A comment, Schlaubstar, 2012 on Youtube

How to fix licq to support the new, longer 16-character passwords of ICQ

Linux, Programming, t3h intarweb, Unix No Responses »

Aug 102017

Yes, I’m still using ICQ despite it being in the hands of a certain Mail.ru Corporation. And yes, I’m still using the ancient UNIX client [licq] to connect to its network as well. I just love it for its simplistic and compact GUI including a single message mode. The thing is, when you look at its [Github project], you can see that the client hasn’t seen any active development for three years, so I assume we can consider the software “pretty dead”. I don’t like the other available UNIX/Linux clients though, so I want to keep using licq for as long as possible, just like Miranda on Windows.

Thing is, since it hasn’t seen any development for 3 years, licq also doesn’t support the long up-to-16-character passwords that the network supports since some time in 2016. Those old 8-character passwords (clients usually truncate anything beyond that) are not exactly very secure though, so I wanted to [change my password] to a longer, more secure one – which by now requires a phone to be attached to your ICQ account by the way.

Miranda supports that already, and so do all the other modern clients with support for the Oscar protocol and ICQ, but licq can’t log in anymore after such a change. So I tried to modify the source code and fix this myself. I’ve been using the last stable release [1.8.2] for this, building on CentOS 6.9 Linux.

First, unpack licq-1.8.2.tar.bz2, then enter the new directory licq-1.8.2/, this is your source root that all other paths I’ll mention will be relative to.

The most important changes have to be made in the file plugins/icq/src/packet-srv.cpp, which is a part of the ICQ protocol plugin. Open the file in your favorite text editor, and hop to line number 595, here you’ll find this:

expand/collapse source code

//-----NewLogon-----------------------------------------------------------------

CPU_NewLogon::CPU_NewLogon(const string& password, const string& accountId, const string& md5Salt)

  : CPU_CommonFamily(ICQ_SNACxFAM_AUTH, ICQ_SNACxAUTHxLOGON)

```
{
```

  // truncate password to MAX 8 characters

```
  string pass(password);
```
```
  if (pass.size() > 8)
```
```
  {
```

    gLog.warning(tr("Password too long, truncated to 8 Characters!"));

```
    pass.erase(8);
```
```
  }
```

Alright, as you can see, there is a truncate that cuts everything after 8 characters before hashing the password. Clearly, that won’t work, so change the code to this:

expand/collapse source code

//-----NewLogon-----------------------------------------------------------------

CPU_NewLogon::CPU_NewLogon(const string& password, const string& accountId, const string& md5Salt)

  : CPU_CommonFamily(ICQ_SNACxFAM_AUTH, ICQ_SNACxAUTHxLOGON)

```
{
```

  // truncate password to MAX 16 characters

```
  string pass(password);
```
```
  if (pass.size() > 16)
```
```
  {
```

    gLog.warning(tr("Password too long, truncated to 16 Characters!"));

```
    pass.erase(16);
```
```
  }
```

A similar change has to be applied further down as well, please hop to line number 646 in the same file and you’ll find something that looks almost the same:

expand/collapse source code

//-----Logon--------------------------------------------------------------------

CPU_Logon::CPU_Logon(const string& password, const string& accountId, unsigned short _nLogonStatus)

```
  : CSrvPacketTcp(ICQ_CHNxNEW)
```
```
{
```

  // truncate password to MAX 8 characters

```
  string pass(password);
```
```
  if (pass.size() > 8)
```
```
  {
```

    gLog.warning(tr("Password too long, truncated to 8 Characters!"));

```
    pass.erase(8);
```
```
  }
```

Again, fix it:

expand/collapse source code

//-----Logon--------------------------------------------------------------------

CPU_Logon::CPU_Logon(const string& password, const string& accountId, unsigned short _nLogonStatus)

```
  : CSrvPacketTcp(ICQ_CHNxNEW)
```
```
{
```

  // truncate password to MAX 16 characters

```
  string pass(password);
```
```
  if (pass.size() > 16)
```
```
  {
```

    gLog.warning(tr("Password too long, truncated to 16 Characters!"));

```
    pass.erase(16);
```
```
  }
```

Now the client is fixed functionally, but there are some additional changes you may wish to apply in the localization files for German, Spanish and Belarusian, in the files po/de.po, po/es.po and po/be.po respectively. Those are GNU message catalogs before compilation, you can just edit them with any text editor, like with the source code. The relevant lines in those three files look as follows:

po/de.po:

#~ msgid "Password too long, truncated to 8 Characters!"

#~ msgstr "Passwort zu lang, wurde auf 8 Zeichen beschnitten!"

po/es.po:

#~ msgid "Password too long, truncated to 8 Characters!"

#~ msgstr "Copntraseña demasiado larga, truncada a 8 caracteres!"

po/be.po:

#~ msgid "Password too long, truncated to 8 Characters!"

#~ msgstr "Пароль занадта доўгі, абмяжоўваем 8 сымбалямі!"

Just change all occurrences of 8 to 16 for all those lines above, save the files, and you’re done and ready for compilation. Now I won’t help you much with that, but let’s just say you need at least cmake, GNU make, and a C and C++ compiler for this. In the most optimal case you can just enter the source root after patching and run something like this, the last step with root privileges:

$ mkdir ./build
$ cd build/
$ cmake ..
$ make
# make install

And yes! It works! After compiling and replacing my licq version with the patched one, I can log in with longer passwords! If you’ll keep your version the same, you might also be ok with just replacing the original /usr/local/lib/licq/protocol_icq.so with the one from plugins/icq/build/src/. Actually, you might be able to compile and replace just the ICQ protocol plugin by itself, without all of the other stuff.

Recompiling the whole thing won’t hurt though, so yeah. I should probably submit a patch based on this, but I doubt anyone would commit it anymore… Soon, most Linux distributions and UNIX operating systems may even drop their official licq packages anyway.

How the Mail.ru / MyMail Apps leak your 3rd party login data and your emails to Russia

Mobile, Security 2 Responses »

Jul 282017

1.) Introduction

Of course you could say: “If you’re going to use Russian software, that’s what you’d have to expect!”. But yeah. I’ve actually used tools written by Russian developers before, and they used to be very slim and fast, so I thought, why not give it a shot. Background is that I’ve finally ditched my ancient Nokia E72 “smart phone” based on Symbian 9.2 / S60 3rd, which has become almost unusable because of its lack of modern SSL ciphers (most websites won’t let you connect anymore) and because of its Skype and ICQ clients being banned from their respective servers.

So I finally went ahead and got myself an Android 7.1.1 device, the Blackberry KEYone, my second attempt at using the OS (first was a Motorola Milestone 2 with Android 2.1, a failure because of many reasons).

Anyway, I had to find an eMail app that would let me do two things:

Display and send everything as plain text (I hate HTML mails and find them pretty insulting to be honest)
Allow me to connect to mail servers which support only older SSL/TLS protocols and ciphers (I’ve got no choice here)

2.) The Mail.ru email client on Android

2a.) The app itself

So, I tested a lot of clients, one of which was [Mail.ru], a pretty high-ranked email app (4.6/5) with more than 10 million installs out there. Superficially, it looks just like pretty much any other email client, because there are likely readily available Android libraries for implementing email clients:

An image directly from the Google play store, showing the apps’ GUI (click to enlarge)

So they advertise it with slogans like “ideal application for any mail” and “add all your email boxes in one application”. Actually, it’s ideal for just one thing: To hand over all your email accounts and emails to a Russian company and with it the Russian government – because in Russia, companies have to yield to the government and grant it full access to user accounts and data by default.

I guess free Russian developers and actual Russian software companies have to be treated very differently!

What I did was to enter my own email account credentials in the Mail.ru app to be able to fetch my emails via IMAP. I found that the client does not meet my personal requirements (no way to force plain text email), so after my quick test, I just uninstalled the app.

2b.) What the app does without you noticing

However, by that time, the Mail.ru app had already leaked my account credentials to certain mail.ru and my.com servers (my.com is a part of the bigger Mail.ru group), which had now started to log into my account from Russia – periodically checking all my email boxes and downloading every single message stored on my own server. Let’s have a look at the logs!

Here is their first connection attempt, coming from 5.61.237.44 (sapif30.m.smailru.net) as well as the second one from 94.100.185.215 (rimap21.i.mail.ru):

Tue 2017-07-25 14:59:27: Session 5554; child 3; thread 1232
Tue 2017-07-25 14:59:26: Accepting IMAP connection from [5.61.237.44:42273]
Tue 2017-07-25 14:59:27: SSL negotiation successful (♡)
Tue 2017-07-25 14:59:27: --> * OK ♡ IMAP4rev1 ♡ ready
Tue 2017-07-25 14:59:27:  1 OK LOGIN completed
Tue 2017-07-25 14:59:27:  1 OK LIST completed
Tue 2017-07-25 14:59:27:  * BYE IMAP engine signing off (no errors)
Tue 2017-07-25 14:59:27: --> . OK LOGOUT completed
Tue 2017-07-25 14:59:27: IMAP session complete, (2654 bytes)
Tue 2017-07-25 14:59:27: ----------
Tue 2017-07-25 15:00:04: ---------- Partial transcript, remainder will follow.
Tue 2017-07-25 15:00:04: Session 5556; child 4; thread 3588
Tue 2017-07-25 14:59:28: Accepting IMAP connection from [94.100.185.215:53424]
Tue 2017-07-25 14:59:28: SSL negotiation successful (♡)
Tue 2017-07-25 14:59:28: --> * OK ♡ IMAP4rev1 ♡ ready
Tue 2017-07-25 14:59:28:  1 OK LOGIN completed
Tue 2017-07-25 14:59:28:  * CAPABILITY ♡
Tue 2017-07-25 14:59:28: --> 2 OK CAPABILITY completed

You might have guessed it, the ♡ marks things I cut from the logs for privacy reasons. Guess I got a bit too creative. Anyway, this was only the beginning. Later, some mail collector servers from the IP range 185.30.17*.** (collector*.my.com) started to log in and download all my emails from all my folders! Here’s just a small excerpt from the commands issued with one of my archive folders serving as an example – most of the stuff has been cut out to make it more concise:

Tue 2017-07-25 14:59:29: <-- 3 LIST "" "*"
Tue 2017-07-25 14:59:31: <-- 23 FETCH 22:* (UID FLAGS)
Tue 2017-07-25 14:59:52: <-- 49 STATUS "Archives" (UIDNEXT MESSAGES UNSEEN UIDVALIDITY)
Tue 2017-07-25 14:59:52: <-- 49 STATUS "Archives" (UIDNEXT MESSAGES UNSEEN UIDVALIDITY)
Tue 2017-07-25 14:59:53: <-- 50 STATUS "Archives/2013" (UIDNEXT MESSAGES UNSEEN UIDVALIDITY)
Tue 2017-07-25 14:59:53: <-- 51 SELECT "Archives/2013"
Tue 2017-07-25 14:59:53: <-- 52 FETCH 1:* (UID FLAGS)
Tue 2017-07-25 14:59:53: <-- 53 UID FETCH 7 (RFC822.SIZE BODY.PEEK[] INTERNALDATE)

All of those are just the remote commands issued to my server. Note that in IMAP4, UID FETCH <UID> BODY.PEEK[] at the bottom is an actual message download. Needless to say, there were thousands of those going unchecked, because it took me 3 days to discover the leak. And I only discovered it coincidentally too. So by that time they had long downloaded all my emails from my own server to Russia. If you're not running your own mail server, you wouldn't even notice this.

So if you just happened to enter your AOL, Yahoo, gmail or Hotmail accounts, you'd never see those Russian servers accessing those accounts remotely!

3.) This can't be ok, can it?

This behavior is completely unacceptable and has been reported to Google as it is borderline regarding Googles' own privacy policy:

Privacy Policy & Secure Transmission

If your app handles personal or sensitive user data (including personally identifiable information, financial and payment information, authentication information, phonebook or contact data, microphone and camera sensor data, and sensitive device data) then your app must:

Post a privacy policy in both the designated field in the Play Console and from within the Play distributed app itself.

Handle the user data securely, including transmitting it using modern cryptography (for example, over HTTPS).

The privacy policy must, together with any in-app disclosures, comprehensively disclose how your app collects, uses and shares user data, including the types of parties with whom it’s shared.

Prominent Disclosure Requirement

If your app collects and transmits personal or sensitive user data unrelated to functionality described prominently in the app’s listing on Google Play or in the app interface, then prior to the collection and transmission, it must prominently highlight how the user data will be used and have the user provide affirmative consent for such use.

First of all, the mail collectors drop down to cryptographic ciphers even I wouldn't use anymore when asked to do so. I mean, it sounds hypocritical coming from me (because I'm actually using very old ciphers too, as I'm out of options on my ancient server), but they do fall back to what's by no means "modern cryptography". Also, the leaking of account credentials and data to Russian servers and the continuous use of said data even after the user has stopped using Mail.ru services is not mentioned anywhere while installing or using the app, not that I could see at least.

I most definitely didn't give my consent to having the app use my data like this - I wasn't presented with an EULA during the installation or use of the software. Also, the (Russian...) email they had sent me after accounts were set up in the app didn't show an EULA or privacy statement either. It's even worse considering [Mail.ru's history] in terms of handling that information.

None of this is new either, see e.g. [this Reddit] (MyMail is from my.com - as said, a part of the Mail.ru Group).

Well, I started to look around and found a Mail.ru [user agreement] online. The interesting part is point 4.1.3:

4.1.3 In addition to the registration procedure on the Internet Service specified in clause 4.1. the user may be granted the right to register through using its data (login and password) of the e-mail box registered at the third person’s resource.

Irrespective of using any method of registration on the Internet Service the User’s password used to visit the Internet Service shall be beyond the reach of Mail.Ru.

Now that part is a bit problematic. The "third person's resource" is clearly your own mail account on some other server. So like my email account on my own server. The question is, what exactly does it mean when they say that the users' password shall be "beyond the reach of Mail.Ru"? Guess they'd mean my actual plain text password, right?

Well, no matter if they use hashes with <-- 2 authenticate CRAM-MD5, or instead just plain text <-- 1 LOGIN ♡@♡.♡ ♡♡♡♡♡♡, they do have my password stored away on their servers as clear text (probably on some encrypted file system? But still.). I wouldn't call that "beyond the reach of Mail.ru" anymore.

I guess I could have misread the user agreement (that I wasn't even presented with!) somewhere, but it doesn't seem to me as if they'd be following their own rules regarding privacy?!

If you're using the Mail.ru app I can only advise you uninstall it if you haven't done so already and to change all account passwords ever entered in the application to stop the Russian collector servers from logging into your accounts and "stealing" your email even after app deinstallation.

On a side note: Since K-9 Mail isn't exactly right for me either, I settled with [R2Mail2], which is being developed in Austria by the company [RundQuadrat]. I've been talking with its developer over the last few days, and he seems a like a nice family guy. I do like the client, as it has an impressive feature list, let's just name a few:

Manually configurable SSL/TLS cipher list, you can pick which ciphers you want or don't want to use, including the option to support a few deprecated ciphers.
Data oriented encryption with either S/MIME, or even PGP and PGP/MIME for emails and also arbitrary files (a small tool for file encryption is embedded in the client).
Support for Microsoft Exchange servers
Option to stop syncing in the background, so a full shutdown of the app is possible with ease.
Full plain text support, so you can force all messages to be displayed and sent in plain text only.
The client itself can be password protected and can be instructed to store all local data in encrypted form.
Extremely configurable: Reply/Forward Prefixes, host name use in EHLO command, notification LED color ( :roll: ), IPv4/IPv6 preference, Certificate store access & configuration, peak day/time option to boost synchronization, sync grouping with other apps to save battery, local email pruning and many, many other things.

It does come at a price though, as it costs 4.80€. But if you want a seriously powerful and I'd say more trustworthy email application for Android, you might give this a shot. Otherwise, maybe just go with the free K-9 mail app if you want plain text and don't need to rely on mail servers with antiquated SSL/TLS implementations.

But no matter what, stay away from Mail.ru and MyMail!

Games that run on Windows XP / XP x64 even though they shouldn’t; A compatibility report

Gaming, Windows 2 Responses »

Jul 122017

I thought about writing something like this for a while now, so here it is. A list of games that don’t officially work on XP / XP x64, but still do. Either out of the box or by using some slight modifications or by using real binary hacks and stub DLLs. This list is by no means complete, it’s basically just the stuff I stumbled over. Some of the games will require slightly more complex solutions, for which individual guides already exist, either here or elsewhere. I won’t describe the procedures again, but just link to the corresponding information where necessary.

Where known, the game engine used by a title will also be listed, because games using the same engine can sometimes be persuaded to work in the same way.

Since my Anime (and Manga and visual novel) infection has already spread throughout my brain completely while creating fatal degeneration in the process, I had to split this article into four categories, to better suit peoples’ interests – 1 and 2 are almost the same though:

Western games
64-bit games officially supported on XP x64
Weird Japanese shit
Visual novels (which by definition are often also weird Japanese shit)

Platform compatibility information was mostly taken from Valve Steam, so the operating system requirements specified here might not always match those listed at other websites selling those games.

I’m actually planning on keeping this list up to date as time progresses!

Updates (latest first):

2017-09-11: “Gal*Gun: Double Peace” / “ぎゃる☆がんだぶるぴーす” has been added.
2017-09-05: “Ne no Kami” part 2 and “The last Birdling” have been added. Ren’Py version number added for “Fatal Twelve”.

Ok, let’s start:

1. Western Games

Here’s the normal stuff:

1a. Dishonored

Claims:	Windows Vista
Developer & Engine:	Arkane Studios; Unreal Engine 3
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum; Several playthroughs on XP completed, likely no more development
Genre:	First Person Rogue (Steampunk setting)
Synopsis:	See [Wikipedia]
Notes:	It’s a dark, very much steampunk, interesting parallel world setting. Features a world that changes subtly based on the characters’ actions. The sequel will no longer work on XP. Runs fine even with mid-range hardware from around 2015 or so.

1b. Legend of Korra

Claims:	Windows Vista
Developer & Engine:	PlatinumGames; In-house PlatinumGames Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests carried out, no playthroughs
Genre:	Beat ’em up
Synopsis:	See [Wikipedia]
Notes:	It may look animeish at first, but is actually a US-made game.

1c. Life is strange

Claims:	Windows Vista
Developer & Engine:	Dotnod Entertainment; Unreal Engine 3
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests carried out, no playthroughs
Genre:	Graphic adventure
Synopsis:	See [Wikipedia]
Notes:	It’s an episodic series, and I’ve only covered the first part.

1d. Master of Orion

Claims :	Windows 7 64-bit
Developer & Engine:	NGD Studios; Unity Engine 5.2
Requirements:	64-bit; Will work on XP x64, but not on XP 32-bit, as it’s a true 64-bit binary.
Compatibility confidence:	Fair; Only brief tests carried out, no playthroughs
Genre:	4X strategy
Synopsis:	Not much to say here, it’s once again a turn-based game about conquering the galaxy.
Notes:	This is about the 2016 version; A classic returns, well, at least almost. Requires fairly powerful hardware.

1e. Mechwarrior Online

Claims:	Windows 7
Developer & Engine:	Piranha Games; CryEngine 2.5 – 3
Requirements:	Steam version; The regular game launcher won’t work.
Compatibility confidence:	High; played for hundreds of hours, but there is a lot of active development, so the more distant future is rather uncertain, hence no “Maximum” confidence.
Genre:	Tactical combat simulator
Synopsis:	At the beginning of the clan invasion, the player – whether on the side of one of the Inner Sphere Houses or any of the Clans – is thrown into Battletech warfare.
Notes:	They have just launched their new game launcher, which is now built with .Net 4.5.2, which doesn’t work on XP. So now, the only way is via the Steam platform. Until their single player title comes out, this is the latest and greatest from the Battletech universe, and it sticks to the canon rather strictly as well. Requires very powerful hardware even on XP, especially on the GPU side of things. Better use top end stuff. Note that it does automatically launch the 64-bit version when on XP x64.

1f. Stellaris (also applies to: Europa Universalis 4, Hearts of Iron 4 and Crusader Kings 2)

Claims:	Windows 7
Developer & Engine:	Paradox Development Studio; In-house Clausewitz Engine
Requirements:	Stub DLL hack; Missing Win32 API / Kernel API function calls, requires UncleVasyas’ (Oleg Ovcharenkos’) XP hack: [Link].
Compatibility confidence:	Low; Haven’t tested this myself at all, as I do not yet own the game. However, given users’ reports and when looking at results when using Olegs’ patch on other games, this will very likely work just fine.
Genre:	4X strategy (Stellaris)
Synopsis:	See [Wikipedia] (Stellaris)
Notes:	May buy this in the future. Requires very powerful hardware, even on XP. Better get ready to use the fastest stuff XP / XP x64 can support in terms of CPU and GPU.

1g. XCOM: Enemy Unknown (also applies to: XCOM: Enemy Within)

Claims:	Windows Vista
Developer & Engine:	Firaxis Games; Unreal Engine 3
Requirements:	Stub DLL hack; Missing file I/O function calls that are available via Microsofts’ backported fileextd.dll. Required hacks by KawaiiSara (32-bit) and ScavengerSpb (64-Bit) described [here] for XCOM: Enemy Unknown and [here] for XCOM: Enemy Within.
Compatibility confidence:	High; No full playthroughs, but played for several hours
Genre:	Strategy
Synopsis:	See [Wikipedia]
Notes:	This was one of the early binary hacks for Games on XP. This is mostly just because the developer didn’t care about properly including fileextd.h, as well linking against and deploying fileextd.dll. Requires fairly current hardware.

2. 64-bit Games officially supported on XP x64

This is a special category for games that do support Windows XP – either only in its 64-bit incarnation, or with a specific port supporting the 64-bit version of the OS officially. Because of this, the “compatibility confidence” rating is being omitted.

2a. Cities Skylines

Claims:	Windows XP x64 Edition
Developer & Engine:	Colossal Order; Unity Engine 5.x
Requirements:	64-bit
Genre:	Construction & Management Simulation
Synopsis:	Build a huge freaking city, what else?
Notes:	Requires powerful hardware, not matter which OS you’re using. Better prepare a fast multi-core CPU and a lot of RAM, like 8GB+.

2b. X-Plane 10

Claims:	Windows XP or Windows XP x64 Edition
Developer & Engine:	Laminar Research; In-house X-Plane 10 core engine
Requirements:	None; Runs out of the box on XP & XP x64
Genre:	Flight simulator
Synopsis:	Fly planes. Huh.
Notes:	Depending on what you’re doing this might require a ton of CPU horsepower and 4GB+ of RAM. The sequel will no longer work on XP / XP x64 due to requiring a more modern Direct3D API.

3. Weird Japanese shit

Well, Japanese stuff is… different. Sometimes in good ways. Sometimes in bad ways. And sometimes in weird ways. Let’s go:

3a. A magical high-school girl / 魔法の女子高生

Claims:	Windows XP / XP x64 (So why is this game listed here? See below, it’s basically a reversed case…)
Developer & Engine:	illuCalab; Unity Engine 5.4
Requirements:	None; Is partially broken out of the box on XP & XP x64 though.
Compatibility confidence:	Low; Played for many hours and it works, but audio is broken and will likely remain in this state.
Genre:	ARPG, somewhat rouge-like
Synopsis:	See [Steam]
Notes:	This is an oddball. It actually specifies Windows XP, but its audio component is built with .Net 4.5, which is not available on XP / XP x64. It still works, but without sound. If you still want to play this on XP, I’d suggest you prepare a good music playlist to run in the background. You’ll have to make the “swooosh”, “zap” and “booom” sounds by yourself though. It’s actually a pretty intelligent game, where spellcrafting works via some AI code that interprets the spell names you type in when creating a new one. Fun fact: Naming a spell “Nagasaki” creates a fire bomb type spell. Talk about political correctness, heh…

3b. Crush Crush

Claims:	Windows 7 SP1
Developer & Engine:	Sad Panda Studios; Unity Engine 5.4.1
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests carried out, no playthroughs
Genre:	Clicker, Yuri
Synopsis:	See [Steam]
Notes:	It’s probably as bad as its logo suggests. While being a clicker you’re supposed to be able to flirt with or date girls, no idea. I only picked this up because it’s supposed to contain Yuri content (Girls Love). I might never really play this, but at least it’s free, so you got nothing to lose.

3c. Gal*Gun: Double Peace / ぎゃる☆がんだぶるぴーす

Claims:	Windows 7
Developer & Engine:	Inti Creates; Unreal Engine 3
Requirements:	64-bit; Will work on XP x64, but not on XP 32-bit, as it’s a true 64-bit binary.
Compatibility confidence:	Fair; Only brief tests carried out, no playthroughs
Genre:	Bishōjo rail shooter
Synopsis:	See [Steam]
Notes:	Bought this on Steam on a -75% sale (taking the risk that it might no work), because it looked like some perverted fun. I might never play it though, as it really needs a game pad, and I suck with those. Well, I do still have my 3dfx/Interact Hammerhead FX, so maybe I’ll try some day. This game seems to work on XP x64 only by accident: It uses the Unreal Engine 3, but is compiled for 64-bit. Clearly, it was never originally intended to ever work on the OS, and was likely never tested on XP x64 either.

3d. Hyperdimension Neptunia Re;Birth 1, 2 & 3 V Generation / 超次次元ゲイムネプテューヌRe;Birth1, 2 & 3 V Generation

Claims:	Windows 7 64-bit
Developer & Engine:	Idea Factory, Compile Heart & Felistella; Sony PhyreEngine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	High; Played for quite a while without issues, no complete playthroughs though.
Genre:	JRPG
Synopsis:	See [Wikipedia]
Notes:	Runs with OpenGL 3.3 if modern Direct3D isn’t present, which allows the 3D renderer to work on XP. All the other components are fine with DirectX 9.0c. The later Neptunia versions (basically all which are asking for Direct3D 11) dropped support for OpenGL, so any version asking for D3D11 should no longer work on XP.

3e. Valkyria Chronicles / 戦場のヴァルキュリア -Gallian Chronicles-

Claims:	Windows Vista
Developer & Engine:	SEGA; CANVAS Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests carried out, no playthroughs
Genre:	Strategy RPG
Synopsis:	See [Wikipedia]
Notes:	I should really play this! It seems to be a somewhat WW1/WW2ish game, and looks pretty good.

4. Visual Novels

Like “graphical novels”, these are crossovers between books and games, somewhat like those multi-branching adventure books for kids you might or might not know. VNs usually tend to require a fair amount of Japanophilia on behalf of the player / reader, at least sometimes. Most are distinctly Asian after all. There are two rough categories: 1.) Typical Visual Novels with a branching decision tree that allows the player to reach different story paths and endings and 2.) Kinetic Novels, that do not allow the player to make any choices, but instead focus on telling a single story as well as possible.

As all of them fall into a single genre (visual novel), the “Genre” part will be replaced with “Subgenre”, like “drama” or “Comedy” or something similar.

Let’s go:

4d. ChuSingura46+1 S / 忠臣蔵46+1

Claims:	Windows 7
Developer & Engine:	inra; Unity Engine 5.4
Requirements:	64-bit; Will work on XP x64, but not on XP 32-bit, as it’s a true 64-bit binary.
Compatibility confidence:	Fair; Only the first part has been tested, and only very briefly.
Subgenre:	No idea. There are tons of Samurai girls, and that’s all I know.
Synopsis:	See [Steam]
Notes:	As said, only the initial free-to-play part has been tested, so I don’t know about chapters 2-5.

4a. Chuusotsu – 1st Graduation: Time after Time / ちゅーそつ! 1st graduation

Claims:	Windows Vista
Developer & Engine:	Studio Beast; KiriKiri Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; The game hasn’t been released at the time of writing, but brief tests have been done running the demo without problems so far. The release is expected some time in Q4 2017.
Subgenre:	Cute Slice of Life, Sterile Dystopia with social commentary (afaik)
Synopsis:	See [Kickstarter]
Notes:	I actually backed this. I like this kind of “no personal freedom” kind of sci-fi setups, where certain individuals struggle with their lack of free choice or expression of opinion. This title might be a lot less serious though, I simply don’t know yet.

4b. Fatal Twelve / フェイタルトゥウェルブ

Claims:	Windows 7
Developer & Engine:	Aiueo Kompany & Sekai Project; Ren’Py Engine 6.99.12.4 (Python 2.7)
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; The game hasn’t been released at the time of writing, but like with Chuusotsu, brief tests have been carried out on the demo without problems. The release is expected on 2018-01-01.
Subgenre:	Mystery, supernatural, Yuri
Synopsis:	See [Kickstarter]
Notes:	I saw it’s graphical style, and I knew I had to back this. It looks rather well made, visually at least. Should contain lots of Yuri elements, which is always a reason for buying pretty much anything!

4c. Flowers -Le volume sur Printemps-

Claims:	Windows Vista
Developer & Engine:	Innocent Grey; unknown engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum; Full playthrough completed, several parts replayed.
Subgenre:	Yuri Drama, Slice of Life
Synopsis:	Our protagonist Suoh – which suffers from pretty intense social anxiety – changes schools, right into a classy christian, private all-Girls school. The story follows her finding her first friends (and more than that) as well as her opening up to the people around her.
Notes:	No explicit stuff, so this is on the softer side of Girls Love. It does feature drama as well. Note that this is a longer VN, but still only the first part of a four-part series. Each part is supposed to represent a season – spring, summer, autumn and winter, both in actual time of the year as well as the maturation of the characters. Rather lengthy, ~20 hours. Part 2 will come out soon (likely this month), and will be tested immediately after release!

4e. Kindred Spirits on the Roof / 屋上の百合霊さん

Claims:	Windows Vista
Developer & Engine:	Liar-soft; Codex RScript Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum; Full playthrough completed.
Subgenre:	Yuri, Slice of Life
Synopsis:	Happens that for some reason our protagonist (a girl, like all characters here) is sensitive to the supernatural and hence manages to make contact with the two ghosts on the roof of the school. Those happen to have watched many a bad outcome when it comes to romances at the school, unable to intervene for decades. Now that they can talk to a living person for the first time, they’ve picked you to become their “tool” to “get those girls together”.
Notes:	Does feature sex scenes, but they’re rare and not overly explicit. Its a longer Yuri VN, and despite having a few steamy moments, I’d still call this one “soft and sweet”. Gives you a good 20 hours of girls getting closer to girls!

4e. The last Birdling

Claims:	Windows XP, but also DirectX 10 (Huh?! How’s that gonna work?)
Developer & Engine:	InvertMouse; Ren’Py Engine 6.99.12.3 (Python 2.7)
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests completed, no playthroughs
Subgenre:	Fantasy
Synopsis:	A story of two members of opposing races of which one is about to become extinct, who become friends against all odds, and then have to hide / defend their friendship without enraging their respective peoples.
Notes:	This is not actually Japanese, the developer is an Australian who’s lived in Hong Kong. I’m not sure if this is Yuri, but probably not, Yuri friendship at best? I do like stories, where people who’re supposed to be hating each other due to their upbringing become friends instead, and then start to defend that friendship. Should be interesting even without Yuri. The game doesn’t actually use any DirectX 10 resources, it renders to OpenGL and makes use of some DirectX 9.0c libraries.

4f. Ne no Kami: The two Princess Knights of Kyoto / ねのかみ京の都とふたりの姫騎士

Claims:	Windows 7 / Windows Vista in the Readme file, noting that “XP may work, but it’s untested”
Developer & Engine:	Kuro Irodoru Yimiji; Artemis Engine w. m-kz / iMel
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum for part 1; 1½ playthroughs completed, both the censored and uncensored versions have been extensively tested. Fair for part 2; Only brief tests completed, no playthroughs.
Subgenre:	Yuri, Supernatural
Synopsis:	Our girl – despite being the long-time love interest of a rather well-endowed certain someone that will become really important in this story – is being abducted by her own friend to become a wielder of ancient, divine powers that are meant to be used to battle forces once again threatening to invade the Earth from some demonic realm.
Notes:	This game knows how to smear the borders between good and evil. The more you learn, the less clear it becomes which side is really in the right and which isn’t. I like that way of world building and story development. This game does feature one explicit scene, which I found to be rather annoying. You can still play the censored version though. The sequel should be nearly completed now, it had to be delayed due to the unfortunate death of one of the lead voice actresses. Update: Part 2 has been released!

4g. Nekopara / ネコぱら

Claims:	Windows Vista
Developer & Engine(s)	NEKO WORKs; TCP(KiriKiri) or KiriKiri Z (unclear which one) Engine for Vol.0-2, Ares CatSystem2 Engine for Vol.3
Requirements:	.exe unpack and binary header hack for the patches of Vol.1-2, Vol.3 itself needs an additional stub DLL hack on top of that, which is based on Oleg Ovcharenkos’ work for Stellaris, etc. When running the Steam version, Vol.3 also needs a Steamless hack to decrypt/unpack the SteamStub DRM so the stub DLL hack may be applied. The whole procedure from A to Z is documented [here]. Thanks fly out to Oleg for his help with Vol.3!
Compatibility confidence:	High; No complete playthroughs through Vol.3 yet, but a lot of shorter test runs. Plus “I just have a good feeling about this” for some undefined reason. Vol.0-2 have a rating of Maximum.
Subgenre:	Harem, dating simulator, Eroge
Synopsis:	Tons of catgirls working in your bakery. Catgirls in heat (this turns into something very, VERY explicit, if you happen to have the uncensored version). Other than that, just cute catgirls that you can pet and play around with. Also: Minor character development.
Notes:	This game will defile you. If you’re new to this stuff, it may redefine your understanding of how perverted Japanese shit can really be. Unless you play the pure, censored version.

4h. Neko-nin exHeart / 猫忍えくすはーと

Claims:	Windows 7
Developer & Engine:	Whirlpool; YU-RIS Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum; Complete playthrough without hiccups
Subgenre:	Supernatural
Synopsis:	There were once powerful catgirl ninjas (don’t switch your brain on please, you really don’t need that piece of equipment here) serving their human masters, but no more. It seems nobody needs their personal kitty ninjas these days. Nevertheless, two of them just show up one day declaring they would serve you (heh, right) as their new master, while you weren’t even aware catgirls existed. Or ninjas. Or ninja catgirls.
Notes:	It ain’t great, but it’s cute, even if rather short. Bought this out of frustration during a time where Oleg Ovcharenko hadn’t yet helped me with hacking Nekopara Vol.3.

4i. Nurse Love Addiction / 白衣性愛情依存症

Claims:	Windows 7
Developer & Engine:	Kogado Studio; TyranoScript Engine (not sure if true, but binary analysis suggests it, it’s definitely built with Borland C++ at least)
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum; Complete playthrough without any issues
Subgenre:	Yuri, Drama
Synopsis:	Dragging her long-time friend along with her, our protagonist decides to become a nurse, hence entering a nursing school. But will she be ready for what she got herself into?
Notes:	Don’t rush into this one thinking you’re going to get sweet, fluffy Yuri. This game looks like it, but it turns out to be quite dramatic and depending on how you approach the setting, it may hit you rather hard. Better keep that in mind, this VN is not as light-hearted or superficial as it may look on the surface. Easily goes on for 10+ hours as well.

4j. Panzermadels

Claims:	Windows Vista
Developer & Engine:	DEVGRU-P; TyranoScript Engine
Requirements:	Special launch condition; Works only when launched outside of Steam (with Steam still running in the background, you just have to click the .exe file directly instead of launching it from within the Steam client application).
Compatibility confidence:	Maximum; Multiple complete playthroughs without any problems
Subgenre:	Tank dating simulator (don’t ask…)
Synopsis:	It’s so stupid, why don’t we just skip this?
Notes:	The crown jewel of stupidity. You’re dating girls… who are tanks. I mean, in this game you can get court martialed for “doing sexual stuff with military equipment”. It’s still plenty of fun though, maybe because of it being so stupid. Just drink a beer or three while playing this and it’ll be fine! Ah, by the way: This is not actually Japanese-made, the developers originate from the UK I believe. Also, this game was only meant as a short joke anyway.

4k. Planetarian ~The Reverie of a little Planet~ / Planetarian ～ちいさなほしのゆめ～

Claims:	Windows Vista
Developer & Engine:	Visual Art’s & Key; RealLive Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Maximum; Complete playthrough without problems
Subgenre:	Postapocalyptic drama, Kinetic Novel
Synopsis:	It’d be on the lengthy side, so see the [Wikipedia] instead
Notes:	I have not yet tested the newer “HD” version on Steam, which claims Windows 7, but only the regular version. The HD version will be tested in the future. This is simply one of the best VNs I have ever played, despite it’s age and respectively lower visual quality. Its dark, hopeless and yet intriguing postapocalyptic world just draws you into this 2 character piece like few other VNs manage. Prepare your tissues however, this is a drama after all. Thumbs up for a VN that manages to do so much world building in such a short time (you’ll complete this in 3-5 hours). Update: …as soon as there is a version with English or German text. Currently it’s Chinese only.

4l. Season of 12 Colors / 十二色的季节

Claims:	Windows 7 SP1
Developer & Engine:	Juziban; BK Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests completed, no playthroughs
Subgenre:	Unsure, but not a drama? Seems to feature a slow, soft narrative…
Synopsis:	See [Steam]
Notes:	Rather untouched yet, I might play this in the not-so-near future. It’s supposed to have “healing” effects, so I guess it’s soothing to the mind.

4m. Steins;Gate

Claims:	Windows 7
Developer & Engine:	5pb. Games & Nitroplus; Infinity Engine
Requirements:	None; Runs out of the box on XP & XP x64
Compatibility confidence:	Fair; Only brief tests completed, no playthroughs
Subgenre:	Drama, time travel
Synopsis:	See [Wikipedia]
Notes:	Only the original DVD version has been tested, but not the Steam “HD” version. I haven’t really played this much yet, but it’s supposed to be one of the best visual novels ever. Remember how great the Anime was? It’s based on this game.

4n. VA-11 HALL-A (“Valhalla”)

Claims:	Windows 7
Developer & Engine:	Sukeban Games; GameMaker C++ Engine
Requirements:	Special launch condition; Requires the renaming or removal of the GameMaker engine component library GMResource.dll in the games’ root folder to execute without fatal errors. Works for all versions (original, Steam & GOG).
Compatibility confidence:	Low; Only few tests completed, some basic gameplay, file I/O etc. The game does still reproducibly crash upon exit because something goes wrong with its use of Direct3D, which is by no means critical, but gives me a bad feeling about this. Really needs a playthrough to raise confidence.
Subgenre:	Cyberpunk Dystopia, Yuri, Kinetic Novel
Synopsis:	You’re a bartender girl in a dystopian cyberpunk world, taking good care of your patrons while listening to the stories they have to tell while drinking.
Notes:	XP compatibility for this VN [was requested by Konstantin] in the comment section of the Nekopara Vol.3 hack. Well, barkeepers are cool, always wanted to play one in a game, because usually, you only meet them, but they’re never the stories’ protagonists. This title is supposed to have several Yuri characters as well, including yourself. I’m unsure how much drama there is though… Also: The game suggests you “get a drink and a few snacks” and chill out while reading / playing this – nice!

That’s it for now, but there might be more to come!

How to make Nekopara Vol.3 work on Windows XP / Windows XP x64 (and: A hint for Mechwarrior Online players still sitting on XP / XP x64)

Anime & Manga, Gaming, Scripting, Windows 9 Responses »

Jul 072017

Nekopara Vol.3 logo 1. Introduction

Of course I would never play something like Nekopara *cough*, so this is just a post describing a technical solution to a compatibility problem! Ok?! Good.

Yeah, it’s another one of those “something broke on XP / XP x64, so let’s fix it” articles. I’ve already been pla… eh.. investigating Nekopara Volumes 0, 1 and 2, and while the developer claims it needs Windows Vista or higher, those titles worked just fine on XP and XP x64. The final Volume 3 however broke.

I wondered why, given they’re all pretty similar, so I started unpacking the .exe files, looking for information. What I found in the meta data was that Vol.0-2 have been using the TVP(Kirikiri) or maybe the forked [Kirikiri Z] game scripting engine, whereas Vol.3 swapped that for the [Ares CatSystem2] engine, for whatever reason. My assumption would be, that the CatSystem2 thingy was actually built for Vista+ for real, thus breaking XP compatibility. Plus, some other minor components are broken as well (some installers, patches, etc., just like the older volumes).

Now, I’ve already been talking to a guy called UncleVasya / Oleg Ovcharenko, who built a [stub DLL solution] for games based on the Clausewitz Engine (Europa Universalis 4, Hearts of Iron 4, Crusader Kings 2 and finally Stellaris), making it work on XP. It’s pretty similar to the XCOM hacks[1][2]. So I asked him about this one as well, and with quite some work and some additional (important) hints from him regarding the Steam version, I managed to make it run!

So, first things first: Thanks Oleg, you’re doing great work!

I will now show you how to make this visual novel / game work on XP x64 and XP, both for the slightly trickier Steam version (whether you choose to play the censored or the uncensored version doesn’t matter, the corresponding patch will be discussed as well), as well as the normal version.

Note: All screenshots in this post are 8-bit (256 color) PNG files. They may look a bit bad at times, but better than JPEG in the case of those specific images. Reason for not using truecolor PNG: 8-bit saves a ton of bandwidth.

2. How to make the non-Steam version work on XP / XP x64

Software required:

[Nekopara Vol.3]
[7-zip] archiver
NTCore [CFF Explorer] (optional; only needed for patches)
Olegs’ [patcher]

2a. The main game

First, buy the game and download it. Do not pirate it! You suck if you do (I actually fooled around with a pirated version as well, but only after buying the game). When running the installer, you’ll notice that it already breaks early on after invoking the launcher:

Nekopara Vol.3s' installer already breaks

Nekopara Vol.3s’ installer already fails to execute on XP

As you can see, it calls InitializeCriticalSectionEx(), which is a newer, Vista+ version of InitializeCriticalSection(), see the MSDN[1][2] for details. Since the new version works differently, you can’t just hex edit your way out of this one.

First, unpack Olegs’ patcher to some subdirectory of your choice. Then, unpack the Nekopara Vol.3 installer (the .exe file) into a subfolder using 7-zip, and look for a file called INSTALL.exe. Copy that file into the directory where Olegs patcher resides, so where files like xp_EU4_1.21.cmd and xp_Stellaris_1.6.cmd can be found.

Since the scripts from Oleg aren’t made for hacking our files, we’ll write a new one for this, let’s call it xp_installer.cmd. Edit that with a text editor, and add the following lines:

@ECHO OFF
rundll32.exe zernel32.dll,PatchFile INSTALL.exe

Make sure xp_installer.cmd, zernel32.dll and the INSTALL.exe from Nekopara are in the same directory, then execute xp_installer.cmd. either by just double clicking it, or by opening a cmd terminal and by running it from there. Like this (you don’t need to run the extra commands, they’re just there to show you more information):

Olegs’ patch doing its magic on INSTALL.exe!

After that, rename your original INSTALL.exe in the directory where you unpacked the Nekopara Vol.3 installer, creating a backup file. Copy the following files from the patcher directory back to the installer directory: INSTALL.exe, zernel32.dll, z3d9.dll, zs2_32.dll and normaliz.dll. The “z” files are now implementing the missing functions, while redirecting all the others to the real Windows libraries like kernel32.dll, d3d9.dll, ws2_32.dll etc.

You don’t need to repack anything, just run INSTALL.exe directly, and you’ll no longer be greeted with an error message, but with this:

The installer works now, great

Install the game to a directory of your choice. Now, if you click the NEKOPARAvol3.exe in the directory where the game was installed, the same launcher comes up again, but now it allows you to configure and play the actual game instead of installing it…

Nekopara Vol.3s’ launcher after installation

…or does it? Well, the “System settings” part’ll work, yes, but when clicking that alluring “Start” button, you’ll run into yet another wall:

Nekopara still won't execute due to GetTickCount64()

What now? GetTickCount64(), that’s what.

Guess which function call doesn’t exist on XP? See the MSDN[1][2] again. GetTickCount64() really is an improvement over GetTickCount(), but still, XP simply doesn’t have this either. As you can see from the title bar, the offending binary is cs2.exe, which is the actual game. We can get rid of the issue by using Olegs’ patcher again, so it’s the same process as with INSTALL.exe, just use this script instead, call it xp_cs2.cmd or something:

@ECHO OFF
rundll32.exe zernel32.dll,PatchFile cs2.exe

Again, in case something goes wrong, rename your original cs2.exe before copying back the patched version with its .dll files. After copying back, you can run the game either by invoking cs2.exe directly, or by launching it from the NEKOPARAvol3.exe launcher:

Running the non-Steam version of Nekopara Vol.3 on XP x64 (click to enlarge)

2b. Making patches work as well

Patches are essentially also just self-extracting archives that execute a launcher after unpacking. We’ll discuss the patch 11 in this case. Running it will produce a different kind of error (people who know the content restoration patches for the Steam version may have seen this error as well):

Nekopara Vol.3 patch failure, due to it not being “a valid Win32 application”.

This error means that the header of the binary is asking for a more modern platform. This may make sense, if the program really calls modern functions, but you know, there are modern applications that don’t ask for it and then fail with calls to things like GetTickCount64(), and there are programs which ask for a modern platform without ever having an actual need for it. The patchers are in the latter category of programs.

Unpack the patcher nekopara3_v11_update.exe using 7-zip, and look for a file called updater.exe. Create a backup copy of it, then open this file in NTCores’ CFF Explorer, and click on the “Optional Header” part. You’ll see something like this, I’ve marked the relevant lines with some red blocks for you:

updater.exe in CFF Explorer (click to enlarge)

The marked fields show values like 0006 and 0000, as you can see. The significant number is the last or rightmost, so 6 and 0. This corresponds to the platform target Windows NT 6.0, or in other words: Windows Vista. Just rewrite that to show the following numbers, then save the file:

Patch the header to NT 5.1 (click to enlarge)

NT 5.1 (0005, 0001) equals Windows XP. Note that the kernel versions 5.0 mean Windows 2000, 5.2 means Server 2003 or XP x64 (slightly more modern). Again, no need to repack anything, just save the file after the modifications have been made and execute updater.exe afterwards, you should be getting this:

Nekopara Vol.3 non-Steam patcher working on XP

And here we have a working patcher (click to enlarge)

Yay! And now, for the Steam version of Nekopara Vol.3…

3. How to make the Steam version work on XP / XP x64

Software required:

[Nekopara Vol.3] on Steam (a censored version)
[Content restoration patch] (optional; only required if you have to do perverted things to the cat girls)
at0ms’ [Steamless]
A Windows Vista or newer machine (needed to run Steamless, can be a virtual machine)
[7-zip] archiver
NTCore [CFF Explorer] (optional; only needed for the content restoration patch)
Olegs’ [patcher]

3a. The main game

First, buy the game on Steam and download it. If you really need the uncensored version (you probably do, heh?), buy the content restoration patch at Denpasoft and download that as well. Of course, running the game as-is won’t work, otherwise we wouldn’t need this article in the first place:

The Steam version of Nekopara Vol.3 breaks on XP as well of course, due to GetTickCount64() call, a newer and better version of GetTickCount(), see MSDN[1][2].

Now, what I didn’t get at first was that patching the Steam versions’ NEKOPARAvol3.exe can never work out of the box. The reason is, that the offending function calls aren’t plainly there for us to see – the actual game binary cs2.exe is encrypted and packed into a SteamStub binary as its payload data. This is a part of the Steamworks DRM system wrapping our program up.

To be able to patch it, we (unfortunately) need to crack its cryptographic DRM protection system first. Now, let me say this again: I do not condone piracy. Don’t fucking crack and distribute this game. You’re an ass if you do. Removing the DRM part is only being done so we can fix the game on XP, keep that in mind!

Well, let’s start; First, boot up a Vista or newer Windows, and install Steamless on it. I actually tried to compile Steamless for XP, but this is .Net 4.5.2 stuff. To make it work on .Net 4.0 would require modifications of its build files / source code, which is a bit over my head right now. So we’re stuck with needing a modern Windows OS to do this. Copy the problematic NEKOPARAvol3.exe from your Steam game installation directory over to that machine, or just install Steam and the game on the modern Windows OS as well (which is what I actually did).

Launch Steamless, open that .exe and decrypt / unpack it, Steamless will leave your binary alone, and create a new, fixed one, so you don’t need to create a manual backup copy:

Steamless cracking NEKOPARAvol3.exe (click to enlarge)

Copy the fixed file back to XP, and rename it back to NEKOPARAvol3.exe. Create a backup of the original .exe in your Steam game installation directory, while you’re at it.

Unpack Olegs’ patcher in a directory of your choice, and move the NEKOPARAvol3.exe there as well, that’s where files akin to xp_EU4_1.21.cmd and xp_Stellaris_1.6.cmd can be found. Since those patcher scripts aren’t targeted at Nekopara Vol.3, we’ll write our own, call it xp_neko_3.cmd or something, open it in a text editor and enter the following lines:

@ECHO OFF
rundll32.exe zernel32.dll,PatchFile NEKOPARAvol3.exe

Make sure that NEKOPARAvol3.exe, zernel32.dll and xp_neko_3.cmd are together in the same folder, then execute xp_neko_3.cmd either by double-clicking it, or by opening a cmd terminal and executing it from there. Like this:

Olegs' patcher handling the decrypted NEKOPARAvol3.exe

Olegs’ patcher handling the now-decrypted Steam version of NEKOPARAvol3.exe

Copy the fully fixed .exe back into the Steam game installation directory, together with the patchers’ stub libraries zernel32.dll, z3d9.dll, zs2_32.dll and normaliz.dll, which will handle the functions usually missing on XP.

Now, run the game either by executing NEKOPARAvol3.exe, or by launching it from within Steam, and you should be greeted with something like this:

Nekopara Vol.3 running on XP x64 in its Steam version (click to enlarge)

Great (or something)!

Please be aware that if the binary is ever overwritten by Steam because of some update or whatever, you have to re-do the procedure, meaning the Steamless unpacking plus applying Olegs’ patch. If the game terminates without any error when launched from within Steam, try to run NEKOPARAvol3.exe directly instead, and you’ll see the error messages – Steam tends to suppress them.

3b. The content restoration patch (this also applies to the patches for Nekopara Vol.1 and Vol.2)

So you want to lewd the cat girls? Perverted! Plus, Windows XP / XP x64 won’t let you, because the patch is asking for a newer platform (despite not actually requiring it though):

Nekopara Vol.3 content restoration patch failure on XP, due to the patch not being “a valid Win32 application”.

But if you absolutely have to, here’s how. Unpack the nekopara_vol3_Steam_R18DLC.exe you bought and downloaded from Denpasoft using 7-zip. Look for the file SteamPatch.exe, and open it in CFF Explorer:

The Nekopara Vol.3 Content restoration patchs’ SteamPatch.exe in CFF Explorer

Now, this is similar to the procedure described for updater.exe for a non-Steam versions’ patch. The significant (rightmost) numbers in the fields where it days 0006 and 0000 represent Windows NT 6.0, or in other words Windows Vista. Since the patcher doesn’t really need any Vista-specific functions, we’ll just fix the header that is currently asking for a NT 6.0 platform as follows:

Change the fields to 5.1 (0005 and 0001 respectively) to have it check for XP+ instead, and it’s fixed!

Save the file after modifying it. Just like for the non-Steam version patches, there is no need to repack anything. Just run updater.exe directly, and you’ll now get this:

The Nekopara Vol.3 content restoration patch for the Steam version working on XP x64. Because you’re in it for the Hentai.

There you go, pervert! You now have the fully restored version of Nekopara Vol.3 on Steam, running on XP or XP x64.

And last but not least: Thanks again, Oleg! I made you touch some weird shit, but you still fixed it and gave me the right ideas about the Steam version as well, yay!

4. Bonus feature: How to make Mechwarrior Online work on XP / XP x64 after their launcher upgrade

While entirely unrelated to the weird Japanese shit above, I’ll just mention this here as well, because it doesn’t deserve its own post, given the simplicity of the “solution”; Piranha Games decided to give Mechwarrior Online (MWO) a new game launcher called “MWO Portal”, that is now built with .Net 4.5.2, just like Steamless, breaking it on XP. Mind you, the game itself would still work just fine, even the 64-bit version on XP x64.

Windows XP / XP x64 users will likely never see this launcher work on their OS (Unless ExtendedXP really takes off, it’s pretty good already, but yeah).

Since hacking .Net 4.5 stuff to run on .Net 4 / .Net 4 CP is not something I can do yet, MWO would be gone from all XP machines. There is an easy fix for this though:

Get the game on Steam! The Steam version doesn’t include the launcher, as Steam itself is handling both the execution and the updates of MWO. Without the launcher, MWO still works just fine!

Automatically updating Microsoft Security Essentials (wherever it doesn’t work anymore…)

Security, Windows 2 Responses »

Jun 292017

Recently, I ran into another issue on my old Windows XP x64 machines, and on regular XP and Windows Vista boxes as well. Microsofts’ Security Essentials software – let’s just call it MSSE – stopped updating itself. Even more problematic was the fact that manual updates wouldn’t work anymore either. It would download the new definitions, but not install them. With no error messages to be found anywhere, I had no idea what to do. Ok, on XP x64, MSSE was never supported to begin with (the last 64-bit version 4.4.304.0 for Vista works though), but the problem also showed up on supported systems, maybe because of their EoL status.

Strangely though, sometimes it would work out of the blue, but mostly, it seems to be broken. This is specifically bad right now, because very recently, the Microsoft Malware Protection Engine that MSSE and many other Microsoft security products are based on has had some critical bugs resulting in potential remote code execution exploits (at the highest privilege levels). By just scanning a file – e.g. an attachment of an email – the code inside would be run and evaluated by the MMPE, and during that phase, the code could “break out” into the system, infecting it with god knows what.

So, updates are really important right now, or the security tool you may rely upon to protect you at least a little bit may become the most dangerous thing on your old XP x64, PosReady2009 XP or Vista box, and not just there but on more modern systems as well (The Windows Defender on Windows 7+ uses the same MMPE).

What I did was to download the full update pack mpam-fe.exe from Microsoft [here], and install it manually. Interestingly, this worked just fine. Based on that, I wrote a very simple little batch script, that automates the process. Only drawback: It relies on one external tool, namely wget.exe, needed to download the package from Microsoft. Sadly, Windows doesn’t seem to have a command line tool to do that on its own. You can get wget by installing [GNU on Windows], a collection of free UNIX command line tools built for Windows.

Once wget.exe is in your users’ search path, you can use the task scheduler to automate the launch of the following updater script (just save it as a .bat file somewhere):

```
@ECHO OFF
```

:: Fetch the most current AV definitions (%TEMP% doesn't need

:: to be quoted, because it returns a short path anyway):

wget.exe --no-check-certificate -O %TEMP%\mpam-fe.exe "https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64"

:: Install them, wait for 120 seconds, then delete the installer:

```
%TEMP%\mpam-fe.exe
```
```
CHOICE /C:AB /D:A /T:120 >NUL 2>&1
```
```
DEL /F %TEMP%\mpam-fe.exe
```
```
:: And we're done.
```
```
EXIT
```

I have no idea why the regular way of updating MSSE breaks on some systems, but now that I’ve been running the above script on my machines every night, MSSE is staying up to date pretty nicely. Ah yes, one thing: In case your system is 32-bit and not 64-bit, you need to change the URL being called by wget. Just replace the HTTP variable arch=x64 with arch=x86 in that script, and it’ll download the 32-bit version of mpam-fe.exe!

Also note that you can actually abort the 120 second wait by maybe accidentally pressing either A or B in the above example, because the delay is implemented in a weird way using CHOICE, since Windows XP doesn’t have a native sleep or wait command. If you want to prevent such accidents, you can make CHOICE use stranger characters that you would never be able to enter accidentally, like this for example:

And with that you can keep older machines using MSSE a tiny little bit more secure in case the auto-update breaks for you as well.

A HakuNeko 1.4.2 release for Windows (cross-compiled on Linux)

Anime & Manga, Linux, Powerful Tools, Programming, Scripting, Windows 2 Responses »

May 312017

1.) What for?

Usually, porting my favorite manga ripper [HakuNeko]^[1] would involve slightly more exotic target platforms like [FreeBSD UNIX]. This changed with version 1.4.2 however, as this version – the most current at the time of writing – would no longer compile on Windows machines due to some issues with its build toolchain. And that’s the most common platform for the tool!

This is what the lead developer had to say about the issue while even suggesting the use of [FMD] instead of HakuNeko on Windows:

“The latest release does not compile under windows due to some header include contradictions of sockets […]”
-in a [comment]^[1] to HakuNeko ticket #142 by [Ronny Wegener], HakuNeko project leader

^[1] Edit: Links have been fixed, as the HakuNeko project has now been moved to HakuNeko Legacy due to the development of its replacement, [HakuNeko S].

Normally I wouldn’t mind that much and keep using 1.4.1 for now, but unfortunately this is not an option. Quite a few Manga websites have changed by now, breaking compatibility with the previous version. As this is breaking most of HakuNekos’ functionality for some important sites, it became quite unusable on Windows, leaving Linux as the only officially supported platform.

As using virtual machines or remote VNC/X11 servers for HakuNeko proved to be too tedious for me, I thought I’d try to build this by myself. As the MSYS2/MinGW Windows toolchain seemed to be broken for 1.4.2, I tried – for the very first time – to cross-compile on Linux, choosing CentOS 7.3 x86_64 and MinGW32 4.9.3 for the task. This was quite the challenge, given that HakuNeko comes completely unprepared for cross-compiling.

2.) First, the files

Took me many hours / days to get it done – 100% statically linked too – and it’s finished now! What I won’t provide is an installer (don’t care about that), but here are my v1.4.2 builds for Windows:

[HakuNeko 1.4.2 for Win32] (MinGW32 4.9.3, statically linked against wxWigets 3.0.2, cURL 7.47.0 and OpenSSL 1.0.2h)
[HakuNeko 1.4.2 for Win32] (portable version, compiler & linking identical to above)

As of today, those versions have been tested successfully on the following operating systems:

Windows XP Professional SP3 / POSReady2009
Windows XP Professional x64 Edition SP2 w. Server 2003 updates
Windows Server 2003 R2 x64 SP2
Windows Vista Enterprise x64 SP2
Windows 7 Professional x64 SP1
Windows 10 Professional x64 build #1607

Please be aware that not all of the functionality has been tested by me, just a few downloads that wouldn’t have worked with 1.4.1, a few more random downloads here and there, plus chapter-wise .cbz packaging. It’s looking pretty good I think. Here are some sample screen shots as “proof” of it working (click to enlarge):

: HakuNeko 1.4.2 starting up on Windows 7, giving us an “update” notification (heh..)

: HakuNeko 1.4.2 running on Windows 7 after updating its Manga lists

HakuNeko 1.4.2 downloading “Kobayashi-san Chi no Maid Dragon” on XP x64 (Note: I own that Manga in paper form)

3.) What has been done to make this work?

3a.) Initial work:

First of all, cross-compiling is a bottomless, hellish pit, a horrible place that you never want to enter unless a.) The build toolchain of the software you wanna compile is very well prepared for it or b.) you really have/want to get your hands on that build or c.) you hate yourself so much you have to hurt yourself or d.) you actually enjoy c.).

The reasons for choosing cross-compiling were that Ronny Wegener had said, that the MSYS2/MinGW32 build would fail on Windows, plus it would require GCC version 5.3 to link with the bundled, pre-built static libraries (OpenSSL, cURL, wxWidgets).

So I thought it would be more likely to work if I were to run my own MinGW setup on Linux, not relying on the bundled stuff but linking against the libraries that come with MinGW32 4.9.3 on my platform of choice – CentOS 7.3 Linux.

One exception was the GUI library wxWidgets 3.0.2 that I had to cross-compile and statically link by myself as well, but luckily, that’s easy despite its size. wxWidgets is one piece of software that does come well-prepared for cross-compiling! In my case, that made it as simple as this (parallel compile with 6 CPUs):

$ ./configure --prefix=/usr/local/i686-w64-mingw32 --host=i686-w64-mingw32 --build=x86_64-linux \
 --enable-unicode --with-expat --with-regex --with-opengl --with-libpng --with-libjpeg --with-libtiff \
 --with-zlib --with-msw --enable-ole --enable-uxtheme --disable-shared
$ make -j6
# make install

3b.) HakuNeko build toolchain / Makefile modifications for cross-compiling:

HakuNeko is much harder, and I don’t even remember half of what I did, but most of it was manually editing the ./Makefile after $ ./configure --config-mingw32 would have produced something rather broken.

Let’s get to it, file paths are relative to the source root. First, edit the following parts of the ./Makefile (you need to look for them in different places of the file). First, the PREFIX, should be in the bottom half of the file:

PREFIX = /usr/local/i686-w64-mingw32/

CC and the CFLAGS:

CC = i686-w64-mingw32-g++
CFLAGS = -c -Wall -O2 -std=c++11 \
 -I/usr/local/i686-w64-mingw32/lib/wx/include/i686-w64-mingw32-msw-unicode-static-3.0 \
 -I/usr/local/i686-w64-mingw32/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -D__WXMSW__ -mthreads \
 -DCURL_STATICLIB -I/usr/i686-w64-mingw32/sys-root/mingw/include

Add -DPORTABLE, if you want to build the portable version of HakuNeko.

Then, the Windows resource compiler, controlled by RC and RCFLAGS:

RC = /usr/bin/i686-w64-mingw32-windres
RCFLAGS = -J rc -O coff -F pe-i386 -I/usr/i686-w64-mingw32/sys-root/mingw/include \
 -I/usr/local/i686-w64-mingw32/include

And finally, the static linking part, which is the hardest stuff to get done right, LD, LDFLAGS and LDLIBS:

LD = i686-w64-mingw32-g++
LDFLAGS = -s -static -static-libgcc -static-libstdc++ -mwindows -DCURL_STATICLIB
LDLIBS = -L/usr/local/i686-w64-mingw32/lib   -Wl,--subsystem,windows -mwindows \
 -lwx_mswu_xrc-3.0-i686-w64-mingw32 -lwx_mswu_webview-3.0-i686-w64-mingw32 \
 -lwx_mswu_qa-3.0-i686-w64-mingw32 -lwx_baseu_net-3.0-i686-w64-mingw32 \
 -lwx_mswu_html-3.0-i686-w64-mingw32 -lwx_mswu_adv-3.0-i686-w64-mingw32 \
 -lwx_mswu_core-3.0-i686-w64-mingw32 -lwx_baseu_xml-3.0-i686-w64-mingw32 \
 -lwx_baseu-3.0-i686-w64-mingw32 -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lcurl -lidn -liconv \
 -lssh2 -lssl -lcrypto -lpng -ljpeg -ltiff -lexpat -lwxregexu-3.0-i686-w64-mingw32 -lz -lrpcrt4 \
 -lwldap32 -loleaut32 -lole32 -luuid -lws2_32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 \
 -ladvapi32 -lwsock32 -lgdi32

Took a while to find the libraries (and static library order!) necessary to satisfy all the dependencies properly.

If you need it, here is the modified Makefile I’ve used to cross-compile:

[HakuNeko Makefile] for cross-compiling HakuNeko 1.4.2 for Windows on CentOS 7.3 x86_64 Linux (needs statically linked & installed wxWidgets first).

3c.) Source code modifications:

However, something will still not be quite right, because some of the crypto libraries will provide the MD5 functions MD5_Init(), MD5_Update() as well as MD5_Final(), and those are already defined by HakuNeko itself. This will break the static linking, as redundant definitions won’t work. We’ll rely on the libraries (libcrypto, libssl), and comment the built-in stuff out in src/v7/v7.c:

void MD5_Init(MD5_CTX *c);
void MD5_Update(MD5_CTX *c, const unsigned char *data, size_t len);
void MD5_Final(unsigned char *md, MD5_CTX *c);

…becomes:

/* void MD5_Init(MD5_CTX *c);
 * void MD5_Update(MD5_CTX *c, const unsigned char *data, size_t len);
 * void MD5_Final(unsigned char *md, MD5_CTX *c);
 */

On top of that, the configure system may have generated src/main.cpp as well as src/main.h. Those are bogus files, turning the entire tool into nothing but one large “Hello World” program. Plus, that’s hard to debug, as the binary won’t even output “Hello World” on a Windows terminal when it’s built as a GUI tool. I only found the issue when testing it with Wine on Linux.

Please delete src/main.cpp and src/main.h before continuing.

Now, if you’re really lucky, you should be able to run something like $ make -j6 and watch everything work out nicely. Or watch it crash and burn, which is the much, much more likely scenario, given I’ve likely only given you half of what I did to the build tools.

Well, in any case, no need to run $ make install of course, just grab the binary build/msw/bin/hakuneko.exe and copy it off to some Windows machine, then try to run it. If you’ve built the portable version, you may wish to rename the file to hakuneko-portable.exe, just like the official developers do.

4.) The future

Let’s just hope that the developers of HakuNeko can get this fixed for versions >=1.4.3, because I really, really don’t want to keep doing this. It’s extremely painful, as cross-compiling is exactly the kind of living hell I heard a lot of people saying it is! I think it’s a miracle I managed to compile and run it at all, and it was so frustrating and tedious for somebody like me (who isn’t a developer).

The statement that this took “hours / days” wasn’t an exaggeration. I think it was something like 10-12 man hours of pure frustration to get it done. I mean, it does feel pretty nice when it finally works, but I wouldn’t bet on myself being able to do this again for future versions…

So please, make it work on Windows again, if possible, and keep HakuNeko cross-platform! It’s still my favorite tool for the task! Thanks!

A build of 64-bit puTTY that works on XP x64 and Server 2003 x64

Powerful Tools, Programming, Windows 12 Responses »

Mar 132017

Anyone 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:

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

#elif defined _MSC_VER && defined _M_AMD64

```
 
```
```
  /*
```

   * 64-bit BignumInt, using Visual Studio x86-64 compiler intrinsics.

```
   *
```

   * 64-bit Visual Studio doesn't provide very much in the way of help

   * here: there's no int128 type, and also no inline assembler giving

   * us direct access to the x86-64 MUL or ADC instructions. However,

   * there are compiler intrinsics giving us that access, so we can

   * use those - though it turns out we have to be a little careful,

   * since they seem to generate wrong code if their pointer-typed

   * output parameters alias their inputs. Hence all the internal temp

```
   * variables inside the macros.
```
```
   */
```
```
 
```
```
  #include 
```

  typedef unsigned char BignumCarry; /* the type _addcarry_u64 likes to use */

```
  typedef unsigned __int64 BignumInt;
```
```
  #define BIGNUM_INT_BITS 64
```

  #define BignumADC(ret, retc, a, b, c) do                \

      {                                                   \

          BignumInt ADC_tmp;                              \

          (retc) = _addcarry_u64(c, a, b, &ADC_tmp);      \

          (ret) = ADC_tmp;                                \

```
      } while (0)
```

  #define BignumMUL(rh, rl, a, b) do              \

      {                                           \

          BignumInt MULADD_hi;                    \

          (rl) = _umul128(a, b, &MULADD_hi);      \

          (rh) = MULADD_hi;                       \

```
      } while (0)
```

  #define BignumMULADD(rh, rl, a, b, addend) do                           \

      {                                                                   \

          BignumInt MULADD_lo, MULADD_hi;                                 \

          MULADD_lo = _umul128(a, b, &MULADD_hi);                         \

          MULADD_hi += _addcarry_u64(0, MULADD_lo, (addend), &(rl));     \

          (rh) = MULADD_hi;                                               \

```
      } while (0)
```

  #define BignumMULADD2(rh, rl, a, b, addend1, addend2) do                \

      {                                                                   \

          BignumInt MULADD_lo1, MULADD_lo2, MULADD_hi;                    \

          MULADD_lo1 = _umul128(a, b, &MULADD_hi);                        \

          MULADD_hi += _addcarry_u64(0, MULADD_lo1, (addend1), &MULADD_lo2); \

          MULADD_hi += _addcarry_u64(0, MULADD_lo2, (addend2), &(rl));    \

          (rh) = MULADD_hi;                                               \

```
      } 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:

#elif defined _MSC_VER && defined _M_AMD64

```
 
```

  /* 32-bit BignumInt, using Visual Studio __int64 as BignumDblInt

   * This is compatible with VS2010 & VS2012 for building a x86_64

   * version of puTTY (no __int128 with those compilers).

```
   */
```
```
 
```
```
  typedef unsigned int BignumInt;
```
```
  #define BIGNUM_INT_BITS  32
```

  #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 using a modern SSH server (click to enlarge)

And:

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…

The final browser for Windows XP / XP x64: Firefox 52.0 ESR (And: Electrolysis / e10s multiprocessing support)

Software, Windows 1 Response »

Mar 082017

Firefox ESR dark logo 1.) 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:

: Firefox 51.0.1 is offering the ESR upgrade (click to enlarge)

: Firefox 51.0.1 Release is downloading Firefox 52.0 ESR (click to enlarge)

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 (click to enlarge)

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

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.e10sBlockedByAddons    [boolean]   false
extensions.e10sBlocksEnabling     [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

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…

Older Entries