Home / Hacking Sumatra PDF 3.2 to work on WinXP & Server 2003 (x86/x64)

[ Moderator’s Note: Follow the instructions below at your own risk. While they shouldn’t cause any issues if followed properly, no official support will be provided for any such user-modified EXE. The last official Sumatra PDF version for WinXP is 3.1.2. ]

Hello,

I just registered here to show you how to binary-hack Sumatra PDF 3.2 in its portable version to work on Windows XP and Server 2003. That includes the 64-bit version in regards to Windows XP x64 and Windows Server 2003 x64. This might not be interesting for 99% of the user base, but I still wanted to share this.

First, you’ll need NTCore’s CFF Explorer. That’s what we’ll use to modify the PE32/PE32+ header of the program to change the header properties “MajorSubsystemVersion” and “MinorSubsystemVersion”, which correspond to the NT kernel version. Also, we’ll use it to modify the load-time DLL import table of the binary program to hard-remove a dependency on d2d1.dll (this part is essentially software vandalism!).

d2d1.dll is some kind of glue-layer library to make Direct2D work on modern systems, or at least I suspect it to be. I’m not sure. Since we don’t need such a thing on XP, ripping the link to its exported symbols out forcefully might work, right?

Open up CFF Explorer and load SumatraPDF-3.2-64.exe or SumatraPDF-3.2-32.exe into it, depending on whether it’s 32 or 64-bit XP/2003 you wanna run it on. Click on the “Optional Header” thing under “NT Headers”, see here:

CFF1692×467 19.6 KB

Here you can see, that the MajorSubsystemVersion is 0005, with the MinorSubsystemVersion being 0002 (already modified!). That corresponds to Windows Server 2003 or XP x64, which run on the Windows NT 5.2 kernel. 32-bit XP would need 0005 and 0001 here (NT 5.1). This will be set to 0006 and 0000 by default (Windows NT 6.0, which means Win Vista). Modify it to match your target platform. Keep the leading zeroes!

Now, click on the “Import Directory” folder. This is the load-time DLL import table. So, the table that specifies which DLLs the program should load and which functions to import from them at load-time (=when you start the program). Find d2d1.dll, right-click it, and pick “Delete Import Descriptor”:

CFF2692×467 19.7 KB

Now click save, and confirm to overwrite the .exe.

Congratulations, you have just vandalized a beautiful piece of software. That concludes the hack, nothing else is needed, at least not for version 3.2:

sumatra32-64bit-on-XPx64792×792 32.7 KB

Cheers!

Thanks for sharing, @GrandAdmiralThrawn! Does make me wonder though - if that’s all it takes then has anyone tried simply compiling the program with an older version of Visual Studio and seen if they can get it to work under XP with minimal code changes?

P.S. Added a disclaimer at the top, just in case someone has issues and decides to direct a complaint about it to us.

Thanks for adding the disclaimer @SumatraPeter, I didn’t think about that!

As for recompiling: It’s probably enough to pick the right platform toolset, like e.g. v141_xp. With that you should be able to compile, at least with VS2017. Could be that the d2d1.h import and d2d1.dll link would have to be removed manually as well, I haven’t looked at the project/solution files yet.

I’ll have access to my Windows build VM on Monday. Not sure if I’ll have time, but if yes, I’ll attempt to compile a build targeting XP / XP x64 directly. Would be cleaner and more proper than the hack I’ve shown above.

I removed XP support in https://github.com/sumatrapdfreader/sumatrapdf/commit/28bd54bd66adb019176eb48c03518ae65f217799 so the first step would be to undo changes to premake files and re-generate the solution.

Re-adding XP support wouldn’t be hard but it was also more work than I was willing to do.

It boils down to using Windows APIs that are no longer available in XP and the XP-compatible SDK no longer being able to compile some of the code and I didn’t have the patience to fix up all those issues.

I’m surprised your hacked binary works at all but I wouldn’t bet that it works in all possible code paths.

Speaking of compilation @kjk, how hard would it be to add ARM64 as a target so that users can run native versions of Sumatra on Win10 on ARM devices?

It’s not too hard and it’s on my list.
That being said, I don’t have an ARM device so no way to test it.

Not worth me posting one of my units as they are the $4-40 Raspberry type but you could possibly add a crowdfund hardware option to the donation page (same paypal account)

Is there anything specific one should test, other than all the file formats which are supported? So far I’ve only tried a few PDFs and CBZ with JPEG and PNG files inside on my XP x64. Those files worked fine so far, and blazing fast at that!

Another user I know asked me to re-do the hack for the 32-bit version, because he wants to use it on his retro computers with XP. So far, he’s reported no issues to me.

Will hopefully be able to take a look at the source code tomorrow, that’ll be fun (I’m a highly incapable programmer, at least when it comes to C/C++).

Thats what I love about XP very little bloat and easy to modify, nothing in 10 is worth upgrading for except more frequent fixes.

Watch out for the issues raised on GitHub towards 3.2.1 a few of those may cause problems whilst testing. Perhaps test a current Pre-release in tandem ?
A Process Monitor comparing side by side with a suported OS such as vista upwards, tracing cascading calls through dlls may spot any process failings ?

Although in this case the “blazing fast” part was more Sumatra PDF than XP. I compared it with CDisplayEx for a comic book / manga reader, and while CDisplayEx is better suited for this specific task (2-page view includes fold-shade rendering or what you call it, and right-to-left reading), Sumatra is faster.

For PDF I compared it to Adobe Acrobat Reader 10.1 and Foxit Reader 611.1031, and… Well… XP or not, speed-wise, Sumatra just wipes the floor with those. But that’d be common knowledge I guess.

PS.: My XP x64 machine is relatively “modern”; Xeon X5690 hexcore, 48GiB RAM, 1.6TB SSD, 54TiB RAID-6, GTX Titan Black, but programs like Adobe Reader can still make it feel sluggish… whereas Sumatra does not.

Only thing I’ll miss on occasion will be PDF forms. But maybe PDF.js can handle those.

Basic form filling is on the back burner whilst Annotation is in active development.

Personally dont like the prospect of XFA forms support since that requires java or similar exploitable functions (and I have easily used such mods in the past on behalf of an institutional client who could not provide a password for their key online form)

Winners of March " Pwn2Own" was the one click PDF exploit of Acrobat.

Of course MuPDF-GL includes javascript in its forms support which I will use when necessary via a link from SumatraPDF.

Since Embedded text fonts and images such as PNG can be used as attack objects NO PDF aspect is safe.

At my work I read many pdf books, and we have XP. I want to download your latest version with multiple windows supply. I plead you, please make this version for XP too.

Serge
you will need to find a good programmer to compile the source code so that it could work on redundant systems, The above hack may help however it is untested and certainly XP will no longer be supported.

I have actually tried to compile the source code for XP for a few hours, but surprisingly, I couldn’t manage. It’s far harder than my binary hack, which is kind of… strange, really.

Anyway, I believe the hack should be simple enough to apply, no? Or are you having trouble applying it? If you’re stuck somewhere, I’d be happy to help.

I’m not sure if I should re-distribute modified binaries…

Pity, that Krzysztof doesn’t want to add xp support. XP is much better than newer versions and some people still work on this system. It much easier to understand and more friendly. If his older versions could include multiple windows, because it’s really not comfortable to open 20-30 documents in one line, i wouldn’t beg him now, i’d rather download older version and use it. But, unfortunatelly, older versions don’t include that option and I have to open all docs in one line.

Its not kjk did “not want” he did try, its newer MS VisStudio won’t support XP so needs unwarranted debugging of xp failures.

With version 3.1.2 there are multiple untabbed windows
Plus tricks to get multiple windows including with tabs. But you need to play around with settings for the way you work.

I don’t understand. You mean 3.1.2 version also supports multiple windows? i mean, i need like that: one group of tabs was separately from another group, every group of tabs is a different window icon in the task bar. Does 3.1.2 support this option? How can I do that?

By the way, the last version of Visual Studio that supports XP officially is VS2017. The one with the v141_xp platform toolset. Starting from VS2019, XP support is gone.

About the tabs: I tried using multiple windows with tab groups per window, but it appears my hack is causing issues. First of all, the tabs have no text displayed on them. So all the tabs appear as blank. Additionally, I couldn’t manage to open two separate windows with one tab group in each window. New PDFs would always open within a single window. Is this just a configuration issue? I don’t know.

Serge
Switch Options> use tabs OFF means seperate windows per file or same file.
Or run two seperate copies of exe on same file or seperate files.

Then you can set tabs on for one or the other, what you dont always get is one file history.

image1150×470 297 KB

Ok, I got it. That’s wonderful.
Thank you!