Difference between revisions of "Vizcacha"
m (→Technical background: minor change - missing "h") |
|||
| Line 5: | Line 5: | ||
==Technical background== | ==Technical background== | ||
| − | Vizcacha consisted of two programs: one for the racer and one for the tournament administrator; | + | Vizcacha consisted of two programs: one for the racer and one for the tournament administrator; both DOS native executables. The racer version would start and load a TSR routine in memory, then run Stunts as a child process. The routine was supposed to detect Stunts and activate another routine that would inhibit the options "Load Replay" and "Continue Driving" in the replay menu. Without these two options, it was impossible to perform replay handling. It would also intercept the "Save Replay" option and add an encoded footer at the end of the replay file saved certifying that it had been saved while Vizcacha was functioning normally and therefore, without the use of replay handling. If something would go wrong, the replay would be saved as usual, without the certification. The tournament administrator version would simply check on a replay file and verify the validity of the certification. |
At the time of publishing, Cas had been able to get both programs working on his computer in pure DOS with the only exception that the inhibition was only working on the keyboard and not on the mouse. Still, if the program had worked well on other systems, he was considering to just have Vizcacha disable the mouse driver or inhibit the mouse entirely while on the replay menu, which was easy to do. | At the time of publishing, Cas had been able to get both programs working on his computer in pure DOS with the only exception that the inhibition was only working on the keyboard and not on the mouse. Still, if the program had worked well on other systems, he was considering to just have Vizcacha disable the mouse driver or inhibit the mouse entirely while on the replay menu, which was easy to do. | ||
Unfortunately, the memory layout of Stunts seemed to vary significantly depending on where in memory it had been loaded and on what else was in memory at the moment, so the assumptions Cas had made on where to locate the variables did not generally work. When Vizcacha was run in DOSBox or in pure DOS on a different computer, it failed to inhibit the menu options and could even overwrite sensible memory causing a crash. A more profound analysis of the memory layout could help revive the project, but its importance has weakened in recent years. | Unfortunately, the memory layout of Stunts seemed to vary significantly depending on where in memory it had been loaded and on what else was in memory at the moment, so the assumptions Cas had made on where to locate the variables did not generally work. When Vizcacha was run in DOSBox or in pure DOS on a different computer, it failed to inhibit the menu options and could even overwrite sensible memory causing a crash. A more profound analysis of the memory layout could help revive the project, but its importance has weakened in recent years. | ||
Revision as of 23:31, 25 September 2020
Vizcacha is a defunct software project by Cas started in August 2009. The aim of the program was to provide a method of verification for replay handling. The project was abandoned when the strategy it was based upon was found to be unreliable.
History
Around 11 August 2009, Cas was making some tests on his laptop computer. He had found a simpler way to face the problem of verifying replay handling. At least, the idea itself was simple. After four nights of programming and testing, the program seemed to be working fine, so he posted it in the forum on August 15. When the community members started to test Vizcacha, it would either always report RH was not used or crash depending on the platform it had been run on. By late September, Cas had reached the conclusion that Stunts did not necessarily handle its memory the way he had assumed and to solve this, a lot more work was necessary. The project was abandoned by the end of the year.
Technical background
Vizcacha consisted of two programs: one for the racer and one for the tournament administrator; both DOS native executables. The racer version would start and load a TSR routine in memory, then run Stunts as a child process. The routine was supposed to detect Stunts and activate another routine that would inhibit the options "Load Replay" and "Continue Driving" in the replay menu. Without these two options, it was impossible to perform replay handling. It would also intercept the "Save Replay" option and add an encoded footer at the end of the replay file saved certifying that it had been saved while Vizcacha was functioning normally and therefore, without the use of replay handling. If something would go wrong, the replay would be saved as usual, without the certification. The tournament administrator version would simply check on a replay file and verify the validity of the certification.
At the time of publishing, Cas had been able to get both programs working on his computer in pure DOS with the only exception that the inhibition was only working on the keyboard and not on the mouse. Still, if the program had worked well on other systems, he was considering to just have Vizcacha disable the mouse driver or inhibit the mouse entirely while on the replay menu, which was easy to do.
Unfortunately, the memory layout of Stunts seemed to vary significantly depending on where in memory it had been loaded and on what else was in memory at the moment, so the assumptions Cas had made on where to locate the variables did not generally work. When Vizcacha was run in DOSBox or in pure DOS on a different computer, it failed to inhibit the menu options and could even overwrite sensible memory causing a crash. A more profound analysis of the memory layout could help revive the project, but its importance has weakened in recent years.
