We have an internal release ready.
We are working on trying to load the DLL's from Open office into the high memory area of OS/2. We are already having some success with Firefox.
By doing this the lower shared memory issue's with OS/2 and the associates hangs of the desktop should going away.
This is a a feature we have been trying to get in previous open office versions as the loading of these large DLL's into lower shared memory reduces the uptime of an OS/2 system.
Roderick Klein
Mensys B.V.
What should I expect with this answer?
- is there an already running Open Office 3.4 or not?
- when will it be public? (next month/year...?)
- loading the dlls in high memory - has open office to be changed for this or eCS?
That is what it makes hard to understand and follow or stay tuned: the (allways) avesive answers and non concrete informations and timetables - why can't there be an answer that is not a mystery/riddle or that is just simple?
There is a 3.4 version that is receiving final internal testing. It does not yet work with loading DLL into high memory.
The source code for open office does not have be modified for this feature. When you open a word document it already uses API calls to store the dats of that document into high kernel memory (effected by the virtualaddresslimit). However with several different tools you can modify the DLL headers to tell the kernel what portion to also load high of the DLL's into high memory itself.
Scott Garfunkel from IBM (before he stopped working on the OS/2 kernel) put that feature in very far.
Now you can use a tool such as highmem.exe and do *.dll. Once you do that on firefox/thunderbird/openoffice DLL. It works fine, until you exit the application. Then some memory clean up code in the kernel blows up and you get a system TRAP.
(As a warning don't start experimenting these on your system unless you know what your doing and keep track of which DLL's you modify!)
We are looking at the applications to find out if we can only use a subset of DLL's to load high memory. This is already working with Firefox partly. Instead of having 150 of lower shared memory we now end up in the lab with 260 MB or more. (These figures can change). This research is being done with memory dumps, theseus and the kernel debugger. This takes time and is not realy something you can translate into a time frame.
Can this highmem stuff be fixed in the long term, yes it can and we might get a sollution for eCS 2.2. We fixed plenty of other stuff in eCS without kernel sources. Sometimes a fix is easy sometimes its down right hard. For example look at the TCPIP32DLL.DLL that would crash on SMP systems. That new DLL version (gets installed with eCS 2.2 by default and all latest ACPI versions) reduces Firefox crashes on SMP systems. But it did take time to get it done.
If we don't make it then Open Office 3.4 will be released with eCS 2.2 without the high load option with eCS 2.2 in the second week of april.
Thats also why you don't hear much about Open Office because more focus has been on eCS with all the new drivers. Currently I'm also working with David and Lars on the USB drivers.
Roderick Klein
Mensys B.V.
