I was honestly staggered by the depth of knowledge of Claude showed about Xywrite and its listserv. Claude model is Sonnet 4.6. I raised this issue to the group a few months ago and Carl answered he had noticed the problem but had no immediate solution. Since Claude wasn't able to fix it either, this this is just offered FYI. Harry Favor XyWrite / vDOS-plus Win-F11 Window Sizing Dialog ================================================ Claude (Anthropic) and Harry June 27, 2026 Harry: not sure if your model's dataset covers keyboard assignments for 16-bit DOS xywrite 4.0, but if it does is there any way to access the windows key from the xy kbd under the vdos emulator? CLAUDE: That's a genuinely niche intersection - XyWrite 4.0 DOS, the vDOS emulator, and Windows key access - but I can engage with it at a reasonable level. A few clarifying questions first: 1. What are you trying to do with the Windows key? Pass it through to a Windows function from inside vDOS, or assign it as a trigger for something within XyWrite's keyboard file? 2. Which vDOS variant are you running - plain vDOS, vDOS-plus, or vDOS-LFN? The plus variant has more keyboard passthrough flexibility. 3. Are you working with XyWrite's KBD file directly - the binary keyboard assignment file - or through the ASSIGN command at the XyWrite prompt? The reason I ask: the Windows key didn't exist when XyWrite 4.0 was written (it appeared with the Windows 95 keyboard spec in 1994, and XY4 DOS predates that), so it has no native scancode mapping in XyWrite's keyboard table. Whether you can access it depends almost entirely on whether vDOS intercepts and translates it before XyWrite sees it, or passes a scancode XyWrite can be taught to recognize. My strong suspicion is that vDOS-plus is your best path if any path exists - but your answers above will sharpen that considerably. Do you have the vDOS configuration file accessible? Harry: using vdos plus xywrite emulator. usually directly edit the .kbd file when editing key assignments. CLAUDE: Good - vDOS-plus is the right variant for this, and direct .kbd editing is the correct approach for XyWrite power users. That narrows the question usefully. The core problem is architectural: The scancode gap: XyWrite's keyboard handler was written around the 83/84-key AT and XT scancode sets. The Windows key generates extended scancodes (E0 5B / E0 5C for left/right Windows key) that simply didn't exist in that world. XyWrite 4.0's keyboard interrupt handler almost certainly ignores or drops them - they fall outside the scancode range it was designed to process. The vDOS-plus layer: This is where any solution would live. vDOS-plus has a vdos.cfg configuration file with keyboard handling options. The key question is whether it has a key remapping or scancode translation directive that could intercept the Windows key's E0 5B extended scancode and re-emit it as something XyWrite does recognize - a function key, an Alt combo, a Ctrl combo - before XyWrite's handler sees it. What I'd suggest checking: 1. Your vdos.cfg - look for any key= or keyboard= directives 2. The vDOS-plus documentation or readme for scancode remapping options 3. Whether AutoHotkey running alongside vDOS-plus could intercept the Windows key at the Windows level and translate it to a keystroke XyWrite handles natively What are you actually trying to trigger - is there a specific XyWrite function you want on the Windows key? Harry: under vdos a keyboard combination (Win-F11) originally allowed shrinking font/window size (win-F12 maximized). a recent windows update destroyed that functionality. In the vdos window it is still possible to use the win-F11 with mouse clicks on the top left corner of the window, but is a kludge to do. looking for a way to automate that. CLAUDE: That's a much clearer problem - and it's essentially a Windows-level automation task, not an XyWrite .kbd problem at all. The Windows update broke the vDOS-plus window sizing hotkey, and you want to restore equivalent one-keystroke functionality. AutoHotkey is almost certainly your cleanest solution. Since the Windows key is invisible to XyWrite/vDOS, you can intercept Win-F11 at the Windows layer before vDOS sees it, and script the mouse clicks on the top-left corner that currently work manually. A few questions to design the right script: 1. Do you have AutoHotkey installed - and if so, v1 or v2? (They have different syntax) 2. Is the top-left corner click sequence consistent - same pixel coordinates every time, or does the vDOS window move around? If the window position varies, the script needs to find the window first and calculate relative coordinates rather than use fixed screen positions. 3. Is it specifically Win-F11 you want to reassign, or would any available hotkey do - Ctrl-F11, for instance - since Win-key combos can be tricky for AHK to intercept reliably depending on Windows version. 4. What does the click sequence look like exactly - single click, double click, right-click menu selection on the corner? The AHK approach would run invisibly in the background, require no changes to vDOS or XyWrite configuration, and survive future Windows updates. But the window-relative coordinate question is the critical design detail. Harry: left click top right corner, drop down menu appears with about 10 options. Scroll down to win-f11 option and click. works fine. am not using auto hotkey and am reluctant to. the problem as i see it is not emulating the win-F11 combination, since Windows/Vdos already does not accept those scan codes for any function. the drop down menu functionality is not using scan codes either, but some other method buried under the hood. my sense is that hoping for some keyboard alternative may not be workable. CLAUDE: Your analysis is sharp and almost certainly correct. Let me restate it to confirm we're aligned: What's actually happening: The drop-down menu from the top-left corner click is the Windows system menu (the legacy WS_SYSMENU control), not a vDOS or XyWrite construct at all. The resize/restore functions it offers are Windows window-management calls operating entirely outside the DOS emulation layer. The original Win-F11/F12 shortcuts were probably vDOS-plus's own hotkey hooks into that same Windows layer - and the update broke those hooks without touching the system menu itself. Why a .kbd solution won't work: Exactly as you reasoned - the system menu pathway never touches scancodes. XyWrite can't see it, intercept it, or trigger it. They're in completely separate layers. What might actually work without AutoHotkey: 1. Check vDOS-plus documentation or its config file for any hotkey reassignment options that survived the Windows update - the functionality may be rebindable within vDOS-plus itself to a key combination Windows hasn't claimed 2. Windows keyboard shortcuts for the system menu: Alt-Spacebar opens the system menu natively in any Windows application including vDOS. From there arrow keys navigate. Clunky but no mouse required - and it's pure Windows, update-proof. Have you tried Alt-Spacebar inside the vDOS window? That may be your most frictionless path without third-party tools. Harry: alt spacebar does not work in the vdos window. I also have a memory that powertools uses that combo. CLAUDE: Both observations are well-taken: Alt-Spacebar: vDOS-plus almost certainly intercepts it before Windows sees it - that key combo has a long DOS-era history (it was used in various DOS shells and applications) so vDOS probably swallows it deliberately to avoid conflicts inside the emulation layer. That explains why it doesn't surface the Windows system menu. PowerToys: Your memory is correct - PowerToys uses Win-key combinations extensively, and there's a real possibility that a recent PowerToys update (or Windows update affecting PowerToys) is now capturing Win-F11 before vDOS-plus can act on it, which could be exactly what broke the original functionality. That's a plausible culprit worth investigating. Practical next step: Check PowerToys Keyboard Manager and the FancyZones or other modules for any Win-F11 assignment that appeared or changed recently. If PowerToys is intercepting it, you may be able to disable that specific binding and restore vDOS-plus's original behavior. But if that doesn't pan out - and given that Alt-Spacebar is also blocked - your instinct that a keyboard alternative may not be workable is probably right. The vDOS window management layer and the Windows system menu are both effectively sealed off from keyboard access inside the emulation environment. Is PowerToys running on the NUC, and do you know which version? Harry: just updated to the latest version, but the key combo issue started many months ago. CLAUDE: That's an important timeline detail - it rules out the recent PowerToys update as the trigger, and pushes suspicion back toward a Windows update from several months ago that changed how Win-key combinations are handled system-wide. This actually fits a known pattern: Microsoft has periodically tightened its grip on Win-key combinations, reserving more of them for system functions and making them harder for third-party applications to intercept. vDOS-plus's hook into Win-F11/F12 was always operating in a gray zone - it was catching those combos at a level Windows has progressively made less accessible to non-Microsoft software. Honest assessment at this point: The combination of factors - Alt-Spacebar swallowed by vDOS, Win-key combos now locked out by Windows, system menu inaccessible by keyboard from inside the emulation layer - suggests you've hit a genuine dead end on the pure keyboard path without a tool like AutoHotkey. The one remaining lead worth checking: The vDOS-plus configuration file may have a parameter for the window resize hotkey that could be reassigned to a combination Windows hasn't claimed - something like Ctrl-F11 or Shift-F11. The vDOS-plus developer (Rugxulo, or the current maintainer) may have addressed this exact Windows update breakage in documentation or forums. Do you know where you obtained your vDOS-plus build - is it the standard release or a customized XyWrite-specific package? Harry: customized xy specific package. CLAUDE: That's a key detail - the XyWrite-specific vDOS-plus package is almost certainly the Wengier Wu build, which has been the standard vehicle for XyWrite-under-vDOS for years and has its own configuration layer on top of standard vDOS-plus. This matters because: Wengier's build has its own documentation and config options that differ from stock vDOS-plus - the Win-F11/F12 window sizing was likely his addition specifically, not a vDOS-plus stock feature. Which means the fix, if one exists, is also likely in his hands. Most productive next step: The XyWrite user community - specifically the XyWrite mailing list or the XyWrite III/4 user group - is small but technically deep, and this exact breakage may have been reported and addressed already. Wengier himself has historically been responsive to that community. Do you have access to: 1. The XyWrite mailing list (still active as of my knowledge cutoff) 2. The configuration/readme files that came with your specific vDOS-plus XyWrite package - there may be a documented alternative hotkey or a config parameter for the window sizing function that Wengier added as a fallback If you can find the readme or config documentation I'm happy to help parse it for relevant parameters. That's a more targeted path than anything we can reverse-engineer from outside the package. Harry: yes, the wengier wu build. did run the problem by the xy listserv which has many top problem solvers. They noticed the problem as well, but had no fix to offer. CLAUDE: That's a significant data point - if the XyWrite listserv's best problem solvers couldn't crack it, that's a strong signal the issue is genuinely intractable through conventional means. Those are not casual users. Honest summary of where that leaves you: The Windows update effectively closed the channel Wengier's build used to hook Win-F11/F12, and neither the vDOS-plus layer nor XyWrite's keyboard handler can reach the window management functions through any currently accessible pathway. The listserv confirmation means this isn't a configuration gap - it's a Windows policy change that revoked access. Which leaves essentially two realistic options: 1. Live with the mouse/menu kludge - genuinely the path of least resistance given the constraints 2. Reconsider AutoHotkey - I know you're reluctant, and that's reasonable, but it's worth understanding why: AHK could watch for a keystroke that is accessible from inside vDOS (a Ctrl or Alt combo that vDOS passes through), then execute the precise mouse click sequence on the system menu automatically. It would be invisible once running and could be set to launch with Windows. The script itself would be perhaps 10 lines. The reluctance to add another dependency is legitimate. But if the mouse kludge becomes genuinely burdensome, AHK is the only remaining tool with the right access level to solve this. Is the reluctance to AutoHotkey primarily about complexity, trust, or something else? Harry: every installed prog adds more overhead, just trying to keep things as simple as possible. CLAUDE: That's a completely sound principle, especially on a system you've tuned carefully. Every background process is a potential conflict, update headache, or resource drain - and AutoHotkey, while lightweight, is not zero-cost on those dimensions. Honest conclusion then: You've exhausted the legitimate options. The mouse/menu path is the de facto solution until either: - Wengier releases an updated build that works around the Windows policy change - which may or may not happen depending on his bandwidth and interest - A future Windows update restores or relaxes the Win-key interception behavior - unlikely but not impossible - You find the kludge genuinely unworkable at which point AHK's overhead cost may become worth paying The listserv dead end is actually clarifying - it means you're not missing something obvious. The problem is real, the fix doesn't currently exist at an acceptable complexity cost, and the mouse workaround is the pragmatic answer for now. Worth checking Wengier's build release notes periodically to see if he addresses it. Does he distribute updates through the XyWrite list, or through a separate channel? --- END OF DIALOG ---