Kari,
I’m somewhat familiar virtual environments. They are great for many uses. However, one of the original ‘wishes’ that prompted this ‘radical idea’ thread is the wish that XyWrite could run in an environment where it could make use of the vastly extended memory that old 16 bit machines could not. (A secondary ‘wish’ was to make the modern Windows environment resources available; such as printers, etc.)
I don’t think the virtual environment is the real problem here. The ‘legacy’ XyWrite application doesn’t know how to access it to begin with.
The original Atex editor was actually an OS unto itself. As such, it was also restricted to a 16 bit address space, but the OS knew how to page in memory when it was needed. All the editor application was to ‘ask’ for more space for the data it was working on and it would be paged into the 16 bit address space the editor could a access.
A number of older applications that were running on the same DOS/Win3.x as XyWrite could make use of extended memory, which could be available by installing an extended memory card and paging driver to DOS during system boot-up. (I haven’t thought about Config.sys for many years. 😊)
The problem was that XyWrite still didn't know it was there. The programs that did, such as Lotus 1-2-3, did.
Which reminds me. The Lotus people also marketed a word processor that looked remarkably like Atex/XyWrite. The name was Ami Pro. – The resemblance Atex/XyWrite may not be accidental. A number of the old Atex programmers migrated to Lotus Corp. In Cambridge. – An equally ‘odd’ coincidence is that when Lotus got bought out by IBM, and the Ami Pro dropped. Eventually someone from that conglomeration of IBM acquisitions created Signature.)
I’d bet that Ami Pro could access paged memory.
Sent from Mail for Windows 10
From: xywrite-bounce@xxxxxxxxon behalf of Kari Eveli
Sent: Saturday, April 21, 2018 3:26:13 AM
To: xywrite@xxxxxxxx
Subject: Re: A radical idea: a new XyWritePhil,
For nostalgia, the best remedy is using one of the virtualized solutions
to run old programs. In many cases, old programs run better and faster
and more reliably now than ever before. And, best of all, they can be
used in novel ways in workflows that keep basic editing very simple (as
in Xy3) and converted (either using XY print files or external
conversion programs) to produce for instance Unicode XML. For this kind
of use, I think the Xy3 file format is far better than newer more
complicated variants. Therefore, a modified Xy3 engine is what I would
like to see. Xy4 has many amenities that serve their users well, but it
is much more complicated to use as a rough and ready formatting platform
for custom purposes.
P.S. I have used NB3 to convert from Xy to Ventura and ultimately to
PDF. And nowadays, I use it to convert from Xy via external conversion
programs to Unicode XML-type format for publishing online databases. For
this work, native Unicode support and an augmented formatting code
vocabulary (custom 'print modes' in Xy parlance) would be beneficial.
Best regards,
Kari Eveli
LEXITEC Book Publishing (Finland)
lexitec@xxxxxxxx
*** Lexitec Online ***
Lexitec in English:
Home page in Finnish:
> I got into this discussion to see if there is a modern need that would
> make it worthwhile to pull XyWrite into 2018. So far, there’s been a big
> mix of opinions.
>
> Personally, I’m nostalgic about XyWrite. I used to support if for my
> publishing clients. I’m also nostalgic about my job as a programmer at
> Atex where the editor was born.
>