The Problem

Classic ASP applications written in VBScript are facing an existential threat — not because ASP itself is broken, but because Microsoft is removing VBScript from Windows entirely.

Classic ASP relies on VBScript as its scripting engine. No VBScript means no Classic ASP. For organisations and developers running ASP applications that still work perfectly fine and serve real users, this is a serious problem.

ASPPY is the answer.

Microsoft's VBScript Deprecation Timeline

VBScript (Visual Basic Scripting Edition) is a lightweight scripting language first introduced by Microsoft in 1996. It has been available as a system component in Windows and widely used for automating tasks and controlling applications, as well as embedded within HTML pages — commonly in conjunction with Active Server Pages (ASP).

Microsoft announced a phased deprecation plan in May 2024. The three phases are as follows:

• Phase 1: VBScript is pre-installed as a Feature on Demand (FOD) by default in Windows 11 24H2 and later, ensuring existing dependencies still work while organisations migrate away.
• Phase 2 (from 2027): The VBScript FOD will no longer be activated by default. Users who need it must manually enable it via Settings > System > Optional Features.
• Phase 3: VBScript will be fully retired and removed from future Windows releases, including all associated .dll files.

When Phase 3 arrives, all VBScript dynamic link libraries will be removed from Windows, and projects that rely on VBScript will stop functioning entirely.

Why Microsoft Is Removing VBScript

This move is part of a broader strategy to remove Windows and Office features that threat actors use as attack vectors to deliver malware. Attackers have used VBScript in campaigns distributing strains like Lokibot, Emotet, Qbot, and DarkGate.

Microsoft states that technology has advanced over the years, giving rise to more powerful and versatile scripting languages such as JavaScript and PowerShell — languages that offer broader capabilities and are better suited for modern web development and automation tasks.

In short: VBScript is old, unmaintained, and a security liability. Its last stable release (5.8) dates back to 2010 — over fifteen years ago.

The Impact on Classic ASP

Classic ASP applications written in VBScript will stop working once Phase 3 is reached. This affects:

• Websites and web applications built on Classic ASP
• Any server still running Windows where VBScript is removed or disabled
• Hosting environments that upgrade their OS without re-enabling VBScript as an optional feature

For many businesses, rewriting these applications from scratch in a modern language is not a realistic short-term option. The applications work, they serve users, and a full rewrite is expensive and risky.

What ASPPY Is

ASPPY is a self-contained Classic ASP execution engine that runs independently of the Windows VBScript component. It bundles its own VBScript interpreter, meaning it does not depend on Windows to provide vbscript.dll.

Crucially, ASPPY is built entirely in Python. Python runs on Windows, Linux, and macOS — which means ASPPY does too. This is a fundamental architectural decision that makes ASPPY truly platform-independent. A Classic ASP application can now be hosted on a Linux VPS, a macOS development machine, or a Windows Server, without any changes to the ASP code itself. Linux typically runs Python 10–30% faster than Windows, increasing the performance advantage of ASPPY over Classic ASP/VBScript on IIS.

This means:

• Classic ASP applications continue to run unchanged, even after Microsoft removes VBScript from Windows
• No rewrite of existing ASP code is required
• ASPPY runs on Windows, Linux and macOS — anywhere Python runs
• ASPPY runs as a standalone HTTP server (on port 8080 by default), sitting behind a reverse proxy such as IIS, nginx, or Apache
• The proxy handles everything else — static files, PHP, ASPX — and transparently forwards .asp requests to ASPPY

Platform Independence — Windows, Linux, Android and macOS

Because ASPPY is built on Python, it is not tied to any operating system. This opens up hosting scenarios that were never previously possible for Classic ASP:

A Classic ASP application that today runs on a Windows Server with IIS can tomorrow be migrated to a Linux cloud instance at a fraction of the hosting cost — with zero changes to the ASP code. Developers on macOS can run and test Classic ASP applications locally without needing a Windows machine or a VM.

Android support is a particularly striking example of just how platform-independent ASPPY is. Python runs on Android via environments like Termux or UserLAnd, and several web server applications are available for Android:

• KSWEB — a full-featured web server app for Android supporting nginx, Apache, and PHP
• Servers Ultimate — a flexible server suite for Android supporting Apache, nginx and many other protocols
• Termux + nginx/Apache — Termux provides a full Linux-like environment on Android where nginx or Apache can be installed and run alongside ASPPY via Python
• UserLAnd — runs a full Linux distribution on Android without root, enabling standard nginx or Apache setups

This means a Classic ASP application can technically be developed, tested, or even served from an Android device — something that was never conceivable with native Classic ASP on Windows.

This platform independence is a second major reason ASPPY was created, entirely separate from the VBScript deprecation issue. It fundamentally changes where Classic ASP can run.

How ASPPY Fits Into the IIS Setup

The web.config described in the companion wiki page routes .asp requests to ASPPY via IIS Application Request Routing (ARR). From the browser's perspective, nothing changes — the same URLs, the same responses, the same behaviour. ASPPY is completely invisible.

Browser → IIS (port 80/443)
              │
              ├─ *.php   → PHP via FastCGI
              ├─ *.aspx  → ASP.NET
              ├─ static  → IIS StaticFile module
              └─ *.asp   → ASPPY (port 8080)

On Linux or macOS, nginx or Apache fills the same role as IIS — proxying .asp requests to ASPPY on port 8080 while handling everything else natively.

When Microsoft eventually removes VBScript from Windows in Phase 3, IIS-hosted Classic ASP applications protected by this setup will continue running without interruption.

ASPPY Picks Up Where Classic ASP Left Off

ASPPY is not just a compatibility layer — it also extends Classic ASP with features that developers always wished were there but Microsoft never added.

Extended Request and Response Objects

Classic ASP's Request and Response objects were functional but limited, especially around file handling. ASPPY adds two long-missing capabilities:

• Request.Files — a straightforward way to access uploaded files from a multipart form submission. Classic ASP required third-party components or complex workarounds to handle file uploads. In ASPPY this is built in.
• Response.File — a single method to flush any file directly to the browser, handling headers, content type, and binary streaming automatically. Sending a file for download in Classic ASP required cumbersome binary stream workarounds. In ASPPY it is one line.

New Built-in Modules

ASPPY ships with a set of native modules that address the gaps Classic ASP developers have always worked around with third-party ActiveX components or external tools:

• ASPPY.zip — create and extract ZIP archives directly from ASP code, with no external dependencies
• ASPPY.pdf — generate PDF documents server-side, a capability Classic ASP never had natively
• ASPPY.image — manipulate images server-side: resize, crop, convert formats and more
• ASPPY.JSON — parse and produce JSON natively, essential for modern web applications and APIs
• ASPPY.pop3 — connect and read a pop3-enabled mailbox
• ASPPY.imap — connect and read an imap-enabled mailbox

These modules make ASPPY a genuinely capable modern web platform, not simply a preservation effort. Existing Classic ASP code runs unchanged, and new code can take advantage of these modules immediately — no third-party components, no COM registration, no legacy ActiveX dependencies.

Summary

ASPPY is not a workaround — it is a forward-compatible replacement engine that lets Classic ASP applications outlive the platform they were built on.