[Date Prev][Date Next][Subject Prev][Subject Next][Date Index][Subject Index]

Re: XYWRITE 4.018 Source Code | request for resources



Harry,
My impression is that people here are mostly in “receive mode.” I came in open to
collaboration, expecting more active engagement. A few people have been helpful and shared resources
when I asked, which I appreciate—but overall, I expected more support and contribution.
That said, I’m continuing forward. I’m about 60% done with XyWin and will keep pushing
ahead. I may extend the work further, but so far I’m honestly disappointed by the limited
response and lack of resources, information, etc. I requested.
________________________________
XyWin (XyWrite for Windows 4.13) – Key Bugs & Issues
Below is a cleaned and consolidated list of the major, historically documented problems, along with
brief descriptions and potential solutions.
________________________________
1. System Stability
General Protection Faults (GPF)

  *   Description: Random crashes during common operations (save, switching modes, UI interactions).
  *   Cause: Invalid memory access due to Win16 segmentation and C/ASM boundary issues.
  *   Potential Fix:
     *   Audit C/ASM interface (far pointers, segment handling)
     *   Ensure proper use of GlobalLock / memory validation
     *   Increase stack/heap sizes in the executable

________________________________
2. Startup Failures
Font Enumeration Crash

  *   Description: Crash on startup when too many system fonts are installed.
  *   Cause: Fixed-size buffer overflow during font listing.
  *   Potential Fix:
     *   Add bounds checking in font enumeration callback
     *   Cap font count or dynamically allocate buffer

UIF Device Corruption (XWUIF.UIF)

  *   Description: Immediate crash or “Internal Error” on launch.
  *   Cause: Malformed or oversized device= string.
  *   Potential Fix:
     *   Replace unsafe string handling (strcpy, sprintf)
     *   Enforce buffer limits and proper termination

________________________________
3. Printing Issues
UWF Spooler Hang

  *   Description: Application freezes during printing.
  *   Cause: Incompatible “Universal Write Filter” logic with Windows spooler.
  *   Potential Fix:
     *   Change default UWF setting (2 → 1)
     *   Adjust print loop timing / status handling

Driver Conflicts / Lockups

  *   Description: Crashes or freezes when using certain printer drivers.
  *   Cause: Conflict between legacy drivers and Windows environment.
  *   Potential Fix:
     *   Use standard Windows drivers
     *   Remove reliance on legacy/native drivers

________________________________
4. Editing & Core Functionality
No Undo System

  *   Description: No way to revert edits—major usability flaw.
  *   Cause: Original architecture lacks undo tracking.
  *   Potential Fix:
     *   Implement a basic undo buffer (intercept insert/delete operations)
     *   Store changes in a memory-backed stack

Erratic Text Selection

  *   Description: Mouse selection is inaccurate or inconsistent.
  *   Cause: Poor integration between GUI layer and text engine.
  *   Potential Fix:
     *   Rework cursor mapping logic
     *   Fall back to keyboard-based selection model

________________________________
5. File Handling & Compatibility
Import/Export Failures

  *   Description: Word/WordPerfect filters fail or corrupt formatting.
  *   Cause: Broken or improperly installed conversion filters.
  *   Potential Fix:
     *   Rebuild or replace filters
     *   Use RTF/plain text as intermediary formats

ANSI / Unicode Limitations

  *   Description: Cannot handle modern character sets.
  *   Cause: Legacy encoding assumptions.
  *   Potential Fix:
     *   Extend character handling layer (non-trivial)
     *   Accept limitation or bridge via external conversion

________________________________
6. User Interface Issues
Dialog Box Freezes (“Sticking”)

  *   Description: Dialogs become unresponsive or won’t close.
  *   Cause: UI thread/message loop issues in Win16 environment.
  *   Potential Fix:
     *   Improve message handling
     *   Add forced refresh or state reset logic

________________________________
7. Architectural Limitations
Memory Constraints (16-bit)

  *   Description: Inherent limits due to 16-bit segmented memory model.
  *   Cause: Win16 architecture and legacy design.
  *   Potential Fix:
     *   Optimize memory usage
     *   Increase stack/heap where possible
     *   Long-term: requires architectural redesign

________________________________
Summary
To your question: yes—in theory, XyWin could have delivered those features (no memory limits,
proper undo/redo, no DOS shelling).

If people have more info on other bugs please share them here with all.
-Best

--
====================================================================================================
  XYWIN OVERALL SUMMARY
====================================================================================================
  Total segments:        81
  Byte-identical:        22 (27.2%)
  Tier-1 (trivial):      31
  Tier-2 (close):         1
  Tier-3 (moderate):      7
  Tier-4 (significant):  18
  Tier-5 (major):         2

  Segment bytes (orig):     672,735
  Segment bytes (built):    681,403
  Byte match (overlap):     375,146 / 672,495 (55.78%)

________________________________
From: xywrite-bounce@xxxxxxxxxxxxx <xywrite-bounce@xxxxxxxxxxxxx> on behalf of Harry
Binswanger <dmarc-noreply@xxxxxxxxxxxxx>
Sent: Monday, April 6, 2026 5:01 PM
To: xywrite@xxxxxxxxxxxxx <xywrite@xxxxxxxxxxxxx>
Subject: Re: XYWRITE 4.018 Source Code | request for resources

When the time comes, I have my prioritized wish list for improvements. I can anti-climax it by
naming the top ones:

1. No memory limitations (beyond what any editor has)
2. Unlimited undo and redo
3. Not having to shell to DOS to get non-XyWrite things done.

Wouldn't XyWin have all those features, and more?

Regards,
Harry

At 03:05 AM 4/5/2026, you wrote:
Reply to note from "Martin J. Osborne" <dmarc-noreply@xxxxxxxxxxxxx> Sat, 4 Apr 2026
20:48:11 -0400

Martin,

> Are we now at a point at which someone could fix bugs and add
> features, or does that require transforming the source code into a
> form that can be understood (by a human or LLM)?

The source is in assembly language, which is readable by humans and (presumably) AIs. Building on it
would make a fantastic open-source project, assuming it meets no legal roadblocks. The prospect is
tantalizing, but it's early days. And xyghost evidently still has some tricks up his sleeve.

--
Carl Distefano
cld@xxxxxxxxxx