31 December 2021

WebAssembly in Windows XP

While it has been 15 years since I did real Webdev work (php + dhtml mind you), my recently build clang toolchain need some wasm trial. This tutorial https://depth-first.com/articles/2019/10/16/compiling-c-to-webassembly-and-running-it-without-emscripten/ will serve as reference, emscripten itself being mostly python based might be works on XP.

clang download: https://sourceforge.net/projects/xpitory/files/clang/ (25MB)

to check what's supported target:


Compiling add.c example (I added -v to see more detail):


As the article explained browser security mostly prevent direct access like that, so lets skip to python webserver:


To test add.html, 360 Chrome Browser 69 is used:


That's it. I think...


WASI runtime is included in the clang package above, but haven't follow up the article to test it. Basically think of wasi sdk like mingw + libgcc + libstdc++, so instead of relying on emscripten prepared libraries you build your own from scratch. Note that since llvm 12 there is llvm own libc, not sure how different is this from wasi-libc.

next time I will demostrate using clang 10 as usable Visual C++ 2019 build tools replacement, all within XP box.

25 December 2021

Lightweight PDFium based reader

For a long time the best lightweight PDF reader for XP is SumatraPDF 3.1.2 which based on MuPDF. There is  alternative such poppler/xpdf and ghostscript, all of them use rather unfriendly GPL-like license. PDFium which used within Chromium is new BSD license or APL 2.0 but has crude packaging (typical of google).

I stumbled on https://github.com/vfr/UXReader-Windows a nice pure Win32 API UI library for pdfium, then made little quick change on UXReaderMainWindow.cpp: commenting ChangeWindowMessageFilterEx (which break XP) and add simple argument passing using CommandLineToArgvW so it now will open file from association / cmdline. Note that it's just a barebone demo for the library but IMHO suck less than FoxIt reader. I mean whats the point having a light renderer if you bloat everything else.

Campared to MuPDF I think it's faster (and smaller too), still when rendering image-rich page with multiple overlays and transparency nothing beats Adobe Reader!

opening large ETOPO map

download: UXReader.7z (1.6 MB) require VC++ runtime 2017

24 December 2021

Python 2.7 and TLSv1.3

Python 2.7.18 is the last bugfix version of any python that officially support Windows XP. By default those trying to build it on Windows will need openssl 1.0.2 per preconfigured VS2010 project file, that mean TLS 1.2 at best for you. However as we know, the patch to support TLS 1.3 also landing on 2.7.x line all you need is to build hashlib and ssl module with openssl 1.1.1 or preferably 3.0.x header and import libs (so you can update the dll in the future). 

To do so, basically remove libeay and ssleay projects from the solution and remove them from being listed as dependency of _ssl and _hashlib project. 

Put openssl 3.0.x header directory "openssl" into [root]\externals\openssl-1.0.2t\include32 

Rename the import lib of openssl 3.0.x into libeay.lib and ssleay.lib respectively and place them at [root]\PCBuild.

Build haslib and ssl module as usual.

To see if your python has TLS 1.3 you can use ssl.HAS_TLSv1_3 boolean to make sure they are compiled properly, note that with openssl 3.0.x there are a lot of deprecated warnings but no error. Be sure to put libcrypto-3.dll and libssl-3.dll in either DLLs subdirectory and anywhere in %PATH% environment.

my build can be found here https://sourceforge.net/projects/xpitory/files/python/

Since openssl is dynamically loaded it's preferred to be compiled with MSVC 9 (as is python 2.7) though I rarely see issue of mixing msvcrt.

my personal build of openssl 3.0.1 https://sourceforge.net/projects/xpitory/files/shared-builds/openssl-3.0.1-fips-win32.7z/download

19 December 2021

32-bit OSes for Virtual PC

After being not bootable for long time, finally ReactOS 0.4.14 is run on Virtual PC 2007 again! This opensource NT5 remake project are closely related to wine and mingw which quite helpful to enhance XP. 

ReactOS 0.4.14


On other hand I'm checking out what's the greatest 32-bit mainstream Linux distro available for Virtual PC, MX Linux 21 (Linux 5.10 LTS) is one of few. This "lightweight" fluxbox variant shown running Firefox 93. Booting took some minutes though.

MX Linux 21

I've kept some historical 32-bit Linux distros iso that compatible with VPC as well:

RHEL 6.10, Oracle Linux 6.10, CentOS 6.10 (Gnome 2, LK 2.6): the last true "LTS" (~10 years) 32-bit Linux, which demonstrate how far kernel 2.6 can be tweaked and enhanced through backport.
Chakra 2012.07 (KDE4, LK 3.4): a rare 32-bit KDE4 SC distro, if not the only one.
Tails 3.11 (Gnome 3, LK 4.8): Privacy oriented distro, a rare Gnome 3 with systemd that able to boot into desktop after a little while.
Xubuntu 18.04.5 (XFCE4, LK5.4): generally regarded as the last 32-bit Ubuntu.

18 December 2021

Resuming XPitory

In the past, I made promise about blogging more but deliver none. This time, I'm deliver some before blog it...

20 years after XP released, it still my main windows OS and without a doubt the greatest 32-bit OS of all time.

Now with everyone start ignoring its existence, it's a good time to officially call XP the center of 32-bit retrocomputing.
A time when 2GB ought to be enough memory for anything, a time when entire OS fits in a CD and a time when people care much about making lean and mean software.

Xpitory used to be a place where I put few port for XP years ago. Now I have new goal, this would host lots of opensource software for XP. It will start by providing development toolchain first.

The plan goes like this:

1) Toolchain (compiler, VCS, make-tools)
-- Clang/LLVM 10 + GCC 10 (done, GCC still uder testing)
-- Git 2.34.1/SVN 1.14.1 (done)
-- cmake 3.20, ninja 1.9, msbuild ??, meson ?? (cmake and ninja: done, newer meson need python 3.5: done, newer msbuild need mono 6.12: not started)

2) Command-line software. Nowadays the most powerful software to tackle modern task usually available from CMD box, they are more portable and easier to port to XP.
-- FFMPEG
-- VIPS + IM
-- more

3) GUI Software. This is the harder one, framework like Qt, GTK and WX are increasingly getting away from XP, especially when they put effort on HiDPI, touch awareness and fixes for Windows 10. Other such as the lame Electron should be ignored.
There has been significant growth on Qt5-based software, so putting a working Qt 5.15 on XP is priority. QtWebEngine dependency will be avoided while QtWebkit still possible. Few software still use Qt4, putting on version 4.8.7 with all unofficial fixes and add webp support to it would be nice.
GTK 3.x will be avoided. it's slow and it is the one that technically getting farthermost away from Windows. Focus will be on porting GTK2 software instead.
WxWidgets supposedly the most windows friendly, but I'm not familiar.. will see about it.
MFC: should be no problem, as long as < VS2019 16.8
FPC/Delphi: FPC still support XP, Delphi software known to use lots of delay-load dll to check compatibility.