Spitfire BBS has officially made it past the 1-1-2025 date wall.

For those who have followed my Spitfire preservation work, Spitfire v3.7 had a Y2K-style date issue that caused the system to fail on modern dates with the message: “You Need To Set The Date & Time First”

For a long time, the workaround was to run the Windows 7 Spitfire VM with the clock rolled back. That worked, but it was never a real fix. It also created problems for normal system operation, file dates, logging, shares, user records, and anything else that expects the operating system clock to be correct.

After a lot of testing, debugging, and binary patching, my registered Spitfire installation is now running in production on the real 2026 date.

This was not just a quick “make it boot” patch. Early test builds were able to get Spitfire started, but some internal date fields still wrote 2024 into user records and logs. That caused weird follow-on issues, including bulletins and newsletters continuing to show as updated after they had already been viewed.

What the current registered build fixes

• Startup on real 2026+ dates
• Correct visible system date
• Correct new-user dates
• Correct Last Time On and Original Log On fields
• Working birthdate entry
• Correct bulletin/newsletter update behavior
• Correct CALLERS.LOG dates
• No more VirtualBox date rollback required
• No more VirtualBox needed; Spitfire can run on XP through Windows 10 32-bit systems

This is now running on my production Spitfire system.

There is also now a patched shareware baseline. The shareware version boots on modern dates and handles the main Y2K25/user-date issue correctly. The newsletter behavior in the shareware build is improved, though it may still require an extra login/read cycle before the update notice fully clears. That is still a major improvement over the original behavior.

SFToss32

SFToss32 has been moving forward as a new 32-bit FTN tosser for Spitfire. The goal is to bring practical FidoNet-style echomail and netmail handling back to Spitfire systems without depending on the old DOS-era tosser stack.

Testing has shown inbound tossing, outbound tossing, and AreaFix-style functionality working. This is a big deal because it means Spitfire is not just booting again — it is getting modern support pieces around it so it can participate in FTN-style networks.

SF FTN Utility

The SF FTN Utility was built to make the Spitfire + FidoNet setup process less painful. It is a helper/wizard-style tool for the configuration and safety checks around Spitfire FTN operation.

The goal is to make this less of a “you must already know every ancient detail” project and more of a guided process that a returning Spitfire sysop could realistically follow.

Message Base Safety

A major part of the preservation work has been looking at Spitfire’s message base behavior and safety. Older BBS software can be fragile, and Spitfire is no exception.

We have spent time reviewing message-base structures, looking at risky delete/pack behavior, and building safety tooling around the parts of Spitfire that can damage or corrupt message data if something goes wrong.

This is not glamorous work, but it matters. If Spitfire is going to live on, the message base has to be treated carefully.

SFPack32

SFPack32 is the modern replacement effort for the old Spitfire message conference packer. The idea is to provide a safer, 32-bit tool for packing Spitfire message conferences without depending on the old DOS utility that has major Y2K issues.

The focus has been safety first: dry-run behavior, clear reporting, warnings, and making sure a sysop knows exactly what will happen before anything is written.

This is one of those utilities that can be boring when it works and terrifying when it does not, so the goal is boring and safe.

SF Full Screen Editors

Spitfire’s editor situation has also been getting preservation attention. SFAME and SFSME have both been reviewed, cleaned up, and packaged for modern Spitfire use.

The big focus here has been making these editors easier to preserve and deploy, documenting the menu files correctly, and making sure they still behave properly with Spitfire in 2026+.

Full-screen message editors are part of what made BBS systems feel alive. Keeping them usable helps preserve the real Spitfire experience, not just the executable.

Spitfire Uploads

Spitfire uploads have been another deep rabbit hole.

Spitfire, NetSerial, external protocols, and modern telnet/virtual-modem setups do not always play nicely together. A lot of work has gone into testing upload behavior, external protocol configuration, ADF, Zmodem, FDSZ, and the weird edge cases that show up when 1990s BBS assumptions meet 2020s networking.

This area is still one of the trickier parts of running Spitfire today, but the testing has helped document what works, what fails, and what a sysop should watch out for. As of now, uploads in Spitfire are still broken, but tickets have been opened with NetSerial.

Bot-Gate

Bot-Gate is my anti-bot front-door gate for BBS systems. While it is not Spitfire-specific, it is part of the larger ecosystem around keeping old-school BBS services online today.

The internet in 2026 is not the internet Spitfire was written for. Telnet ports get hammered by bots, scanners, and junk connections. Bot-Gate helps filter that noise before it reaches the BBS.

For old BBS software, sometimes preservation is not just fixing the software. It is also building a protective shell around it.

Spitfire BBS Preservation

The larger Spitfire preservation effort now includes:

• Restoring and preserving Mike Woltz’s Spitfire website content
• Keeping official shareware downloads available
• Repairing the 2025+ date issue
• Preserving registered-install knowledge without redistributing private registered files
• Testing Spitfire under Windows 7, Windows 10, DOSBox-X, NetSerial, and other environments
• Documenting setup details so they are not lost
• Building modern helper tools around Spitfire
• Looking for ways to preserve the source code if it still exists

This has become more than just “can I get my old BBS to boot?” It has become a real preservation project.

Why this matters

Spitfire was created by Mike Woltz of Buffalo Creek Software. For many of us, Spitfire was not just another DOS BBS package. It was the software that introduced us to sysop life, online communities, message bases, file areas, doors, ANSI screens, and the magic of calling another computer.

For me personally, Spitfire was one of the things that helped lead me into a 25 year career in technology, now retired. Keeping it alive is not just nostalgia. It is a way of preserving a piece of personal computing history.

Between the Y2K25 repair, SFToss32, SFPack32, the FTN tools, editor preservation, upload testing, message-base safety work, and the broader documentation effort, Spitfire is not just being kept as a museum piece.

It is becoming usable again on modern retro-BBS systems. Spitfire lives.

If you are a former or current Spitfire sysop, or if you still have an old registered copy tucked away somewhere, contact me at xbit.bbs[at]protonmail[dot]com