- Updated to boost 1.82
- Fixed TAP driver enumeration change
- Added .bat files to start simulator
- Updated to platform tolset v143
- Removed NuGET boost dependency
- Added gitignore to hide most stuff that we don't want to track
- Removed profile from putty command line
- Changed TAP driver name to what is the default with OpenVPN install
"COS FRONT-END PROTOCOL INTERNAL REFERENCE MANUAL SM-0042", and make it
compatible with the implementation in DtCyber, the CDC Cyber 6000 series
emulator.
I've commented the loop out that was causing the infinite recursion.
Not sure why the code was there, I thought it had to do with
sluggish console. I don't see that though with the code removed,
so let's hope this is sufficient. That would be easy...
This involves:
- updated project files,
- removal of support for XP
- update to latest boost (1.75)
- updating code to work around new deprecation warnings
There is also some cleanup in the project files here.
The problem was that two consequtive reads of the RTC in quick
succession within the compiler was used to validate the
results in the buffer filled by the mtimes syscall.
This syscall buffer is potentially filled by another processor
or by the same one, so the programmers decided to use two
techniques to decide if the results are reliable:
1. Read the buffer twice and compare
2. Make sure that the two reads happened within 200 clock-cycles
from one another.
Since our RTC is based on the host clock, the actual time
passed between those two instructions depends on the host
speed.
This fix allows for a - programmable - interval within which
if two RTC queries are made, we return an artificially low
delta time. This makes cc happy, while doesn't interfere
with normal OS operation and scheduling.
The setting (RealTimeClockChunkLimit, which defaults to 5000)
might need to be adjusted for slow machines, such as the
RaspberryPi4 or similar.
