Manchmal ist es ganz praktisch, wenn man schnell eine Verknüpfung von einem Programm benötigt, öffnet man das Startmenü -> Alle und zieht die Verknüpfung aus dem Startmenü auf den Desktop. Dann kann man im Reiter Verknüpfung bspw. unter „Ziel:“ schnell mal einen Parameter anhängen.
Das ist gerade interessant, wenn beispielsweise beim Edge Canary neue Funktionen getestet werden, die nur über neue Parameter funktionieren. Ein Versuch in der Windows 11 25H2 (26200 derzeit Dev) bringt aber eine ganz andere Verknüpfung auf den Desktop. Weder „Ziel:“ noch „Ausführen in“ kann geändert werden (siehe Bild).
Die Vermutung liegt nahe, dass es an der Änderung des Startmenüs liegt. Denn in der Canary, Dev und auch Beta (welche ja noch die Windows 11 24H2 ist), habe ich schon das neue Startmenü.
Wer also weiterhin eine Verknüpfung auf dem Desktop benötigt, muss diese also von der Programm.exe erstellen, oder die Verknüpfung aus dem üblichen Ordner
C:\Users\Dein Name\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
herauskopiert werden. Mit einem lokalen Konto konnte ich das jetzt nicht nachprüfen und auch den Speicherort dieser neuen Verknüpfung konnte ich nicht aufspüren. Außer in der Registry ist dieser Name „verewigt“ unter
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\CloudStore\Store\DefaultAccount\Current
Windows 11 Tutorials und Hilfe
- In unserem Windows 11 Wiki findet ihr sehr viele hilfreiche Tipps und Tricks.
- Falls ihr Fragen habt, dann stellt diese ganz einfach bei uns im Forum.
- Installationsmedien: Aktuelle Windows 11 ISOs findet ihr hier: 23H2 22631, oder 24H2 26100. Ansonsten immer in der rechten Sidebar.
- Windows 11 neu clean installieren Tipps und Tricks.
- Windows 11 auch ohne TPM und Secure Boot installieren.
- Windows 11 mit lokalem Konto auch Offline installieren.
- Windows 11 Inplace Upgrade Reparatur oder Feature Update.
- Automatisch anmelden Pin entfernen Windows 11.
- Alle Beiträge zu Windows 11 im Blog findet ihr über diese Seite. Wobei auch alle anderen Artikel interessant sein können.
für die Leute die ex copy-pasten wollen:
%APPDATA%\Microsoft\Windows\Start Menu\Programs
öffnet dann
shell:startup
zukünftig auch die reg?
Das eine hat mit dem anderen nichts zu tun.
Hallo MoinMoin,
.
einer deiner Sätze beginnt so: „Mit einem lokalen Konto konnte ich das jetzt nicht nachprüfen“.
.
Durch den Satzbau folgere ich, dass du kein lokales Konto für eine Prüfung zur Verfügung hattest. Ich hab es versucht und komme auf keine andere Bedeutung als diese.
.
Oder wolltest du die Aussage treffen, dass unter Verwendung eines lokalen Kontos das beschriebene Verhalten nicht festgestellt wurde?
.
Keine Ahnung was Du wirklich berichten wolltest. Aber für den letzteren Sinn müsste es wohl etwas anders geschrieben werden.
.
Kannst Du es präzisieren?
Danke
…dass du kein lokales Konto für eine Prüfung zur Verfügung hattest.
Richtig
Schätze da hast Du recht @moinmoin (Jürgen),
Du bist ja mit einem MS-Konto unterwegs.
Diesen Registry-Eintrag finde ich nämlich auch bei mir.
MS verlagert da Vieles in die Cloud!
Naja, das Startmenü scheint immer noch ‚reg-zentriert‘. Thema Ordnerumleitung… Wenn ich ein ‚Image‘ für das Ausrollen vorbereite, versuche ich ALLE Ordner im entsprechenden regzweig _vorab_ so hinzubiegen, das sie zentral ‚verwaltet‘ – quasi auf einem Server liegen – werden können. (Und teste es in einer VM – nicht Broadcom
Darunter auch die vom Startmenü, respektive ff. reg-Zweige:
Computer\HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
Computer\HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
(hier Network/Local-Instance), generell aber auch
Computer\HKEY_USERS\SID\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders…
Und das wirklich bei Allen SID! – inklusive Import/Export von diversen „DEFAULT“-Profilen.
Es verspricht mit Sicherheit viel Tipp-Arbeit
Aber es lohnt sich – ganz ohne Cloud. Wichtig ist, das bei verschiedenen ‚Probeläufen‘ – quasi Login via MS ‚Default-User‘ (= SYSTEM-User) – alle Startmenü-Einträge reibungslos! funktionieren. Das ist im Prinzip auch mein täglich Brot, um festzustellen, ob MS Windows (gebeugt sei Dir, oh Herr, Bill Gates :), wirklich stabil – hier in Sachen Startmenü/Taskleiste – läuft. Also, ich kann erst mal nicht mekkern, aber es war wirklich einfacher, als ich das Startmenu/Taskleiste einfach nur via XML verteilen konnte… ;-). Für Fragen fast jederzeit offen. Aber viellleicht zur Orientierung: In allen HKREF\SID\..\Explorer verweisen die entsprechenden Ordner auf ‚meine‘ Ordner und nicht nicht ins Weltall. Zugegeben, etwas Erde-Zentriert… Jute Nacht 
Bei mir hat sich das Verhalten beim Kopieren von .lnk Dateien
%APPDATA%\Microsoft\Windows\Start Menu\Programs
z. B. von Startmenü Alle nach Desktop durch Drag & Drop nicht verändert.
Aber die Dateien aus den Unterordnern werden im Startmenü unter Alle überhaupt nicht mehr aufgelistet.
Kopiert man den Link aus dem Unterordner aber in Programs hoch funktioniert wieder alles wie zuvor.
Für ein paar eigene Programme hat Microsoft dafür anscheinend irgendwo anders neue Links auf GUIDs in Registry oder direkt im Store für Startmenü Alle angelegt. Für viele andere und die anderer Firmen dagegen nicht.
Also die Änderung ist das man die Verknüpfung nicht mehr anpassen kann aber die Verknüpfung selbst funktioniert weiterhin. Okay etwas das ich nie genutzt habe geht dann nicht mehr.
Diese Änderung ergibt so gar keinen Sinn. Wer denkt sich solchen Unfug aus? Ich meine, da muss ja jemand nachgedacht und gesagt haben, dass das jetzt so gemacht wird, weil… Auf die Begründung bin ich gespannt.
Das ist ja nix neues, an so was konnte/musste man sich doch jahrelang gewöhnen. Die verpassen es einfach, ein Betriebssystem auf den Markt zu bringen, welches vom Benutzer (wenigstens in der optischen Darstellung) nett angepasst werden kann.
Ich muss heut etwas ändern für den User negativ, damit ich es in ein paar Jahren wieder zurück ändere und es dem Nutzer als NEUHEIT wieder verkaufen kann 🤣
Wir reden von MS, da ist „Sinn“ eine gänzlich andere Dimension…. 🤣
gepostet mit der Deskmodder.de-App für Android
Das ist nichts neues.
Solche Verknüpfungen gab es z.B. schon unter Windows 7 bei Microsoft Office 2010 und anderen Microsoft-Programmen.
Da waren die Parameter der Verknüpfung auch nicht änderbar.
Ich glaub die Änderung hat etwas damit zu tun, ob die Windows Einstellungen (also auch die Verknüpfungen im Startmenü) mit der Cloud Synchronisiert werden oder nicht. Wer also über ein MS Konto verbunden ist, da werden wohl die Verknüpfungen in der Cloud mit sitzen. Ob gewollt oder für eine Zukunftsfunktion – wer weiß.
Kann mir auch vorstellen, dass MS als „Sicherung in der Cloud“ bezeichnet, selbst dadurch aber schnell auswerten kann (durch die Verknüpfungen) was die User so verwenden, an Programme, Funktionen etc.
Heut ist doch die neue und Wertvollste Währung, „Daten von Usern“
also bei mier nix neues
in welcher windows Build soll es denn sein ?
Es gibt schon seit zig Jahren zwei „LNK“ Verknüpfungstypen in Windows. Zum einen die klassischen Verknüpfungen die man selbst anlegt und die auch von vielen Installern angelegt werden und zum anderen diejenigen, die von MSI Installationsdateien angelegt werden.
Bei letzteren wird nicht etwa auf ein Programm in einem bestimmten Pfad verwiesen, sondern auf einen GUID. In der Registry ist unter diese GUID der Pfad zum Programm eingetragen, wird dort ausgelesen und dann gestartet. Selbst der Pfad zum Icon des Programms zeigt nicht mehr auf die *.exe Datei sondern auf einen GUID Pfad unter dem das Icon abgelegt wurde. Dass man solche Verknüpfungen nicht um zusätzliche Argumente erweitern kann war schon immer so.
Darum, dass es schon „immer so war“ geht es nicht. Sondern, dass Microsoft genau das im Startmenü geändert hat.
Was wurde geändert?
Wenn du auf Windows 11 24H2 (und auch 23H2, 22H2, Windows 10, …) eine GUID Verknüpfung vom Startmenü auf den Desktop ziehst (egal ob „Verschieben“, „Kopieren“ oder „Verknüpfung erstellen“), dann wird sie danach immer noch „nicht änderbar“ sein. Das war schon immer so und hat nichts mit irgendeiner neuen Beta zu tun.
Der unterschied ist eigentlich ziemlich einfach…jetzt werden alle Verknüpfungen die ich vom Startmenü ziehe zu unveränderbaren Verknüpfungen…selbst wenn die Verknüpfung im Startmenü ordner nicht so eine Verknüpfung ist…das wird im Artikel alles erklärt…
Das was im Artikel steht stimmt einfach nicht, darum geht es ja. Ich habe es gerade mit Build 26200 und 27913 getestet:
– „Explorer“ und „Terminal“ aus dem Startmenü auf den Desktop gezogen = nicht editierbar (sind aber auch im Startmenü schon nicht editierbar)
– „Microsoft Edge“ und „OneDrive“ aus dem Startmenü auf den Desktop gezogen = weiterhin editierbar (und auch im Startmenü sind sie schon editierbar)
Das Verhalten ist also identisch zu vorher. Daher die Frage: Was wurde geändert?
Nur mal rein interessehalber, wie editierst du Verknüpfungen direkt im Startmenü?
Und wenn du schon testest, dann mit der 26100 und 26200 oder Canary. Dann wird dir der Unterschied, wie im Beitrag auffallen.
Den Edge hab ich in der 26200 auch einmal probiert. Nicht editierbar. Hast du noch das „alte“ Startmenü? Das würde es (wie schon im Text vermutet) erklären.
Meine Vermutung liegt oder lag eigentlich bei „exe“ vs. „App/appx“
.
Auf dem Bild vermute ich eine
Verknüpfung zu einem klassischen Programm mit exe, egal ob installiert oder portable
und
den Aufruf einer App/appx,
was auch den Zielnamen OperaSoftware.OperaWebBrowser.1750263 erklären würde. Zumindest kenne ich diese durch Punkte getrennten Namen nur von den App-appx-Paketen und nicht von Programmen als exe.
.
In Regedit dürfte dann jetzt ein als App gehandhabtes Programm dann wohl auch mit diesem Punkt-Namen an einer der für Apps üblichen Stellen auftauchen?
Wie z.B. unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Applications
.
Das Foto zeigt meiner Meinung nach den Unterschied in der Handhabung zw. den leichter manuell steuerbaren Programmen (exe) und den reduziert beherschbaren Apps, die als Appx-Paket kommen.
.
Wie am Anfang benannt ist das mein Vermutung … man müsste nach der von MoinMoin festgestellten Änderung eine neue herkömmliche Programminstallation durchführen und sich dann deren erstellte Verknüpfungen im Startmenü ansehen. Wenn Windows künftig tatsächlich ein per Setup installiertes Programm wie eine App handhabt und sich das entsprechend zurecht biegt, wäre das in der Tat ein Novum.
Beide Opera-Versionen sind Programminstallationen, keine Apps.
Um es kurz zu machen, höchst wahrscheinlich: Eine Verknüpfung der Verknüpfung der Verknüpfung der… usw. wo dann irgendwo auch selbst das ‚Original‘ verloren…
Ich habe mir angewöhnt: „exe-Files „Als Pfad kopieren“ (danke MS), also ‚direkt‘ zu hinterlegen. Aber zwei Fragen (an „Microsoftianer“ ;): 1. Was haben Versions-abhängige Install-Ordner (msedge usw.) im produktiven Bereich verloren? Bei Programmierung, Versions-control usw. kein Problem. Aber im produktiven Bereich? 2. Es gibt unter MS Windows mindestens 102+verschiedene verlink-Typen. Warum? Die ‚Einfachsten‘, via mklink /?, kann ich ja gerade so noch nachvollziehen. Aber die anderen 98… Vielleicht klärt mich mal jemand auf. Danke. OE. PS.: Ich bereinige/kontrolliere fast täglich via taskschd.msc verschiedene Einträge. Erst kürzlich, bei einem „Versions-Sprung“ von Google Chrome (leider auch bei FF u.a.) mehrere fehlerhafte (versions-abhängige) Einträge gefunden – naja, diese ‚Dinger‘ ’starten‘ quasi bei „Anmeldung des Users“ und „wiederholen Dies ‚Alle Stunde UND jeden Tag’…“ Bringt endlich diesen Unsinn…. Zurück zum Thema: fehlerhafte Verknüpfungen (auch bei CSLID u.a. registry!) ein überschaubares Niveau…? Nur so’ne Idee!-) Gibt es ‚Hilfsmittel‘, um ‚CSLID-Abhängigkeiten‘ aufzulösen? Wie macht Ihr/seht Ihr da noch durch?