nisus.com

Nine years + 1 day ago (April 29, 2005), Apple shipped OS X 10.4, the first version to add support for 64-bit addressing.

Since Lion shipped, the OS actually requires 64-bit capable hardware.

And today, almost every app I use runs as a 64-bit app, even those that will likely never need to address more than a few megs of memory, let alone those that need to address more than 4GB.

And then there is Nisus Writer Pro.

I'm a long-time Nisus user, dating back to the days of System 7, and languages kits, and that little copy-protection dongle.

I like the product, and recommend it, so it's embarrassing to see messages like the one by Thom Hogan posted on the Macintouch website today.

I don't mean this post to come off as a rant, but I do think it would be nice for Nisus to give us some hints about their future plans for 64-bit support.

I'm not asking for a ship date, but can you at least tell us if you're actively working on fixing this?

Hi Steven,

I have been observing that same MacInTouch discussion and also wondered about a 64-bit NWP. For discussion we should also consider a response posted there, which seemed well-informed. I will add it here, in hope that Martin will also comment on it if he replies to your question about a 64-bit NWP.

Motti Shneor
To Thom - Actually, they don't need to go 64bit to "break the 32 bit barrier", and I seriously doubt your documents break it in the first place.
A short hint from a developer: When running on a 64bit-kernel Mac OS X, your virtual-memory system always works with 64-bit address-space, and 32bit applications can map much more than just the 4GB of 32bit address. Actually they can assign many pointers to blocks of data each limited to 32bit address space (4GB). So, 32bit program isn't really a problem here.
I didn't use NisusWriter for a long time now, But in the past I was a real master of NisusWriter 3.4.8 and Nisus 4.0.x (On Mac OS Classic). Despite the heavy changes, I clearly remember that Nisus could very well cross-refer document-files containing parts of the same document. It could also easily continue page numbers, maintain continuous styling etc.
Now for your documents:
A quick rough estimate will tell you that a full page of "Arial 10pt" text is about 3750 characters. Times 500 pages gives 1,875,000 characters, or roughly 1.789 megabytes, where 32bit address space spans 4096 megabytes. That is hardly even close to where I'd look for problems.
Even If I double that size (for fonts, styles, printing directions etc), and add lots of images, I simply can't see how your documents "break the 32bit limit". More likely you hit upon a NisusWriter nasty bug that exposes on big documents. That bug would probably also lurk in a 64bit version. I'd recommend that you contact Nisus and report your problem.

TomRitch wrote:For discussion we should also consider a response posted there, which seemed well-informed.

Subsequent to my posting here, I saw Motti Shneor's reply to Thom Hogan's post, and I immediately became a bit embarrassed about having failed to do the basic math myself.

After all, 4GB is enough to encode an hour of HD video. So an 800-page document, or even an 800-thousand-page document should easily fit in 4GB.

But I also see that Thom Hogan has followed up as follows:

No, I break the 32-bit barrier in NisusWriter Pro, with regularity. Watching the app in Activity Monitor, I can see exactly when it tries to allocate more memory than it can manage. I long ago reported this to the developer and the answer I got back is that the problem wouldn't go away until they had 64-bit support.

Following the old rule of 2Kb per letter-size page, 4GB would be enough for over 2 million pages! (Of course, for a 32-bit app, both the data and the app has to share a combined 4GB space.)

At this point, I don't know what to believe. Thom claims he was told by "the developer" (presumably Nisus) that the problem he was running into could only be fixed by adding 64-bit support.

It would be nice if someone from Nisus could give us a definitive answer.

sjk
(Nisus user since Nisus was called Paragon!)

We are aware that 64-bit is desirable and we do have plans to provide a 64-bit version of NWP.

Motti Shneor
To Thom - Actually, they don't need to go 64bit to "break the 32 bit barrier", and I seriously doubt your documents break it in the first place.
A short hint from a developer: When running on a 64bit-kernel Mac OS X, your virtual-memory system always works with 64-bit address-space, and 32bit applications can map much more than just the 4GB of 32bit address.

I believe that is incorrect. While it's true that a 32-bit operating system can map more than 4GB of RAM, any single 32-bit app will be limited to 4GB of RAM. Even using techniques like physical address extension (PAE), does not remove the 4GB limit for a single 32-bit app.

His estimation of memory costs for text is off by a factor of 4x, though he did say it was a rough estimate:

A quick rough estimate will tell you that a full page of "Arial 10pt" text is about 3750 characters. Times 500 pages gives 1,875,000 characters, or roughly 1.789 megabytes, where 32bit address space spans 4096 megabytes. That is hardly even close to where I'd look for problems.

Text characters on OSX are typically stored and accessed using the "unichar" data type, which is a 16-bit Unicode representation. So even if your text uses just boring old A-Z's, you're going to use 2 bytes per character. Each character is also going to be mapped to a glyph in its respective font, which is an additional 2 bytes per character. So at a minimum those 1.8 million characters will cost you 7.2 million bytes of RAM– or about 6.8 MB, not 1.8 MB.

None of this takes into account RAM required to track layout metrics (eg: each line fragment on the page, the advancement for each glyph within its line, formatting, etc). All of that is going to dwarf the requirements for the raw text. So his larger point is correct: text is not the main culprit when it comes to exhausting RAM.

Taking Thom's experience as an example:

Thom Hogan
No, I break the 32-bit barrier in NisusWriter Pro, with regularity. Watching the app in Activity Monitor, I can see exactly when it tries to allocate more memory than it can manage. I long ago reported this to the developer and the answer I got back is that the problem wouldn't go away until they had 64-bit support.

If I recall correctly the RAM exhaustion was caused by the use of many large images. Even if one uses compressed image file formats (eg: JPEG), when it comes time to show these on screen, OSX will decompress and very likely rasterize the image to a full bitmap and cache it. For example, a JPEG taking 1.6 MB of disk storage could expand to something like 20 MB in RAM (depending on the nature of the image). So that single image can easily use more RAM than all the plain text in a 500-page book!

I'd hasten to say that customers running into the 4GB memory limit are rare. In any case, converting NWP to 64-bit will be a good thing and should prevent possible issues when working with complex image-heavy documents.

Hello Steven, in case this is still a point of interest for you, the recently released Nisus Writer Pro version 2.1 is now 64-bit. It also offers up a variety of other enhancements.