Building ecl 12.5.1 for win64

It seems that current support of win64 is broken - you can only set GMP_TYPE to gc (although gmp has right project in msvc\gmp\build.vc8\lib_gmp_amd64) and anyway building ends with following error:

        cl -c /EHsc /DGC_DLL /DGC_BUILD /nologo /D_CRT_SECURE_NO_DEPRECATE /DNDEBUG /MD /O2 /arch:SSE2 -DG
ECL_API="__declspec(dllexport)" -I./ -I../ -I..\..\src\c -I..\..\src/gc/include  -I..\..\src/gc/include/pr
umber.obj number.c
cl : Command line warning D9002 : ignoring unknown option '/arch:SSE2'
number.c
../../src/c/number.d(479) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture
../../src/c/number.d(479) : error C2065: 'fwait' : undeclared identifier
../../src/c/number.d(497) : error C4235: nonstandard extension used : '__asm' keyword not supported on this architecture
../../src/c/number.d(497) : error C2065: 'fwait' : undeclared identifier
NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\amd64\cl.EXE"' : re
'0x2'
Stop.

So I made set of patches to build ecl on win64

dcu files loader for ida pro v2

Download
Changelog:

• Initial support for 64bit DCU files from XE2 added. dcu64.l64 now can load at least some files, he-he
• Changed logic that calculates size of .bss section. Now if size of some type is not known (for example it is imported from other .dcu) code just assumes that it has pointer size
• Reloc type 6 processing (xe2 specific ?) fixed

ecl 12.5.1 on xp64

I tried today to build subj with vs2008 on xp 64 bit and got error:

;;;   Invoking external command:
;;;   cl -I. -IC:/src/ecl/msvc/ -DECL_API -IC:/src/ecl/msvc/c /EHsc /DGC_DLL /DGC_BUILD /nRT_SECURE_NO_DEPRECATE /Zi /D_DEBUG /MDd /Od -DGC_BUILD -w -c C:/src/ecl/msvc/lsp/export.c -FoC:/sched/msvc/lsp/export.obj
Internal or unrecoverable error in:
illegal stream mode

Stack trace:

wincheck rc8.16

Download mirror
Changelog:

• add -rdata option for checking .rdata sections. These sections must be non-discardable and their names cannot begin with PAGE. Kernel-mode only
• add checking of kernelbase!KernelBaseGlobalData functions pointers (windows 7 only)
• add checking of SSPI dispatcher tables (called from SECPKG_FUNCTION_TABLE.CallPackage function)
  
• add checking of dxg!gaDxgFuncs table
• fixed function names in W32pServiceTable for windows 8 64bit

vulnerable regexps in ruby

I hope all of you already saw it
Wonderful

w8 64bit kernel object types

Added since windows 7:

• ExCompositionSurfaceObjectType
• ExpIRTimerObjectType
• IopWaitCompletionPacketObjectType

ecl.dll

I already claimed that ecl.dll crashes when loaded from .dll in ecl.dll!_GC_init_thread_local(). So finally I know why. Short answer - bcs it contains static TLS and so cannot be loaded with LoadLibrary:

On Windows operating systems before Windows Vista, __declspec( thread ) has some limitations. If a DLL declares any data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, you cannot extend this space to allow for the thread local variables declared with __declspec( thread )

Problem is that thread_local_alloc.c (where located function GC_init_thread_local) MUST be used bcs it required for elc threads. And you just cannot build ECL without threads support - msvc\Makefile contains following astounding lines:

# Currently it is NOT SUPPORTED to build ECL without threads. The reason
# is that certain exception handlers in Windows always use new threads.

Wonderful