An interesting thread here, guys.
I'll offer a few points of clarification from my standpoint...
SpinRite 7 will be a full "start over from scratch" for SpinRite. This is mostly because SpinRite will be running on an entirely new windowed graphical operating system and it will have more of a feeling of being a mass storage workstation. As I currently envision it...
A (possibly long) list of the system's current drives with an overview of their characteristics will be running down the left side of the screen — like large vertical tabs on a web browser — and that list will dynamically grow and shrink as drives are added or removed. Those left-edge tabs will be large enough to allow monitoring of progress of any operations on that drive. So in addition to identifying the drive, what it's doing, if anything and a progress bar will always be visible. When a drive is selected, it obtains focus and the entire rest of the screen displays details about it with horizontal tabs running across the top allowing selection of various views of the drive's information, SMART, logs, maps, specs... everything.
I'm sure I'll lift much of the proven low-level math/time/display routines from v6.1 since they are already performing the 64-bit math that's required for 48-bit LBA drives. And, certainly, much of SpinRite's recently rewritten core will be moveable almost whole, since, as was observed above, it's all already flat-model 32-bit code. But mostly what will survive is in its entirety is everything I've just learned during the work on v6.1. This is one of the reasons do not plan to put SpinRite down and wait at all. My head is chock full of "SpinRite" right now. So I want to capture that in SpinRite's new code.
I've not allowed myself to "crack open the box" of RTOS-32, though I've been drooling to do so. So I do not yet know how much of RTOS-32's low-level driver code will survive. But I do NOT intend to rewrite anything that doesn't need it. It already has drivers for IDE, ATA, SATA, USB, and NVMe controllers. So one of our first orders of business will be to determine whether they're already able to handle everyone's systems as they are out of the box. If so, that means that I'll only need to add low-level hooks for SpinRite-specific operations. I already know that the drivers provide a very generic abstracted interface to their callers. (Read this, write that, did it work?) So I'll need to provide the means for SpinRite to obtain far more detail and talk to drives' "metadata." But SRv6.1 already does this so adding that won't be a mystery or a big deal. And I purchased the entire source code for everything.
So my plan for SR7 will be familiar to those who were with me from the start of SR6.1. I'm going to quickly bring up a simple command line interface with a scrolling text window and write a "drive enumerator" to discover every drive attached to the system. Then I'll add a benchmark to verify the readability of everything that anyone has. We'll quickly learn whether RTOS-32's existing drivers are able to handle everything that SpinRite 6.1's drives have learned to handle. And if not I'll dig into them to enhance them with what I've learned from v6.1.
At that point we'll have the basis for SR7 and I'll implement SpinRite 7's proposed Windowing system. One of the reasons I like the windowing architecture I described above is that it's completely modular and open-ended. The drive technologies that it can handle are transparent under the drive list on the left, and the functions it's able to handle per drive are also open-ended with tabs across the top. And... tabs can be added as we go along, adding additional features and capabilities to SpinRite. And, if a SpinRite 7 owner also owns Beyond Recall, the "Beyond Recall" tabs simply get added to the common SpinRite workstation.
And, finally, RTOS-32 also provides a large subset of the original Win32 API, which is the API to which I still code. The DNS Benchmark, InControl, ValiDrive, etc. are all written in the original Win32 API. And THAT means that all of the prototyping of SR7's new tabbed-windowed UI can be coded, implemented and tested by all of us under Windows without leaving Windows. This will make that aspect of the development much easier. And it also leaves open the possibility that some future SpinRite may also be dual-hosted and able to run entirely under either RTOS-32 or Windows.
So, that's my current plan. As for how long it will take?... I have no idea. But what I can promise is an interesting journey, an approach that will get something up, running and testable as soon as possible, and a result that's going to be worth working towards.
