mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wieso funktionieren Decompiler immer deutlich schlechter als Compiler?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Bastler (Gast)
Datum:

Bewertung
-21 lesenswert
nicht lesenswert
Hallo,

Da ich gerade selber das Problem habe, eine .hex zerlegen zu wollen, da 
aber selber nicht weiterkomme, und auch keinen finde, der dazu bereit 
wäre, sich das mal näher anzusehen, frage ich mich, warum es eigentlich 
so schwer möglich ist, Maschinencode zurück zu C zu Decompilieren. 
Immerhin folgt ja der Maschinencode auch nur einem bestimmten Katalog an 
Instructionen die ein entsprechnder Prozessor beherrscht. Warum also ist 
es so einfach den Code zu compilieren, aber extrem schwer die Software 
wieder zurück zu Source Code zu bekommen? Und warum kann man dann als 
Mensch der davor hockt das was der Disassembler rauswirft doch irgednwie 
lesen und verstehen, warum kann das nur ein Mensch? Ich meine klar, die 
Kommentare usw. werden nicht mit kompilliert, sind also in dem 
Maschinencode nicht mehr da, aber der Source Code ist ja danach in einer 
anderen Form noch da nur eben nicht mehr in dem was Menschen (Ohne 
gewaltig Aufwand) lesen können, sondern eben in Maschinencode. Gibt es 
Programme die aus einer .hex wieder eine .C oder .C++ Datei machen 
können, und die sind uns einfach nur nicht zugänglich und z.B. 
Regierungen (Und vielleicht einigen Chinesen) vorbehalten, oder ist das 
wirklich so unmöglich? Und warum schaut eigentlich der C Code den IDA 
z.B. rausschmeißt so anders aus als echter Source Code, warum ist dieser 
Pseudo C Code so anders?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
28 lesenswert
nicht lesenswert
Oh man... Aus einem Hamburger kann man auch nicht wieder eine Kuh 
machen! Lern einfach mal C und Assembler und du versteht es.

Autor: Karl M. (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Ganz einfach,

weil 95% der "alten"/ notwendigen Informationen fehlen.

Es wird ja nur der Machinencode gespeichert, nicht der Umstand des Wieso 
man etwas so macht.

Ich nutze die Macroerweiterung eines Compilers, um mir eine 
"Hochsprache" zu implementieren.

Oder Funktionale Macros, erklären werde ich das nun nicht weiter.

Autor: A. K. (prx)
Datum:

Bewertung
10 lesenswert
nicht lesenswert
Anders ausgedrückt: Warum ist es schwerer, Zahnpasta zurück in die Tube 
zu drücken, als raus? ;-)

Compilierung ist ein teilweise irreversibler Prozess, es dabei geht viel 
Information verloren. Ein Decompiler kann diese verlorene Information zu 
erraten versuchen, oder frei erfinden, aber nicht originalgetreu 
wiederherstellen.

: Bearbeitet durch User
Autor: GEKU (Gast)
Datum:

Bewertung
6 lesenswert
nicht lesenswert
Codeoptimierung und fehlende symbolsche Adressen  machen die 
Rückübersetzung nicht leicht.

Autor: Paul (Gast)
Datum:

Bewertung
14 lesenswert
nicht lesenswert
Bastler schrieb:
> nd die sind uns einfach nur nicht zugänglich und z.B.
> Regierungen (Und vielleicht einigen Chinesen) vorbehalten

Genau, wenn man nicht verstanden hat, warum etwas nicht geht, ist die 
Regierung schuld, weil sie verschweigt, daß sie es doch kann.

Autor: Ntldr -. (ntldr)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Hauptproblematik ist dass der Kompilierprozess stark verlustbehaftet 
ist. Da verschwinden nicht nur Kommentare, sondern durch Optimierungen 
und Umorganisationen des Codes ne Menge zusätzlicher Informationen. Ob 
du für deine Schleife ein for, while oder gar goto verwendet hast, ist 
im Maschinencode nicht mehr erkenntlich. Eventuell verschwindet deine 
Schleife auch komplett und der Code wird einfach direkt 4 Mal 
ausgeführt.

Menschen haben gegenüber der Software dann einen entscheidenen Vorteil: 
Jeder der sich mit Reverse Engineering auseinandersetzt wird selbst auch 
Programmieren. Somit kann man sich Konstrukte in der Disassembly (bzw. 
auch im Dekompilat) manuell in sinnvollen Code zurückdenken. Weiterhin 
kann der Mensch viel eher die Funktionsweise des Codes analysieren. 
Hierbei helfen auch z.B. Fehlermeldungen. Wenn in einer Funktion ein 
call zu print mit "[ERROR] SetVoltage: Voltage is negative" als Argument 
steht, kann ich davon ausgehen, dass die Funktion SetVoltage heißt und 
irgendeine Spannung setzt.

Übrigens: Ghidra hat auch nen recht brauchbaren Decompiler.

Autor: Theor (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bastler schrieb:
> [...] Und warum schaut eigentlich der C Code den IDA
> z.B. rausschmeißt so anders aus als echter Source Code, warum ist dieser
> Pseudo C Code so anders?

Das wäre vielleicht ein guter Ansatzpunkt für Dich, die Sache mal näher 
zu untersuchen.

Was sind die Unterschiede? Wie würdest Du sie beschreiben?

Falls Du schon in der Lage bist, nicht-trivialen Code zu schreiben, 
empfehle ich Dir solch ein Programm mal zu compilieren und mit IDA 
wieder zurück zu übersetzen. Variiere beim compilieren auch mal die 
Optimierungsoptionen.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Besonders lustig ist's wenn man ein Programm analysiert, das 
größtenteils furchtbar ineffizient ist, aber stellenweise ein paar enorm 
clevere Optimierungen hat (z.B. binäre Suche bei einem großen 
switch-case). Da ahnt man was der Compiler produziert hat und was 
"original" ist!

Autor: Bastler (Gast)
Datum:

Bewertung
-9 lesenswert
nicht lesenswert
Hallo,

Das ist ja das Problem ich interessiere mich schon lange fürs 
Programmieren, weiß aber nicht wo ich anfangen soll, dazu war ich in 
Sprachen (Englisch) Noch nie eine Leuchte, so gut wie alles übers 
Programmieren ist aber in Englisch. Daran ist es bisher immer 
gescheitert. Warum kann man denn nicht einfach einen Prozessor 
simulieren, dann den Code auf dem simulierten Prozessor ausführen 
lassen, dabei beobachten was passiert, und anhand von dem zurückrechnen, 
wie der Code lautet? Sicherlich wirst du keinen sofort wieder 
kompilierungsfähigen Code bekommen aber was du vielleicht hinkriegst 
wäre was lesbares? Ich meine ich kenne jemanden, der früher bei einer 
großen Firma war die beutellose Sauger baut. Chinesen haben Geräte 
dieser Firma kopiert. Darauf befand sich die selbe Software wie auf den 
original Geräten. Aber ein ganz anderer Prozessor der nicht 
programmkompatibel ist. Den Unkompillierten Code hat nur die Firma des 
Originalgerätes, und trotzdem lief auf den Fälschungen später der Code 
der Originalfirma. Nun frage ich mich, wie wurde der Code da drauf zum 
laufen bekommen, woher weiß die Originalfirma dass es ihr Code ist 
(Derjenige sagte mir, dass es eine art stempel in der .hex gibt, der 
ihnen das verifizieren ermöglichte) und wie haben die den Code überhaupt 
bekommen? Ich denke nicht dass sie den unkompiliert gekriegt haben, also 
können sie ihn nur aus einem verkauften Gerät auf irgendeine Weise am 
Lockbit vorbei gelesen haben, dann wie auch immer reverse engineert 
haben, und anschließend auf einen anderen Prozessor kompiliert haben. 
Dabei blieb der Stempel der Originalfirma der zum Verifizieren diente 
aber erhalten?!?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Bastler schrieb:
> Warum kann man denn nicht einfach einen Prozessor simulieren, dann den
> Code auf dem simulierten Prozessor ausführen lassen, dabei beobachten
> was passiert

Kann man, ist nur eine unendliche Fummelei. Wie ein millionenteiliges 
Puzzle aus sich verändernden dreidimensionalen Teilen!

> und anhand von dem zurückrechnen, wie der Code laute

Wie stellst du dir diese "Berechnung" vor?!

Bastler schrieb:
> weiß aber nicht wo ich anfangen sol

Ausrede, es gibt Mengen an Einsteiger Informationen. Auch auf Deutsch. 
Und Englisch lernt sich dabei fast von selbst.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne Englisch kein programmieren. Punkt.

> Warum kann man denn nicht einfach einen Prozessor
> simulieren, dann den Code auf dem simulierten Prozessor ausführen
> lassen, dabei beobachten was passiert

Kann man doch, macht man auch. Nur ist ein simulierter Prozessor noch 
kein komplettes Systems.

Hier ist zum Beispiel ein besonders schicker Simulator für den 6502 
Prozessor: http://www.visual6502.org/JSSim/

Da kannst du jedes einzelne Signal bei der Ausführung des kleinen 
Programms  mitverfolgen. Damit kannst du üben. Das Programm ist nur 
wenige Bytes groß. Der Befehlssatz des Prozessors ist mit Google leicht 
zu finden. Vielleicht bekommst du so ein Gefühl dafür, was es bedeutet, 
ein 1000 mal größeres Programm nachzuvollziehen.

> und anhand von dem zurückrechnen, wie der Code lautet?

Das wurde bereits beantwortet. Lerne Programmieren, dann wirst du es 
verstehen.

> Sicherlich wirst du keinen sofort wieder kompilierungsfähigen Code
> bekommen aber was du vielleicht hinkriegst wäre was lesbares?

Das Problem ist, dass sämtliche Labels fehlen. Eine Ansammlung von 
mehreren zig-tausend Befehlen ohne Beschriftung durchblickt kein 
normaler Mensch. Gleiches gilt für die Ansammlungen von Daten. Ohne 
Markierungen, was wozu dient, ist das einfach nur ein großer Hausen 
Zahlen, du hast das doch selbst gesehen!

> Darauf befand sich die selbe Software wie auf den
> original Geräten. Aber ein ganz anderer Prozessor der nicht
> programmkompatibel ist.

Das kann unmöglich sein. Die selbe Software ist nur auf einem 
kompatiblen Prozessor lauffähig.

> und wie haben die den Code überhaupt bekommen?

Da fragst du die falschen Leute. Woher sollen ausgerechnet wir das 
wissen? Wir waren nicht dabei.

> Ich denke

zu viel über Sachen nach, von denen du keinen blassen Schimmer hast.

> weiß aber nicht wo ich anfangen soll

Fange hiermit an http://stefanfrings.de/avr_workshop/index.html und 
arbeite dich dann durch die weiteren Infos auf der Seite durch.

: Bearbeitet durch User
Autor: loeti2 (Gast)
Datum:

Bewertung
11 lesenswert
nicht lesenswert
Wieso kann ich aus einem Essen das Rezept nicht rekonstruieren?

Autor: svensson (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Um es einfacher auszudrücken, weil es keine eineindeutige Beziehung 
zwischen Maschinencode und Hochsprachen-Code gibt.

Verschiedene C-Codeabschnitte können einen identischen Codeschnipsel 
ergeben. So lassen sich ganze Programmteile beliebig "umformulieren" und 
haben trotzdem den gleichen Maschinencode.
Beispielsweise kann die Zahl 5 in Variablen des Typs Byte, Word, 
Shortinteger, Integer oder auch als Gleitkommazahl gespeichert werden. 
Dadurch wird es bei Datenstrukturen schwierig zu erkennen, wie sie 
aufgebaut sind.

Hinzu kommt, daß die Hochsprachen mit Hilfe einiger weniger 
Grundfunktionen komplexere Funktionen in Standardbibliotheken abbilden, 
d.h. diese werden wieder und wieder in den Maschinencode eingebettet 
oder als Unterprogramme aufgerufen. Das zu entwirren, ist extrem 
schwierig, weil die aussagekräftigen Labels für Sprungmarken und 
Variablen fehlen.

Autor: Test (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Ganz einfach: Die chinesische und amerikanische Regierung haben sich 
gegen dich verschworen. Ist doch logisch. Warum auch sonst?!

Autor: wolle g. (wolleg)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ohne Englisch kein programmieren. Punkt.

Wieso Punkt?
Man muss die Bedeutung der Befehle kennen. Punkt
Natürlich ist es hilfreich, wenn man auch noch etwas Englisch kann.
Man stelle sich nur vor, die Japaner verwenden Japanisch, die Russen 
verwenden Russisch oder andere Arabisch, usw.
Früher gab es sogar problemlos Arbeitsspeicher, Programmspeicher, 
Kellerspeicher usw
alles ohne Englisch und leicht verständlich.

: Bearbeitet durch User
Autor: Bastler (Gast)
Datum:

Bewertung
-10 lesenswert
nicht lesenswert
Das Problem an der Sache ist einfch dass ich noch niemanden gefunden 
habe,
den ich dahingehend ausquetschen kann. Ich kenne jemanden der früher bei 
Renault in der Entwicklung war, seitdem kenne ich jeden 
Motorkennbuchstaben den Renault je verwendet hat auswendig, du kannst 
mich am Telefon nach einem Fehler fragen, und ich weiß was es ist, und 
ich kann dir sagen, wie du aus einem d7f Twingomotor 5 Ps und eine Menge 
Drehmoment mehr rausholst indem du die Nockenwelle um eine definierte 
Gradzahl verdrehst und einen Sensor tauschst. So jemanden gibt es aber 
im Bereich Programmieren nicht, der den ich bei Renault da kenne ist in 
Rente hat Zeit, den kann man gut ausfragen, wenn ich jetzt noch jemanden 
finden würde der sowas im Bereich Programmieren ist... Aber das gibts 
nicht, die haben alle was anderes zu tun, ich weiß ja noch nicht mal mit 
welcher Sprache ich anfangen soll, C C++ (Schwer, sagen alle) Java 
(Gibts für St Dinger schon garkeine Compiler...) oder sonst noch 
irgendwas anders? Kotlin, hab ich mal gehört, gibts für STm, PIC usw 
auch keinen Compiler, usw. Dann sagt der eine schon wieder Englisch 
braucht man unbedingt, der andere sagt braucht man nicht ubedingt, der 
nächste sagt sollte man können. Ein bisschen englisch kann ich, ich kann 
mich auch gut mit jemandem auf Englisch unterhalten, auch in einem 
amerikanischen Forum halbwegs verständlich auf Englisch schreiben, was 
ich aber nicht kann ist eine Englische Anleitung zum Programmieren 
lernen lernen was die ganzen befehle machen und gleichzeitig noch raten 
was englische Begriffe bedeuten von denen ich noch nie gehört habe, ich 
sehe schon hoffnungsloser Fall.

Autor: test (Gast)
Datum:

Bewertung
9 lesenswert
nicht lesenswert
Wie wäre es, wenn du das tust was alle anderen auch tun... einfach mal 
anfangen und dabei langsam lernen.
Und dafür braucht man nix, einfach irgendeine freie Entwicklungsumgebung 
auf den PC packen und anfangen.
Und dann nicht bei jedem Problemchen sofort jemanden Fragen. Einfach mal 
selbst die Lösung suchen, auch wenns zwei Wochen dauert. Nur so lernt 
man Probleme selbständig zu lösen.

Autor: Antoni Stolenkov (Gast)
Datum:
Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
Bastler schrieb:
> frage ich mich, warum es eigentlich so schwer möglich ist, Maschinencode
> zurück zu C zu Decompilieren.

Beim Compilieren wird die Bedieneroberfläche der Programmiersprache 
entfernt.

Das ist so als wenn Du einen Blick in Deinen aufgeschraubten Computer 
wirfst und Dich fragst was das Alles darstellen soll.

Ich geh Bettkarte stempeln.

Autor: A. S. (achs)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Was möchtest Du eigentlich?

Programmieren? Fange auf dem PC an, installiere Dir die Sprache, die Dir 
als erstes in den Sinn kommt, und lege los. Egal ob C, JAVA, Logo oder 
irgendwas grafisches für 4-jährige.

µController LEDs blinken lassen? kaufe Dir irgendeinen fertigen Bausatz, 
der Dir vor die Tastatur fällt und in Stückzahlen umworben wird.

Wenn Du dann erste Erfahrungen hast, dann kannst Du Dir noch immer eine 
geeignete Sprache oder eine geeignete Architektur auswählen, die ersten 
paar Wochen ist es egal, hauptsache Du springst in kalte Wasser.

Autor: Hans-Georg L. (h-g-l)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Decompilieren im Sinne aus einer Binärdatei Source code zu machen kannst 
du vergessen. Es gibt Tools die dir einen Assembler code generieren und 
den du mit einem eingebauten Debugger durchsteppen kannst. Das 
funktioniert aber nicht immer fehlerfrei und Datenbereiche versucht er 
auch zu dekompilieren. Ich habe das mal für C++ code und Windows mit 
x32dbg bzw x64dbg gemacht. Das kannst du nicht aus einem Buch lernen das 
musst du selber ausprobieren. Wenn dein Binärcode im debug mode erstellt 
wurde und noch die Symboltabellen enthält bekommst du sogar noch 
sinnvolle Namen sonst ist alles einfach durchnummeriert.

Autor: Axel S. (a-za-z0-9)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Bastler schrieb:

> ich interessiere mich schon lange fürs
> Programmieren, weiß aber nicht wo ich anfangen soll

Fang einfach überhaupt an.

> Warum kann man denn nicht einfach einen Prozessor
> simulieren, dann den Code auf dem simulierten Prozessor ausführen
> lassen, dabei beobachten was passiert, und anhand von dem zurückrechnen,
> wie der Code lautet?

Genau das macht ein Disassembler ja. OK, außer daß er den Prozessor 
nicht simuliert, das ist vollkommen unnötig. Man kann den 
Maschinencode 1:1 in Assemblercode zurück übersetzen. Nur ist Assembler 
eben nicht C. Oder C++. Oder Pascal. Rust. Java. $YOU_NAME_IT

Denn da geht es doch schon los: aus welcher Hochsprache resultiert denn 
der betrachtete Maschinencode? Oft kann man das erraten, manchmal aber 
auch nicht. Z.B. sind C und C++ so nah beieinander, daß es schon 
schwierig wird.

> Sicherlich wirst du keinen sofort wieder
> kompilierungsfähigen Code bekommen aber was du vielleicht hinkriegst
> wäre was lesbares?

Ernsthafte Programmierer können Assembler ihrer Zielplattform lesen. 
Insofern ist diese Anforderung trivial erfüllbar. Nur hilft das bei der 
eigentlichen Fragestellung kein bißchen weiter.

Das Beispiel wurde doch schon genannt: ein Decompiler gleicht dem 
Versuch, aus einer Portion eines Gerichts das Rezept zu rekonstruieren. 
Der Disassembler entspricht dann dem Chemiker, der den Gehalt 
verschiedener Nährstoffe bestimmen kann. Damit kannst du zwar eine 
enährungstechnisch gleichwertige Pampe produzieren, aber dem Rezept bist 
du damit kein Stückchen näher gekommen.

Das Reverse-Engineering von Kochrezepten ist dem Reverse-Engineering von 
Software dahingehend vergleichbar, daß die erforderlichen Kenntnisse und 
Erfahrungen sehr hoch sind. Sie sind nicht wesentlich von denen 
verschieden, die benötigt werden, um das entsprechende "Rezept" von 
Grund auf neu zu erfinden.

Da du (nach eigener Aussage) nie gelernt hast, zu programmieren, wirst 
du auch an der Aufgabe des Reverse-Engineerings scheitern. Und die 
Leute, die es könnten, haben weiß Gott besseres zu tun, als einem 
Skript-Kiddie beim Tunen seines E-Scooters zu helfen. Du hast verloren. 
Trag es mit Würde!

Autor: Thomas Z. (Firma: Unaffiliated) (usbman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur mal so als Hinweis:
IDA ist kein Decompiler sondern ein Disassembler. Für diese Disassembler 
gibt es ein Plugin genannt HexRays was versucht erkannte Funktionen in 
einer C ähnlichen Pseudo Sprache anzeigen zu lassen. Das funktioniert 
erstaunlich gut und man kann Variablen sogar sprechende Namen geben die 
dann wieder im Disassembler auftauchen. Das Plugin erzeugt aber manchmal 
auch kompletten Unsinn. Dann liegt es am Betrachter dem Decompiler auf 
die Sprünge zu helfen.

Dieses Decompiler Plugin ist als nur dann hilfreich wenn du wirklich gut 
programmieren kannst und wird für etwa 2500 Euro netto verkauft. Was 
natürlich die Frage aufwirft woher deine Version wohl stammt.....
Der Hersteller sagt zu diesem Plugin:  Es funktioniert manchmal ist aber 
besser als garnichts.

Decompiler gibt es zumindest für native Compiler nicht. Auch das HexRays 
Plugin ist relativ neu 8..10 Jahre.
Übrigens haben ernsthaft Anwender Signatur Files für die gängigen Libs 
der Compiler auf der Platte. Dann sieht der Disassembler Output gleich 
mal viel besser aus.

Thomas

Autor: M. K. (sylaina)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ist schon Freitag?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Bastler schrieb:
> Das Problem an der Sache ist einfch dass ich noch niemanden gefunden
> habe, den ich dahingehend ausquetschen kann.

Da gibt es etwas, das nennt sich "Google". Und noch etwas namens 
"Amazon", das kann dir sogenannte "Bücher" bis an die Haustür schicken. 
Programmieren lernt man besser mit einem gut durchdachten Lehrplan, und 
nicht indem man kreuz und quer Fragen stellt.

Bastler schrieb:
> weiß ja noch nicht mal mit welcher Sprache ich anfangen soll

Da du Controller programmieren und reverse engineeren willst: C.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Ernsthafte Programmierer können Assembler ihrer Zielplattform lesen.

Sicher nicht. Von dem Programmierer, der die Lohnbuchhaltung geschrieben 
hat, erwarte ich daß er sich mit Steuern, Renten und Krankenversicherung 
auskennt und mein Gehalt richtig berechnet. Auf welchem Rechner das dann 
ausgeführt wird, ist ihm (und auch mir) egal. Und das Gehalt ist für 
mich jedenfalls "ernsthaft".

MfG Klaus

Autor: minifloat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Warum also ist es so einfach den Code zu compilieren, aber extrem schwer
> die Software wieder zurück zu Source Code zu bekommen?

Warum also ist es so einfach die Zutaten zusammen zu rühren, aber extrem 
schwer den Kuchen wieder zurück zu getrennten Zutaten zu zerlegen?

Denk 'mal darüber nach, welche Informationen im Source Code enthalten 
sind, die dann im Hex File fehlen.

mfg mf

Autor: minifloat (Gast)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
M. K. schrieb:
> Ist schon Freitag?

Wenn du den Brückentag frei hast, ja. Also sowas ähnliches wie 
Freitag...

mfg mf

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bastler schrieb:
> ich weiß ja noch nicht mal mit welcher Sprache ich anfangen soll

Ich habe Dir etwas empfohlen. Du musst das lesen und ausprobieren, 
um weiter zu kommen.

Oder lies irgendeine andere Anleitung, die dir besser gefällt. Irgendwo 
musst du anfangen.

: Bearbeitet durch User
Autor: Stephan (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Du wirst den Roller nicht so einfach umbauen können.
Beitrag "BLDC Controller mit STM32F103C8T6 Geschwindigkeitsbegrenzer in der .hex"

Autor: Berufsrevolutionär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Warum also ist
> es so einfach den Code zu compilieren, aber extrem schwer die Software
> wieder zurück zu Source Code zu bekommen?

Naja Source-code ist nicht gleich Source-Code insbesonders bei 
Hochsprachen wie C, weil eben eine Hochsprache - Kompilierung keine 
bijektive Abbildung ist. Und statt was scheinbar falsches aka anders als 
erwartet auszugeben (bspw. while-loop statt ädequate foor-loop) macht 
der de-compiler lieber keine ausgabe anstatt Prügel zu beziehen dafür, 
daß er was sinngemäß richtig wiedergegeben hat, aber eben nicht auf den 
(überflüssigen) I-Punkt genau.

De-compiler sind auch nur Menschen, die scheuen sich auch ihren "Cheffe" 
dämlich ausschauen zu lassen - auch wenn er es verdient hat.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Du kannst den Maschinencode mit einer Auflistung der Bauteile eines 
Hauses vergleichen. Für jeden Stein, Schraube, Rohrstück, usw. ist ganz 
genau beschrieben, welche Abmessungen es hat und wo es positioniert ist.

Mit so einer Liste wäre man theoretisch imstande, das gleiche Haus 
erneut zu bauen. Aber du als Mensch kannst an so einer Liste nicht mehr 
das große Ganze erkennen. Dementsprechend schwierig sind Änderungen. 
Welche Steine müssten in der Liste geändert werden, damit ein anderes 
Rohr verlegt werden kann? Bei tausenden Steinen ist das schwer 
herauszufinden.

Dazu kommt, das in sicherheitsrelevanten Anwendungen oft ein 
Selbst-Schutz gegen Veränderungen integriert ist. Damit werden 
gefährliche Fehlfunktionen verhindert. Diesen Algorithmus müsste man 
dann auch noch knacken, falls vorhanden.

: Bearbeitet durch User
Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bastler schrieb:
> C++ (Schwer, sagen alle)

Ja, C++ ist schwer zu lernen.
Alleine schon, weil es eine Multiparadigmensprache ist.
Dennoch rate ich dir dazu.
Einen großen Teil der C Grundlagen lernst du automatisch mit.

Wer zuerst C lernt, und dann C++ hat größere (innere) Hürden zu 
überwinden, als anders rum.

Zeitfenster:
Wenn du dir Mühe gibst....
Dann benötigst du für das lernen der µC Grundfunktionen (fast egal 
welcher µC) und die erste Sprache (auch recht egal, welche), ca 3 Jahre.
Plus ca 1/2 Jahr für jede weitere µC Familie und weitere Sprache.

Nach ca 10 Jahren kannst du dann auf diesem Gebiet recht fit sein.
Wenn du ein Überflieger bist, mag es schneller gehen.

Autor: oszi40 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Disassembler für Kuchen nennt sich Rosinenpicker. Das Rezept wird er so 
kaum herausbekommen.
C3 2000 ist z.B. bei Z80 ein absoluter Spung nach 2000. Aber was ist 
irgendwo 44C3 eine Adresse oder ein Stück des Befehls oder ein Wert? Das 
nur der Erzeuger, für andere wird es mühsam.

Autor: Hans-Georg L. (h-g-l)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Im Anhang ein Beispiel wie so etwas aussieht.
Das ist allerdings x86 Assembler und Windows mit einem selbstgeschrieben 
Programm mit dem ich versucht habe proprietäre DLLs zu Analysieren.

@Thomas Z.
Es gibt für Windows eine freie Sparversion von IDA, hat mich allerdings 
nicht überzeugt. Damit lassen sich keine Plugins laden.

Autor: Nick M. (muellernick)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wenn schon die Hochsprache (von mir aus C) so leicht zu verstehen ist, 
dann versuch dich mal an "Obfuscated C". https://ioccc.org/
Vieleicht verstehst du dann, warum Maschinencode nur schwer zu verstehen 
ist. Obwohl das doch "eigentlich das Gleiche ist".

Nick

Autor: Roland F. (rhf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Dr. Sommer schrieb:
> Und noch etwas namens "Amazon", das kann dir sogenannte "Bücher"
> bis an die Haustür schicken.

Und es gibt auch den örtlichen Buchhändler, bei dem man auch alle Bücher 
kaufen kann und der dazu noch deutlich schneller ist (außerdem 
unterstützt man dadurch die heimische Wirtschaft).

> Da du Controller programmieren und reverse engineeren willst: C.

Und da empfehle ich immer noch (trotz des Alters) "Programmieren in C" 
von Kernighan & Ritchie. Zum verstehen der C-Grundlagen für mich immer 
noch der Maßstab.

rhf

Autor: batman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Warum kann man denn nicht einfach einen Prozessor
> simulieren, dann den Code auf dem simulierten Prozessor ausführen
> lassen, dabei beobachten was passiert, und anhand von dem zurückrechnen,
> wie der Code lautet?

Z.B. weil der Programmablauf von den jeweiligen Eingaben abhängt. Das 
ist ja gerade der Sinn und Zweck von EDV.
Dass man heutzutage schon Computer programmiert, um eine LED im Takt 
blinken zu lassen, täuscht vielleicht etwas über diesen eigentlichen 
Zweck hinweg.

Autor: Roland F. (rhf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,
Arduino Fanboy D. schrieb:
> Zeitfenster:
...
> ...3 Jahre.
> ...1/2 Jahr
> ...10 Jahren

Ich hoffe, du arbeitest nicht als Motivationstrainer.
:-)

rhf

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Roland F. schrieb:
> Ich hoffe, du arbeitest nicht als Motivationstrainer.

Er hat allerdings Recht.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Roland F. schrieb:
>  Motivationstrainer.

Mit dem Wissen wächst die Verzweiflung :-) Einige Studenten wie Claus W. 
haben im letzten Jahrtausend in 8 Wochen ein Betriebssystem mit Papier, 
Bleistift und Befehlstabelle komplett auseinandergenommen. Heute sind es 
nur ein paar GB mehr... :-)

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Roland F. schrieb:
> Ich hoffe, du arbeitest nicht als Motivationstrainer.
Ja, das ist keine meiner Kernkompetenzen!

Andererseits neige ich dazu Leute in ihren vorgefassten Meinungen zu 
bestärken, wenn sie mir richtig erscheinen.

Der Bastler kann englisch lesen und schreiben.
Dagegen fehlt es ihm an fachlicher Kompetenz/Vokabular.

Das sind ganz normale Voraussetzungen, fast schon gute, für einen "EDV" 
Anfänger.

Nicht so prickelnd, ist die Verweigerung anzufangen.
> Tausend mal schaut der Wille durch das Fenster,
> bis die Tat durch die Tür schreitet.

Das stimmt mich hier, in der Tat, etwas pessimistisch. Und diesen 
Pessimismus zeigt auch Bastler. Also muss ich ihn da bestätigen.

Auch der Versuch sich irgendwo anzuhängen "dass ich noch niemanden 
gefunden habe, den ich dahingehend ausquetschen kann" mündet in 
gegenseitigem Frust, erfahrungsgemäß. Bastler muss lernen, sich die 
Information selber zu beschaffen, und die Zeit kommt oben drauf.
> Wir lernen, in dem wir es tun.

Klar, könnte ich den Arduino Priester machen, und sagen:
So kommst du schnell zu ersten Erfolgserlebnissen!

Aber für die "Tiefe" ist dann auch die Zeit nötig.
Aus meiner Sicht:
1. Egal wo
2. Hauptsache, anfangen
Irgendwo werden einen die Aufgaben und Interessen dann schon hin führen.

Also ruhig, fremde *.hex Dateien analysieren.
Ist auch ein Startpunkt.
(dass ich ihn für suboptimal halte, ist dabei zweitrangig)

: Bearbeitet durch User
Beitrag #5990959 wurde von einem Moderator gelöscht.
Autor: Lothar J. (black-bird)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gebt euch keine Mühe, eure Vorschläge und Erfahrungen nimmt er doch 
nicht an, er sucht immer noch einen Dummen, der die Arbeit für ihn 
macht.
Genau das zeigen seine Beiträge zum Thema und die fehlenden Antworten 
auf eure Fragen.

Blackbird
PS: Interessant sind eure Beiträge trotzdem.

: Bearbeitet durch User
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bastler schrieb:
> seitdem kenne ich jeden
> Motorkennbuchstaben den Renault je verwendet hat auswendig,

Ganz fein. Toll gemacht!

Autor: Plah (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Zeitfenster:
> Wenn du dir Mühe gibst....
> Dann benötigst du für das lernen der µC Grundfunktionen (fast egal
> welcher µC) und die erste Sprache (auch recht egal, welche), ca 3 Jahre.
> Plus ca 1/2 Jahr für jede weitere µC Familie und weitere Sprache.
>
> Nach ca 10 Jahren kannst du dann auf diesem Gebiet recht fit sein.
> Wenn du ein Überflieger bist, mag es schneller gehen.

Bei mir im Studium waren für das erlernen der beiden Sprachen C und C++ 
15CP (also 450h) vorgesehen. Waren insgesamt 3 Klausuren im 1. und 2. 
Semester (Grundlagen, OOP, Datenstrukturen und Algorithmen). Wobei es da 
natürlich nicht nur um die Programmiersprachen ging.

Insgesamt waren es 5 Semester zu je 4 Monaten (2 Monate Semesterferien 
pro Semester), 1 Praxissemester und 1 Semester Bachelorarbeit und 
Wahlfächer. Und das war nur auf der FH - also auf Sparflamme.

Autor: Theor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Das Problem an der Sache ist einfch dass ich noch niemanden gefunden
> habe,
> den ich dahingehend ausquetschen kann. [...]

Mit etwas Geduld, wird Dich jemand finden. Das ist wie mit der Liebe. 
:-)
Naja. Das ist schon nützlich, so jemanden zu haben, aber auch, selbst 
anzufangen.

> ... ich weiß ja noch nicht mal mit
> welcher Sprache ich anfangen soll, {...]
Super. Du weisst schon mehr als ich: "Kotlin" lese ich zum erstenmal. 
:-)
Wie das so ist. 3 Fachleute und 4 Meinungen. :-)

Im Grunde ist es egal, welche Sprache Du als erstes lernst. Schau Dir 
einfach mal drei oder vier verschiedene an und nimm die, welche Dir 
intuitiv geeignet erscheint. Das kann auch BASIC sein, oder Python.
Das wesentliche ist für einen Anfänger nicht, eine Sprache zu wählen, 
die für einen bestimmten Zweck geeignet ist oder für eine bestimtme 
Plattform, meine ich.
Das wesentliche ist vielmehr, mit einer Denkweise Erfahrungen zu machen, 
die darauf hinauslääuft,
1. sich in einer sehr detailliert definierten Sprache auszudrücken und
2. Vorgänge in extrem kleine Schritte zu zerlegen, wie man das im 
täglichen Leben eigentlich nicht gewohnt ist, weil man schon vergessen 
hat, welche präzise und vorausschauende Planung allein das Gehen 
erfordert (OK. So bewusst lernen wir das nicht, aber nimm etwa das 
Autofahren als Vergleich, falls Du einen Führerschein hast).

> Dann sagt der eine schon wieder Englisch [...]
Naja. Das war früher, so in den 80er Jahren, noch wesentlich bedeutender 
als heute. (Denk dran, dass hier viele alte Säcke rumlungern). Es gibt 
schon recht viel deutsche Literatur. Allerdings wirst Du langfristig 
nicht darum herum kommen, Engslisch zu lernen.

> was
> ich aber nicht kann ist eine Englische Anleitung zum Programmieren
> lernen lernen was die ganzen befehle machen und gleichzeitig noch raten
> was englische Begriffe bedeuten von denen ich noch nie gehört habe, ich
> sehe schon hoffnungsloser Fall.

Da empfehle ich mal Youtube-Video "Vera F. Birkenbihl - Sprachen lernen leicht gemacht - 2004 - Landsberg"
Ich habe diesen Vortrag auch erst vor einigen Monaten entdeckt. Habe 
aber festgestellt, dass ich damals (ich war in Fremdpsprachen auch keine 
Leuchte), als ich wirklich Programmieren und Elektronik lernen wollte, 
faktisch genau so vorgegangen bin. Schritt für Schritt, Wort für Wort. 
Ohne Anleitung und nicht so wie in der Schule. Im Laufe der Zeit merkt 
man sich immer mehr. Das geht schon, wenn man die Sache nur stark genug 
verstehen will.

Also: Viel Erfolg.

Autor: Alter Hase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> warum es eigentlich
> so schwer möglich ist, Maschinencode zurück zu C zu Decompilieren.

Ein Compiler ist wie eine Traubenpresse, um Traubensaft herzustellen:

Trauben kommen in die Presse, zudrücken, Saft kommt raus, Trester (die 
zerquetschten Trauben) bleiben übrig und kommen auf den Kompost.

Aus dem Saft kannst Du auch keine Trauben mehr bauen, obwohl Du exakt 
weißt, wie der Saft hergestellt wurde. Ein Teil wurde vernichtet 
(verrottet auf dem Kompost) und nur der Saft wurde aufgehoben.


      Trauben  <==>   C-Code
      Presse   <==>   Compiler
      Saft     <==>   Maschinencode

Autor: Alter Hase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Darum auch: Du programmierst nicht für den Compiler, sondern für den 
Programmierer der Deinen Code lesen und verstehen muss (oft ist man das 
selbst, nach einiger Zeit).

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Einige Studenten wie Claus W.
> haben im letzten Jahrtausend in 8 Wochen ein Betriebssystem mit Papier,
> Bleistift und Befehlstabelle komplett auseinandergenommen.

Ich habe möglicherweise noch einen kommentierten Ausdruck des kompletten 
Quellcodes eines Unix-Kernels rumliegen. Den gabs damals in Buchformat, 
und nicht sonderlich dick. Hat sehr zum Verständnis der Innereien von 
Betriebssystemen beigetragen.

"You are not expected to understand this"
https://en.wikipedia.org/wiki/Lions%27_Commentary_on_UNIX_6th_Edition,_with_Source_Code

: Bearbeitet durch User
Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ich habe möglicherweise noch einen Ausdruck des kompletten Quellcodes
> eines Unix-Kernels rumliegen. Den gabs damals in Buchformat, und nicht
> sonderlich dick. ;-)

Das Kommentierte ROM Listing des Commodore 64 gab es auch mal als Buch. 
Das war ein dicker schmöker. Dessen Code dürfte vom Umfang her dem 
Roller ähnlich sein.

Das bring mich auf folgende Idee:

Bastler, schau Dir mal diese Seite an: 
https://www.pagetable.com/c64disasm/

Das ist der Disassemblierte Code des Commodore 64. Rechts daneben die 
Kommentare aus dem originalen Quelltext. Noch weiter rechts die 
Kommentare von unterschiedlichen sehr erfahrenen Spezialisten, die das 
Gerät in und auswendig kannten.

Kannst du mit solchen Kommentaren etwas anfangen? Dazu eine Testfrage: 
Wie lautet die Bildschirmmeldung nach dem Einschalten, die 
Betriebsbereitschaft signalisiert? Kannst du sie im Code finden?

Zweite Testfrage: Was müsstest du ändern, um die standard 
Hintergrundfarbe vom Bildschirm zu ändern. Findest du die Stelle?

Versuch mal kurz, diese Fragen zu beantworten. Achte auch mal darauf, 
wie wertvoll die fett hervorgehobenen Kommentare im Originalquelltext 
sind, welcher den anderen Kommentatoren damals nicht zur Verfügung 
stand. Dann wird dir vielleicht ein bisschen klar, wie schwer fremder 
Assembler Code zu analysieren ist.

: Bearbeitet durch User
Autor: svensson (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gäbe auch noch die Möglichkeit - die wird hier aber vermutlich nicht 
zutreffen! -, daß das Programm in Assembler geschrieben wurde UND der 
Programmierer ein Disassemblieren erschweren wollte.
In solchen Programmen findet sich oft "toter Code", der unsinne Loops 
erzeugt, oder selbstmodifizierenden Code -> auch sehr schön, um den 
Disassembler zu verwirren.

Warum hat man das gemacht? µP haben im Gegensatz zum µC i.d.R. keinen 
Schutz gegen das Auslesen. Und wer sein Programm schützen wollte...
Heute schützt man ein Produkt oft besser durch die Software im µC als 
durch Patente. Hochwertige µP-Software wird häufig durch Dongles 
geschützt, wobei es auch da extrem schwierig ist, die passenden Zeilen 
im Code zu finden, um die Abfrage zu deaktivieren oder das Ergebnis als 
okay zu liefern.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> woher weiß die Originalfirma dass es ihr Code ist

An der Benutzeroberfläche, dem Hardwareinterface und vor allem an den 
Fehlern.

Autor: Klaus R. (klaus2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mische einen Kuchenteig. Nehme anschließend 150g Zucker wieder heraus.

Klaus.

Autor: GEKU (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besonders schwer zu durchschauen sind Programmaufrufe oder Sprünge über 
Zeigervariable,  denn deren Inhalt ist nur zur Laufzeit verfügbar.

Autor: W.S. (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Bastler schrieb:
> Da ich gerade selber das Problem habe, eine .hex zerlegen zu wollen, da
> aber selber nicht weiterkomme, und auch keinen finde, der dazu bereit
> wäre, sich das mal näher anzusehen, frage ich mich, warum es eigentlich
> so schwer möglich ist, Maschinencode zurück zu C zu Decompilieren.

Also erstens, wenn du schon daran scheiterst, eine Hexdatei fachgerecht 
zu zerlegen - wobei deren Format ja nun wirklich seit gefühlten 100 
Jahren in allen Einzelheiten dokumentiert ist - dann solltest du 
zuvörderst darüber dich belesen, bis du es kapiert hast.

OK, die Programmierer des GCC waren bislang auch zu blöd, zu kapieren, 
wozu das CS:IP-Format und der dazugehörige Blocktyp im .hex eigentlich 
gedacht ist. Sonst hätten sie für die 32 Bit Controller gleich zum dafür 
gedachten Blocktyp gegriffen.

Und als nächstes solltest du dich fragen, wie du zu der sachlich 
unbegründbaren Annahme kommst, daß das Ausgangsmaterial für eine 
Hexdatei nur ein C-Quellcode sein könnte. Tip: Es gibt noch andere 
Programmiersprachen außer C.

W.S.

Autor: Karl M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GEKU schrieb:
> Besonders schwer zu durchschauen sind Programmaufrufe oder Sprünge über
> Zeigervariable,  denn deren Inhalt ist nur zur Laufzeit verfügbar.

Jein, der Code, zeigt einem doch die Ladevorgänge in die 16-Bit 
Register, wenn dann etwas nach indirekten Zugriffen aussieht, ist es ein 
einfaches den realen Ort zu berechnen.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
W.S. schrieb:
> OK, die Programmierer des GCC waren bislang auch zu blöd, zu kapieren,
> wozu das CS:IP-Format und der dazugehörige Blocktyp im .hex eigentlich
> gedacht ist

Der GCC arbeitet überhaupt nicht mit dem Hex Format. Wenn schon, dann 
binutils und objcopy.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe vor einer Weile mal den Code aus einem dieser $10-LCD-„Scopes“ 
mit einem ATmega64 nach C zurückübersetzt.

Das ging, weil der ohne Optimierung übersetzt war. Da war es tatsächlich 
möglich, mit etwas trial und error einen C-Code zu schreiben, der zu 
identischem Assembler-Code kompilierte. gcc erzeugt ohne Optimierung 
ganz gut erkennbare Pattern.

Solche Details wie Variablen- oder Funktionsnamen spukte das Verfahren 
natürlich nicht aus.

Oliver

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Bastler schrieb:
> Maschinencode zurück zu C zu Decompilieren

Was bringt dir das denn, wenn du kein C verstehst?

Bastler schrieb:
> Und warum schaut eigentlich der C Code den IDA z.B. rausschmeißt so
> anders aus als echter Source Code, warum ist dieser Pseudo C Code so
> anders?

Wenn du warmes und kaltes Wasser vermischst und hinterher lauwarmes 
Wasser hast, kannst du daraus ohne weiteres auch nicht wieder warmes und 
kaltes Wasser machen. Das ganze nennt sich Entropie. "You can not 
unscrumble the eggs!"

Autor: Antoni Stolenkov (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wolle g. schrieb:
> Stefanus F. schrieb:
>> Ohne Englisch kein programmieren. Punkt.
>
> Wieso Punkt?

Das ist ergonomischer.

Autor: Antoni Stolenkov (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit dem Transistor ist Englisch die Sprache der Elektronik. Das hat 
sich auch mit dem Computer nicht geändert. Im Gegensatz zur Elektronik 
hat die Sprache hier logische und physikalische Spuren hinterlassen.

Für einen Linguisten mag das vielleicht interessant sein, der Praktiker 
bleibt einfach beim Englisch und macht nichts lieber als einen Punkt.

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Antoni Stolenkov schrieb:
> Das hat sich auch mit dem Computer nicht geändert.
Zunehmend gibt es Datenblätter nur noch auf Chinesisch.

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Antoni Stolenkov schrieb:
>> Das hat sich auch mit dem Computer nicht geändert.
> Zunehmend gibt es Datenblätter nur noch auf Chinesisch.

Wenn man wirklich will, kann man schon finden..
https://www.ccc.de/hackabike/
https://www.bussgeldkatalog.org/roller-entdrosseln/

Das mit dem Asm-Code kann man ja mal selber machen. Viele kleine 
Codeschnipsel von Hex/Asm nach C, C++ oder Pascal o.ä. übersetzen und 
schauen wie gut das geht.

Es kann aber unbekanntes Know How im Code sein, z.B. ein bestimmter, 
besonders ausgefeilter Algorithmus, denn man selber - und das 
Übersetzungsprg auch nicht - gar nicht kennt.
Das Übersetzerprg könnte zumindest skippen (aber an welcher Stelle?) 
oder einen Ersatz vorschlagen (aus welcher Bibliothek?).

Die beste Übung ist wohl, viele kleine Programme von Asm nach C und C++ 
(und von mir aus Java) übersetzen und umgekehrt.

Das geht nicht immer astrein. Wenn man aber nach einer gewissen Zeit ein 
gewisses Gefühl dafür bekommt, warum das wohl so ist, dann wäre man 
eigentlich schon einen Schritt weiter.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt's eigentlich schon eine Programmiersprache, die ausschliesslich in 
Chinesisch formuliert ist? APL mag manchen so erscheinen, ist aber 
mathematisch inspiriert.

: Bearbeitet durch User
Autor: Hugo H. (hugohurtig1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Gibt's eigentlich schon eine Programmiersprache, die ausschliesslich in
> Chinesisch formuliert ist?

https://de.wikipedia.org/wiki/Chinese_BASIC

Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Gibt's eigentlich schon eine Programmiersprache, die ausschliesslich in
> Chinesisch formuliert ist?

Das würde die chinesischen Programmierer vom Weltvorrat an vorhandener 
Software ausschliessen - so blöd sind die nicht.

Auch teutsche Programmiersprachen sind ausgestorben, sogar bei Siemens.

Georg

Autor: rbx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Auch teutsche Programmiersprachen sind ausgestorben, sogar bei Siemens.

Gemäß eines bloggenden Insiders hat man sich in den 70ern sehr wohl die 
Frage gestellt, ob die Programmiersprachen eingedeutscht werden sollten.

Das Killerargument dagegen: bessere Unterscheidbarkeit Schlüsselwörter 
und eigene Token

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
A. S. schrieb:

> Gemäß eines bloggenden Insiders hat man sich in den 70ern sehr wohl die
> Frage gestellt, ob die Programmiersprachen eingedeutscht werden sollten.

Schlimmer noch: bei Microsoft hat man sich in VBA dafür entschieden, das 
zu tun!

Autor: Bastler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ja das sind Hacker

rbx schrieb:
> Arduino Fanboy D. schrieb:
>> Antoni Stolenkov schrieb:
>>> Das hat sich auch mit dem Computer nicht geändert.
>> Zunehmend gibt es Datenblätter nur noch auf Chinesisch.
>
> Wenn man wirklich will, kann man schon finden..
> https://www.ccc.de/hackabike/
> https://www.bussgeldkatalog.org/roller-entdrosseln/
Ja, das sind richtige Hacker, aber sowas kann ich bei weitem nicht und 
werde ich auch nie können. Die Deutsche Polizei braucht mich in 
Österreich nicht zu interessieren ich darf da 25 mitm E Scooter... Ich 
denke aber dieses Verfahren der Polizei Fahrzeuge einzuziehen und dann 
durch Sachverständige zu prüfen wird bald am Ende sein, wenn ich jetzt 
programmieren könnte würde mir schon so einiges einfallen um denen das 
Leben beim begutachten so richtig schwer zu machen (Lockbits, 
selbstlöschender Code, Prüfstandserkennung, Geofencing, Sperrsysteme die 
erkennen wenn das Fahrzeug von der Polizei mitgenommen wurde usw, usf) 
Das wird für die Ordnungshüter noch ganz schön schwierig in der Zukunft, 
einfach mal aufschrauben und sagen "Da is jan Tuning Vergaser drin!" 
wird dann nichtmehr gehen, die haben dann das gleiche Problem wie ich 
jetzt mit meinem Scooter, entweder kriegen sie die Daten aus dem 
Prozessor garnicht erst raus, oder aber sie stehen davor und sagen "OH, 
tuning Einsen und Nullen, nur wo sind die in dem 128kb großen hex File?"

Autor: A. K. (prx)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
A. S. schrieb:
> Gemäß eines bloggenden Insiders hat man sich in den 70ern sehr wohl die
> Frage gestellt, ob die Programmiersprachen eingedeutscht werden sollten.

Yep. Eine deutsche Assembler-Sprache gab es beispielsweise beim 
Telefunken Grossrechner TR-440. BRINGE statt MOVE. Der Rest vom Umgang 
war ähnlich, es wurde nicht gelinkt, sondern montiert.

: Bearbeitet durch User
Autor: Hugo H. (hugohurtig1)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bastler schrieb:
> Die Deutsche Polizei braucht mich in
> Österreich nicht zu interessieren ich darf da 25 mitm E Scooter.

Dann kauf Dir doch bitte einen der das kann - und gut ist es.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
A. S. schrieb:
> Das Killerargument dagegen: bessere Unterscheidbarkeit Schlüsselwörter
> und eigene Token

Hmm, damit können die Engländer, und Amerikaner leider nicht viel 
anfangen. Demnach müssten die doch eine andere Sprache bevorzugen, oder 
nicht?

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Nop schrieb:
> Schlimmer noch: bei Microsoft hat man sich in VBA dafür entschieden, das
> zu tun!

Und damit reichlich Ärger gestiftet beim internationalen Austausch von 
Excel Makros gestiftet.

: Bearbeitet durch User
Autor: Antoni Stolenkov (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Antoni Stolenkov schrieb:
>> Das hat sich auch mit dem Computer nicht geändert.
> Zunehmend gibt es Datenblätter nur noch auf Chinesisch.

Die haben sich aber ...

Georg schrieb:
> A. K. schrieb:
>> Gibt's eigentlich schon eine Programmiersprache, die ausschliesslich in
>> Chinesisch formuliert ist?
>
> Das würde die chinesischen Programmierer vom Weltvorrat an vorhandener
> Software ausschliessen - so blöd sind die nicht.

... ins gemachte Bett gelegt.

Autor: Martin V. (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Bastler
Wie so oft im Leben gibt es auch beim Programmieren zwei Seiten. Die 
Programmiersprache, die kann man lernen. Tja, und dann kommt noch das 
"Talent", wenn ich es mal so ausdrücken darf. Und das ist m. E. nicht 
erlernbar. Glaub mir, ich hab schon so einige "talentlose" Programme 
gesehen und mit einigen mußte ich auch arbeiten. Diese Programme 
erfüllten zwar die Anforderungen, waren aber null bedienerfreundlich. 
OK, du willst programmieren lernen, dann fange an. Hast du schon eine 
Idee? Nein, dann kennst du jemanden, der eine hat? Auch nicht? Nun, dann 
wird es schwer, denn ohne Ziel einen Weg zu finden ist meist planloses 
Hin-und Hergelaufe. Ohne ein Ziel wirst du den Weg nicht finden.
Trotzdem, nimm dir die hier von Stefanus vorgeschlagene Lektüre vor.

Stefanus F. schrieb:
> Fange hiermit an http://stefanfrings.de/avr_workshop/index.html und
> arbeite dich dann durch die weiteren Infos auf der Seite durch.

Vielleicht hilft dir auch dieses:
https://www.makerconnect.de/media/user/oldmax/PC%20und%20Mikrocontroller%20Teil%201%20und%202%20Stand%2026.07.2019.pdf

Ist ein wenig als Leitfaden zur Programmerstellung gedacht.
Ach ja, Programme zu disassembleren macht nur in ganz seltenen Fällen 
Sinn. Die Vorstellung, man könnte sich in professionelle Programme 
hacken, ist für einen Anfänger völlig illusorisch. Selbst Spezialisten 
fällt das nicht leicht, und bevor die sowas anfangen, schreiben sie 
lieber ein eigenes Programm. Da haben sie dann auch das, was sie haben 
wollen.
Zum Schluß noch eine Bemerkung zur Sprache "Englisch". Ja, das ist die 
Sprache der Elektronik und Software, aber mit Grundkenntnissen kommt man 
schon ganz gut zurecht. Ein Hindernis in einer Programmiersprache ist 
englisch sicher nicht.
Gruß oldmax

Autor: klausb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> A. S. schrieb:
>> Gemäß eines bloggenden Insiders hat man sich in den 70ern sehr wohl die
>> Frage gestellt, ob die Programmiersprachen eingedeutscht werden sollten.
>
> Yep. Eine deutsche Assembler-Sprache gab es beispielsweise beim
> Telefunken Grossrechner TR-440. BRINGE statt MOVE. Der Rest vom Umgang
> war ähnlich, es wurde nicht gelinkt, sondern montiert.

Schön mal vom T eakholz R echner 440 zu hören. Wieviel gab es davon?

Es ist doch kein Problem, weder im Assembler noch in C für jeden 
englischen Ausdruck ein deutsches Makro vorzuschalten.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin V. schrieb:
> Ein Hindernis in einer Programmiersprache ist
> englisch sicher nicht.

Die paar Schlüsselwörter kann man auswendig lernen und 
Programmieranleitungen gibt es genug in jeder beliebigen Sprache.

Der Knackpunkt sind hier eher die 3rd party Bibliotheken und 
Datenblätter.

Autor: Martin V. (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Stefanus F. schrieb:
> Der Knackpunkt sind hier eher die 3rd party Bibliotheken und
> Datenblätter.

So kompliziert ist das nun auch wieder nicht. Ein Anfänger liest sich, 
wenn er will, da hinein. Und wenn es um die Frage geht, "versteht er es 
dann auch?" kommen wir wieder zum Punkt "Talent".
Gruß oldmax

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
klausb schrieb:
> Schön mal vom T eakholz R echner 440 zu hören. Wieviel gab es davon?

46-60, je nach Quelle. Wohl hauptsächlich an Hochschulen.

Es gibt natürlich auch einen Emulator dafür: http://www.tr440.info/

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> Ich denke aber dieses Verfahren der Polizei Fahrzeuge einzuziehen
> und dann durch Sachverständige zu prüfen wird bald am Ende sein,

Wieso? Die behalten die einfach ein, bis die Prüfung vollumfänglich 
abgeschlossen ist. Du machst es denen schwer? Dann dauert das eben 25 
Jahre.

Stefanus F. schrieb:
>> Das Killerargument dagegen: bessere Unterscheidbarkeit Schlüsselwörter
>> und eigene Token
>
> Hmm, damit können die Engländer, und Amerikaner leider nicht viel
> anfangen. Demnach müssten die doch eine andere Sprache bevorzugen,
> oder nicht?

War das nicht OpenOffice/LibreOffice, die daran teilweise noch immer 
kranken? Schließlich haben die den Code von StarOffice übernommen und da 
wurde deutsch programmiert (benamt) und kommentiert...

Und ja, die sprachabhängigen Schlüsselworte in Excel sind ein kräftig 
leuchtendes Lowlight in der realen Welt. Genauso nervig ist die 
Stringumwandlung von "1.23" in eine Zahl, was ebenfalls nur 
sprachabhängig ist.

Autor: MeierKurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
>Genauso nervig ist die
> Stringumwandlung von "1.23" in eine Zahl, was ebenfalls nur
> sprachabhängig ist.

"1.23" sollte eigentlich kein Problem bringen, da intern mit 
us-amerikanischen Format gerechnet wird.
Man muss halt darauf achten, dass der String ins us-amerikanischen 
Format umgewandelt wird, also vorher ein replace des 
Application.International(xlDecimalSeparator) mit einem "." vornimmt - 
vorher natürlich Tausendertrennzeichen entfernen.
Klingt blöde - ist es aber nicht, wenn man sich klar macht, dass eine 
Anzeige (also ein ganz normaler String) jeder Zahl bzw. Datums immer 
länderspezifischen Ursprungs ist oder sein kann.
Das "weiß" der String natürlich nicht und kann es daher auch nicht 
verraten - insbesondere wenn sich Ursprung und Istzustand der 
Ländereinstellung unterscheiden.

Autor: Hugo H. (hugohurtig1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bastler schrieb:
> wenn ich jetzt
> programmieren könnte würde mir schon so einiges einfallen um denen das
> Leben beim begutachten so richtig schwer zu machen (Lockbits,
> selbstlöschender Code, Prüfstandserkennung, Geofencing, Sperrsysteme die
> erkennen wenn das Fahrzeug von der Polizei mitgenommen wurde usw, usf)

Spinner :-)

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hugo H. schrieb:
> A. K. schrieb:
>> Gibt's eigentlich schon eine Programmiersprache, die ausschliesslich in
>> Chinesisch formuliert ist?
>
> https://de.wikipedia.org/wiki/Chinese_BASIC

Da spart man sich sicher die interne Umsetzung der Schlüsselworte in 
Token-Werte. Jeder Befehl ein 16bit-Unicode-Buchstabe.

Autor: Hugo H. (hugohurtig1)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Carl D. schrieb:
> Jeder Befehl ein 16bit-Unicode-Buchstabe.

Das halte ich für ein Gerücht.

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hugo H. schrieb:
> Carl D. schrieb:
>> Jeder Befehl ein 16bit-Unicode-Buchstabe.
>
> Das halte ich für ein Gerücht.

Das war keine Tatsachenbeschreibung, sondern eine mir in den Sinn 
gekommene Option, die sich aus der Wortgewaltigkeit chinesischer 
Schriftzeichen ergeben könnte. Mein ZX81 vor fast 40 Jahren hat seine 
Basic-Tokens jedenfalls als 8-Bit Wert in den Speicher gelegt.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MeierKurt schrieb:
> S. R. schrieb:
>> Genauso nervig ist die Stringumwandlung von "1.23" in eine Zahl,
>> was ebenfalls nur sprachabhängig ist.
>
> "1.23" sollte eigentlich kein Problem bringen, da intern mit
> us-amerikanischen Format gerechnet wird.

Sagen wir's mal so... ich habe bei uns ein paarmal gut nach dem Fehler 
gesucht, weil die eine oder andere Tool-Versionsnummernverwaltung bei 
uns genau darauf basiert.

Und es nicht funktioniert hat, weil Schweden wie Deutschland ein 
Dezimalkomma benutzt, die ursprünglichen Entwickler aber nicht.

> Das "weiß" der String natürlich nicht und kann es daher auch nicht
> verraten - insbesondere wenn sich Ursprung und Istzustand der
> Ländereinstellung unterscheiden.

Eben. Spaßig ist auch, wenn der Build immer montags kaputtgeht, weil 
dann "mån" im Datumsfeld steht... aber daran ist nicht Excel schuld.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Auch teutsche Programmiersprachen sind ausgestorben, sogar bei Siemens.

Auch ansonsten war die Siemens-Dokumentation in erstaunlich sperriger 
Form geschrieben. Ich erinnere mich noch an den Begriff 
Prozeßsignalformersteuerung im (natürlich auf Microfiche gelieferten) 
Handbuch einer R10VH. Es hat ewige Zeit gedauert, bis ich verstand, was 
der Begriff bedeuten sollte...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Auch teutsche Programmiersprachen sind ausgestorben, sogar bei Siemens.

In der Lehre werden gelegentlich noch so Gräuel wie "Logo" (hat nichts 
mit Siemens Logo zu tun) verwendet, welches eine deutsche Variante hat. 
Das hat den Vorteil, dass auch Seiteneinsteiger-Informatik-Lehrer, 
welche kein Englisch können, damit klar kommen.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Yep. Eine deutsche Assembler-Sprache gab es beispielsweise beim
> Telefunken Grossrechner TR-440. BRINGE statt MOVE. Der Rest vom Umgang
> war ähnlich, es wurde nicht gelinkt, sondern montiert.

In meiner Jugend(tm) war in vielen Büchern noch die Sprache von "binden 
und laden". Statisches Linken wurde mit Hilfe des sog. "Bindeladers" 
durchgeführt.

Auch im Jahr 2009 wurden diese Begriffe noch in Vorlesungen verwendet:
https://www.informatik.uni-kiel.de/~wg/Lehre/Vorlesung-SS2009/Folien_20090420.pdf

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> In der Lehre werden gelegentlich noch so Gräuel wie "Logo" (hat nichts
> mit Siemens Logo zu tun) verwendet, welches eine deutsche Variante hat.
> Das hat den Vorteil, dass auch Seiteneinsteiger-Informatik-Lehrer,
> welche kein Englisch können, damit klar kommen.

Naja, ersetzen wir lieber "klar kommen" durch "klar kommen sollten".

Es gab etliche Versuche, im Schulunterricht deutschsprachige 
Programmiersprachen einzuführen, die aber glücklicherweise allesamt 
gescheitert sind, da es außer den paar Schulbüchern keinerlei weitere 
Literatur dazu gab und das ganze keinerlei Relevanz außer der Schule 
hatte.

Bei vielen derartigen Versuchen steckt aber einfach auch ein gewisser 
politischer Klüngel dahinter. Ich erinnere mich noch an die Einführung 
einer völlig exotischen Programmiersprache an Schleswig-Holsteiner 
Schule, so gegen Mitte/Ende der 1980er Jahre. Wie sich mittlerweile 
herausstellte, war der entsprechende Entscheidungsträger im 
Kultusministerium verwandt mit dem Geschäftsführer des Unternehmens, das 
den entsprechenden Compiler oder Interpreter herstellte.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Das hat den Vorteil, dass auch Seiteneinsteiger-Informatik-Lehrer,
> welche kein Englisch können, damit klar kommen.

Och, das war schon bei APL der Fall. Dessen Quellcode verstehen 
englische Muttersprachler genauso wenig wie Deutsche, und der Lehrer, 
der sich damals (unabhängig von 3 Schülern) an meiner Schule damit 
befasste, war unvermeidlich Seiteneinsteiger.

: Bearbeitet durch User
Autor: Georg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
>> Schön mal vom T eakholz R echner 440 zu hören. Wieviel gab es davon?
>
> 46-60, je nach Quelle. Wohl hauptsächlich an Hochschulen.

Ich kann mich dunkel erinnern, dass der Uni Tübingen so ein Rechner fürs 
Rechenzentrum politisch aufs Auge gedrückt wurde. Die Zentraleinheit war 
aber so schwer (nicht nur Teakholz), dass der Kran umstürzte und das 
Dach des Rechenzentrums durchschlug. Das löste bei den Verantwortlichen 
zunächst Jubel aus, weil man dachte, jetzt wäre man den ungeliebten 
Rechner los, aber das war ein Irrtum - es wurde von den gleichen Stellen 
beschlossen alles zu reparieren.

Alles Geschichte, meines Wissens war das sowieso der letzte 
Telefunken-Rechner.

Georg

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:
Jetzt ist mir der Name der Programmiersprache wieder eingefallen: COMAL.

https://de.wikipedia.org/wiki/COMAL

https://www.booklooker.de/B%C3%BCcher/Borge-Christensen+COMAL-0-14-Handbuch-Herausgegeben-vom-Landesinstitut-Schleswig-Holstein-f%C3%BCr-Praxis/id/A02fE9pj01ZZJ

Aus inhaltlicher Sicht war die Einführung von COMAL kein völliger 
Unsinn, da es gegen Ende der achtziger Jahre einen großen Umbruch in den 
Schulen gab. Auf der einen Seite waren (schulabhängig) sehr viele 
Commodore PET/CBM oder Apple II(-Nachbauten) vorhanden, auf der anderen 
Seite wurden schon neue PCs mit MS-DOS beschafft. COMAL konnte auf allen 
Systemen genutzt werden.

Trotzdem gab es hier in S-H eben das "Gschmäckle", weil der deutsche 
Hersteller/Händler eben eng mit den Entscheidungsträgern liiert war.

Nun die Frage:
Kennt hier jemand COMAL noch aus der eigenen Schulzeit?
In welchem Bundesland war das?

: Bearbeitet durch User
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Ich kann mich dunkel erinnern, dass der Uni Tübingen so ein Rechner fürs
> Rechenzentrum politisch aufs Auge gedrückt wurde.

Während meiner Studienzeit wurde für das Physikzentrum ein neuer 
zentraler Server ausgeschrieben. Dabei musste es sich gemäß politischer 
Vorgabe aber um ein deutsches Produkt handeln.

Daraufhin wurde ein "AEG SPARCserver 1000" statt des "Sun SPARCserver 
1000" beschafft...

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Dabei musste es sich gemäß politischer
> Vorgabe aber um ein deutsches Produkt handeln.

Sicher dass nicht nur der Händler deutsch sein musste? Das gibt's immer 
noch, Forschungsprojekte an Hochschulen dürfen nur bei europäischen 
Zwischenhändlern statt direkt in China bestellen. Der Zwischenhändler 
freut sich über die Marge...

Georg schrieb:
> Ich kann mich dunkel erinnern, dass der Uni Tübingen so ein Rechner fürs
> Rechenzentrum politisch aufs Auge gedrückt wurde.

Oh Graus... Behörden-Bürokratie am Werk...

Andreas S. schrieb:
> , da es außer den paar Schulbüchern keinerlei weitere
> Literatur dazu gab und das ganze keinerlei Relevanz außer der Schule
> hatte.

Seit wann interessiert irgendjemanden die Relevanz von Schulstoff?

An meiner Ex-Schule gab es den Informatikunterricht auch schon seit den 
80ern. 20 Jahre später waren die Konzepte anscheinend noch die gleichen, 
man hat wohl nichts dazugelernt. Das Beklagen von miserablem 
Informatikunterricht könnte Bibliotheken füllen - lassen wir das :-)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Georg schrieb:
> Die Zentraleinheit war aber so schwer (nicht nur Teakholz),

Ich hatte jahrelang ein recht kompaktes Netzteil der TR-440 im Keller 
rumliegen. Ein Drehstrom-Linearnetzteil für -5,2V ECL. Das war richtig 
schön schwer. Zig Stück davon...

Siehe obere Reihe in
http://www.vaxman.de/historic_computers/telefunken/tr440/tr440.jpg

: Bearbeitet durch User
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Andreas S. schrieb:
>> Dabei musste es sich gemäß politischer
>> Vorgabe aber um ein deutsches Produkt handeln.
>
> Sicher dass nicht nur der Händler deutsch sein musste?

Ja, da bin ich ganz sicher. Das Teil wurde mit AEG-Beschriftung 
geliefert, und beim Login erschien auch irgendwo ein "AEG SunOS" statt 
"Sun SunOS". Natürlich war allen Beteiligten klar, dass es sich nur um 
ein umgelabeltes Sun-Produkt handelte, denn schließlich sollte das 
System auch so kompatibel wie möglich sein. Ich weiß aber nicht, ob auch 
jede Seite in der Schrankwand voll Handbücher entsprechend umetikettiert 
war.

Autor: Martin K. (martin_k662)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem nennt sich 'semantische Lücke' und beschreibt i.w. den 
Verlust von Informationen zwischen den verschiedenen Darstellungsebenen 
(die meisten Daten gehen beim Optimieren und kompilieren verloren,z.b. 
Typinformationen). Aus llvm bytecode könnte man z.B. auch Dinge in 
andere Sprachen übersetzen, da dort noch nahezu alle Typinformationen 
vorhanden sind.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin K. schrieb:

> Das Problem nennt sich 'semantische Lücke' und beschreibt i.w. den
> Verlust von Informationen zwischen den verschiedenen Darstellungsebenen
> (die meisten Daten gehen beim Optimieren und kompilieren verloren,z.b.
> Typinformationen).

Der Witz ist: Es geht eigentlich überhaupt keine (nützliche) Information 
verloren, es wird nur (unnütze) Redundanz entfernt. Schließlich läuft 
das Binary ja und tut, was es soll (im Idealfall). Sprich: all das 
entfernte Zeug ist für den Endzweck nicht nötig, ja es stört sogar. Es 
würde die Sache ganz sicher größer als nötig machen und (sehr 
wahrscheinlich) auch langsamer als möglich.

Alles eine Frage des Zwecks. Normalerweise ist der Zweck eines 
Programms, seine Aufgabe zu erledigen und dabei möglichst wenige 
Resourcen zu verbrauchen.

Dass es so viel redundantes Zeug zu entfernen gibt, zeigt eigentlich nur 
eins: Die Beschreibungssprache für das Problem taugt nicht sehr viel, 
jedenfalls nicht unter dem Aspekt, das Problem für das Zielsystem 
effizient zu beschreiben.

Allerdings taugt sie dazu, es menschenverständlich zu beschreiben 
(Hardcore -C/C++ mal ausgenommen, das dient auch eher nur dazu, die 
Intentionen des Programmierers zu verdunkeln).

> Aus llvm bytecode könnte man z.B. auch Dinge in
> andere Sprachen übersetzen, da dort noch nahezu alle Typinformationen
> vorhanden sind.

Es gibt in praktisch jeder Sprache und mit jeder Toolchain viele 
Möglichkeiten, menschenverwertbare Information mit in das Binary zu 
füllen, wenn man das will. Nur bläht das halt mit Sicherheit den Code 
auf und macht ihn i.d.R. auch langsam. Deswegen klemmt man sich das 
normalerweise, außer zu Debug-Zwecken.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Der Witz ist: Es geht eigentlich überhaupt keine (nützliche) Information
> verloren, es wird nur (unnütze) Redundanz entfernt.

Du siehst Kommentare im Quelltext also als völlig nutzlos an.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Du siehst Kommentare im Quelltext also als völlig nutzlos an.

Für den Endzweck des Programms sind sie ganz offensichtlich nutzlos, da 
der ja ganz offensichtlich auch ohne diese Information erfüllt werden 
kann.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Es geht eigentlich überhaupt keine (nützliche) Information
> verloren, es wird nur (unnütze) Redundanz entfernt.

Ist eine Frage der Sichtweise. Ich brauche diese Informationen, um den 
Code zu verstehen. Also sind sie nicht unnütz.

> Dass es so viel redundantes Zeug zu entfernen gibt, zeigt eigentlich
> nur eins: Die Beschreibungssprache für das Problem taugt nicht sehr
> viel, jedenfalls nicht unter dem Aspekt, das Problem für das
> Zielsystem effizient zu beschreiben.

Du musst ein Roboter sein, wenn du das ernst meinst.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:

> Ist eine Frage der Sichtweise.

Ganz genau. Ich formulierte es so:

>> Alles eine Frage des Zwecks

> Ich brauche diese Informationen, um den
> Code zu verstehen.

Du vergißt: es nicht nicht der Endzweck des Codes, von dir verstanden zu 
werden. Der ist: möglichst effizient zu laufen.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
c-hater schrieb:
> Du vergißt: es nicht nicht der Endzweck des Codes, von dir verstanden zu
> werden.

Doch. Code der nicht gepflegt werden kann, ist Einweg-Müll - fast nichts 
wert.

> Der ist: möglichst effizient zu laufen.

Effizienz rangiert in den allermeisten Anwendungen nicht auf Platz 1, 
nicht auf Platz2 , auch nicht auf Platz 3, sondern irgendwo ganz weit 
hinten. Aber dass deine Ansichten ziemlich weit weg von der Realität 
heutiger Softwareentwickler entfernt ist, das wissen wir ja schon 
länger.

Denke mal wirtschaftlich, dann bekommst du vielleicht auch mal wieder 
einen richtigen Job.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:

> Effizienz rangiert in den allermeisten Anwendungen nicht auf Platz 1,
> nicht auf Platz, auch nicht auf Platz 3 sondern irgendwo ganz weit
> hinten.

Weil es so viele Idioten gibt, die das so sehen, haben wir heute halt 
die Software, die wir eben haben.

All die Fortschritte der Leistungsfähigkeit der Hardware wurden 
unverzüglich dadurch aufgezehrt, dass er dazu verwendet wurde, es dummen 
und faulen Programmierern leichter zu machen, anstatt dazu, den 
Anwendern schnellere Programme zu Verfügung zu stellen.

> Aber dass deine Ansichten ziemlich weit weg von der Realität
> heutiger Softwareentwickler entfernt ist, das wissen wir ja schon
> länger.
>
> Denke mal wirtschaftlich, dann bekommst du vielleicht auch mal wieder
> einen richtigen Job.

Ich habe einen richtigen Job. Ich brauche mich nicht so zu 
prostituieren, wie du das tust...

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Weil es so viele Idioten gibt, die das so sehen, haben wir heute halt
> die Software, die wir eben haben.

Das sind nicht Idioten, sondern Softwareentwickler die damit ihren 
Lebensunterhalt verdienen (müssen).

Im Hobby dürfen gerne andere Maßstäbe gelten und sicher gibt es in der 
kommerziellen Softwareentwicklung auch zahlreiche kleine Ecken, wo auf 
Performance optimiert werden sollte. Das gilt jedoch nicht für die große 
Masse der Software.

> All die Fortschritte der Leistungsfähigkeit der Hardware wurden
> unverzüglich dadurch aufgezehrt, dass er dazu verwendet wurde, es dummen
> und faulen Programmierern leichter zu machen

Ich korrigiere: geschäftstüchtige Programmierer

> anstatt dazu, den Anwendern schnellere Programme zu Verfügung zu stellen.

Dafür ist Software sehr viel billiger geworden. Ich erinnere mich an den 
ersten IBM PC, den mein Vater für seine Firma anschaffte. Der Rechner 
kostete ein Monatsgehalt, das Textverarbeitungsprogramm drei 
Monatsgehälter und das Schach-Spiel ein viertel Monatsgehalt.

Wer würde heute für einen PC mit Textverarbeitung und Schachspiel (sonst 
nichts weiter) rund 18000 Euro ausgeben? Du nicht, habe ich Recht?

Abgesehen davon hast du maßlos übertrieben. Mein erster PC keine Musik 
in CD Qualität abspielen - geschweige denn erzeugen. Mein jetziger PC 
ist Pi mal Daumen 500x so schnell. Dafür stellt er Videospiele in 
damaliger Kino-Qualität samt Musik die zur Szene passen generiert wird 
ohne das geringste Ruckeln. So viel zum Thema, dass die ganze Leistung 
vergeudet wird.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Stefanus F. schrieb:

> Ich korrigiere: geschäftstüchtige Programmierer

Ich hasse die Ferenghi.

Autor: Nils (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solange die Experten hier meinen, das ein Compiler aus Eiern ein Rührei 
macht und man das nicht trennen kann ist mein Job ja sicher.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Ich hasse die Ferenghi.

Der war guuuuut!

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Auch ansonsten war die Siemens-Dokumentation in erstaunlich
> sperriger Form geschrieben.

IBM kann das aber auch... "Leitwegeinrichtung" in OS/2.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso ist es so schwer, aus einer Tüte Paniermehl ein Brötchen zusammen 
zu setzen.?😄

Autor: Christian M. (Firma: magnetmotor.ch) (chregu) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Der Rechner
> kostete ein Monatsgehalt, das Textverarbeitungsprogramm drei
> Monatsgehälter und das Schach-Spiel ein viertel Monatsgehalt.

Na, wer genügend Zeit und Geld hat auch noch Spiele zu kaufen, für den 
ist es wohl nicht teuer!
Ich nie weder Zeit noch Geld in Spiele investiert.

Gruss Chregu

Autor: Martin V. (oldmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich bin schon erstaunt, welche Vorstellung hier auch von Fachleuten 
verbreitet werden. Ich muß c-heater Recht geben, wozu braucht ein 
Prozessor symbolische Adressen und Kommentare? Er liest Befehlscode, 
also Maschinencode,und führt einen nach dem anderen aus.Was interessiert 
ihn der Programmierer mit seiner Denkweise, alles noch Mal mit 
Kommentaren erklären zu müssen, was sowieso klar ist und eine Adresse 
symbolisch zu zu verwalten ist für den Prozessor genauso unsinnig.
Wenn ein Programmierer meint, einen Maschinencode deassemblieren zu 
müssen, dann soll er doch Mal denken wie ein Prozessor!
Gruß oldmax

: Bearbeitet durch User
Autor: svensson (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwie haben ja alle recht.

Die Lösung des Problems wären interpretierende Programmiersprachen (gibt 
es die für µC überhaupt?), hier kann jederzeit der Quellcode samt 
Kommentaren geändert werden. Leider erkauft man sich das für einen 
Performanceverlust um den Faktor 100.
Allerdings ist es nahezu unmöglich, geistiges Eigentum bei 
interpretierenden Sprachen zu schützen.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Martin K. schrieb:
>
>> Das Problem nennt sich 'semantische Lücke' und beschreibt i.w. den
>> Verlust von Informationen zwischen den verschiedenen Darstellungsebenen
>> (die meisten Daten gehen beim Optimieren und kompilieren verloren,z.b.
>> Typinformationen).
>
> Der Witz ist: Es geht eigentlich überhaupt keine (nützliche) Information
> verloren, es wird nur (unnütze) Redundanz entfernt. Schließlich läuft
> das Binary ja und tut, was es soll (im Idealfall). Sprich: all das
> entfernte Zeug ist für den Endzweck nicht nötig, ja es stört sogar. Es
> würde die Sache ganz sicher größer als nötig machen und (sehr
> wahrscheinlich) auch langsamer als möglich.

Widerspruch: es geht das Entscheidendste verloren, was der Compiler 
benutzt und der Programmierer kreiert bzw. einsetzt, und das sind 
Datentypen. Datentypen sind dafür verantwortlich, dass der später 
Maschinencode so aussieht, wie er aussieht. Zweitens die Struktur des 
Codes in der Hochsprache, wie Klassen, Funktionen, Kontrollstrukturen, 
etc. . Beides benutzt der Compiler nicht einfach nur, um irgendwelchen 
1:1 Maschinencode daraus zu erzeugen, sondern ist auch zusammen mit dem 
abstrakten Maschinenmodell der Hochsprache Grundlage für alle 
Optimierungen.

Natürlich kann das niemand verstehen, für den

1) alles ein "int" ist, und
2) sollte 1) nicht zutreffen, dann eben ein String

Autor: Arduino Fanboy D. (ufuf)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Natürlich kann das niemand verstehen, für den ...

Ach, der c-hater mag eine neurotische Fehlanpassung haben...
Aber wie ein Kompiler in etwa funktioniert, wird er schon wissen.
Und dass man aus einer *.hex kein hübsches/wartbares C oder C++ Programm 
generieren kann, auch.

Sein Interesse, vermute ich mal, liegt eher im Bereich Zwietracht sähen, 
polemisieren usw.

Autor: batman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nils schrieb:
> Solange die Experten hier meinen, das ein Compiler aus Eiern ein Rührei
> macht und man das nicht trennen kann ist mein Job ja sicher.

Leider sind die Jobs nicht sicher vor solchen "Experten", wie man an 
manchen Produkten erkennt.

Autor: A. S. (achs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gehen nicht nur Kommentare und benamung verloren, sondern auch alles 
HW- und Projektspezifische.

Der Code ist ggf. portabel, z.B. bezüglich endianess. Das ist nicht mehr 
rekonstruierbar.

Anderes Beispiel: mit einem Rezept im Backbuch kannst Du einen Kuchen 
backen. Durch Analyse des Kuchens aber nicht diese Rezeptseite 
rekonstruieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.