XPost: comp.os.ms-windows.programmer.win32, alt.windows7.general   
   From: G6JPG@255soft.uk   
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)