Forum: Offtopic Wäre sowas auch in Pascal passiert?


von Jon (Gast)


Lesenswert?


: Verschoben durch Moderator
von Uhu U. (uhu)


Lesenswert?

Jon schrieb:
> oder Bascom? oder Java?

Nein, aber nicht weil diese Sprachen so viel besser sind, als C, sondern 
weil man damit keine Treiber schreibt.

von Kim S. (Gast)


Lesenswert?

ach schreibt man nicht?? Das ist mir neu!
Abgesehen von Maustreibern...gibt es noch grundlegendere Treiber in 
Pascal...und nur weil jemand das heute nicht macht, bedeutet es ja nicht 
das es in Pascal nicht geht!
http://www.amazon.de/Systemnahe-Programmierung-Borland-Pascal-vollst%C3%A4ndiger/dp/3322872394

von Kim S. (Gast)


Lesenswert?

hierzu sei noch gesagt das Buch bezieht sich auf eine steinalte Version 
von Pascal..in freepascal spräche aber  ganz sicher nichts dagegen

von (prx) A. K. (prx)


Lesenswert?

In vielen Sprachen - aber eben nicht in C - kann bei Array-Zugriffen 
Code eingebaut werden, der Indices auf zulässigen Wertebereich 
überprüft. Das spielt bei Thema "buffer overflow" eine nicht 
unerhebliche Rolle.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Kim Schmidt schrieb:
> Das ist mir neu!

Hast du denn dann auch zumindest ein Beispiel für ein Gerät, dessen
Betriebssystem in Pascal geschrieben wäre?  Im Gegensatz zu einem PC
ist ja so ein Gerät ein eher in sich abgeschlossenes System, bei dem
es nun nicht auf umfängliche Kompatibilität zu existierenden
Anwendungsprogrammen ankommt, die der Nutzer haben möchte.  Insofern
sollte es dort sehr viel leichter sein, alternative Betriebssyteme zu
benutzen als auf einem PC.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Eigentlich ist die Krux nicht in der Programmiersprache zu suchen, 
sondern in dem hier benutzten Prinzip, den Router als Server zu 
missbrauchen.

Schon seit Urgedenken des Internets gilt eine Grundsatzregel:

   Ein Router ist kein Server.
   Dienste haben auf einem Router nichts zu suchen.

Leider halten sich die Hersteller von Routern für den Heimgebrauch daran 
immer weniger - einfach um einen Mehrwert zu erzeugen. So werden dann 
Drucker-, NAS- und andere Schnickschnack-Server in den Router 
integriert, obwohl das eigentlich ein No-Go ist.

Otto Normaluser möchte sich aber neben seinen Router keinen weiteren 
Netzwerkserver stellen - warum eine weitere Kiste?

P.S.
Als Gründer des fli4l-Router-Projekts kann ich von dem Thema ein Lied 
singen...

: Bearbeitet durch Moderator
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Ein Router ist kein Server.

Naja, einen DHCP-Server habe ich auf dem Router auch noch mit drauf.
Einfach, weil bei ihm die verschiedenen Netze zentral auflaufen.

Aber ansonsten volle Zustimmung.

von Robert L. (lrlr)


Lesenswert?

>Hast du denn dann auch zumindest ein Beispiel für ein Gerät, dessen
>Betriebssystem in Pascal geschrieben wäre?

die Frage war ja, was wäre wenn..
also WENN ein in pascal geschriebenes (U)nix drauf laufen WÜRDE..

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Robert L. schrieb:
> die Frage war ja, was wäre wenn..

Die hilft uns nur leider in der Praxis nicht.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Ein Router ist kein Server.
> Dienste haben auf einem Router nichts zu suchen.

Mal abgesehen von DHCP: Auf meiner Fritz!Box habe ich auch NAS- und 
andere Schnickschnack-Server.

Da ich damit bisher keine Probleme hatte und falls ich als Mitleser mal 
fragen darf: Warum dürfen Server und Router nicht zusammen in ein Gerät? 
Einigkeit scheint in diesem Punkt ja zu herrschen.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Robert L. schrieb:
> die Frage war ja, was wäre wenn..
> also WENN ein in pascal geschriebenes (U)nix drauf laufen WÜRDE..

Zugegebnermaßen schützt Pascal den Programmierer eher gegen 
Buffer-Overflows als C.

Aber man sollte immer bedenken: Man kann sich mit jeder 
Programmiersprache ins Knie schießen... da kommts immer auf die eigene 
Blödheit an.

Außerdem kann so eine automatische "Sicherheit" zu Leichtsinn verführen: 
"Ich bin ja angegurtet, also kann mir nichts mehr passieren" .... sagte 
derjenige, der mit 200 gegen die Wand fuhr...

Natürlich könnte man auch in C eine Lib schreiben, die Array-Zugriffe 
(wie z.B. Buffer für Strings) komplett kapselt und jeden Zugriff prüft. 
Das geht dann halt auf Kosten der Geschwindigkeit und wird sich dann 
eher mit der Geschwindigkeit eines Pascal-Programms messen lassen.

Der Programmierer müsste sich dann extremst disziplinieren: Die 
Verwendung von Pointern wäre zwar gestattet, jedoch nicht der Zugriff 
auf den Speicher über den Pointer. Array-Zugriffe müssten ebenso über 
die Lib abgewickelt werden.

Also: Theoretisch bekäme man das schon so "sicher" wie in Pascal. Aber 
zu Kosten von Freiheit, die ein C-Programmierer eher nicht aufgeben 
möchte. Denn sonst wäre er eher ein Pascal-Programmierer geworden ;-)

: Bearbeitet durch Moderator
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Torsten C. schrieb:
> Warum dürfen Server und Router nicht zusammen in ein Gerät?

Aus Sicherheitsgründen, damit ein Bug im Router nicht so leicht
durch andere ausnutzbar wird.  Je mehr Dienste es gibt, um so
angreifbarer ist ein System.  Ein Router / Firewall sollte daher
möglichst wenig Angriffspunkte bieten.

von Kim S. (Gast)


Lesenswert?

die Frage war ja, was wäre wenn..

Die hilft uns nur leider in der Praxis nicht.
!?!?!?!


Was ist denn das für Ein Argument?
Klar ist was wäre wenn wichtig..das ist ja die Frage von ganz oben!?!

Es spricht nichs dagegen ein System in PAscal zu schreiben, also bleit 
die frage..wäre es damit auch passiert!?

Denn dieses Problem ist ja nun ein Fortlaufenden bei C, in C++ soll das 
ja angeblich besser geworden sein?
Ich frage mich nur deshalb, weil gerde in sicherheitsrelevanten 
bereichen Pascal ähnliche Sprachen verwendet werden, wieso nicht bei 
Routern?
Gibt es keine brauchbaren Programmierer mehr die diese Sprachen 
beherschen?
Bequemlichkeit?
Aber ganz sicher sind es kosten...den ein programmeirer der diese 
sprachen beherscht ist nunmal teurer als ein C Mensch die es wie Sand am 
Meer gibt.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Torsten C. schrieb:
> Da ich damit bisher keine Probleme hatte und falls ich als Mitleser mal
> fragen darf: Warum dürfen Server und Router nicht zusammen in ein Gerät?
> Einigkeit scheint in diesem Punkt ja zu herrschen.

Ein Router hat genau eine Aufgabe, nämlich Netze voneinander zu 
trennen und den Datenverkehr zwischen den Netzen zu regeln. Dabei muss 
er oft gewissen Sicherheitskonzepten genügen. Jedenfalls sollte ein 
Netzwerkadministrator solche Sicherheitskonzepte für die Szenarien, für 
die er verantwortlich ist, entwickeln.

Das Sicherheitskonzept wird dann umgesetzt durch Anwendung von 
Topographie, Routing- und Firewall-Regeln. Damit wird der Datenverkehr 
zwischen den Netzen auf das beschränkt, was tatsächlich notwendig ist.

Die Wirklichkeit sieht bei den Heimroutern aber ganz anders aus. Hier 
gibt es eigentlich meist nur nur ein Werkzeug zur Umsetzung eines sehr 
allgemein gehaltenen Sicherheitskonzeptes (nämlich das des Herstellers): 
Das nennt sich IP-Masquerading. Aber genau das ist kein Ersatz für 
eine Firewall.

Zu den Schwächen von IP-Masquerading und das falsche Wiegen in 
Sicherheit gibt es genügend Stoff im Internet. Darauf will ich gar nicht 
eingeghen. Andere Mittel wie Portfilter sind dem Otto-Normal-User als 
Firewall-Werkzeug viel zu kompliziert. Was macht er also? Er schaltet 
die Firewall ab ("weil, das lief vorher nicht richtig") oder aktiviert 
sie erst gar nicht ("weil, wozu brauche ich die, versteh ich eh nicht?") 
oder konfiguriert sie entweder komplett kaputt ("Hilfe, nix geht mehr") 
oder leitet  versehentlich sämtliche Zugriffe von außen auf seinen 
Hauptrechner ("das Spiel XYZ läuft nur, wenn ich meinen Rechner als 
'exponierten Server' im Router freigebe").

Also: Ein Heimrouter muss so allgemein vom Hersteller vorkonfiguriert 
sein, dass er von Otto-Normal-User in Betrieb genommen werden kann. Denn 
dieser ist ja kein Netzwerk-Administrator.

Solange von außen keine Ports offen sind, ist das alles kein Problem. 
Dann macht der Router ja genau, was er soll - hoffentlich. Die Gefahr 
eines Einbruchs in das interne Netzwerk ("Heimnetzwerk") ist dann 
minimal.

Wenn nun aber Dienste auf dem Router aktiv sind, dann sind Ports offen, 
über die ein Angriff stattfinden kann. Idealerweise sind es Ports, die 
nur im internen Netz zugänglich sind. Aber auch das kann bereits eine 
Schwachstelle sein. Schafft man es nämlich, einen PC aus dem internen 
Netzwerk zu "überreden", von "innen" aus den Router anzugreifen, hat man 
eventuell schon verloren. Vielleicht mag jetzt der eine oder andere 
ungläubig den Kopf schütteln, aber es gab solche Fälle bereits in der 
Vergangenheit.

Krasser wird die ganze Sache, wenn Dienste auch "versehentlich" im 
äußeren Netz zugänglich gemacht werden. Das kann durch die Blödheit des 
Users geschehen, der eine Anleitung missverstanden hat oder auch durch 
tatsächliche Verwundbarkeit von Diensten wie der sog. "Fernwartung", die 
nachweislich schon bei AVM-Routern (Fritz!Box) von außen geknackt werden 
konnte.

Ergo: Dienste auf einem Router stellen immer ein mögliches 
Einbruchsszenario und damit ein erhöhtes Sicherheitsrisiko dar. Ein 
Einbruch in ein Netz über solch einem Router kann fatal sein, denn meist 
"vertrauen" die Rechner im internen Netz diesem Router, d.h. es sind 
keine weiteren Sicherheitsmaßnahmen vorhanden, um sich gegen den eigenen 
Router zu schützen.

von Torsten C. (torsten_c) Benutzerseite


Lesenswert?

Jörg Wunsch schrieb:
> Aus Sicherheitsgründen, damit ein Bug im Router
Danke für die Antwort.
Dann halte ich mich mit der OT-Frage auch wieder raus.

BTT:
Der Antwort von Frank M. (ukw) ist kaum was hinzuzufügen und sagt schon 
alles.

Kim Schmidt schrieb:
> Ich frage mich nur deshalb, weil gerde in sicherheitsrelevanten
> bereichen Pascal ähnliche Sprachen verwendet werden, …

In den sicherheitsrelevanten Bereichen die ich kenne, wird aus einem 
Simulink-Modell mit TargetLink C-Code erzeugt.
Dabei ging es aber nur um 'Automotive Safety Integrity Level C', wenn 
ich mich recht erinnere.

Kennst Du Beispiele mit Pascal?

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Kim Schmidt schrieb:
> Es spricht nichs dagegen ein System in PAscal zu schreiben

Nun, warum tut's dann keiner?

Irgendeinen Grund muss es geben.  Am Erlernen der Sprache selbst liegt
es ganz gewiss nicht, in dieser Hinsicht ist Pascal ja eher einfacher
als C.

von Paul B. (paul_baumann)


Lesenswert?

Jörg Wunsch schrieb:
> Irgendeinen Grund muss es geben.
Ja, den suche ich da auch.

> Am Erlernen der Sprache selbst liegt
> es ganz gewiss nicht, in dieser Hinsicht ist Pascal ja eher einfacher
> als C.

Da gebe ich Dir vollkommen Recht.
Es kann nur daran liegen, daß seit einigen Jahren die Leute in Schule, 
Berufsschule und / oder Universität "C" gelehrt bekommen.
Die Leute nehmen dann, was sie kennen und können. Früher hätten sie 
Pascal genommen.

MfG Paul

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Paul Baumann schrieb:
> Die Leute nehmen dann, was sie kennen und können. Früher hätten sie
> Pascal genommen.

Wenn, dann eher Modula-2. Gibts auch schon seit "früher[tm]" und ist 
wesentlich formaler und komfortabler als Pascal ("Labersprache") 
ausgelegt. Wirth hat da so ziemlich alle Fehler, die er in Pascal (bzw. 
Modula) reinsteckte, ausgemerzt.

Ich könnte mir vorstellen, dass damit eher die Implementation eines OS 
möglich wäre. Aber auch Modula-2 ist längst altes Eisen und ist von 
Oberon (ebenfalls von Wirth) abgelöst worden.

Und wenn man da mal schaut, wird man auch fündig:

"Das ETH Oberon System ist ein eigenständiges Betriebssystem der ETH 
Zürich, das in der Sprache Oberon implementiert ist, als 
Entwicklungsgrundlage für die Sprache diente und ebenso wie der Compiler 
kostenlos erhältlich ist."

(aus http://de.wikipedia.org/wiki/Oberon_%28Programmiersprache%29 )

P.S.
Was ist für Dich "früher"? Unix - größtenteils in C programmiert - gibts 
seit 1970. Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache, 
also nicht praxisrelevant.

: Bearbeitet durch Moderator
von Kim S. (Gast)


Lesenswert?

warum es keiner tut?"
Na also damals zu DOS Zeiten wurden doch viele Treiber in Pascal 
geschrieben und mittlerweile ist halt C populärer

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Kim Schmidt schrieb:
> Na also damals zu DOS Zeiten wurden doch viele Treiber in Pascal
> geschrieben und mittlerweile ist halt C populärer

Das ist meines Erachtens falsch. C war immer populärer. In den 70ern 
gab's noch kein DOS - und damit auch kein Pascal für DOS. Unix gab es 
aber schon - in C programmiert.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> C war immer populärer.

Und MS-DOS war (zumindest treibermäßig) zu großen Teilen noch in
Assembler programmiert.

von Pandur S. (jetztnicht)


Lesenswert?

>  ... Ich frage mich nur deshalb, weil gerde in sicherheitsrelevanten
bereichen Pascal ähnliche Sprachen verwendet werden, wieso nicht bei
Routern?


Router .. sicherheitsrelevant ? Router sind Devices vom Grabbeltisch, 
die erst mal billigst sein muessen...

von Kim S. (Gast)


Lesenswert?

na aber allmählich lernen doch auch die letzten das Internetkomponenten 
sehr wohl als sicherheitsrelevant einestuft werden sollten

von Kaj G. (Firma: RUB) (bloody)


Lesenswert?

Paul Baumann schrieb:
> Es kann nur daran liegen, daß seit einigen Jahren die Leute in Schule,
> Berufsschule und / oder Universität "C" gelehrt bekommen.
Bloedsinn. Schau doch mal in die Plaene von Unis/FH, da steht Java ganz 
oben, und ganz vielleicht noch C++, wenn ueberhaupt. Manchmal noch 
Python oder Ada,
C wird nur in wenigen Studienfaechern angeboten (z.B. IT-Sicherheit an 
der Uni Bochum).

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Jetzt Nicht schrieb:
> Router .. sicherheitsrelevant ? Router sind Devices vom Grabbeltisch,
> die erst mal billigst sein muessen...

Redest Du jetzt von Routern im Heimbereich oder Routern in einem 
Rechenzentrum beispielsweise?

Wenn jemand von "sicherheitsrelevanten Bereichen" spricht, meint er 
dabei nicht unbedingt das Netz zu hause... Ich käme da jedenfalls nicht 
unbedingt als erstes auf diese Idee.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Die Überprüfung der Array-Grenzen zur Laufzeit ist sicher ein gutes
Mittel, um Buffer-Overflows zu erkennen und weiteren Schaden zu
verhindern.

Auf den Routern läuft üblicherweise Linux als Betriebssystem. Linux ist
einschließlich seiner Treiber in C programmiert, wobei es sicher mit ein
paar Verrenkungen auch möglich wäre, einen Treiber in Pascal zu
schreiben.

Der Router-Hersteller würde aber mit hoher Wahrscheinlichkeit das
Range-Checking in Pascal deaktivieren, um den damit verbundenen
Speicher- und Laufzeit-Overhead zu minimieren und damit möglicherweise
ein paar Cents beim Prozessor und Flash-Speicher einzusparen. Solche
Sicherheitsüberprüfungen werden oft nur während der Entwicklungs- und
Testphase aktiviert. Treten bei den Tests keine Fehler auf, wird die
Software als ausreichend fehlerfrei betrachtet, so dass in der Release-
Version auf die Prüfungen verzichtet wird.

Vielleicht macht sich der (schlampige) Hersteller auch überhaupt keine
Gedanken um solche Dinge. Dann wird er, was die Sicheheitsabfragen
betrifft, einfach die Defaulteinstellungen des Compilers verwenden. Bei
vielen Pascal-Compilern (bspw. bei Free Pascal) ist das Range-Checking
(zusammen mit etlichen anderen Sicherheitsüberprüfungen) aber default-
mäßig deaktiviert (vermutlich, um bei Benchmarks besser abzuschneiden).

Somit ist also auch bei Pascal-Treibern trotz der prinzipiell höheren
Sicherheit von Pascal gegenüber C die Chance recht groß, dass es so ein
Bug bis ins Serienprodukt schafft.

von Paul B. (paul_baumann)


Lesenswert?

Frank M. schrieb:
> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache,
> also nicht praxisrelevant.

Bei uns im Betrieb (sogar im ganzen Kombinat) wurde sämtliche 
Anwendungssoftware in Pascal geschrieben.

Frank M. schrieb:
> In den 70ern
> gab's noch kein DOS - und damit auch kein Pascal für DOS.

In den 70ern gab es CP/M und damit ein System, auf dem Pascal-Kompiler 
liefen.


>> Es kann nur daran liegen, daß seit einigen Jahren die Leute in Schule,
>> Berufsschule und / oder Universität "C" gelehrt bekommen.
Kaj G. schrieb:

> Bloedsinn.

Vorsicht µit den jungen Pferden!
> Schau doch mal in die Plaene von Unis/FH, da steht Java ganz
> oben, und ganz vielleicht noch C++, wenn ueberhaupt.

Ich sprach auch von Schule und Berufsschule. Liest man hier jeden Tag, 
wie Kinder und Jugendliche sich mit dem Kram befassen müssen und über 
deren "Freude" darüber.

MfG Paul

von Uhu U. (uhu)


Lesenswert?

Kim Schmidt schrieb:
> warum es keiner tut?"
> Na also damals zu DOS Zeiten wurden doch viele Treiber in Pascal
> geschrieben und mittlerweile ist halt C populärer

Damals hat man Treiber im ASM geschrieben. Die Rechner waren einfach 
nicht schnell genug, als dass man sich den Luxus einer Hochsprache fürs 
OS hätte erlauben können, ohne dass das die ganze Kiste nur mit sich 
selbst beschäftigt gewesen wäre.

Das frühe C war eine Art Super-Assembler und deswegen prädestiniert 
dafür, ASM im Betriebssystembau abzulösen.

Wie oben schon gesagt, gab es von Wirth auch experimentelle 
Betriebssysteme, die in Pascal und Nachfolgern geschrieben waren - das 
waren aber alles Lehrprojekte, die nie praktische Relevanz erlangten.

von Uhu U. (uhu)


Lesenswert?

Paul Baumann schrieb:
> Bei uns im Betrieb (sogar im ganzen Kombinat) wurde sämtliche
> Anwendungssoftware in Pascal geschrieben.

Treiber sind keine Anwendungssoftware...

von Paul B. (paul_baumann)


Lesenswert?

Uhu Uhuhu schrieb:
> Treiber sind keine Anwendungssoftware...

Echt jetzt?
/Loriot
Ach?!
\Loriot

Pass auf, ich erkläre es Dir noch einmal haarklein:
Frank M. schrieb:
>> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache,
>> also nicht praxisrelevant.
Daraufhin schrieb ich:
>> Bei uns im Betrieb (sogar im ganzen Kombinat) wurde sämtliche
>> Anwendungssoftware in Pascal geschrieben.

->Schlussfolgerung: Die Sprache ist sehr wohl praxiasrelevant gewesen,
denn sonst hätten sich nicht Dutzende Progarmmierer im ganzen Land damit 
produktiv beschäftigt.

Nein, es ging nicht um Treiber.

MfG Paul

von Marko ⚠. (mos6502) Benutzerseite Flattr this


Lesenswert?

A. K. schrieb:
> In vielen Sprachen - aber eben nicht in C - kann bei
> Array-Zugriffen
> Code eingebaut werden, der Indices auf zulässigen Wertebereich
> überprüft. Das spielt bei Thema "buffer overflow" eine nicht
> unerhebliche Rolle.

Bounds Checking bringt massig Overhead mit sich und hilft nicht immer. 
In C ist das eh kein Problem, man muss nur die n-Funktionen (also z.B. 
snprintf statt sprintf benutzen) und ein paar einfache Regeln beachten. 
Nur weil C schlechte Programmierer nicht vor sich selbst schützt ist es 
nicht per se "gefährlich".

von Uhu U. (uhu)


Lesenswert?

Paul Baumann schrieb:
> ->Schlussfolgerung: Die Sprache ist sehr wohl praxiasrelevant gewesen,
> denn sonst hätten sich nicht Dutzende Progarmmierer im ganzen Land damit
> produktiv beschäftigt.

Ich habe auch schon Anwendungsprogramme in Pascal geschrieben - das war 
aber zu 8080/Z80-Zeiten. Es gab auch im Westen eine Pascal-Gemeinde, die 
wurde aber den Ruch der Software-Esoterik nie so recht los...

Uhu Uhuhu schrieb:
> Wie oben schon gesagt, gab es von Wirth auch experimentelle
> Betriebssysteme, die in Pascal und Nachfolgern geschrieben waren - das
> waren aber alles Lehrprojekte, die nie praktische Relevanz erlangten.

Ich hoffe, du kennst den Unterschied zwischen einem Betriebssystem und 
Anwendungssoftware...

von Paul B. (paul_baumann)


Lesenswert?

Uhu Uhuhu schrieb:
> Ich hoffe, du kennst den Unterschied zwischen einem Betriebssystem und
> Anwendungssoftware...

Nein. Erklär doch mal!
;-)

MfG Paul

von (prx) A. K. (prx)


Lesenswert?

Malignes Melanom schrieb:
> Bounds Checking bringt massig Overhead mit sich

Nicht unbedingt. Das muss nicht bei jedem Zugriff stattfinden, wenn der 
Compiler feststellt, dass es ausreicht, vor der Schleife zu 
kontrollieren statt drinnen beim Zugriff.

Bei einem auf 0 basierten Index ist das z.B. ein Vergleich und ein 
komplett ignorierter Sprung oder eine Exception. Bei heutigen 
Prozessoren ist das kein grosser Aufwand und wird als unabhängiger 
Seitenpfad oft nur gering in die Laufzeit eingehen.

> und hilft nicht immer.

Hat niemand behauptet. Ist nur ein Baustein.

> In C ist das eh kein Problem

Manuell programmiert ist das auch in Assembler kein Problem. Perfekt 
programmiert funktioniert alles. Aber wer programmiert schon perfekt?

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Paul Baumann schrieb:
> In den 70ern gab es CP/M und damit ein System, auf dem Pascal-Kompiler
> liefen.

Der erste Release von Turbo-Pascal (für CP/M) war im November 1983.

Alles davor hat keiner freiwillig auf CP/M benutzt, weder C-Compiler
noch Pascal-Compiler.  Da konntest du während des Compilierens ja
in Ruhe einen Kaffee aufbrühen und trinken.

1983 war UNIX bereits beim legendären System V angelangt und bestand
vermutlich schon zu mehr als 95 % aus C-Code.

Ich habe Turbo-Pascal für CP/M auch gern benutzt, nicht dass du mich
falsch verstehst, Paul.  Aber ich wäre nicht auf die Idee gekommen,
damit das BDOS oder BIOS meines CP/M zu schreiben – um mal so zumindest
annähernd auf das zurückzukommen, um das es eingangs ging.

von (prx) A. K. (prx)


Lesenswert?

Jörg Wunsch schrieb:
> Alles davor hat keiner freiwillig auf CP/M benutzt, weder C-Compiler
> noch Pascal-Compiler.

Doch. Man hat das genutzt was es gab und hatte nicht die heutigen 
Ansprüche an die Zykluszeit bei der Entwickung. Es war aber noch nicht 
die Zeit von C, damals waren ausserhalb der Unix-Szene andere Sprachen 
üblich. C gab es m.W. nur als Tiny-C.

So gab es beispielsweise UCSD P-Code Pascal. Mit dem Auftritt von 
Turbo-Pascal war das natürlich tot, aber bis dahin eine durchaus für 
Anwendungen nutzbare Sprache.

Ich habe testweise auch mal PL/I für CP/M ausprobiert. In Anbetracht der 
überschaubaren Leistung eines solchen Systems war das sogar 
einigermassen brauchbar (abgesehen von Eigenheiten der Sprache selbst) 
und hatte trotz Subset einen beachtlichen Funktionsumfang.

von Thomas E. (thomase)


Lesenswert?

Jörg Wunsch schrieb:
> Paul Baumann schrieb:
>> In den 70ern gab es CP/M und damit ein System, auf dem Pascal-Kompiler
>> liefen.
>
> Der erste Release von Turbo-Pascal (für CP/M) war im November 1983.

Das war aber das Teufelszeug vom Klassenfeind. Vielleicht hatten sie ja 
was Eigenes. Die waren ja nicht doof.

mfg.

von Uhu U. (uhu)


Lesenswert?

Thomas Eckmann schrieb:
> Das war aber das Teufelszeug vom Klassenfeind.

Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut 
war?

Nicht nur Chinesen haben ein Faible für technische Abkürzungen ;-)

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Uhu Uhuhu schrieb:
> Thomas Eckmann schrieb:
>> Das war aber das Teufelszeug vom Klassenfeind.
>
> Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut
> war?

Wikipedia sagt dazu:

Die PDP-11 wurde wegen ihrer technischen Bedeutung auch in der 
Sowjetunion und ihren verbündeten Staaten ohne Lizenz nachgebaut. 
Beispiele dafür sind:

  - SM-4, SM-1420, IZOT-1016 (Bulgarien).

  - K 1600 (DDR)

  - Mera (Polen)

  - I-102 (Rumänien)

  - SM-4, SM-1420, SM-1600, Elektronika BK-0010, DVK, UKNC (Sowjetunion)

    TPA-51 (Ungarn) "TPA" (ung. Abk.)
    "Speicherprogrammierbarer Analysator".
    Exakter Nachbau des PDP 11/40 vom Institut für Kernphysik (KFKI) der
    Ungarischen Akademie der Wissenschaften (MTA). "TPA-11/40" wurde
    später in "TPA-51" (11+40) umbenannt.

Ich selbst habe in den 80ern an einer PDP11 gearbeitet - im Institut für 
Kernphysik in Köln. Der Kernspeicher, wo Magnete auf einer Drahtmatrix 
aufgezogen waren und man jedes Bit noch einzeln sehen konnte, hat mich 
bis heute fasziniert...

Betriebssystem war RSX-11, ein Realtime-OS. Aber auch unixoide Systeme 
wie Ultrix, Unix System 7 und BSD waren für die PDP11 verfügbar. Womit 
wir wieder bei C und nicht bei Pascal wären ;-)

: Bearbeitet durch Moderator
von Paul B. (paul_baumann)


Lesenswert?

Thomas Eckmann schrieb:
> Das war aber das Teufelszeug vom Klassenfeind. Vielleicht hatten sie ja
> was Eigenes.

Ja, hatten sie.
SCP, CPA und MCP.

Dann gab es auch noch "UDOS" (Nein, nicht Lindenbergs und Jürgens)
;-)

MfG Paul

Edith sagt gerade noch:

Frank M. schrieb:
> - K 1600 (DDR)

PDP11 kenne ich nur vom Namen, aber der K1600 hatte m.E.n. keine 
Kernspeicher mehr, sondern rauhe Mengen an dynamischen RAMs vom Typ 
U6164

von (prx) A. K. (prx)


Lesenswert?

Uhu Uhuhu schrieb:
> Nicht nur Chinesen haben ein Faible für technische Abkürzungen ;-)

Yep. Hardware musste umständlich nachgebaut werden, weil in 
nennenswerten Stückzahlen schwer zu kriegen. Software musste nur einmal 
geklaut werden und brauchte beim Schmuggel weniger Platz (ja, ich weiss, 
nicht alles war stibitzt...).

Aber wenn man in der Geschichte ein wenig zurück blickt, dann kann man 
das auch anderswo finden. So hat auch dein Lieblingsfeind und heutiger 
Vorreiter beim geistigen Eigentum im 19. Jahrhundert von den Europäern 
geklaut was sich zu klauen lohnte. Das findet gewöhnlich dann allmählich 
ein Ende, wenn der Schaden zu gross wird, der durch Klau innerhalb des 
Emporkömmlings entsteht. Das merken allmählich auch die Chinesen, die 
sich ja auch selber beklauen was das Zeug hält.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Paul Baumann schrieb:
> PDP11 kenne ich nur vom Namen, aber der K1600 hatte m.E.n. keine
> Kernspeicher mehr, sondern rauhe Mengen an dynamischen RAMs vom Typ
> U6164

Die PDP-11 Reihe hatte lange genug Bestand, um mit Kernspeicher 
anzufangen und später auf Halbleiterspeicher zu überzugehen. 1970 kamen 
die ersten Modelle als TTL-Gräber raus, 1990 die letzten mit 
vollintegriertem Prozessor.

Eingesetzt werden sie z.T. noch heute. Geplant bis 2050: 
http://www.theregister.co.uk/2013/06/19/nuke_plants_to_keep_pdp11_until_2050/

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Uhu Uhuhu schrieb:
> Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut
> war?

Wobei die Hardware meines Wissens nicht geklaut war.  Bspw. hatte der
K1630 von robotron NMOS-Bitslice-CPUs.  Waren leider nicht die
schnellste, die TTLs der PDP dürften einiges schneller gewesen sein.

Die Software hatte allerdings auf irgendwelchen Kanälen ihren Weg zu
robotron gefunden … allerdings gab es auch da Eigenentwicklungen
teilweise von Unis, die beliebter waren als der robotron-Krams (OS/RW).

Paul Baumann schrieb:
> Ja, hatten sie.
> SCP, CPA und MCP.
>
> Dann gab es auch noch "UDOS" (Nein, nicht Lindenbergs und Jürgens)
> ;-)

War aber alles nichts „eigenes“. ;)  SCP war nur ein umgelabeltes
CP/M, bei CP/A hatte sich die AdW viel Mühe gemacht und viel eigenes
drin, aber das BDOS war auch original.  UDOS hieß westlich von Werra
und Elbe „RIO“.

Eine (meines Wissens) wirkliche Eigenentwicklung von robotron war
SIOS:

http://www.robotrontechnik.de/html/software/sios.htm

von Paul B. (paul_baumann)


Lesenswert?

Jörg Wunsch schrieb:
> wirkliche Eigenentwicklung von robotron war
> SIOS:

SIOS! Ja, -das hatte ich ganz vergessen. MCP war vom Mansfeld Kombinat 
in Eisleben entwickelt.

MfG Paul

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Jörg Wunsch schrieb:
> Eine (meines Wissens) wirkliche Eigenentwicklung von robotron war
> SIOS:
>
> http://www.robotrontechnik.de/html/software/sios.htm

Nette Formulierung:

"Zu SIOS gibt es kein kompatibles westliches Betriebssystem."

D.h. die Wessis habens jedenfalls nicht geklaut ;-)

: Bearbeitet durch Moderator
von (prx) A. K. (prx)


Lesenswert?

Frank M. schrieb:
> D.h. die Wessis habens nicht geklaut ;-)

... und die Ossis kaum genutzt, weil Wessi-Soft nicht drauf lief. ;-)

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

Frank M. schrieb:
> Betriebssystem war RSX-11, ein Realtime-OS. Aber auch unixoide Systeme
> wie Ultrix, Unix System 7 und BSD waren für die PDP11 verfügbar. Womit
> wir wieder bei C und nicht bei Pascal wären ;-)

Unix wurde ursprünglich auf PDP-8 entwickelt.

von Uhu U. (uhu)


Lesenswert?

A. K. schrieb:
> So hat auch dein Lieblingsfeind und heutiger
> Vorreiter beim geistigen Eigentum im 19. Jahrhundert von den Europäern
> geklaut was sich zu klauen lohnte.

Wer ist mein Lieblingsfeind?

von Arne S. (Gast)


Lesenswert?

A. K. schrieb:
> In vielen Sprachen - aber eben nicht in C - kann bei Array-Zugriffen
> Code eingebaut werden, der Indices auf zulässigen Wertebereich
> überprüft. Das spielt bei Thema "buffer overflow" eine nicht
> unerhebliche Rolle.
Ich meine, dass C-Run von IAR eben ganau sowas (und anderes) tut.

von Uhu U. (uhu)


Lesenswert?

Paul Baumann schrieb:
> MCP war vom Mansfeld Kombinat in Eisleben entwickelt.

Die Abkürzung MCP kenne ich von den Burroughs: Master Control Program.

Auf den verschiedenen Rechnerlinien gab es sehr verschiedene Versionen:

Die B6700 war eine Hardware-Stackmaschine; deren MCP war in Algol 
programmiert.

Die B1700er-Linie war der erste vollständig mit Halbleitern aufgebaute 
kommerzielle Rechner.

Deren MCP war in einer speziellen Sprache namens SDL - Software 
Development Language - programmiert. Der Prozessor war als 
Interpretationsmaschine optimiert, die einen Zwischencode per 
Microprogamm interpretierte. Microprogramme wurden mit einer Art 
Assembler namens MIL - Microcode Implementation Language oder so ähnlich 
- geschrieben.

Die Microprogramme konnte man über die Konsole schrittweise durchtackern 
- mit 24 LEDs, 24 Kippschaltern zum Register laden und einige andere 
Taster für Halt, Step...

Wirth hatte an der 1700 auch gefallen gefunden und es gab auch ein 
Pascal-OS dafür.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Uhu Uhuhu schrieb:
> Unix wurde ursprünglich auf PDP-8 entwickelt.

... und später als SystemV auf einer 3B2 von AT&T weiterentwickelt.

Die erste 3B2 mit der Seriennummer 0000000018, die über den Teich nach 
Europa ging, landete damals in der Firma, in der ich als junger Spunt 
gerade anfing. Und ich war begeistert:

  - Ein echter Shutdown-Schalter, der die Maschine ordnungsgemäß
    herunterfuhr. Einen Power-Off-Schalter gab es gar nicht.
    Somit war versehentliches Abschalten gar nicht möglich.
    (Heutzutage kann das jeder PC, damals war das eine absolute
    Neuheit)

  - Sagenhafte 4 MB RAM, auf dem sich 5-6 Entwickler parallel
    austoben konnten. Sogar gleichzeitiges Compilieren von mehreren
    Entwicklern war damit möglich - auch wenn das erste System-V
    damals noch gar keine Pages kannte, sondern nur Swapping.
    (Paging kam später, meiner Erinnerung nach in System-V R3)

  - Der U3B-Prozessor beherrschte elementare C-Funktionen wie strcmp(),
    strcpy(), memcpy(), memcmp() usw. direkt als Maschinen-Befehle.

Damals dachte noch niemand an Buffer-Overflows als mögliches 
Angriffsszenario... ;-)

: Bearbeitet durch Moderator
von Paul B. (paul_baumann)


Lesenswert?

Frank M. schrieb:
> Sogar gleichzeitiges Compilieren von mehreren
>     Entwicklern war damit möglich

Ein vernünftiger Rechner erlaubt sogar das Gegenteil:
Das gleichzeitige Entwickeln von mehreren Kompilern.
;-)

MfG Paul

von Thomas E. (thomase)


Lesenswert?

Frank M. schrieb:
> Sogar gleichzeitiges Compilieren von mehreren Entwicklern war damit möglich

In der DDR wurden die Entwickler in Gruppen kompiliert?

mfg.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Thomas Eckmann schrieb:
> In der DDR wurden die Entwickler in Gruppen kompiliert?

Wieso DDR? Neeee, Köln gehörte nicht zur DDR ;-)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Frank M. schrieb:
> Köln gehörte nicht zur DDR ;-)

Kann mich auch nicht dran erinnern, je von einer 3B2 in der DDR
gehört zu haben. ;-)  Die „Oberen“ dort waren ohnehin eher Vax- und
VMS-lastig in ihren Bestrebungen (robotron hatte einen funktionierenden
Vax-Clone).

von Thomas E. (thomase)


Lesenswert?

Frank M. schrieb:
> Wieso DDR? Neeee, Köln gehörte nicht zur DDR

Was? Köln a.d. Oder ist doch DDR.

mfg.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Ich habs in einem anderen Thread schon mal erwähnt - bis einschliesslich 
Mac OS 7 wurde auf dem Mac unter MPW in Pascal geschrieben, und zwar 
nicht nur Anwendungen, sondern auch Treiber (natürlich geht das).
Die aufkommende C-Manie erforderte dann Gluecode, um die ROM und 
Systemroutinen auch unter C aufzurufen.

Die ROMs waren allerdings grösstenteils in 68k Assembler genagelt.

von (prx) A. K. (prx)


Lesenswert?

Frank M. schrieb:
> Die erste 3B2 mit der Seriennummer 0000000018, die über den Teich nach
> Europa ging, landete damals in der Firma, in der ich als junger Spunt
> gerade anfing. Und ich war begeistert:

Wo wir grad beim Kopieren waren: Dessen Instruction Set Architecture war 
wie manch andere der 80er sehr von der VAX inspiriert - höflich 
ausgedrückt. Mit dem gleichen Problem: Es ist schon recht aufwändig, bei 
solchen ISAs auf einen Befehl pro Takt zu kommen, ganz zu schweigen von 
mehreren Befehlen pro Takt. Die Lebensdauer solcher Architekturen war 
dadurch recht begrenzt. Beim Versuch, die VAX wesentlich zu 
beschleunigen, ist DEC deshalb beinahe koppheister gegangen.

>   - Der U3B-Prozessor beherrschte elementare C-Funktionen wie strcmp(),
>     strcpy(), memcpy(), memcmp() usw. direkt als Maschinen-Befehle.

Was nicht unbedingt ein Vorteil sein musste. Nicht selten waren solche 
Befehle langsamer als manuell programmierte Ersatzsequenzen. 
Beispielsweise weil der Microcode alle Fälle von Alignment und Overlap 
berücksichtigen muss, der Programmierer aber oft a prio weiss wie es 
sich damit verhält. Zum WE-32100 Prozessor (der von manchen AT&T 3Bs 
verwendet wurde) ist für den STRCPY Befehl eine Mindestlaufzeit von 
83-182 Takten überliefert.

Die unstrittig vorhandene Eleganz und Schönheit ist in dieser Branche 
kein wirklich entscheidendes Kriterium. Effizienz schlägt Schönheit. DEC 
wechselte zunächst zur MIPS Architektur, bevor Alpha kam.

Mir ging es allerdings zunächst nicht viel anders, als ich den nicht 
unähnlich entwickelten NS32000 und NEC V60 Architekturen begegnete. Bis 
ich ARM2 begegnete. Da wurde mir allmählich klar, wieviel man mit solch 
eleganter Komplexität verliert.

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

A. K. schrieb:
> Die unstrittig vorhanden Eleganz und Schönheit ist in dieser Branche
> kein wirklich entscheidendes Kriterium. Effizienz schlägt Schönheit.

Die Schönheit war für ASM-Programmierer ein Kriterium - auf 8086 & Co. 
ASM zu programmieren, ist nicht das reine Vergnügen, wegen der vielen 
Asymmetrien.

von (prx) A. K. (prx)


Lesenswert?

Uhu Uhuhu schrieb:
> Die Schönheit war für ASM-Programmierer ein Kriterium - auf 8086 & Co.
> ASM zu programmieren, ist nicht das reine Vergnügen, wegen der vielen
> Asymmetrien.

Yep. Aber schon die Namensgebung des STRCPY Befehls stellt klar, dass 
die 3B2 die C Programmiersprache im Sinn hatte. Immerhin war das Ding 
von AT&T.

Generell waren die 80er eine Ära, in der Mikroprozessoren zunehmend auf 
den Einsatz mit Hochsprachen optimiert wurden und 
Assembler-Programmierung in den Hintergrund rückte. Parallel dazu 
entstanden optimierende C Compiler, die weit mehr waren, als eine 
ungefähre 1:1 Umsetzung von Quellcode in Maschinencode.

IBM hatte das schon in den 70ern gemerkt, aber niemandem verraten (801).

: Bearbeitet durch User
von Timm T. (Gast)


Lesenswert?

Uhu Uhuhu schrieb:
> Wie hieß das PDP-11-Plagiat, das erfolgreich beim Klassenfeind geklaut
> war?

Ihr hättet sie uns auch verkaufen können. Wolltet ihr ja nicht.

Wenn mir jemand was nicht verkaufen will, bau ichs mir halt selber.

Frank M. schrieb:
> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache,
> also nicht praxisrelevant.

O.Montenbruck, T.Pfleger: ASTRONOMIE MIT DEM PERSONAL COMPUTER, 2. Aufl. 
1993

Alles von Koordinatentransformation bis zu SoFi-Berechnungen und 
Planetenbahnen in Pascal. Nö, ist nicht praxisrelevant...

von Uhu U. (uhu)


Lesenswert?

Timm Thaler schrieb:
> Ihr hättet sie uns auch verkaufen können. Wolltet ihr ja nicht.

Wir schon, aber wir durften nicht - das haben sich die Amis vorbehalten 
und haben prächtig daran verdient.

Ich war kurz nach Gorbatschows Amtsantritt für einige Wochen in Moskau 
bei einer Bank - was ich dort im Rechenzentrum gesehen habe, das hätten 
wir denen im Leben nicht verkaufen dürfen: u.a. das seinerzeit neuste 
Modell einer HP 3000.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Timm Thaler schrieb:
> Frank M. schrieb:
>> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache,
>> also nicht praxisrelevant.
>
> O.Montenbruck, T.Pfleger: ASTRONOMIE MIT DEM PERSONAL COMPUTER, 2. Aufl.
> 1993
>
> Alles von Koordinatentransformation bis zu SoFi-Berechnungen und
> Planetenbahnen in Pascal. Nö, ist nicht praxisrelevant...

Ich sprach davon, dass Pascal in den 70ern nicht praxisrelevant war, 
weil es damals zunächst reine Lehrsprache war. Später natürlich schon. 
A.K. hat es auch erwähnt, z.B. den Erfolg von Turbo Pascal in den 80ern.

In den 70ern jedoch wurden schon ganze Betriebssysteme in C geschrieben. 
Pascal spielte da noch eine untergeordnete Rolle.

Jetzt verstanden? ;-)

von Timm T. (Gast)


Lesenswert?

Frank M. schrieb:
> Ich sprach davon, dass Pascal in den 70ern nicht praxisrelevant war,

Nein, das geht aus der Semantik Deines Satzes nicht hervor. Bitte 
informiere Dich über Zeitformen.

Frank M. schrieb:
> In den 70ern jedoch wurden schon ganze Betriebssysteme in C geschrieben.
> Pascal spielte da noch eine untergeordnete Rolle.

In den 70ern gab es auch schon qwerty-Tastaturen, und wir benutzen sie 
heute noch. Trotzdem eine Scheissidee, oder? Dvorak und Neo spielte nie 
eine Rolle.

von Frank M. (ukw) (Moderator) Benutzerseite


Lesenswert?

Timm Thaler schrieb:
> Nein, das geht aus der Semantik Deines Satzes nicht hervor. Bitte
> informiere Dich über Zeitformen.

Tut mir leid, dass Du mich falsch verstanden hast, als ich davon sprach, 
dass Pascal 1971 als reine Lehrsprache konzipiert wurde. Wo soll ich den 
Keks hinschicken? ;-)

Kannst mir ja einen Link über Zeitformen schicken, aber bitte dann per 
PM.

> In den 70ern gab es auch schon qwerty-Tastaturen, und wir benutzen sie
> heute noch.

qwerty-Tastaturen sind geil. Ich benutze sie unter Unix und Linux und 
zum Programmieren sogar bevorzugt. Man schont dabei Shift- und 
Alt-Tasten, d.h. die in der Shell und in C sehr oft vorkommenden Zeichen 
/ { [ ] } \ sind mit nur einem Tastendruck erreichbar.

Aber wir kommen vom Thema ab.

von Michael E. (Firma: irgendeine) (nodalek)


Lesenswert?

Frank M. schrieb:

> Als Gründer des fli4l-Router-Projekts kann ich von dem Thema ein Lied
> singen...

Ich möchte dir für das Projekt Danken, es hat mir einige Jahre lang gut 
gedient.

: Bearbeitet durch User
von Arc N. (arc)


Lesenswert?

Frank M. schrieb:
> Timm Thaler schrieb:
>> Frank M. schrieb:
>>> Pascal gibt's seit 1971 - ausgelegt als reine Lehrsprache,
>>> also nicht praxisrelevant.
>>
>> O.Montenbruck, T.Pfleger: ASTRONOMIE MIT DEM PERSONAL COMPUTER, 2. Aufl.
>> 1993
>>
>> Alles von Koordinatentransformation bis zu SoFi-Berechnungen und
>> Planetenbahnen in Pascal. Nö, ist nicht praxisrelevant...
>
> Ich sprach davon, dass Pascal in den 70ern nicht praxisrelevant war,
> weil es damals zunächst reine Lehrsprache war. Später natürlich schon.
> A.K. hat es auch erwähnt, z.B. den Erfolg von Turbo Pascal in den 80ern.
>
> In den 70ern jedoch wurden schon ganze Betriebssysteme in C geschrieben.
> Pascal spielte da noch eine untergeordnete Rolle.

Kommt drauf an wie "untergeordnet" definiert wird... UCSD-Pascal 1) bzw. 
das portable UCSD p-System (Ende der 70er, Anfang der 80er) waren, neben 
anderen, die Vorläufer heutiger VMs wie der Java-VM und 
(experimenteller) Betriebssysteme und relativ weit verbreitet. Von 
Western Digital gab's eine Hardware-Implementierung 2) und Apple setzte 
bei der Lisa auf Pascal. Aufgrund der Hardwarebeschränkungen der ersten 
Macs wurde dann z.T. von Hand in Assembler übersetzt... 3)
1) http://en.wikipedia.org/wiki/UCSD_Pascal
2) http://en.wikipedia.org/wiki/Pascal_MicroEngine
3) 
http://www.folklore.org/StoryView.py?project=Macintosh&story=Hungarian.txt

von Jens M. (Gast)


Lesenswert?

Jon schrieb:
> oder Bascom? oder Java?
>
> 
http://www.heise.de/newsticker/meldung/Kritische-Luecke-in-etlichen-Routern-2655271.html

Gibt es denn die Java, Pascal oder Bascom Compiler für die 
entsprechenden Zielsysteme?

von Kim S. (Gast)


Lesenswert?

Pascal mit Sicherheit, basic,.puh k.a. vielleicht..Java vermutlich nicht

von Reinier Z. (mcnetuser)


Lesenswert?

Torsten C. schrieb:

> Warum dürfen Server und Router nicht zusammen in ein Gerät?

Sie dürften problemlos in ein Gerät. Es müssten lediglich
zwei komplett eigenständige Prozessorsysteme sein. Gehäuse
und Stromversorgung können sie sich teilen.

von Hans Ulli K. (Gast)


Lesenswert?

Jens Martin schrieb:
> Jon schrieb:
>> oder Bascom? oder Java?
>>
>>
> 
http://www.heise.de/newsticker/meldung/Kritische-Luecke-in-etlichen-Routern-2655271.html
>
> Gibt es denn die Java, Pascal oder Bascom Compiler für die
> entsprechenden Zielsysteme?

Schau mal nach welchen Libs dein Programm braucht.
Unter Linux wird meistens die libc benutzt und die ist leider in C

Dein Java ist dann zwar sicher, dein Problem liegt dann aber anderen 
Libs.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.