Note that the default binaries of v0.88 of TnFOX on Windows incorporated into itself the following libraries:
MSVC6 is not supported, nor is MSVC7.0 (Visual Studio .NET). You need MSVC7.1 minimum (Visual Studio .NET 2003) and MSVC8 as well as MSVC9 work well. GCC v3.2.2 to v4.3 is known to compile working binaries on Linux but is untested on Windows. The Digital Mars compiler wasn't up to the job last summer 2004. Intel's C++ compiler v8 for Windows works fine, though its config is very out of date nowadays.
The only official compiler supporting x64 is MSVC8 (Visual Studio 2005) and MSVC9 so this is what I describe. You can make it work with beta compilers from the Platform SDK, but you NEED at least the MSVC7.1 STL (rather than the MSVC6 STL which comes with those test compilers) which is hard to get. Chances are that Intel's C++ compiler as well as GCC should produce working x64 code.
config.py as desired - note that by default, config.py will detect whether your command box is a 32 bit or 64 bit binary and will build for that unless specifically overridden. scons msvcproj which will auto-detect your MSVC installation and generate suitable MSVC project files which will invoke scons for you. TnFOX/windows directory - these include the ZLib library (as zlib), the graphics libraries for JPEG (as libjpeg), PNG (as libpng), TIFF (as libtiff) and BZip2 (as libbzip2). In all cases any version information is not used so openssl-0.9.8 must be renamed to simply "openssl". Note that all libraries are linked in statically so don't go building DLL versions! (eg; use nt.mak instead of ntdll.mak when building OpenSSL). If this seems like hassle, once you've done it you can forget about it thereafter.If any library cannot be found, support for it is disabled automatically. You should bear in mind that after compiling using the enclosed project files where necessary, you should move the library to the root of its project and append either a 32 or 64 to the filename as appropriate so that scons can find the correct one.
HeapCreate() family) with its own based on FX::FXMemoryPool when the build mode is release. This is done because quite frankly, the Win32 standard allocator is crap - especially on systems with more than one processor. Admittedly it's nothing like as crap as the allocators used to be on older MSVC's (especially the famous one where realloc() in the debug library corrupted your memory), but when compared to ptmalloc2 (the glibc standard allocator) it sucks major monkey balls.
All DLL's are prebound for during the build process to speed loading times plus I made a number of lesser used DLL's for Win32 release builds delay loaded (ie; loaded only when they are first needed). This should lower both load times (I've set a custom load address too) and run-time memory usage for the majority of cases. Note that prebinding only speeds loading when loading onto your local system (your application's installer should do this).
TnFOX is able to use >2Gb address spaces and so has the IMAGE_FILE_LARGE_ADDRESS_AWARE bit set in its executable header. You should set the same bit in your applications if you are also able to handle such addresses (ie; you don't use signed pointer comparisons). While you never see the advantage of this on most 32 bit Windows, you do when running in an emulated 32 bit environment on Windows x64. You can produce binaries customised for your processor by adjusting the config.py file.
TnFOX is also no-execute compatible, meaning that its stacks can be marked as no-execute. This is specified to the MSVC linker (where supported) using the /NXCOMPAT switch.
The only thing remaining which shall be fixed later is working set optimisation (WSO) which I can't do until I have a serious client application for TnFOX to profile against. But don't worry, it'll come!
v1.4.7