Just for fun

Why are we hiding from the police dad? They use vi son, we use emacs.

gbildify expat module and test it on windows

During my work on migration from dmake to gnu make (gbuildification) of expat module i discovered some innocent looking lines in the old dmake based make file:

.IF "$(BUILD_X64)"!=""
# ---------------- X64 stuff special ---------------------
#  use UNICODE only because shell/shlxthandler
#  doesn't link against ascii_expat_xmlparse
#---------------------------------------------------------
SLOFILES_X64=$(SLO_X64)/xmlparse.obj \
             $(SLO_X64)/xmlrole.obj \
             $(SLO_X64)/xmltok.obj
CDEFS_X64+=-DXML_UNICODE -DCOMPILED_FROM_DSP
CFLAGS_X64+=-I..
LIB1TARGET_X64=$(SLB_X64)/$(TARGET)_xmlparse.lib
LIB1OBJFILES_X64=$(SLO_X64)/xmlparse.obj
LIB2TARGET_X64=$(SLB_X64)/$(TARGET)_xmltok.lib
LIB2OBJFILES_X64=$(SLO_X64)/xmlrole.obj \
    $(SLO_X64)/xmltok.obj
.ENDIF # "$(BUILD_X64)"!=""

So what is BUILD_X64 here and when it is used? My understanding was, that LO isn’t shipping as 64 bit binary on Windows. Tor did some great work on it but it is still highly experimented. So what is all that stuff about? It turns out, that LO does shipp nativ 64 bit extension for 64 bit OS for shell integration and special version of expat (64 bit) must be created for that.

Not big deal, right? So what’s the problem with that? The problem was to test it. Gbuildification has already broken almoust everything, so before merging the gbuildified expat to master some real tests should be done, especially if some native bits are involved. Having only access to WinXP (32 bit) and VS 2008 Express was clearly not sufficient. So before installing a whole blown testbed with new VM, 2008 Server 64 bit, SDKs and 64 bit VS compiler i thought i would just ask the folks out there for help.

Continue reading