da**********@gm ail.com wrote:
I have a C++ app on my flash drive that i am running,
So why are you posting to a .NET group?
OK, I can't immediately think of an appropriate newsgroup off the top of my
head either, but I'm sure there is one (maybe one of the
comp.os.ms-windows.* groups). Anyway, moving right along...
but often times, i must take the flash drive out of the computer and use
it elsewhere while the executable continues to run.
however, the executable's behavior is sporadic, and it will
disappear. I think the app is calling a DLL that exists in the
current directory, but since the flash drive is gone, it can't find
it.
so, i wanted to know if i could load the executable with all of its
associated DLLs into memory and run it from there... that way i am
free to remove the flash drive at will.
I'm pretty sure this just isn't possible without the application cooperating
by copying itself to a safe location first, and restarting itself from
there. As I've always learned it, loaded binaries are just memory-mapped
files, which means that Windows can choose to discard pages (or never load
them in the first place) and page them in as needed. If you remove the
original file while it's still being used this way, things fail rather
spectacularly. I don't know whether the loader can detect executables being
launched from removable drives to take special action (like paging
everything out to swap, or not discarding any pages ever), but I'd assume it
doesn't, certainly not on all versions of Windows. If anyone knows
differently I'd love to hear it...
Paging can happen even if the application imports no further DLLs.
Obviously, if it does import DLLs this just exacerbates the problem, and if
it dynamically loads DLLs when they're no longer there you're completely
sunk. You can inject threads in the application and force it to load those
DLLs before its time, but this may cause DLL initialization to happen at an
unexpected time and it will prevent the DLL from unloading when the
application might expect it to, either of which can easily cause trouble.
That's assuming that you can figure out what DLLs it's going to dynamically
load in the first place -- the application might try discovering them on
disk, which will of course fail if the medium's gone. None of this will do
anything to safeguard against the possibility of the DLL needing to be
available for paging, and I haven't even addressed the problem of the
application's default directory becoming invalid (which is something a lot
of applications don't like, unsurprisingly) .
In short, the only reliable way of making this work is to copy the
executable and its dependencies to temporary (but reliable) storage.
*** DISCLAIMER *** i know that i could put the executable and
associated files on the local drive, please don't suggest alternatives
to my process. i want to load the program in memory and make sure it
can run it stably from there as a proof of concept.. just to prove
it's possible.
I'm not sure it is. You could try attaching a debugger to the application to
see why it *really* crashes (is it a page fault, a file not found error or
something else entirely?) and you might improve your chances by having the
executable and its dependencies be as small as possible (to encourage
everything being paged in and nothing being discarded) but it's still a
crapshoot.
You could try creating a RAM drive and copying the flash drive contents
there. That's technically still a "local drive", but it doesn't take up disk
space other than in the swap file.
--
J.
