If the total sectors exceeds 127Gb this is not possible, but normal
simh disks are smaller and the largest user settable size via RAUSER
is just under 1Tb. The excessive size case (>127Gb) will have a CHS
of 0xFFFF10FF.
simh never cares about the CHS Disk Geometry value in the VHD footer
data structure, but other applications which do care about the CHS
value using the previously incorrect value as the capacity of the disk
even though the Current Size indicated in the footer may have been
larger.
Remove windows_build.yml due to a MS compiler enforcement change. Build
fails because libpng16.lib was compiled with a different compiler
version (VS 2008?) relative to the current VS 2022 installed in the
Github windows-latest runner.
MS decided that libraries must be compiled with a compatible compiler,
preferably the compiler-in-use. While not conclusively traced to a MS
trouble ticket, it seems reasonable to assume there exists a trouble
ticket wherein an older MS compiler generated code that was incompatible
with VS 2022, thereby necessitating the enforcement (speculation: LTO
instrumentation, for example?)
- Bump SIMH_VERSION_MINOR in CMakeLists.txt. This propagates down
through the rest of the CMake infrastructure.
- README-CMake.md, cmake/{GitHub-release.md,cmake-builder.sh}: Update
documentation. (Prettiness.)
- vcpkg.json: Update simh version-string. (Consistency.)
NOTE: Github CI/CD: There has to be an automated way to update version
numbers; researching.
PDP11/pdp11_rq.c re-uses ->filebuf as a sector buffer (under the #defined
name rqxb) and allocates it as such. If an RQ disk is detached and
another attached, this buffer would be lost and the pointer reset to
NULL. sim_disk.c would only allocate the buffer if UNIT_BUFABLE is set,
which means to buffer the whole disk. Since this rightly isn't set on RQ
disks, the pointer would remain NULL and segfaults would ensue. See
open-simh issue 274.
add comment about safe re-use of filebuf
Fixes suggested by running the Clang memory santizer on the Github CI/CD
pipeline:
- sim_exp_check: Use calloc() to allocate and initialize the PCRE
captured string offset vector. Also check the offsets to ensure they
are captured substrings:
-- If a substring wasn't captured, the offset pair is { -1, -1 }.
(Of course, this would never happen in SIMH. :-)
-- Remove the corresponding "_EXPECT_MATCH_GROUP_{pat}" variable
from the environment when its substring isn't captured. unsetenv()
is locally implemented in scp.c, which sets the environment
variable to an empty string; it isn't actually removed.
Failure occurs in multiple tests.
- _sim_debug_write_flush: Ensure that debug_line_buf_last's underlying
buffer is initialized when realloc-ed. (i650 failure.)
- vid_version: Initialize local variables "compiled" and "running". MSan
claims that these aren't initialized. Reading the SDL source, the
patch level might not be initialized on some platforms. (multiple
sim_video tests.)
NOTE: Do not attempt to run interactive memory-santized simulators on
Linux platforms where ncurses <= 6.2+20201114-2. MSan detects
uninitialized variables within ncurses; newer versions of ncurses fix
them.
- Give appveyor.yml some much needed attention. Specifically, work
around the CMake build termination when the issuing the "CMake is too
old to produce packages" warning message. There's something funky with
how Appveyor's runtime interacts with PowerShell and
warning/diagnostic output ends up terminating builds unexpectedly.
Appveyor's technical support says to write the CI/CD script using the
old DOS CMD interpreter, not PowerShell.
- Cut down the number of builds. Older Visual Studio VM images are still
in the appveyor.yml matrix, just commented out.
- dep-locate.cmake: Update dependency library version numbers to reflect
recent releases for libpng16, SDL and SDL_ttf. This affects the XP
"legacy" CMake builds on Github CI/CD, Appveyor's VS 2017 and earlier
VM images that build the minimal SIMH dependency library support
(i.e., environments where vcpkg is known not to work.)
VS installer's startup is not instantaneous and there's some lag in the
CI/CD pipeline. Adjust strategy to wait for startup (20 seconds max) to
make the script more robust. (Doesn't seem to get triggered, but that
doesn't mean it won't happen in the future.)
Add the the following command line flags:
--force: Forces VS instance termination, if any are running.
(Unclear impact. Paranoia.)
--norestart: Delay reboot, if reboot needed. (Probable reason why
(Most likely reason why installs were incomplete.)
--installWhileDownloading: Self-explanitory. (Unclear impact.)
"Get-VSSetupInstance/Select-VSSetupInstance" will report a VS
instance ID if successful, e.g.:
DEBUG: Get-VSSetupInstance/Select-VSSetupInstance
InstanceId : 8d19910a
DisplayName : Visual Studio Enterprise 2022
InstallationVersion : 17.6.33815.320
InstallationPath : C:\Program Files\Microsoft Visual Studio\2022\Enterprise
InstallDate : 6/20/2023 9:38:11 PM
Useful output in the GH CI/CD log for future debugging.
Rethink how the Windows XP toolkit installs because the Chocolatey
installer(s) changed and broke the SIMH CI/CD build. Revert to a
previous strategy that updates the GH Windows runner image in-place with
Microsoft's vswhere and vs_installer tools.
There's some Grey Magic in how this is done, with some adapted
PowerShell code from the Chocolately PS scripts. The upshot is that
vs_installer spawns a subprocess to do the actual install, but there's
now way to get vs_installer to actually wait for that subprocess to
complete. So, the script has to look for the installer subprocesses and
poll-wait for them to finish.
* CMake build infrastructure
The squashed commit that builds and packages releases for the SIMH
simulator suite with CMake, version 3.14 or newer.
See README-CMake.md for documentation.
Only SCP libraries should be including additional OS specific include
files since they cover both:
1) Are responsible for platform specific details integrated into simh
support
and
2) Implement extended functionality optimally considering the proper
behaviors to cooperate with the simh event system and existing
capabilities.
Simulator code can optionally include any of these system include files:
<stddef.h>, <stdlib.h>, <stdio.h>, <stdarg.h>, <string.h>, <errno.h>.
<limits.h>, <ctype.h>, <math.h>, <setjmp.h>
Such inclusion will be redundant with what is already provided here
by sim_defs.h. Simulator code should include SCP provided include files:
"scp.h", "sim_card.h", "sim_console.h", "sim_disk.h", "sim_ether.h",
"sim_fio.h", "sim_imd.h", "sim_scsi.h", "sim_serial.h", "sim_tape.h",
"sim_timer.h", "sim_tmxr.h", "sim_video.h"
depending on the specific needs of the device being simulated.
