Upgrading Pentium G2020 to Xeon E3 1265L

Today I received a used Xeon E3 1265L from China via ebay for $85. My motherboard is AsRock B75M-GL and originally host Pentium G2020 (was about the same price at that time). This Xeon is lower in wattage(45 vs 60) and has more cores (4+HT vs 2). Sandy/Ivy motherboard was Intel's last generation to properly support XP (my USB3 ports automatically turn to USB2), so I'm grateful to have this processor upgrade. Not just for XP but also for other classic 32bit compatible OSes (OSX 10.6.8, RHEL6, DragonFly BSD 3.2.8 or Solaris 10)

There is an incident during installation, I accidentally scratches the LGA pins and two pins get bent (gulp), When I first boot it, the BIOS tweets 4 times and I was like "Damn I'm done for it!". I spent a lot of time to massage the bent pins using smallest screwdriver that I have with other hand holding flashlight and I hardly break a sweat (cool). Once both looked upward again, the second boot get the system properly detected, temperature is at ~38C so I guess that's good enough for used item.

Now for the first time :

So this configuration: Server CPU  + desktop motherboard is a good deal afterall. I understand why used ECC DIMM is super cheap since it's has big compatibility issues, but this cheap Xeon is no-brainer.

BTW the delivery is one and half week late than the max. estimated date.

ActivePerl 5.22 XP installable

I have installed MSYS2 version that works with XP, and Perl 5.22 was the last build to run. In few cases I'd need to use native version e.g. in conjunction with native gnu-make. So I look at ActivePerl 5.22 which unfortunately drop support for XP just at the same version that I need.. heh!

Installing it under MS Application Verifier disguise works well, but damn, ActiveState sure know how to play hide and seek with their installation files lol. No worries! Process Explorer/Hacker will track them down for us.

After trivial tests I don't see any problem with its executables it's not like they try to disallow it to run on XP, seems they just make it not installable. I wonder if more ISVs doing this.

So I remove the "obstacle" in the msi file and pack a 7zip of it.

Note that while Perl is opensource, ActiveState added package manager among other enhancements which make it overall not OSS.

ActivePerl-5.22.4_installer.7z

Migration pain from DVD disc

Since 2001 I have used CD, beyond scratches it's quite realiable, I have hundreds CDs still readable from which I bought between 2001-2007, that's up to 15 years durability and counting. There is an exception: all "GTPro CDR+" brand CDs are unreadable (all of them!), it's single most popular brand in my area (probably in the entire country) and represent  about half of all of my CDs. Was it a dumping case? who knows... Good things my conscience say I should not trust just one brand.

Since late 2000's I switched to DVDs and the awful traits just started to crop up just after 5 years period. "disc rot" which in my experience seems only happen with DVD, while in other hand CDs experience crumpling due to unprotected data layer surface (upside) which common on cheap disc, especially in outer region where physical contact often made with tray. DVD instead rot from inside, and it rot badly and visibly, a clear sign that this "backup" media need immediate replacement... duh!


The importance of LBA in your catalog

When data is stored in "continous and read only" manner, Knowing the LBA is like knowing the page number of a printed book, the table of content. That the lesson I learned (from isobuster) and unfortunately most cataloging software doesn't store LBA. Why important? because different burning software has different sorting order.

For example cdrtfe use:
All caps -> Title Case -> lowercase precedence for filename aka:

ZACK -> lower LBA
Duck
alabama -> higher LBA

And not just filename order, directory hierarchy also has several pattern order on how LBA then assigned to the files inside (root to child, parent directory grouping to root, etc).
Thus only have filename, size, or even metadata is NOT good enough. Because in the end during the nightmare you'll be like "Which burning software I use to burn that disc?" not good!

Imagine if TOC is not readable "enough" (I said "enough" because there may several TOC available: ISO9660, Joliet, Amiga RockRidge, Mac HFS, UDF etc and having one of supported and not fake one being readable is enough). You're left with huge multiple chunk of readable raw data with 2KB blocksize to recover, and with most type of files being binary you need to figure out header and end header of filetype, which size belong which file and so on, yeah possible as they are sequential... but not gonna do that to a hundred of 4 GB DVDs ain't we?


Recovery Tools

The tool that I use is cdrtools' readcd and isobuster. The latter is to figure out LBA from salvaged TOC, note that TOC not always written inner (lowest LBA) some software write TOC at highest LBA (outer) which most likely worst idea. Readcd is capable of image cloning as well as on-demand sector range copying. Note that isobuster is also capable of unstoppable copying but IMO not as good as readcd, therefor I use the free version 0.99.9, cdrtools is open source.

Note about unstoppable copying in both software:
While isobuster will pause on error via dialog box which then you can retry and continue.
With readcd (a commandline app) you can "force-pause" the pending not-yet-started loop cycle by selecting something (with left click) in the cmd window in Windows 10 or right-click -> select (block) for earlier Windows but you need to monitor the progress. Otherwise you can join readable chunks from sector range copying.

Condition

Unreadable: a disc that might superficially pristine (not even single scratch/rot) but become unrecognizable or before that, have tons of read errors all over area after period of being kept.
Disc rot: mostly happen from outer region to inner and quite visible, has washed out coloration.
Inaccessible: Disc TOC isn't readable "enough", On NT6 drive letter will show but will give error message when you access it
Unrecognizable: Your disc no longer considered a disc, it just some another plastic to your drive. None of your disc area is readable and not just the data area. Here on NT6 Drive letter wont show. So readcd/isobuster can't access it as well. Being uncognizable in mostly persistent and nothing you can do about it but at early stage you can bet your luck.

Dealing with physical damage

Use toothpaste to wash the disc from glued dirt and especially deep scratches. Note I don't know what going to happen to the disc due to detergent, but it always give new hope for retrieval, afterall once I get the data the disc will go straight to the bin.

Dealing with disc rot

Just because the area start to rot doesn't mean it become completely unreadable. Anywhere in the rotten area you could bet your luck to retrieve tiny file of several blocks. Most DVD any brand that I have tend to develop rot at varying degree. Somehow having TOC readable mean good chance of read for the rest data, not so much when TOC not readable that is resort to use sector range copying, of the very same disc but in different recovey session. So don't give up to make the TOC readable first. By average I could recover 3 to 3.7GB of 4GB data.

Dealing with the unreadabledisc

Now here we go the shitty part, the unreadable disc, the worst case scenario. Many remain mystery for me, like how the hell this crap being manufactured and being brand related occurrence. In my experience DVD brand printed as "mitsubishi" is known to be suicidal . From my experience there are several factor involved in recovery chance (of course most of the blame goes to the disc manufacturer):
- proper drive read speed (lowest speed is not always better!)

- the laser itself (yep this quite low-level so different drive, different chances)
- initial drive's spin-up/down
- operating temperature

FFmpeg for Windows XP

FFmpeg itself has no problem with XP, but its dependencies are. This build is feature complete  (and therefor non-opensource and not redistributable) oh well.

This build specifically for XP so most of AVX optimization disabled
Aotuv is used for vorbis encoder and capable of ~32kbps at -aq 0
x264 and vpx codec use high bitdepth but not for x265 (is too slow)
your custom fonts goes to fonts sub-directory (via fontconfig)
your frei0r dlls goes to frei0r sub-directory
your ladspa dlls goes to ladspa sub-directory
place libbdplus.dll+libaacs.dll or libmmbd.dll in the root directory if you need those
flagged with LAA (bigmem)

download:
version 3.4.1
ffmpeg-3.4.1.7z (24.4 MB)
ffmpeg-3.4.1_LTO.7z (21.3 MB) small build

Configured as:

configure --enable-nonfree --enable-gpl --enable-version3 --enable-small --enable-avresample --enable-pthreads --disable-w32threads --enable-avisynth --enable-chromaprint --enable-frei0r --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libdc1394 --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libilbc --enable-libkvazaar --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopencv --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-librtmp --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-decklink --enable-libmysofa --enable-openal --enable-opencl --enable-opengl --enable-libmfx --disable-avx --disable-avx2 --pkg-config-flags=--static --extra-libs="-lstdc++ -lgomp"

GTK 2.24.31 static library barebone

As a prior reference https://code.google.com/archive/p/static-gtk2-mingw32/
the thing is no patch provided but hints, that's enough though.

So why GTK2? well, after maintaining pygi-aio for several years, nothing really that good.. honestly
There is rough edges, regressions and more importantly it feel less responsive (with slower start-up). Overall GTK 3.x was turbulent version.

Just FYI, it's possible make GTK3 static build, especially prior to GDK's switch to adwaita as default theme, that is GTK 3.6.x where you get "somewhat" native theme, GTK 3.22 also have "somewahat" native theme returned and  it break XP compatibility Well duh.

I made a mod of vispdisp (a streaming image viewer powered by VIPS) and make single exe with GTK 3.6
https://github.com/tumagonx/XPitory/raw/master/static_port/vipsdisp/vipsdisp.exe support huge tiff/jpg/png image (upx'ed 1.56MB)
That's just to prove I'm not making excuse for choosing GTK2 over GTK3 :)

The goal here is to make it barebone otherwise you may as well use the dll version, no?
Considerations:
1 the focus is GTK alone, the rest isn't that important
2 dependencies will be trimmed down until it become what's GTK only really can use from
3 optimization flags

1) With version 2.24.31 I choose Glib 2.34.x which is the minimum to build the latest librsvg (more about it later), Glib also getting bloated too overtime and there are some regressions I don't want to mess with in more recent versions. Supposedly the officially supported static build for Glib was version 2.28-2.30 but it seems my workaround is fine for 2.34. With this other dependencies are pretty much settled:

zlib 1.2.11
win-iconv 0.6
gettext 0.18.3.2
libffi 3.2.1
pixman 0.34
cairo 1.12.18 (I have crash with cairo 1.14.10)
glib 2.34.3
atk 2.8.0
pango 1.40.12 (1.40.14 claim need glib 2.34, but actually it need quite recent one)
gdk-pixbuf 2.26.5
gtk+ 2.24.31

2) Several libraries to be trimmed down:
pixman : has big chunk of SIMD code, configure with --disable-sse2 --disable-ssse3
cairo : only few features that needed by GTK2, configure with --enable-pthread --disable-interpreter --disable-fc --disable-ft --disable-gobject --disable-png --disable-svg --disable-script --disable-ps (note: pthread is needed for static build to avoid mutex crash)
glib : disabling debugging make it smaller, configure with --enable-debug=no
pango : ditto
gdk-pixbuf : only use gdiplus, configure with --with-included-loaders=gdip-png,gdip-gif,gdip-bmp,gdip-tiff,gdip-emf,gdip-jpeg,gdip-wmf,gdip-ico --without-libpng --with-gdiplus --without-libjasper --without-libtiff --without-libjpeg --disable-modules --enable-debug=no
gtk : --disable-modules --with-included-immodules=ime,ipa --enable-debug=no

Do we need svg support? hint: it was one of format that MS really "hate" and hey Qt has it.
if so things get complicated as there is circular dependencies between gdk-pixbuf and librsvg, to solve that merge librsvg objects into libgdk_pixbuf-2.0.a and pass all librsvg dependencies through LIBS that is libcroco and libxml2, overall adds 500KB.

Do we need fontconfig/freetype? it will solve problem of "complex/unusual" font rendering that plagued win32 backend, but it also add almost 700KB (including several config files) and annoying font caching startup once in a while... frankly for most of case it's redundant.

Do we need full jpeg, png and tiff support? gdiplus backend provide less feature for these formats: no progressive mode, no png metadata, incomplete tiiff format/compression and so on. but this will add even more weight 1-1.5MB depends on configuration. Furthermore there is psd, webp, and raw modules that can be enabled

3) the flags is nothing special and for portability reason -flto is avoided (it will make your exe even smaller but you'll need gcc 4.6-4.8, I think)
cflags : -Os
add -fno-unwind-tables -fno-asynchronous-unwind-tables if EH is SJLJ, but not for DWARF or SEH
add -ffunction-sections -fdata-sections this is effective against simpleton app but lost it once app getting complex, in this case -flto is better replacement for dead code removal.
ldflags : -Os -Wl,-s
add -Wl,--gc-sections to correspond above cflags or -flto if you use it on cflags
cppflags : -DGLIB_STATIC_COMPILATION -DGOBJECT_STATIC_COMPILATION -DGDK_PIXBUF_STATIC_COMPILATION -DPANGO_STATIC_COMPILATION -DATK_STATIC_COMPILATION -DGTK_STATIC_COMPILATION -DGDK_STATIC_COMPILATION

The static library is intended for static exe, if monolithic dll desired then we need better replacement for GetModuleFileName (without relying on DllMain) such GetModuleHandleEx otherwise localization path will be unpredictable.
Produced exe for simpleton app is about 3.6MB, 3MB with LTO libraries, and a little over 1MB if compressed with 7zip.That's half of prior effort, not bad.

Downloads
Patches (including new stock icons replacement) : gtk+-2.24.31-static_patch.7z
Libraries and (flattened) headers : gtk+-2.24.31_win32_win64_sjlj.7z
add to ldflags like: -lgtk-win32-2.0 -lgdk-win32-2.0 -lpangocairo-1.0 -lpangowin32-1.0 -lpango-1.0 -latk-1.0 -lcairo -lpixman-1 -lgdk_pixbuf-2.0 -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lintl -liconv -lz -lffi -lws2_32 -lole32 -lwinmm -ldnsapi -lshlwapi -luuid -lgdi32 -lgdiplus -lusp10 -lmsimg32 -limm32
alternatively create text files named libgtk2.a with linker script:
GROUP(-lgtk-win32-2.0 -lgdk-win32-2.0 -lpangocairo-1.0 -lpangowin32-1.0 -lpango-1.0 -latk-1.0 -lcairo -lpixman-1 -lgdk_pixbuf-2.0 -lgio-2.0 -lgmodule-2.0 -lgobject-2.0 -lglib-2.0 -lintl -liconv -lz -lffi -lws2_32 -lole32 -lwinmm -ldnsapi -lshlwapi -luuid -lgdi32 -lgdiplus -lusp10 -lmsimg32 -limm32)
then we can just add only -lgtk2 in ldflags

Qemu for Windows XP

QEMU provide binaries for windows at https://qemu.weilnetz.de/w32/
But around version 2.8 (the builds is snapshot based) it was dropped XP support  (supposedly version 2.9 when it switched to SRWLOCK mutex thread)

I build recent qemu version that compatible with XP (32-bit) by reverting the threading model to 2.8.x version.

The build is LAA (bigmem) and fully static binary
https://sourceforge.net/projects/xpitory/files/qemu/

HAXM maybe possible using http://software.intel.com/sites/default/files/haxm-windows_r05.zip note that the installer itself wrongly flagged as NT6 executable! but you can open it using 7-zip and then use the hax.msi to install (only for XP32)

This post (and hopefully much more) will be part of XP revival effort which started at github https://github.com/tumagonx/XPitory (apparently not a viable option for long term use so I move to SF).