Program data storage.

pcmattman · **Posted:** Tue Jul 24, 2007 1:36 am

JamesM wrote:

Quote:

I have heard of an OS storing the disk sectors required to be loaded each time a program starts, and going from that list. I guess that causes problems for defragmenters though!

As I mentioned above, Vista does that. Although it stores the filenames instead of the disk sectors so it can shimmy sectors around on disk to it's heart's content.

I don't see the speed increase unless you stored the entire image in memory.

JamesM · **Posted:** Tue Jul 24, 2007 2:56 am

@pcmattman:

Why? a lot of programs (as i said, graphics intensive, games, resource intensive) are I/O bound on startup, loading resources. If those resources are precached this reduces the startup time. The amount of computation that most programs do (excluding specialist programs - interpreters, compilers, translators etc) its minimal compared to the amount of resources loading.

You would get a speedup if you stored the image, yes, but you would also get a speedup without. (As can be shown in that this 'feature' of vista was apparently stolen and M$ have another court case on their hands)

hailstorm · **Posted:** Thu Jul 26, 2007 5:31 am

AJ wrote:

MessiahAndrw wrote:

This has given me a few interesting ideas. How about hibernating programs? Like, if you need to close a program, you have a choice of saving it's state.

Some potential problems:

* What if your program requires dynamic linking? There is a high chance that when it wakes up, the dll could be in a different place.
* What if your program makes use of something like its Program ID or Window ID which are likely to be assigned dynamically?
* How do you solve the problem of several instances of the program running / hibernating concurrently.

I think it's a good idea in some cases, but just wanted to throw some thoughts in to the melting pot

Cheers,
Adam

Good questions, though I think these problems can be overcome.

The first problem has to do with how you load your dynamic libraries into the process address space. If the library is loaded, don't load id, but map the pages is in the right order, I guess this information is stored when the user decides to hibernate the program. Otherwise, load the library and do the same thing; map the pages how they should be mapped.

The second problem can be solved pretty simple. Take a look at windows for example. When the user decides to close a program, windows sends a message to this program, that it is about to be closed. The program responds to this message by doing a cleanup of <fill in here> and responding to the windows kernel that closing the program is ok.
This principle can be applied to hibarnating programs. Though pid's and window-id's can change, by using a kind of (registered) call back function in the program itself or some kind of messaging system, the program can reinit it's important program id's and do a kind of reclaim of resources.

Third prob: You cann create a reservation file that is used to register hibernated programs using pid's, window id's etc. This is needed anyways. When multiple instances of a program are hibernated, a combination of a screenshot and the program's title will do the trick to recognize the right instance of the program.

My conclusion: Hibernating programs is certainly possible.

OSDev.org

Program data storage.

Who is online