ExtMemObjects...Window vs Actual...
Posted: Sat Sep 09, 2017 8:44 pm
I'm trying to deal with ExtMemObj's that are outside the normal 2GB addressable memory limit while using a limited size window for what is mapped.
If I allocate 64MB or 128MB and decide to use it as a remap window for a beyond 2GB addressable area that is a multiple of the window size (128MB access window into 1GB allocated for example....)
I'm trying to work out if this is even practical within the current mechanisms of the ExecNG Memory Management.
I do know that this will seem somewhat strange but it is required for the way I am currently dealing with non-native ELF and other Executable formats.
locally mapping the allocations is okay so far but when I am dealing with memory locations I can't safely access without a whole window-size=allocation-size I quickly run out of memory before the application proceeds.
I was thinking of an ExtMemObj handle with some means of walking the memory it refers to in window-size steps and accessing things that way.
maybe there is something I'm missing when reading ExtMemObj usage?
I'm trying to workaround DLL loading limitations without introducing too many fake DLLs or loading DLLs recursively until memory is exhausted.
If I allocate 64MB or 128MB and decide to use it as a remap window for a beyond 2GB addressable area that is a multiple of the window size (128MB access window into 1GB allocated for example....)
I'm trying to work out if this is even practical within the current mechanisms of the ExecNG Memory Management.
I do know that this will seem somewhat strange but it is required for the way I am currently dealing with non-native ELF and other Executable formats.
locally mapping the allocations is okay so far but when I am dealing with memory locations I can't safely access without a whole window-size=allocation-size I quickly run out of memory before the application proceeds.
I was thinking of an ExtMemObj handle with some means of walking the memory it refers to in window-size steps and accessing things that way.
maybe there is something I'm missing when reading ExtMemObj usage?
I'm trying to workaround DLL loading limitations without introducing too many fake DLLs or loading DLLs recursively until memory is exhausted.