ich habe Probleme mit der Installation des STM32 Cube IDE Programms. Sobald ich das Programm heruntergeladen habe, extrahiert und als Administrator ausgeführt habe, bekomme ich ständig einen NSIS Fehlermeldung und die Installation wird abgebrochen.
Bereits auf 2 Verschiedenen PCs habe ich es Ausprobiert, leider ohne Erfolg. Auch auf eine Ältere Version bin ich bereits umgestiegen zum Versuch, auch da kam die Fehlermeldung. (jeweils Windows 10/11 in 64 Bit, mit 8 GB RAM).
Weiß da jemand einen Rat oder hat eine Idee woher das kommen könnte?
Man könnte glatt meinen, Windows sei für Analphabeten gemacht, die durch aussagekräftige Sätze zu sehr verunsichert werden. Gleichzeitig wird an Linux kritisiert, es würde zu viele "kryptische" Details anzeigen. Es ist wohl nicht einfach, es allen Usern Recht zu machen.
In deinem Fall gilt wohl die alte Regel:
Nochmal downloaden
Reboot tut gut
Und wenn nicht: alles platt machen und neu installieren
Das hat es tatsächlich gebracht. Warum stand das nirgends..
Das weiß man doch, dass viele Anwendungen nicht damit klar kommen, wenn sie in einem Pfad abgespeichert sind der zu lang ist (>= 256 Bytes) oder Sonderzeichen / Leerzeichen enthält...
Das weiß man doch, dass viele Anwendungen nicht damit klar kommen, wenn
sie in einem Pfad abgespeichert sind der zu lang ist
Ja gut, aber wenn der Hersteller es doch genau so ausliefert, wie soll man das ahnen?
Und die nächste Frage ist, warum der Hersteller so weiter nacht, obwohl er sowohl das Problem als auch die simple Lösung kennt. Ist das noch Doofheit oder schon böse Absicht?
Ja gut, aber wenn der Hersteller es doch genau so ausliefert, wie soll
man das ahnen?
Hat der Hersteller es auf die Festplatte nach "C:\Ein Unfassbar\langer Pfad\auf\meinem Computer\Für meine tollen\Mikrocontroller-Projekte\Welche ich mit dem STM32\umsetzen möchte\Wobei ich aber bereits\An der Installation der IDE scheitere\weil ich ein übertriebenes Ordnersystem habe\Statt alles im Downloads-Ordner zu speichern\wie normale Menschen" gespeichert oder der Nutzer?
Und die nächste Frage ist, warum der Hersteller so weiter nacht, obwohl
er sowohl das Problem als auch die simple Lösung kennt. Ist das noch
Doofheit oder schon böse Absicht?
Wenn das mal das größte Problem bei dieser Software wäre, haha... Geschenkter Gaul und so. Die VSCode Extension funktioniert überraschend gut, und VSCode ist doch deutlich schneller.
Vermutlich Ignoranz. Die, die den Installer zusammenfrickeln, bekommen vorgegeben (von einer Managementebene höher), wie die Dateien zu heißen haben, und das ist dann so. Das interne Rückmeldesystem ("Äh, Chef, das geht so nicht") existiert zwar, wird aber nicht gelesen (denn der Chef ist auf einem anderen Kontinent).
Das geht sogar, aber man muss halt andere OS-APIs und String-Funktionen nutzen für den Dateizugriff. Also nicht so programmieren wie 1995. Aber die Embedded-Branche liebt ja ihre statischen "char"-Arrays mit Nullterminierung... Okay, zugegebenermaßen muss das erst in der Registry aktiviert werden.
Das geht sogar, aber man muss halt andere OS-APIs und String-Funktionen
nutzen für den Dateizugriff.
Richtig, aber davon wird NSIS nichts wissen. Ist ja auch bescheuert, was soll das, den Lebenslauf im Dateinamen oder Pfad unterzubringen.
Daß Dateinamen genutzt werden können (statt der 8.3-Kürzel aus DOS-Zeiten) ist ja durchaus ein Fortschritt, aber was muss an den Dateinamen und Pfaden einer simplen IDE so lang werden, daß 255 Zeichen überschritten werden?
Wie auch immer, der Nullsoft-Installer müsste geändert werden.
Und /dann/ ist wiederum sicherzustellen, daß auch die IDE und die zig von ihr aufgerufenen Programme mit den beknackten überlangen Namen zurechtkommen ...
Das hat es tatsächlich gebracht. Warum stand das nirgends..
Vielen Dank.
Unsere IT war auch der Ansicht, dass Länge und Leer- und Sonderzeichen im Pfad/Dateinamen schon seit Jahrzehnten völlig unproblematisch sind und uns nach einer Ordner-Neustrukturierung entsprechend ausgelacht. Die Erkenntnis kam nach nur wenigen Tagen, nicht nur im Elektronik-Entwickungsbereich.
aber was muss an den
Dateinamen und Pfaden einer simplen IDE so lang werden, daß 255 Zeichen
überschritten werden?
Habs jetzt mal ausprobiert. Der Dateiname
1
C:\Meine Daten\Meine tolle Software-Sammlung\Ich bewahre alle Installer auf fuer immerxxxy\Tief verschachtelte Ordnerstrukturen sind was ganz tolles\en.st-stm32cubeide_1.18.1_24813_20250409_2138_x86_64.exe\st-stm32cubeide_1.18.1_24813_20250409_2138_x86_64.exe
funktioniert. Das ist der Original-Name der ausgepackten Datei, insgesamt 259 Zeichen. Ein Zeichen mehr geht nicht; zusammen mit dem terminierenden Null-Byte sind das dann 260, also MAX_PATH.
Was jedoch nicht geht: Umlaute im Ordnernamen, also C:\Users\mmüller\Downloads... geht nicht. Immerhin geht auch François nicht, also sind die Franzosen selbst auch betroffen. Das gute alte Home-Verzeichnis mit Leerzeichen & Sonderzeichen, schon immer der Härtetest für viel Software.
Der Ratschlag im ST-Forum ist somit auch nur halb sinnvoll, den Dateinamen zu kürzen ist sinnlos. Heißt aber auch das Problem wäre einfach zu lösen (anders als das MAX_PATH-Problem), indem man die Datei-Zugriffs-Funktionen sinnvoll aufruft. Kann übrigens trotzdem ein Fehler von ST sein, man kann in NSIS-Installern eigenen Code unterbringen. Tatsächlich soll NSIS wohl Unicode unterstützen.
Die NSIS-Fehlermeldung (Nullsoft Scriptable Install System) bedeutet in der Regel, dass der Installer beschädigt ist oder verändert wurde, nachdem er erstellt wurde. Das kann mehrere Ursachen haben:
Und dann ist wiederum sicherzustellen, daß auch die IDE und die zig
von ihr aufgerufenen Programme mit den beknackten überlangen Namen
zurechtkommen ...
Ich erinnere mich an ein SAP Schulung (Hybris E-Commerce), dass musste man nach C:\hybris auspacken (keinen Buchstaben mehr!), sonst funktionierte es nicht. Da war die Grenze allerdings nicht 256 Zeichen, sondern deutlich höher. Der Längste Pfad umfasste mehrere Zeilen auf dem Bildschirm.
Ganz toll sind an der Stelle auch Leerzeichen im Benutzernamen. In unserer Firma bestand der Betrieb auf vollständig ausgeschriebene Namen (wie Max Müller), weil sie sonst nicht eindeutig gewesen wären.
Ganz toll sind an der Stelle auch Leerzeichen im Benutzernamen. In
unserer Firma bestand der Betrieb auf vollständig ausgeschriebene Namen
(wie Max Müller), weil sie sonst nicht eindeutig gewesen wären.
Naja, Leerzeichen sind nicht so exotisch, und nur ganz wenige Sprachen kommen ausschließlich mit lateinischen Schriftzeichen aus... Wir haben Umlaute und "ß", Franzosen und Italiener diverse Akzent-Zeichen, und viele Sprachen von Arabisch bis Chinesisch haben überhaupt nichts mit lateinischer Schrift zu tun. Denen allen vorzuschreiben ihre eigenen Namen nach ASCII ohne Leerzeichen zu transkribieren nur weil solche Programme so mies programmiert sind grenzt an Diskriminierung. Eigentlich müsste man alle Software-Entwickler zwingen Leerzeichen und Nicht-ASCII-Zeichen in ihren Benutzernamen aufzunehmen damit solche Probleme früh gefunden werden!
Windows unterstützt Unicode seit Windows 2000, also seit einem schlappen Vierteljahrhundert. Überhaupt kann man Dateinamen so verarbeiten dass der Zeichensatz vollkommen wurscht ist, nur die Zeichengröße muss man beachten (8 vs 16 bit) - das muss man bei den Windows-APIs aber sowieso hartkodieren. Man muss nur das Trennzeichen (Back)Slash erkennen, alles dazwischen wird 1:1 durchgereicht ohne Verarbeitung. Die IDE selbst ist ja Java, das kapselt das sowieso sehr elegant mit java.io.File , da muss man sich eigentlich schon Mühe geben es falsch zu machen.
Kommandozeilen am Leerzeichen Aufspalten reicht schon.
So ein Installer muss aber gar keine Kommandozeilen-Programme aufrufen, schon gar nicht sofort beim Start noch bevor irgendwas installiert wird. Unter Windows können Programme das Aufspalten explizit kontrollieren, unter Unix wird nicht automatisch gespalten außer es wird über eine Shell ausgeführt, in allen Fällen kann man es korrekt machen wenn man nur will.
