Windows is doing this already - pages are pulled in from the executable as needed.


Actually, the entire program is loaded (minus any referenced externals) upon execution, then any dll's that are accessed are processed at first usage and expunged when they have a use count of 0. But thats not what I'm meaning.

IE: Splash window shows up, only once during program start (like Adobe Photoshop, etc), then when it's done, those areas are freed from memory, to allow for other code to pull in, and if you never use a certain function (within the program, not a dll), the code isn't read in from the exe on disk.



Humm... if they're referencing the import table, it should work... but I guess it depends on details of your scheme. Sounds like you're doing weird stuff ^_^


But thats the problem, each segment is dynamically loaded when needed, and when it's no longer needed, expunged for free space to work in. IE: A 2 meg exe would take 64k of any memory to run in, as the sections needed would be in chunks and would only need about 64k of memory to work with. It's how the Macs do things on such short memory constraints. It's the closest I can explain what I'm doing, takes chunks from a "chunk file", same idea though, when I need the code, that part that is referenced, is pulled in, set up and used, count is kept a hold of and when room is needed, the oldest chunk gets tossed.
Posted on 2003-08-03 18:09:45 by FunkyMeister

Actually, the entire program is loaded (minus any referenced externals) upon execution, then any dll's that are accessed are processed at first usage and expunged when they have a use count of 0. But thats not what I'm meaning.

Wrong :)
Pages are pulled in on a as-necessary basis. It's not done in 4k increments though, I think it might be 64k or something like it. If you don't believe me, try creating an executable with a huge (say, 128 megs) array of 'A's. Will take some time assembling it with masm because of the way DUP works. But it will show I'm right.

Also, the advantage of letting windows handle this (voided if you use silly things like EXE packers) is that, in low-mem situation, windows can discard code/static-data pages, and re-read the, directly from the disk file if needed again. If you use exe compression or implement your own swapping scheme, you have dirty pages, which have to be swapped out to the pagefile.

Not saying you can't get some benefit from doing it on your own...
Posted on 2003-08-03 18:16:18 by f0dder


Wrong :)
Pages are pulled in on a as-necessary basis. It's not done in 4k increments though, I think it might be 64k or something like it. If you don't believe me, try creating an executable with a huge (say, 128 megs) array of 'A's. Will take some time assembling it with masm because of the way DUP works. But it will show I'm right.


Well, either way, I need a safe bet to call windows library functions from a non-in-memory function (pulled in as needed/used). And the thing is, the entire program will load if you have enough memory (seen that happen). The Cache also will have a copy of it (if it's large enough too). If you don't have the memory, then yes, the entire thing gets tossed into the swap file minus the part that's not there. I've not run into any program that hasn't done that. Minus the DLLs.


Also, the advantage of letting windows handle this (voided if you use silly things like EXE packers) is that, in low-mem situation, windows can discard code/static-data pages, and re-read the, directly from the disk file if needed again. If you use exe compression or implement your own swapping scheme, you have dirty pages, which have to be swapped out to the pagefile.

Not saying you can't get some benefit from doing it on your own...


Well, the problem is, I need to do it myself. The mystery on getting to Windows is odd, not sure why Microsoft made talking to their OS so alienating.

It's got to be the hardest one to talk to out of a good deal of them, well, for what I'm doing.
Posted on 2003-08-03 23:49:03 by FunkyMeister