|
Hi Russ,
Thank you so much for your insights and for sharing the information about IBM’s port and Dragonfly Software/Nota Bene’s involvement. Your input is incredibly helpful and provides additional context as I continue to work on this project. I’ll definitely keep
these factors in mind as I move forward.
In terms of my progress, I’ve been diving into the codebase and gathering feedback from the community. After careful consideration, I’ve decided to remove the project (II PLUS) from GitLab for now. I’ll continue my research and engage more with the community
as I study the word processor and its underlying structure.
Here’s a summary of my current research findings:
3. SUMMARY TABLE
4. CONCLUSIONS
XyWrite 4.018 appears to be built entirely with MASM, and the use of advanced instructions like MOVSX, SETcc, and BSWAP confirms this. There is no evidence of C language in the binary, and the number of relocations (597) is typical for a well-organized assembly
project, rather than C compiler output.
Based on this analysis, my current understanding is that XyWrite 4.018 is a fully hand-written assembly program, with no evidence of C code involved, contrary to some earlier assumptions.
Given all this, I’ve decided to take a step back from the GitLab repository for now to further study the architecture, engage with the community, and plan the next steps for the project. Your feedback and support, along with the help from the community, will
be invaluable as I continue this effort.
Thanks again for your support, and I look forward to continuing the conversation as I move forward.
Best regards,
XYGHOST
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalf of russurquhart1@xxxxxxxxxxx <dmarc-noreply@xxxxxxxxxxxxx>
Sent: Monday, February 23, 2026 4:53 AM To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx> Subject: Re: Archival Request – Seeking All XyWrite Versions for Code Evolution Research Hi,
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!
Good luck,
Russ
On Sunday, February 22, 2026 at 01:02:10 PM CST, xyquest xyghost <dmarc-noreply@xxxxxxxxxxxxx> wrote:
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 were simple curiosity or a light reverse engineering exercise. But my aim is much 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 v1.10.
• 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 design principles continue well into the future instead of remaining locked inside 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 for Code Evolution Research
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. I'm all in on exhaustive thoroughness. But "having a complete corpus of XyWrite's history" aside, I just can't see it.
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 follow-through, to be honest.)
So I'll be watching your threads with great interest 🙂
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalf of xyquest xyghost <dmarc-noreply@xxxxxxxxxxxxx>
Sent: Sunday, February 22, 2026 11:39 AM To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx> Subject: Archival Request – Seeking All XyWrite Versions for Code Evolution Research
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)
|