Thanks for your reply. To clarify, I tested smartmontools on a Windows 7 Pro x64 machine with 4 drives in total:
2 SATA drives attached to the built-in Intel I/O Controller Hub 10 (ICH10).
2 USB connected drives connected using a SATA <=> USB bridge (A 500GB WD5000E035 and a 1TB WD1000H1U). I think the bridges are both oxford ones.
Both 32bit and 64bit builds of smartmontools work against these 4 drives.
Re. the relocation info. Sorry, you're right the article doesn't say it. I cant find a microsoft KB article saying it but I am pretty sure that it is true. This forum post says that the default behaviour of windows 7/vista is to "randomize only images that have relocation information and are explicitly marked as compatible with ASLR by setting the IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE (0x40) flag in DllCharacteristics field in the PE header" see here
On 23 February 2010 20:10, Christian Franke <Christian.Franke@t-online.de>
Richard Flint wrote:
Just wanted to offer some results and observations on the new support for cross compilers targeting windows x64.
I built and setup a MinGW 64bit cross compiler in Ubuntu which was a horrible experience in itself and several times I felt like giving up, however happily I was eventually able to build working x64 builds of Smartmontools.
I tested smartctl and smartctl-nc windows x64 builds and they seem to work fine. I also tested combining the x64 smartctl-nc with 32bit gsmartcontrol-0.8.5 and they interoperate fine.
Good news - thanks for testing!
I tested most of the functions of smartctl including drive identify, short/extended self-tests, view drive health, smart attributes and retrieving temperature logs and all the features I tried appeared to work identically to the 32bit build.
Which controller was used for testing? Its driver apparently implements IOCTL_ATA_PASS_THROUGH. Did you try the 32bit build also on x64 on the same machine? If this works then the driver also supports the 32bit versions of this I/O-control.
I do have an observation to make though. The compile process as-is strips out relocation information in the exe. This basically makes the exe's incompatible with the ASLR feature in Windows Vista/7.
I didn't find a separate GNU ld option to enable relocation info in .exe files. The ".reloc" segment is apparently generated if and only if the PE binary exports symbols. This is the case for .dll files but can also be done for .exe files.
For testing purposes, the following can be used to enable PE relocation info and to set ASLR and DEP flags in the PE header:
It works for me for 32 and 64-bit builds. The drawback is a useless table of exported symbols in the .exe file. This could be prevented by exporting a single dummy symbol.
This is a minor thing, but ASLR allows you to take advantage of added security features in these OS's. This article shows how ASLR can be enabled, however it does require relocation info in the exe's to work http://eleves.ec-lille.fr/~couprieg/post/Enable-DEP-and-ASLR-on-your-applications-built-with-MinGW <http://eleves.ec-lille.fr/%7Ecouprieg/post/Enable-DEP-and-ASLR-on-your-applications-built-with-MinGW>
The article does not mention the relocation info problem.