Software Deployment

ORIGINAL: pjgeutjens

The working directory for a shortcut basically indicates where the target of the shortcut (usually an exe) can find any other files, like DLLs for example, that it needs to be able to startup and function.

PJ



Pieter,

This raises an interesting question, does/can the working directory for a shortcut influence the normal rules for DLL search order ?

I have always assumed that it cannot, because otherwise the shortcut working directory could be used as a form of 'poor man's application isolation', but I'm prepared to be proved wrong and would be interested in yours (and others) views on this.

Regards,

Spartacus

Hi Vataprasad,

The "WkDir" column in the "Shortcut" table are used to define the working directory of a shortcut.

The value of "WkDir" can be a directory defined in the "Directory" table "INSTALLDIR", or a property defined in the "Property" table "MYPROPERTY" (without the qotes).

/Matias

It´s simply the directory for the target of the shortcut. E.g. if the shortcut target is a .exe file, then the working directory for that shortcut
is the directory where that .exe file resides in, and so on.

It´s simply the directory for the target of the shortcut. E.g. if the shortcut target is a .exe file, then the working directory for that shortcut
is the directory where that .exe file resides in, and so on.

While this is usually true, this does not always have to be the case. The working directory for a shortcut basically indicates where the target of the shortcut (usually an exe) can find any other files, like DLLs for example, that it needs to be able to startup and function.

PJ

This raises an interesting question, does/can the working directory for a shortcut influence the normal rules for DLL search order ?

Graham,

interesting question. Some research taught me that the current working directory is part of the DLL search order, so yes, it does greatly impact this.
It would seem there's been quite some writing done on the subject of "DLL Search Order Hijacking", which, if I understand correctly, basically entails putting a compromised version of a DLL in the working directory/ EXE path to have it supersede a system dll.

Be sure to check out that article I linked, I found it very interesting.

Rgds,

PJ