Zumindest mit der lizensierten Light-Variante gibts einige Problemchen. - Beim Replace stürzt das Programm ab - Diverse Netzwerklinks lassen sich nicht öffnen - Immer noch die gleichen nervenden Rechteprobleme wenn unter C:/Programme installiert Getestet unter Win10Pro
:
Wiederhergestellt durch Moderator
Ich habe es auch unter Win10 Pro installiert. Soweit klappt alles wie es soll - Auch die Replace funktion. Aber ich habe es nicht unter "\Programme" installiert - Das sollte man auch tunlichst sein lassen.
:
Wiederhergestellt durch Moderator
Wäre jetzt ein schönes Beispiel für meinen Thread gewesen: Beitrag "Windows 10 look&feel der Anwendungen?" ;)
:
Wiederhergestellt durch Moderator
Thomas H. schrieb im Beitrag #4217260:
> Schmeiss den PC weg
Der ist brandneu!
Lt. Cadsoft Support gibt es noch keine Erfahrungen unter Win10...
:
Wiederhergestellt durch Moderator
Moby schrieb: > Thomas H. schrieb im Beitrag #4217260: >> Schmeiss den PC weg > > Der ist brandneu! > Lt. Cadsoft Support gibt es noch keine Erfahrungen unter Win10... Die hatten über eine halbes Jahr Zeit mal eine der Previews in eine VM zu hauen und ihr hoffentlich vorhandenes Testarsenal darüber laufen zu lassen... Aber gut: Hier läuft zumindest eine 6.3 problemlos, soweit ich das testen konnte/wollte... Allerdings liegen die Verzeichnisse mit den Libraries usw., wie auch bei allen anderen Entwicklungstools, nicht auf C
Arc N. schrieb: > Allerdings liegen die Verzeichnisse mit den > Libraries usw., wie auch bei allen anderen Entwicklungstools, nicht auf > C Hatte mich nur interessiert, wie das nun unter Win10 ausschaut: Nämlich genauso inkompatibel zu den vorgesehenen Programmorten wie eh und je. Eine 6.6er Installation macht unter Win10 ansonsten auch keine Probleme.
Stefan P. schrieb: > Aber ich habe es nicht unter "\Programme" installiert - Das sollte man > auch tunlichst sein lassen. Kannst Du das irgendwie begründen?
Rufus Τ. F. schrieb: > Stefan P. schrieb: >> Aber ich habe es nicht unter "\Programme" installiert - Das sollte man >> auch tunlichst sein lassen. > > Kannst Du das irgendwie begründen? Eagle packt(e) da auch alle Bibliotheken, ULPs und sonstiges, was sich verändern könnte, hin. Und da diese Ordner schreibgeschützt sind bzw. ab NT/95 nicht mehr für Benutzerdaten gedacht waren, geht dann u.U. einiges schief (spätestens wenn der Benutzer keine Adminrechte hat, auch wenn Windows versucht es einigen alten Programmen recht zu machen und Schreibzugriffe umleitet)
Arc N. schrieb: > Eagle packt(e) da auch alle Bibliotheken, ULPs und sonstiges, was sich > verändern könnte, hin. Wenn es das immer noch tut, verdient CadSoft Prügel dafür. Und zwar schon seit 20 Jahren -- denn seitdem (genauer: mit der Oberfläche und den Systemvorgaben von Windows 95) ist klar, daß derartiges dort nicht hingehört. Ja, es ist bekannt, daß die "Human User Interface Guidelines" der Betriebssystembauer zu den am meisten ignorierten Dokumentationen überhaupt gehören ...
Moby schrieb: > Zumindest mit der lizensierten Light-Variante gibts einige Problemchen. > - Beim Replace stürzt das Programm ab > - Diverse Netzwerklinks lassen sich nicht öffnen > - Immer noch die gleichen nervenden Rechteprobleme wenn unter > C:/Programme installiert > > Getestet unter Win10Pro Das Hauptproblem ist offensichtlich, das Windows 10 und Eagle in einer Hochsprache wie C und nicht, so wie es sich gehört, in x86 Assembler entwickelt wurden. Solche Probleme sind nur und ausschließlich auf die Verwendung von Hochsprachen und - noch schlimmer - Objektorientierung zurückzuführen.
Arc N. schrieb: > Eagle packt(e) da auch alle Bibliotheken, ULPs und sonstiges, was sich > verändern könnte, hin. Die mitgelieferten Bibliotheken, ULPs etc. sollte man nicht ändern. Für eigene (oder abgeänderte und umbenannte) nimmt man ein separates Verzeichnis an einem Ort, auf dem man Schreibrechte hat, und sagt das Eagle in den Optionen. Das mache ich seit Eagle 4.irgendwas so ...
Ich schrieb: > Die mitgelieferten Bibliotheken, ULPs etc. sollte man nicht ändern. Für > eigene (oder abgeänderte und umbenannte) nimmt man ein separates > Verzeichnis an einem Ort, auf dem man Schreibrechte hat, und sagt das > Eagle in den Optionen. vernünftig zumal mein Kollege und ich auf eigene Bibliotheken auf der Netzwerkplatte zugreifen. Es wäre halt auch umständlich das an jedem Arbeitsrechner zu ändern.
Rufus Τ. F. schrieb: > Dieser Clown ist kaputt. Er ist nicht komisch. Die richtige Reaktion wär ja wohl in Mod-Logik gewesen: Beitrag zuvor löschen wegen Themenverfehlung. Da scheint mit den Moderatoren hier auch so einiges nicht zu stimmen... Beleidigungen verstossen gegen Forenregeln.
Scelumbro schrieb: > Läuft Eagle nicht auf MenuetOS? Bist du des Lesens kundig? Oder wo siehst du das unter "System-Voraussetzungen" gelistet? http://www.cadsoft.de/eagle-pcb-design-software/ueber-eagle/
Rufus Τ. F. schrieb: > Wenn es das immer noch tut, verdient CadSoft Prügel dafür. Und zwar > schon seit 20 Jahren -- denn seitdem (genauer: mit der Oberfläche und > den Systemvorgaben von Windows 95) ist klar, daß derartiges dort nicht > hingehört. Imho ist der Kommentar ziemlicher Schwachsinn, denn das Problem liegt bei MS, vor Allem in den neueren Betriebssystemen wg. des Rechtemanagements. Aber der "Standard User" drückt auf Installieren und geht dabei einen Kaffee trinken.... Es ist ja auch ein unzumutbarer Aufwand einfach bei der Installation einen anderen Laufwerksbuchstaben außer "C" zu wählen :-(
Rufus Τ. F. schrieb: > ist klar, daß derartiges dort nicht > hingehört. Kannst Du dir den Aufschrei unter den typischen EAGLE-Benutzern vorstellen, wenn Cadsoft das umstellt? Es gibt sogar eine Option in den Einstellungen, um die leichte grafische Überarbeitung der Icons rückgängig zu machen...
Tom schrieb: > Es gibt sogar eine Option in den > Einstellungen, um die leichte grafische Überarbeitung der Icons > rückgängig zu machen... ...und das ist auch gut so, damit man sie wiedererkennt. Es ist überhaupt so, daß die Leute an Bewährtem hängen, deshalb konnte sich diese dämliche Kacheloberflächen bei Windows nicht durchsetzen und deshalb gibt es auch Sachen wie "Classic Shell", damit sich die Leute die Rechner so zurecht machen können, wie es sinnvoll ist. mfG Paul
Jörn P. schrieb: > ... > Imho ist der Kommentar ziemlicher Schwachsinn, denn das Problem liegt > bei MS, > vor Allem in den neueren Betriebssystemen wg. des Rechtemanagements. > ... MS hat seit mehreren Jahrzen dokumentiert wo welche dateien abzuglegen sind. Dies ist in der Anwendung nachweislich nicht berücksichtig worden! Das dann MS anzulasten ist dann schon eine frechheit. Es ist eigentlich eher eine frecheit von cadsoft jahrelang diese dokumente nicht gelesen und berücksichtigt zu haben. Das Problem existiert übrigens seit es NTFS gibt. gruss.
123 schrieb: > Es ist eigentlich > eher eine frecheit von cadsoft jahrelang nanana.. Wer so schreibt, scheint mir ein Linuxer zu sein. Dort ist ja auch alles bis ins Kleinste reglementiert, was wohin zu kommen hat. Aber ich pfeife drauf und installiere mein Zeugs niemals per 'default', sondern immer dort, wo ICH das für angemessen halte. Jaja, es gelangt dann immer noch genug Zeugs an Stellen, wo ich es nicht hin haben will, aber um beim Beispiel Eagle zu bleiben, hält sich dies in Grenzen und auf D:\EAGLE funktioniert selbiges auch problemlos. Ich frag mich, was das für Leute sind, die sich wie "123" derart darüber aufregen, daß andere Leute ihre eigenen Vorstellungen haben und demzufolge nicht konform zum allgemeinen Zug der Lemminge laufen. W.S.
Jörn P. schrieb: > Rufus Τ. F. schrieb: >> Wenn es das immer noch tut, verdient CadSoft Prügel dafür. Und zwar >> schon seit 20 Jahren -- denn seitdem (genauer: mit der Oberfläche und >> den Systemvorgaben von Windows 95) ist klar, daß derartiges dort nicht >> hingehört. > > Imho ist der Kommentar ziemlicher Schwachsinn, denn das Problem liegt > bei MS, > vor Allem in den neueren Betriebssystemen wg. des Rechtemanagements. Nein, das Problem liegt definitiv nicht bei MS. Es ist ebenso unter Unices völlig normal, dass nur root Schreibrechte auf /bin, /sbin etc. hat und das völlig zu recht. Ein normaler User hat dort nichts zu verändern. > Aber der "Standard User" drückt auf Installieren und geht dabei einen > Kaffee trinken.... > > Es ist ja auch ein unzumutbarer Aufwand einfach bei der Installation > einen anderen Laufwerksbuchstaben außer "C" zu wählen :-( Was zum Teil wiederum an schlecht geschriebenen Anwendungen liegt, da so einige dieser Sorte außerhalb ihrer fest einprogrammierten Pfade schlicht nicht funktionieren/funktionierten.
Arc N. schrieb: > Was zum Teil wiederum an schlecht geschriebenen Anwendungen liegt, da so > einige dieser Sorte außerhalb ihrer fest einprogrammierten Pfade > schlicht nicht funktionieren/funktionierten. Zumindest sollte Cadsoft es doch endlich mal im Jahre 2015 auf die Reihe bekommen in ihrem dämlichen Installer, wenn man doch noch - so wie es richtig ist - nach C:\Programme installieren möchte, auch den Zielverzeichnisnamen automatisch mitzuführen, ohne dass man den dann auch noch manuell neu eingeben muss (dann isser nämlich einfach erstmal weg). Andere Softwarefirmen schaffen das doch auch. Ist ihnen aber wohl noch immer schnurz (wie so manch anderes in ihrem halbgaren Programm. Aber das merkt man erst, wenn man mal bessere Bedienkonzepte erlebt hat). Eagle anno!
Paul B. schrieb: > mfG Paul Damit haben Du und die anderen ("nicht lesenswert"-klickenden) Reaktionäre die Aussage meines Beitrags sehr schön bestätigt. Danke.
Tom schrieb: > Damit haben Du und die anderen ("nicht lesenswert"-klickenden) > Reaktionäre die Aussage meines Beitrags sehr schön bestätigt. Danke. Geht's noch, oder soll ich einen Arzt holen? MfG Paul
Jörn P. schrieb: > das Problem liegt bei MS, > vor Allem in den neueren Betriebssystemen wg. des Rechtemanagements. Das Rechtemanagement ist nicht das Problem, sondern damit nicht umgehen zu können^Wwollen. > Es ist ja auch ein unzumutbarer Aufwand einfach bei der Installation > einen anderen Laufwerksbuchstaben außer "C" zu wählen :-( Und ohne wirklich triftigen Grund falsch. Denn die Anwendung selbst gehört durchaus nach C:\Program Files. Mitgelieferte Daten nach C:\ProgramData und Benutzeränderbare Daten in dessen Profil. Warum so viele Windows-User immer an den Speicherorten drehen wollen, erschließt sich mir nicht. Andererseits hält sich leider auch Microsoft oft genug nicht an die eigenen Vorgaben und hat allgemein mit der Organisation der Pfade ziemlichen Bockmist verzapft. Das Leerzeichen in Program Files ist eine lästige und immer wieder fehlerträchtige Sache, der ganze (x86)- und SysWow64-Krampf ebenso, zumal eine Unterscheidung zwischen x86 und x64 eigentlich nur bei tatsächlich gemeinsam genutzten DLLs Sinn ergibt. Sorry fürs Abschweifen, aber das mal als Beispiel wo schiefe Blicke in Richtung MS angebracht sind. Bei der (viel zu späten) Einführung tatsächlich eingeschränkter Rechte eher nicht.
Malte S. schrieb: > Warum so viele Windows-User immer an den Speicherorten drehen wollen, > erschließt sich mir nicht. Z.B. weil sie die Daten von den Programmen getrennt (etwa auf einem Netzwerkspeicher) haben wollen um sie beim Backup auch alle zu erwischen. Oder weil sie die Daten eines Projektes aus gründen der Nachvollziehbarkeit beisammen halten wollen.
Georg W. schrieb: > Malte S. schrieb: >> Warum so viele Windows-User immer an den Speicherorten drehen wollen, >> erschließt sich mir nicht. > > Z.B. weil sie die Daten von den Programmen getrennt (etwa auf einem > Netzwerkspeicher) haben wollen um sie beim Backup auch alle zu > erwischen. Oder weil sie die Daten eines Projektes aus gründen der > Nachvollziehbarkeit beisammen halten wollen. Aber genau das ist doch bei den Standardorten gegeben Programme in %PrigramFiles%, Daten im Profil oder wo auch immer man speichert. Es ging mir darum, warum Leute die Software an einem Nicht-Standardort installieren. Das ist allenfalls bei portablen Programmen sinnvoll, die nicht eh die Registry brauchen, also trotz zentralem Installationsort Systemspezifisch sind.
Genau das tut Eagle aber nicht. Eagle installiert sich nach C:/EAGLE, und dort liegen Programme und Projekte fröhlich beisammen. Stammt halt aus der Zeit von MS-DOS 3.3.
Malte S. schrieb: > Daten im Profil Dann muss ich die Daten zu einem Projekt wieder unter Profil/Eagle/..., Profil/Atmel/... und Profil/Eiwergrüschlagmichtot/... zusammen suchen. Und wenn nach Jahren ein Gerät zur Reparatur herein kommt ist kaum noch nachvollziehbar was damals weshalb gemacht wurde. Den gesamten Ordner umziehen war auch nicht unproblematisch. Und zum Backup: Wenn sich alle Programmierer an die vorgegebenen Ordner hielten anstatt 1000 kreative Wege um sich an den Vorgaben vorbei zu mogeln suchen wäre es kein Problem. Seit es für diese halsstarrige Spezies noch transparente Ordner gibt ist es noch toller geworden. Manche wollen sich auch direkt unter C:/ einnisten, der nächste hat den Pfad hart codiert und man hat dann plötzlich einen Ordner Program Files neben Programme. Wenn diese Ställe des Augias auf dem Laufwerk C wenigstens frei von Daten und wichtigen Einstellungen sind kann man sie im Falle des Falles einfach platt machen und das System mit den noch benutzten Programmen neu aufsetzen. Tante Edith gibt souleye recht: Die Programmierer von Eagle braten sich auch eine Extrawurst.
:
Bearbeitet durch User
W.S. schrieb: > Aber ich pfeife drauf und installiere mein Zeugs niemals per > 'default', sondern immer dort, wo ICH das für angemessen halte. Das kann ich nur unterstreichen. Ich halte eine gewisse Ordnung auf meinem PC und habe mehrere Platten (logisch und physisch). ICH bestimme welches Programm wo installiert wird und nicht Microsoft. Leider gibt es heute im 21.Jahrhundert immer noch Programme, die das nicht mit sich machen lassen. OK, dann landet es auch nicht auf meinem PC. Auf meiner "C"-Platte befindet sich nur das Betriebssystem und sonst nix. Das man darüber geteilter Meinung sein kann ist klar, deshalb muss der thread aber nicht ausarten (es ist schon eine Frechheit...)
Moby schrieb: > Zumindest mit der lizensierten Light-Variante gibts einige > Problemchen. > - Beim Replace stürzt das Programm ab > - Diverse Netzwerklinks lassen sich nicht öffnen > - Immer noch die gleichen nervenden Rechteprobleme wenn unter > C:/Programme installiert > > Getestet unter Win10Pro Stand heute nichts neues, auch unter Eagle 7.5 nicht. Einen reproduzierbaren Fehler enthalte ich zum Beispiel bei der Neuanlage eines Boards, Einbindung einer Bibliothek + ADD-Befehl. Ich hab mal Lib und die Debug-Meldung drangehängt.
Das solltest Du CadSoft zukommen lassen. Und mal im WERFault-ReportQueue-Verzeichnis nachsehen, ob da ein Crashdump liegt, den sendest Du (erst auf Nachfrage!) auch an CadSoft.
Habe anfänglich auch die neuste 7.4 Light installiert und konnte die ganze leidige Problematik unter Win10 ebenfalls feststellen. Habe die dann runtergeschmissen und zu Testzwecken die 7.3 installiert, alles bei der Installation als Default - läuft fehlerfrei und astrein in allen Punkten. Fazit : Es liegt nicht an MS, sondern eher an der 7.4x Version - meine ich zumindest.
Karlheinz K. schrieb: > zu Testzwecken die 7.3 installiert, alles bei > der Installation als Default - läuft fehlerfrei und astrein in allen > Punkten. Obiges reproduzierbare Problem tritt leider auch unter V7.3 auf.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.