Source Control

Because I'm lazy I had a large set of development directories that I date stamped when doing the last RetroChallenge. I decided these should really be under source control so that if I change functionality and decide that code I've changed needs to be reverted back to previous version its much easier as I have a proper list of changes to files over time.

The first problem is that my source control server was destroyed when I moved my server to a new data centre. I have a backup of all the source control files but needed to rebuilt a virtual machine and install the source control software before I could start.

Once done I found all the old versions of my source and sorted them into date order, one by one I copied the files over the top of the previous version and checked them in, ensuring each time to removed unused files that had been deleted or renamed in the project. Each time also ensuring that everything still compiled correctly.
Now I have a nice an clean project with all of the changes I've made over the last RetroChallenge so that any code that has been removed is still there if required.

Once complete I then got a fresh version from source control and ensured everything is working.
At this point I found a few issues that need addressing with hard coded machine names (bad I know) which need to be setup in the configuration file instead.
Everything was working fine apart from the terminal program that I was fiddling with back along, somehow I've managed to mess up the line feed and everything is not displayed where it should be, I think this is the actual terminal program at fault in rendering the frame not the backend. I will need to test this against the other terminal program I have to check that is isn't the back end.

Database

Started on the database for my BBS backend which will hold the system frames and control the functionality within the backend.

Tried to make the frame store as compatible with the current saved frame formats that are out there, most of them contain details of the frame owner, permissions and routes to other frames.

As the ViewData system works on frame numbers even gateways etc will be allocated a frame, therefore I have abstracted out the frame details so that I can base other entities on them for future functionality. Started off by creating a page (based on frame) which can hold the code for a static page. These are date stamped so that the system can tell if the frame has been updated. Backend systems such as news feeds etc can update these pages to change content in the system. Also added a gateway (based on frame) which is a frame that takes the user to another BBS, this holds the remote connection details of the other BBS and will be contacted when you navigate to this specific frame type. This allows me to just add frame addresses that access other systems.

The system also allows for multiple systems to be run from the same database, this allows me to have multiple BBS systems running with different content in each. Ideally this may include examples of old BBSs and example Prestel pages.

Server

Originally the entire BBS ran on a PC in my office, this is mainly due to the numerous modems connected to it.

As I have a dialup gateway as a separate module I'm intending to run the dialup gateway on the PC and then have everything else installed on a new virtual server.
This will enable me to have the backend available even if the dialup lines aren't. The backend and database can then run on the new virtual machine and can then talk to the gateway wherever it is.

So ended up building another virtual machine just for this. Installed SQL, IIS (for the web based interface later on) and later once recompiled, the services that run the BBS.