Question about spinrite 6 and 7 segmented vs paging memory model.

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


Well-known member
Jul 19, 2021
So I've been reading multiple sources about memory management and operating systems including virtual memory and paging and in some cases how the kernel (windows/linux) manages memory for itself. I am still early on this, but I think in some cases the kernel does not include paging the a process would. My question for this post is does SpinRite 6.1 not use paging, but rather use segments? Also, as SR7 will move to a OS similar to Windows will it then use paging? I understand paging uses the memory management unit of the CPU if SpinRite 6 is not using paging that it must just ignore the memory management unit and you have code that handles/understands your segmentation? I guess as spinrite is small and the only thing running, you might not need paging.

Anyway a random question tying spinrite into my quest to fully understand windows and linux.

Paging is a way to simulate having more memory than is physically present. SpinRite is around 64K in size... lack of memory is not really an issue for it, even on old machine with only 640K of RAM.
I think paging does more than just allow an extension to physical memory via persistent storage. Paging would also allow the same memory to be allocated to multiple processes (operating system code). I think it is the case that memory is often allocated to more than one process, in fact I think that's why Windows uses copy on write as part of its memory manager. So if the memory needs to be modified for one process and not the other you'd end up with two copies with one modified. Paging, I think is the basis for virtual memory managers. There is a more primitive virtual memory technique called base and bound, but it makes me think that is just using segment registers, not sure. For the On-Time Win32 kernel I did some very quick research and it looks like it does use paging by default but it might be the case that it has like a kernel pool of memory which is using segmenting. Not sure, quick reading. This is not a very important question but I guess I'm just generally curious as to how SpinRite will be developed and how it compares to other operating systems. And I wonder if SpinRite will evolve into a Windows program, in which case I think (maybe, not sure) the segment stuff will go away.

I generally think I understand paging more than how segmenting would work in spinrite or even an old dos program. The only thing I imagine with segments and just manually dealing with them, I guess I would have to mess around with the ideas.
I suspect it all began with IBM mainframes. Core memory was expensive, even more expensive that spinning disks. In order to be able to tackle larger problems, paging to secondary media (which almost always disk until after 2000) was used.

Then came the need for things like Unix to have every system process see their view of memory as unique, so then you have virtual memory mapping. That may or may not incorporate swap (disk paging.) The idea is that you can let the CPU think the memory exists in one place and the memory management unit will actually map the memory to another address. This allows for the concept of read only memory or even write only memory... but those concepts aren't as commonly used outside of esoteric OS needs. There are also memory mapped files... where the byte address in memory represents an offset in the file, but I personally wonder how useful that is compared to just writing your own code to manage a file. (In this case you'd be letting the OS manage it... but it's going to be generalized whereas you could write more efficient specific code.)
Paul's correct about the origins of paging being to deal with constrained memory environments. You would never swap memory out of a machine if you had any other choice.

That said, there are some other clever uses for the virtualization of memory. For example, a clever operating system can notice (and many virtual environments now do) when differing VM on a hypervisor, or different processes within an OS, have duplicate copies of the same memory — like the same OS running in adjacent VMs or the same DLL library code being used by differing processes. So the manager of memory virtualization might only load one (read-only) instance of anything that's being shared into physical memory, then "point" all of the various users of that single instance to it. Each of those users would think that their copy was private. And it might appear at differing apparent physical addresses, but they would actually all be sharing the same single instance.

(But even so... the motivation for all of that cleverness is still the reduction in actual memory usage. :)
  • Like
Reactions: SeanBZA