Those with a healthy bit of paranoia would question what a free piece of software does behind the scenes and my product should be no different.
These days the term "free" is thrown around everywhere and while you may not be paying your hard earned money for a product or a service, chances are that you are the currency being paid for usage of the software or service. These days it is common that companies across the globe install what they term as "telemetry" in their products, but in reality it is more common that this telemetry is actually spyware designed to monitor your activities and report back to home base. This data is then collected and sold for profit.
All the major tech companies are doing it and have been doing it for, I dare say, decades.

ROWB is released as freeware, in the truest meaning of the word: free. No cost, no spyware, no telemetry, you are literally given this software as a gift with no strings attached.

While I hesitate to release the source code for my application, due to the thieving nature of people, skilled tech-people and developers will know how to get their hands on my source code. Just know that under Danish and EU law, decompiling my software is illegal and carries hefty penalties, if caught.

All this aside, the following is a detailed accounting for what goes on inside my software.

First of all, let's touch on some of the "hidden" things that ROWB does. While some of this can be paranoia inducing, I assure you these things are there for good reason.

• Requests information from the Windows Registry.
• Runs a monitor on a particular folder on your harddrive.
• File system interaction to read, write and delete files.
• Runs a monitor checking your task manager for the game.

On top of that, there's a bunch of code running the custom built UI system, displaying all the backup information.

On of the very first things that happens, when ROWB is started, is that a request is made to the Windows Registry for information regarding Steam.
Some aspects of the Windows Registry, act as a public information phone book. Everyone has access to it, so they can get / read needed information, however in this "public" mode, data in the Windows Registry can not be altered. ROWB only requests information in this "public" mode.

The data requested, includes the path to where Steam is installed. If it appears that Steam is installed, further data is requested from the Windows Registry, to figure out whether "Railroads Online" is installed or not. If it turns out that both are installed, then ROWB has what it needs to function and provide ease-of-use handling.
Among this data, as mentioned the path to where Steam is installed, which is then used to determine where the game is installed, along with the path to where the game saves it's game worlds.
As it so happens, these game world files are the ones ROWB is designed to deal with - in a good way.

If it is determined that either Steam or Railroads Online (or both) are not installed, an error dialog is displayed requesting you to install both, to be able to use ROWB.

Once the initial checks with the Windows Registry are performed and it is determined that both Steam and Railroads Online are installed, the next step is firing up the "folder monitor".
ROWB asks the Windows file system, to please tell ROWB whenever a file in the game's saves folder changes. A file change occurs, whenever you save the game, either by overwriting an existing game world or creating a new save file, by choosing a slot that was previously empty.

The game's saves folder, is the only folder being monitored through this process and only the 10 possible save slot files are ever checked. No other file activity is monitored, nor touched, ever.

Once the folder monitor is running, the next thing to start is the internal save file cache manager. When a save file changes, the folder monitor reports to the cache manager that a change has occurred.
The cache manager, then checks each of the possible 10 save slot files, to see if they exist and if so, each individual save slot file is loaded into memory to perform a Sha1 hash of the file itself.
Additionally a data entry within the save file is read, containing the date and time when this save file was generated, as done by the game itself.

The cache manager then maintains a listing of these save file Sha1 hashes and date stamps, allowing other parts of the program to react to any changes.

Somewhere in between everything else that's going on, another small background monitor process at some point finishes it's startup procedure: the game monitor.
This is similar to what Discord does, when it switches it's UI to show what games you are playing. ROWB has a similar game monitor that checks the Windows Task Manager to see whether Railroads Online is running or not.
While Discord monitors for a lot of different games and applications, ROWB is restricted to only look for Railroads Online.

When the game monitor detects that Railroads Online is now running, it generates an event internally in the application, that the UI handler then uses to enable or disable the "Play" toolbar button.
No additional tasks are searched for, no data is logged regarding your usage of the game, nothing is ever sent anywhere from ROWB.

It is anybody's guess what kind of usage data is gathered and sent by other similar Task Manager monitoring tools and I can certainly understand why some people are paranoid about it. This is personal private data and not data that belongs to a company to sell for profit. Names shall not be mentioned ...

When the cache manager is done doing it's work, it reports it's findings to the UI handler and to the Backup Manager.
The UI handler reads the found save file information and updates the "Home" view with save slot date information and file sizes, at first defaulting to not show how many backups exist for each slot, because that information has not yet been loaded from disk. That's the Backup Manager's job to do.

The Backup Manager is started up, which is a process that runs entirely in the background. As the name suggests, it's primary job is to keep track of backups, but also to generate backups. The very first thing the backup manager does, is to check the folder where backups are stored, to see if there are any backup archives to be found there. Any backup archives that are found, are then partially loaded into memory, strictly for the purpose of fetching slot, date, time and the stored hash for each backup. The actual compressed backup data is skipped.

During this initial loading process, the backup history is also generated in memory. Dates and times are arranged in chronological order to allow the UI handler to display relevant backup history information as needed.
Once this loading process is completed, the backup manager reports back to the UI handling, that it has completed it's job and presents the backup history results. This is where the UI handling updates the "Home" view with the number of backups stored per save slot and the backup log panel is also updated with the available backup history.

The backup manager's primary job, is to safeguard your saved worlds by making a copy of a save as it is generated by the game and storing it for safe keeping.
A series of events occur to accomplish this task, starting with the folder monitor. When you save to a slot in the game, the folder monitor detects that one or more files where changed. This change triggers an event that causes the cache manager to reload all the save file information. Once this is completed, another event is triggered signalling that the cache manager has done it's job and this is where the backup manager comes in.

All of the currently cached save files are queued up for processing in the backup manager and it starts the job of checking each save file for changes. While I could have narrowed the checking to just the single file that was changed by the game, I decided it was safer to check all the available save files to avoid any one save file being missed.

The cache manager has already taken care of the process of generating a Sha1 hash for each of the save files, so the backup manager checks it's internal backup history dictionary to figure out whether this particular save has already been backed up or not. When the backup manager comes across a save file hash that doesn't already exist in it's internal backup history dictionary, the save file is then put through a GZip compression to conserve space and then appended to the appropriate backup archive for safe keeping. Finally a unique backup ID is generated for this backup, which includes the slot number, the date and time of the save file. These backup IDs are only used internally for faster referencing, however they can always be used to quickly transfer relevant information between different aspects of the application. The UI handling makes extensive use of these backup IDs as a compact way of dealing with the data needed for displaying backup history.

The backup archives mentioned previously, are similar to how a regular ZIP file works. The save files are compressed and then stored in a structured file format, allowing up to a couple of billion compressed save files to exist in every backup archive. One backup archive is generated per month and will therefore only contain backups made for that particular month. This also makes it easier to delete old backup archives in a single swoop, by simply deleting the backup archive in the backups folder, which is readily available through the UI.

For the technically inclined, here is the full outline of the .backup file format:

4 bytes - File ID: "WBA" followed by an end-of-file marker.
          Hex   : 57 42 41 1A
          UInt32: 440484439

4 bytes - Archive month signifier
          byte: century part of year (i.e.: "20" from the year 2021)
          byte: decade part of year (i.e.: "21" from the year 2021)
          byte: month (1 to 12)
          byte: terminator, must always be zero.
        

Int32 (4 bytes) - BackupEntryCount
          Indicates the total number of backup entries following this.

<The following is repeated BackupEntryCount times>

UInt64 (8 bytes) - BackupID (see: &qout;BackupID" further down)
Sha1Hash (20 bytes) - standard Sha1 hash of the original save file.
Int32 (4 bytes) - compressed block size in bytes.
bytes[compressedSize] - the GZip compressed data of the original save file.
        

The one marker in this data that is a bit special, is the "BackupID" which follows this format in this order:

UInt32 (ulong) (8 bytes)

byte 0: Slot Number
byte 1: Century part of what becomes an UInt16 (ushort), same as the month signifier above.
byte 2: Decade part of what becomes an UInt16 (ushort), save as the month signifier above.
byte 3: Month (1 to 12)
byte 4: Day
byte 5: Hour
byte 6: Minute
byte 7: Second
        

As you can see, it's relatively straight forward, but a neat shortcut to dealing with large quantities of backups and provides a nifty way of referencing them quickly.

Among the other jobs that the backup manager has to perform, is restoring a backup. Through the UI, you can trigger a restore to take place, which then after you have confirmed that this is what you really want to do, triggers the backup manager to perform a restore operation on the single backup that you have selected. The UI internally makes use of the backupID to reference this particular backup, so that ID is included when the backup manager is instructed to begin restoring the backup.

The backup archive that contains the specified backupID, is then opened for reading and the compressed block of data, is then decompressed and finally written to the game's saves folder. If that slot is already occupied by another save, it is overwritten with the contents from the backup. Keep in mind, that ROWB does request you to confirm this action before it takes place.
In most cases, the file being overwritten will already exist as a separate backup in the backup archives somewhere, so it's not a total loss, unless you yourself have cleared out these older backups.

Worth noting, is that performing backups takes priority over restoring and any other task the backup manager can perform.

Of perhaps less importance, is the ability to export a backup to a folder of your choice. Whether you have selected just one backup or multiple backups, triggering an export will pop up a standard Windows folder browser dialog, requesting that you select a folder somewhere on your computer, where you want to export the backups to.

Once a destination is confirmed, the backup manager begins the process of exporting these backups to the selected folder. Just like during a restore operation, ROWB reads through each relevant backup archive, finds the backups you have selected, decompresses them and then writes those files to disk.

From time to time, it's good to clear out old junk. On both the "Home" view and the "Backup Archives" view, you have options to delete files and backups, through the trash bin tool button icon.
There are confirmation dialogs at every step, just to make sure that you indeed want to delete stuff.

Deleting a save in a slot on the "Home" view through ROWB, is usually not that big of a deal, because that save has automatically been backed up already and therefore should still exist in the backup archives, unless of course you have delete those backups as well.

Deleting one or more backups however, is a bit more dangerous to do. There is no undo option to deleting backups. It is a permanent deletion, with no options for recovery later on, so I recommend that you think carefully before deleting any backups.
There were thoughts of adding automatic clean-up of older backups into ROWB, however it hit me that there is the likely scenario of someone putting the game down for say 3-6 months and then coming back to the game and running ROWB again.
With an auto-prune (delete) old backups option of say: "anything older than 30 days" (or whatever was configured), there would be the potential of ROWB effectively wiping all backups due to the time difference. So, I chose to skip having this sort of automation, in favour of keeping your backups safe.

As you can tell by now, there is a lot of stuff happening under the hood in ROWB.

All of these different monitors, managers and processes, were built to ensure the safety of your data at all times. In particular the folder monitor and cache manager, work in tandem to ensure that the game has completely finished writing the save data to the file, to avoid conflicting with the game, once the backup process beings. This is of particular importance, since two programs effectively are trying to access the same single file at the exact same time, which if not done correctly, can cause either or both programs to crash, horribly, possibly even corrupt the save data beyond repair.

Everything that ROWB does, is built with the sole purpose of keeping your world saves as safe as possible, without causing conflicts or otherwise interferring with the running of the game.
In effect, ROWB, for intents and purposes, is designed to be "forgotten" about, once you start playing. Just leave ROWB running in the background while you are playing and ROWB will silently but surely and safely generate backups of your worlds, every time you hit the save button in the game.

Everything in ROWB is event driven, so if nothing changes, then nothing happens. There is no timed checking of the save files every 60 seconds or something crazy like that. When you close ROWB's window, the application does shut down, however if the backup manager is still processing, it will remain active in the background until it completes it's current work and then terminate.