Sorry your browser is not supported!

Is it possible to piggyback the load commands so that they infact read from a memory location, rather than disk? Obviously, if you had access to the source you could butcher the functions to do this, but unfortunately, we can't rewrite load image.

I was thinking that you could use filemapping, but the filemapping creation routines libraries return handles, and AFAIK you can't pass a handle into load object - it has to be a string.

I appreciate you could just extract or write out the file you want to load to disk, but I'd consider this insecure. Also, you could just use convert memblock to image, but what happens when you're not loading an image - let's say you're using the new Gile[s] importer.

I hope someone knows what I'm babbling on about. Bottom line: Is it possible to use "fake" filesystem locations to use filemapping, rather than file descriptor handles?

It's not possible

The other way would be to build a memblock/mesh using your own routine from data in a filemap.

1 - Write a device driver
- Would need to reboot the machine to make it active. If you get it wrong ... goodbye system!

2 - Intercept calls to the windows file IO functions in Kernel32.
- Safer, but need to understand the IO function calls and handle them all correctly without exception.

Neither easy, and needing expert knowledge of windows internal workings.

Thanks for your input. I'm sure you can appreciate how this would promote "professional" development, but if it isn't possible it isn't possible.

once again, cheers