Windows版OpenOfficeの64bitへの道（壱）

Porting to x86-64 (AMD64, EM64T)

Linux OpenOffice X64のダウンロードはここへ

OpenOffice 64bit版のコンパイルは64bitのMSコンパイルが必要です。このリンクにわずかの情報があって、参考になるでしょう。

Only the newest Visual Studio 2005 is ready to compile C++ 64bit code. Further only versions >= Visual Studio 2005 Standard
will support that.
see also "http://msdn2.microsoft.com/en-us/library/hs24szh9(VS.80).aspx".

64-bit OpenOffice.org installed and working on a linux sandbox

32bitのjavaから64bitのOSのAPIを呼び出そうとすると、Cote’s Weblogにすばらしい内容があって、下にそのままコピーしました。

Also, in response to last week’s 64 bit talk, Roger V. sent this in:

A 64-bit OS can access more memory because it’s using 64-bit address pointers. In C, C++, and assembly language, one deals directly with address pointers.

Whereas in Java, C#, or the myriad of various scripting languages, one is shielded from raw pointers and one doesn’t make direct calls to the OS from these mangaged languages - unless done through a special mapping or adapting mechanism.

So in Java one passes references to objects around and has no idea how big the reference is. Unlike address pointers in C, a Java reference is not directly manipulated. Now from Java, if you want to interact with the native OS, where address pointer types do matter, you have to use the JNI and write that code in C. Java interacts via JNI conventions with the C code, and the C code can interact with any native OS APIs. The C code can then deal with any 32-bit vs 64-bit conversion issues (perhaps by even dropping into some inline assembly language if necessary).

When you pass an address (like a pointer to a string buffer) to an OS API, the language signature for calling the API will make the type of address pointer (32-bit or 64-bit) very, very explicit indeed. You have to pass it the kind of address pointer that the API expects.

So 32-bit code running on a 64-bit OS has to make any system call interactions via some sort of thunk layer. Hence when I run 64-bit Firefox on 64-bit Ubuntu and attempt to use the Adobe Flash player (which to this day is still only available in 32-bit versions no matter what OS), I have to use a special adapter plugin that provides for this thunking. (Same goes for any C/C++ shared libraries - the 32-bit app will have to have 32-bit versions of its shared libraries.)

Now with Apple’s latest version of the Mac OS X, the thunking is essentially the other direction. Apple is still using an essentially 32-bit OS, but wants to provide the ability to run 64-bit software applications (Photoshop) that can address beyond 4 GB of memory. So they have a special 64-bit compatible thunking layer for such 64-bit programs that adapts OS calls down to the actual 32-bit native OS API calls. If there is a comprehensive 64-bit thunking layer for all OS APIs, then 64-bit software, including their shared libraries, can be ported to run.

If you young whipper snappers had been around programming in C or assembly back in the days of the 8088/8086/80286 and then dealt with the transition from 16-bit code (MS-DOS, Win3.0) to 32-bit architecture (Win32), this 32-bit to 64-bit thing would all be old hat. Also, if you recall, Win95 was a 32-bit API programming model that thunked down to an underlying 16-bit MS-DOS underpinning.

Hopefully 64-bit will last us longer than 32-bit has - before we have to deal with the 64-bit to 128-bit transition.

–RogerV

Java Native Access - Dynamically access native libraries from Java without JNI.


32-bit or 64-bit JVM? How about a Hybrid?

Building OpenOffice.org 2.x (680er series) under Windows with MinGW compiler+tcsh