Eagle Probleme unter Win10

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.

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

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 ...

Dieser Clown ist kaputt. Er ist nicht komisch.

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:
> 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 :-(

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:
> 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.

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.

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.

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.

Rufus Τ. F. schrieb:
> Das solltest Du CadSoft zukommen lassen.

Ist auf dem Weg.

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.