[English]Kleiner Schlenker ins Microsoft Software-Land. Einem Nutzer ist aufgefallen, dass die Dateigröße des Sysinternals RDCMan 3.1 extrem angestiegen ist. Kamen 2.9x-Versionen noch mit schlanken Größen von weniger als 3 Megabyte daher, wird mir das Tool in der Version 3.1 mit einer Download-Größe von über 100 Megabyte angezeigt. Kleiner Blick auf den Sachverhalt und warum die Programmdateien immer fetter werden.
Was macht RDCMan?
Zuerst ein kurzer Sprung, der beleuchtet, was sich hinter RDCMan aus den Sysinternals-Tools verbirgt. Sysinternals wurde ja von Mark Russinovich, damals Gründer von Winternals, 1996 ins Leben gerufen, um dort eine Sammlung kleiner, aber nützlicher Tools – bevorzugt für Windows – kostenlos bereitzustellen. Inzwischen ist Russinovich Microsoft Mitarbeiter (Technischer Direktor von Microsoft Azure), Winternals wurde ja 2006 von Microsoft gekauft.
Beim Tool RDCMan handelt es sich um einen Remotedesktopverbindungs-Manager, der mehrere Remotedesktopverbindungen verwalten kann. Die von diesem Tool unterstützten Features lassen sich hier nachschlagen.
Inflation der Programm-Dateigröße
"Hyperinflation" bei Microsoft Software. Dass Office-Apps für Mobilfunkgeräte schon mal mehrere hundert Megabyte fett sind und die Update-Downloads dann zuschlagen ist längst bekannt. Ich habe daher vor vielen Jahren die ganzen Microsoft Office-Apps für Word, Excel etc., die ich für Tests auf meinem Android Smartphone installiert hatte, rigoros deinstalliert.
Nun hat mich Blog-Leser Tobias die Woche in einem Tweet auf einen besonderen Fall hingewiesen. Er schrieb mir, dass der RDCMan in der älteren Version 2.93 mit weniger als 3 Megabyte bei der Dateigröße auskomme. Aber bei der neuen Version 3.1 wäre die Datei bereit 65 Megabyte groß.
Ich habe dann gleich mal auf der Sysinternals-Webseite nachgeschaut, der Remotedesktopverbindungs-Manager v3.1 (RDCMan) wurde zum 5. Mai 2025 aktualisiert und schlägt mit einer Download-Größe von 116,1 Megabyte zu Buche.
An dieser Stelle haben ich dann schon geschluckt. Tobias fragte sich, ob die modernen Compiler inzwischen den Code derart aufblähen und verwarf dies als unrealistisch. Mir ging kurz "kann es sein, dass da funktional so viel dazu gekommen ist", durch den Kopf. Hielt ich auch nicht für realistisch. Damit blieb eigentlich nur noch, dass da irgend ein Framework angeklebt und mit ausgeliefert wurde.
.NET 8.x-Laufzeitumgebung mit im Paket
Albacore hat Tobias auf x.com auf seine obige Frage, was die Größe der .exe-Datei so aufbläht, dann mit einer Erklärung geantwortet. Die neuen 3.x-Versionen des Remotedesktopverbindungs-Managers (RDCMan) wurden auf auf .NET 8 migriert. Und nun wird das .NET 8-Framework jetzt gebündelt und in der Anwendung mit ausgeliefert. Ob das der Stein der Weisen ist?
MVP: 2013 – 2016
Wow, andere schreiben sicherheitskritische Komponenten neu – in Rust.
Wenn schon .net: Andere Installer laden sich bei Bedarf die passende Version aus dem Netz nach. Aber halt bei Bedarf.
Was ist an RDCMan denn sicherheitskritisch? Und ich glaube, die Portierung auf .net 8 dürfte weitaus einfacher und schneller gewesen sein, als alles in Rust neu zu erfinden.
Versteh mich nicht falsch, aber .net hat durchaus seine Darseinsberechtigung, auch wenn du die Sprache jetzt vielleicht jetzt nicht so geil findest.
Ist halt wie bei Java, du brauchst eben die Runtime damit das läuft. Und das ist auch ok so. Meistens ist das Problem die endliche Resource "Zeit". Ist halt ein Unterschied, ob ich 20 Arbeitstage brauche um das in .net zu migrieren oder 200 um das in Rust so "halbneu" zu erstellen.
Wild an den Haaren herbeigezogen natürlich, aber du weist auf was ich hinaus will. Auch wenn die andere Lösung besser ist von der Technik, heisst das noch lange nicht, dass es auch die logisch bessere Lösung ist :D
tja meine Damen und Herren, das passiert wenn man seit Jahrzehnten allen möglichen Scheiß macht aber sein System nicht mit einem ordentlichen Paketmanager ausstattet. Die Entscheidung das Redist von .NET beizupacken erscheint logisch und verständlich, in Konsequenz jedoch ist es saudumm und offenbart für mich, wie grundlegende Funktionen eines Betriebssystems keine Priorität haben, die letzten CandyCrush Versionen aber in Startmenüs schon.
alle Microsoft Produkte werden nur noch zum Ressourcenfresser. Wir haben hardwaretechnisch Leistung ohne Ende, aber MS verkackt es immer wieder.
Win-Startmenü sorgt für CPU Peaks, Explorer friert in Netzlaufwerken fest, Officeanwendungen öffnen in Schneckentempo…
Wir brauchen ein ressourcenschonendes, leicht zu bedienendes Betriebssystem und was wir bekommen ist ein mit Tracking und Werbung verseuchte Oberfläche die pausenlos zu Mutti telefoniert…
Wir sind Sklaven und es wird Zeit zu rebellieren und dem Anbieter den Finger zu zeigen! (klingt leider leichter als getan)
> Wir brauchen ein ressourcenschonendes, leicht zu bedienendes Betriebssystem und was wir bekommen ist ein mit Tracking und Werbung verseuchte Oberfläche die pausenlos zu Mutti telefoniert…
Das gesuchte System existiert seit Jahrzehnten… GNU/Linux. Meine Empfehlung Debian, weil kommerziele Anbieter und Distris (Bsp: Ubuntu) zwangsläufig wie Microsoft in Interessenskonflikte geraten und in der Regel gegen Anwender/Community entscheiden.
Ressourcenschonend? Leider nur noch in der Theorie
Man könnte meinen, Linux sei der Retter in Sachen Effizienz – doch auch dort ist längst nicht alles gold, was glänzt. Selbst im Open-Source-Lager wird inzwischen hier und da unnötig aufgebläht. Zugegeben, nicht so eklatant wie bei Microsoft, aber eben doch spürbar.
Wer wissen will, was wirklich ressourcenschonende Programmierung bedeutet, sollte einen Blick in die Demoszene werfen. Dort wurde mit begrenztem Speicher, winzigen Dateigrößen und krudem Hardwarezugang Großartiges geschaffen. Code, der mit wenigen Kilobyte auskam – heute kaum noch vorstellbar.
Ressourcenschonung war einmal ein essenzieller Aspekt der Programmierung. Spätestens mit der Einführung von Festplatten und CDs in den 80ern und 90ern war plötzlich Platz im Überfluss vorhanden – und mit ihm kam die Verschwendung. Seither scheint sich kaum jemand noch ernsthaft um Effizienz zu kümmern.
Als jemand er selbst ein 4k und 2k Demo geschrieben hat.. das ganze ist ja nett. Aber hat keinen praktischen Nutzen. Es ist mehr wie ein Knobeln.. oder Heutzutage, wie kann ich meine PV Anlage und Speicher so optimieren, keinen Strom vom Netzerzeuger zu brauchen. Jedem seine Spielwiese.
das .NET mit auszuliefern, ist nur ein Wink mit dem Zaunpfahl, dass Microsoft Windows weiter umbaut. Weniger Win32 API, mehr Apps.
Das ganze Win32/ActiveX/COM/COM+ Zeugs hat sich einfach nicht bewährt. Es schafft Schnittstellen und Abhängigkeiten die schwer zu verstehen und zu warten sind.
Dem schließe ich mich an. Ich selbst programmiere hier und da ein paar Kleinigkeiten und bin immer wieder erstaunt, was ein bisschen Optimierung so tun kann. Eine per VBA gebastelte Formel, die in Excel 1 Millionen Zeilen nach mehreren Kriterien in mehreren Spalten durchsucht, kann mehrere Minuten oder unter 10 Sekunden benötigen. Je nachdem, wie man die optimiert oder nicht optimiert.
Demoszene .. hach das waren noch Zeiten :-)
Du solltest da wirklich stark unterscheiden. Ja, damals waren die Resourcen knapper und daher musste man mehr darauf achten, aber da wurde auch noch Hardwarenah programmiert mit VIEL weniger Features und Möglichkeiten.
Das kannst du UNMÖGLICH mit heute vergleichen. Vor allem sind ja auch die Systeme viel komplexer geworden – alleine die Authentifizierung die man heute bauen muss, dürfte mehr Programmcode enthalten wie damals komplette Programme.
Und es macht halt auch nur bedingt Sinn. Klar ist C# nicht Hardwarenah wie C++ oder Rust. Aber dafür kannst du schnell und "effizient" Programme erstellen und Pflegen – das ist heute durchaus wichtiger.
Performance ist immer noch ein Thema und man sollte nicht ineffizient werden. Mehr Power unter der Haube entschuldigt auch nicht, wenn man schlecht programmiert.
Aber versuch mal heue eine ERP mit C++ oder irgendwas Hardwarenahen zu bauen. Vergiss es. Da sind ganz andere Anforderungen wichtig, anstatt die letzten 2 KB rauszukitzeln :)
Als jemand der Linux seit den 1990ern benutzt muss ich sagen das ich gegenüber dem System immer mehr Ablehnung entwickele.
Besonders die letzten Jahre wo viele Projekte von politischen Aktivisten unterwandert wurden und man kaum noch etwas installieren kann das nicht vor politischem Aktivismus trieft, mache ich mir zunehmend Sorgen um GNU/Linux.
Ich hoffe das sich diese Sache aber langsam dem Ende zuneigt.
OpenSuse findet keine Willigen mehr zur Wahl in den Vorstand und ist quasi tot.
X11 wird wiedermal geforked weil die aktuellen Entwickler sich um das Projekt nicht mehr kümmern und lieber ihr unfertiges Wayland pushen und X11 sterben lassen wollen.
Alle möglichen Distributionen sind mehr damit beschäftigt irgendwelche Fähnchen zu schwingen anstatt ihre Hausaufgaben zu machen und folgen dann in vorauseilendem Gehorsam den Institutionen die diesen Quatsch vorantreiben.
Überall Code oft Conduct und Sprachpolizei um Leute mundtot zu machen die sich beschweren. Die Folge: Etliche Hauptentwickler ziehen sich vollständig/nahezu vollständig aus dem Projekt zurück oder werden gar rausgeschmissen.
Code-Qualität und die Fähigkeit sein Päckchen tragen zu können sind weniger wichtig wie Hautfarbe, Geschlecht oder Gefühle… Was sich katastrophal auf die Code-Qualität auswirkt/auswirken wird.
Die Leute scheinen nicht zu verstehen das man die Projekte gezielt manipuliert und kaputt machen möchte indem man die Userbase spaltet, aber das Handeln von Red Hat/Free Desktop Foundation im Zusammenhang mit X11 sollte einigen die Augen geöffnet haben.
Kann man nur hoffen das es bald wieder besser wird sonst wird es Linux in der Form nicht mehr lange geben.
Aber die ersten Forks laufen ja schon…
In diesem Zusammenhang passt die aktuelle Nachricht:
https://gitlab.gnome.org/GNOME/libxml2/-/issues/913
libxml2 – für die Unwissenden – das ist die zentrale XML Lib in jedem Safari (Apple OS), Google Chrome und Microsoft Edge (Windows?). Das Paket ist derzeit ohne Maintainer.
https://m.xkcd.com/2347/ at its best!
In den Beobachtungen stimme ich mit Dir überein, in der Konsequenz und Befürchtung nicht. Deshalb Debian, weil die BigTech und BigPlayer was von "predatory actors" im System haben.
Debian ist voll mit genau den Problemen die ich gerade beschrieben habe…
Also definitiv keine Lösung.
Das gehört schon zum Debian Projekt seit es das gibt.
Aber spannender finde ich.. dass sich meist genau eine besondere Benutzergruppe in dieser Weise äußert.
Oder wie man beim Debian Projekt sagt, das Projekt wäre so schön, aber leider hat man User
Also ich nutze Debian seit "slink" und der Unsinn gehörte noch nie zum Debian Projekt.
Aber man sieht n deiner Argumentationsweise schon das du nicht wirklich diskutieren willst…
Das ist keine Nachricht, das ist ein Entwickler der sich in einem Github Ticket über generelle Probleme der Open Source Szene beklagt. Er hat eine ziemlich verquere Einstellung zu Sicherheitsupdates und scheint sich seiner Verantwortung nicht bewusst zu sein.
Darum geht es aber gar nicht: Im Kern ist Open Source in vielen Teilen inzwischen eine massive Ausbeutung von freiwilliger Arbeit. Die größten Konzerne der Welt profitieren davon, aber sie tragen oft nur sehr wenig bei. Man nimmt sich die Arbeit, unterstützt aber nicht diejenigen, die sie tuen. Spätestens seit Log4j oder dem xz-Gau sollte auch dem gierigsten CEO klar geworden sein, dass es so nicht mehr weitergeht. Man kann nicht kritische Software komplett auf der Arbeit von ausgebeuteten Freiwilligen aufbauen. Ja, xkcd bringt es gut auf den Punkt.
stimmt bis auf das mit xz
Das war kein Gau. Der Schmus wurde von einem Debian Maintainer aufgedeckt bevor es Schaden anrichten könnte. Genauso so funktioniert Peer-Review.
War da was bejammert, hat keine Ahnung und on top darauf auch keinen wissenschaftlichen Hintergrund (Stichwort pre-prints vo Papers).
Bist Du sicher, dass Du da nicht etwas verwechselst? Denn Andres Freund ist PostgreSQL-Entwickler bei Microsoft. Ich habe auf die Schnelle keine Quelle für eine Debian-Maintainer-Aktivität irgendeines Pakets gefunden.
Es wurde auch kein Peer-Review durchgeführt sondern nur zufällig von ihm gefunden:
"I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.
Really required a lot of coincidences."
Quelle: https://mastodon.social/@AndresFreundTec/112180083704606941
Das liest sich nicht gut für jemand wie mich, der über einen Umstieg auf Linux nachdenkt.
Also Wahl zwischen Pest und Cholera?
Code of Conduct ist ein Problem. Darum ist BSD auch nicht mehr der Rede wert, deren Sprech und Forderungen waren an Dreistigkeit nicht zu überbieten.
Aber Debian läuft seit zig Jahren wunderbar auf meinen Systemen: Virtuell, ARM64, x86-64
Schau es Dir selber an, bevor Du auf (teils berechtigte) Kritik Dritter hörst. So ziemlich alles ist besser, als im goldenen Käfig der Abhängigkeit zu verharren.
Erste Erkenntnis, niemand wartet auf dich dass Du nun ein Linux User wirst.
Und noch weniger darauf, dass du dann viele nervst mit Dingen die bei Dir nicht gehen.
> Code of Conduct ist ein Problem. Darum ist BSD auch nicht mehr der Rede wert, deren Sprech und Forderungen waren an Dreistigkeit nicht zu überbieten.
Worum geht 's? Und welches BSD ist gemeint?
Nein, alles ist besser als überteuertes proprietäres Zeugs von Herstellern, die keinen Scheiß auf Dich geben und hintenrum Deine Daten absaugen weil Du in deren Systemen nichts machen kannst.
Dann nimm lieber freie, kostenlose Software von Leuten, die ebenfalls keinen Scheiß auf Dich geben, die aber wenigstens vieles selbst fixen kannst und Du den Peer-Review einer weltweiten Gemeinschaft hast.
;-)
Manche Woken wurden vielleicht von MS eingeschleust oder KI-Schwall-Bots sabotieren solche offenen Systeme. Ist bei Parteien auch nicht anders. Offen ist dann leider auch = angreifbar, wenn die Strukturen nicht gefestigt sind.
Wow. Trotz der langen Zeit als Linux Nutzer, hast du offensichtlich wenig vom Linux Öko-System verstanden.
"Code of conduct" wurden und werden eingeführt, weil man Freiwilligen schlecht vermittlen kann, dass man seine Freizeit für ein Projekt opfert und sich dafür von jedem dahergelaufenden Rüpel auch noch anmeckern lassen muss. Hier musste sich etwas ändern, da immer mehr Projekte Entwickler verloren haben oder keine neuen gefunden haben. Respektvoller Umgang miteinander sollte eigentlich ein Selbstverständnis sein. Aber offensichtlich gibt es viele, die Respekt nervig finden. Selbst Linus bemüht sich inzwischen, höflicher zu sein (auch wenn ihm das nach wie vor nicht immer gelingt). Natürlich sind auch einige Entwickler gegangen und gegangen worden, weil sie einfach nicht respektvoll zusammen arbeiten können und daher gegen den jeweiligen "Code of conduct" verstoßen haben. Das ist schade, aber wer so ein Ego ist, dass er Höflichkeit und Respekt nicht hinbekommt, muss gehen. Du kannst nicht gemeinsam vorankommen, wenn einzelne mit Rüpelei, Rassismus oder Hetze die Stimmung vergiften. Das sage ich aus jahrzehntelanger Erfahrung mit ehrenamtlicher, gemeinsamer Arbeit.
Um X11 ist ein neuer Glaubenskrieg ausgebrochen. Das nimmt immer mehr religiöse und verschwörungstheoretische Züge an. Fakt ist, dass X11 zu viele Problemstellen hat, um es nachhaltig zu verbessern. Seit Jahren wird nur noch stellenweise geflickt. Niemand hätte den gigantischen Aufwand einer Neuentwicklung auf sich genommen, wenn man den X-Server noch hätte nachhaltig am Leben halten können. X11 kann einige, oftmals exotische, Dinge besser als Wayland – derzeit. Aber in vielen modernen Entwicklungen (Multimonitor, HDR, sauberes fractional Scaling, verschiedene Sync-Frequenzen je Monitor etc) hinkt es hinterher und ist nur schwer zu modernisieren. Und sicherheitstechnisch hat es ebenfalls viele Baustellen.
Da im Wayland Lager mehr Fortentwicklung und Manpower exisitiert, wenden sich immer mehr Entwickler und Distributionen vom X-Server ab. Wenn es gelingt, dass der Fork xlibre wirklich Fahrt aufnimmt, also Spenden akquiriert, weitere Entwickler findet, User die intelligente Bug-Reports schreiben etc – dann wird X11 weiterleben. Du kannst ja selbst prüfen, ob du genug dafür beiträgst. In den vielen Diskussionen in den letzten Tagen habe ich leider gesehen, dass die größten X11 Befürworter oft aggressiv und großmäulig sind, aber nix konkretes für das Projekt tun. So wird das sicherlich nix… Und wenn ihr X11 Fans kein großes Momentum aufbaut, wird kein neues Interesse an dem Projekt aufkommen und es wird endgültig sterben.
"Die Leute scheinen nicht zu verstehen das man die Projekte gezielt manipuliert und kaputt machen möchte indem man die Userbase spaltet, aber das Handeln von Red Hat/Free Desktop Foundation im Zusammenhang mit X11 sollte einigen die Augen geöffnet haben."
Deine Verschwörungstheorien kannst du dir ins Klo hängen. Der, leider auch ziemlich großmäulige, Entwickler des Forks macht derzeit vor allem durch seine Opferhaltung auf sich aufmerksam. Dass er guten und sicheren Code schreiben kann, muss er erst beweisen. Dass man seinen Code rausgeworfen hat, ist verständlich. Das hat nix mit "böser Konzern" zu tun. Kein Projekt-Owner übernimmt hunderte(!) Commits von einem Außenseiter einfach so. Er hat das Projekt massiv mit seinem Code geflutet. Ein Nobody, den niemand kennt. Nach der xz-Lücke klingeln da bei allen serösen Projekt-Maintainern die Alarmglocken. Und auch die X111 Fans sollten sich fragen, ob das alles mit rechten Dingen zugeht. Die ganzen Code Commits müssen alle einzeln geprüft werden. Die Ressourcen dafür fallen nicht vom Himmel. Da es einen Fork gibt, ist auch nicht damit zu rechnen, dass der Entwickler weiter konstruktiv zur weiteren Verbesserung beiträgt. An diesem Punkt schmeißt jeder sicherheitsbewußte Maintainer den ganzen Krempel wieder raus.
Niemand in der Industrie hat einen Vorteil davon, dass X11 stirbt. Im Gegenteil: Es sind viele Ressourcen in die Entwicklung einer Alternative geflossen. Da niemand für die Nutzung von Wayland bezahlt, kann man damit auch kein Geld verdienen. Investieren ohne Return macht ein Konzern nur, wenn du ihn mit der Peitsche dazu antreibst.
Aber Verschwörugnstheorien haben selten irgendwas mit Logik und Vernunft zu tun…
Das nennt sich Wirthsches Gesetz (https://de.wikipedia.org/wiki/Wirthsches_Gesetz). Vielleicht ist hier die Intention, die Vollständigkeit und Konsistenz der Anwendung sicher zu stellen, auch der Sicherheit willens. Oder es ist schlicht Faulheit, frei nach dem Motto "Wir brauchen aus dem Paket nur eine Funktion, aber wir wissen nicht wie wir den Rest weglassen können und die Zeit das rauszufinden haben wir nicht. Aber ist ja auch egal, die Anwender kaufen sich einfach eine größere Festplatte, einen schnelleren Prozessor oder ein neues Smartphone. Und wer das nicht will, der muss halt damit leben, dass die Zeit, die wir einsparen, bei ihm zur Wartezeit wird.
Wie gern erinnere ich mich an die Zeiten, als die Entwickler noch jedes eingesparte Byte und jede unnötige Schleife gefeiert haben.
von einem Microsoft-Menschen mal gehört:
"Microsoft vertrat schon immer die Ansicht: wir programmieren – für Geschwindigkeit sorgt dann Intel"
Das ist also nicht wirklich neu. Microsoft hat "schon immer" die beim Release verfügbare Hardware ausgenutzt, da über den Lebenszyklus ja ohnehin schneller/besser nachkam. Bzw. kommen sollte.
Es liegt wahrscheinlich einfach daran, dass Microsoft möchte, dass die Sysinternals-Tools möglichst sofort und ohne Abhängigkeiten funktionieren. Das war bei Sysinternals immer der Ansatz. Es ist im Falle von RDCMan jetzt natürlich maximal blöd, aber die Motivation dahinter ist verständlich.
Es gibt seit vielen Jahren den wunderbaren Dienst "live.sysinternals.com" über den man sich in kniffligen Situationen ohne Schnickschnack und Blödsinn alle Sysinternals-Tools herunterladen kann. Der Dienst funktioniert in jedem Browser – auch uralten Versionen, da er einfach nur eine Verzeichnisausgabe ist. Einfach das benötigte Tool herunterladen und sich auf die Problemlösung konzentrieren. Nebenkriegsschauplätze wie Framework-Installationen stören da massiv.
RDCMan muss diese Richtlinie wahrscheinlich auch umsetzen und die Entwickler haben hier den einfachen Weg genommen, um voranzukommen: In Visual Studio den Deployment Mode auf Self-Contained gesetzt und Produce Single File aktiviert.
Hätte man "Framework-Dependent" gesetzt wäre die Datei halb so groß aber beim Start ohne installierte .NET Desktop Runtime – und die hat so gut wie niemand installiert – gibt es nur eine Fehlermeldung. Die .NET Desktop Runtime ist nicht das .NET Framework, das bei Windows quasi immer dabei ist.
Natürlich kann man Visual Studio auch sagen, dass das zusammengeschnürte Kompilat danach bitte auf das getrimmt werden soll, was auch wirklich benutzt wird, aber das funktioniert in diversen Fällen nicht, da dann diverse Funktionen der Programmiersprache C# wegfallen, weil sie mit Trimming (noch) nicht kompatibel sind. Der Compiler muss vereinfacht gesagt zur Kompilierzeit exakt erkennen können, was benutzt wird und was nicht. Das geht noch nicht immer, auch wenn daran gearbeitet wird, dass es immer besser funktioniert.
Danke für die sachliche Erklärung, Anonym. Erfrischend, wenn man einen Kommentar liest, der Fakten aufzählt statt eigene Befindlichkeiten. Und nebenbei hat man noch was gelernt.
Die technischen Hintergründe, von dir als Fakten bezeichnet, sind ja schön und gut (ich habe ewig kein Visual Studio auf meinen Systemen installiert gehabt, konnte dazu also keine Aussage treffen). Mich interessieren aber eher die Implikationen des Ganzen. Wenn ich 30 Apps auf dem System habe, laufen auf den Geräten nur noch Update-Orgien, wo Megabyte um Megabyte an Code unnötig über die Leitungen auf die Systeme geschaufelt wird. Und das KI-Zeugs ist da noch nicht mal berücksichtigt. Das sind dann die Punkte, wo ich die Entwicklung in Form solcher Blog-Beiträge hinterfrage. Mir sind noch die Versprechen Microsofts auf der BASTA 2006 Entwicklerkonferenz im Ohr, wie toll die neue Umgebung mit xaml &Co. werde, und die Registry verschwindet. Damals stand man gefühlt vorm Abgrund, weil alles mobil werden sollte. Heute sind wir einen guten Schritt weiter, imho :-)
Normalerweise braucht man standalone auch nicht und hat den installer der das nachlädt. Sysinternals-tools kommen gerne da ran wo es zickt.und da sollten die auch offline funzen
Stimmt natürlich. Wenn man das nur auf einem einzelnen System installiert bräuchte man die '(Standalone) .NET-Desktop-Runtime' aber tatsächlich nur einmal. Jetzt hat man allerdings das Problem, dass man irgendwann die ganze Software auf eine neuere Basis heben muss – für neue Funktionen und aus Sicherheitsgründen, weil irgendwann der 'Support' für die Vorversionen ausläuft und '.net' und dabei insbesondere '.net 8' auf keinem System vorinstalliert ist, wie auch schon angemerkt wurde.
Es gibt doch die vollständige 'Sysinternals-Suite' zum Download. Vieleicht ändert sich das wieder, wenn alle 'Tools' auf das neueste '.net' portiert sind. Dann könnte man eine 'Portable' mit einer mitgelieferten '(Standalone) .NET-Desktop-Runtime' erstellen – das wären dann nur einmal ~65MiB für x64 bzw. ~60MiB für x32, die auch nur knapp 3x so groß wie die MSVC++ Runtime sind – oder eine 'Installable' auf Basis von einer systemweiten Installation von '.net' bringen und dann nur die (kleinen) 'Tools' bei Bedarf oder regelmäßig automatisch updaten.
Außerdem gibt es ja noch 'live.sysinternals.com' von wo aus man den Kram direkt starten (z.B. [ https://live.sysinternals.com/RDCMan.exe ] ) und sogar komplett als Netzlaufwerk für den Zugriff auf immer aktuelle Komponenten einbinden kann. Dafür benötigt man zumindest momentan auf jeden Fall noch eigenständige Programme!
Bezieht sich das "Dafür" in "Dafür benötigt man zumindest momentan auf jeden Fall noch eigenständige Programme" auf "Außerdem gibt es ja noch 'live.sysinternals.com' von wo aus man den Kram […] komplett als Netzlaufwerk für den Zugriff auf immer aktuelle Komponenten einbinden kann"?
Denn dafür braucht man auf jeden Fall keine eigenständigen Programme, da man nur den Befehl "net use Z: \\live.sysinternals.com\tools" im Ausführen oder Kommandozeilen Fenster eingeben muss um die Tools auf Z: zu mounten (Alternativ über "Netlaufwerke verbinden…" im Explorer).
Da das per WebDAV implementiert ist, müsste das schon seit WinowsXP funktionieren.
Nö, das war darauf bezogen, dass die Software ohne Abhängigkeiten funktionieren muss, weil man von einem nicht vorhandenen .net ausgehen muss.
Außerdem wäre es in Zukunft möglich, dass entsprechende Verzeichnisse angelegt werden z.B. /standalone mit vollständigen und /net8dependent für von net 8 abhängigen Werkzeugen, die dann entsprechend kleiner sind oder so.
Dass das über Webdav geht wusste ich aber tatsächlich nicht sondern dachte, dass das per SMB eingebunden wird – kann auch sein, dass es den letzten Jahren geändert wurde.
Apple hat gezeigt mit MacOSX dass es genau so geht.
Android hat es kopiert.
Microsoft wollte es mit den Apps nach machen.
Jede App eigenständig für sich, statisch gebaut .
Hallo Günter,
mein Kommentar bezogt sich nicht auf Dich oder Deinen Artikel, sondern auf die zum Zeitpunkt meines Kommentars einzigen anderen beiden Kommentare, bei denen der eine politische Intrigen im Linux-Entwicklungsumfeld kolpotierte und der andere das übliche Microsoft-Bashing betrieb, inhaltlich also wenig neues bot.
Inhaltlich weiter führte einzig der von mir kommentierte Kommentar, der erklärte, WARUM etwas ist wie es ist. Ohne Wertung, ohne Meinung, einfach nur Fakten.
Das ist im übrigen das einzige, was mich interessiert: Fakten. Die Meinung dazu bilde ich mir immer noch selbst und mache sie nicht von der Meinung andere abhängig.
Auf Deiner Seite darfst Du natürlich gern Deine Meinung vertreten, aber wie gesagt bezog sich mein Kommentar nicht auf den Artikel, sondern den Kommentar.
Danke für den Artikel und Deine Arbeit dafür. =)
VG
Joerg
Das ist leider so (mit .NET) aus meiner Sicht lieber eine Fat Binary die einfach läuft als wenn etwas nachgeladen oder installiert werden muss.
"Winternals wurde ja 2006 von Microsoft gekauft."
Freudscher Verschreiber?
Quelle: https://en.wikipedia.org/wiki/Sysinternals
"Winternals" !?
'Winternals Software LP' hieß die Firma, die früher 'Sysinternals' entwickelt hat und eben von MS gekauf wurde.
[ https://de.m.wikipedia.org/wiki/Windows_Sysinternals#Geschichte ]
Das ist doch vergleichbar mit der "flatpak-Lösung" unter Linux — jede App bringt ihre notwendigen Runtimes + Libs gleich mit. Wird dort als DIE Lösung gepriesen.
Wenn das Ganze doch dort so toll ist, kann die Anwendung des Prinzips unter Windows ja wohl nicht verkehrt sein. Zur Not ersetzt man halt die zu klein gewordene System-SSD durch eine entsprechend größere und stellt auch gleich noch den DSL-Anschluss auf angemessene Bandbreite um.
Ironie OFF
Sucht mal im Internet nach Rdcman und password encryption. Leider setzen viele Admins gedankenlos diese rdcman Katastrophe ein. Es gibt Alternativen, welche die credential Datenbank entsprechend gut mit Passwort verschlüsseln.
Das ist nichts neues. Jedes Programm welches sich bei einem anderen Programm anmeldet, hat quasi einen Passwort Speicher eingebaut, in dem diese im Klartext liegen. Ob Firefox/Google Chrome, Thunderbird, Plattform egal. Wenn ein Kennwort zum Einsatz kommt, wird es irgendwo gespeichert.
Deshalb ja auch Passkeys.