From Newsgroup: alt.windows7.general

Hello Shugo,

Not really, but as a workaround:
use a .bat instead:

[snip]

or 2nd idea: a little app launcher .exe with only a listbox
with a list of apps and a start button, then ShellEx with
relative path.

I've been thinking of and coming up with a few solutions myself too, but
would like to explore the possiblility of using an already existing
mechanism first.

Thanks for the suggestions though.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2025/9/2 10:36:46, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

[]

I'm puzzled; don't . and .. work in shortcuts?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

interracial marriage was still illegal in 17 states in 1967.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB
harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

I'm programming against the IShellLink interface ( https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinka) ,
which suggests a relative path is possible (SetRelativePath), but I'm not
able to get it to work or find code explaining how to do it.

I did find this : https://devblogs.microsoft.com/oldnewthing/20171019-00/?p=97247 , but I'm
not even sure if that is what I'm after ... :-|

Question: does someone have an example to what I'm supposed to do to make it happen ?

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

J.P. ,

I'm puzzled; don't . and .. work in shortcuts?

Alas no. Not thru the "properties" of an existing one, not when creating
one using VBScript, and not when doing the same using the IShellLink object.

The first and the last will throw an error, and VBScript will just silently combine it with the "c:\" root.

Though for the IShellLink object its possible that I've just not found the correct way to do it...

That is, using XPsp3. I've got no idea if it has changed on later versions
of Windows.

Regards,
Rudy Wieser



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Tue, 9/2/2025 7:34 PM, J. P. Gilliver wrote:

On 2025/9/2 10:36:46, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB
harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

[]

I'm puzzled; don't . and .. work in shortcuts?

A shortcut is designed to be copied or moved anywhere.

If the shortcut icon is sitting on the desktop, and
it says ..\programname.exe , that's not going to work.

If the shortcut icon uses an absolute path, then it can be copied
or moved anywhere. If the Original file is moved (somewhere), you
are required to create a new Shortcut (new absolute path).

If you want a file to appear in two places (on the same partition),
then mklink or junction.exe might work. Then, the item is no longer
a shortcut, it's a file, and it looks like a file icon. A hardlink
of a file can be moved to the desktop, but when the program
"works out where it is", as some programs do, it is going to find
that it is not located in the portable folder where all the
DLLs are located.

Right now, the betting money is on a shortcut with an absolute
path inside it. Then, the executable that is loaded, is loaded
from the same folders as where the DLLs are located (right next
to the EXE).

*******

The rules are different for Metro.App , but the newsgroup
list does not hint that this is a requirement.

# A folder full of scum and villainy (mixed types are present)

explorer.exe shell:AppsFolder

# These are two shortcuts, compared.
# I might even find both of these in AppsFolder (on a newer OS).

[Picture]

https://i.postimg.cc/ZR6KdXfH/shortcut-comparison.gif

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

A shortcut is designed to be copied or moved anywhere.

And, as it looks now, their *only* goal. I can imagine using a full path
as the default, but ignoring relative paths is just a "it works for us" short-sighteness.

... unless you have a good reason why relative paths would not be possible ?

If the Original file is moved (somewhere), you are required to create
a new Shortcut (new absolute path).

Nope. It will try to find the target itself, but gives you the option to browse for it.

I could easily do without that behaviour (its search method is opaque) and
just get an "target has gone" error. Have not seen any configuration for
that though.

If you want a file to appear in two places (on the same partition),
then mklink or junction.exe might work.

Hard links do not work on FAT32 (thumb)drives. And neither program exists
on my OS (XPsp3).

but when the program "works out where it is", as some programs
do, it is going to find that it is not located in the portable
folder where all the DLLs are located.

:-) Pros and cons. They have to be weighted.

Right now, the betting money is on a shortcut with an absolute
path inside it.

Not usable on a removable (thumb)drive I'm afraid.

... hence my (subject-line) question.

Regards,
Rudy Wieser



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

J.P. ,

But I don't know - if the "Start in" field is not filled in, does the shortcut [or, perhaps more accurately, whatever's processing it]
assume it is in some prefefined location, such as %windows%\system32
or something like that, rather than where the shortcut actually is?

Using IShellLink to create the shortcut I get the root-of-roots, the desktop folder. And I can't edit the shortcuts target and working-directory properties anymore (the fields are grayed out). Why ? Good question.

If the shortcut icon uses an absolute path, then it can be copied
or moved anywhere.

Yes, but that's not "relative".

Indeed. Paul just tried to tell me why using an absolute path is the best idea ever and I should not want anything else.

R didn't say _why_ he wanted "relative shortcuts":

:-) You even quoted the reason in your post ! :

[quote=me, initial post]
(for use on a removable USB harddisk)
[/quote]

all I could think of was that he wanted to be able to move/copy an entire structure - shortcuts and targets - to a different location (say, another machine, or a memory stick or external drive which might have a
different letter at times).

Or move to another location on the same drive, or to another drive on the
same 'puter. All examples where relative shortcuts would be usefull.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Wed, 9/3/2025 3:47 AM, R.Wieser wrote:

Paul,

A shortcut is designed to be copied or moved anywhere.

And, as it looks now, their *only* goal. I can imagine using a full path as the default, but ignoring relative paths is just a "it works for us" short-sighteness.

... unless you have a good reason why relative paths would not be possible ?

If the Original file is moved (somewhere), you are required to create
a new Shortcut (new absolute path).

Nope. It will try to find the target itself, but gives you the option to browse for it.

I could easily do without that behaviour (its search method is opaque) and just get an "target has gone" error. Have not seen any configuration for that though.

If you want a file to appear in two places (on the same partition),
then mklink or junction.exe might work.

Hard links do not work on FAT32 (thumb)drives. And neither program exists on my OS (XPsp3).

but when the program "works out where it is", as some programs
do, it is going to find that it is not located in the portable
folder where all the DLLs are located.

:-) Pros and cons. They have to be weighted.

Right now, the betting money is on a shortcut with an absolute
path inside it.

Not usable on a removable (thumb)drive I'm afraid.

... hence my (subject-line) question.

Regards,
Rudy Wieser

There is a feature called "AppPath" or so, where executables not
in the regular path environment variable, are stored in the Registry.

https://learn.microsoft.com/en-us/windows/win32/shell/app-registration

I somehow doubt a USB key would be allowed a reference in there.
Only partition letters "in good standing" like C: should be
stored there. Any partition which is volatile would be a poor
candidate for inclusion, since the drive letter could be reused
any time.

But that's just a demo that at some point, they decided to augment
%path% type environment variables, with a few more pointers.

Just leave your EXE and DLL in the bin\ subdirectory you created
and people will find it :-) Or, consult the people who make portable applications, and maybe they have a treatise on the subject.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 02.09.2025 11:36, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

I'm programming against the IShellLink interface ( https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinka) ,
which suggests a relative path is possible (SetRelativePath), but I'm not able to get it to work or find code explaining how to do it.

I did find this : https://devblogs.microsoft.com/oldnewthing/20171019-00/?p=97247 , but I'm not even sure if that is what I'm after ... :-|

Question: does someone have an example to what I'm supposed to do to make it happen ?

Not really, but as a workaround:
use a .bat instead:

cd \myPath\
start myapp.exe
exit

ciao...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Paul,

There is a feature called "AppPath" or so, where executables not
in the regular path environment variable, are stored in the Registry.

I know. Arlen seems to swear by it.

I somehow doubt a USB key would be allowed a reference in there.

Guess again. Arlen uses it to store the path to batch files. I've also
had it, as a test, point to a textfile. It also worked.

Only partition letters "in good standing" like C: *should* be
stored there.

(bolding mine). As mentioned above, it seems to accept anything. It looks like it just shoves it to the shell and make it its problem.

But that's just a demo that at some point, they decided to augment
%path% type environment variables, with a few more pointers.

Its usefull for programs which have a lot of "rubbish" stored alongside.
You don't want to have those in the searchpath.

Just leave your EXE and DLL in the bin\ subdirectory you created
and people will find it :-)

Thats good for the 'puter you're on. For all others, just place those DLLs next to the executable.

Or, consult the people who make portable applications, and maybe
they have a treatise on the subject.

Wrong focus. Although its likely my desired relative shortcut will point
to an executable or two, it would also be used to point to folders,
textfiles and other. Just like the current shortcut can do.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 03.09.2025 16:35, R.Wieser wrote:

...

Or, consult the people who make portable applications, and maybe
they have a treatise on the subject.

Wrong focus. Although its likely my desired relative shortcut will point to an executable or two, it would also be used to point to folders, textfiles and other. Just like the current shortcut can do.

Hi!

If the file is a known filetype with a registered
standard app, then ShellExecute(...) or "start" in a .bat
should open the file just fine, even folders.
(just tried with start foldername)

ciao...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 02.09.2025 11:36, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

I'm programming against the IShellLink interface ( https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinka) ,
which suggests a relative path is possible (SetRelativePath), but I'm not able to get it to work or find code explaining how to do it.

I did find this : https://devblogs.microsoft.com/oldnewthing/20171019-00/?p=97247 , but I'm not even sure if that is what I'm after ... :-|

Question: does someone have an example to what I'm supposed to do to make it happen ?

or 2nd idea: a little app launcher .exe with only a listbox
with a list of apps and a start button, then ShellEx with
relative path.

ciao...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2025/9/3 7:21:58, Paul wrote:

On Tue, 9/2/2025 7:34 PM, J. P. Gilliver wrote:

On 2025/9/2 10:36:46, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB
harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

[]

I'm puzzled; don't . and .. work in shortcuts?

A shortcut is designed to be copied or moved anywhere.

If the shortcut icon is sitting on the desktop, and
it says ..\programname.exe , that's not going to work.

I wouldn't expect it to - unless the target was moved/copied to the same relative location. But that's what R.Wieser said he _wanted_: a shortcut
the refers to a target relative to where the shortcut is.

But I don't know - if the "Start in" field is not filled in, does the
shortcut [or, perhaps more accurately, whatever's processing it] assume
it is in some prefefined location, such as %windows%\system32 or
something like that, rather than where the shortcut actually is?>

If the shortcut icon uses an absolute path, then it can be copied

Yes, but that's not "relative".

or moved anywhere. If the Original file is moved (somewhere), you
are required to create a new Shortcut (new absolute path).

R didn't say _why_ he wanted "relative shortcuts": all I could think of
was that he wanted to be able to move/copy an entire structure -
shortcuts and targets - to a different location (say, another machine,
or a memory stick or external drive which might have a different letter
at times).>

If you want a file to appear in two places (on the same partition),
then mklink or junction.exe might work. Then, the item is no longer

I've never got into those (-:

a shortcut, it's a file, and it looks like a file icon. A hardlink
of a file can be moved to the desktop, but when the program
"works out where it is", as some programs do, it is going to find
that it is not located in the portable folder where all the
DLLs are located.

Right now, the betting money is on a shortcut with an absolute
path inside it. Then, the executable that is loaded, is loaded
from the same folders as where the DLLs are located (right next
to the EXE).

*******

The rules are different for Metro.App , but the newsgroup
list does not hint that this is a requirement.

# A folder full of scum and villainy (mixed types are present)

explorer.exe shell:AppsFolder

# These are two shortcuts, compared.
# I might even find both of these in AppsFolder (on a newer OS).

[Picture]

https://i.postimg.cc/ZR6KdXfH/shortcut-comparison.gif

Paul

So far, I've (AFAIK) managed to not get involved with metro "app.s";
from your picture, I see they _have_ Target and Start in parameters, but
not in editable fields.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"The wish of the lazy to allow unsupervised access [to the internet] to
their children should not reduce all adults browsing to the level of suitability for a five-year-old."
Yaman Akdeniz, quoted in Inter//face (The Times, 1999-2-10): p12
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Schugo,

If the file is a known filetype with a registered
standard app, then ShellExecute(...) or "start" in a
.bat should open the file just fine, even folders.
(just tried with start foldername)

Thanks for the suggestion.

I'm still hoping someone knows how to create a relative shortcut though.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Real links are not an option? https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions --
Mit Radwegen lernte ich den Menschen kennen. http://radwege.udoline.de/
GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Udo,

Real links are not an option? https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions

The first one doesn't work with FAT 32 (the default for thumbdrives), and
the second has the same problem a shortcut has : using full pathnames.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 03.09.2025 19:19, R.Wieser wrote:

Schugo,

If the file is a known filetype with a registered
standard app, then ShellExecute(...) or "start" in a
.bat should open the file just fine, even folders.
(just tried with start foldername)

Thanks for the suggestion.

I'm still hoping someone knows how to create a relative shortcut though.

I haven't found any code example to add the StringData structure.
Looks like you have to create the .lnk file by yourself.

IShellLinkA::SetRelativePath doesn't seem to do this: https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishelllinka-setrelativepath


This is from the LNK file format:

2.1.1 LinkFlags
The LinkFlags structure defines bits that specify which shell link structures are present in the file format after the ShellLinkHeader structure.

HasRelativePath (0x00000008)
The shell link is saved with a relative path string. If this bit is set, a RELATIVE_PATH StringData structure (section 2.4) MUST be present

2.4 StringData
RELATIVE_PATH: An optional structure that specifies the location of the link target relative to the file that contains the shell link. When specified, this string SHOULD be used when resolving the link.

...
Example:
Because HasRelativePath is set, the RELATIVE_PATH StringData structure
follows:

CountCharacters: (2 bytes), 0x0007 Unicode characters.
String (14 bytes), the Unicode string: ".\a.txt".

ciao...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 02.09.2025 11:36, R.Wieser wrote:

...
I did find this : https://devblogs.microsoft.com/oldnewthing/20171019-00/?p=97247 , but I'm not even sure if that is what I'm after ... :-|

however, there he claims the relative path is already in any .lnk,
but not used, because LINKINFO and LINKTRACK is used first.

"Normal shortcuts already remember the targetAs location relative to the shortcut itself. However, the relative path is not used until other avenues have been exhausted. To give the relative path more prominence, letAs disable the other avenues."

so you have to add these 2 flags

SLDF_FORCE_NO_LINKINFO
SLDF_FORCE_NO_LINKTRACK

with

IShellLinkDataList::SetFlags https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ishelllinkdatalist-setflags

ciao...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Tue, 2 Sep 2025 11:36:46 +0200, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

I'm programming against the IShellLink interface ( https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinka) ,
which suggests a relative path is possible (SetRelativePath), but I'm not able to get it to work or find code explaining how to do it.

I did find this : https://devblogs.microsoft.com/oldnewthing/20171019-00/?p=97247 , but I'm not even sure if that is what I'm after ... :-|

Question: does someone have an example to what I'm supposed to do to make it happen ?

Regards,
Rudy Wieser

Shortcut file strictly use absolute path.

The relative path part of it (set by SetRelativePath), is only use as a hint
on resolving broken link.

SetRelativePath documentation's remark:
"The SetRelativePath method can be used to help the link resolution process find its target based on a common path prefix between the target and the relative path."

Even if a relative path is used to set the (normal) Path field, the Shell
Link API will expand it to a full path. Also, SetIDList only accept absolute IDList.

The only way to create a shortcut file with its Path field set to a relative path, is to craft the shortcut file without using Shell Link API. Though,
I'm not sure about the actual result when such shortcut file is used, since
the Shell Link API is expecting absolute paths for all fields.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On Wed, 3 Sep 2025 20:38:58 +0200, Udo Steinbach wrote:

Real links are not an option? https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions

Hardlink and symlink can't store command line argument. So it can't be used
to run an application with command line arguments.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 03.09.2025 21:22, R.Wieser wrote:

Udo,

Real links are not an option?
https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions

The first one doesn't work with FAT 32 (the default for thumbdrives), and the second has the same problem a shortcut has : using full pathnames.

A solution without programming:

https://optimumx.com/download/Shortcut.zip

Z: is a USB drive
make a link to Z:\test\test2\dxcpl.exe

shortcut32 /a:c /f:test.lnk /t:.\test\test2\dxcpl.exe /w:.\test\test2

- click on the test.lnk,
- file is not found, click search button, point to the .exe
- .exe launches, .lnk is updated in this moment with the correct relative
paths
- change the drive letter to G:
- click on the G:\test.lnk, .exe launches correctly

ciao...


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2025/9/3 14:17:47, Paul wrote:

On Wed, 9/3/2025 3:47 AM, R.Wieser wrote:

Paul,

A shortcut is designed to be copied or moved anywhere.

_If_ it has an *absolute* path in "Target" (and in "Start in" if that's relevant). Which it _will_, if it's made by the usual "make shortcut"
method.

[]

There is a feature called "AppPath" or so, where executables not
in the regular path environment variable, are stored in the Registry.

That's fine on one computer.

[]

My understanding is that Rudy wants to have (for example):

a\b\shortcut.lnk

that points to

a\c\target.exe

[I have _deliberately_ *not* put anything before "a", because it could
be in the root, or a subdirectory]

and, to be able to move/copy directory a (and its subfolders b and c) to anywhere (including an external drive and/or another computer where no "AppPath" has been invoked), and still have the shortcut find the target.

[I would have thought changing the absolutes in the shortcut to Target: ..\c\target.exe, and Start in: to ..\c, from whatever creating the
shortcut had put there, would work, but I haven't tried.]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf

"Get off my turf!" screamed Pooh, as he shot at Paddington.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 9/2/2025 5:36 AM, R.Wieser wrote:

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB harddisk) and can't seem to find out how it works.

* the target of the link is relative to the location of the link itself.

I'm programming against the IShellLink interface ( https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinka) ,
which suggests a relative path is possible (SetRelativePath), but I'm not able to get it to work or find code explaining how to do it.

I did find this : https://devblogs.microsoft.com/oldnewthing/20171019-00/?p=97247 , but I'm
not even sure if that is what I'm after ... :-|

Question: does someone have an example to what I'm supposed to do to make it happen ?

Regards,
Rudy Wieser

For Win 11:
Make a batch file that has a list of the items you want to find.
Manually select the item and have batch enter its name into "Quick
Search" in task bar and followed with a CR and search result will
include present location of the item

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Schugo,

I haven't found any code example to add the StringData
structure.

Thats part of it. The other one is the IDList. I'm not at all sure what
will happen when they mismatch.

Looks like you have to create the .lnk file by yourself.

... And hope that, when I put a relative path to the target in there, its resolved correctly. Mind you, there is no need for a shortcut to do such a resolving, as it's supposed to have full paths.

Yes, I've been thinking about generating the shortcut datafile myself too.
:-)

I've already sought for and found some file-format descriptions. No indication which version of Windows they are valid for though. :-(

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Shugo,

so you have to add these 2 flags

SLDF_FORCE_NO_LINKINFO
SLDF_FORCE_NO_LINKTRACK

I did, and saw no difference.

Thats the problem with "just do it" suggestions. Without test cases and/or description *when* those flags should have effect its rather hard to check (w|t)hat they actually do. :-(


But have you noticed this :

"Deleting those two pieces of information means that the shell cannot use
them to help find the shortcut.

*If the file doesn't exist at the specified absolute path*,

then the relative path will be applied to the location of the shortcut
itself, and the shell will look for the file at the resulting location"

(bolding mine)

That means that the "its now relative" trick will only work when the
origional target file isn't there anymore.

Now imagine copying a folder-tree, containing a document and a shortcut to
it, to somewhere else , and than double-clicking the copied shortcut to edit the also just copied document.

You won't like the result. :-|

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

JJ,

Shortcut file strictly use absolute path.

Really ? (don't worrry, just some ribbing)

From your own quoting :

The *relative path part* of it (set by SetRelativePath),

(bolding mine)

And by the way, thats *not* a relative path (so much for descriptive names
and descriptions). From the MS docs :

"The address of a buffer that contains the *fully-qualified path* of the shortcut file, ... *It should be a file name* "

(bolding mine)

And yes, I got confused by that methods name too - it has exactly zero to do with the other, very similar name (just no "Relative" in it).

Even if a relative path is used to set the (normal) Path field,

You can't do that, I tried (duh). The only thing you will get is an error (or, in case of vbscript, having it silently combined/prepended with the C:\ drive).

the Shell Link API will expand it to a full path.

See above, thats not my experience.

Also, SetIDList only accept absolute IDList.

Well, thats easy : I'll just remove that list ! :-) But yes, that was
another thing crossing my mind.

The only way to create a shortcut file with its Path field set
to a relative path, is to craft the shortcut file without using
Shell Link API.

Yep, it looks like it.

Though, I'm not sure about the actual result when such shortcut
file is used, since the Shell Link API is expecting absolute paths
for all fields.

:-)) I just replied to Shugo with the same doubt.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Schugo,

A solution without programming:

https://optimumx.com/download/Shortcut.zip

Z: is a USB drive
make a link to Z:\test\test2\dxcpl.exe

That is a solution for the current computer.

The idea is to have the shortcut on an USB (thumb)drive, and have it work
even when its put into another 'puter (and getting another drive letter ).


Thanks for the program.

... but a quick look at its readme.txt file does seem to indicate its also only uses full pathnames ...

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Zaidy036,

For Win 11:
Make a batch file that has a list of the items you want to find.
Manually select the item and have batch enter its name into "Quick Search" in task bar and followed with a CR and search result will include present location of the item

That solution only works for the current 'puter (and won't work if-and-when
I take the USB (thumb)drive to another one).

Its also a bit over-engeneered. :-) (Shugo's first reply suggested a two-line batch file)

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2025-09-03 13:26, R.Wieser wrote:

J.P. ,

But I don't know - if the "Start in" field is not filled in, does the
shortcut [or, perhaps more accurately, whatever's processing it]
assume it is in some prefefined location, such as %windows%\system32
or something like that, rather than where the shortcut actually is?

Using IShellLink to create the shortcut I get the root-of-roots, the desktop folder. And I can't edit the shortcuts target and working-directory properties anymore (the fields are grayed out). Why ? Good question.

The per-user Desktop is only the "root-of-roots" in the Windows
95-inspired shell object model . In the real NT-based operating systems
such as Windows NT 3.x, Windows 2000 or Windows 11, the root-of-roots is
the empty root of the NT kernel object naming system, which contains a
folder named "\??" with symlinks like "\??\C:" This root is only
accessible using the low level NTDLL.DLL APIs and the driver programming kernel APIs, such as ZwCreateFile() etc.

If the shortcut icon uses an absolute path, then it can be copied
or moved anywhere.

Yes, but that's not "relative".

Indeed. Paul just tried to tell me why using an absolute path is the best idea ever and I should not want anything else.

R didn't say _why_ he wanted "relative shortcuts":

:-) You even quoted the reason in your post ! :

[quote=me, initial post]
(for use on a removable USB harddisk)
[/quote]

all I could think of was that he wanted to be able to move/copy an entire
structure - shortcuts and targets - to a different location (say, another
machine, or a memory stick or external drive which might have a
different letter at times).

Or move to another location on the same drive, or to another drive on the same 'puter. All examples where relative shortcuts would be usefull.

Regards,
Rudy Wieser

One thing to consider is that removable hard drives can be formatted
with almost any OS supported file system, including the NTFS version
used for Windows NT 6.0x (Vista/Win7/Win8/Win8.1 for x=0/1/2/3), which
happens to support relative file system symlinks, but subject to the
arbitrary rule that to create an on-disk NTFS symlink, a user needs the special privilege to create kernel namespace symlinks such as "\??\C:" .

Significantly older NTFS versions only supported absolute symlinks in
the form of "junctions", which were stored on disk in terms of the
kernel namespace name of the drive containing the target directory
(junctions cannot link to files), but I don't remember the exact cut-off
OS version that introduced general NTFS symlinks, which may be different
from the version that added mklink and other UI support.


Enjoy

Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 2025-09-04 08:22, R.Wieser wrote:

Shugo,

so you have to add these 2 flags

SLDF_FORCE_NO_LINKINFO
SLDF_FORCE_NO_LINKTRACK

I did, and saw no difference.

Thats the problem with "just do it" suggestions. Without test cases and/or description *when* those flags should have effect its rather hard to check (w|t)hat they actually do. :-(

But have you noticed this :

"Deleting those two pieces of information means that the shell cannot use them to help find the shortcut.

*If the file doesn't exist at the specified absolute path*,

then the relative path will be applied to the location of the shortcut itself, and the shell will look for the file at the resulting location"

(bolding mine)

That means that the "its now relative" trick will only work when the origional target file isn't there anymore.

Now imagine copying a folder-tree, containing a document and a shortcut to it, to somewhere else , and than double-clicking the copied shortcut to edit the also just copied document.

You won't like the result. :-|

Indeed, and that is why I always disable the "Distributed Link Tracking" services in Windows installations that contain them, as those services
exist only to produce the same wrong result for links within OLE2-style documents (a concept which includes MS Office 9x, Explorer shell
shortcut files etc. etc.) .

Enjoy

Jakob
--
Jakob Bohm, MSc.Eng., I speak only for myself, not my company
This public discussion message is non-binding and may contain errors
All trademarks and other things belong to their owners, if any.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 04.09.2025 09:02, R.Wieser wrote:

Schugo,

A solution without programming:

https://optimumx.com/download/Shortcut.zip

Z: is a USB drive
make a link to Z:\test\test2\dxcpl.exe

That is a solution for the current computer.

The idea is to have the shortcut on an USB (thumb)drive, and have it work even when its put into another 'puter (and getting another drive letter ). ...

It works!
The magic happens after "File not found", when you point it to
the file, the .lnk is updated with realtive paths.
I checked in a hex editor.
And I also checked, it works with a different drive letter.

ciao..

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 04.09.2025 09:02, R.Wieser wrote:

Schugo,

A solution without programming:

https://optimumx.com/download/Shortcut.zip

Z: is a USB drive
make a link to Z:\test\test2\dxcpl.exe

That is a solution for the current computer.

oh, btw: I found no references in the .lnk
to the current computer only, but the volume
label of the USB-Stick instead.

ciao..

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Schugo,

It works!
The magic happens after "File not found",

I already posted to you why that will not always work.

Furthermore, what you describe is what a standard shortcut already does -
but only when you actually try to open the target, not when you read the shortcuts stored paths.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 04.09.2025 16:11, R.Wieser wrote:

Schugo,

It works!
The magic happens after "File not found",

I already posted to you why that will not always work.

Furthermore, what you describe is what a standard shortcut already does - but only when you actually try to open the target, not when you read the shortcuts stored paths.

if you think so... works fine for me.

BTW: here I found some source code to create a .lnk file

https://github.com/ElektroStudios/Easy-Link-File-Viewer/releases/tag/v1.7

And this tool also saves the relative paths correctly. Also works with a changed drive letter.

If you create a shortcut with the windows UI there are no correct relative paths, like you said. Just look with a hex editor!

ciao...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Shugo,

if you think so... works fine for me.

Ok, you've convinced me.

I created a link with that program :

shortcut32 /a:c /f:test.lnk /t:.\test.txt

Yes, using an hex viewer I see only "test.txt" (ascii and wide-char) in the file (no absolute path).

Alas, when I double-click the link it causes an "problem with shortcut"
dialog to pop up, and I'm asked if I want to delete it.

I'm not even getting an "missing shortcut" dialog ...

It works when I provide a full path though. Than again, when I do so the shortcut file itself looks quite different. And again quite different from
a shortcut created by the OS.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Shugo,

Another thing :

[quote=you]
The magic happens after "File not found", when you point
it to the file, the .lnk is updated with realtive paths.
[/quote]

Are you *sure* that the result is again a relative path (to the target), and not an absolute path as it normally contains ? As the shortcut-creating program doesn't seem to work for me, can you check ?

The thing is, if the standard resolving by the OS of a relative shortcut created by that program results in a shortcut with absolute paths again than its no good for me* - it has to /stay/ relative.

* and I don't need to put effort into finding such a program for my OS or trying to generate such a shortcut file myself.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 05.09.2025 09:34, R.Wieser wrote:> Shugo,

Another thing :

[quote=you]
The magic happens after "File not found", when you point
it to the file, the .lnk is updated with realtive paths.
[/quote]

Are you *sure* that the result is again a relative path (to the target), and not an absolute path as it normally contains ? As the shortcut-creating program doesn't seem to work for me, can you check ?

Not at the beginning of the file, only at the optional string section RELATIVE_PATH towards the end of the file. The normal path strings at
the beginning of the file are always absolute. I tried changing an
absolute to a relative path by hand and it failed with file not found.

But what again is your exact problem, if it works on changed drive letters
and when moved to a different drive even deep down in a directory?
I haven't tested it, but I'm 99% sure that it works also on a different
windows installation, if that works.

(my test target was 2 folders down btw, yours was in the same folder,
maybe that makes a difference, if the find target (?) button is shown)

ciao..

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Shugo,

But what again is your exact problem, if it works on changed
drive letters and when moved to a different drive even deep
down in a directory?

Assuming you are talking about a standard shortcut, it doesn't work as long
as the origional target is still present (read : the subtree is copied).

I haven't tested it, but I'm 99% sure that it works also on a
different windows installation, if that works.

Thats part of the problem : in /some/ (normal) situations it works, and in other (as normal) situations it won't. And thats just begging for Murphys
law to be invoked. :-(


As an example, try this :

1) Create a textfile and write "origional" in it. Close it
2) Create a shortcut to it next to that textfile.

3) copy the textfile and shortcut to some other spot on the same 'puter
4) Open the copied textfile and replace "origional" with "copy". Close it

5) Double-click the copied shortcut. I /want/ to see the textfile with "copied" in it, but that is not what happens - at least, not here.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 05.09.2025 17:05, R.Wieser wrote:> Shugo,

But what again is your exact problem, if it works on changed
drive letters and when moved to a different drive even deep
down in a directory?

Assuming you are talking about a standard shortcut, it doesn't work as long as the origional target is still present (read : the subtree is copied).

I haven't tested it, but I'm 99% sure that it works also on a
different windows installation, if that works.

Thats part of the problem : in /some/ (normal) situations it works, and in other (as normal) situations it won't. And thats just begging for Murphys
law to be invoked. :-(

As an example, try this :

1) Create a textfile and write "origional" in it. Close it
2) Create a shortcut to it next to that textfile.

3) copy the textfile and shortcut to some other spot on the same 'puter
4) Open the copied textfile and replace "origional" with "copy". Close it

5) Double-click the copied shortcut. I /want/ to see the textfile with "copied" in it, but that is not what happens - at least, not here.

ok, that's true, unless the original file is moved/deleted, then
the "copy" is opened...

I'm happy that it works with changed drive letters, your use case is
like never happening in my reality ;)

ciao..
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

Schugo,

ok, that's true, unless the original file is moved/deleted,
then the "copy" is opened...

Yep. And that won't do.

I'm happy that it works with changed drive letters, your use
case is like never happening in my reality ;)

.... Until it does happen and you accidentily invoke the wrath of Murphys
law ... :-p

Thanks for the help.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general


"R.Wieser" wrote :

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB harddisk) and can't seem to find out how it works.

It looks like I ran head-first into some "over-engenering". :-(

As I could not find any way to create a relative shortcut using the
IShellLink object, I took a better look at the Shortcut file itself. And
going on a hunch, I was able to solve the problem in the most basic way ever
: by manually creating a shortcut file.

It turns out that writing the header with only the "HasRelativePath" flag
set and than the desired (counted-length) relative path followed by four
bytes all Zero (as the end of extras list of blocks) does the trick.

Adding other strings (arguments, working directory, description) the same
way also works.

One downside though : when going into the properties and changing the target causes the shortcut to revert to its normal, absolute paths format.

... At least, here on my XPsp3 machine.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.windows7.general

On 05.09.2025 21:05, R.Wieser wrote:

"R.Wieser" wrote :

Hello all,

I'm trying to create relative shortcuts* (for use on a removable USB
harddisk) and can't seem to find out how it works.

It looks like I ran head-first into some "over-engenering". :-(

As I could not find any way to create a relative shortcut using the IShellLink object, I took a better look at the Shortcut file itself. And going on a hunch, I was able to solve the problem in the most basic way ever : by manually creating a shortcut file.

It turns out that writing the header with only the "HasRelativePath" flag set and than the desired (counted-length) relative path followed by four bytes all Zero (as the end of extras list of blocks) does the trick.

Adding other strings (arguments, working directory, description) the same way also works.

One downside though : when going into the properties and changing the target causes the shortcut to revert to its normal, absolute paths format.

... At least, here on my XPsp3 machine.

congrats! good to know.

ciao..

--- Synchronet 3.21a-Linux NewsLink 1.2