parity: 1.0.5 released

parity is an open source project who's goal it is to ease porting applications from UNIX-like systems to Windows. It relies on the presence of a UNIX Layer for Windows such as Interix or Cygwin. parity is most tested on Microsofts Subsystem for UNIX-based Applications, so it will work there best.

parity uses Microsoft Tools - like cl.exe, link.exe, etc. - to mimic a GCC like interface, while really compiling natively for Windows. This results in pure and native Windows Libraries and Executables, which can be mixed freely with any existing Software pieces.

The most effort has been put into shared library handling, which now behaves nearly the same as on common UNIX-like systems. There also is a patch for libtool, which makes it know about parity (which passes all tests of the libtool test-suite). Advanced Features like a working -rpath option have been added to improve the handling of DLLs on Windows.

parity ships with a little runtime enhancement library called parity.runtime. This library abstracts away the need to take care of what kind of paths are used. This means you can now give a UNIX-style path to an executable built with parity, and it will understand it. Previously this was not possible, and all Windows executables would need Windows-style paths to work.

parity 1.0.5

fixed support for Interix 6.0. Support for Visual Studio 2008 tested.

Migrated Project Files and Solutions to Visual Studio 2008.

Enabled color support for native windows builds, if it is built using autotools (i.e. build parity with itself).

Parity no longer decides wether certain paths are "bad", like /usr/local. This fixes issues with a Gentoo Prefix installation.

Fixed the -O switches, which had no effect until now. Now proper optimizations are performed by the target compiler.

Added an x86 binary decoder to support fixing certain instructions at link time. Insertion of instructions in unlinked code is now fully supported. This is the basic building block for beeing able to avoid the __declspec(dllimport)'s. The plan is, to fix every instruction that accesses a global data symbol to use a symbol that possibly comes from a DLL by adding an additional indirection. There is still lot of work to be done, since every x86 instruction that can access such a global data symbol (every instruction that can take an address as operand) needs to be recognized and patched.

Posted by Markus Duft 2008-05-13