What is a Desktop Shortcut?
A desktop shortcut is a small file that acts as a pointer to another file, folder, or program elsewhere on the computer. When a person double-clicks a shortcut, the computer follows the pointer and opens the thing the shortcut points to. The shortcut itself is not the program, not the file, and not the folder. It is only the pointer.
This article is part of the foundational file-system orientation sequence in the 57 Studios™ Modding Knowledge Base. The previous article (What is a File Extension?) established how the suffix at the end of a filename communicates the file's type to the operating system. The present article builds on that foundation to explain desktop shortcuts, which are themselves a specific type of file with a specific extension and a specific internal structure that separates them from every other kind of file on the computer.
Understanding shortcuts is directly relevant to Unturned™ mod development because the tools in the modding workflow — Unity Editor, Blender, Notepad++, and others — are routinely accessed through desktop shortcuts. New developers who do not understand what shortcuts are, and what distinguishes them from the programs they point to, encounter predictable and recurring confusion. This article eliminates that confusion before it arises.
Prerequisites
- Completion of What is a File Extension?
- A Windows computer with a desktop visible
- Approximately thirty-five minutes of uninterrupted reading time
- No prior knowledge of how shortcuts work is assumed or required
What you will learn
- What a desktop shortcut is at a technical and conceptual level
- What the
.lnkfile format is and what it contains internally - How shortcuts differ from the original files, programs, and folders they point to
- How to create shortcuts using several different methods
- What shortcut icons and shortcut arrows look like and what they communicate
- What the Target and Start In fields in a shortcut's properties mean
- How to configure a shortcut to run a program with administrator privileges
- What common mistakes new users make with shortcuts, and how to avoid them
- The 57 Studios documented desktop shortcut conventions for modding-tool shortcuts
Background
Desktop shortcuts became a standard feature of the Windows operating system in the mid-1990s. Before shortcuts existed, launching a program required either navigating to the folder where the program was installed and double-clicking the executable directly, or maintaining a separate launcher application. Shortcuts addressed both problems by allowing a small, lightweight pointer file to live anywhere on the computer while the actual program remained in its installation folder.
The desktop — the visible area of the screen that sits behind all open windows — became the canonical location for shortcuts because it is always accessible and requires no navigation to reach. A person can minimize all open windows and immediately see the desktop and its shortcuts. This accessibility made the desktop the dominant location for shortcuts, though shortcuts can be placed anywhere: in folders, on the taskbar, in the Start Menu, and in document libraries.
The distinction between the shortcut and the thing it points to is the single most important concept in this article. This distinction recurs constantly in practical computer use and is the root cause of several common mistakes that new users make. The section on the difference between a shortcut and the original file explores this distinction in depth.
The flowchart above shows the essential relationship. The shortcut lives in one location; the original file or program lives in another location entirely. The shortcut contains a pointer that tells Windows where to find the original.
A brief history of the .lnk format
The .lnk file format was introduced with Windows 95 in 1995 and has remained the standard Windows shortcut format through every subsequent version of Windows, including the current Windows 11. The format was designed to be extensible so that future versions of Windows could add new shortcut features without breaking existing shortcuts. The same .lnk file created on Windows 95 is readable by Windows 11, though Windows 11 adds features that the older file would not contain.
The timeline shows that the core .lnk format has been continuous across nearly thirty years of Windows development. The shortcut file a developer creates today is built on the same structural foundation established in 1995.
Did you know?
The .lnk extension is treated specially by Windows. Even when a user has configured Windows to show file extensions for all file types, .lnk files do not display their extension in File Explorer by default. A shortcut to Blender named Blender appears as Blender in File Explorer, not Blender.lnk. This is a deliberate Windows design choice intended to keep the desktop experience clean for everyday users. Developers who need to confirm that a file is a .lnk shortcut can right-click it, choose Properties, and read the Type field, which will say "Shortcut."
The .lnk file format
A .lnk file is a file like any other file on the computer. It has a name, an extension (.lnk), content, and metadata. What makes it different from other files is what its content contains: rather than containing an image, a document, or executable code, a .lnk file contains a structured record of information that describes where the original file or program is located and how it should be opened.
The content of a .lnk file is binary, meaning it is not human-readable text. Opening a .lnk file in a text editor produces garbled characters, not meaningful information. Windows reads .lnk files using a dedicated parser built into the operating system, which is why double-clicking a shortcut opens the target rather than opening the shortcut file itself for editing.
The internal structure of a .lnk file includes the following key fields:
| Field | Purpose | Example value |
|---|---|---|
| Target path | Full path to the file or program the shortcut points to | C:\Program Files\Blender Foundation\Blender 4.1\blender.exe |
| Start In path | The working directory the program should use when launched | C:\Program Files\Blender Foundation\Blender 4.1 |
| Arguments | Additional text passed to the program at launch | --no-splash |
| Run style | Whether the program window opens normally, minimized, or maximized | Normal window |
| Icon location | The file from which the shortcut's icon is drawn | Embedded in the target .exe |
| Icon index | Which icon within the icon file to use | 0 (first icon) |
| Description | Optional text description visible in the Properties dialog | Blender 3D Editor |
| Shortcut key | An optional keyboard combination that activates the shortcut | None |
| Run as administrator | Whether the program should launch with elevated privileges | No |
The fields above represent the full anatomy of a .lnk file. Most shortcuts use only the Target path and the Icon location; the other fields are used for specific purposes described later in this article.
The flowchart above shows the internal anatomy of a .lnk file. Each field in the .lnk structure serves a distinct purpose; the field descriptions above explain when each field matters in practice.
Best practice
Always check the Target field of a shortcut before relying on it, particularly for shortcuts that have existed on the desktop for a long time. The Target field is the most important field in the shortcut, and a shortcut with an incorrect or outdated Target field will fail to open its intended program.
The difference between a shortcut and the original file
This is the most important section in this article, and it is the section that most directly prevents the common mistakes described later.
A shortcut is not the original file. A shortcut is not a copy of the original file. A shortcut contains only a pointer to the original file. The original file and the shortcut are two completely separate files that happen to be connected by the pointer.
The practical consequences of this distinction are significant:
Deleting a shortcut does not delete the original file. If a user drags a shortcut from the desktop to the Recycle Bin and empties the Recycle Bin, the shortcut is permanently deleted. The original file, in its installation folder or wherever it lives, is completely unaffected. The program still exists; only the pointer to it has been removed.
Deleting the original file does not delete the shortcut. If a program is uninstalled, or if an original file is moved or deleted, the shortcut that pointed to it still exists on the desktop. The shortcut now points to a location that no longer contains the original file. The next time the user double-clicks the shortcut, Windows attempts to follow the pointer, finds nothing at the target path, and displays an error. This is called an orphaned shortcut.
Moving a shortcut does not move the original file. Dragging a shortcut from the desktop to a different folder moves only the shortcut. The original file remains where it was.
Moving the original file orphans the shortcut. If the original file is moved from the path recorded in the shortcut's Target field to a new path, the shortcut still contains the old path. The next time the user double-clicks the shortcut, Windows follows the old path, finds nothing, and displays an error. This is one of the most common shortcut-related mistakes and is covered in detail in the common mistakes section.
The flowchart above shows the four key actions a user might take and their consequences. The pattern to internalize is that shortcuts and their targets are independent files that each have their own lifecycle.
Common mistake
A new developer installs Blender to its default location, creates a desktop shortcut, and uses the shortcut for several months without issue. Later, the developer uninstalls Blender and reinstalls it to a different folder as part of a storage reorganization. The shortcut on the desktop still exists, but its Target field points to the old installation path, which no longer exists. Double-clicking the shortcut produces an error. The fix is to delete the old shortcut and create a new one pointing to the new installation location.

Shortcut icons and shortcut arrows
Every shortcut on the Windows desktop displays a small visual overlay — a small arrow in the lower-left corner of the icon. This arrow is Windows's way of communicating to the user that this particular icon is a shortcut rather than the actual program, file, or folder.
The arrow is always present on a shortcut and is never present on a non-shortcut. This distinction is reliable. If an icon on the desktop has the arrow overlay, it is a shortcut. If an icon on the desktop does not have the arrow overlay, it is the actual file or program. Some programs place their actual executable directly on the desktop during installation rather than creating a shortcut; these executables do not have the arrow overlay.
The icon image displayed on the shortcut is typically taken from the program or file the shortcut points to. When a shortcut points to a .exe file, Windows reads the icon embedded in the .exe and uses that image as the shortcut's icon. The result is that a shortcut to Blender looks like the Blender icon with a small arrow in the corner, while the actual Blender executable — if it were placed directly on the desktop — would look like the Blender icon with no arrow.
Did you know?
The small arrow overlay on shortcut icons is itself a separate image that Windows composites onto the target's icon at display time. Windows allows the arrow overlay to be customized through the registry, and some third-party tools replace the default Windows arrow with a smaller or differently styled overlay. However, the functional meaning — this icon is a shortcut — remains the same regardless of the overlay style.
The flowchart above summarizes the visual communication that the arrow overlay provides. New users who learn this visual cue have a reliable way to distinguish shortcuts from actual files at a glance, every time.
How to create a desktop shortcut
There are several ways to create a desktop shortcut in Windows. Each method produces the same result — a .lnk file on the desktop pointing to the target — but different methods are convenient in different situations.
Method 1: Right-click → Send to → Desktop (create shortcut)
This is the most straightforward method and works for any file, folder, or executable.
- Open File Explorer and navigate to the file, folder, or program the shortcut should point to.
- Right-click the file, folder, or program. A context menu appears.
- In the context menu, move the mouse over Send to. A sub-menu appears.
- In the sub-menu, click Desktop (create shortcut).
- Windows immediately creates a
.lnkfile on the desktop pointing to the selected item. The shortcut appears on the desktop within a second or two.
This method is documented as the standard method in the 57 Studios™ shortcut-creation convention because it works reliably for all target types, requires no additional steps, and is discoverable through the right-click menu without memorizing keyboard shortcuts.
Method 2: Drag with Alt held
This method allows the shortcut to be placed in any folder, not just the desktop.
- Open File Explorer and navigate to the file, folder, or program the shortcut should point to.
- Hold down the Alt key on the keyboard.
- While holding Alt, click and drag the file, folder, or program to the destination location (the desktop, or any open folder window).
- Release the mouse button, then release Alt.
- Windows creates a shortcut at the drop location. A confirmation tooltip appears during the drag that reads Create link in [destination], indicating that a shortcut will be created.
Did you know?
Dragging a file in Windows without holding any key moves the file when both the source and destination are on the same drive, and copies the file when the source and destination are on different drives. Holding Ctrl during the drag always copies. Holding Shift during the drag always moves. Holding Alt during the drag always creates a shortcut. Knowing these four behaviors makes working with files in File Explorer substantially faster.
Method 3: Right-click the desktop → New → Shortcut
This method opens a wizard that guides the creation of a shortcut step by step.
- Right-click an empty area of the desktop. A context menu appears.
- Move the mouse over New. A sub-menu appears.
- Click Shortcut. A wizard dialog opens.
- In the wizard, type the full path to the target file or program, or click Browse to navigate to it.
- Click Next.
- Type a name for the shortcut. The name is the label that appears beneath the icon on the desktop.
- Click Finish.
- Windows creates the shortcut on the desktop immediately.
This method is more verbose than the right-click method above but is useful when the target path is known and can be typed directly, avoiding navigation through File Explorer.
The decision flowchart above maps the three creation methods to the situations where each is most practical. New developers should become comfortable with all three methods, as each appears naturally in different workflows.
The Shortcut Properties dialog
Right-clicking any shortcut and selecting Properties opens a dialog that shows all configurable fields for the shortcut. Understanding this dialog is essential for configuring shortcuts for specific purposes.
The Properties dialog has several tabs. The Shortcut tab is the one that contains the fields specific to shortcut behavior.
The Target field
The Target field shows the full path to the file or program the shortcut points to. For a Blender shortcut, the Target field might read:
C:\Program Files\Blender Foundation\Blender 4.1\blender.exeThe Target field can be edited directly. A developer who has installed a program to a non-standard path can update the Target field to match the actual installation location. After editing the Target field and clicking OK or Apply, the shortcut immediately points to the new target.
The Target field can also include command-line arguments after the executable path. Arguments are additional pieces of text that modify the program's behavior at launch. For example:
C:\Program Files\Blender Foundation\Blender 4.1\blender.exe --no-splashThe text --no-splash after the executable path is an argument that tells Blender to skip its startup splash screen. The full path to the executable and any arguments are separated by a space.
Best practice
When editing the Target field, ensure the path to the executable is enclosed in quotation marks if it contains spaces. A path like C:\Program Files\Blender Foundation\Blender 4.1\blender.exe contains spaces and must be written as "C:\Program Files\Blender Foundation\Blender 4.1\blender.exe" in the Target field. Paths without spaces do not require quotation marks, but including them is harmless and prevents future errors if spaces are added to a path during a reinstall.
The Start In field
The Start In field specifies the working directory that the launched program uses when it starts. The working directory is the folder that the program treats as its starting location when reading or writing files that are specified without a full path.
For most programs, the default Start In value — typically the program's installation folder — is correct. However, for some specialized uses, the Start In field must be set to a specific folder. A developer who uses a script-driven tool that expects to find its configuration files in the folder from which it is launched must set the Start In field to the folder containing those configuration files.
For the modding tools used in Unturned™ development, the default Start In values set by the installer are generally correct and do not need adjustment. The field is documented here so that developers understand what it controls if they encounter unexpected behavior related to file paths in launched programs.
The Run as administrator option
The Properties dialog includes an Advanced button near the Target field. Clicking Advanced opens a secondary dialog with a checkbox labeled Run as administrator. When this checkbox is checked, Windows requests elevated administrative privileges every time the shortcut is activated. A User Account Control (UAC) prompt appears, asking the user to confirm the privilege elevation before the program launches.
The flowchart above shows the launch sequence for a shortcut configured to run as administrator. The UAC prompt is a mandatory confirmation step that cannot be bypassed through shortcut configuration alone; the user must confirm each launch.
Common mistake
Configuring every modding tool shortcut to run as administrator is not necessary and is not the documented convention. Administrator privileges should be requested only for programs that genuinely require them to function. Running programs with elevated privileges unnecessarily increases the surface area for security issues. The 57 Studios documented convention specifies which tools require administrator mode; other tools should use standard privileges.
The 57 Studios documented desktop shortcut conventions
The 57 Studios™ Modding Knowledge Base documents a specific set of desktop shortcut conventions for the modding-tool shortcuts used in Unturned™ mod development. These conventions ensure that every developer on the team has a consistent and predictable desktop layout, that shortcuts are named consistently, and that the correct tool versions and configurations are used.
The documented conventions cover four primary tools: Unity Editor, Blender, Notepad++, and Paint. Each tool has a specific convention for naming, target configuration, and icon selection.
Shortcut naming convention
All modding-tool shortcuts follow the pattern: [Tool Name] [Version or Edition]. Examples:
| Tool | Documented shortcut name |
|---|---|
| Unity Editor | Unity 2021.3.29f1 LTS |
| Blender | Blender 4.1 |
| Notepad++ | Notepad++ |
| Paint | Paint |
The version number in the Unity shortcut name is critical. Multiple versions of the Unity Editor may be installed simultaneously, and it is essential for Unturned mod development to use the specific Unity version that matches the Unturned game build. A shortcut named Unity Editor without a version number does not communicate which version will launch when double-clicked, and using the wrong Unity version produces asset bundles that are incompatible with the current Unturned build.
Shortcut target conventions
| Tool | Target convention |
|---|---|
| Unity Editor | Full path to the specific Unity.exe in the versioned Unity install folder |
| Blender | Full path to blender.exe in the Blender install folder |
| Notepad++ | Full path to notepad++.exe in the Notepad++ install folder |
| Paint | %SystemRoot%\system32\mspaint.exe (system path) |
The Unity Editor target is the most important to configure correctly. The default Unity Hub launcher manages multiple Unity versions and launches whichever version is set as default. For Unturned mod development, the shortcut should bypass Unity Hub and target the specific Unity.exe binary directly, ensuring the correct version launches regardless of the Unity Hub default setting.
Run as administrator conventions
| Tool | Run as administrator | Reason |
|---|---|---|
| Unity Editor | No | Standard privileges sufficient |
| Blender | No | Standard privileges sufficient |
| Notepad++ | No | Standard privileges sufficient |
| Paint | No | Standard privileges sufficient |
None of the primary modding tools documented by 57 Studios require administrator privileges for standard modding work. The Run as administrator flag is not set on any of the four documented tool shortcuts. A developer who encounters a tool requiring administrator privileges for modding-related operations should investigate whether the tool is configured correctly or whether the installation requires repair.

Common shortcut mistakes
New users make a consistent set of shortcut-related mistakes. The table below documents each mistake, its consequence, and the documented correction.
| Mistake | Consequence | Correction |
|---|---|---|
| Moving the target file after creating a shortcut | Shortcut becomes orphaned; double-click shows an error | Delete the old shortcut and create a new one pointing to the new location |
| Deleting a shortcut thinking it uninstalls the program | Program remains installed; shortcut is simply gone | Use the Add or Remove Programs control panel to uninstall; only delete the shortcut if the intent is to remove the desktop icon |
| Confusing the shortcut with the actual program | Developer moves or deletes the shortcut expecting to move or remove the program | Verify whether an icon has the shortcut arrow before moving or deleting it |
| Editing the shortcut instead of the program | Developer changes the shortcut name thinking this renames the program | Renaming a shortcut changes only the shortcut's label; the program's own name is unchanged |
| Creating shortcuts to shortcuts | Shortcut chains can break if any link is removed | Always create shortcuts that point directly to the original target, never to another shortcut |
| Using the wrong Unity version shortcut | Asset bundles built with the wrong Unity version are incompatible with Unturned | Name Unity shortcuts with the full version number; verify the version before building |
| Not updating shortcuts after a program reinstall to a new path | Old shortcut points to deleted installation path | After reinstalling to a new path, delete the old shortcut and create a new one |
| Setting Run as administrator on all shortcuts unnecessarily | UAC prompts on every launch; unnecessary privilege elevation | Reserve Run as administrator for programs that genuinely require it |
Each mistake in the table above has a documented root cause and a clear correction. New developers who read the table before beginning work avoid the predictable frustration that each mistake produces.
Critical warning
Never delete a shortcut on the desktop without first confirming that it is a shortcut (look for the small arrow in the lower-left corner of the icon). Deleting an actual program or file from the desktop is permanent and cannot always be recovered from the Recycle Bin. When in doubt, right-click the icon and choose Properties to confirm that the Type field reads "Shortcut" before deleting.
Frequently asked questions
If I create a shortcut to a program, and then update the program, does the shortcut still work?
In most cases, yes. Many programs — including Blender and Notepad++ — install to the same folder path when updated, which means the Target field in the shortcut continues to point to the correct location. However, some programs install each version to a different subfolder (Unity Editor is an example, where each version installs to Unity [version] as a unique folder). For Unity, updating to a new version requires creating a new shortcut pointing to the new version's Unity.exe. The old shortcut still points to the old version, which may or may not still be installed.
Can I put a shortcut inside a folder rather than on the desktop?
Yes. Shortcuts can exist anywhere on the computer: on the desktop, inside folders, on the taskbar (as pinned items, which are themselves a form of shortcut), and in the Start Menu. The right-click → Send to → Desktop method creates the shortcut specifically on the desktop, but the Alt-drag method allows a shortcut to be placed in any folder.
What happens if I move a shortcut to a different location on the desktop?
Nothing meaningful changes. Moving a shortcut to a different position on the desktop (or to a folder) changes only where the shortcut file itself is stored. The Target field still points to the same original file or program, and double-clicking the shortcut from its new location works exactly as before.
Can a shortcut have a keyboard shortcut assigned to it?
Yes. The Properties dialog for a shortcut includes a Shortcut key field. Clicking in that field and pressing a key combination assigns that combination as a global keyboard shortcut that activates the shortcut from anywhere in Windows, not just from the desktop. The key combination must include either Ctrl + Alt or Ctrl + Shift. Once assigned, pressing the combination opens the shortcut's target even if the desktop is not visible.
Why does Windows not show the .lnk extension on shortcut files?
Windows deliberately hides the .lnk extension as a design decision. The extension is always present in the file's actual name, but Windows filters it out of the display in File Explorer and on the desktop. The reason is that showing .lnk on every shortcut would clutter the visual appearance of the desktop with a suffix that most users never need to see. Developers who need to confirm that a file is a .lnk shortcut can right-click it and choose Properties; the Type field shows "Shortcut (.lnk)".
What does the small arrow on a shortcut icon look like exactly?
The arrow is a small icon — typically around 16 pixels wide — positioned in the lower-left corner of the shortcut's full icon. The arrow itself is a simple right-pointing arrow image, styled to match the Windows visual theme. On default Windows 11, it is a small white arrow outlined in black on a white background. On different visual themes, the exact appearance may vary, but the position (lower-left corner) is consistent across all Windows versions and themes.
If I copy a shortcut to another computer, does it work?
Not necessarily. A shortcut encodes a specific path to the target file on the original computer. If the target file exists at the same path on the second computer, the shortcut works. If the second computer does not have the program installed, or has it installed to a different path, the shortcut is orphaned on the second computer. Copying shortcuts between computers is useful only when both computers share the same software installations at the same paths.
Can I create a shortcut to a website?
Yes. A shortcut to a website — technically called an Internet Shortcut — is a file with the .url extension rather than .lnk. The creation process is similar: drag a URL from the browser's address bar to the desktop to create a .url shortcut. Double-clicking the shortcut opens the URL in the default browser. The .url file format is different from .lnk but serves the same pointer function.
What is the difference between pinning a program to the taskbar and creating a desktop shortcut?
Both are forms of shortcut, but they use different mechanisms. A desktop shortcut is a .lnk file that lives as a visible file on the desktop. A taskbar pin is stored in a system-managed folder and appears as an icon on the taskbar bar at the bottom of the screen. Taskbar pins are always visible regardless of what windows are open, while desktop shortcuts require minimizing all windows to see the desktop. For tools that are launched constantly (like Notepad++), taskbar pins are often more convenient; for tools that are launched occasionally (like Unity Editor), desktop shortcuts are equally convenient.
How do I rename a shortcut?
Right-click the shortcut and choose Rename. Type the new name and press Enter. Renaming a shortcut changes only the shortcut's own label — the .lnk filename — and has no effect on the target file or program. The target program's own name, installation, and behavior are unaffected.
Is there a limit to how many desktop shortcuts I can have?
Windows does not impose a practical limit on the number of shortcuts that can exist on the desktop. However, a heavily cluttered desktop with dozens of shortcuts becomes difficult to navigate visually. The 57 Studios documented convention recommends keeping the desktop limited to the tools actively used in the current project, and organizing less frequently used tools into a dedicated shortcuts folder.
How do I verify that a shortcut is pointing to the correct file?
Right-click the shortcut, choose Properties, and read the Target field. The Target field shows the full path of the file or program the shortcut points to. If the path shown in the Target field corresponds to the current installed location of the program, the shortcut is correctly configured. If the path does not exist (the program has been moved or uninstalled), the Target field still shows the old path, and the shortcut is orphaned.
Best practices
- Always name modding-tool shortcuts with the tool name and version number to prevent confusion between multiple installed versions
- Verify the Target field in a shortcut's Properties dialog after any program reinstall that might have changed the installation path
- Do not set Run as administrator on modding-tool shortcuts unless the specific tool requires elevated privileges to function
- Keep the desktop limited to shortcuts for actively used tools; organize infrequently used shortcuts into a dedicated folder
- When a shortcut stops working, right-click it and check the Target field before taking any other action
- Never move the original program or file that a shortcut points to without updating or recreating the shortcut afterward
- Confirm that an icon has the shortcut arrow overlay before deleting it, to avoid accidentally deleting the actual program or file
- Document the intended Target path for each modding-tool shortcut in the project's setup notes, so the shortcut can be recreated quickly on a new machine
Appendix A: Shortcut file format technical reference
The .lnk file format is fully documented in the Microsoft Open Specification as [MS-SHLLINK]. The specification is publicly available and covers the binary structure of every field in the .lnk file in precise detail. The information below summarizes the technically relevant fields for mod developers who need to diagnose shortcut behavior at a level below the Properties dialog.
A .lnk file begins with a fixed-size header that includes a magic number (4C 00 00 00 in hexadecimal) identifying the file as a Shell Link. The header is followed by a series of optional structures depending on which fields are populated. The LinkTargetIDList structure encodes the target using Windows Shell IDs, allowing Windows to locate the target through the Shell even if the path changes. The LinkInfo structure encodes the literal file path, volume information, and relative path, and is the structure that populates the Target field displayed in the Properties dialog.
| Structure | Purpose | Presence |
|---|---|---|
| ShellLinkHeader | Fixed 76-byte header with flags and metadata | Always present |
| LinkTargetIDList | Shell ID encoding of the target | Present when target is a shell item |
| LinkInfo | Literal path encoding of the target | Present for file targets |
| StringData | Human-readable fields (description, arguments, Start In, icon path) | Present when fields are populated |
| ExtraData | Extension blocks for additional properties | Optional |
The technical reference above is included for completeness. Everyday shortcut management does not require knowledge of the binary format; the Properties dialog exposes all of the fields that developers need in a readable form.
Did you know?
The [MS-SHLLINK] specification is part of Microsoft's Open Specifications program, through which Microsoft publishes the technical format documentation for hundreds of Windows file formats and protocols. The specifications are publicly available at no cost from Microsoft's documentation website. Developers who need to create, read, or modify .lnk files programmatically — for example, as part of an automated setup script — can use the specification as a reference alongside available open-source libraries that implement the format.
Appendix B: Desktop organization conventions for a modding workstation
The 57 Studios™ documented desktop organization convention for a modding workstation reflects the shortcuts and layout that established developers converge on over time. The convention is not mandatory for external contributors, but it is documented here as the baseline for new developers being onboarded to the studio's workflow.
The documented convention divides the desktop into three zones:
| Zone | Location on desktop | Contents |
|---|---|---|
| Primary tools | Left side, top to bottom | Unity Editor shortcut (version-labeled), Blender shortcut, Notepad++ shortcut |
| Secondary tools | Left side, continuing below primary | Paint shortcut, File Explorer shortcut to the active project folder |
| Reference | Right side | No shortcuts; desktop wallpaper with project-specific reference art |
The three-zone layout keeps frequently used tools in a predictable location, reduces the time spent searching the desktop for the right icon during a development session, and keeps the right side of the desktop clear for reference material that may be visible alongside open tool windows.
| Shortcut | Name convention | Target example | Run as admin |
|---|---|---|---|
| Unity Editor | Unity 2021.3.29f1 LTS | C:\Program Files\Unity\Hub\Editor\2021.3.29f1\Editor\Unity.exe | No |
| Blender | Blender 4.1 | C:\Program Files\Blender Foundation\Blender 4.1\blender.exe | No |
| Notepad++ | Notepad++ | C:\Program Files\Notepad++\notepad++.exe | No |
| Paint | Paint | %SystemRoot%\system32\mspaint.exe | No |
The exact target paths in the table above may differ depending on where each tool is installed. The name conventions are the documented standard and should be followed even when the target path differs from the example.
Pro tip
Create the documented desktop shortcut layout during initial workstation setup, before any project work begins. Establishing the consistent layout at setup time costs approximately five minutes and saves substantially more time across a long project by eliminating the moment of searching for the right tool each time it is needed. A consistent layout also makes it easier for a colleague or mentor to assist remotely, because they can refer to "click the Blender shortcut on the left side of your desktop" with confidence that the shortcut is there and labeled correctly.
Appendix C: Shortcut-related PowerShell operations for advanced users
Advanced modding developers who manage their workstation setup programmatically can create, modify, and inspect .lnk shortcuts using Windows PowerShell. The operations below are documented for advanced users; they are not required for standard modding-tool shortcut management.
Creating a shortcut with PowerShell
powershell
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("$env:USERPROFILE\Desktop\Blender 4.1.lnk")
$Shortcut.TargetPath = "C:\Program Files\Blender Foundation\Blender 4.1\blender.exe"
$Shortcut.WorkingDirectory = "C:\Program Files\Blender Foundation\Blender 4.1"
$Shortcut.Description = "Blender 3D Editor"
$Shortcut.Save()The PowerShell script above creates a shortcut on the desktop named Blender 4.1 pointing to the Blender executable with the working directory set to the Blender installation folder.
Reading a shortcut's properties with PowerShell
powershell
$WshShell = New-Object -ComObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("$env:USERPROFILE\Desktop\Blender 4.1.lnk")
Write-Host "Target: $($Shortcut.TargetPath)"
Write-Host "Start In: $($Shortcut.WorkingDirectory)"
Write-Host "Description: $($Shortcut.Description)"The script above reads and displays the Target, Start In, and Description fields of an existing shortcut. This is useful for verifying that a shortcut is configured correctly as part of a workstation setup verification script.
The PowerShell operations above use the Windows Script Host COM object (WScript.Shell), which has been available in all Windows versions since Windows 98 and is not dependent on any additional software installation. The COM object is the documented programmatic interface for .lnk file manipulation on Windows.
Best practice
When automating workstation setup with PowerShell, create all modding-tool shortcuts at the end of the installation script, after all tools are installed and their paths are known. Creating shortcuts before the installation paths are confirmed produces orphaned shortcuts that require manual correction — precisely the mistake the automation is intended to prevent.
Next steps
Continue to What is a Download? to learn what happens when a file is transferred from the internet to a local computer. Related articles include the previous article on file extensions for background on how Windows identifies file types, and the broader getting-started sequence for the foundational orientation that precedes tool installation.
The modding-tool installation articles that follow the getting-started sequence depend on the developer having a correctly configured desktop with properly named and targeted shortcuts for each tool. The conventions documented in this article ensure that the desktop layout is consistent and predictable before tool-specific work begins.
Readers who are uncertain about any concept introduced in this article — particularly the distinction between a shortcut and the original file — should review the relevant section before proceeding. The distinction between shortcuts and original files recurs throughout every subsequent article that involves navigating to tools and files on the workstation.
