Russ, Response to Point 1 That was my understanding as well. However, after analyzing XyWrite 4.018, it appears to be entirely written in assembly. I have not yet examined Signature (SIG) in depth, so it’s possible that version may contain some C components, but I can’t confirm that yet. At the moment, I’m still trying to collect additional versions of the editor executable. Carl was kind enough to share the versions he had, and for example, 4.018 is not the final build — 4.018a appears to be the last version, with an additional 13 bytes of code. In one of my earlier posts, I compiled what I believe is the most comprehensive list so far of different XyWrite versions (though it still needs updating). I’m fairly certain there are individuals who have lesser-known or rarely distributed builds that could contribute meaningfully to this effort. At a minimum, it would be useful to compile verified MD5 and SHA checksums for all known versions. If the source code is ever released and people begin building their own versions, having authoritative checksums for original binaries would help distinguish authentic historical builds from newly compiled ones. That’s something worth considering. Regarding the toolchain: based on opcode analysis and binary characteristics, I settled on MASM 6.11d and LINK 5.13 as the most plausible build tools for XyWrite 4.018. LINK 5.15 also works and still calculates the DOS checksum field (even though MS-DOS doesn’t actually use it). That observation alone suggested the linker version was likely somewhere between 5.10 and 5.15 — earlier versions are noticeably slower. Similarly, MASM 6.0 or 6.11d would both fit; 6.11d assembles 64 ASM files very quickly and worked well in my tests. The instruction profile supports a 386+ target (with a few 486 instructions ================================================================================ 3. SUMMARY TABLE ================================================================================ Item | Hex Signature | Count | Minimum CPU | Present? --------------------------|------------------|--------|-------------|---------- C Runtime strings | ASCII markers | 0 | N/A | NO C compiler watermarks | "Microsoft" etc | 0 | N/A | NO PUSH immediate | 68/6A | 1,172 | 80186 | YES Operand size prefix | 66 | 1,424 | 80386 | YES Address size prefix | 67 | 1,083 | 80386 | YES Near conditional jump | 0F 8x | 171 | 80386 | YES MOVSX | 0F BE/BF | 11 | 80386 | YES SETcc | 0F 9x | 13 | 80386 | YES SHLD/SHRD | 0F A4/A5/AC/AD | 6 | 80386 | YES BT/BTS/BTR/BTC | 0F A3/AB/B3/BA | 47 | 80386 | YES BSWAP | 0F C8-CF | 4 | 80486 | YES 586+ instructions | (various) | 0 | Pentium | NO Notably: No C runtime strings or compiler watermarks were found. No Pentium-class instructions appear. A small number of 486 instructions (e.g., BSWAP) are present. Heavy use of 386 operand/address prefixes suggests deliberate 32-bit instruction usage within a DOS environment. All of that strongly supports a hand-written assembly codebase targeting 386/486 systems rather than a C-port of earlier assembly. Response to Point 2 I’m not entirely sure about the current rights situation — that uncertainty is actually why I initiated the broader conversation in the first place, before we ran into the earlier misunderstandings and distrust. For now, I’ve shared the first two reconstructed builds (XY2 and XY3) with Ed and Carl. I’ll let them set up their own build environments, work with the code independently, and study it. They can report back with their findings while I continue focusing on XyWrite 4. At this stage, I’m trying to proceed carefully and incrementally. The larger discussion — particularly around the releasability of the source code, long-term stewardship, and the possibility of a future “XyWrite 5” orLonger term, I would also like to examine how XyWrite for Windows was implemented and how its architecture evolved compared to the DOS line. But that’s further down the road. For now, my focus remains: documenting what exists, validating builds, understanding version differences, and clarifying the technical lineage Best, XYGHOST ________________________________ From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalfSent: Friday, February 27, 2026 9:46 PM To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx> Subject: Re: About the reverse-engineering thread Congrats on the progress you're making. I just had a couple of thoughts: 1) I recall hearing, and this could be wrong certainly, but at the time that IBM took Xywrite and made Signature, they took the assembly source and ported that to C. (I was under the impression that someone in the group, at that time, and seen the C source and/or had a copy. I remember thinking that 2) Dragonfly Software/Note Bene, the company, I thought had the rights and use of the original Xywrite engine and source, and therefore had control ofverse engineering the executable. (For example, when Compaq came out with the first IBM compatible computer, they were taken to court and had to prove Just some thoughts! Russ On Friday, February 27, 2026 at 03:03:02 PM CST, xyquest xyghost <dmarc-noreply@xxxxxxxxxxxxx> wrote: 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. IAlso, 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 howBest regards, XYGHOST ========================================================================================== === PROGRESS METRICS === ========================================================================================== --- TCH] ========================================================================================== ========================================================================================== ________________________________ From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalfSent: Friday, February 27, 2026 5:43 PM To: xywrite@xxxxxxxxxxxxx <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.