Meine letzte Frage zu Assembler…oder Assembly ist assembler und assembly das gleiche und 2 Frage:
Kann man ein Netzwerk in Assmebler machen ein localisiertes netwerk ein hauptpc und ein nebenpc der allles lädt jedoch ist es möglich muss fast möglich sein(Windows 95)
geb es einen localen Server der über Microsoft läuft…
Also MUSS es möglich sein!!!enn es es schon in den 1995 gegeben hat…wenn nach dem wisssen der 90 es möglich ist muss es möglich sein.
Hallo
Meine letzte Frage zu Assembler…oder Assembly ist assembler
und assembly das gleiche und 2 Frage:
Assembly ist wohl der englische Name für Assembler. Dabei handelt es sich um eine Programmiersprache. Lies mal hier: http://de.wikipedia.org/wiki/Assemblersprache
Kann man ein Netzwerk in Assmebler machen
Aus Deinem Geschreibsel werde ich nicht wirklich schlau. Was möchtest Du denn genau machen? Und warum möchtest Du das in Assembler machen?
CU
Peter
Hallo Fragewurm,
Also MUSS es möglich sein!!!enn es es schon in den 1995
gegeben hat…wenn nach dem wisssen der 90 es möglich ist muss
es möglich sein.
Es gibt kein einziges Problem, welches sich in eine beliebigen Programmiersprache umsetzen lässt, welches nicht auch in Assembler gelöst werden kann!
Das Ganze ist nur eine Frage des Aufwands.
Ein Programmierer schafft im Durchschnitt etwa 10 Zeilen Code pro Tag. Darin ist Planung, Codierung, Compilieren, Dokumentation erstellen und Debuggen/Testen enthalten.
Je nach Hochsprache entspricht eine einzelne Zeile Code aber 10-50 Zeilen Assembler.
In Assembler hat man also 10-50 mal so lange bis das Programm läuft.
Bei grösseren Projekten rechnen man den Aufwand schnell mal in Mannjahren, da wird man in Assembler halt ganz schön alt dabei 
MfG Peter(TOO)
Hallo,
Bevor es Plattformen wie .NET oder Java gab, wurden Programme, die ín Hochsprachen wie C++ geschrieben wurden, direkt in Maschinensprache übersetzt. Wenn man also für mehrere Plattformen Code schreiben wollte, waren neben bestimmten Richtlinien auch Compiliervorgänge für jede Plattform erforderlich.
Mit der Einführung von Zwischencode - maschinennahem Code, der Assembly - bei z. B. .NET oder Java hat sich da einiges vereinfacht.
Ein Assembler ist ein Tool, das ein in Hochsprache geschriebenes Programm in eine Komponente übersetzt mit maschinennaher Sprache (Assembly Language) - eben ein Assembly - übersetzt. Typischerweise wird dieses Assembly nochmals zur Laufzeit in die eigentliche ausführbare Maschinensprache übersetzt. Dafür gibt es Laufzeitumgebungen wie .NET oder Java. Man spricht in diesem Zusammenhang von IL (Intermediate Language von .NET) oder Bytecode (Java), der dann beim Doppelklick auf das ausführbare Programm in die eigentliche Maschinensprache übersetzt und dann ausgeführt wird.
Der Vorteil ist, dass man sich bei der Laufzeitumgebung auf Standards verlassen kann, die Laufzeitumgebung kümmert sich dann um das spezifische Übersetzen in die für das jeweilige Endsystem geeignete Maschinensprache. Man hat also nur noch einen Compiliervorgang und kann das Assembly auf unterschiedliche Plattformen ausliefern.
Vor diesen Laufzeitumgebungen sprach man nicht von Assemblies, sondern von Executables und Binaries. Es ist möglicherweise etwas verwirrend, weil auch damals mit Assembler schon eine maschinennahe Sprache gemeint war in der man maschinennahe programmieren konnte, die aber den Zwischenschritt Bytecode / IL nicht kannte.
Was du allerdings mit einem Server für Assembler meinst, weiß ich nicht. Höchstens einen Application Server, auf dem du Netzwerk(Server)komponenten (Programme = Assemblies) zur Verfügung stellst, auf die von Clients (andere Assemblies auf den konsumierenden PCs) zugegriffen wird. Das kann - wenn man einige (z. T. viele) Dinge beachtet - durchaus plattformunabhängig sein. Und alle diese Komponenten laufen im Endeffekt in Maschinensprache. Wie schon geschrieben wurde, mit ausreichend Geduld, kann man das manuell auch programmieren.
Gruß
maria
Hallo Maria,
Bevor es Plattformen wie .NET oder Java gab, wurden Programme,
die ín Hochsprachen wie C++ geschrieben wurden, direkt in
Maschinensprache übersetzt. Wenn man also für mehrere
Plattformen Code schreiben wollte, waren neben bestimmten
Richtlinien auch Compiliervorgänge für jede Plattform
erforderlich.Mit der Einführung von Zwischencode - maschinennahem Code, der
Assembly - bei z. B. .NET oder Java hat sich da einiges
vereinfacht.
Verkauft das MS so?
Dann schau mal bei UCDS Pascal rein, das war 1978 auf dem Markt:
http://de.wikipedia.org/wiki/UCSD_Pascal
http://en.wikipedia.org/wiki/UCSD_Pascal
Wobei die meisten BASIC-Interpiler auch schon eine Art von P-Code verwendeten und das schon eine ganze Weile vorher.
Auch ein Teil der Nixdorf-Computer waren im Prinzip so aufgebaut. Die Hardware bestand aus 4 Z80 Mikroprozessoren, welche nach aussen eine virtuelle CPU simulierten.
MfG Peter(TOO)
Hallo Peter,
Verkauft das MS so?
Nein, weil MS kein Java verkauft.
Dann schau mal bei UCDS Pascal rein, das war 1978 auf dem
Markt:
http://de.wikipedia.org/wiki/UCSD_Pascal
http://en.wikipedia.org/wiki/UCSD_PascalWobei die meisten BASIC-Interpiler auch schon eine Art von
P-Code verwendeten und das schon eine ganze Weile vorher.
Mir war UCDS Pascal nicht bekannt, bei der angeführten Verbreitung wohl eher ein universitäres Unikum, und BASIC war in den meisten Versionen interpretiert.
Breite kommerziell vermarktbare und wirklich plattformunhabhängige Verwendung gibt es definitiv erst seit der Java VM.
Gruß
Maria
Jetzt hab ich mich vertippt auch noch
UCSD Pascal.
ja ich sage danke für die ganzen antworten aber mit visual c++ ein bt… naya ist viel zu schwer…deshalb in assember irgendwie wird es schon gehen…
Hallo Maria,
Mir war UCDS Pascal nicht bekannt, bei der angeführten
Verbreitung wohl eher ein universitäres Unikum,
UCSD Pascal war Anfang der 80er sehr weit verbreitet nicht nur an Unis.
Unter anderem war die Version für den Apple ][ sehr verbreitet.
und BASIC war
in den meisten Versionen interpretiert.
Die meisten BASIC-Interpreter sind Compreter oder Interpiler.
Die Schlüsselwörter werden bei der Eingabe schon erkannt und als Tokens (meistens 1 Byte) abgelegt. Ist im Prinzip auch schon eine Art von P-Code.
Reine Interprter, die also die Eingabe1 zu 1 im Speicher ablegen, habe ich nur ganz wenige kennen gelernt.
Breite kommerziell vermarktbare und wirklich
plattformunhabhängige Verwendung gibt es definitiv erst seit
der Java VM.
Dies liegt am Internet und der kostenlosen Verbreitung.
In den 80er Jahren musste man so etwas meist noch kaufen oder schwarz kopieren. Da war die Verbreitung noch wesentlich langsamer. Es gab aber auch noch wesentlich weniger PCs!
MfG Peter(TOO)
Wenn ein…
…2 jähriger, ein Buch über Atomphysik lesen möchte, wird er schnell das Interesse verlieren, da ihn Bücher über Biene Maja, mit vielen Bildern, mehr ansprechen. Bloss ist der Poster mittlerweile weit entfernt, von diesem Alter, in dem so was als süss oder belächelt empfunden wird.
Der User hat hier im Forum, schon mehrfach so Fragen gestellt (Internet Explorer in Assembler usw.) jetzt ist es gar schon ein komplettes OS.
Wer den User zum ersten mal gelesen hat, sei vergeben, aber an alle anderen warum antwortet ihr noch auf so was? Jeder der von dieser Materie Ahnung hat, weiss doch was es heisst ein OS nur in C zu schreiben und welches Know How/Zeit/Manpower nötig ist. Allein schon die Fragestellungen, zeigen doch das Know How des Posters. Der kann nicht mal eine Linux-Ordnerstruktur in einem assoziativen Array speichern.
Troll! Mehr gibt es da nicht zu sagen!
Hallo Peter,
Mir war UCDS Pascal nicht bekannt, bei der angeführten
Verbreitung wohl eher ein universitäres Unikum,UCSD Pascal war Anfang der 80er sehr weit verbreitet nicht nur
an Unis.
Unter anderem war die Version für den Apple ][ sehr
verbreitet.
Wieder was gelernt.
und BASIC war
in den meisten Versionen interpretiert.Die meisten BASIC-Interpreter sind Compreter oder Interpiler.
Die Schlüsselwörter werden bei der Eingabe schon erkannt und
als Tokens (meistens 1 Byte) abgelegt. Ist im Prinzip auch
schon eine Art von P-Code.
Wie meinst du das? Tokenizing ist doch ein Schritt der lexikalischen Analyse. Das hat gar nichts mit intermediate Code, wie wir ihn heute im Zusammenhang mit virtuellen Laufzeitumgebungen kennen, zu tun.
Reine Interprter, die also die Eingabe1 zu 1 im Speicher
ablegen, habe ich nur ganz wenige kennen gelernt.
Die legen also eine bereits teilweise analysierte Version des Quellcodes ab. Das ist aber bereits Teil der Interpretierens und hat genau gar nix mit compilieren zu tun, wohl eher mit Performance.
Breite kommerziell vermarktbare und wirklich
plattformunhabhängige Verwendung gibt es definitiv erst seit
der Java VM.Dies liegt am Internet und der kostenlosen Verbreitung.
In den 80er Jahren musste man so etwas meist noch kaufen oder
schwarz kopieren. Da war die Verbreitung noch wesentlich
langsamer. Es gab aber auch noch wesentlich weniger PCs!
Zum Teil sicher.
Gruß
maria
Hallo Maria,
und BASIC war
in den meisten Versionen interpretiert.Die meisten BASIC-Interpreter sind Compreter oder Interpiler.
Die Schlüsselwörter werden bei der Eingabe schon erkannt und
als Tokens (meistens 1 Byte) abgelegt. Ist im Prinzip auch
schon eine Art von P-Code.Wie meinst du das? Tokenizing ist doch ein Schritt der
lexikalischen Analyse. Das hat gar nichts mit intermediate
Code, wie wir ihn heute im Zusammenhang mit virtuellen
Laufzeitumgebungen kennen, zu tun.
Richtig, nicht mit der heutigen Technik. Die damaligen CPUs haben aber auch genau so viel mit den Heutigen zu tun.
Effektiv im Speicher wurde der Baum, welcher die lexikalische Stufe erzeugt abgelegt, das ist schon ein Zwischenprodukt.
Damals war weniger die Portierbarkeit, ausser z.B. bei UCSD Pascal, der Ansatz, sondern eine kompakte Speicherausnutzung. Es war nicht unüblich, dass Mehrplatzsysteme mit 16 Usern mit 32KByte Hauptspeicher auskamen.
CBASIC, so um 1977, verwendete auch einen P-Code.
http://de.wikipedia.org/wiki/CBASIC#Eigenschaften
Visual BASIC MS konnten bis zur Version 4 nur P-Code erzeugen, die Versionen 5 und 6 konnten dann wahlweise P-Code oder direkt nativen Code erzeugen.
http://de.wikipedia.org/wiki/Visual_Basic_Classic#19…
Ich selbst Entwickelte ende 70er einen P-Code für spezielle Prüfgeräte. Um keinen Compiler entwickeln zu müssen, wurde der P-Code mit einem Macro-Assembler erzeugt. Der eigentliche Grund war der Platzbedarf für die Prüfabläufe. Grundsätzlich wäre der P-Code portabel gewesen, aber es wurden nicht so viele Prüfgeräte hergestellt, als dass unterschiedliche Hardware verwendet worden wäre.
Reine Interpreter, die also die Eingabe1 zu 1 im Speicher
ablegen, habe ich nur ganz wenige kennen gelernt.Die legen also eine bereits teilweise analysierte Version des
Quellcodes ab. Das ist aber bereits Teil der Interpretierens
und hat genau gar nix mit compilieren zu tun, wohl eher mit
Performance.
Deshalb wurde diese Technik damals such Interpiler oder Compreter genannt.
http://universal_lexikon.deacademic.com/254206/Interpiler
Wenn ich jetzt ganz tief in der Kiste krame, waren die meisten CPUs schon immer P-Code-Maschinen. Die Assemblerbefehle werden nämlich meistens nicht durch die Hardware direkt abgearbeitet, sondern durch Mikrocode interpretiert.
Typischerweise verwenden CISC-CPUs Mikrocode und RISC-CPUs habe die Befehle fest verdrahtet.
Im Prinzip geht es darum, dass für eine virtuelle Maschine Programme erstellt werden, welche dann über einen Interpreter abgearbeitet werden.
Je nach den Umständen nennt sich der Interpreter dann halt Simulator, Emulator, P-Code-Interpreter oder sonst wie. Die Technik dahinter ist uralt und vom Prinzip her immer die Selbe.
MfG Peter(TOO)
P.S. Java
Hallo Maria,
Verkauft das MS so?
Nein, weil MS kein Java verkauft.
Naja, MS darf das nicht mehr …
1996 erwarb MS eine Java-Linzenz von Sun. Allerdings hat dann MS dieses Java so verbastelt, dass die Grundidee hinter Java ausgehebelt wurde (MS ermöglichte direkten Zugriff auf Windows, direkt aus Java), was dann 2003 zum Verlust der Lizenz führte.
MfG Peter(TOO)
Hallo Peter,
Du hast doch ein paar Jahre Vorsprung vor mir. Mein Einstieg war „erst“ 1986 mit Schwerpunkt Anwendungsentwicklung. Mein Horizont ist jetzt wieder ein Stück gewachsen. Danke dir für die interessanten Ausführungen.
lg
maria
Hallo Maria,
Du hast doch ein paar Jahre Vorsprung vor mir. Mein Einstieg
war „erst“ 1986 mit Schwerpunkt Anwendungsentwicklung. Mein
Horizont ist jetzt wieder ein Stück gewachsen. Danke dir für
die interessanten Ausführungen.
Ich vermute, du bist zu einseitig von MS informiert worden.
Eigentlich hat MS nie etwas neues erfunden, die tun immer nur so und verpassen dem Zeugs einen neuen Namen.
MfG Peter(TOO)
Ich nie ein komplettes OS…mir hat ja nichts weitergeholfen…
Dir ist auch leider so nicht zu helfen.
Seit Wochen postet du irgendwelche Fragen, wie man dieses oder jenes „mit/in Assembler machen könnte“.
Du bist auf keine der sachlichen Antworten eingegangen, warst nicht in der Lage oder Willens uns irgendwelche Hintergründe zu schildern. Wir kennen ja nicht einmal den Prozessor.
Grüße
fribbe
Paranoia
Moin,
Dir ist auch leider so nicht zu helfen.
warum antwortet dem überhaupt noch jemand? Mich erinnert das sehr stark an die Erfinder von wasweißich für Maschinen, die vor lauter Angst, ihre Idee könnte geklaut werden, nciht mal dem Handwerker sagen, wie das Gerät aussehen soll.
Gruß Ralf
Hallo Peter,
dass MS die VM nicht erfunden hatte war mir schon klar 
, nur nicht wieweit in die Vergangenheit die Wurzeln des Konzeptes reichen.
Liebe Grüße
maria
Hallo Gruß- und Namenloses Etwas,
Meine letzte Frage zu Assembler…oder Assembly ist assembler
und assembly das gleiche und 2 Frage:
Also doch noch nicht doe letzte Frage. Schade.
Kann man ein Netzwerk in Assmebler machen ein localisiertes
netwerk ein hauptpc und ein nebenpc der allles lädt jedoch ist
es möglich muss fast möglich sein(Windows 95)
geb es einen localen Server der über Microsoft
läuft…
Möchtest Du ein Betriebssystem welches irgendein Netzwerkprotokoll verwendet, ein eigenes Netzwerkprotokoll was z.B. eigenständig läuft oder was willst Du? Bitte definiere Dein problem genauer. Danke.
Also MUSS es möglich sein!!!enn es es schon in den 1995
gegeben hat…wenn nach dem wisssen der 90 es möglich ist muss
es möglich sein.
Was hat es 1995 gegeben? Worauf beziehst Du Dich? Bitte nähere Angaben. Danke.
Gruß
h.