All of what follows is predicated on the assumption that your program
can be used to monitor any other program; that is, it’s not a specially
designed program. If this isn’t the case, then most of what follows
will not apply.
Unless I’m missing something, no matter what you use - subst, Object
Manager, et. c. - if you use standard resources - drive letters or
really anything that resolves to a system or session wide symbolic link
- you’re going to be SOL if whatever the application originally used
happens to exists on the new machine, and it isn’t the same thing.
Also, what are you doing about the data? That is, are you packing it up
and taking it with you? Is this what the virtual disk is for? It
doesn’t matter what you put under the application, as long as the
application expects to read a certain file from, say, “C:\tmp\tst2,”
then “c:\tmp\tst2” or a hard link to it must exist on the new machine,
and if it already exists and isn’t the same, you’re screwed. A virtual
disk doesn’t change this. It some cases it probably would be possible
to exploit the separate local and global DOS namespaces to get around
this, but not in generic way that would work for any resource.
Object Manager is ultimately involved in this whole mapping business,
but using it directly won’t help you get around this problem.
In order to do this, I think you need an additional level of abstraction
here, and you’ve got to essentially monitor all system resources that
the application uses: file system, registry, stack, context, et. c.
This is a tall order. This is essentially what VMM’s do with Live
Migration. Because you are confining yourself to applications only (not
drivers), your task is easier, but it is still a lot of work.
If I’m on the right track, let me know, and we’ll see how it goes, if
you still wish to proceed, but, assuming I am, one would have to have a
very good reason for doing this to make it worth the investment. One
very good reason is if this is for educational purposes.
mm
xxxxx@gmail.com wrote:
Hi everyone,
Earlier this week, I have asked a question regarding virtual disk and Michal answered me that I can use either subst or DefineDosDevice.
Let me try to explain what I am trying to do here just to give you little bit of background. Right now, I have a program that sort of checkpoint an application and I can move it to other machine and restart the app there.
As an initial step, it is working relatively but suppose I have a machine that has c: and d: drive and I move an app to new machine that has c: drive only. In this case, an app can fail if it expects any data from d:. Of course I save all the dependent files in certain fashion to differentiate data between from c: and d: drive.
Now, I can use either subst or DefineDosDevice to create d: drive but then this d: drive will then appear in other apps in the same machine.
In other words, I just want to have it display in my app only. I also have read that Object Manager deals with all the data regarding devices so I was just wondering if there is any calls that I can work with to show my app d: drive.
Or just an initial step, is there any way I can somehow directly store d: drive in Object namespace? I am sort of limited to use calls in NTDLL so this is another problem.
If I can at least know the function calls that I can use for query/set d: drive, I can perhaps just add d: drive and replace arguments.
Please let me know if I am making any sense. I will really appreciate any help/advice.
YEH
