I have fond memories of using Lotus AmiPro word processor. If it would run on 64-bit Windows, I'd probably still use it today.

One of the most infamous bugs in the program was its inability to show simultaneously the bottom of a page together with the beginning of the next page. (See: Wikipedia page)

The limitation was fixed in the 32-bit rewrite (as Word Pro) but I have often wondered what technical reason lay behind this limitation. (If my memory is right, MS Word 6 on Windows 3.x didn't have the same problem.)

Does anyone know the reason for this quirk?

  • Even if it did run on 64-bit Windows I doubt you'd be able to print from it. – Alan B Sep 24 '20 at 11:47
  • @Alan B: true, though not too much of a problem for me, as I don't print much. FWIW, what I find works best on my older OS virtual machines is to install a Postscript printer driver, print to a Postscript file, then convert to PDF. – Armes Pueppilein Sep 24 '20 at 15:03
  • In that era Microsoft used unpublished APIs to get around some limitations in Windows. Competing applications were left out in the cold. – Brian Sep 24 '20 at 15:32

Speculation: each page had its own memory segment, and the page drawing (rendering) routine was designed to work with 16-bit NEAR pointers within the segment.

In the 16-bit world of Windows 2.x and 3.x, memory management informed the program architecture to a large degree. Each pointer could be NEAR or FAR (or HUGE), with tradeoffs in size, performance and flexibility.

I don't know about the internal architecture of Ami Pro, but it would have been possible/convenient to design the application to store each page in its own memory block/segment (probably allocated using GlobalAlloc). The Windows global heap could handle most of the large-scale memory management, including the ability to allocate Expanded or Extended memory blocks. The maximum size of a segment, 64 KiB, would have been quite enough for a typical page, possibly with graphics stored separately. The elements on the page could then be managed using NEAR pointers, possibly even using a local heap inside each segment.

The text display and editing routines could then be kept simple/fast because they could work with a single "active" page at a time, relying only on NEAR pointers. They would allow you to manipulate text within the page, with the complication that any text that flowed off the "bottom" of the page would have to be copied over to the memory block for the next page, etc. Showing two pages at the same time would have been possible but more complex.

  • This definitely sounds plausible. Of course we can only know the full details by seeing the original source code, which is impossible. Voting this as the accepted answer. Thanks for an interesting explanation. – Armes Pueppilein Oct 1 '20 at 9:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.