Jul 122017

Windows XP dark age logoI 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:

  1. Western games
  2. 64-bit games officially supported on XP x64
  3. Weird Japanese shit
  4. 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!

Ok, let’s start:

1. Western Games

Here’s the normal stuff:

Dishonored logo1a. 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.


Legend of Korra logo

1b. Legend of Korra

Claims: Windows Vista
Developer & Engine: PlatinumGames, using their 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.


Life is strange logo

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.


Master of Orion (2016) logo

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.


Mechwarrior Online logo

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.


Stellaris logo

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

Claims: Windows 7
Developer & Engine: Paradox Development Studio, using their 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.


XCOM logo

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.

Vities Skylines logo

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+.


X-Plane 10 logo

2b. X-Plane 10

Claims: Windows XP or Windows XP x64 Edition
Developer & Engine: Laminar Research, using their 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:

A Magical Highschool Girl logo

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…


Crush Crush logo

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.


Hyperdimension Neptunia logo

3c. 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.


Valkyria Chronicles logo

3d. 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:

Chuusotsu First Graduation: Time after Time logo

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.


Fatal Twelve logo

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

Claims: Windows 7
Developer & Engine: Aiueo Kompany & Sekai Project, Ren’Py Engine (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!


Flowers -le Volume sur Printemps- logo

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!


Chusingura46+1 S logo

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.


Kindred Spirits on the Roof logo

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!


Ne no Kami: The two Princess Knights of Kyoto logo

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; 1½ playthroughs completed, both the censored and uncensored versions have been extensively tested.
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. :(


Nekopara logo

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.


Neko-nin exHeart logo

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.


Nurse Love Addiction logo

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

Claims: Windows 7
Developer & Engine: Kogado Studio, unknown engine
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.


Panzermadels logo

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.


Planetarian logo

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

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.


Season of 12 Colors logo

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.


Steins;Gate logo

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.


VA-11 HALL-A logo

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!

Jul 072017

Nekopara Vol.3 logo1. 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:

  1. [Nekopara Vol.3]
  2. [7-zip] archiver
  3. NTCore [CFF Explorer] (optional; only needed for patches)
  4. 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:

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

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

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

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:

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

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

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

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

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:

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

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

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:

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

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

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

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:

The Nekopara Vol.3 Content restoration patchs' SteamPatch.exe in CFF Explorer, fixed for XP

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

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.

The new MWOPortal launcher

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! :)

Jun 292017

Microsoft Security Essentials logoRecently, 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):

  1. @ECHO OFF
  2. :: Fetch the most current AV definitions (%TEMP% doesn't need 
  3. :: to be quoted, because it returns a short path anyway):
  4. wget.exe --no-check-certificate -O %TEMP%\mpam-fe.exe "https://go.microsoft.com/fwlink/?LinkID=121721&arch=x64"
  5. :: Install them, wait for 120 seconds, then delete the installer:
  6. %TEMP%\mpam-fe.exe
  7. CHOICE /C:AB /D:A /T:120 >NUL 2>&1
  8. DEL /F %TEMP%\mpam-fe.exe
  9. :: And we're done.
  10. 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:

  1. CHOICE /C:©® /D:® /T:120 >NUL 2>&1

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.

May 312017

HakuNeko logo1.) What for?

Usually, porting my favorite manga ripper [HakuNeko] 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] to HakuNeko ticket #142 by [Ronny Wegener], HakuNeko project leader

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:

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 downloading "Kobayashi-san Chi no Maid Dragon" on XP x64

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 \

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:

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


  1. /* void MD5_Init(MD5_CTX *c);
  2.  * void MD5_Update(MD5_CTX *c, const unsigned char *data, size_t len);
  3.  * void MD5_Final(unsigned char *md, MD5_CTX *c);
  4.  */

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! :)

Mar 132017

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

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

64-bit puTTY failure on XP x64

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

Mar 082017

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

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

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


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

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

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

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

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

Firefox 52.0 ESR reporting is version

Firefox 52.0 ESR reporting is version (Click to enlarge)

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

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

2.) Electrolysis / e10s

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

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

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

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

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

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

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

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

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

Feb 242017

Firefox + HTML5 + XP logo1.) Introduction & Explanation

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

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

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

2.) Making it work

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

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

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

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

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

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

HTML5+H.264 on Firefox not yet working

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

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


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

Adobe Primetime fully enabled

Adobe Primetime fully enabled (click to enlarge)

3.) Testing

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

Youtube confirming full HTML5 video support

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

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

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

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

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

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

There you go!

4.) Thanks

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

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

media.gmp-eme-adobe.visible		true

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

Feb 152017

GCC on CygWin logoStill using my aging XP x64, I recently tried to compile a newer version of the GNU compiler collection (GCC) on my equally aging installation of [CygWin], v1.7.35(0.287/5/3). Reason is that I can no longer update CygWin itself, because the project did away with NT5.x compatibility, so now you need Windows Vista or 7 for the latest version. Given that CygWin uses a rolling release model, you can’t get any “in between” versions later on. Also, despite my best efforts to make use of the great work of Peter Castros’ [CygWin Timemachine], I still haven’t managed to get a later version of CygWin that still supports XP. The later versions all have some kind of massive problem with the bash/sh permanently crashing and coredumping. No idea what the reason is.

And even if it would work, I’d still be stuck with GCC 5.3.0 or 5.4.0 or something. It’s not that I absolutely need a fresh C/C++ compiler right now, but it’s good to be prepared, especially when it comes to the adoption of modern C++ standards. Since I’m doing my own Windows builds of libav and ffmpeg (also: For a new x265-based benchmark project similar to my old [x264 benchmark]), I wanted to be able to use a current version.

On Linux and BSD UNIX, compiling and using a new version of GCC is surprisingly simple! On CygWin however, it bombed for me trying to build the JNI (Java Native Interface), and after disabling it, it stumbled over some mysteriously missing files while I was following [this guide].

Luckily, a commenter named Joaquin provided a [solution] for this: CygWin seems to be missing some prerequisites that need to be downloaded. A script for doing that is included in the ./contrib/ folder of the unpacked GCC source tree, ./contrib/download_prerequisites! Let’s have a look inside:

  1. # Download some prerequisites needed by gcc.
  2. # Run this from the top level of the gcc source tree and the gcc
  3. # build will do the right thing.

Sounds useful… and:

  1. # Necessary to build GCC.
  2. MPFR=mpfr-2.4.2
  3. GMP=gmp-4.3.2
  4. MPC=mpc-0.8.1

Aha! So we’re missing “mpfr”, “gmp” and “mpc”. [mpfr] is a floating-point math library, [gmp] is another arithmetic library, and [mpc]… well, a math library as well. I have no idea why my CygWin would be missing those, or maybe it just doesn’t have the required versions? Uhm, and the following:

  1. # Necessary to build GCC with the Graphite loop optimizations.
  2. if [ "$GRAPHITE_LOOP_OPT" = "yes" ] ; then
  3.   ISL=isl-0.15

[ISL] is optional, but I guess it’s useful? I’m not actually sure what it really does though. Whatever it is, just call that helper script before the configuration stage, and everything should be fine. While sitting inside the root of the unpacked source tree, for GCC version 6.3.0 in my case (make SURE to choose a --program-suffix, or installation might effectively annihilate your platform compiler!), do something like this on your CygWin terminal:

./configure --program-suffix=-6.3.0 --enable-languages=c,c++ --disable-shared 
make -j12
make install

I’m limiting myself to C/C++ here. I don’t need Fortran (I think) and the JNI component of the Java stuff breaks on CygWin anyway, so we’ll leave Java out. Also, we’ll have no link-time optimization (lto), but the important stuff will be there. The C++ shared library is disabled and I built the thing with -j12 to spawn 12 threads (or is it processes?) for speeding up the build, since I have 12 logical CPUs.

And that’s it!

To test things, I recompiled ffmpeg-3.2.4 with the new GCC 6.3.0 + yasm 1.3.0, and everything turned out just fine after rolling out the resulting ffmpeg.exe including some necessary CygWin libraries (cygwin1.dll and cygiconv-2.dll):

.\ffmpeg.exe -version | find /V "configuration"
ffmpeg version 3.2.4 Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 6.3.0 (GCC)
libavutil      55. 34.101 / 55. 34.101
libavcodec     57. 64.101 / 57. 64.101
libavformat    57. 56.101 / 57. 56.101
libavdevice    57.  1.100 / 57.  1.100
libavfilter     6. 65.100 /  6. 65.100
libswscale      4.  2.100 /  4.  2.100
libswresample   2.  3.100 /  2.  3.100
libpostproc    54.  1.100 / 54.  1.100

A quick test showed the ffmpeg binary can cleanly decode H.265/HEVC video and also other stuff like FLAC, so it’s looking good! :)

Nov 242016

Broken Windows logo[1] I know what I should do if a system service on Microsoft Windows starts crashing of course; Fixing it is the way to go! But sometimes you simply can’t, because the component causing a certain instability can’t be swapped out or updated. Now Windows services do have a mechanism for monitoring and restarting a service upon failure, but it seems that only works if the system gets an actual error code back from the service upon termination. But it doesn’t seem to work (at least for me) if the service just dies abnormally. Windows recognizes the service has stopped somehow of course, but the restart procedure just doesn’t kick in.

So I thought I’d do it myself, programmatically. And it’s actually pretty easy. I solved this with VBScript, Windows Batch and Mark Russinovichs’ pslist plus grep. So the prerequisites are:

  • Microsoft Windows (well, huh..)
  • MS Windows Script(ing) Host / VBScript, Windows should come with this preinstalled since Windows 2000.
  • [pslist]
  • [grep][src] (grep is optional, I used GNU grep 2.5.4 in this case, licensed under the [GPLv3+])

Make sure the pstools and grep are within your %PATH%, so Windows can find those .exe files. If you don’t want to use grep, you can also use Microsofts’ own find command, if your version of Windows has it.

I divided this into two small scripts. Since the main part is Batch, it might be problematic if you run it at very short intervals, checking for the services’ status, because you get a command window popping up on the desktop. Since most users wouldn’t want that, another script acts as a launcher, hiding the cmd.exe window so it’s run fully in the background without disturbing any potential users or administrators. The launcher looks like this, in my case it’s meant to watch over an Apache web server:

  1. Set WshShell = CreateObject("WScript.Shell")
  2. WshShell.Run chr(34) & "C:\Server\Scripts\monitor-httpd.bat" & Chr(34), 0
  3. Set WshShell = Nothing

And that script C:\Server\Scripts\monitor-httpd.bat we’re launching looks like this:

  1. @ECHO OFF
  2. FOR /F "tokens=* delims= usebackq" %%I IN (`pslist ^| grep httpd`) DO SET HTTPDSTATUS=%%I

A version relying on Microsoft find instead of GNU grep could look like this:

  1. @ECHO OFF
  2. FOR /F "tokens=* delims= usebackq" %%I IN (`pslist ^| find /I "httpd"`) DO SET HTTPDSTATUS=%%I

To get a services’ exact name, just launch services.msc from Start \ Run or run the command net start on a cmd terminal.

As you can see, this greps “httpd” from the process list and pushes its output into %%I and finally into %HTTPDSTATUS%. We have to use a FOR /F for that, as Windows has no way of pushing command outputs from subshells into shell variables like UNIX has (like e.g. var=`command` or var=$(command)). Then we check for the status of that variable. If it’s not defined, then the process http.exe was nowhere to be found! In that case we restart the associated system service (needs proper permissions!). If the variable is defined, we do nothing but unsetting it, since we can assume the service is operating normally. Or at the very least it’s running. ;)

You can automate that by using the Windows task scheduler:

Scheduling an Apache web server "watchdog"

Scheduling an Apache web server “watchdog” (German Windows)

Create a Schedule to your liking and you’re done! If you can afford the affected service to be down for 5 minutes and no longer, just run it every 4 minutes or so.

The solution shown above can easily be adapted to monitor and restart any Windows service you have, as long as the service isn’t fundamentally broken so that it wouldn’t even start up anymore. Also, you can do a lot more, like sending notification eMails with a command line mailer like [blat] when crashes do occur. Of course, this is only useful for services that crash rarely. If it dies every few minutes, you should reaaally fix it instead of just pushing the restart button all the time… ;)

And that’s that!

[1] © Mar.0007. Original Version for desktopwallpapers4.me.

Nov 192016

FreeBSD GMABoost logoRecently, after finding out that the old Intel GMA950 profits greatly from added memory bandwidth (see [here]), I wondered if the overclocking mechanism applied by the Windows tool [here] had leaked into the public after all this time. The developer of said tool refused to open source the software even after it turning into abandonware – announced support for GMA X3100 and X4500 as well as MacOS X and Linux never came to be. Also, he did not say how he managed to overclock the GMA950 in the first place.

Some hackers disassembled the code of the GMABooster however, and found out that all that’s needed is a simple PCI register modification that you could probably apply by yourself on Microsoft Windows by using H.Oda!s’ [WPCREdit].

Tools for PCI register modification do exist on Linux and UNIX as well of course, so I wondered whether I could apply this knowledge on FreeBSD UNIX too. Of course, I’m a few years late to the party, because people have already solved this back in 2011! But just in case the scripts and commands disappear from the web, I wanted this to be documented here as well. First, let’s see whether we even have a GMA950 (of course I do, but still). It should be PCI device 0:0:2:0, you can use FreeBSDs’ own pciconf utility or the lspci command from Linux:

# lspci | grep "00:02.0"
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
# pciconf -lv pci0:0:2:0
vgapci0@pci0:0:2:0:    class=0x030000 card=0x30aa103c chip=0x27a28086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller'
    class      = display
    subclass   = VGA

Ok, to alter the GMA950s’ render clock speed (we are not going to touch it’s 2D “desktop” speed), we have to write certain values into some PCI registers of that chip at 0xF0hex and 0xF1hex. There are three different values regulating clockspeed. Since we’re going to use setpci, you’ll need to install the sysutils/pciutils package on your machine via # pkg install pciutils. I tried to do it with FreeBSDs’ native pciconf tool, but all I managed was to crash the machine a lot! Couldn’t get it solved that way (just me being too stupid I guess), so we’ll rely on a Linux tool for this. Here is my version of the script, which I call gmaboost.sh. I placed that in /usr/local/sbin/ for global execution:

  1. #!/bin/sh
  3. case "$1" in
  4.   200) clockStep=34 ;;
  5.   250) clockStep=31 ;;
  6.   400) clockStep=33 ;;
  7.   *)
  8.     echo "Wrong or no argument specified! You need to specify a GMA clock speed!" >&2
  9.     echo "Usage: $0 [200|250|400]" >&2
  10.     exit 1
  11.   ;;
  12. esac
  14. setpci -s 02.0 F0.B=00,60
  15. setpci -s 02.0 F0.B=$clockStep,05
  17. echo "Clockspeed set to "$1"MHz"

Now you can do something like this: # gmaboost.sh 200 or # gmaboost.sh 400, etc. Interestingly, FreeBSDs’ i915_kms graphics driver seems to have set the 3D render clock speed of my GMA950 to 400MHz already, so there was nothing to be gained for me in terms of performance. I can still clock it down to conserve energy though. A quick performance comparison using a crappy custom-recorded ioquake3 demo shows the following results:

  • 200MHz: 30.6fps
  • 250MHz: 35.8fps
  • 400MHz: 42.6fps

Hardware was a Core 2 Duo T7600 and the GPU was making use of two DDR-II/667 4-4-4 memory modules in dual channel configuration. Resolution was 1400×1050 with quite a few changes in the Quake III configuration to achieve more performance, so your results won’t be comparable, even when running ioquake3 on identical hardware. I’d post my ~/.ioquake3/baseq3/q3config.cfg here, but in my stupidity I just managed to freaking wipe the file out. Now I have to redo all the tuning, pfh.

But in any case, this really works!

Unfortunately, it only applies to the GMA950. And I still wonder what it was that was so wrong with # pciconf -w -h pci0:0:2:0 0xF0 0060 && pciconf -w -h pci0:0:2:0 0xF0 3405 and the like. I tried a few combinations just in case my byte order was messed up or in case I really had to write single bytes instead of half-words, but either the change wouldn’t apply at all, or the machine would just lock up. Would be nice to do this with only BSD tools on actual FreeBSD UNIX, but I guess I’m just too stupid for pciconf