Thank you for the explanation. That is indeed impressive work. That is a "simpler" overlay system than I was imagining (I'm sure there areplex overlay building tools that were on the market in that era. Now that It in 5.x?). But I think it had a dependency on some runtime overlay manager. You would probably be able to observe this by whatever interrupt they chose for that. In any case—your huge investment of time is appreciated. - Kurt ________________________________ From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalfSent: Friday, February 27, 2026 7:24 PM To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx> Subject: Re: About the reverse-engineering thread 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: A standard MZ stub (fully defined by the MZ header) Followed by a raw overlay appended beyond the logical EXE image size defined in the header 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) === TRINITY (Key Metrics) === MZ Header (14/14 fields match) Decoded EXE image size (per header): 369,568 bytes Actual full file size (including overlay): 681,824 bytes Overlay size: 312,256 bytes Relocation entries: 597 (XyWrite 3.58b was a beast — 1,333 relocation entries — and it took three months and hundreds of hours to fully reverse engineer.) Relocation table size: 2,388 bytes 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 checksum and relocation table — producing a byte-for-byte identical MD5. ________________________________ 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 that offset. 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 space. My current task is: Split code from data cleanly Reassemble the overlay components Relink them into a BIN overlay Append that rebuilt overlay to the reconstructed stub 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 behalfSent: 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 overlays. 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 be laid out such that the entry point locations were consistent - Kurt From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> On BehalfSent: Friday, February 27, 2026 1:03 PM To: xywrite@xxxxxxxxxxxxx Subject: Re: About the reverse-engineering thread 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 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 360KB 16-bit EXE program. Then a BIN overlay was appended, making the final version about 665KB. 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 to complete. I will continue the work and share progress. P.S. I will continue to use AI to help generate messages, regardless of how Best regards, XYGHOST ========================================================================================== === PROGRESS METRICS === ========================================================================================== --- TCH] ========================================================================================== ========================================================================================== ________________________________ From: xywrite-bounce@xxxxxxxxxxxxx<mailto:xywrite-bounce@xxxxxxxxxxxxx> <xywrite-bounce@xxxxxxxxxxxxx<mailto:xywrite-bounce@xxxxxxxxxxxxx>> on behalf of em36 <dmarc-noreply@xxxxxxxxxxxxx<mailto:dmarc-noreply@xxxxxxxxxxxxx>> Sent: Friday, February 27, 2026 5:43 PM To: xywrite@xxxxxxxxxxxxx<mailto:xywrite@xxxxxxxxxxxxx> <xywrite@xxxxxxxxxxxxx<mailto:xywrite@xxxxxxxxxxxxx>> Subject: About the reverse-engineering thread For better or worse, this thread illustrates something I've noticed elsewhere: Whenever someone spends dozens or hundreds of hours working on something that will benefit many other people, a significant number of people will complain that there is something dishonest or disgraceful about it. I've seen many instances of this, and that is perhaps the case here. I don't care whether an email message seems to have been cleaned up or written by AI. The author may not have the linguistic skills needed to write the message on their own. What matters is the content, and in this case, it seems very likely that the content is both real and valuable. It's impossible (for me at least) to imagine any way it could not be. The culture of mistrust that has manifested itself on this list may now have destroyed the one real chance we have of bringing XyWrite into the twenty-first century. I very much hope that the person who is working on this will have the grace to ignore the mistrust and continue working. and I would certainly hope to hear more about this project. My guess is that I'm not alone in thinking this. Anyone who shares my view - and I hope that the original poster will consider joining in this - is welcome to get in touch with me at edward-dot-mendelson-at-columbia-dot-edu and I'll be glad to share the information with others who get in touch in the same way. But I hope someone else has already taken steps in the right direction, and my offer here is superfluous.