GPT hands off to NAPT.

[ONiX]

German Portal Team (Marcus R.) handed over the torch to North American Portal Team (Ozz N.).

What did POP6 offer?
A great alternative to FrontDoor 2.2, and Intermail 1.5

Portal of Power Key Functionality

* Startup & Framework (PORTAL.PAS)

Initializes the TSR environment (InitPortal) and enforces 80286 capability before booting the main session.
Loads every major subsystem (display, modem/comms, mail configuration, file utilities, emulation helpers, editors, network/area managers, task handling, etc.) through a single umbrella USES list so the monolithic firewall of services is ready before PortalMain runs.
Sets up overlay linking, optional self-check/debug modes, and manages shared resources such as the TSR installation lock to prevent duplicate instances.

* User Configuration & Area Management (MAILCFG.PAS)

Central dialog routines for mail configuration, such as netmail/echomail directories, tick area definitions, node setup, and file-forwarding rules.
Provides helpers for multi-selecting areas/files for nodes, validating binary fields (modes/flags), and supporting schedulers (SchedulerSetup) as well as OK-file management.
Offers fine-grained UI elements (menus, entry screens) to load/edit portal-specific resource definitions (GetEsrAndWin, BrowseRecords, etc.).

* Outbound Queue & File Handling (OUTMAN.PAS)

Implements the interactive “Outbound Manager” where queued bundles/mail/files/requests appear as OutboundEntry objects sorted by destination.
Supports manual file sending, request generation, polls, re-addressing, status changes, viewing archives, and bundle merging, with direct file-system synchronization (e.g., rewriting *.REQ, *.LO, *.UT lists).
Global maintenance commands clean outbound directories, remove undialables, and deal with bad WaZOO/packet cases; built-in logic also deletes completed entries and cleans orphan packets (section “ScanOutbound”).
The UI allows marking groups of entries, batch deletions, and status updates, mirroring FTSC-style file handling within the queue.

* FTS-0001 / FTSC Fallback Support (FALLBACK.PAS)

Implements FTSC/FTS-0001 fallback sender and receiver routines (FTSC_Sender, FTSC_Receiver) that wrap the WaZOO exchange in simpler SEA/MDM/ACK/NAK interactions when preferred protocols fail.
RecvMDM7, TrySEALink, and SEA_* procedures handle the low-level handshakes, CRC-protected request transfers, and decides whether inbound/outbound file requests happen via SEA, SEAlink, or basic transfers.
Password handling and session logging follow FTSC expectations (FTSC-001 references), including password validation, inbound file attach receipt, file request negotiations, and outbound responses (e.g., SendWaZoo(2) plus TrySEALink detection of SYN, TSync, ACK, etc.).
The fallback also supports FTSC-style request files (HoldFileName(...)+REQ) and cleans up when no mail is waiting, logging the FTS-0001 session life cycle.

* Underlying Services & Helpers

Low-level utilities for buffered text files, UI entry screens, menus, and prompts are centralized in OproUtil.PAS, supporting consistent behavior for menus/windows across POP.
MailUtil, FileUtil, OutUtil, Display, and others (per PORTAL.PAS USES clause) provide shared functionality such as address manipulation, ARC handling, validators, log output, scheduler timers, and transfer-window management.
Additional units (AreaMan, NodeList, OutInfo, FallBack, FileFwd, etc.) integrate tightly with the UI to let the operator browse/edit nodes, files-to-forward, inbound/outbound summaries, and transfer statistics.

* FTSC References:

FTSC-001 is concretely implemented as the “FTSC fallback” in FallBack.PAS, including the sender/receiver protocols, request parsing (GenREQName, SEA_*), and the explicit logging of FTS-0001 sessions (AddLog('*','Receiving mail using FTS-0001 fallback '), etc.).
The fallback adheres to FTSC expectations by accommodating passworded packets, SEA-based request/reply exchanges, and the standard ASCII/CRC framing that predates WaZOO (FTSC-0001 terminology is used in comments and log strings).
In summary, POP is a heavily modular Fidonet mailer that combines configuration editors, outbound queue management, protocol fallbacks, and a UI shell rooted in the PortalMain session to manage mail flows, node lists, and FTSC-compliant transfers—even when modern routines (WaZOO/SEAlink) can’t be used.

[ONiX]

After sitting on the code for almost 2 years...

I decided, why not build a modern TCP based POP7. Leverage DXSock6 and DXSock_ServerCore ~ so I knew I would have one of the fastest builds available.

What did I learn over those 24 months of reading over the code (line by line)?

Roadmap for a new developer

Entry point:

PORTAL.PAS boots the application: it performs runtime checks (Is286Able, TSR guard) and then calls InitPortal (INIT.PAS), PortalMain (SESSION.PAS), and FinishPortal. Globals.PAS, MailCfg.PAS, and Config.PAS define/track runtime state, node configuration, and user preferences.

Core loops and mail handling:

SESSION.PAS (not read yet but central) orchestrates the mailer session, calling:
Net/Echo mail scanning (MAILSCAN.PAS, MAILPACK.PAS), macros (MACRO.PAS), forwarding (FILEFWD.PAS), and outbound queue (OUTMAN.PAS/OUTMAN2.PAS).
Area management (AREAMAN.PAS/AREAMISC.PAS), scheduler (EVENT.PAS), and node list compilation (NLCOMP.PAS).

Hardware/communications layer:

Serial/modem access is in MODEM.PAS and COM.PAS (Fossil/serial driver wrappers).
Terminal interactions (DUMBTERM.PAS, DISPLAY.PAS, KEYBOARD.PAS) surface to the operator.

Supporting utilities:

FILEUTIL.PAS, MEMSTAT.PAS, MOREHEAP.PAS, UTIL.PAS, and Z* units handle archives, memory, and helper routines.
OUTINFO.PAS, NODELIST.PAS, MAILUTIL.PAS encapsulate node metadata, routing, and status reporting.
MAP of features: OUTMAN for queue management, NLMAN + NODELIST for node traversal, PFIX/BIMAIL for scanning, FUNC* for request/function server.

Build infrastructure:

Overlay usage (OvrlayIn, overlay directives) keeps the DOS-era code manageable; modules are mostly unit-based with heavy conditional compilation.

Performance improvement opportunities

Reduce global overlays: Portability to Free Pascal/Linux allows removing overlay directives ({$O Op*}) that exist for 16-bit memory conservation; freeing overlay-related code will simplify linking and improve virtual memory behavior.

Modernize I/O loops:

EVENT.PAS and MAILSCAN.PAS show tight loops with IdleClock/WaitForAction; convert to event-driven or use ThreadSwitch/DoSleepEx sparingly to avoid busy polling.
Look at OUTMAN/OUTMAN2: if they make repeated ReadLn/WriteLn calls on sockets or files, buffering can be tightened—use larger block reads/writes instead of character-wise loops.

Refactor buffer handling:

Many units (e.g., MAILUTIL, FILEUTIL) use FillChar, Move, and manual packing; replacing with Move-based streaming or Pascal record streaming (with stream helpers) reduces memcopies.
Inline UniqueName/Archive operations could use FileStream wrappers under Free Pascal to avoid manual file descriptors.

Limit global state updates:

Frequent updates to StatRec, Data, Cfg (see EVENT.PAS) and disk writes (daily logs, PORTAL.DRI) can be batched or deferred with Flush only on significant changes.

Use multi-threading wisely:

dxsock_genericserver already uses BeginThread; ensure the main mail loop releases CPU (ThreadSwitch) when idle; consider handing off some CPU-intensive scanning (MAILSCAN) to worker threads if you can isolate state.

Memory footprint:

MOREHEAP.PAS, MEMSTAT.PAS, and overlays were there to stretch 16-bit DOS limits. On Linux, free up unused heap machinery and rely on Free Pascal’s allocator to avoid fragmentation.

Replacing communications with DXSock6/DXSock_GenericServer

Current communications stack:

COM.PAS plus MODEM.PAS drive serial/Fossil ports. Higher levels (Session, OutMan, MailUtil) expect ComPort objects for dialup.
The existing architecture is tightly coupled to modem operations (dial strings, MNP/Z modem transfers via Z* units).

Replacement effort outline:

Abstract transport interfaces: Introduce a Pascal record or object (e.g., TCommTransport) that exposes Connect/Disconnect/Send/Receive methods. The current modem calls (e.g., dialing nodes) will be redirected to this transport interface.
Wrap DXSock6 client usage: For outgoing sessions, instantiate TBPDXSock, configure via TBPDXNewConnect, and replace ComPort calls with SendBuf/ReadLn wrappers. Pay attention to PeerPort/PeerIPAddress tracking that Session code needs for node stats (see MailUtil.pas).
Introduce server/listener path: If the mailer is expected to listen (incoming nodes), replace Com/Modem listener loops with TBPDXGenericServer. Set OnProcessSession to dispatch to existing mail-session handler (probably via PortalMain’s session logic).
Handle protocols: Existing modules rely on ZSend/ZReceive for control—these expect a modem-style ReceiveBuf. Wrap TBPDXSock.Read/ReadLn so that the Z-modem routines continue to work; you may need to port them to use DXSock-friendly abstractions (buffer sizes, CRLF delimiting).
Session metadata: Ensure PeerIPAddress, PeerPort, CharactersPerSecond metrics map to what the mailer expects for logging (see MailUtil).
Linux-specific tuning: DXSock6 is cross-platform, but you must ensure Linux socket initialization (calls to InitSocket etc.) happens before use—Free Pascal needs initialization code similar to the original WSAStartup (but for Linux only ensures ABI compatibility).

Estimated work:

Proof-of-concept (40–60 hours): Build a new transport abstraction and replace a single communication path (e.g., outbound session) with DXSock, verifying mail packets still stream correctly.
Full integration (100+ hours): Update inbound/outbound, Z-modem abstractions, logging, node statistics, and test on Linux network environment. Expect to refactor Session, OutMan, and MailUtil to stop assuming serial/TCP semantics simultaneously.
Testing/regression (20–40 hours): Validate with actual Fidonet nodes, ensure the event scheduler, TASK queue, and scanners work over sockets instead of modems.
Risk areas:

Telephony-specific logic (dial strings, carrier detection, MNP) has no direct equivalent in DXSock; if you still need dialup, keep a shim layer that simulates serial behavior while forwarding data to sockets.
Overlay-heavy modules may refer to ComPort^.Read/Write; you’ll need to provide compatible wrapper functions that call TBPDXSock.
In summary: PORTAL.PAS coordinates over fifty units; focus first on the session/communication units (Session.PAS, Modem.PAS, Com.PAS, MailUtil.PAS). Replace their low-level I/O with DXSock6 wrappers while preserving node/mail logic. Performance will improve by removing legacy overlays, simplifying event loops, and taking advantage of DXSock’s buffering.

[ONiX]

1st - Reduce global overlays: Portability to Free Pascal/Linux allows removing overlay directives ({$O Op*}) that exist for 16-bit memory conservation; freeing overlay-related code will simplify linking and improve virtual memory behavior.

2nd - Modernize I/O loops:

EVENT.PAS and MAILSCAN.PAS show tight loops with IdleClock/WaitForAction; convert to event-driven or use ThreadSwitch/DoSleepEx sparingly to avoid busy polling. Look at OUTMAN/OUTMAN2: if they make repeated ReadLn/WriteLn calls on sockets or files, buffering can be tightened—use larger block reads/writes instead of character-wise loops.

3rd - Refactor buffer handling:

Many units (e.g., MAILUTIL, FILEUTIL) use FillChar, Move, and manual packing; replacing with Move-based streaming or Pascal record streaming (with stream helpers) reduces memcopies. Inline UniqueName/Archive operations could use FileStream wrappers under Free Pascal to avoid manual file descriptors.

4th - At this point, the most impactful helper refactor would be for ReadLine (to use buffered streaming) and UniqueName (to rely on TFileStream/TPath helpers).

Testing during the Thanksgiving holiday.

[ONiX]

Internal Documentation of the units involved from 6 to 7.

Use32 – enables the 32-bit runtime support that the rest of the program assumes.
Dos – provides direct DOS system calls and low-level OS interaction.
OpCrt – supplies console I/O helpers such as WriteLn and key handling.
OpDos – wraps DOS services like file manipulation and date/time.
OpDate – makes date calculations and formatting easy.
OpWindow – powers the text-windowing framework used by the UI.
OpEntry – handles registration of entry points and overlay entry logic.
OpMenu – builds and manages the menu system.
OpLArray – supports dynamic arrays/long strings used across modules.
Init – performs the portal-wide initialization (InitPortal).
YooHoo2U – kicks off POP mail sessions (StartMailSession, ReceiveMailSession).
Config – loads, saves, and edits the global configuration data.
MailCfg – exposes the mail configuration dialog and related helpers.
Display – drives windows for status, outbound, and node summaries.
Modem – abstracts modem control, protocol timeouts, and baud handling.
Com – offers communications port implementations for the hardware layers.
Globals – defines shared globals such as Cfg, Data, and StatRec.
RBrowser – browses and edits record files (used for custom record access).
NodeList – reads/displays the node list and routing metadata.
OutMan – manages outbound batches and scheduling.
NlMan – provides the node list manager UI.
Util – general-purpose helpers (FreeUpMemory, FinishPortal, error handling).
ZMisc – low-level helpers for Zmodem operations.
ZSend – implements Zmodem sending logic.
ZReceive – implements Zmodem receiving logic.
TextEdit – offers a simple text editor for message editing.
ArcView – lets the user inspect archives without extracting them.
AreaMan – manages mail areas and their properties.
Event – calculates and switches events/aliases (ChangeEvent).
Unixdate – converts to/from Unix timestamps needed by some logs.
DumbTerm – drives the dumb terminal mode for direct terminal sessions.
FileFwd – implements file forwarding capabilities.
NlComp – compiles optimized node lists for fast lookups.
MailUtil – mailbox/address utilities for FidoNet-style packets.
FileUtil – file-system helpers (copy, delete, make dirs, CRC).
Session – contains the main PortalMain loop.
MemStat – reports memory usage and frees caches.
ScrBlank – blanks/unblanks the screen and handles the clock.
OutInfo – reads outbound path info and expands entries.
FallBack – handles the fallback protocol (FTSC sender/receiver).
PFix – scans and fixes network mail packets.
FuncReq – parses and executes function requests.
DosShell – lets the user escape to the DOS prompt.
MTask – multi-task helper for critical sections and task tracking.
Send2Utl – manages the send-to list/table.
UserEdit – provides the user editor for account tweaking.
List – exposes the list handler used by various lists.
PoPTypes – shared type definitions used across the whole program.
NewExp – config export routines.
NewImp – config import routines.
FuncSrvr – function-server lifecycle (InitFunctionServer, etc.).
LCR – least-cost routing calculations for calls.
RngAnaly – range analyzer for answer-call/no-connect logic.
RCBrowsr – browsing helper for range/cluster data.