Win64 is also making good progress behind the scenes. The uncommitted Win64
UNO bridge I've been coding (a lot of it in AMD64 assembly) should now be
able to call arbitrary C++ methods from UNO and UNO methods from C++ (not
tested yet), but the poorly documented internals of MSVC C++ exception
handling are still TODO.
I also played a bit with mingw-w64 (an independent and alternative
mingw-like project capable of producing both Win32 and Win64 binaries) as
an alternative C++ compiler on Windows, but its MSYS2 environment can't
easily replace Cygwin due to using /c instead of /cygdrive/c, so a
tremendous amount of patching configure.ac, set_soenv.in, and many Perl
scripts that assume /cygdrive would be required. Using Cygwin instead of
MSYS2 might be more successful, but since GCC has different exception
handling to MSVC, Windows builds would need to be debugged with gdb instead
of Visual Studio, and AOO extensions would need to be built with mingw and
would be incompatible with the MSVC extensions. Also either we would need
the ship the GCC C and C++ runtimes, or link them statically and have
bloated binaries. It's worth noting LO gave up on mingw.
Where mingw could really help though, is building Windows binaries quickly
for testing purposes. Since Windows builds very slowly, and *nix builds
quickly, we could build a Windows version on *nix at *nix speeds by
compiling it in this setup:
mingw
Cygwin
Wine
*nix
;-)
We could also try a more ambitious setup of Windows Platform SDK in place
of mingw there, but how well it works on Wine is an open question.
FWIW, clang-cl from LLVM is really easy to install:
http://www.llvm.org/builds/
The thing is, libc++ hasn't been ported yet to Windows, so it depends on
the Visual Studio libraries for everything.
All in all it is likely a better option than mingw, or cygwin.
Pedro.
