Win64 port
This documents progress being made in porting AOO to run on 64 bit Windows.
Strictly speaking, it should be called the x86-64 or AMD64 port, since there are other 64 bit architectures that Microsoft Windows supports that are not being addressed here (eg. Aarch64), but most of the work done is to data types and API calls, so it will also benefit future ports to those other 64 bit architectures.
This has traditionally been a difficult platform to port to due to Windows uniquely being a LLP64 platform, whereas *nix is LP64; ie. sizeof(long) == 32 on Win64, but 64 on *nix. Every "long" everywhere in the codebase may have to potentially be replaced, and every conversion between long and pointer will definitely need replacement. A UNO bridge for LLP64 will also be necessary.
It's not all doom and gloom though. The *nix 64 bit port already must have eliminated conversions between int and pointer, making our life easier. Java, Python, StarBasic and other languages with types of known size should be ok.
So starting with Windows 7 64 bit, Cygwin64, 64 bit Java 9, Ant 1.10.2, let's push on and see how far we get.
Status
- In 2018, at least 83 out of 189 modules (43.9%) built successfully.
- 2 January 2025, 112 out of 185 modules (60%) were building successfully.
- 3 January 2025, 138 out of 185 modules (74.6%) were building successfully.
- 4 January 2025, 158 out of 185 modules (85.4%) were building successfully.
Currently the x86-64 bridge in main/bridges needs to be developed further and debugged. The bridge needs to work with the Win64 C++ ABI in assembly language, and throw and catch arbitrary C++ exceptions from assembly language, a major challenge.
Testing
Use the latest Git trunk and 64 bit Cygwin.
Make sure you pass --enable-win64 to ./configure like below (without it, 32 bit binaries get built), and then "source winAMD64Env.set.sh":
autoconf
./configure \
--enable-win64 \
--with-dmake-url=https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2 \
--with-epm-url=https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz \
--disable-directx --with-ant-home=/cygdrive/c/apache-ant-1.10.2 \
--without-junit \
--enable-verbose
source winAMD64Env.set.sh
./bootstrap
cd instsetoo_native
build --all
Outstanding issues
Compatibility with old Windows versions
uwinapi in main/sal proxies/emulates over 50 Windows API functions that are not available on older Windows versions, but uses 32 bit assembly languages. Only a few were ported to AMD64 (via porting them to C instead of assembly). Most should be unnecessary though, and are there mostly for Win9x.
Python
Python was a major mission to patch and might not work.
Star Basic native DLL calls
The "DLL manager" in main/basic/source/runtime/dllmgr.cxx, which allows StarBasic to call native functions in arbitrary external DLLs, only ever supported Win32.
At present, it's been disabled on Win64. Whether it should be implemented, and whether it should support other operating systems and architectures, remains an open question.
Database access and SDBC API
What size are traditional integer-valued SQL properties, such as Statement.MaxRows, on 64 bit database drivers?
- Java's JDBC API added a 64 bit Statement.getLargeMaxRows() (https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#getLargeMaxRows--) in addition to the older 32 bit Statement.getMaxRows().
- ODBC started using SQLLEN/SQLULEN in such cases, which uses pointer-sized integers, ie. 32 bit on 32 bit architectures, and 64 bit on 64 bit architectures (https://www.unixodbc.org/doc/ODBC64.html).
- ADO is like ODBC.
SDBC provides integral properties, such as Statement.MaxRows, almost exclusively in 32 bits (http://www.openoffice.org/api/docs/common/ref/com/sun/star/sdbc/Statement.html#MaxRows). What should we do about that, when calling lower-level APIs such as the above, that take/return 64 bit parameters?
At present, we extend to 64 bit integers when calling, and truncate to 32 bit integers when returning.
However in the long run, it would be more desirable to extends the SDBC API to allow callers to work with 64 bit integers directly. Since UNO interfaces are immutable, we'd have to provide new interfaces with different names (eg. Statement2), or same name but in a different package.
Java > 8 breaks the build in scripting
With Java 9 and later, the build breaks in the scripting module, because main/scripting/java/build.xml passes the -Xbootclasspath compiler argument to javac, but this was removed after Java 8.
Maybe -Xbootclasspath is unnecessary. It was done to avoid some Rhino bug, and might not be required any more? Needs testing.
Issues (old)
| Date | Issue | Resolution | Fixed in SVN revision |
|---|---|---|---|
| 2018/03/03 | Java 9 is not detected by oowintool. | Patched oowintool to detect it. | 1825763 |
| 2018/03/04 | dmake's old config.guess can't detect Cygwin64. | Patched main/bootstrap.1 to overwrite its config.guess with our own newer one. | 1825798
1825802 |
| 2018/03/04 | dmake uses Cygwin API functions that were deprecated on Cygwin32 and have been removed in Cygwin64. | Added a patch in main/solenv/src to change dmake to use the replacement Cygwin APIs, and patched main/bootstrap.1 to apply the patch during ./bootstrap. | 1825798
1825802 |
| 2018/03/04 | Binaries built are 32 bit. | Changes to configure.ac, set_soenv.in, various dmake and gbuild files are necessary to set up the 64 bit cl.exe. WORK ONGOING. | 1825935 |
| 2018/03/05 | ext_libraries/apr builds 32 bit and fails to link. | Build was hardcoded to 32 bit, and needed 64 bit detection improved and resulting build files copied from the right location. | 1825848 |
| 2018/03/05 | main/lucene won't build with Java 1.9, needs -source and -target to be at least 1.6. | Patched it to use those. As discussed on the mailing list before, we should use minimum Java version of 1.7, but OS/2 only has 1.6, so this change which used 1.6 shouldn't break any platform. | 1825849 |
| 2018/03/05 | main/curl only builds 32 bit and fails to link. | Patched it to build 64 bit on Win64. | 1825850 |
| 2018/03/05 | main/sal doesn't build. Missing endianness, wrong types, 32-bit assembly language in macros, lots wrong... | Builds now and unit tests pass, but unsure whether there are any remaining type conversion bugs. | 1825923
1826021 |
| 2018/03/06 | Win64 has the wrong CPPU_ENV of "msci". | Changed it to "mscx". | 1825956 but reverted and placed into win64.patch |
| 2018/03/07 | main/icu doesn't build, hardcoded to Win32. | Patched to use 64 bit compiler as necessary. | 1826062 |
| 2018/03/07 | main/salhelper won't link, needs linker symbol map. | Added new symbol map for Win64. | 1826066 |
| 2018/03/07 | main/icc won't compile, needs strcasecmp. | If Win32 is not detected, stricmp is defined as strcasebmp. Patched to detect AMD64 as well. | 1826069 |
| 2018/03/07 | ridljar won't build, javadep from soltools doesn't support Java 9's new class file changes. | Patched javadep. | 1826078 |
