Jan 152015
 

4Kn logoWhile I’ve been planning to build myself a new RAID-6 array for some time (more space, more speed), I got interested in the latest and greatest of hard drive innovations, which is the 4Kn Advanced Format. Now you may now classic hard drives with 512 byte sectors and the regular Advanced Format also known as 512e, which uses 4kiB physical sector sizes, but emulates 512 byte sectors for compatibility reasons. Interestingly, [Microsoft themselves state], that “real” 4Kn harddrives, which expose their sector size to the operating system with no glue layers in between are only supported in Windows 8 and above. So even Windows 7 has no official support.

On top of that, Intel [has stated], that their SATA controller drivers do not support 4Kn, so hooking one such drive up to your Intel chipsets’ I/O controller hub (ICH) or platform controller hub (PCH) will not work. Quote:

“Intel® Rapid Storage Technology (Intel® RST) version 9.6 and newer supports 4k sector disks if the device supports 512 byte emulation (512e). Intel® RST does not support 4k native sector size devices.”

For clarity, to make 4Kn work in a clean fashion, it must be supported on three levels, from lowest to highest:

  1. The firmware: For mainboards, this means your system BIOS/UEFI. For dedicated storage controllers, the controller BIOS itself.
  2. The kernel driver of the storage controller, so that’s your SATA AHCI/RAID drivers or SAS drivers.
  3. Any applications above it performing raw disk access, whether kernel or user space. File system drivers, disk cloning software, low level benchmarks, etc.

Granted, 4Kn drives are extremely new and still very rare. There is basically only the 6TB Seagate enterprise drives available ([see here]) and then some Toshiba drives, also enterprise class. But, to protect my future investments in that RAID-6, I got myself a [Toshiba MG04ACA300A] 3TB drive, which was the only barely affordable 4Kn disk I could get, basically also the only one available right now besides the super expensive 6TB Seagates. That way I can check for 4Kn compatibility relatively cheaply (click to enlarge images):

If you look closely, you can spot the nice 4Kn logo right there. In case you ask yourselves “Why 4Kn?”, well, mostly cost and efficiency. 4kiB sectors are 8 times as large as classic 512 byte ones. Thus, for the same data payload you need 8 times less sector gaps, 8 times less synchronization markers and 8 times less address markers. Also, a stronger checksum can be used for data integrity. See this picture from [Wikipedia]:

Sectors

Sector size comparison (Image is © Dougolsen under the CC-BY 3.0 unported license)

Now this efficiency is already there with 512e drives. 512e Advanced Format was supposedly invented, because more than half the programs working with raw disks out there can’t handle variable sector sizes and are hardcoded for 512n. That also includes system firmwares, so your mainboards’ BIOS/UEFI. To solve those issues, they used 4kiB sectors, then let a fast ARM processor translate them into 512 byte sectors on the fly to give legacy software something it could understand.

4Kn on the other hand is the purist, “right” approach. No more emulation, no more cheating. No more 1GHz ARM dual core processor in your hard drive just to be able to serve data fast enough.

Now we already know that Intel controllers won’t work. For fun, I hooked it up to my ASUS P6T Deluxes’ secondary SATA controller though, a Marvell 88SE6120. Plus, I gave the controller the latest possible driver, the quite hard-to-get version 1.2.0.8400. You can download that [here] for x86 and x64.  To forestall the result: It doesn’t work. At all. This is what the systems’ log has to say about it (click to enlarge):

So that’s a complete failure right there. Even after the “plugged out” message, the timeouts would still continue to happen roughly every 30 seconds, accompanied by the whole operating system freezing for 1-2 seconds every time. I cannot say for any other controllers like the Marvell 9128 or Silicon Image chips and others, but I do get the feeling that none of them will be able to handle 4Kn.

Luckily, I do already have the controller for my future RAID-6 right here, an Areca ARC-1883ix-12, the latest and greatest tech with PCIe x8 3.0 and SAS/12Gbit ports with SATA/6Gbit encapsulation. Its firmware and driver supports 4Kn fully as you can see in Arecas [specifications]. The controller features an out-of-band management system via its own ethernet port and integrated web server for browser-based administration, even if the system doesn’t even have any OS booted up. All that needs to be installed on the OS then is a very tiny driver (click to enlarge):

Plus, Areca gives us one small driver for many Windows operating systems. Only for the Windows XP 32-Bit NT5.1 kernel you’ll get a SCSI Miniport driver exclusively, while all newer systems (WinXP x64, Windows Vista, 7, 8) get a more efficient StorPort driver. So, plugged the controller in, installed the driver, hooked up the disk, and it seems we’re good to go:

The 4Kn drive is being recognized

The 4Kn drive is being recognized (click to enlarge)

Now, any legacy master boot record (MBR) partition table has a 32-bit address field. That means, it can address 232 elements. With each element being 512 bytes large, you reach 2TiB. So that’s where the 2TiB limit comes from. With 4Kn however, the smallest addressable atom is now eight times as large: 4096 bytes! So we should be able to reach 16TiB due to the larger sector size. Supposedly, some USB hard drive manufacturers have used this trick (by emulating 4Kn) to make their larger drives work easily on Windows XP. When trying to partition the Toshiba drive however, I hit a wall, as it seems Windows disk management is about as stupid as was the FAT32 formatter on Windows 98:

MBR initialization failed

MBR initialization failed (click to enlarge)

That gets me thinking. On XP x64, I can still just switch from MBR to the GPT partitioning scheme to be able to partition huge block devices. But what about Windows XP 32-bit? I don’t know how the USB drive manufacturers do it, so I can only presume they ship the drives pre-partitioned if its one of those that don’t come with a special mapping tool for XP. In my case, I just switch to GPT and carry on (click to enlarge):

Now I guess I am the first person in the world to be able to look at this, and potentially the last too:

fsutil.exe showing a 4Kn drive on XP x64

fsutil.exe showing a native SATA 4Kn drive on XP x64, encapsulated in SAS. Windows 7 would show the physical and logical sector size separately due to its official 512e support. Windows XP always reports the logical sector size (click to enlarge)

So far so good. The very first and most simple test? Just copy a file onto the newly formatted file system. I picked the 4k (no pun intended) version of the movie “Big Buck Bunny”:

Copying a first file onto the 4Kn disks NTFS file system

Copying a first file onto the 4Kn disks NTFS file system

Hidden files and folders are shown here, but Windows doesn’t seem to want to create a System Volume Information\ folder for whatever reason. Other than that it’s very fast and seems to work just nicely. Since the speed is affected by the RAID controllers write back cache, I thought I’d try HD Tune 2.55 for a quick sequential benchmark. Or in other words: “Let’s hit our second legacy software wall” (click to enlarge):

Yeah, so… HD Tune never detects anything above 2TiB, but this? At first glance, 375GB might sound quite strange for a 3TB drive. But consider this: 375 × 8 = 3000. What happened here is that HD Tune got the correct sector count of the drive, but misinterpreted each sectors’ size as 512 bytes. Thus, it reports the devices’ size as eight times as small. Reportedly, this is also the exact way how Intels RST drivers fail when trying to address a 4Kn drive. HD Tune 2.55 is thus clearly hardcoded for 512n. There is no way to make this work. Let’s try the paid version of the tool which is usually quite ahead of its free and legacy counterpart (click to enlarge):

Indeed, HD Tune Pro 5.00 works just as it should when accessing the raw drive. Users who don’t want to pay are left dead in the water here. Next, I tried HDTach, also an older tool. HDTach however reads from a formatted file system instead of from a raw block device. The file system abstracts the device to a higher level, so HDTach doesn’t know and doesn’t need to know anything about sectors. As a result, it also just works:

HD Tach benchmarking NTFS on a 4Kn drive

HD Tach benchmarking NTFS on a 4Kn drive (click to enlarge)

Next, let’s try an ancient benchmark, that again accesses drives on the sector level: The ATTO disk benchmark. It is here where we learn that 4Kn, or generally variable sector sizes aren’t space magic. This tool was written well before the times of 512e or 4Kn, and look at that (click to enlarge):

Now what does that tell us? It tells us, that hardware developers feared the chaotic ecosystem of tools and software that accesses disks at low levels. Some might be cleanly programmed, where most may not. That doesn’t just include operating systems’ built-in toolsets, but also 3rd party software, independently from the operating system itself. Maybe it also affects disk cloning software like from Acronis? Volume shadow copies? Bitlocker? Who knows. Thing is, to be sure, you need to test that stuff. And I presume that to go as far as hard drive manufacturers did with 512e, they likely found one abhorrent hell of crappy software during their tests. Nothing else will justify ARM processors at high clock rates on hard drives just to translate sector sizes plus all the massive work that went into defining the 512e Advanced Format standard before 4Kn Advanced Format.

Windows 8 might now fully support 4Kn, but that doesn’t say anything about the 3rd party software you’re going to run on that OS either. So we still live in a Windows world where a lot of fail is waiting for us. Naturally, Linux and certain UNIX systems have adapted much earlier or have never even made the mistake of hardcoding sector sizes into their kernels and tools.

But now, to the final piece of my preliminary tests: Truecrypt. A disk encryption software I still trust despite the project having been shut down. Still being audited without any terrible security hole discoveries so far, it’s my main choice for cross-platform disk encryption, working cleanly on at least Windows, MacOS X and Linux.

Now, 4Kn is disabled for MacOS X in Truecrypts source code, but seemingly, this [can be fixed]. I also discovered that TC will refuse to use anything other than 512n on Linux if Linux kernel crypto is unavailable or disabled by the user in TC, see this part of Truecrypts’ CoreUnix.cpp:

#if defined (TC_LINUX)
if (volume->GetSectorSize() != TC_SECTOR_SIZE_LEGACY)
{
  if (options.Protection == VolumeProtection::HiddenVolumeReadOnly)
    throw UnsupportedSectorSizeHiddenVolumeProtection();
 
  if (options.NoKernelCrypto)
    throw UnsupportedSectorSizeNoKernelCrypto();
}
#endif

Given that TC_SECTOR_SIZE_LEGACY equals 512, it becomes clear that hidden volumes are unavailable as a whole with 4Kn on Linux, and encryption is completely unavailable altogether if kernel crypto isn’t there. So I checked out the Windows specific parts of the code, but couldn’t find anything suspicious in the source for data volume encryption. It seems 4Kn is not allowed for bootable system volumes (lots of “512’s” there), but for data volumes it seems TC is fully capable of working with variable sector sizes.

Now this code has probably never been run before on an actual SATA 4Kn drive, so let’s just give it a shot (click to enlarge):

Amazingly, Truecrypt, another software written and even abandoned by its original developers before the advent of 4Kn works just fine. This time, Windows does create the System Volume Information\ folder on the file system within the Truecrypt container, and fsutil.exe once again reports a sector size of 4096 bytes. This shows clearly that TC understands 4Kn and passes the sector size on to any layers above itself in the kernel I/O stack flawlessly (The layer beneath it should be either the NT I/O scheduler or maybe the storage controller driver directly and the layer above it the NTFS file system driver, if my assumptions are correct).

Two final tests for data integrities’ sake:

Both a binary diff and SHA512 checksums prove, that the data copied from a 512n medium to the 4Kn one is still intact

Both a binary diff and SHA512 checksums prove, that the data copied from a 512n medium to the 4Kn one is still intact

So, my final conclusion? Anything that needs to work with a raw block device on a sector-by-sector level needs to be checked out before investing serious money in such hard drives and storage arrays. It might be cleanly programmed, with some foresight. It also might not.

Anything that sits above the file system layer though (anything that reads and writes folders and files instead of raw sectors) will always work nicely, as such software does not need to know anything about sectors.

Given the possibly enormous amount of software with hardcoded routines for 512 byte sectors, my assumption would be that the migration to 4Kn will be quite a sluggish one. We can see that the enterprise sector is adapting first, clearly because Linux and UNIX systems adapt much faster. The consumer market however might not see 4Kn drives anytime soon, given 512 byte sectors have been around for about 60 years (!) now.

Update 2014-01-16 (Linux): I just couldn’t let it go, so I took the Toshiba 4Kn drive to work with me, and hot plugged it into an Intel ICH10R. So that’s the same chipset as the one I ran the Windows tests on, an Intel X58. Only difference is, that now we’re on CentOS 6.6 Linux running the 2.6.32-504.1.3.el6.x86_64 kernel.  This is what dmesg had to say about my hotplugging:

ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: ATA-8: TOSHIBA MG04ACA300A, FP2A, max UDMA/100
ata3.00: 732566646 sectors, multi 2: LBA48 NCQ (depth 31/32), AA
ata3.00: configured for UDMA/100
ata3: EH complete
scsi 2:0:0:0: Direct-Access     ATA      TOSHIBA MG04ACA3 FP2A PQ: 0 ANSI: 5
sd 2:0:0:0: Attached scsi generic sg7 type 0
sd 2:0:0:0: [sdf] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
sd 2:0:0:0: [sdf] Write Protect is off
sd 2:0:0:0: [sdf] Mode Sense: 00 3a 00 00
sd 2:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 2:0:0:0: [sdf] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
 sdf:
sd 2:0:0:0: [sdf] 732566646 4096-byte logical blocks: (3.00 TB/2.72 TiB)
sd 2:0:0:0: [sdf] Attached SCSI disk

Looking good so far, also the Linux kernel typically cares rather less about the systems BIOS, bypassing whatever crap it’s trying to tell the kernel. Which is usually a good thing. Let’s verify with fdisk:

Note: sector size is 4096 (not 512)
 
WARNING: The size of this disk is 3.0 TB (3000592982016 bytes).
DOS partition table format can not be used on drives for volumes
larger than (17592186040320 bytes) for 4096-byte sectors. Use parted(1) and GUID 
partition table format (GPT).

Now that’s more like it! fdisk is warning me, that it will be limited to addressing 16TiB on this disk. A regular 512n or 512e drive would be limited to 2TiB as we know. Awesome. So, I created a classic MBR style partition on it, formatted it using the EXT4 file system, and mounted it. And what we get is this:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sdf1             2.7T   73M  2.6T   1% /mnt/sdf1

And Intel is telling us that they don’t manage to give us any Windows drivers that can do 4Kn? Marvell doesn’t even comment on their inabilities? Well, suck this: Linux’ free driver for an Intel ICH10R south bridge (or any other that has a driver coming with the Linux kernel for that matter) seems to have no issues with that whatsoever. I bet it’s the same with BSD. Just weak, Intel. And Marvell. And all you guys who had so much time to prepare and yet did nothing!

Update 2014-01-20 (Windows XP 32-Bit): So what about regular 32-Bit Windows XP? There are stories going around that some USB drives with 3-4TB capacity would use a 4Kn emulation (or real 4Kn, bypassing the 512e layer by telling the drive firmware to do so?), specifically to enable XP compatibility without having to resort to special mapping tools.

Today, I had the time to install XP SP3 on a spare AMD machine (FX9590, 990FX), which is pretty fast thanks to a small, unused testing SSD I still had lying around. Before that I wiped all GPT partition tables from the 4Kn drive, both the one at the start as well as the backup copy at the end of the drive using dd. Again, for this test, the Areca ARC-1883ix-12 was used, now with its SCSI miniport driver, since XP 32-Bit does not support StorPort.

Please note, that this is a German installation of Windows XP SP3. I hope the screenshots are still understandable enough for English speakers.

Recognition and MBR initialization seems to work just fine this time, unlike on XP x64:

The 4Kn Toshiba as detected by Windows XP Pro 32-Bit SP3, again on an Areca ARC-1883ix-12

The 4Kn Toshiba as detected by Windows XP Pro 32-Bit SP3, again on an Areca ARC-1883ix-12 (click to enlarge)

Let’s try to partition it:

Partitioning the drive once more, MBR style

Partitioning the drive once more, MBR style

Sure looks good! And then, we get this:

A Master Boot Record, Windows XP and 4Kn: It does work after all

A Master Boot Record, Windows XP and 4Kn: It does work after all (click to enlarge)

So why does XP x64 not allow for initialization and partitioning of a 4Kn drive using MBR? Maybe because it’s got GPT for that? So in any case, it’s usable on both systems, the older NT 5.1 (XP 32-Bit) as well as the newer NT 5.2 (XP x64, Server 2003). Again, fsutil.exe confirms proper recognition of our 4Kn drive:

fsutil.exe reporting a 4kiB sector size, just like on XP x64

fsutil.exe reporting a 4kiB sector size, just like on XP x64

So all you need – just like on XP x64 – is a proper controller with proper firmware and drivers!

There is one hard limit here though that XP 32-Bit users absolutely need to keep in mind; Huge RAID volumes using LUN carving/splitting and software JBOD/disk spanning using Microsofts Dynamic Volumes are no longer possible when using 4Kn drives. Previously, you could tell certain RAID controllers to just serve huge arrays to the OS in 2TiB LUN slices (e.g. best practice for 3ware controllers on XP 32-Bit). Then, in Windows, you’d just make those slices Dynamic Volumes and span a single NTFS file system over all of them, thus pseudo-breaking the 2TiB barrier.

This can no longer be done, as Dynamic Volumes seemingly do not work with 4Kn drives on Microsoft operating systems before Windows 8, or at least not on XP 32-Bit. The option for converting the volume from MBR to GPT is simply greyed out in Windows disk management.

That means that the absolute maximum volume size using 4Kn disks on 32-Bit Windows XP is 16TiB! On XP x64 – thanks to GPT – it’s just a few blocks short of 256TiB, a limit imposed on us by the NTFS file systems’ 32-bit address field and 64kiB clusters, as 232 * 64KiB × 1024 × 1024 × 1024 = 256TiB.

And that concludes my tests, unless I have time and an actual machine to try FreeBSD or OpenBSD UNIX. Or maybe Windows 7. The likelihood for that is not too high at the moment though.

Sep 062014
 

The Grim Dawn logoGame compatibility is generally becoming a major issue on Windows XP and XP x64, and I’m not even talking about Direct3D 10/11 here. Microsofts own software development kits and development environments (VisualStudio) come preconfigured in a pretty “Anti-XP” way these days, even if you intend to just build Direc3D 9 or OpenGL 4 applications with it.

There are examples where even Indie developers building Direct3D 9.0c games refuse to deal with the situation in any way other than “Please go install a new OS”, Planetary Annihilation being the prime example. Not so for Grim Dawn though, a project by a former Titan Quest developer which I [helped fund] on Kickstarter a while back. In their recent build numbered B20, an issue arose that seemed to be linked to XP exclusively. See this:

Grim Dawn B20 if_indextoname() Bug

Grim Dawn B20 if_indextoname() bug, in this case on a German 32-Bit Windows XP. Looks similar on XP x64 though. © by [Hevel].

More information can be seen in the corresponding Grim Dawn [forum thread], where I and others reported the issue, determining that it was on XP only in the process. That thread actually consists of two issues, just focus on the if_indextoname() one. This is also documented at [Microsofts MSDN library].

The function seems to be related to DNS name resolution and is a part of the Windows IP Helper API on Windows Vista and newer.  if_indextoname() does however not exist on any NT5.x system, which means Windows 2000, XP and 2oo3 Server which includes XP x64 and there is no fallback DLL. My assumption is, that this happened because of the newly added multiplayer netcode in the game.

Now the interesting part: After me and a few other XP users reported the issue starting on the 30th of August, it took the developers only 3 days to roll out a hotfix via Steam, and all was good again! I believe nowadays you can judge developers by how well they support niche systems, and in this case support was stellar. It may also have something to do with the Grim Dawn developers actively participating in their forums of course. That’s also great, as you can interact with them directly! No in-between publisher customer support center crap, but actually people who know their stuff, ’cause they’re the ones building it!

So I’d like to say a big “Thank you, and keep up the good work!” here!

Jun 162014
 

Zune LogoAnyone remember Microsoft Zune? No? Maybe because it’s dead. Well, one day Microsoft thought that Apple got a bit too powerful in the multimedia business, and late to the game as the guys from Redmond usually are, they launched their counterpart when the battle was already lost – in 2006. To promote their music service and their dedicated WMA (ew!) players a bit, they also released a free (as in freeware of course) Zune theme for Windows XP. Now while I’m a XP x64 freak, I don’t usually care about Luna UI themes since I’m using plain GDI, but a guy I know said that he used it back then, for the eye candy.

So, since it’s a bit quiet on the Linux and UNIX front lines right now, I felt a little bit more stupid than usual today! I thought I’d go ahead and install myself some Zune Theme, that can strangely still be [downloaded] from Microsoft at the time of writing.

Well, na-ah. It’ll just tell you, that you need “Windows XP SP2” for that. On XP x64 SP2 that is. Since it’s a MSI installer package, I thought I’d take a look with the [Orca resource editor]. And well, what do we have here…

Orca, inspecting the WinXP Zune theme installer

Orca, inspecting the WinXP Zune theme installer (click to enlarge)

For things that should work but don’t, it’s usually the LaunchCondition resource causing the trouble. Here we can see the rule that checks your system before letting the setup actually install anything:

  • ( ( VersionNT = 501 ) AND ( ServicePackLevel >= 2 ) )

So, what does that mean? I mean, besides “Fu, XP x64 users!”. Well, it’s checking the kernel version (5.1) and service pack level (equal to or greater than 2). The service pack level is ok, it’s the kernel check that’s troublesome, since XP x64 has a newer kernel with version number 5.2.3790. We’re interested in the “5.2” part. Now most users on the web just delete the entire LaunchCondition resource, but that’s not very smart, as it’d make the software installable on Vista, 7, etc. It’s not a clean way to do it! To do it the right way, we need to extend the rule and make this installable on XP only, but still on NT 5.1 (Windows XP 32-Bit) as well as NT 5.2 (Windows XP Professional x64 Edition and Server 2003). Like this:

  • ( ( ( ( VersionNT = 501 ) OR ( VersionNT = 502) ) AND ( ServicePackLevel >= 2) )

This means “we need NT 5.1 or NT 5.2, but in both cases we also need service pack 2”. This works just fine. See here, in Orca:

Orca, after modifying the Zune theme installer

Orca, after modifying the Zune theme installer (click to enlarge)

After saving the modified file, you can just launch the Zune theme installer on XP x64 as usual, and it’ll work. After resetting a few things like the larger scrollbars and title bars back to my pixel saver settings, it’ll look somewhat like this:

Applied and slightly modified Zune theme on XP x64

Applied and slightly modified Zune theme on XP x64 (click to enlarge)

The task bar is still too thick here, but I guess we can’t shrink that. If you have a filled up tray on a two-line task bar it’ll now be three icons high instead of just two. So yes, this does still consume more screen real estate than plain Win2000-style GDI does. But well, just in case you want to get the Zune theme to install on your XP x64 box “the right way”, here it is!

Oh, and if you don’t want to do it by yourself, I’ll provide the modified theme here, just remember: If you don’t trust me or the files I’m hosting here, you can always do the modification yourself!

Apr 022014
 

ADATA logoIn the past, ADATA has been known for its budget series of solid state drives, but never really for any killer products. That place has recently been taken by the likes of Intel, Samsung and Crucial amongst a few others. Now it seems that ADATA has seen enough mediocrity and is reaching for the top of the line. Based on a Marvell 88SS9189 – just like the Crucial M550 1TB drive – the new ADATA Premier Pro SP920 boasts the same 1TB capacity, some 20nm Micron NAND, a SATA/6Gbps interface and a somewhat more rich kit than Crucial does, for roughly the same price.

ADATA Premier Pro SP920 1TB announcement

ADATA Premier Pro SP920 1TB announcement

While the disk is available in smaller capacities of 128GB, 256GB and 512GB too, only the largest ones with 512GB and 1TB will make use of the full potential of NAND flash parallelism, reaching 4k random read IOPS close to 100k and write IOPS close to 90k with read and write transfer rates beyond the 500MB/s wall. The good thing about this drive – just as with the Crucial m550 – is that we finally get some large SSDs for a relatively affordable price. But that alone wouldn’t really interest me that much, now would it?

The thing that really piqued my interest was the fact that ADATA decided to develop their own SSD toolbox, which comes in the form of a tiny, single “SSDTool.exe” file. The rather slim tool features most important features, the ATA TRIM command above all. So ADATA is now joining the ranks of the manufacturers backporting TRIM to Windows XP and Windows XP Pro x64 Edition as the fourth member, limited to Intel, Samsung and Corsair before that. I had to give that a try immediately of course, again on XP x64, see here:

Please note that since I did not really have any supported ADATA drive available, some functionality of the ADATA SSD toolbox naturally wasn’t available to me. But as we can see, all the important stuff is there, just like on other well-developed SSD toolboxes such as the one made by Intel. There are the OS tweaks, TRIM of course, host writes information, firmware update functionality, S.M.A.R.T. and secure erase. And it works just fine on XP / XP x64 as far as I can see.

If you want to check out which ADATA SSDs are currently supported by SSDTool.exe, please check out the [compatibility list] on ADATAs download page (just scroll down a bit)! Also, if you want to learn more about the functionality before installing, a [manual] is available.

Please note that Windows XP and Windows XP Pro x64 Edition are however not officially supported, so this is subject to change any time. This is also the reason why I decided to offer a download of the current version 1.2 of the toolbox right here:

  • [ADATA SSD Toolbox version 1.2] (use the checksums below to compare with the version provided by ADATA)
    • md5 checksum: 942b8920a1d3e97a4c33d817220eb1ff
    • SHA1 checksum: a996ccc8edae8916f7f7f2cf372d8527bd912015
    • SHA512 checksum: 0fe1e18c184c19dab83060351238043f18a47e570d8cab3139566490fe3c03f66a \
    • 38736527143a62167163f736d79eb14000b9ecc00a9482e0b4ed7dc6122bb9

So there you go! While this may not stay compatible to XP forever regarding future SSD releases, it should work just fine with the current ones, like the massive 1TB Premier Pro SP920! So besides Intel, Samsung and Corsair, this opens up a fourth option for steadfast XP users who wish to use a large and fast SSD!

Update, 2014-04-07: Just to make sure whether my assumptions were correct and to probe ADATA support, I actually sent them a request a few days ago, asking whether their SSD toolbox started up on Windows XP unintentionally, or whether support is official. Also, I asked if the thing actually really works with an ADATA SSD, since I didn’t have any around to test it. Now guess what…

ADATA support actually informed me, that they would need to ask the tech guys or whatever to test it out, as they were not aware of this. So somebody at ADATA actually fired up a Windows XP machine with an ADATA SSD, installed their SSD toolbox and tested its functionality. Just now, one day before the end of official Microsoft support for Windows XP ADATA let me know, that their tests were successful, and that they will update their manual on the website accordingly. Holy shit! Now that level of support I’d call awesome! Who else goes that extra mile these days? Makes the Premier Pro SP920 all the more attractive, at least for me. :)

Mar 312014
 

South Park: The stick of truth logoWhile marching towards the supposed “end” of my favorite operating system on the Microsoft side of things, there is a small piece of good news. So let’s get to the simple part first: The new South Park game, title “The Stick of Truth” works fine on Windows XP Professional x64 Edition SP2. The Steamworks title explicitly states “Windows XP SP3” on Steam, which would be the 32-Bit version only. Still, no hacking, no tricks, you just click on it and it works. So that’s that. There is however a more problematic issue at had with that game, and that’s the censorship.

Allegedly self-censored on certain target platforms and markets, the game isn’t easily obtained in its uncut form, depending on where you’re sitting and what machine you’re playing on. In the USA, there won’t be much of a problem. In Australia it’s getting troublesome, and same goes for the EU. I’ve been researching a bit, and it seems all versions released to the German and Austrian markets received the maximum cut. That would mean some anal probing and abortion scenes (Ubisofts self-censoring) are gone just as well as the Nazi zombie swastikas and Nazi zombie salutes (Not sure whether self-censored or a result of the German and Austrian constitutions, likely the latter).

It doesn’t end there though: Due to “marketing reasons” it appears to be the case that the UK console versions still have the swastikas, but not the other scenes, such as the anal probing. The UK PC version however remains 100% uncut. What a chaos. Also, the Nazi censorship in Austria and Germany is questionable at best. While portrayal of such imagery on TV is legal, as long as it is done for either making fun of the Nazis (“artistic purposes”) or for historical purposes, this is not the case for interactive games, even if all you may do in such games is fight and kill the Nazis. Or hilarious Nazi zombies, in this case.

Now, you can buy the US version and import it to Germany of course, but this being a Steamworks title, you can’t activate the game on Steam, plus there might be issues with customs. And no activation means no play anyway. You could open up a VPN tunnel to a United States gateway and activate by pretending you’re sitting in the States, but I didn’t want to do crap like that. Instead I tried my luck with the UK PC version, as it was supposed to be uncut and within the EMEA region. So would it allow me to activate it, and would it download the correct version?

Luckily, the answer is yes to both:

Oh, and there are even Nazi zombie animals to encounter. Not to spoil you too much here, so I won’t tell you which ones. But you can be sure, you’ll see tons of stuff that you know from the TV series, and the game delivers around 20 hours of nonsense-filled South Park action. While a little short for a role-playing game, I would say that it’s just fine for this specific one here.

And the important thing: If you’re sitting in the EMEA region or Russia, just get the UK version, stay on the PC and switch your Steam to English. Then nothing can go wrong and you’ll experience the game as it was intended by the creators, Matt Stone and Trey Parker.

The interesting part is, that [this Austrian game store] actually does sell the [US uncut version] and also the [UK uncut version] (it says there you need VPN to the UK for that too, which proved to be untrue), so how illegal can it be?! Probably not at all. Just like it was with “The Witcher”, for some games it’s still best to get the UK version!

Jan 072014
 

XCOM: Enemy Within logoA while ago I have published an [article] describing the modifications and source code published by the Steam forum users KawaiiSara and ScavengerSpb to deal with XCOM: Enemy Unknown not running on Windows XP (dealt with by KawaiiSara) and Windows XP Pro x64 Edition (dealt with by ScavengerSpb). In short, what they did was to map certain kernel32.dll API calls that only exist on >=Vista to a Microsoft compatibility DLL called fileextd.dll. This is officially supported by Microsoft on Windows XP in fact, but some developers choose not to use it, or maybe they simply don’t know about it. The proper header file fileextd.h would be available in the Microsoft platform SDK, but my assumption still is, that the developers of XCOM have no clue about this. I tried to tell them, but I presume that my suggestion never reached the development team, getting stuck at the support level of the publisher. They did promise me to relay the information, but I doubt that ever happened.

So, now I heard about this new standalone expansion pack for the game, called [XCOM: Enemy Within]. A user going by the name of [renezett] in the [Voodooalert forums]German flag got the game and attempted to apply the same hack that was originally done, albeit based just on the binary version of the mapping stub DLL zernel32.dll, without compiling it from source himself. That’s ok though. By hacking the games EXE with a hex editor and placing the zernel32.dll and fileextd.dll in the same folder, the issues weren’t resolved this time around though.

XCOM: Enemy Within

XCOM: Enemy Within

It seemed that some part of the expansion pack still wanted to call the kernel API function GetFileInformationByHandleEx(), naturally a part of the NT 6.x kernel API or – on XP – fileextd.dll. See this part of the zernel32 header source code, where we can clearly see how the function is being intercepted and mapped over to fileextd.dll for hacked binaries calling zernel32.dll instead of kernel32.dll directly:

#pragma comment(linker, "/export:GetFileInformationByHandleEx=fileextd.GetFileInformationByHandleEx")

So, what went wrong? When working together with renezett to resolve the issue for him, I had a hunch that it was simply some additional binaries or libraries calling the function for this new expansion set of the game, and that has proven true. While I cannot provide the exact file names, I asked renezett to look at all other EXE and DLL files of the game with his hex editor, and look for KERNEL32.DLL strings and to replace them with ZERNEL32.DLL, just like with the original hack. Now he did indeed find some additional DLLs in \common\XCom-Enemy-Unknown\XEW\Binaries\Win32\ that linked against kernel32.dll, and after replacing the strings and putting the zernel32.dll and fileextd.dll there, the game worked!

So basically, it’s the same hack, just more files that need to be modified in order to make it work! Scratch another XP incompatibility issue!

Update: A user calling himself None has posted a [comment]German flag, explaining that the problem was likely not some other binaries or libraries calling the Kernel API functions in question, but just some misplaced files, maybe just fileextd.dll not sitting next to the games binary. He also explained that only one file required hex editing as described, and that’s the following:

  • SteamLibrary\SteamApps\common\XCom-Enemy-Unknown\XEW\Binaries\Win32\XComEW.exe

Also, None suggested not to change anything in XComGame.com as that broke the game for him, rendering it inoperable entirely. So it seems to be pretty much the same as with the original XCOM game after all. </update>

Now, if only the Planetary Annihilation developers would finally learn, that Microsofts Visual Studio 2012 has a “v110_xp” and not just a “v110” platform target for the linker, wouldn’t that be something? Just a few clicks away! But it seems “we don’t wanna!” is their current attitude regarding the issue…

Oh, and to make it easier for you in case you want to try this out, here are the download links again:

If those links ever break, just let me know and I will re-host the files on my own server.

May 292013
 

Metro Last Light logoAnd here’s another one. There were games that did not support Windows XP at all, like [Dishonored] or [XCOM]. Some were just without all official support, but working flawlessly nonetheless, and others just carelessly compiled and linked, which could be fixed by a [rather simple function call redirection] to a proper backport DLL that Microsoft actually offers officially. So in many cases, XP and XP x64 support is not impossible at all. So why does it disappear? Simply because of the one factor that rules all and everything: Money.

Supporting an operating system may seem simple, just see whether your game runs and be done with it. It never is that simple though. So my assumption is, that official support is simply vanishing because of cost. Cost of testing, quality assurance and ongoing after sales support. That stuff is probably more expensive than I thought, and I cannot think of any other reason why this would be the case also for 4A games’ latest release: [Metro Last Light]. If the cost of testing, QA and support is greater than return of investment expectations (=sales on XP platforms), then they won’t go there.

So, Metro Last Light is kind of an in-between thing. If you look at its [Steam page], you’ll see that it doesn’t completely rule out XP, but it limits support to the regular 32-Bit NT 5.1 version. The reasons are simple. While XP x64 may seem like a better option for modern games due to its greater RAM support and 4GB userspace windows for 32-Bit applications, it is simple not as wide-spread as good old 32-Bit XP. So from a businessmans perspective, it may seem like a good idea to throw out XP x64 support and keep XP x86 in, as about 22x as many people are using XP x86 when compared to XP x64 according to the [latest Steam survey] from April 2013 (If you click on this link later, you’ll probably get different figures as the link’ll point to a more recent survey page).

So, 0.38% of all users are on XP x64. Actually, a +0.01% rise since last month, pffh. And in comparison, 8.25% of all Steam users are on XP x86, or 32-Bit. Since Metro Last Light still has that Direct3D 9 renderer that Metro 2033 also featured, they might have thought “we can still squeeze some cash out of XP, but not XP x64”.

Still, the good thing is, that business decisions not always have to affect technical details in every single aspect. Sure, there ain’t no support whatsoever, but who cares, if you can get this nonetheless, on Windows XP x64 Edition:

Metro Last Light on XP x64

So yeah, it just works. No hiccups, no nothing. It’s still sad that developer 4A games would state upon inquiry that they do not support XP x64. It would be nice if they could just say something like “We cannot officially support this, if you’re running into issues, you’re on your own, but yes, it will usually run, but don’t take it for granted.”. That would be cool. Because in this case I had to buy the game (there is no demo!) to run the test. I will admit I actually tried to evaluate the situation using cracked copies, but it seems the cracks are actually less compatible to XP x64 than the actual game. ‘Cause the cracked binaries all crashed. The legit game does not! It was risky to buy without knowing, but at least now I can share this with you!

The configuration of the successful test:

  • ASUS P6T Deluxe mainboard, X58 chipset
  • Intel Core i7 980X @ 4.0GHz
  • 48GB of DDR-III/1456 CL10 memory
  • 2 x EVGA GeForce GTX 580 3GB Classified Ultras (running Metro Last Light in Single card mode, need to update the driver for SLI)
  • 314.07 GeForce driver w.o. Metro Last Light support (the nVidia game ready driver for the game is version [320.18])

So there you go! Another desperate win for the dying breed! ;)

Apr 022013
 

Frog ASPIToday I would like to discuss a few useful tricks for Windows XP x64. Yeah. Again. But this time around, it’s at least partially about stuff that you can’t easily find on the Internet anymore, whether it’s the information or the actual software part that’s missing. There are several software components that are sometimes hard to use or find for XP x64. Some are even hard to set up for regular 32-bit Windows XP. The following solutions will be discussed:

  • 1.) The ASPI Layer (digital media access)
  • 2.) UDF 2.5 (for Blu-Ray and HD-DVD access)
  • 3.) exFAT (some modern cameras etc. need this file system)
  • 4.) EXT2/3/4 (for Linux and UNIX compatibility)
  • 5.) Universal SSD TRIM (keep your SSD clean, tidy and fast, like on modern systems)

So, let’s start with #1:

1.) The ASPI layer:

Edit: Note that in the meantime, the FrogASPI solution described here is no longer the only option. Another one that works even for 64-bit applications accessing the ASPI layer has been found, see further below!

1.a) FrogASPI:

One of those things that have been abandoned by Microsoft is the ASPI layer, the Advanced SCSI Programming Interface. Meant as a way for digital storage media access it was most prominently used to read from optical drives digitally (also on ATA, not just SCSI), so you didn’t need to rip audio CDs via MSCDEX on Win98 or via the crappy analog link from your drive to the sound card. ASPI can also be used to access other types of storage devices, but this is the most important part. Some older software, like my beloved Xing AudioCatalyst (an ancient CD ripper including the Fraunhofer mp3 encoder) might still need ASPI to access audio CDs.

However, Adaptec stopped shipping ASPI drivers for Microsoft Windows after Microsoft had abandoned the API and introduced its own replacement called SPTI, the SCSI PassThrough Interface. As a matter of fact, you can still install Adaptecs ASPI layer on 32-Bit Windows XP, as it includes a working 32-Bit kernel driver. So for 32-Bit XP, it’s still fine. However, there is no such driver for XP x64 (and also not for 32/64-Bit Vista/7/8). So, no ASPI at all?

For a loong time I indeed had to live without it, until I found that french guy named Millenod (That’s his nick name, I will not disclose his real name) who had written a 100% userspace ASPI layer, that would work on any newer Windows operating system on x86, no matter the bitness. This is called FrogASPI, and unfortunately, Millenods website for it is down by now. In its core, it is actually just an SPTI wrapper. Back in those days, I even wrote the guy an email, thanking him for his work. Here is a part of his reply:

“FrogAspi is effectively an SPTI wrapper. I decided to work in “user” mode, instead of kernel ones, for many reasons.. It was for me the fastest way to implement a generic ASPI layer, which is not OS specific as drivers.”

-Millenod, Developer of FrogASPI

After renaming the FrogAspi.dll to the proper name wnaspi32.dll and putting it into %WINDIR%\SysWOW64\ for 64-Bit Windows, it can be used by any ASPI-enabled application. For 32-Bit Windows, please use %WINDIR%\system32! See, what Adaptecs own aspichk.exe has to say about what we just did:

Adaptec ASPI Check

You’ll see that some files are reported as missing. You do not have to care about that though, ASPI32.SYS would’ve been the 32-Bit kernel driver, WOWPOST.EXE is a 16-Bit Windows ASPI helper tool, WINASPI.DLL the corresponding 16-Bit Windows driver. None of those are needed. Now, that FrogASPI is mapping all ASPI calls to SPTI, we can begin to actively use it even on 64-Bit Windows. See AudioCatalyst for instance, with ASPI being available:

AudioCatalyst using FrogASPI

AudioCatalyst reading the Postal Original Soundtrack CD using FrogASPI

As you can see, everything works just fine. Oh, and besides, in case you want AudioCatalysts CDDB feature back (as shown in this screenshot), just add the following lines to your AudioCatalyst.ini, sitting in the programs installation folder, this’ll switch from the now-broken CDDB to FreeDB:

  1. CDDBServer=freedb.org
  2. CDDBHTTPPath=/~freedb/cddb.cgi
  3. CDDBLocation=Random FreeDB Site
  4. CDDBTCPIPPort=8880
  5. CDDBConnectVia=TCP/IP

You can download FrogASPI right here:

Unfortunately I cannot give you a download link for Xing AudioCatalyst, as it’s commercial software even today.

1.b) StarBurn ASPI (An update from 2016-12-05):

In the meantime, user Steve Sybesma has [commented] about a different solution provided by [StarBurn Software]. With their recording software comes a native ASPI layer for both 32-bit and 64-bit systems with full compatibility for even 64-bit programs that want to use ASPI. I decided to fetch the necessary DLLs from their SDK and release them in the form of a standalone InnoSetup installer for Windows 2000 and newer. The installer will auto-detect your operating systems’ bitness and will install the 32-bit ASPI layer on 32-bit systems as well as both the 32-bit as well as the 64-bit one on 64-bit systems.

Here it is:

It has been successfully tested on Windows 2000 Pro SP4, Windows XP Pro SP3, Windows XP Pro x64 Edition SP2 as well as Windows 10 Pro x64. If you don’t want to trust my installer, that’s fine as well of course. You can just install the StarBurn software from its original source, it should give you the same level of ASPI support, just with more additional stuff being installed!

Now, to #2, the UDF 2.5 file system for HD-DVDs and Blu-Rays:

2.) UDF 2.5:

Now this one was a real bitch. It took me months to finally get it nailed! UDF 2.5 is a file system. And it’s used for basically two type of media: HD-DVD discs and Blu-Ray discs, including the most modern 3D Blu-Rays. It just bugged me like hell, that I couldn’t access the discs as I normally would in Windows Explorer or on the command line. Windows XP simply does not have the proper file system kernel driver. And while it’s relatively easy to find one for 32-Bit WinXP, it’s immeasurably harder to find the single one existing driver for Windows XP x64. I’m not even sure if it still exists on the web..

One day I came across a person whose name I forgot, but that guy had searched the web for months just like me, and he found the driver just before it went offline. So he re-uploaded it, with his single file sharing link in some post on some unknown website being the only thing that saved my bacon. Maybe one day, somebody will find the XP x64 UDF 2.5 driver here on my site after desperate searching? Who knows.

So, the only existing driver has been developed by Panasonic/Matsushita, a company that also builds optical drives. It works on Windows XP x64 as well as Server 2003 x64. And here it is, together with the Toshiba-made UDF 2.5 driver for regular 32-Bit Windows XP just for completeness:

Again, I would like to emphasize that it took me months to find that freaking 64-Bit XP driver, I’m not even sure what Panasonic/Matsushita developed it for, but here it is for your enjoyment. After installation and reboot, you can browse a HD-DVD or Blu-Ray just like any CD or DVD disc, see here:

UDF 2.5 at work in XP x64

The Blu-Ray folder structure of the german uncut version of “The Boondock Saints”, viewed using the Panasonic/Matsushita UDF 2.5 driver for XP x64

And now, #3, the exFAT file system:

3.) exFAT:

exFAT is a successor to the older FAT32 file system that uses a 64-bit address field instead, allowing for larger than 4GB files, the most notorious limitation of regular FAT. exFAT is now being used on newer cameras and other handheld devices for memory card formatting. Since the comparably heavy-weight NTFS is typically not used on such devices, exFAT is the replacement we get. Also, exFAT is the official file system for SDXC and Memory Stick XC cards, so they may very well come exFAT-preformatted! The only sour part is, that exFAT is kind of proprietary (Microsoft), like NTFS. That’s a bit crappy, but well.

I have however already written an article about exFAT on XP x64, so I will just link to it. exFAT is also very easy to get for both 32-Bit and 64-Bit flavors of Windows XP:

And now, finally, some free file systems from the Linux world:

4.) EXT2/3/4:

EXT is one of the most widely if not the most widely used file system in the entire world of Linux. It has also been ported to other systems like BSD, Solaris or ReactOS. And also Windows actually, although the implementation is not the most seamless you can dream up. But still, you can get read/write access to all currently used EXT versions under Windows, even the fast new EXT4.

The software that I found most useful for this is called [ext2fsd], short for EXT2 file system driver. It comes with the actual driver plus a helper tool for mounting and for enabling write access. It would be nice to just be able to mount EXT filesystems seamlessly from the start, without having to use that mounting tool, but we’re not that far yet it seems. However, drives can be configured to auto-mount later, so you need the tool only once for each drive. Write access has to be enabled by hand.

Currently, ext2fsd supports the following systems: NT 5.0 (Windows 2000), NT 5.1 (Windows XP 32-Bit), NT 5.2 (Windows XP x64, Server 2003), NT 6.0 (Windows Vista), NT 6.1 (Windows 7, Server 2008). Where not explicitly mentioned, it supports both 32-Bit and 64-Bit versions of said operating systems. And here is what it looks like in action:

EXT4 mounted on XP x64

A Linux-created EXT4 filesystem mounted on XP x64 for read/write using ext2fsd

The only strange thing is, that ext2fsd calls the EXT4 file system “EXT3”. It shouldn’t. But other than that, it works just fine. I haven’t tested a lot of r/w, but so far it worked fine, without any corruption or anything. The helper tool also gives you a function for flushing the write cache, and a nice statistics window for monitoring the file system usage while mounted. It also allows the user to manually unmount of course. Even mkfs is there, so you can format drives as EXT under Windows, the only useful tool missing would be fsck for checking & repairing such filesystems. But you can’t have everything I guess.

So, usage is not as seamless as it would be with native NTFS/FAT32/exFAT drivers, but it’s ok and it greatly boosts the Linux interoperability of XP x64 and other Windows systems. Also, EXT filesystems can easily be used in other UNIX-style systems like Solaris, BSD or MacOS X, so this allows a lot of different systems to exchange data easily using removable sticks or harddrives. Since it of course supports large files (>4GB) and it’s more easy to handle across a wide spectrum of operating systems, unlike exFAT it might one day become the #1 choice for data exchange, replacing FAT32 and NTFS in that field. However, today, NTFS on Linux is probably a lot more widespread than this EXT driver on Windows, so there is still a long way to go.

Of course, there is a downside to this too: All the POSIX permissions like ownership, read/write/execute bits etc. just do not work on Windows. You can neither read nor write any such meta data using ext2fsd. I have neither checked the umask that ext2fsd uses yet, nor what ownership it sets, but I would guess it’s root:root with permissions 777 or rwxrwxrwx. But whatever it is, you will most likely need to take care of that when mounting on your UNIX-style system.

I hope this was helpful, if you have any comments about these helpful add-ons, just post away!

5.) Universal SSD TRIM:

This is a 2014-11-03 edit of the original article.

Usually, I would tell users who would like to use an SSD on Windows XP or XP x64 to re-align their partitions with a [gparted ISO] after installation to get proper alignment, and more importantly to use either Intel, Corsair or Samsung SSDs so that they can TRIM their SSDs properly using their respective manufacturers’ XP-compatible software tools, maintaining full write speed over the entire life time of the SSD drive.

It seems that I can now finally confirm, that the latter criterion no longer needs to be met. Basically, I found an easy way to TRIM any SSD on Windows XP or Windows XP x64, as long as the following logical criteria are met:

  • The SSD itself needs to support TRIM. Well, that was obvious.
  • The controller driver needs to support TRIM. Now I can’t speak for just any driver, but I have tested this on Intels ICH10-R and an ancient ICH7-M, both worked just fine with AHCI drivers installed. Usually, AHCI is what you want. Avoid IDE/legacy PATA modes. You may need to configure this properly in your systems BIOS and you may need to retrofit AHCI drivers in XP if your system was installed using IDE mode to avoid bluescreens on boot. If you need help doing that, please ask away in the comments.

So, what’s the solution? It’s called the ADATA SSD Toolbox! Basically, ADATA developers seem to have forgot or were actually never instructed to install an artificial vendor obstruction inside their software. So what they did was to write an SSD toolbox that just complies to the SATA standard, implementing its TRIM command for any compatible SSD, no-holds-barred! I have tested this on an Intel 320 SSD, as well as on a Crucial m500 SSD now, despite no official XP support being present:

So there you go! Now pretty much any TRIM capable SSD can be made to accept TRIM on Windows XP and XP x64! Together with gparted for partition alignment, we have a full-featured SSD solution for XP, leaving nothing to be desired!

Download the ADATA SSD Toolbox here: [ADATA SSD Toolbox v2.0.1].

Nov 112012
 

Dishonored LogoDeveloped by Arkane Studios and published by Bethesda, “Dishonored” is supposed to be a really cool new stealth / assassination style game with a deep story and a tense atmosphere amplified by really nice artwork. If you want to get an impression of this game, please watch the [debut trailer] and the [gameplay trailer]. Meanwhile, the cool song from the gameplay trailer has gotten so much attention, that it has been released as an [mp3] including its own [remix contest].

Basically, the game is set in a steampunkish world with swords, muzzle-loader pistols but also some Tesla high tech stuff. And in the dark corners of the plague-ridden, rotting city there is even magic. So, everything seems cool, and even though this is a console port, it seems to be one well-done at least. Yeah, the textures aren’t fly, even if you choose to fully [tune the engine], but the watercolor style is still more than nice enough to look at in my opinion.

Now, the one question that is interesting to me of course: Why does Bethesda insist this game needs Windows Vista/7 as a minimum? The renderer is DirectX 9.0c, sitting in an Unreal Engine 3, like many modern games. So why? Maybe some special function calls like in XCOM that need to be hacked to work? Maybe some modern API calls that do not exist on XP? Or something else? No. None of those. It was simply laziness in the software testing process I assume. Or maybe Bethesda just didn’t want to care to have to offer official XP support. Whatever the reasons are, it works just fine anyway, see here (click to enlarge):

Dishonored running on Windows XP Professional x64 Edition

So there we go! Another Vista/7 only game, that works just fine on Windows XP. Make sure though that you’re running your XP with SP3, and your XP x64 with SP2. You should really run the latest patchlevels anyway. So if you have everything up to date, you should be just fine. No modifications or hacks required for this one!

Oct 312012
 

XCOM Enemy unknown LogoWhen it was announced that Sid Meiers company Firaxis would do a sequel for the UFO/XCOM series in a classic style, fans rejoiced! UFO: Enemy unknown and XCOM: Terror from the Deep were two of the best strategy & tactics games ever. Plain and simple. Now, XCOM: Enemy unknown was released recently, based on the Unreal Engine 3. What some people didn’t understand, since it was DirectX 9.0c only: Why did it require NT6 aka Windows Vista/7/8?

Well, Firaxis decided to use some of NT6 kernels features to open files. Sounds very simple. It is. But the functions that Firaxis chose to use are NT6 only. Actually, Microsoft provides a DLL called filext.dll that brings those functions to XP and XP x64, but Firaxis chose not to use it. Or maybe they just didn’t care enough. So they’re calling a very few NT6-exclusive functions in kernel32.dll, which are simply not there on XP and XP x64.

A user on the steam forums called [KawaiiSara] now debugged that problem and wrote a stub DLL called zernel32.dll that intercepts all kernel32.dll calls, then redirects the NT6 specific ones to the filext.dll that Microsoft provides and passes through the rest to the real kernel32.dll. To make that work, all kernel32.dll calls in the games EXE file have to be replaced with zernel32.dll (or whatever you wanna call your own stub DLL) calls using a hex editor.

Then, user [ScavengerSpb] developed a similar stub DLL based on KawaiiSaras code for Windows XP x64 Edition. While KawaiiSara has posted both the binary DLLs as well as the source code, ScavengerSpb has as of yet only published the binary versions, so use this at your own risk!

Links:

This is confirmed to work both on the demo as well as on the final version of the game. Of course, there is no official support for this hack, so use this at your own risk. It might break in the future due to patches or whatever. Also, when Steam decides to patch the games EXE, the hex edit needs to be reapplied, or it won’t be calling zernel32.dll anymore.

Still, KawaiiSara, ScavengerSpb, you’re my heroes of the day! If ScavengerSpb decides to fulfill my request to publish his XP x64 source code, I will update this post. The code can easily be built using Microsoft Visual Studio Express (2008/2010), which is free.

For your enjoyment, see the following screenshots of the XCOM: Enemy unknown demo version running on Windows XP x64 Edition thanks to the work of KawaiiSara and ScavengerSpb (click to enlarge to 2560×1600):

XCOM Enemy unknown ingame screenshot 1

XCOM Enemy unknown ingame screenshot 2

Thank god that there are some good Hackers out in this world! What would I do without them?

Update: ScavengerSpbs source code for XP x64 added to the links!