There were a couple of things that were to my understanding, fwiw.
- At the time the IBM took over the port of Xywrite to a windows version, they had ported the assembly code base to C and had added Windows font support, etc.
- It was also my understanding that some members of this group saw and had access, albeit, that C source code.
- Dragonfly Software/Nota Bene, have some right to the Xywrite engine and it's source. I would think they might have a say into your efforts which i applaud, as it moves forward!
ans-serif;font-size:13px;color:#26282a;">
quest xyghost <dmarc-noreply@xxxxxxxxxxxxx> wrote:
, Arial, sans-serif;font-size:13px;color:#26282a;border-left: 1px solid #ccc;padding-left: 8px;margin: 0px 0px 0px 8px" class="ydpab1a9672inline_reply_quote_container" data-split-quote-node="true">
Michael,
Thank you for the thoughtful reply — I genuinely appreciate both the interest and the candid perspective.
That’s a fair question: what am I actually shooting for?
You’re right that the scope may seem like overkill if the goal werech broader and long-term.
One of my primary goals is to fully reverse engineer XyWrite 4.018 — completely and accurately.
For context:
• I have already completed a full reverse engineering of XyWrite II• I am currently deep into XyWrite III Plus v3.58b — which is already a very large undertaking (1,333 relocations, 57 structural zones, complex overlay behavior, etc.).
• XyWrite 4.018 is significantly larger and architecturally more complex than both.
The deeper I go, the more I realize that binary analysis alone is not enough to fully understand the intent behind architectural decisions — especially across transitions like:
II → III
III → III Plus
III Plus → 4.x
That’s where historical toolchain knowledge, developer recollections, build systems, and architectural context become invaluable.
This isn’t just about disassembly.
It’s about understanding:
• The evolution of the memory model
• Overlay and segment strategy
• The shift (if any) from pure assembly toward C integration
• How features were layered without breaking newsroom stability
• What constraints shaped the engine’s internal design
Ultimately, yes — I want to understand the word processor completely.
But beyond that, I want to give something back.
If we can fully understand 4.018 at the architectural level, it opens the door to:
• A clean, documented technical reference of the engine
• A maintainable modern codebase inspired by the original
• A possible “XyWrite 5.0” built with the same philosophy
• Easier ports (Linux-native included)
• A future-proofed continuation rather than a fossilized binary
XyWrite is still my favorite word processor. I would like to see its designe 16-bit executables.
So yes — it’s ambitious. Possibly absurdly ambitious.
But it’s motivated by preservation, understanding, and forward continuity — not just reverse engineering for its own sake.
And I would genuinely welcome your thoughts, especially given your systems background. If you’re experimenting with Linux-native directions, that intersects directly with where I ultimately hope this can go.
Thank you again for engaging — I’m glad you’ll be following along.
Best,
XYGHOST358B
(Prefer to remain anonymous)
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalf of Michael Wilson <dmarc-noreply@xxxxxxxxxxxxx>
Sent: Sunday, February 22, 2026 6:25 PM
To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx>
Subject: Re: Archival Request – Seeking All XyWrite Versions
I certainly have no proprietary knowledge. I was just a XyWrite fan back in the day and only recently discovered this list.
But I'm a retired systems developer and your line of questioning piques my interest.
What are you actually shooting for? The breadth and depth of what you're looking for would even be breathtaking overkill for a simple reverse engineering of the software, if that was your goal.
Don't get me wrong, I'm not "raising an eyebrow" at your motivations.
As an adjacent note: I've been toying with doing some very strange things to get it a linux native version, with little success (owing to little
So I'll be watching your threads with great interest 🙂
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> onnone">
Sent: Sunday, February 22, 2026 11:39 AM
To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx>
Subject: Archival Request – Seeking All XyWrite Versions for
Hello everyone,
As part of my ongoing research into the development history of XyWrite, I am attempting to document and analyze the evolution of its executable code across all major and minor releases.
To do this accurately, I am hoping to locate as many original binaries as possible — including:
• Retail releases (all eras)
• Minor revisions and lettered builds
• OEM variants
• Newsroom or enterprise editions
• Beta or pre-retail builds
• IBM Signature / Project J variants
• Regional or localized releases
• Disk images with original timestamps intact
Even versions that may seem redundant (e.g., small letter revisions) are extremely valuable for comparative analysis of:
• Toolchain changes
• Memory model transitions
• Overlay/linking strategies
• Optimization patterns
• Feature integrations and removals
• Bug-fix deltas between builds
If you have any versions in your personal archives and would be willing to share copies for research and preservation purposes, I would be deeply grateful. I am especially interested in maintaining original file dates and untouched binary states.
This effort is strictly historical and technical in nature — focused on documenting the architectural evolution of XyWrite across its lifetime.
If you prefer to respond privately, please feel free to do so.
Thank you to everyone who has already contributed knowledge and corrections. Your expertise is helping build what I hope will become a reliable technical record.
Sincerely,
XYGHOST358B
(Prefer to remain anonymous)