start existing process in memory

[Devin]

I've tried using the START command but it requires me to specify the
location of executable file.

Is it possible to skip specifying the location and just call the
running executable in memory?

If the START command isn't appropriate, what other command should I
try?

Thanks,

Devin

 

[foxidrive]

I've tried using the START command but it requires me to specify the
location of executable file.

Is it possible to skip specifying the location and just call the
running executable in memory?

Please explain further.

What you might want is a ramdrive.

 

[Tim Meddick]

An executable in memory *must* originally be executed from an existing (.exe) file on
your system.

Although, the path does not appear in memory detail - just the (.exe) name -
nevertheless, to "start" the same executable again, you must have the path to the
(.exe) file.

What happens next (after starting an executable with the same name as the one in
memory) depends on the way executable was built.

Some executables will start another "instance", whereas others will just start
another "thread" and yet others will simply recall the window of it's single
instance.

It would help if you more detailed in what executable (or type of executable) you are
trying to [re]execute?

Probably, the simplest advice would be to type the executable's (full - including the
".exe" bit) name into "Search for files and folders" on your start menu...

==

Cheers, Tim Meddick, Peckham, London.

 

[Todd Vargo]

I've tried using the START command but it requires me to specify the
location of executable file.

Is it possible to skip specifying the location and just call the
running executable in memory?

If the START command isn't appropriate, what other command should I
try?

If it's already in memory, then it is already started. Perhaps you are
looking for AppActivate in VBScript. Like the others, I can think of a few
other meanings too so you will have to chime in to give us more details.

 

[Devin]

Thank you all for replying.

As for details.. I'm trying to run the file/encryption program,
TrueCrypt, from memory again. I use it to encrypt data on my USB
drive.

Sorry if the explanation is long but here it is anyway.

Environment setup and usage:
i) two partitions created - one is open and the other is close
(encrypted).
ii) TrueCrypt.exe reside on the open partition so it is possible for
me to access the encrypted partition anywhere by mounting it to an
available drive letter.
iii) after successful mount, there's an encrypted file within the
(encrypted) partition, which I need to mount as well.

Two simple scripts for :
i) mounting encrypted partition (1st stage) - reside on open or local
partition
ii) mounting encrypted file (2nd stage) - reside within the encrypted
partition

Script content :
1st stage
start "" TrueCrypt.exe /quit background /volume "\Device
\Harddisk1\Partition2" /letter X

2nd stage
start "" TrueCrypt.exe /quit background /volume "X:
\EncryptedFile.tc" /letter Z

To run second script (for mounting encrypted file), I need to either:
i) create another copy of original executable to be inside the same
folder where the script reside. Disadvantage: version conflict will
happen if I forget to update the copy after updating the original (on
USB device's open partition) and mounting with the latest version.
Tiring to remember which copies require updating.
2) hardcoded the executable path on open partition. Disadvantage:
path can break since the USB's drive letter for open partition can
vary.
3) hardcoded the executable path on local partition (i.e. C drive).
Disadvantage: portability lost

I'd like to explore ways that will allow me to :
a) maintain portability
b) require no hardcoded path
c) reduce/avoid creating multiple copies of TrueCrypt.exe

Now back to my original post:
If I am able to re-rerun TrueCrypt.exe from memory again for stage 2,
it will help me deal with b) and c) above.

Thanks,

Devin

 

[foxidrive]

Script content :
1st stage
start "" TrueCrypt.exe /quit background /volume "\Device
\Harddisk1\Partition2" /letter X

2nd stage
start "" TrueCrypt.exe /quit background /volume "X:
\EncryptedFile.tc" /letter Z

To run second script (for mounting encrypted file), I need to either:
i) create another copy of original executable to be inside the same
folder where the script reside. Disadvantage: version conflict will
happen if I forget to update the copy after updating the original (on
USB device's open partition) and mounting with the latest version.
Tiring to remember which copies require updating.
2) hardcoded the executable path on open partition. Disadvantage:
path can break since the USB's drive letter for open partition can
vary.

Search for the USB drive (by volume label or presence of a file in the
root) and use that drive letter in the script.

3) hardcoded the executable path on local partition (i.e. C drive).
Disadvantage: portability lost

I'd like to explore ways that will allow me to :
a) maintain portability
b) require no hardcoded path
c) reduce/avoid creating multiple copies of TrueCrypt.exe

Now back to my original post:
If I am able to re-rerun TrueCrypt.exe from memory again for stage 2,
it will help me deal with b) and c) above.

You could load a ram drive from the open partition and copy the truecrypt
exe file to it.

 

[Tim Meddick]

Just a suggestion....

In your batch script, to overcome the possibility of differing drive-letters, you
could use :

if EXIST F:\My Path\Myfile.ext start MyProgram.exe F:\My Path\Myfile.ext
if EXIST G:\My Path\Myfile.ext start MyProgram.exe G:\My Path\Myfile.ext
if EXIST H:\My Path\Myfile.ext start MyProgram.exe H:\My Path\Myfile.ext

...with examples given here of possible drives F:;G:; and H:

If a number of commands are needed to run when a variable drive-letter is not known,
then :

if EXIST F:\My Path\Myfile.ext set USB_PATH=F:
if EXIST G:\My Path\Myfile.ext set USB_PATH=G:
if EXIST H:\My Path\Myfile.ext set USB_PATH=H:

....then subsequent commands can all use the same path syntax, e.g. :

start MyProgram.exe %USB_PATH%\My Path\Myfile.ext
del %USB_PATH%\MyProgram.log

I'm not entirely clear what it is you want to achieve.

Having read through your post several times, I guess that I should know but, hope
this may help anyway...

==

Cheers, Tim Meddick, Peckham, London.

 

[Todd Vargo]

Thank you all for replying.

As for details.. I'm trying to run the file/encryption program,
TrueCrypt, from memory again. I use it to encrypt data on my USB
drive.

Sorry if the explanation is long but here it is anyway.

Environment setup and usage:
i) two partitions created - one is open and the other is close
(encrypted).
ii) TrueCrypt.exe reside on the open partition so it is possible for
me to access the encrypted partition anywhere by mounting it to an
available drive letter.
iii) after successful mount, there's an encrypted file within the
(encrypted) partition, which I need to mount as well.

Two simple scripts for :
i) mounting encrypted partition (1st stage) - reside on open or local
partition
ii) mounting encrypted file (2nd stage) - reside within the encrypted
partition

Script content :
1st stage
start "" TrueCrypt.exe /quit background /volume "\Device
\Harddisk1\Partition2" /letter X

2nd stage
start "" TrueCrypt.exe /quit background /volume "X:
\EncryptedFile.tc" /letter Z

To run second script (for mounting encrypted file), I need to either:
i) create another copy of original executable to be inside the same
folder where the script reside. Disadvantage: version conflict will
happen if I forget to update the copy after updating the original (on
USB device's open partition) and mounting with the latest version.
Tiring to remember which copies require updating.
2) hardcoded the executable path on open partition. Disadvantage:
path can break since the USB's drive letter for open partition can
vary.
3) hardcoded the executable path on local partition (i.e. C drive).
Disadvantage: portability lost

I'd like to explore ways that will allow me to :
a) maintain portability
b) require no hardcoded path
c) reduce/avoid creating multiple copies of TrueCrypt.exe

Now back to my original post:
If I am able to re-rerun TrueCrypt.exe from memory again for stage 2,
it will help me deal with b) and c) above.

Where do you currently have TrueCrypt.exe stored? Why can you not call it a
second time without making a copy of it somewhere? Why wont a single script
work?

start "" /wait TrueCrypt.exe /quit background /volume
"\Device\Harddisk1\Partition2" /letter X
start "" /wait TrueCrypt.exe /quit background /volume
"X:\EncryptedFile.tc" /letter Z

 

[Al Dunbar]

Thank you all for replying.

As for details.. I'm trying to run the file/encryption program,
TrueCrypt, from memory again. I use it to encrypt data on my USB
drive.

Sorry if the explanation is long but here it is anyway.

Environment setup and usage:
i) two partitions created - one is open and the other is close
(encrypted).
ii) TrueCrypt.exe reside on the open partition so it is possible for
me to access the encrypted partition anywhere by mounting it to an
available drive letter.
iii) after successful mount, there's an encrypted file within the
(encrypted) partition, which I need to mount as well.

I take it, then, that when the encrypted partition is available, the open
one is not. If that is not the case, I would have the second script find the
executable by looking wherever it might be located (as someone already
suggested. Alternately, you could have the first script create the second
script in the %temp% folder. If the first script knows where the executable
is, it could create that second script with the full path included.

Two simple scripts for :
i) mounting encrypted partition (1st stage) - reside on open or local
partition
ii) mounting encrypted file (2nd stage) - reside within the encrypted
partition

Script content :
1st stage
start "" TrueCrypt.exe /quit background /volume "\Device
\Harddisk1\Partition2" /letter X

2nd stage
start "" TrueCrypt.exe /quit background /volume "X:
\EncryptedFile.tc" /letter Z

To run second script (for mounting encrypted file), I need to either:
i) create another copy of original executable to be inside the same
folder where the script reside. Disadvantage: version conflict will
happen if I forget to update the copy after updating the original (on
USB device's open partition) and mounting with the latest version.

Not an issue if the copy is made each time the first script runs...

Tiring to remember which copies require updating.
2) hardcoded the executable path on open partition. Disadvantage:
path can break since the USB's drive letter for open partition can
vary.
3) hardcoded the executable path on local partition (i.e. C drive).
Disadvantage: portability lost

I'd like to explore ways that will allow me to :
a) maintain portability
b) require no hardcoded path
c) reduce/avoid creating multiple copies of TrueCrypt.exe

Now back to my original post:
If I am able to re-rerun TrueCrypt.exe from memory again for stage 2,
it will help me deal with b) and c) above.

IMHO, this cannot be done.

First, I would assume that truecrypt does not stay resident, but does its
work and then terminates. If so, the memory it occupied would be released
back to the O/S, so you could never be sure that an intact copy of the
program still existed in memory.

Second, even if it did remain in memory, it would be a copy that had already
run. Its data storage might not be re-initialized to what it was when first
loaded from its .exe file.

Third, since the only batch commands that allow you to run a program get
that program from an executable file, the only way you could "re-run" a
program still in memory would be to write a program that would find the
program in memory, optionally initialize its storage (wherever that might
be), and be prepared to provide the command-line parameters corresponding to
the second invocation to the program.

And those are only the few issues I could think of late on a work night! ;-)
But it seems to me that the third option would be far more work to develop
(and, yes, your script would need to know where to find this executable)
than finding a way for the first script to provide the required path to the
second.

/Al

 

[Tim Meddick]

Just one more idea I had...

It might be worth reading through the documentation for TruCrypt - as some programs
allow the use of additional switches, some of which may be to do with manipulating
the memory-resident image.

For instance; I use a similar program called "Private Disk" (because it's very easy
to use, very small and very free).

With "Private Disk", you can use the "/transmit " switch to indicate that the command
runs on the current copy in memory (and not a new instance of it)...

==

Cheers, Tim Meddick, Peckham, London.

 

[Al Dunbar]

A good point. In fact the parameter sequence "/quit background" is said to
"launch the truecrypt background task (tray icon)", and the function of that
aspect is to enable the following:

1) Hot keys
2) Auto-dismount (e.g., upon log off, inadvertent host device removal,
time-out, etc.)
3) Notifications (e.g., when damage to hidden volume is prevented)
4) Tray icon

I do not see where it provides any method to rerun this resident code, but
even if it does, I would assume that the method would be to run the
executable again to do so.

I strongly suspect, however, that the background task contains only the code
required to carry out the four functions above.

/Al

 

[Tim Meddick]

About your comment on the probability that to access the resident code ..."would be
to run the executable again to do so" - I say again - the behaviour of a program,
whose image is already in memory, depends on how the program was written!

As you say that there are more than one component to TruCrypt, and that one of those
is a "tray app", I shouldn't wonder that one of it's hot-key combinations summons the
resident program's user interface...

==

Cheers, Tim Meddick, Peckham, London.

 

[Al Dunbar]

About your comment on the probability that to access the resident code
..."would be to run the executable again to do so" - I say again - the
behaviour of a program, whose image is already in memory, depends on how
the program was written!

Agreed! Of course, no program ever written, regardless of its memory
resident status, can do other than what it was written to do.

As you say that there are more than one component to TruCrypt, and that
one of those is a "tray app", I shouldn't wonder that one of it's hot-key
combinations summons the resident program's user interface...

It might indeed do that. However, it is not clear how the OP's batch file
could: a) press that hotkey, and: b) interact with that interface to do what
the OP otherwise does by running the main executable file.

I would suspect that, if the application were written to do precisely what
the OP wants, he would have figured that out from the documentation, and we
would never have been asked the question.

I am not a betting man, but I'd be willing to risk a pound (or a quid or a
shilling (bob) or a crown or a farthing or a florin or a guinea or a
sovereign) or what have you) on a bet with you that the program has not been
designed to allow a batch file to re-run the code resident in memory without
having to run another executable to actually do so. But I'm a long way from
London (unfortunately), so might only be able to stand you to a (virtual)
pint when you win the bet (as if!).

Oh, and this only applies to the current version, not future ones...


/Al

 

[Tim Meddick]

When I indicated that the "TaskBar app" may have a hot-key combination that could
summon the program's user-interface, I did not mean that it was something that could
be done through a batch-file.

It was my assumption that the OP was using his batch-files as shortcuts to achieving
certain outcomes and the hot-key suggestion was my intention to convey that this
could be a possible alternative *to* a batch-file.

==

Cheers, Tim Meddick, Peckham, London.