On Sun, Feb 26, 2012 at 12:11 AM, Joseph Koshy <firstname.lastname@example.org> wrote:
The first question I would have is whether it is possible to build &
test Windows(R)-compatible binaries using open-source and freely
- Would a source tree that has been ported to ReactOS also be
compatible with regular Windows(R)?
Theoretically, yes, as ReactOS is designed to be ABI-compatible with Windows 2003. However, ReactOS is still "alpha". I would expect it to be complete enough for your purposes, though I have never run anything on top of it myself.
- Would a port to use the MingW cross-toolchain be similarly
I see two questions here. First, would building elftoolchain using MinGW gcc be sufficient, instead of using Visual Studio. My port of elftoolchain used the Microsoft compiler because our existing DynamoRIO and Dr. Memory code is built with that compiler. It would certainly be possible to instead build efltoolchain using MinGW gcc, and that would also simplify the porting (designated initializers, snprintf if using MinGW static libc). The MinGW headers do include the key PECOFF info (definitions like IMAGE_SECTION_HEADER, etc.) Furthermore, the resulting static or shared libraries would even be binary compatible and linkable with the Microsoft compiler, so this would not preclude using them with Visual Studio projects. However, the debug symbols would not be compatible, though that may not be a primary concern. By building elftoolchain with the Microsoft compiler I was able to combine the elftoolchain debugging information into Dr. Memory's debug info (in PDB format). Of course this was mostly useful while debugging my changes to elftoolchain itself and would be less important if the elftoolchain project officially supported PECOFF.
Your second question is about cross-compiling and that should work well: you should be able to build PECOFF files on Linux and you could even enable PECOFF parsing support in a Linux build of elftoolchain and run some tests on Linux. You would still want to do testing on Windows/ReactOS itself of course.