No OOXML

Just sent the following letter to the Australian Standards rep for the proposal DIS29500 (Microsoft Office Open XML standard) which is being Fast Tracked through ISO, even with blatant interoperability, portability and cultural technical issues.  This is based on the instructions posted at Groklaw. Also, instead of just cut-and-pasting the comments from the No OOXML web site, I’ve reviewed them and altered for Australian concerns, so that they really are my own comments.

Essentials to make Windows almost bareable

Okay, so I hate working in Windows, but on my employer’s equipment at least, I must live with it. After having had this machine replaced twice (faulty Dell hardware) and rebuilt more times than I can remember (Windows BSODs), for a total of at least 3 system migrations this past year, I thought I’d better keep a list of what free software to install on top of Windows, and what adjustments to make, so that at least I don’t feel like I’m wearing a straight jacket. Here goes:

Microsoft Vista keyboard?

I spotted a “Vista compatable” keyboard in K-Mart the other day, which set me thinking… what would a Vista keyboard actually do that a “non-Vista” keyboard can’t?

Then I Googled for “Microsoft Keyboard Vista” and found this ad from Microsoft (Google Cache).

What the? “Designed to make it easier than ever to control PC media from your desk, your lap–or even from the comfort of your couch”. So… if I use this keyboard’s Play button to try and play media that Vista’s DRM system thinks I shouldn’t be playing, does it administer an electric shock? What if I have the keyboard in my lap   Ouch! No so comfortable now…

Thanks, Microsoft, but … ahem, no thanks!

32-bit Windows and JVM virtual memory limit

UPDATE: 20110428 — An explanation of my vague “overheads”

See this excellent post by Dharmir Singh that explains the JVM memory structure and shows where some of the missing heap could be going, which I vaguely hand-waved away as “overheads” below.

UPDATE: 20110228 — Some corrections, more observation needed

First, a correction:  “real” operating systems let processes use <=4GiB on a 32bit system.  *BSD lets user processes access 3GiB (read the Devil Book) and Linux lets user processes malloc up to TASK_SIZE — usually 3GiB on a 32-bit system (see “Professional Linux Kernel Architecture”). This is because in each of these operating systems, 1GiB of user space is reserved to map in system libraries (as opposed 2GiB on Win32 with it’s multiple personality disorder). Mapping parts of the kernel makes calling kernel services quicker. An alternative is Mac OS X (XNU): it’s processes actually only map a tiny part of the kernel into user space, so they may malloc pretty much all of the 4GiB address space (see the OS X book). This is at the cost of a slower context switch whenever a system call is made.

Second is the observation Saar makes in the comments below. I guess that the overheads incurred by the JVM must increase in proportion to the heap size (perhaps some tables to manage references???), but to answer that for certain, I’d need to put the JVM in some sort of debugger and measure the actual overheads incurred (and to do that, I’d need to know what they are, instead of just my vague “overheads”).

Also, switching to 64-bit JVM isn’t necessarily the answer: References are twice as long, usually, which means increased overhead.

Clearly some more research is needed here.

UPDATE: 20100819 — Some interesting related posts

Thanks to the people who took the time to check limits in their own systems and comment on this blog, it makes me seem more credible.

I noticed WordPress is generating some related pages links for this, and one of them is a very interesting and informative read. I recommend you take a look at Esken AKSOY‘s post as a general background on how Windows maps memory for client processes (much more accessible than Microsoft’s Knowledgebase article linked below).  It explains the 2GB per-process limit very well. There are also two posts for the cynics / conspiracy theorists among us

UPDATE: 20081104 — More recent info?

I notice this page gets a lot of hits still. It’s quite old and I haven’t researched to see what is happening in OpenJDK or to see if 6u10 addresses any of this for Windows. If anyone has more info please comment or write to me, I’d like to update what I have.

—

On the 32-bit Windows platform, JVM programs can only ever use up to about 1.5–1.6 GiB of memory in RAM per Java VM process. Allocating a heap size greater than this amount will either not work, or force paging and poor performance.

From my own research on this issue (and taking into account Microsoft’s advice on KnowledgeBase about Win32 virtual memory allocation), this is what I understand about the limits of RAM usability, both for Win32 itself, and for 32-bit JVMs running on Windows. I haven’t researched if this limit applies for 64-bit Windows or JVMs, nor what Vista might be doing. Also, though the 4GiB limit is inherent to 32-bit machines, the 2GiB limit seems to be peculiar to Windows, and I’ve not seen it anywhere in Linux, Solaris or BSD: when Unix runs on a 32-bit machine, there’s a 4GiB limit, but not 2GiB.

Shifting Interfaces

Once again, Microsoft have drastically changed their Office interface.

While the new interface is very nice eye-candy and probably has some new features that could help (arguably), it represents yet another need to re-train.

The old argument that OpenOffice is too different from MS-Office to be quickly useable has just vanished. OpenOffice is more like MS-Office 97 than MS-Office 2007 will be, and really, who has needed any of the features in Office XP or Office 2003? What were they, again…? Oh yeah, anoying interface changes, and removal of the stupid Paperclip.

I think I’ll be distributing my work documents in PDF, created by OOo now, except where I must absolutely use MSO documents for work. Everthing else will be OOo. Now I just need to convince my wife that it’s not worth continually purchasing MSO, or even having it on our home PC.