-
Notifications
You must be signed in to change notification settings - Fork 0
QWK.NET ‐ FAQ
This FAQ answers common questions about QWK.NET. For detailed explanations, see the linked canonical documentation.
Lenient mode (default) is recommended for most scenarios. It handles real-world format variations gracefully whilst logging warnings. Use Strict mode only when specification compliance is critical. Use Salvage mode for damaged or corrupted packets. See Validation Modes for detailed behaviour and examples.
Real-world QWK packets often contain format variations (date formats, missing fields, etc.) that differ from the specification but are still valid. Warnings in Lenient mode indicate these variations but don't prevent parsing. See QWK Format Observations for common variations and Validation Modes for when warnings are normal vs problematic.
Errors indicate structural problems that prevent correct parsing (e.g., corrupted headers, missing required files). Warnings indicate format variations or missing optional data that don't prevent parsing. See Validation Modes for the distinction and Troubleshooting for diagnosing specific issues.
QWK.NET uses CP437 (Code Page 437, DOS Latin US), the historical encoding used by DOS-based BBS systems. All text in QWK packets is decoded from and encoded to CP437. See Encoding and CP437 for complete details.
This usually indicates a console/terminal encoding issue, not a library problem. QWK.NET correctly decodes CP437, but your terminal must be configured for UTF-8 to display the Unicode equivalents. See Troubleshooting for platform-specific console configuration guidance.
Byte 0xE3 is the QWK line terminator (π in CP437). QWK messages use this byte instead of CR/LF to separate lines. QWK.NET handles this automatically during parsing and encoding. See Encoding and CP437 for details on line ending handling.
QWKE (QWK Extended) adds enhanced features like extended header fields, reader configuration, and file attachments. QWK.NET supports both formats. Packets are identified by the presence of TOREADER.EXT or TODOOR.EXT files. See QWKE Observations for complete details.
Yes. Lenient mode (default) handles common format variations gracefully. Salvage mode attempts best-effort recovery from damaged packets. See Validation Modes for mode behaviour and QWK Format Observations for common real-world variations.
ZIP format is built-in (via System.IO.Compression). Additional formats (TAR, RAR, 7z, LHA, ZIP (pre-1991), etc.) can be added via the extension system. See API Overview for archive handling and Architecture for extension development.
No. QWK.NET only detects standard ANSI CSI sequences (ESC followed by '['). Backtick-escaped ANSI ([36m) and other BBS-specific conventions are presentation-layer concerns and are out of scope. See Backtick-Escaped ANSI Codes for the architectural rationale and guidance for application developers.
The diagnostics tool (QwkNet.Diagnostics) is a separate command-line application for analysing packets. The core library (QwkNet) is the parsing and generation engine. The tool uses the library but adds analysis, reporting, and validation features. See tool READMEs for usage.
No. QwkPacket is read-only. To create modified packets, use RepPacket to build new reply packets from existing message data. See API Overview for creating reply packets.
QWK.NET is optimised for speed: typical packets (<100 messages) parse in under 1ms. Throughput is 30,000-35,000 messages/second, depending on hardware. Memory usage is approximately 1 KB per message. See tool READMEs for benchmarking capabilities.
QWK.NET targets .NET 10 and is tested on macOS 26+ (Tahoe) and Windows 11. Linux support is untested but should work with .NET 10 runtime. See Compatibility for platform details.
Yes. The extension system allows third-party packages to add archive format support without modifying the core library. See Architecture for extension development guidelines and the TAR extension example.
Verify the archive format is supported (ZIP built-in, others require extensions), the file exists and is readable, and required files (CONTROL.DAT, MESSAGES.DAT) are present. Try Salvage mode for corrupted archives. See Troubleshooting for detailed diagnosis.
Pre-1991, ZIP archive files often used legacy compression methods, non-standard headers, or omitted fields required by ZIP from 1991 onwards. Most contemporary ZIP libraries (including .NET's built-in support) only guarantee compatibility with ZIP 1.0 and later archives. If you try to open a Pre-1991 ZIP packet in QWK.NET, it may fail unless you use an archive extension that adds explicit support for legacy ZIP formats. See Architecture for guidance on supporting additional archive variants.
Check the validation report for warnings about message parsing. Verify whether messages appear in Lenient/Salvage modes but not Strict (indicates format variations). See Troubleshooting for message parsing issues and Index Files (.NDX) for index-related problems.
Index files may be incorrect, missing, or corrupted in real-world packets. QWK.NET falls back to sequential scanning when indexes are invalid. See Index Files (.NDX) for index file structure, common problems, and how validation modes handle them.
- Check Troubleshooting for common problems and solutions
- Review API Overview for library usage patterns
- Consult Glossary for terminology definitions