5

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?

Improve this question
5
  • Even if it did run on 64-bit Windows I doubt you'd be able to print from it.
    – Alan B
    Commented Sep 24, 2020 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
    Commented Sep 24, 2020 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
    Commented Sep 24, 2020 at 15:32
  • Funny thing, I still use AmiPro (for 30 years now). It runs fine on Win10 32-bit, and I just found solution to install it also on 64-bit. Here it is: return2.net/run-16-bit-amipro-3-on-64-bit-windows-10 Didn't try it yet, but it looks promising. Regarding displaying pages... Personally, I prefer Ami solution of keeping them separate than scrolling through them endlessly. I started to use Lotus WordPro on my new laptop since I couldn't install Ami on its 64-bit system. And I hate seeing next page at the bottom of current. But that's me :).
    – AmiPro User
    Commented Jan 24, 2022 at 22:06
  • 1
    @AmiProUser Welcome to the site - I know you can't comment, and since this didn't answer the question I converted it to a comment for you. Hope you stick around!
    – Matt Lacey ♦
    Commented Jan 25, 2022 at 10:07

1 Answer 1

Reset to default
5

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.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .