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

  • Release Candidate 6
    We are at a “proposed final” true release candidate with nothing known remaining to be changed or fixed. 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:

    This forum does not automatically send notices of new content. So if, for example, you would like to be notified by mail when Steve posts an update to his blog (or of any other specific activity anywhere else), you need to tell the system what to “Watch” for you. Please checkout the “Tips & Tricks” page for details about that... and other tips!



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