|
Kurt,
That was XyWrite II Plus 1.10 (1.20). For XyWrite 4.018, the original EXE stub was built with MASM 6.11d (or something very close) and LINK 5.13. Notably, all
XyWrite for Windows versions were also linked with LINK.EXE 5.13, which helped narrow the toolchain profile.
The executable consists of:
If you attempt to disassemble the full EXE directly, most tools will only process the portion defined by the MZ header (i.e., the stub). The overlay is effectively invisible to conventional EXE-aware disassemblers unless you extract it first.
Key Metrics (Original vs Rebuilt)
MZ Header (14/14 fields match)
The critical point is that the MZ header’s calculated image size (pages +d that boundary is overlay data (312,256 bytes). This layout matches exactly in the rebuilt version — including
About the BIN overlay
The BIN file I’m currently using is extracted directly from the original 4.018 executable. With the right script, separating the overlay from the stub is straightforward: you calculate the logical image size from the MZ header and extract everything beyond
Yes, I have disassembled the overlay BIN. It’s substantial — roughly 275K lines once processed — consisting of a mix of code and structured data.
You’re absolutely right that overlay entry points must remain consistent regardless of which overlay segment is loaded. The structure strongly suggests a predefined dispatch or jump table model, where the stub transfers control to known offsets inside the overlay
My current task is:
Once that process is complete (and reproducible), XyWrite 4.018 will be fully reverse-engineered at the binary level, giving us a controlled and verifiable baseline going forward.
Best,
XYGHOST
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalf of Kurt Geisel <dmarc-noreply@xxxxxxxxxxxxx>
Sent: Friday, February 27, 2026 9:41 PM To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx> Subject: RE: About the reverse-engineering thread Thank you for understanding.
I was curious about the overlay approach. When I peeked at your code in Gitlab before it was removed, I saw there were a lot of holes left in the assembler output. I suspect (if not vaguely recall) this was a common way of preparing for
When you say have the BIN files containing the overlay, is this something you have also tried to disassemble? Does its composition appear to rely on an external (custom) tool that you don’t have direct access to? Presumably, it had to
- Kurt
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx>
On Behalf Of xyquest xyghost
Dear Ed, Carl and everyone, Thank you for looking past the generated emails and seeing the positive side of this project. I truly appreciate that. I have sent Ed and Carl the XyWrite2 and XyWrite3 source code for review. I hope he can report his findings and impressions to the group. Also, I have reverse engineered the stub of XyWrite 4.018. I believe many people in this community may not know that XyWrite 4 was built in stages. First, it was built as a The 360KB stub (which is most of the source code) has now been fully reconstructed. What remains is the overlay, about 275K lines of data and some code, mostly data with some code. That part should be easier I will continue the work and share progress. P.S. I will continue to use AI to help generate messages, regardless of how some people feel. What matters is the technical work and the results. I'll let Ed and Carl report back to the group. Best regards, XYGHOST
========================================================================================== === PROGRESS METRICS === ==========================================================================================
Metric ----------------------------------- ---------------------------------------- Full file size 681824 (delta=0) [MATCH] Stub size 369568 (orig=369568, delta=0) [MATCH] Header size 0x0C00 (orig=0x0C00) [MATCH] Reloc count 597 (orig=597) [MATCH] MZ header fields 14/14 Reloc OK (pos+tgt) 597/597 (100%) Full file byte identity 681824/681824 (100%) Load image identity 366496/366496 (100%) Overlay identity 312256/312256 (100%) Active zone opcode identity 17159/17159 (100%) Header diffs 0 bytes Diff regions 0 Longest contiguous match 681824 bytes String match rate 6805/6805 MD5 match [MATCH]
========================================================================================== END OF REPORT ========================================================================================== From:
xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalf of em36 <dmarc-noreply@xxxxxxxxxxxxx>
For better or worse, this thread illustrates something I've noticed
|