Since last year, I have been working with Jim Carpenter, a freelance programmer by trade, on hunting down old Prodigy data so that we may preserve it, display it again, and perhaps even one day use it to recreate Prodigy itself.
We're calling it the Prodigy Restoration Project.
By now you may have seen my latest piece for The Atlantic entitled Where Online Services Go When They Die: Rebuilding Prodigy, One Page at a Time. That article describes the genesis of the project while also diving into the technical back story of the Prodigy service.
The reason we have any hope of doing something like this is because Carpenter discovered that Prodigy screen data can still be found in the STAGE.DAT and CACHE.DAT files located in used Prodigy client directories.
Those two files were used as cache files to speed up load times when using the service. When connecting to Prodigy, the client would download page data into the files. Whenever the client last connected to Prodigy, that data got frozen in time. If a vintage Prodigy client install still exists, we can get at the "frozen" data today.
Here are some screens that Carpenter pulled from a STAGE.DAT I had in my personal archives (these are from a STAGE.DAT file dated October 6, 1996):
We can extract these screens using a series of Python programs written by Carpenter. They read through a previously used STAGE.DAT file, generate a list of pointers to the pages or object data contained within, then direct the Prodigy Reception System client to display them one at a time so we can take screenshots.
Jim's code is not ready for release yet, but he hopes to polish it up enough to put up on GitHub soon. It has a long way to go before becoming a turnkey solution to extracting and displaying the data found in STAGE.DAT files. We're working on it.
With that in mind, I've written the rest of this post in the form of a Frequently Asked Questions.
[ Continue reading Bringing Prodigy Back From The Dead » ]