Impressum Datenschutz
News   Magazin   Börse   Links   ArcArchie   Homepages
 News  Home 

PipeDream, Fireworkz und Ovation Pro Updates

 <   >

PipeDream und Fireworkz
Wie RISCOSitory und Steffen Huber berichten gibt es von der Office Suite PipeDream und Fireworkz jeweils eine neue Version. Bei PipeDream, das nun die Version 4.55 vorliegt, hat nun einen verbesserten Graphikimport, der Export der Charts im Drawformat sind auch für andere Programme als Draw lesbar und es gibt einige weitere Verbesserungen. Bei Fireworkz mit Version 2.00.05 wurde der Import von Exceltabellen verbessert. Beide Programme können auch via PackMan installiert werden.

Ovation Pro
Wie RISCOSitory berichtet hat das Desktop-Publishing Ovation Pro von David Pilling hat wohl Probleme mit dem Titaniumboard und dem RapidO Ig Rechner. Mit einen Update, das man hier herunterladen kann, sind die Probleme wohl aus dem Weg geräumt.
cms, 19. 06. 2016, 11:54 Uhr <   >
...
ImageMaster bzw. DPIngScan ist jetzt frei erhältlich. Die Version die als Upgrade bei David Pilling zum download bereit steht ist eine Vollversion. Funktioniert aber auf dem IGEPv5 und Titanium nicht richtig, weil das dort eingeführte neue Spriteformat nicht unterstützt wird. Weiterentwickelt wird DPIngScan zukünftig von Chris Johnson, der mir gestern eine IGEPv5 fitte Version geschickt hat ;-)
Die Windowsversion ist auch frei ehältlich und läuft ohne Ovation Pro (in der ReadMe steht es noch anders) aber ohne Support für das neue Spriteformat...
Raik, 20. 06. 2016, 09:43 Link
Was macht man denn mit einem neuen Spriteformat ? 48bit Grafik unterstützen ?
naitsabes, 20. 06. 2016, 11:52 Link
Soweit ich weiß geht es nur um die LRGB-Modes die der OMAP5 benötigt.
Ich kann an Chris seiner Beschreibung nicht sehen, daß was Neues dazugekommen ist.
Das Problem ist auf [klick mich] zu erkennen. Rechts ein Altes mit und ohne Fehlfarbe, links oben das, was Imagemaster (alt) auf dem IGEP daraus macht.
Die Sprites werden auf alen Maschinen mit einigermaßen aktuellem RISC OS 5.23(?) richtig dargestellt. Bein Konvertieren gibt es dann Probleme.
Chris Johnson hat !Snapper und !DPIngScan angepasst. Die Sprites werden intern ins RISC OS 3.5 Format gewandelt ...
Raik, 20. 06. 2016, 13:19 Link
OK. Von Bild ist da nicht mehr viel zu sehen.
naitsabes, 21. 06. 2016, 14:21 Link
Nicht wirklich ;-)

Kurioser Effekt. Das Bild ist ursprünglich 720p. Das alte ImageMaster macht daraus irgendwas um 21000x720. Kann sein ich habe sogar noch eine Null vergessen!
Raik, 21. 06. 2016, 16:45 Link
Ich habe es ja schon immer gewusst, dass man besser beim RISC PC bleibt.
Isip, 22. 06. 2016, 07:00 Link
@Isip: Sorry das wir das damals mit meinem Beagleboard angefangen haben ;-) ...
Uwe, 22. 06. 2016, 13:43 Link
Mit jeder neuen Technologie neue Inkompatibilitäten und Probleme. Das war damals schon so ein Mist vom Archimedes auf den Risc PC und hat sich ein jedes Mal mit jeder neuen Maschine und jeder neuen Betriebssystemversion wiederholt. Inzwischen passt irgendwie überhaupt nichts mehr zusammen. Das Ärgerliche dabei ist, dass diese ganzen RISC-OS-Systeme nie wirklich jemals ausgekitzelt worden sind, wie es beim Commodore 64 irgendwann der Fall gewesen war. Die Entwicklung der Software hinkte immer mehr der Entwicklung der Hardware hinterher. Schade eigentlich.
Isip, 22. 06. 2016, 19:36 Link
Das Problem hat mit dem ARM3 angefangen. Der A5000 hätte nie gebaut werden dürfen.
cms, 22. 06. 2016, 20:14 Link
Das stimmt.
Denn dann hätte ich damals(TM) nie einen gekauft, würde diese Seite nicht kennen und müßte mir nun nicht hier alle naselang dieses, meist doch relativ unberechtigte, Rumgejammere und Genörgel anhören.

Seid doch froh, daß mal was Neues kommt !

Guckt Euch die anderen "Alternativsysteme" ( aka Homecomputer ) an, da gibt es mal 'nen Floppyemulator, eine FPGA Simualtion der alten Maschinen oder sowas, aber kein neues Mainboard und schon gleich keines, was dann auch noch funktioniert. Und die Software wird doch gerade angepaßt (und ist in den allermeisten Fällen dann auch noch rückwärtskompatibel (weshalb man solches Zeug, wie einen RiscPC überhaupt noch halbwegs sinnvoll benutzen kann)) - darum ging es doch im Text.
naitsabes, 22. 06. 2016, 23:13 Link
Zusätzlich ist es möglich ein neues Komplettsystem für 200 Euro zu kaufen. Komplet meint inklusive Tastatur, Maus und Monitor.
cms, 23. 06. 2016, 06:29 Link
Die Ironie war ned zu hören?
Isip, 23. 06. 2016, 07:00 Link
Ich lese nicht laut, was soll ich da hören ;-)

Also ich nörgel nicht, im Gegenteil und ich entschuldige mich auch nicht, daß ich mal begonnen habe "Kisten" zu bauen ;-)

In dem DPIngScan-Fall war es so, Do. das Problem bemerkt, Freitag den Arsch bewegt, sprich ein paar Mails geschrieben und Sonntag hatte ich die Lösung.
Immer wieder erstaunt bin ich über David Pilling. Offiziell für RISC OS nicht mehr aktiv, hat es keine Stunde gedauert, bis er sich meldete...
Aber auch die Anderen sind bei Problemen sehr schnell und helfen.
Raik, 23. 06. 2016, 08:56 Link
Die Leistungsfähigkeit der Gemeinschaft muss man schon loben. Eigentlich unglaublich, was da seit dem Tod von RISC OS inzwischen geschaffen worden ist. Das gibt es meiner einer nach so auf keinem anderen System mehr, oder? Dass ich trotzdem ein wenig nörgle, liegt halt daran, dass sich immer was finden lässt - und ich halt Baier bin.
Isip, 23. 06. 2016, 12:43 Link
Auf anderen Systemen passiert auch was. Sie WiFi-Modul für den C64.
Immer wenn Leute mit "Herzblut" dabei sind. Nur das ausserhalb der Szene kaum jemand davon Kenntnis erhält.
Raik, 23. 06. 2016, 13:29 Link
Weiß ned. Von der Digitaltalk habe ich schon ewig nix mehr gehört. Und andere Contakte zum C64 habe i ned. Allerdings ist der C64 noch immer der C64 und ned ein Titanium, RPI oder so. Trotzdem interessant, was man über solche Herzblutsleut alles erfahren und lernen kann. Da kann man fast jede Computerzeitschrift dagegen vergessen. Deswegen habe ich meine Seele auch noch immer nicht an die dunkle Seite der Macht verkauft.
Isip, 23. 06. 2016, 19:29 Link
Ach ja, und die (Fachhoch)Schulen sowieso. Tut mir leid, das schreiben zu müssen. War aber zumindest meine persönliche Erfahrung. Besser gleich sich alles selbst beibringen. Nur wie?
Isip, 23. 06. 2016, 19:30 Link
Bücher lesen ? Wenn man da gute erwischt, kann das sehr effektiv sein.

Es gibt aber auch gerade im Informatik Bereich durchaus ein paar ansehenswerte Online-Kurse und VideoTutorials (vornehmlich an amerikanischen Unis) und gut gemachte Themenseiten. Zum Thema Grafik gibts was unter (click) - als Beispiel, und weil ich es sehr brauchbar fand.
naitsabes, 23. 06. 2016, 21:07 Link
...also von wegen toter Systeme...hab mir zum Spaß nen Amiga 1200 zugelegt und lese gespannt das 2-monatlich erscheinende Heft "Amiga Future"...hat glaube ich immer noch ne 700'er Auflage und da geht sowohl bei Hardware als auch Software noch richtig was nach vorne...
Kümmel, 23. 06. 2016, 23:02 Link
@Isip: Wenn Du Ironie äußerst kannst Du durch das plazieren eines Emoticons sicher sein dass jeder das merkt.. Das korrekte Emoticon für Ironie ist dieses: ;-)

Natürlich kann man über die Verwendung der Emoticons streiten, aber gerade auf einem rein textlichen Medium geht eben doch einiges von der Stimmung verloren die man meint klar herüber zu bringen - und wenn Dich jemand persönlich nicht kennt ist das nochmal zweideutiger als Du selber denkst...

Soo jetz flamed mich mal schön mit meiner besserwisserei :-)

Schöne Grüße,

Uwe

P.S. Und ja, ich fands auch total Geil dass sich soviel Hardware gefunden hat und ein Jeffrey, der das ganze erst möglich gemacht hat (der Wahnsinnige!) Irgendwie sind wieder richtig die 'alten Zeiten' ausgebrochen und ich find's herrlich. Und das Beste ist - es geht immernoch weiter :-)
Uwe, 24. 06. 2016, 08:52 Link
Und ausserdem haben wir jetzt wieder ganz klar einen richtig exotischen Rechner - von einer komischen Insel irgendwo ausserhalb von Europa ;-).

Bin mal gespannt ob Schottland und gesamt-Irland demnächst EU- Beitrittsverhandlungen aufnehmen. Beim Fussball sind sie ja offenbar schon recht eigenständig unterwegs...

Schöne Grüße,

Uwe
Uwe, 24. 06. 2016, 09:09 Link
Müssen die jetzt mit Ihrer Insel aus der 12 Meilenzone rausrudern? Hab gestern oder vorgestern eine Animation in den Nachrichten gesehen, da sah das so aus. ;-)
Raik, 24. 06. 2016, 10:05 Link
Ausnahmsweise off the topic. Wie es aussieht sind ARM Prozessoren bald am oberen Ende angelangt. Fehlt nur noch der Desktopbereich des Mainstreams. Aber wenn ich das richtig verstehe arbeitet man bei den Äpfeln schon seit ein paar Jahren daran.
klick
cms, 24. 06. 2016, 11:10 Link
Bei mir ist alles Ironie und Humor. Saublöd daherreden ist den Baiern in die Windeln gelegt. Was soll ich da also noch extra wie ein Hund markieren gehen?

Schade ist halt, dass so wenige von den ganzen Entwicklungen mitbekommen, ich eingeschlossen. Was in der C64 und Amiga-Szene abgeht, kriege ich schon lange nicht mehr mit. Früher gab's ja noch sowas wie die GO64! am Kiosk, aber heute suche ich mich wund nach solchen Zeitschriften.

Mit den Büchern habt ihr sicher recht; aber es müssen die richtigen sein. Das ist mit Sicherheit wesentlich effektiver als die Schule. Nur für RISC OS und speziell Oberflächen- und Anwendungsprogrammierung gibt es halt kaum etwas. Gut zwar, dass da jetzt auf Arcsite.de endlich jemand einen Kurs dazu schreibt, aber ohne jetzt den Autor kritisieren zu wollen, finde ich den halt ziemlich schlecht, chaotisch, schlecht verständlich und durcheinander. Fast so schlimm wie das von Detlef Thielsch übersetzte Buch "Wimp-Programmierung unter RISC OS". Und recht viel mehr gibt es nicht, oder liege ich da falsch? Zumindest ist mir nicht wirklich etwas bekannt (im deutschsprachigen Bereich).

Und wer zum Henker ist Jeffrey und was hat der möglich gemacht? Ich komme da jetzt ned ganz mit...
Isip, 24. 06. 2016, 19:53 Link
Jeffrey: Zum Glück ist bei Dir alles "Ironie und Humor"!
cms, 24. 06. 2016, 22:10 Link
Satire habe ich vergessen. Von Jeffrey Lee wusste ich natürlich bereits aus der Archive (Jim Nagel). Ich weiß damit sogar, wie er aussieht. Aber trotzdem kenne ich ihn so gut wie gar nicht, jedenfalls nicht en natura. Ich bin ihm noch nie begegnet, und darauf habe ich mich bei obiger Aussage bezogen. Trotzdem vielen herzlichen Dank nochmal für den Hinweis. Ich hatte es eh schon wieder so gut wie vergessen gehabt, was er denn nun eigentlich gemacht hatte.

Hätte das nicht eigentlich die Arbeit von RISC OS Select sein sollen - RISC OS 32-bit fähig zu machen bzw. auf neue Hardware zu portieren (was mit dem A9home ja auch geschafft worden war)? Komisch nur, dass genau das scheinbar gar nicht erlaubt gewesen war, da ja RISC OS Select irgendwie von Castle lizensiert worden sein musste oder so. So ganz habe ich das bis heute ned kapiert.
Isip, 25. 06. 2016, 04:59 Link
Werde mich versuchen, in Zukunft wieder mehr zusammenzureißen (und damit mehr ernst zu bleiben). Aber wie soll man in dieser Welt auch ernst bleiben können? Die Ironie, der Humor und die Satire, das sind alles Waffen, um sich gegen diese Welt zu wehren. Denn ansonsten könnte man sich ja gleich erschießen. Bei dem ganzen Unsinn, der alltäglich gemacht wird. Leider.

So, wie ich das verstehe, hat LeeCraft (Jeffrey) einen neuen Kernel für RISC OS geschrieben (bzw. den alten 32-bit-fähig gemacht). Erinnert mich ein bisschen an Linus Torwald. Jetzt würde mich aber interessieren, wo man so etwas lernt oder wie man an solche Kenntnisse herankommt. Was hat denn der für einen Hintergrund, dass er sowas kann?
Isip, 25. 06. 2016, 07:36 Link
RISCOS Ltd.: Wenn ich das richtig vermutet hatte ROL nur eine Lizenz für RISC OS 4 und deren Weiterentwicklung _für_ _Acornrechner_. Die A7000+ Klone von RiscStation und MicroDigital wurden wohl geduldet, da dort nur sehr wenig (vom Hersteller?) angepaßt werden mußte und das für den damaligen Beitzer von RISC OS eh Penauts war.

Der Omega und der A9home sind bekanntlich kein Rechner von Acorn. Wenn ich das richtig verstanden habe hat MicroDigital sich auch bemüht den Omega wie ein Risc PC aussehen zu lassen. Da wo es nicht ging mußte halt MicroDigital in die Tasten greifen. Da hatte es ja dann auch mit dem RISC OS Stunk angefangen. Den Omega gab es auch nicht wirklich zum. Nur ein paar Prototypen sind rausgegangen.

Der A9home wurde dann richtig verkauft, wenn auch nur in kleinen Stückzahlen. Da ist dann Castle eingeschritten und die Weiterentwicklung von RISC OS für den A9home wurde eingestellt. Damit war Select alias 6 eine Sackgasse.

Jeffrey hat keinen neuen Kernal geschrieben sondern das IYONIX pc RISC OS so angepaßt das es auch dem BeagleBoard von Uwe und später anderen Boards lief. Zusätzlich hat es hier und dort weitere Anpassungen und Verbesserungen in Angriff genommen. Später kammen dann weitere Programmierer dazu.

Keine Ahnung, aber vermutlich hat Jeffrey Informatik studiert und viele Nachte vor dem Bildschirm verbracht. Für mich ist Jeffrey Lee einer der wichtigsten Menschen in der RISC OS Welt und hat die goldene Eichel mit Brillanten verdient.
cms, 25. 06. 2016, 10:40 Link
Danke für die Aufklärung. Und was tut man jetzt, nachdem sich die Briten dazu erklärt haben, die EU zu verlassen? An RISC-OS-Zeugs zu kommen, das war auch so schon immer Stress genug. Von wegen der Gang zum nächsten Computerhändler. In meinen Jugendjahren bestellte ich die Sachen meist telefonisch oder schriftlich in UK und lief dann auf die heimische Bank, um das Geld auf die Insel zu überweisen. Das war sehr aufwändig und teuer, lief aber relativ gut. Und außerdem lernte ich sehr viel dabei. Allerdings isolierte es mich von den Freundeskreisen vor Ort, die sich natürlich alle Microsoft Windows / Intel verschrieben, weil es da niemals ein Problem war, an irgendwas heranzukommen.

Allerdings sei mir die Anmerkung erlaubt, dass ich denen ihre Systeme immer als "billigen" Mist empfand, den ich so nie hatte haben wollen. Ich wollte immer Qualität haben, weshalb ich bis heute bei Acorn / RISC OS geblieben bin. Aber genau deshalb gelte ich vielen wohl noch immer als Snob / Spießer und werde dementsprechend gemieden. Klar, dass ich kaum bis keine Freunde habe. Und Frauen mögen mich deshalb ja auch nicht, warum ich noch immer ledig und Single usw. bin.
Isip, 25. 06. 2016, 14:54 Link
Weiß nicht, ob sich durch den Brexit (wann immer er denn tatsächlich vollzogen wird) groß etwas für den Endverbraucher in der EU ändert. Schon bisher durfte ich einige Pakete aus England beim Zollamt abholen, da kommt halt zusätzlich dann noch Einfuhrumsatzsteuer drauf, dafür bleibt die britische VAT weg.

Ansonsten zahlen wir weiter per PayPal, freuen uns über das schwache Pfund und laden die Software direkt runter, statt auf ein Paket zu warten.
hubersn, 25. 06. 2016, 15:33 Link
Die RISC OS-Geschichte im Bermuda-Dreieck ROL - Pace - Castle wäre sicher ein spannender Roman. Das größte Problem: jeder erzählt eine andere Geschichte.

Castle z.B. sagt, dass nach ihrem Erwerb von "all things RISC OS" von Pace 2003 ROL die Lizenzgebühren nicht oder nicht vollständig bezahlt hat, insbesondere von der Emulator-Front (V-RPC). Das führte dann zur "licence termination".

Die Emulator-Geschichte (erst RO 3.1 im VirtualA5000, dann RO 4 im VirtualRPC) ist auch zusätzlich interessant, weil verschiedene Parteien behaupten, die ROL-Lizenz hätte es nicht erlaubt, RISC OS 4 für nicht-Hardware zu lizenzieren.

(Ex-)Pace-Mitarbeiter sagen, dass ROL der Verpflichtung (laut ihrer RISC OS-Lizenz) zur Verfügungstellung der Änderungen an RISC OS nicht nachgekommen sei und damit die Lizenz automatisch terminiert wurde.

ROL sagt, dass Castle mit dem IYONIX pc ihre Exklusiv-Rechte im Desktop-Bereich verletzt habe und RISC OS 5 niemals richtig lizenziert war ("nicked from Pace" ist ein Originalzitat von Paul Middleton).

Seit 2009/2010 (seit Aaron/3QD ROL übernommen hat) gibt es die Theorie, dass ROL alle Rechte an RISC OS hält - das wurde bisher nicht stichhaltig begründet, sondern basiert darauf, dass irgendwie durch Änderungen unter ROL-Ägide irgendwie das Copyright auf ROL übergegangen ist. Oder so ähnlich.

Dass es hingegen mit der diversen "nicht-Acorn-Hardware" wie A9home, Mico, RiscStation oder Omega Lizenzstress gegeben hat, wie Carlos sagt - daran kann ich mich nicht erinnern. Es gab mal Probleme zwischen MicroDigital und ROL weil MD einfach RO4-Lizenzen haben wollte ohne die Hardware durch ROL zertifizieren zu lassen, aber MD hatte mit so vielen Dingen Probleme...

Interessiert können die Diskussionen in den Drobe-Archiven nachlesen, quasi zum Einstieg:
* http://www.drobe.co.uk/article.php?id=2511
* http://www.drobe.co.uk/article.php?id=2372
hubersn, 25. 06. 2016, 17:25 Link
Wenn ich micht recht erinnere ist Jeffrey hauptberuflich "Spielkonsolenprogrammierer". Zumindest um 2011 rum war das so. Vielleicht kann er inzwischen von seinem "ROOL Engagement" leben.
Zur Verbesserung des a9home hat er nach meiner Erinnerung auch was beigetragen. Kann mich aber gerade nicht erinnern was.

Die Sache mit der "nicht-Acorn-Hardware" habe ich auch irgendwo gelesen. In der GAG News? Herbert hat auch mal versucht "Licht ins Dunkel" zu bringen.

Ich glaube jeder Beteiligte hat seine eigene Wahrheit. Scheinbar waren die Verträge nicht das Papier wert, auf denen sie standen.
Raik, 25. 06. 2016, 21:14 Link
Das mit den Spielekonsolen stand damals so irgendwie auch in der Archive. Ich habe die jetzt leider nicht greifbar.

Schade ist halt freilich die Herumstreiterei. Dass da die Leute irgendwann ned mehr mögen, kann man ja wohl auch irgendwie verstehen. Ist ja fast wie in der EU. Aber scheinbar ist UK auch innerhalb stark gespalten.

Trotzdem denke ich nicht, dass es sehr viel bringen wird, da jetzt noch im Nachhinein "Licht ins Dunkel" zu bringen. Interessant wäre es ja schon, aber zumindest mir würde es persönlich und für meine Rechner wohl gar nichts bringen. Da sind mir praxistaugliche (Programmier)Artikel lieber. Vielleicht lern ich's dann ja doch noch irgendwann.

Mit dem Austritt von UK aus der EU wird sich für den Bezug von RISC-OS-Artikeln (Hardware wie Software) freilich nicht viel ändern. Paypal habe ich selbst aber noch nie verwendet. Ich habe auch keinen blassen Schimmer, wie das funktioniert. Ich habe es immer über die Bank machen lassen. Leider wurde dieser Service im Laufe der Jahre aber immer schlechter, bis er gar nicht mehr funktionierte (Raiffeisenbank Traunstein, viele Filialen geschlossen, inzwischen zu einer Südostoberbayern mit Hauptsitz in Bad Reichenhall fusioniert). Das letzte Mal hatten die viel zu wenig Geld nach UK überwiesen. Die haben mir die Sachen dann trotzdem geschickt. Ich habe ihnen dann einen Umschlag mit dem Geld per Post nach UK geschickt, was auch geklappt hat. Seitdem bin ich aber bei der Postbank. Nix mehr mit Raiffeisenkacke. Die Post baut aber leider jetzt auch gewaltig den Service ab. In unserer Stadt wird diesen Monat die letzte Filiale geschlossen. Die nächste ist dann über 30 km entfernt. Bei sowas fragt man sich dann schon. Da zählen nur noch Bilanzen. Aber nicht mehr der Mensch (um den es eigentlich gehen sollte).
Isip, 26. 06. 2016, 07:42 Link
zu der Kompatibilätsgeschichte die am Anfang noch diskutiert wurde: das Problem bei den damaligen Homecomputern (dazu zähle ich C64, Amiga, Archimedes usw.) war ja, das zu viel Low-Level programmiert wurde. Es wurde natürlich aus Performance-Gründen gemacht und um die letzten geheimen Features oder sogar Bugs nutzen zu können. Aber das war dann auch der Todesstoß, wenn eine Nachfolgegeneration an Hardware raus kam.

Wäre alles Hi-Level und vor allem gegen die OS-API programmiert worden, hätte es viel weniger Probleme gegeben, Software auf der nächsten Generation zu verwenden.

Ich spreche jetzt nicht von Szenedemos, sondern von Anwendungen und Spielen. Wenn man als Entwickler will, das sie lange ohne Stress verwendet werden sollen, muß weg von Assembler und weg von direkten Hardware-Zugriffen.

Dann war noch ein anderer fataler Fehler: ARM Ltd. Das war wohl der Fehler von Acorn die CPUs aus der Hand zu geben. ARM Ltd. hatte sich dann nur noch für Embedded interessiert. Das ist das genaue Gegenteil, was man für Desktop-PCs braucht. Nicht nur was die Leistung angeht, sondern auch die Kompatibilität. Denn im Embeddedbereich interessiert es nicht, ob Software ohne Änderung läuft. Klar, der Anwender installiert da nichts selber, wird ja alles fertig ausgeliefert. Kontraproduktiv für Acorn Risc PC und Nachfolger.

ABER, hätte man z.B. RISC-OS-Anwendungen mit einer Bytecode-Sprache entwickelt (also extrem Hi-Level, weit über C++), wären die Probleme nie da gewesen. OK, Bytecode-Sprachen waren damals ihrer Zeit weit voraus und deshalb nicht effiezient genug.

Wenn RISC OS und ihre Anwendungen in Zukunft weiter überleben wollen, müssen die Entwickler weg von Low-Level. C++ und gegen die RISC OS API ist das Minimum. Am Besten so etwas wie Java mit Hotspot. (nein, Java hat nichts zwangsweise was mit WebSeiten zu tun, kann man ganz normal Desktop-Anwendungen mit entwickeln)
Artchi, 30. 06. 2016, 10:41 Link
Ich denke bei den 8 Bitern wie den C64 hatte man keine Chance als ressourcensparend in Assembler und dann in die Hardware bzw. dem Betriebssystem zu hacken. Nicht schön, aber solange kein Update der Hardware oder dem Betriebsystems (sollte man das besser Firmware nennen :-) kommt kein Problem unbd alles ist eingefroren.

Bytecode/virtuelle Maschinen fressen natürlich Ressourcen, aber das sollte mit moderne ARM Rechner kein Problem mehr sein. Es muss ja nicht Java sein. Nebenbei: Bitte Java nicht mehr im Browser verwenden, braucht man dort nicht mehr und ist einer _der_ Sicherheitslücken neben Flash! Das kann man im Browser sowie in der Javakonfiguration deaktivieren. Artchi und ich meinen Java und nicht JavaScript. So etwas wie Java oder .net empfinde ich aber nicht als zwingend. Mit Umgebungen wie zum Beispiel Qt oder GTK+ und dynamischen Linken (ELF) würde man auch einige Probleme aus der Welt schaffen.

Das hochheben von Bytecode-Sprache von Dir halte ich für etwas übertrieben ("extrem Hi-Level"). Wenn ich mich nicht irre kann man auch in C++ für .net programmieren. Im Prinzip könnte man auch BBC BASIC für die Java VM oder .net portieren. Klar ist das nicht wirklich sinnvoll. Nebenbei ist bei RISC OS BASIC einer der Konstanten. Wenn da kein Assembler drin ist, sind die Chancen sehr groß das RISC OS 3 oder sogar 2 Programme unter RISC OS 5 und moderner Hardware läuft.

BTW: Damals gab es mit p-code von UCSD Pascal schon so etwas ähnliches wie eine VM.

Ich denke das war kein Fehler von Acorn die ARM Prozessoren auszugliedern. Ansonsten wären heute andere Prozessoren in den mobilen Telephonen, Smartphones, Router und alle die anderen embedded Geräten drin. Vielleicht wäre es auch nie zu einen StrongARM gekommen und der ARM8 wäre die Spitze für die Risc PCs gewesen. Ein ARM9, ohne der Erfahrung vom StrongARM, wäre vermutlich nicht erschienen, da es damals schon keine Acornrechner mehr gab. Ich denke im Gegenteil ohne den Umweg Embedded würde es kein ARMv7 und mit Einschränkung ARMv8 für RISC OS geben. Es fehlt neben vielen Kleinigkeiten noch die Unterstützung von mehreren Kernen.
cms, 30. 06. 2016, 12:08 Link
Na, Acorn hatte halt kein Geld mehr und musste deshalb das Tafelsilber verscherbeln (also ARM).
Aber der Einwurf, dass BASIC ja schon da war trifft tatsächlich den Kern. Zur damaligen Zeit war BBC BASIC genau das, was Highlevel- Weiterverwendbarkeit schon aus der 8-Bit Zeit herübergerettet hat.
Diese Gedanken mit Objektorientierung (C++, Java) kamen ja erst deutlich später aufgrund wachsender Programmkomplexitäten an die Oberfläche. Ich denke mal das Developer Studio war ein Werkzeug wogegen Acorn nicht anstinken konnte das damals schon sehr früh erlaubte große Teile des Codes automatisch zu generieren, und dann nur noch die Teile Verstehen zu müssen wo der eigentliche Code hereingeschrieben werden musste. Also doppelklich auf den Button der die Funktion startet -> man ist automatisch an der Code-Stelle (mit ein bischen Erklärung und Beispielcode) an der man dann seinen Code hereinschrieb. So ein bischen wie Dr.Wimp, nur eben nicht in Basic sondern dann in frühem C++ und mit Klicki-Bunti Anbindung übergossen. Was die ganzen Macros machten wusste wohl kaum einer.
Ich habe selber am Archie verfolgt wie C++ aus der Taufe gehoben wurde und das Ganze mit den mickerschuft-Compilern sowie dem gcc verglichen. Und das war bereits in den 90'ern. Von daher hat Acorn echt sehr viel richtig gemacht. Auch die saubere API-Dokumentation über die Programmers Reference Manuals war top - inklusive Style Guide - aber die Nutzerbasis war hierzulande nicht so groß, und auch die Enthusiasten liessen sich nicht wirklich Überzeugen mal so einen 'Wizard' und die dazugehörige Bibliothek zu erschaffen. Schade. Habe damals mehrere Anläufe probiert, ist aber nie einer mitgezogen.
Aber egal Spaß gemacht hats trotzdem und die ganzen Grundlagen und Softwaretechniken die ich mir damals in den Öcher Informatikbibliotheken zusammengetragen habe nutze ich halt jetzt und programmier quer durch den Gemüsegarten was mir halt so unterkommt.
Aber Basic hat halt definitiv seit mindestens 20 Jahren seinen Zenith überschritten, auch wenn's einem mit VBA Makros doch immerwieder über den Weg läuft.

Also wer nochmal Lust hat sich mit einem Programmierwizard für Acorn in C++ mit Toolbox (und neuestem gcc?!) auseinanderzusetzen - ich mach gerne mit :-)

Schöne Grüße,

Uwe
uwe, 30. 06. 2016, 14:48 Link
In meinem Beitrag ging es erstmal ums Prinzip. Du hast Recht, es gibt natürlich auch noch andere Bytecode-Sprachen, aber Java und C# sind so die bekanntesten, da sie von der Syntax mit C/C++ ähnlich sind. Und Programmierer ungerne umlernen, bietet es sich an.

BBC Basic könnte man auch nehmen, ist aber leider nicht Objektorientiert. Man müsste das BBC Basic stark weiter entwickeln und an die heutigen Bedürfnisse anpassen. Ich hatte damals selber sehr gerne BBC Basic benutzt, da es damals wirklich gut war. Aber keiner würde damit heute gerne größere Anwendungen entwickeln wollen/können.

Aber auch C++ ist Hi-Level genug, richtig. Zumindest so weit, das man im Notfall nur neu kompilieren müsste (z.B. weil die nächste ARM-Generation wieder inkompatibel ist). Es ist wichtig, das man den Sourcecode nicht noch absuchen müsste, wie es bei Assembler der Fall ist.

Damals zu C64-Zeiten war natürlich ASM unerlässlich. Aber auf dem Archimedes hätte man schon vieles zumindest in C/C++ machen können. Da C eigentlich nur ein "besserer" Assembler ist, ist der Performance-Nachteil nicht relevant. Mit C++ entfernt man sich noch weiter von der Hardware (mit der Hardware-nah-Option).

Egal, hauptsache die RISC OS Community ist heute so weit sensibelisiert, dass sie nicht in ASM oder C programmiert und vorallem OS-APIs benutzt. Sonst wird sich irgendwann die Geschichte wiederholen...
Artchi, 30. 06. 2016, 15:01 Link
Ja, auf Assembler sollte man heutzutage weitestgehend verzichten. Nur bei kleinen Programmteilen um die Performance zu verbessern würde ich das akzeptieren. Dann ist auch die Umsetzung auf die nächste ARM Generation kein riesiger Aufwand wie zum Beispiel bei Impression.

BBC BASIC ist prima für kleine Aufgaben, aber bei größeren Programmen wird es dann schwierig den Überblick zu wahren. Da würde ich eher auf RiscLua setzen.
cms, 30. 06. 2016, 15:33 Link
Wie wird es eigentlich mit dem Wechsel auf 64-Bit-ARMs aussehen? Wird es so etwas wie WOW64 geben? Oder ist das gar nicht nötig?
Ich muss sagen, das ich bzgl. 64bit-ARM nicht informiert bin.

Mit Bytecode-Sprachen wie BBC-Basic, Java, C# oder Smalltalk müsste man ja nur die Runtime-Engine (Hotspot) portieren und alle Anwendungen würden weiter laufen.

Bei nativen Anwendungen könnte es z.B. Schwierigkeiten bei nativen Plug-Ins geben. Also selbst wenn jemand seine 32-Bit-Anwendung auf 64Bit-ARM portiert, und es dafür 32-Bit-Plugins gibt, wären die Plug-ins nicht lauffähig. Da müssen alle mitziehen.
Artchi, 30. 06. 2016, 15:40 Link
Das ist schon ein Argument für eine VM.

Ich glaube ARMv8 ist überhaupt nicht mit den vorherigen Generationen kompatible. Wenn das stimmt wird es schwer mit einer Portierung von RISC OS. Aber das kenne wir schon. ;-)

BTW: Ich sehe nicht den Grund warum es heute ARMv8 Smartphones gibt. So weit ich weiß nutzt keines davon mehr als 4 GByte RAM und der Geschwindigkeitsgewinn wird sicherlich für kürzeren Laufzeiten bestraft. Im Server- und Desktopbereich sehe ich da schon Vorteile.
cms, 30. 06. 2016, 16:35 Link
@isip
Ich benutze
http://currencyfair.com/

Um Geld in der UK zu senden.

Gruß


Mark B.
Mark, 30. 06. 2016, 20:40 Link
> Egal, hauptsache die RISC OS Community ist heute so weit sensibelisiert,
> dass sie nicht in ASM oder C programmiert und vorallem OS-APIs benutzt.

Was spricht denn gegen C ?
(Die Sache mit dem "besseren Assembler" stimmt doch so einfach nicht wirklich.)

Interessant wäre auch mal eine Diskussion, ob es nicht sinnvoll wäre, eine Art "Hyperebene" einzuführen, auf der man so Kommandos hat, wie "konvertiere-bild-von-jpg-nach-png","spiele-musikfile","zeichne-kreis","melde-speicherbereich-32MB-an(heap)" bis zu "drehe_teekannenbild_auf_3D_Laseroutput". Also quasi noch oberhalb der SWIs und direkt vom CLI aufrufbar - und zwar ähnlich strikt definiert wie die SWIs (und dokumentiert), aber eben von jedem aufrufbar. Insbesondere dann sinnvoll, wenn Programme mal anfangen, das auch zu benutzen - und vor allem ihre eigenen interessanteren SubRoutinen da einzustellen. Die Prozessorzeit, die man da beim Aufrufen verbrezelt, sollte eigentlich mittlerweile vorhanden sein, aber der große Vorteil wäre, daß man quasi das funktionale Programmieren auf eine Ebene weiter hoch(!) hieft und sich auf die Art durch Wiederverwertung wahrscheinlich ziemlich gut reine Programmierzeit einsparen läßt, zumindest für Applikationen - und das scheint ja ein Hauptproblem zu sein.
naitsabes, 01. 07. 2016, 12:06 Link
Ich versuche momentan grundsätzlich erst einmal, das "unter der Haube" zu verstehen. Ich hatte C auf der Fachhochschule und muss sagen, ich hatte nie viel davon verstanden. Seitdem ich aber den "Umweg" über Assembler / Maschinensprache geht, sieht es ganz anders aus. Denn jetzt kann ich mir endlich vorstellen, wie das in etwa funktioniert.

Das mit den Oberflächen zusammenklicken hatten wir auch schon. Aber ich kann einfach nicht damit arbeiten, wenn ich nicht verstehe, wie das funktioniert.

ELV bietet übrigens einen fertig verpackten Raspberry PI 3 für 90 Euro an. Netzteil wird ebenfalls mitgeliefert, Tastatur, Maus und Monitor fehlen allerdings. Ob RISC OS mitgeliefert wird, entzieht sich meiner Kenntnis. Ich denke allerdings schon, weil Noobs genannt wird. Allerdings werben die immer mit dem arschlangsamen Linux (was eh keinen interessiert). Ich hatte Linux ebenfalls 'mal ausprobiert, aber RISC OS ist da irgendwie viel schneller.
Isip, 01. 07. 2016, 19:19 Link
Das ist ja wahrschinlich überhaupt eine ganz spannende Frage, auf welchem Level man da sinnvollerweise anfangen sollte! Die meisten hier haben wahrscheinlich mal BASIC in den Fingern gehabt, um dann mehr oder weniger schnell zu Assembler und/oder einer gängigen Hochsprache ala C/Pascal zu wechseln (auf dem Archie vielleicht auch nur nötig, weils dann auch brauchbar compilierbar war).
Das gilt aber schon ein Weilchen so nicht mehr. Ich weiß nicht, was heute so der "gute" Einstieg wäre. Ich vermute Python wäre eine gute Variante. Und Java eine oft genutzte ?

Für die Zukunft gilt aber vermutlich, daß es den Adress-Juggler, der die Maschinencodes noch alle auswendig kennt, nicht mehr so unbedingt geben wird. Darum auch ist es m.E. wichtig, daß es eine abstraktere Ebene gibt, die dieses neue Herangehen auch unterstützt - auch für RISC OS.
Wir verlassen gewissermaßen momentan die "Gutenberg-Galaxis" (nach Marcshall McLuhan), was manches verändert - auch beim Programmieren, nur daß die Alteingesessenen, daß gar nicht wollen, weil es Umlernen bedeuten würde und tradierte Herangehensweisen ändert.
Ich habe z.B. noch nie von jemandem gehört, der mit Lisp oder SmallTalk angefangen hat, aber eigentlich wäre es vielleicht mittlerweile ganz konsequent. Das daneben dann Hardwarekenntnisse noch ganz hilfreich sind, ist ja richtig, aber es ist keine unvermeidbare Grundbedingung für normale Programmbastelei mehr.

Und das wird sich vermutlich eher noch beschleunigen, wenn dann demnächst die Smartphones (und Rhaspberries) mit stacked RAMs daherkommen und statt 4GB eher 128GB haben werden.
naitsabes, 02. 07. 2016, 13:38 Link
Grundsätzlich stelle ich hier jetzt 'mal die Frage, inwiefern die RISC-Architektur bei Verwendung von solchen Hochsprachen oder Zwischenschichten überhaupt noch sinnvoll ist. Sind andere Prozessoren (CISC) nicht so konstruiert, dass sie bereits auf Maschinensprache-Ebene eher kompatibel bleiben können, obwohl sich irgendwo unter der Haube etwas geändert hat?

Dass die Computer und Software inzwischen sehr komplex geworden sind, dürfte klar sein. Mein Anliegen aber ist das Verständnis. Wie kann man trotz der Komplexheit noch halbwegs verstehen oder begreifen, was man da tut - bei aller Abstraktion? Für mich ist es Frust pur, irgendeine Software zusammenklicken zu müssen. Das hat meiner Ansicht nach mit Verständnis nicht mehr viel bis gar nichts mehr zu tun. Und überhaupt, mit solchen Dingen wie Dr. Wimp oder der Toolbox komme ich bisher gar nicht klar, weil ich nicht verstehe / weiß, was ich da tun muss, um damit eine Software zu "schreiben".
Isip, 02. 07. 2016, 14:57 Link
Eigentlich ist heute die Prozessorarchitektur nachrangig. Historisch war CISC entstanden, weil viel Assembler programmiert wurde und man den Programmieren etwas Komfort bieten wollte. Die RISC-Idee war dann, die Komplexität vom Prozessor in den Compiler zu verlagern. Der ARM war da fast eine Ausnahme, weil er zwar simplifiziert aber eben auch einfach war - wer mal HP PA-RISC programmiert hat oder MIPS, wird verstehen was ich meine.

RISC/CISC spielt eigentlich bei der Überlegung zur Rückwärtskompatibilität keine Rolle - kann man bei beiden machen, ist halt Aufwand und erfordert ggf. Kompromisse bei Performance oder Kosten oder Stromverbrauch oder bei allen dreien. Intel sind die Rückwärtskompatibelfanatiker, ARM eher nicht.

Interessant ist, dass mit MMX die Zeit begann, wo wieder die Low-Level-Frickler bedient werden. Bis heute werden diese ganzen Beschleuniger- und Vektorisiereinheiten von den Compilern eher stiefmütterlich behandelt, weil zu spezifisch. Da sind die GPU-Geschichten schon weiter integriert.
hubersn, 02. 07. 2016, 17:06 Link
Die Lösung für die Abstraktion von ARMs Anti-Kompatibilitäts-Anwandlungen ist vermutlich LLVM. Zumindest auf der Anwendungsebene. RISC OS selbst - das wird spannend. Einige Teile sind ja schon nach C konvertiert werden (CDFSSoftSCSI, ADFS), aber es bleibt natürlich immens viel zu tun. Bis ARMv7 war das ja auch nicht wirklich ein Problem, da das OS ja sowieso stark auf die Hardware drumrum angepasst werden musste, da kam es auf ein paar Kompatibilitätsnacharbeiten auch nicht an.

Das größere Problem sind ja sowieso Anwendungen ohne Source-Code - das OS ändert sich, und so manche Annahme des Programmierers stellt sich nach ein paar Jahren als zu optimistisch heraus, bzw. Flüchtigkeitsfehler führen erst viel später zu Problemen. Instruktiv ist da, die Postings von Jon Abbott im ADFFS-Forum zu lesen. Die allermeisten Spiele aus den späten 80ern oder frühen 90ern sind wirklich nur durch pures Glück gelaufen, die Fehler fallen jetzt erst auf wenn man versucht die damalige Umgebung zu emulieren. Eine Lösung, die nur die CPU-Inkompatiblitäten im Auge hat, wird immer unvollständig sein bezüglich der geheiligten Rückwärtskompatibilität.
hubersn, 02. 07. 2016, 17:16 Link
RISC OS läuft auf dem Pi3 aber nicht aus NOOBS. Da wird es bei Nutzung auf dem Pi3 nichtmal angeboten. Es hilft nur das aktuelle Image selbst anpassen.

Der andere Kram ist mir zu hoch.

WorraCAD lief nie auf meinem RiscPC aber auf dem RPCEmu mit den 4.39 ROM.
Wollte es nur mal erwähnen.
Raik, 02. 07. 2016, 21:32 Link
MIPS war aber vermutlich auch nie wirklich dafür gedacht direkt per Assembler programmiert zu werden. Was irgendwie witzig ist, weil es ja jetzt anscheinend im "embedded" Bereich gut unterwegs ist, während sich ARM anfängt auf den Serverbereich zu stürzen.

Gibt es nicht auch ein paar sinnvoll anwendbare reverse engineering tools für Acorn / RISC OS ? Damit sollte doch eigentlich manches relativ gut zurück in das Hochsprachenlevel gerettet werden können.
Ob sowas dann sinnvoll ist, wer weiß.

Zum Thema RISC vs CISC noch: Bei Intel ist u.a. ja auch witzig (oder traurig), daß es dieses Rückwärtskompatibilitätslevel ja durchaus auf Prozessorebene hat. Unter dem x86 läuft ja letztlich ein RISC, der nach außen hin so tut, als sei er CISC. Wenn man so will, ist da eine zusätzliche Ebene eingezogen, die nur dazu dient, daß irgendwelche "Uralt-Software" von 1985 noch binär abspielbar ist.
Will man eigentlich in der Form schon aus ästhetischen Gründen nicht haben.
naitsabes, 03. 07. 2016, 13:23 Link
Die hohe Rückwärts-Kompatibilität von Intel ist wohl dem Abnehmermarkt geschuldet. Viele wollen das scheinbar so haben. Intel hat in der Zwischenzeit ja versucht, eine komplett neue, bessere, überdachtere und schlankere Prozessorarchitektur einzuführen, ist damit aber scheinbar ziemlich auf die Schnauze gefallen. Das Problem ist halt immer, dass die Leute eigentlich nichts Neues wollen. Das alte soll nur besser, schneller oder irgendwie so sein. Aber nicht viel anders. Denn sonst müssten die Leute ja selbst etwas dafür tun, mit dem jetzt plötzlich völlig anderen System wieder klarzukommen. Das wollen sie aber nicht. Die meisten Menschen wollen anscheinend möglichst wenig tun, lernen (und denken) müssen. Dabei aber gleichzeitig möglichst viel haben wollen.
Isip, 03. 07. 2016, 16:43 Link
@Isip: Das Thema Verständnis war auch mein Ansatzpunkt so einen Programmgenerator / Wizard selber schreiben zu wollen. Genau die fehlende Durchsichtigkeit der MFC hatte mich damals dazu veranlasst nachzuschauen, wie das ganze denn in C++ ohne allzuviele Kryptische Macros zu programmieren sei. Dadurch habe ich mich dann erstmal tief in die Softwarestruktur - Grundlagen eingearbeitet (was für E-Techniker sonst eher unüblich ist) und meine entsprechenden Testimplementierungen auf dem Risc-PC zusammengebaut bis sie liefen. Nur bei Templates und virtueller Überdeckung bin ich dann an die frühen Grenzen von C++ gestossen.

Aber lernen war eben genau der Ansatz! :-)

Gruß,

Uwe
Uwe, 04. 07. 2016, 09:04 Link
Grundüberlegung war, Dateien die die diversen Helferlein wie Toolbox (Fenster u.s.w.) und MenuEd, ResEd erstellen und Menue- und Sprite-Dateien zu nehmen und automatisch entsprechende Objekte innerhalb C++ anzulegen, die einen Zugriff auf diese Objekte erlauben. Dazu kommen dann Zugriffsmöglichkeiten für den WIMP-Umlauf und die Messages, sowie, falls benötigt, Objekte für Datei-Zugriff und auch 'Timer' die über die Reaktion auf Events hinaus Aktionen des Programms ermöglichen die 'im Hintergrund' ablaufen.

Damit hat man also die Aufgabe zunächt mal ein funktionsfähiges Grundgerüst anzulegen, dass dann je nach vorhandenen Objekten in der Toolbox mit zusätzlichen Programmobjekten in C++ ergänzt wird, die dann mit virtueller Überdeckung als Arbeitsmodule an dieses Grundgerüst angeflanscht werden und entsprechend die Messages aus dem Event-Loop weitergereicht bekommen - was dann irgendwann auch schön funktioniert hat.
Diese 'Arbeitsmodule' müssen dann für die grundsätzlichen Objekte aus der Toolbox erstellt werden - das habe ich nur noch für die Teile implementiert die ich dann auch für das damals aktuelle Projekt gebraucht habe. Sonst war leider eigentlich kein Interesse von irgendeiner Seite zu verspüren.
Zum Schluss werden die Module dann automatisch (an die vergebeben Namen angepasst) kopiert und zusammen mit einem Makefile in einer passenden Directorystruktur als Projekt angelegt.
Die Navigation im Quellcode wollte ich eigentlich über Menu und Folding Editor vereinfachen, dazu ist es dann aber nicht mer gekommen.

Na ja egal. Interessiert das jetzt jemanden? :-)

Schöne Grüße,

Uwe

Gruß,

Uwe
Uwe, 04. 07. 2016, 14:31 Link
Ich könnte mir vorstellen, daß das schon aufgrund der verwendeten Sprache schwierig wird, da jemand zu finden.

Und was ist eigentlich "virtuelle Überdeckung" ?
naitsabes, 05. 07. 2016, 12:13 Link
Warum sollte C++ untypisch sein? Gut, vielleicht für RISC OS. WIMPy schimpft mich zumindest immer wieder 'mal, ich sollte das lassen. BBC BASIC und Assembler wären viel besser, und C(++) alles andere für RISC OS geeignet. Damit mag er in mancher Hinsicht Recht haben, C(++) ist alles andere als überschaubar und durchdacht.

Natürlich interessiert mich das, kannste ja 'mal rüberwachsen / durchblicken lassen. Eventuell auch gerne über unsere Mailingliste, da kann man sowas wohl auch besser diskutieren. Soweit ich weiß, hast du dich da inzwischen auch schon angemeldet.

Solche Arbeiten sind freilich immer interessant. Aber wenn man nichts davon weiß (so wie ich bisher), kann man sich dafür halt leider auch nicht interessieren. Das hättest du mir also schon früher sagen müssen / können.

Ist wohl mindestens so interessant wie Markus Bootsequenz, die er sich selbst auf seinem Risc PC zusammengebastelt hat.

Ich kenne dich ja nicht und weiß eigentlich auch sonst nichts von dir (außer, dass du dich Uwe nennst). Anscheinend bist du (auch) E-Techniker. Das in Klammern, weil ich sowas zwar 'mal studiert habe, aber sonst nichts damit war. Heute muss ich zusehen, mit irgendwas mein Geld zu verdienen, damit ich wenigstens meine Miete für die 16 qm hier bezahlen kann.
Isip, 06. 07. 2016, 00:01 Link
Die Vorteile von Assembler sieht man sehr gut bei Impression, das offenbar in Assember geschrieben ist. Die Portierung für 32 Bit hat 2004 angefangen. Wäre das in C geschrieben worden hätte es vielleicht nur zwei Monate gebraucht. Zwei Monate um den einen oder anderen Bug der unter RISC OS 5 zu Tage getretten wäre zu beheben.

BASIC ist für einiges keine schlechte Wahl. Aber etwas langsam und es fehlen viele nütliche Features modernerer Sprachen. Zusätzlich ist BASIC für große Projekte nicht wirklich brauchbar.

C ist ist eigentlich sehr überschaubar. Der Kern kann nur recht wenig und kann Beispiel nicht Mal "Hallo Welt" ausgeben. Über die Bibliotheken kann man dann einiges an Möglichkeiten nach Bedarf hinzufügen. Zusätzlich sind diese Biblotheken auch thematisch geordnet und so kann man das benötigte recht schnell finden. Das macht es eigentlich recht übersichtlich. Andere Sprachen haben im Kern so viele Funktionen, die man sich nie merken kann. Was ein Problem bei C ist, ist die Geschichte mit den Zeigern. Da muss man aufpassen um sich nicht selber ein Bein zu stellen.

Bei C++ kommt die Objektorientierung hinzu, aber ich kenne mich mit C++ nicht aus und kenne OOP nur von anderen Sprachen. Aber damit kann man Teile des Programmes viel besser gegeneinander abschotten und damit Fehler im Prinzip vermindern. Zusätzlich sorgt OOP noch Mal für mehr übersicht, erhöht die Wiederverwendbarkeit und bietet einiges nütliches.
cms, 06. 07. 2016, 19:56 Link
Soweit ich das verstanden hatte, war C eigentlich ein "Abfallprodukt" bei der Entwicklung des Mehrfachbenutzer-Betriebssystems UNIX (Bell Laboratories, Ken Thompson und Dennis Ritchie) und damit freilich auch nie wirklich durchdacht. Es war halt ein Anfang, eine Idee, die sich dann allerdings sehr schnell selbständig gemacht, d. h. durchgesetzt hat. Vielleicht, weil es zu der damaligen Zeit nichts anderes gab. UNIX ist eigentlich voll mit solchem Zeugs, mit solchen Ideen, und das macht es wohl so einzigartig. In Verbindung mit Gnu (der Schaffung eines komplett freien Betriebssystems, das im Prinzip UNIX nachmacht, aber nicht UNIX ist - Gnu steht für Gnu not UNIX), haben diese Ideen wohl eine tragende Rolle bei der Entwicklung fast aller späteren Betriebssysteme erlangt.

Allerdings heißt das noch lange nicht, dass das der Weisheit letzter Schluss ist, und ich freue mich insbesondere über RISC OS, das zum Teil völlig andere Wege als die Unix- und Gnu-Welt gegangen ist und scheinbar einige völlig eigene oder auch andere Ideen umgesetzt und eingebracht hat. RISC OS ist für mich Unix / Gnu / Linux in einigen Punkten ziemlich weit voraus oder zumindest anders. Wo Unix unbequem für mich ist, ist RISC OS für mich oft bequemer.

Und ob es auch ausgerechnet C sein muss, weiß ich nicht. Vielleicht gäbe es heutzutage weitaus bessere Möglichkeiten, den (QUell)Code maschinenspracheunabhängiger zu machen. C ist ja inzwischen doch schon uralt und war ja nie wirklich durchdacht.
Isip, 07. 07. 2016, 01:06 Link
Ich kenne die ersten Versionen von C nicht, da war ich mit anderen Dingen beschäftigt. :-)

Aber C kann eigentlich nur das notwendige wie if, while, for, Zuweisungen, Grundrechenarten, Funktionen, Basis Typen wie int, real und char, Arrays, Unions usw. und halt auch die in meinen Augen große Schwachstelle mit den Zeigern. Da kann man nicht so viel falsch machen.

Auch wenn C die Mutter vieler anderen Programmiersprachen ist - das muss ja ein Grund haben -, so ist C etwas veraltet. C++, C#, Java, Go usw. sind da einfach weiter.

Der Sprung von C als Programmiersprache zu Unix zu Linux zu RISC OS ist interessant. BTW: Der GNU Kernel heißt Hurd und ist in ewiger Entwicklung steht. Der Linux Kernel "bedient" sich nur der Lizenz und Linux selbst den vielen Tools.

C ist halt früher die Programmiersprache gewesen und wird halt immer noch verwendet. Aber unter RISC OS gibt es halt auch nicht so viele Alternativen.
cms, 07. 07. 2016, 10:19 Link
Isip: "Vielleicht, weil es zu der damaligen Zeit nichts anderes gab."

Es gab eigentlich zu jeder Zeit seit den 60ern eine unüberschaubare Anzahl von Programmiersprachen. Warum gerade C so erfolgreich und langlebig wurde, ist eine interessante Frage. Das Tandem mit Unix hat sicher geholfen, weil dadurch jeder Unix-Anbieter quasi automatisch als Pflicht einen C-Compiler haben musste - alle andere Sprachen waren Kür. Und C ist halt sehr sehr einfach strukturiert und so maschinennah, dass ein guter Compiler auch hinreichend einfach zu schreiben war. Die Sprache selbst hat ja nix, die Standardbibliothek ist überschaubar und ist letztlich in weiten Teilen auch in C selbst implementierbar. C reduziert die Komplexität radikal, indem es diese radikal auf den Programmierer abwälzt.

Durch die Idee der offenen Sourcen (anders war Portabilität von Software ja kaum zu gewährleisten) wurde C auch zu einer sehr "sichtbaren" Programmiersprache. Viel verfügbarer Sourcecode ist eine gute Voraussetzung für die Verbreitung einer Sprache.

Amüsant bei der ganzen Programmiersprachendiskussion ist für mich die Stellung von C unter RISC OS gegenüber anderen Betriebssystemen. Während man anderswo nur ganz spezielle Teile (z.B. eine Bibliothek oder auch nur die Schnittstelle zu dieser, oder den Betriebssystemkern, oder zeitkritische Teile) in C schreibt, weil es viel zu low-level und leistungsschwach und umständlich und wenig wartbar und schwer portierbar ist, gilt C unter RISC OS als high-level und leistungsstark - eben weil hier oft noch mit BBC BASIC und/oder Assembler gearbeitet wird. Und dagegen herrschen unter C natürlich fast schon paradiesische Zustände. Problematisch unter RISC OS war natürlich auch immer, dass alternative Sprachen nur durch Drittanbieter verfügbar waren, so dass es auch gute Gründe gab, bei der einzigen Sprache zu bleiben, für die der Hersteller *den* Compiler gebaut hat.
hubersn, 07. 07. 2016, 16:19 Link
@Naitsabetes:

Bei C++ gibt es Vererbung:
Du Kannst also z.B. eine Klasse 'Nachrichtenempfaenger' schreiben, die von einem Programmteil der den Wimp-Poll ausführt mit WIMP-Nachrichten versorgt werden kann. Der Nachrichtenempfänger kann sich als 'Interssent' für die Nachrichten anmelden, die Ihn interessieren. Den Mechanismus kann man dann erstmal schön ausprobieren.
Jetzt willst Du in einem späteren Schritt genau diese Funktionalität zum Beispiel für das abspeichern von Daten Nutzen.
Anstatt die Funktionalität durch direkten Aufruf zu nutzen und damit wieder durchsteigen zu müssen wie das mit dem Anmelden u.s.w. geht, kannst Du eine neue Klasse anlegen, die die Funktionalität von der Empfänger-Klasse erbt. Die ganze Anmeldung und der Nachrichten-Fluss ist damit auch für die Neue Klasse erledigt.

Wenn Du Im Programm nun mehrere Klassen erstellt hast, werden diese während des Programmablaufes als 'Blaupause' für tatsächliche Klassen-Objekte genutzt.

Wenn Du jetzt eine Bibliothek schreibst, deren Nachrichtenverteiler noch gar nicht weiss was für Klassen-Objekte da kommen werden, die alles Nachrichten haben wollen, bist du erstmal im Dilemma wie du die Nachrichtenempfänger ansprichst. In C++ spricht man dann einfach das neue Objekt so an, als wäre es vom Basis-Typ 'Nachrichtenempfaenger', was diese Funktionalität ja von der Basis-Klasse geerbt hat. Diese spezielle Funktion ('Methode' im C++ Sprachgebrauch) von der Basisroutine soll dann auch im neuen Klassenobjekt genutzt werden.

Wenn mit den empfangenen Daten aber etwas gemacht werden soll, muss das Ganze natürlich abgearbeitet werden - und das unterscheidet sich dann zwischen der Basisklasse (Nachricht empfangen) und dem neuen Objekt (Nachricht zum Abspeichern empfangen und Datei abspeichern)

Also schreibt man in der neuen Klasse diese Funktion (Methode)so, dass sie dem Interface der Basis-Methode entspricht und deklariert sie als 'virtuell'. Damit überdeckt sie dann die (größtenteils leere) Funktion (Methode) aus der Basisklasse. Den Inhalt der Funktion (Methode) schreibt man so, das sie tut was sie soll: den Speicherbefehl dekodieren (Filename, Speicherort) und dann die eigentliche Save-Funktionalität aufrufen.

In der Zukunft werden dann alle Nachrichten von der Nachrichten-Verteil-Zentrale an ein Objekt geschickt, das zum Zeitpunkt der Implementierung der Zentrale noch gar nicht geplant oder bekannt war - es könnten also zum Beispiel auch unterschiedliche Leute zu unterschiedlichen Zeiten diese Programmteile schreiben oder sogar Zompilieren (bleiben wir im deutschen :-) - was für eine Bibliothek sehr sinnvoll ist.

Jau. Geht vielleicht was weit, aber ist, denke ich eine schöne Anschauung und lässt sich damit auch sehr elegant umsetzen.

Schöne Grüße,

Uwe

P.S.: Das ganze ginge (auch in C) 'einfacher', aber nicht Typsicher. Und wäre damit bei der (weiter-) Entwicklung fehleranfällig und der Zompiler hilft einem nicht bei der Fehlersuche wenn das Programm irgendwann abstürzt.
Uwe, 08. 07. 2016, 09:24 Link
@Isip: Du hast die Initialen A.A. ist da richtig? Ja, ich bin E-techniker mit viel Informatik-Anteil, weil mich das immer schon interessiert hat. Persönlich kenne ich auf jeden Fall cms.
Ich habe zwar selten Zeit 'privat' zu programmieren, aber wenn ich was programmiere dann versuche ich immer nah am C++ Standard mit den Standard-Bibliotheken zu programmieren - nur Programmteile die direkt Riscos, Android, Windoof oder Linux-Abhängig sind weichen dann davon ab.
Aus obigem Grund nutze ich dann aber auch möglichst aktuelle Compiler, da sie in der Unterstützung der Standards am weitesten sind. Norcroft gehört meines Wissens immernoch nicht dazu.
Ich finde das Programmierprojekt hier auf der Arcsite sehr schön und würde dann versuchen dazu weitere Artikel zu ergänzen - ist vielleicht für die 'Community' am besten Nachzuvollziehen - kann man dann bei der Erstellung und nacher mit der Mailingliste ergänzen wenn jemand Fragen hat.

Als ersten Artikel würde ich mir aber einen Aufsetzartikel für den neuesten gcc - mit möglichst einfacher installationsanleitung wünschen. Hat den jemand aktuell z.B. auf dem Raspi am laufen und in welcher Version?

Schöne Grüße,

Uwe
uwe, 08. 07. 2016, 10:06 Link
OK. Danke für die Erklärung.

Wahrscheinlich muß man das einfach mal selbst ausprobieren, damit man "in real" sieht, wie es funktioniert.
Ich fand das irgendwie immer schon (rein theoretisch und damals(TM) (1995?) in den Büchern oft mit dem Beispiel: Punkt - Linie - Rechteck - Fenster - Oberfläche und alles mit Vererbung) ein wenig zuviel Aufwand an der falschen Stelle, aber das mag daran liegen, daß für meine kleinen privaten Programmbasteleien sowas einfach Overkill ist, wogegen es sicherlich in wirklich großen Projekten durchaus seine Berechtigung haben mag.

Die Idee mit dem Durchreichen von Messages und Events, finde ich aber durchaus sehr witzig.
Allerdings ist das Problem an solchen Konstrukten anscheinend oft, daß sie zwar gut gedacht sind, aber dann nicht generell verwendet werden.
Ich weiß nicht wirklich woran das liegt. Wahrscheinlich hat es was mit "eingeengt werden" zu tun und das mögen Programmierer nicht so gern (was möglicherweise auch ein weiterer Grund für C's Erfolg ist). Bzw. sie akzeptieren es nur auf Betriebssystemebene oder vielleicht noch bei Bibliotheken, von denen sie sich wirklich was versprechen (so ala 3D Engine (Unity) oder MatheLibs), weshalb so Sachen wie DrWimp, ABCLib, diese Archimedes GamesLibrary (wo Stasis dazugehörte) oder auch nur ResFind irgendwie nicht so wirklich allgemeine Standards werden.
naitsabes, 08. 07. 2016, 11:33 Link
Komisch, ich hatte irgendwie abgespeichert das der Artikel #1 mit dem Norcroft umgesetzt ist. War aber Unfug :-)
Ich sehe schon, ich muss dann wohl mal den gcc einfach wieder installieren - Ich hatte den ersten Artikel auch eher als Hinweisgeber, nicht als 'Anleitung' verstanden. Aber vielleicht ist es ja doch so einfach. Ich werd's also mal im Urlaub ausprobieren denke ich.

Danke dafür, und entschuldigt meine vorübergehende Ignoranz :-)

Dann werde ich wohl mal die alten sourcen wieder ausgraben und wieder den Geist da durch quälen müssen :-)

Schöne Grüße,

Uwe
uwe, 08. 07. 2016, 11:35 Link
@naitsabetes: Ja, die Akzeptanz is da oft ein Problem. Aber da muss man sich als Autor der Bibliotheken eben auch an die eigene Nase fassen: entweder eine Bibliothek gibt einen direkten Vorteil wenn man sie nutzt, oder sie wird ignoriert.

Da hilft dann
1) eine gute Dokumentation
2) eine einfache Benutzung (Beispiele!)
3) ein weitreichender Support von Grundfunktionen, aber effektiv im Ablauf.
4) ein fertiges Grundgerüst um Einstiegshemmnisse gering zu halten (evtl. automatisiert/mit Wizard)
5) eine automatische Programmerstellung von wiederkehrenden Objekten auf Grundlage von ResEd, Toolbox, MenuEd, Sprites und eventuellen anderen Tools.

Meinen Ansatz für Punkt 4 und 5 hatte ich damals !Sourceror genannt :-). Er sollte so eine Art Multiple-Choice Programmersteller werden.
Heute würde ich das wohl erstmal nur auf Basis von Dateien aufbauen, die das zu erstellende Projekt beschreiben und alle in einem Unterverzeichnis (oder Archiv) im neu zu erstellenden Programm !NeuesProjektXxx liegen. Die werden dann alle untersucht und soweit wie nötig mit Textdateien angefüttert die erlauben ein Grundgerüst zu bauen. Die Inhalte, die der User des Programmes dann hinzufügt könnte man später eventuell noch weiterverfolgen um im Nachinein auch den Generator nochmal laufen lassen zu können (um z.B. ein Bild oder Fenster hinzuzufügen) ohne das alles wieder weg ist.

Die Krux sind aber erstmal Punkte 1-3 die am Anfang natürlich fehlen - jeder der mit daran arbeitet hat also bis auf 'Lernen' keinen Vorteil.
Vielleicht reich der Vorteil aber dem ein- oder anderen :-)

schöne Grüße,

Uwe
uwe, 08. 07. 2016, 12:06 Link
Die Installation von GCC ist mit PackMan schnell erledigt. Den Rest haben Alexander und ich an bekannter Stelle ja mal angerissen.
cms, 08. 07. 2016, 18:45 Link
Ja, ich habe die Initialen A. A. Mein Nachname ist südtirolischer Herkunft (Kaltern) und ja kein Geheimnis.

Java finde ich als Programmiersprache noch ganz interessant.

Im Prinzip geht es immer um ganze, komplexe Datenblöcke, wenn ich das richtig verstanden habe. Das ist etwas, was Assembler so in der Art und Weise wohl einfach nicht kann. Oder wenigstens nicht so einfach. Wenn man sich da um ein Byte, um eine Speicherstelle oder Adresse vertut, hat man schon einen Fehler. Damit sowas nicht passiert, gibt es in anderen Programmiersprachen (C, C++) entsprechende Konstruktionen bzw. Kontrollmechanismen.

Fenster etwa weisen viele Eigenschaften auf und erfordern damit sehr viele Parameter zur Beschreibung dieser Eigenschaften. Diese Eigenschaften werden in den schon erwähnten Datenblöcken beschrieben. Das sind aneinanderhängende Speicherstellen oder -adressen. Diese werden in den Programmers Reference Manuals von Acorn absolut transparent beschrieben, indem jedes einzelne Bit eines solchen Datenblocks mit ihrer Bedeutung genau aufgezählt wird. Die Datenblöcke müssen natürlich immer gleich aufgebaut sein, damit eine Funktion bzw. Betriebssystemroutine (SWI) sie verarbeiten kann. Die Struktur ist damit von vornherein festgelegt.

In C gibt es nun in einfachster Form die Datentypen (Integer, Char usw.), welche verschiedene Eigenschaften (Größe d. h. Anzahl der erforderlichen Bytes, Typ usw.) eines Datenblocks beschreiben. Die Datentypen dienen damit auch zur Berechnung und zur Verwaltung des erforderlichen Speichers bei der Übersetzung in ein lauffähiges Programm. In Assembler / Maschinensprache müsste man das u. U. selbst machen. D. h. den Speicher selbst einteilen oder verwalten.

Der Compiler verwendet diese Datentypen nun auch zur Überprüfung, zum Beispiel ob Datentyp und Funktionsaufruf zusammenpassen. Auf diese Weise lassen sich Fehler vermeiden, falls man sich verprogrammiert haben sollte (Abruf falscher Adressen und damit falscher Inhalte). Aber auch das Überschreiben der Inhalte von falschen Adressen wird damit in gewisser Art verhindert.

Für ganze Datenblöcke verwendet man in C die sogenannten Strukturen, welche wiederum aus einzelnen Datentypen bestehen (können). Hier aber versagen zum Teil die eben schon erwähnten Kontrollmechanismen, weil C nie wirklich völlig durchdacht war. Um dem abzuhelfen, wurden später C++ usw. erfunden (wenn ich das alles Richtig verstanden habe). Dort gibt es dann auch die Möglichkeit, Teile von Eigenschaften von Strukturen (also die darin enthaltenen Datentypen) beim Erzeugen einer neuen Struktur mit zu übernehmen (also zu kopieren, was aber abstrakt und mir unverständlich mit "vererben" beschrieben wird). Soweit bin ich da aber noch nicht eingestiegen, dass ich das alles richtig verstanden habe. Mir persönlich reicht im Augenblick C.

Ich persönlich finde es schade, dass viele C-Bücher zum Beispiel gar nicht erklären, um was es bei Datentypen geht, was Datentypen oder wofür sie gedacht / gemacht sind (in der Form wie eben beschrieben). Da werden dann einfach Datentypen eingeführt, aufgezählt, und der geneigte Leser versteht wohl überhaupt nicht, wofür die eigentlich gut sind und was man sich darunter vorstellen muss. Warum es die überhaupt gibt. Und das war in der Informatik-Vorlesung auf unserer FH leider genau das selbe. Sowas baut dann doch null Verständnis auf. Denn so schwer ist das eigentlich alles nicht.

Erst, als ich anfing, mich mit der ganzen WIMP-Programmierung unter RISC OS und C in Verbindung mit OSlib zu beschäftigen, bemerkte ich solche Zusammenhänge, weil da auf Grund der Programmers Reference Manuals plötzlich eine Transparenz / Durchsichtigkeit hergestellt worden war, die ich so in ihrer Art und Weise noch nie irgendwo anders fand.

Auf mehr will ich jetzt an dieser Stelle nicht eingehen.
Isip, 08. 07. 2016, 23:32 Link
Das stimmt sicher, daß da viel "implizites" Wissen oft vorausgesetzt wird.

Lustig sind auch die launigen Tabellen zur Operatorenhierarchie - das findet sich auch oft relativ unkommentiert in Einsteigerbüchern und wird vermutlich erstmal als unwichtig / unverständlich überlesen, auch wenn es möglicherweise die wichtigste Tabelle im ganzen Buch ist.
An solchen Stellen war die Computerliteratur (vor allem die "for Beginners") schonmal didaktisch weiter.

Trotzdem muß man sagen, daß es irgendwie auch eine hübsche Sprache ist, was man zum Beispiel dann erkennt, wenn man sich mal alte Sources für Workstations anguckt, die so durchs Usenet geisterten. (click)
naitsabes, 09. 07. 2016, 12:14 Link
C ist aber auch eine lausige Sprache, um die wunderbare Welt der Datentypen und damit letztlich die Errungenschaften des "Strong Typing" zu erklären.

Ich kenne verschiedene Varianten von "Einführung in die Programmierung" - BASIC, Pascal, Modula-2, Scheme, C, Java, Ada. Alles schwierig. In Ada ist es noch am einfachsten, wenn man sich von der imperativen Seite denn nähern will (und da gibt es gute Gründe dagegen), weil beim "programming in the small" Ada einfach alles sehr elegant abdeckt. Man hat die Unterscheidung von numerischen und modularen Typen, man hat abgeleitete Typen auf Basisdatentypenebene, man hat wunderschöne Enums, man hat representation clauses für die Bitfrickelei, man hat unterschiedliche String-Typen, elegante Integration verschiedener Zahlensysteme, Run-Time-Overflow-Checking, sowohl Floating Point als auch Fixed Point...

Aber dann hat man die wunderbare Welt von Ada erklärt, und kurze Zeit später wird man mit der hässlichen Realität von C oder Java konfrontiert. Hat es dann wirklich was genützt? Ist der alte Ansatz, Hochsprachen zu verwenden die trotzdem noch deutliche Rückschlüsse auf die Maschinerie darunter zulassen, überhaupt noch sinnvoll? Will das der Python-/Ruby-/Scala-/Kotlin-Entwickler von heute überhaupt noch wissen, und muss er das wissen um gute Software zu entwickeln?
hubersn, 09. 07. 2016, 14:17 Link
Keine Ahnung, aber mir hilft es ungemein, den C-Code besser zu verstehen. Vielleicht ist das aber auch der falsche Vergleich. Mir ging es hier in erster Linie um C, nicht um die anderen Programmiersprachen. Auf dem C64 konnte ich mit Hilfe von BASIC auch jede Menge Zeugs zusammenfrickeln, ohne wirklich zu verstehen, was so drunter läuft. Nur mit C funktionierte das bisher so halt einfach irgendwie nicht wirklich.
Isip, 09. 07. 2016, 18:32 Link
Was ist c++?:
Ich denke das versteht man nur wirklich wenn man damit herumspielt.
Also am einfachsten ist es eigentlich zu 'leben' wenn man sich vorstellt, jede Klasse ist die Beschreibung einer Rolle z.B. In einem Theaterstück. Wenn man das Stück aufführen will, werden Instanzen für die Rollen angelegt (ein Schauspieler füllt die Rolle mit Leben) dann haben wir dann ein Klassenobjekt.
Danach läuft das Stück ab, indem sich die Darsteller unterhalten, Informationen Austauschen, manche kennen sich, andere müssen miteinander bekannt gemacht werden (Adresse austauschen), U.s.w.
Bei diesem Bild ist das was in C eine Struct war,(was der Charakter zu einem bestimmten Zeitpunkt weiß), mit dem Wesen der Rolle des Schauspielers verknüpft zu einer Klasse.
Dadurch ergeben sich schnell interessante Ansichten während der Programmierung: man stellt sich vor man soll eine Rolle ausfüllen und überlegt was man wissen muß und wen man braucht. Da das Un beide Richtungen geht müssen andere dann auch nur wissen wen sie wie fragen müssen, aber nicht unbedingt wie der Andere das macht.

Ich habe mal den 1. Artikel für C++ nachvollzogen und cms die Ergänzungen direkt mal geschickt. Keine Ahnung wie man das sinnvoll hinzufügen kann.. :-)

Gruß,
Uwe
Uwe, 10. 07. 2016, 17:07 Link
Kennst Du eigentlich !AppBasic ? (Click)
naitsabes, 12. 07. 2016, 11:48 Link
Könntest du mir die Ergänzungen zu C++ bitte auch schicken? Danke!
Isip, 13. 07. 2016, 09:09 Link
Mir bitte auch, ich habe bislang noch nichts bekommen. Nimm carlos2007 usw. als Adresse.
cms, 13. 07. 2016, 09:26 Link
Das !AppBasic sieht wirklich leistungsfähig aus.

@Uwe! Ich möchte gerne noch deine (richtigen) Ausführungen zu C++ ergänzen.

Bei der OOP gilt der Spruch "Tell, don't ask!". Das ist schon etwas anders als die procedurale Programmierung (dort fragt man selber Werte ab, um zu entscheiden, was man wie machen soll).

Durch "Tell, don't ask!" ist die OO-Anwendung skalierbar. Als Coder muss ich nicht nachschauen, welche spezielle Rolle der Schauspieler (Objekt) hat. Weil wenn ich erst wissen muss, welche Rollen es gibt, bin ich ja als Coder auf einen nur mir bekannten Satz von Rollen eingeschränkt (nicht skalierbar). Aber wenn ich nur den Basis-Typ kennen brauche (Schauspieler), wird der spezielle Schauspieler (vererbte Typ) selbst wissen, _wie_ er spielen muss. Ich muss ihm nur sagen, _was_ er machen soll.

Dadurch wird der Anwendungs-Code viel flexibler. Und ich kann mir z.B. switch-case-Konstrukte sparen.

Natürlich kommt im erzeugten Maschinencode nur prozeduraler Code raus. Der Compiler der OO-Sprache nimmt mir die Arbeit ab, die ich mit Basic/C/ASM umständlich selber nachbauen müsste (und könnte).
Aber die Frage ist: warum soll ich alles umständlich selber nachbauen, was schon die OO-Sprache mitbring? Ich will ja eine Anwendung und keine Technik programmieren. Ich will eine fachliche Lösung für ein fachliches Problem entwickeln!

Ich programmiere ja auch nicht das WIMP von RISC OS jedes Mal selber neu, weil ich ein Super-Coder bin. Nein, RISC OS bietet mir die Technik an. Und ich nutze diese Technik um schneller eine Lösung zu entwickeln.

RISC OS hat übrigens auch den Skalierungsgedanken z.B. bei Filesystemen und Filer. Es ist möglich mit dem Filer sowohl auf rohe Verzeichnisse zu zugreifen, als auch auf z.B. Zip-Archive. Und sobald weitere Typen dazu kommen, skaliert das System.

Mit einer OO-Sprache wird aber diese Skalierbarkeit für den Entwickler viel einfacher umzusetzen. Weil der Gedanke in der Sprache und Compiler enthalten ist.
artchi, 14. 07. 2016, 11:52 Link
@cms am Ende des Artikels ist ein Kommentarfeld. Da habe ich die Ergänzungen zu c++ eingetragen. Wenn das verlorengegangen ist muss ich es nochmal neu schreiben. Befinde mich gerade in einer Gegend mit schlechter Netzabdeckung, habe aber den Rechner mit. Mal sehen wann es passt.
Schöne Grüße,

Uwe
Uwe, 16. 07. 2016, 18:47 Link
Da muss dann in der Firewall hängen geblieben sein. Da muss dann aber eine Meldung erschienen sein - oder war die Verbindung schon so schlecht ... Auch ich habe momentan eine schlechte Verbindung. Wann hast Du das abgeschickt? 10. 7.?
cms, 16. 07. 2016, 18:57 Link
8.7.
Uwe, 16. 07. 2016, 19:05 Link
@cms -ist nochmal per mail an Dich, ansonsten schmeiss mal die Einträge hier wieder raus, wenn möglich :-) Danke.
@Isip schau mal in Deinen 'postkasten'
@artchi Danke für die Ergänzungen, an manchen Stellen kann ich aber nicht ganz folgen ;-) Aber wenn wir ein paar Beispiele haben wird es vielleicht klarer.
Uwe, 16. 07. 2016, 22:01 Link
Programmierergeschwafel... wer soll das verstehen? ;-)

Ich durfte/darf die letzte Version von ffmpeg probieren. "Tut gut". Als alpha nicht "released", funktioniert das, was ich bekommen habe, sehr gut!
Christopher ist beim Portieren ein Fehler unterlaufen...;-) FFMPEG sollte auf den Neuen nur mit "ae off" funktionieren... tut auch mit "on" problemlos... keine Lust weiter zu suchen... allet jut.
Raik, 18. 07. 2016, 00:23 Link
Hast ja recht, ich verstehe von dem ganzen Theater hier auch nicht wirklich viel. Zumindest tue ich mich da immer noch sehr schwer.

Schön ist, dass sich immer mehr Leute in unserem E-Mail-Verteiler eintragen. Da sind inzwischen schon mehr als 20 Leute drin. Und vor einigen Jahren erst hatte ich noch geglaubt, ich wäre der letzte RISC-OS-Anwender Deutschlands...
Isip, 18. 07. 2016, 09:10 Link
Das ist auch schwer nachvollziehbar wenn das, schon recht seltsame, Erklärungsmodell "Vererbung" plötzlich mit dem eines "Schauspielers" erklärt wird. Wobei schon richtig war, was da so stand.

Nu ja, ist aber möglicherweise sowieso vorbei mit ARM, respektive genuiner britischer Rechentechnik ... (click) - ich hätte ja eigentlich auf Chinesen getippt oder evtl. Apple. So it goes.
naitsabes, 18. 07. 2016, 13:06 Link
Oh, mein BlackBerry ;-)
Übernahme heißt ja noch nicht "weg vom Fenster".
Ich für meinen Teil habe genug Boards. Das recht bis zum Lebensende ;-)
Raik, 18. 07. 2016, 13:21 Link
... aber es ist schon interessant, wie man Schulden von über 100 Milliarden Dollar den Kaufpreis von fast 25 Milliarden Dollar "auf Pump" finanzieren kann...
Raik, 18. 07. 2016, 14:20 Link
Unter anderem deshalb fand ich die Nachricht nicht gerade beruhigend. Aber in Anbetracht dieser Zahlen ist das halt schon ganz große "Kunst".
naitsabes, 18. 07. 2016, 14:32 Link
Ist das jetzt der Anfang für die Einkaufstouren auf der Insel?
cms, 18. 07. 2016, 19:20 Link
25 Mrd. US$ zu finanzieren um was gescheites zu kaufen ist selten das Problem - das Problem vieler Firmen, die dann so etwas nicht finanzieren können ist oft, dass sie irgendeinen Müll damit kaufen wollen...

Beruhigend an der Nachricht fand ich, dass es eben nicht Apple (oder Samsung oder Intel oder sonstwer aus der Branche) ist, sondern ein "neutraler" Käufer. Die haben höchstwahrscheinlich nicht die Absicht, das Geschäftsmodell von ARM umzukrempeln, und komplizierte Regulierungen sind auch nicht notwendig.

Es wundert mich aber, dass es eine japanische Firma ist. Der Yen hat gegenüber dem Pfund jetzt nicht soooo viel gutgemacht. Vielleicht 10% seit der Brexit-Entscheidung.
hubersn, 18. 07. 2016, 19:46 Link
Warum sperrt mich ArcSite aus, wenn ich versuche mit Pale Moon als Browser zu schauen versuche?
Raik, 21. 07. 2016, 16:34 Link
ArcSite error 403...
Raik, 21. 07. 2016, 16:37 Link
Hallo Raik,

das sollte jetzt mit PaleMoon funktionieren. Wenn nicht bitte direkt eine kurze Nachricht an mich.
cms, 24. 07. 2016, 10:36 Link
Läuft. Super, danke.
Raik, 24. 07. 2016, 13:07 Link
Ganz kurz eine Frage zur Kommandozeile: es gab mal ein Tool nach dessen Start man durch 'PfeilHoch' das letzte Kommando bekam... Ich kann mich aber beim besten Willen nicht erinnern wie das tool hiess oder wo man es findet. Kann mir da mal gerade jemand 'über die Straße helfen'? Danke :-)

Ich denke normalerweise nennt man sowas 'Command Line History' tool.
Gruß,

Uwe
uwe, 25. 07. 2016, 13:56 Link
Ok, habs gefunden. heisst LineEditor und ist ein Modul. die Version die ich gefunden habe (click) ist von 2003 und läuft unter rpcemu..
uwe, 25. 07. 2016, 14:01 Link
Hallo,

nachdem ich eine Weile nichts mit RISCOS gemacht habe, bin ich übder den Micro One gestolpert ... Ich habe ne Schwäche für Homecomputer-Designs ;-) Ich habe noch ein Raspberry Modell B "rumfliegen", aber da hat sich ja ein bisschen was getan. Läuft RISCOS auf dem Raspberry PI 3 ... und merkt man einen Unterschied zu den Vorgänger-Modellen?
Bastian, 27. 07. 2016, 21:23 Link
Ja.
Isip, 28. 07. 2016, 07:02 Link
Ja läuft auf dem Pi3 aber die Unterschiede zu den Vorgängermodellen ist aus meiner Sicht gering.
Hängt aber davon ab, was Du tun möchtest.
Raik, 28. 07. 2016, 09:08 Link
Den 3 habe ich nicht. Aber wenn Du etwas auf der Ramdisk machen möchtest (also mit Memphis) kannst Du sie schon beim Raspberry2 recht groß machen - also z.B. zum Compilieren von größeren Projekten, was dann je nach Anwendungsfall einen wesentlichen Geschwindigkeitsvorteil zur Verwendung der SD-Karte oder einer externen USB-Platte bringt.
Ansonsten habe ich in der Anwendung keinen Unterschied zum Raspberry 1B festgestellt, da eh nur ein Kern benutzt wird. Das gilt im Prinzip genauso für den Raspberry 3. Also Wenn Du mit größeren Dateien hantierst kauf Dir halt nen 3'er, sonst ist das unnötig.

Spannend wird's halt wenn Du im BASIC-Assembler mal einen weiteren Kern antesten möchtest :-) Also zum Beispiel um damit einen alternativen Filer zu schreiben, der vom normalen Filer nur noch gefüttert wird - mit der Rate in der neue Kerne bei den Prozessoren hinzukommen kann man die ja eigentlich als feste Ressource verplanen - wenn was neues kommt gibt's eh genug Kerne dafür ;-)

Schöne Grüße,

Uwe
Uwe, 28. 07. 2016, 10:38 Link
Im Moment würde ich vom RPi 3 (für RISC OS-Nutzung) noch abraten, die SWP-Krise ist noch lange nicht überstanden, und der Performancevorsprung vor dem RPi 2 ist jetzt nicht sooooo immens - und die anderen neuen Dinge wie Bluetooth und WLAN kann man unter RISC OS sowieso nicht nutzen.

Von einem 1er Modell hingegen würde ich definitiv abraten, der 2er ist wirklich sehr viel schneller. Es sei denn, man hat Spezialanwendungen (ADFFS fällt mir da spontan ein), die auf ARMv5 angewiesen sind.
hubersn, 28. 07. 2016, 12:00 Link
Kann man die Zusatzkerne tatsächlich ansprechen ? Vom Basic Assembler aus ?
naitsabes, 28. 07. 2016, 13:18 Link
Na ja, was hindert Dich daran in einen priveligierten Prozessormodus zu wechseln und dann beliebig herumzuprokeln? Ich habe damals mit Basic Assembler Module geschrieben die dann den FIQ (damals noch für die Floppys benutzt) umgebogen haben, um über Interrupt eine selbstgebaute Soundkarte auszulesen oder meine Fräse zu steuern. Ich schätze mal wenn man die Änderungen für 32-Bit berücksichtigt sollte das dann auf jeden Fall gehen. (Das Floppy sollte man dann halt erstmal nicht betreiben :-), aber ich hatte schon eine Festplatte!! Yeah!).
Die neuerliche Zero-Page Schützerei dürfte den direkten Zugriff ohne ein Modul zu schreiben allerdings erschweren - habe mich damit aber noch nicht wirklich befasst.

Viel Spaß,

Uwe
Uwe, 29. 07. 2016, 15:03 Link
Naja, nachdem Assembler eine direkte Abbildung von Maschinensprache sein soll, sollte sich damit eigentlich alles irgendwie anstellen lassen. Zumindest solange der Assembler auch den Befehlssatz vollständig unterstützt. Genau hier habe ich mit C aber Probleme. Damit Module zu schreiben ist zum Beispiel gar nicht so einfach bzw. ohne spezielle Erweiterungen anscheinend gar nicht möglich. Zumindest weiß ich bis heute nicht, wie es geht. Und entsprechende Nachfragerei hat auch nichts zutage befördert. Dem widerspricht aber, dass das alte Security-Modul von rComp mit einem C-Compiler kompiliert worden ist. Leider steige ich da noch immer nicht wirklich durch. Sonst könnte man ja schlicht mal ein neues Modul machen.

Wäre interessant, mehr darüber zu erfahren, wie man denn nun unter RISC OS bzw. vom BBC-BASIC aus die verschiedenen Rechnerkerne ansprechen könnte und wie das generell funktioniert. Gibt es schon dementsprechende Artikel darüber? Sowas würde wohl dem Zeitgeist der 80iger und 90iger Jahre entsprechen, als man in den Zeitschriften noch über wirklich tolle Sachen geschrieben hat. Wenn ich mir die heutigen Hefte zum Beispiel ansehe - wie das RPI-Geek - frage ich mich ernsthaft, was das sein soll. Ich kann damit fast gar nichts mehr anfangen. Um recht viel mehr als um irgendwelche Skripte schreiben oder Software für irgendwelches stupide Zeugs anpassen geht es da doch eigentlich gar nicht mehr. Das Kielwasser fehlt dabei heute total. Man lernt einfach nicht mehr wirklich was.
Isip, 29. 07. 2016, 19:29 Link
Ach ja, und ich liebte RISC OS immer dafür, dass es ausgerechnet so offen ist, keinen Speicherschutz und keine abgesperrten Bereiche wie Windows etc. hat. Genau das nämlich hat das Lernen, Erforschen und Verstehen des Systems und der darauf laufenden Software für mich viel einfacher gemacht. Und das Scheißteil ist nicht so kompliziert. Und trotzdem - oder ausgerechnet deshalb - so verdammt schnell und produktiv (d. h. die Oberfläche).
Isip, 29. 07. 2016, 19:33 Link
Es wäre interessant zu wissen, woher man denn nun erfahren kann, wie der RPI und seine Kernel anzusprechen / zu nutzen sind. Meinen 2 RPIs lag - im Gegensatz zu meinem früheren Commodore 64 - nie ein Handbuch oder sonst irgendeine Dokumentation (mit Ausnahme eines Faltblattes) bei. Keine Ahnung, was man damit soll. Wenn man jetzt zum Beispiel nicht weiß, dass RISC OS darauf läuft - Pech gehabt. Deshalb begrüße ich ja auch solche Komplettpakete mit Gehäuse, Netzteil und vorinstalliertem Betriebssystem, wie es wie ELV es zum Beispiel anbietet. Das Gehäuse anno für sich sieht übrigens recht schick aus. Leider hatte ich da schon meine ersten beiden RPIs. Und mehr brauche ich eigentlich nicht.
Isip, 30. 07. 2016, 07:35 Link
@Uwe
Ein ROM kann man Recht einfach von dem zpp Gedöhns befreien, wenn man selbst kompiliert. Sind nur zwei Zeilen zu ändern. Um die Classic Pandora und das alte Beagleboard auf 800MHz anzuheben gar nur eine.
Informationen sind nicht wirklich zu bekommen.
Bei ROOL ist der zweite Kern gerade Thema.
Ansonsten hilft nur ein "guter Draht" zu den Programmierern.
Raik, 30. 07. 2016, 09:32 Link
@Isip & @Raik
Ich hatte damals irgendeinen Artikel über 'Module Programmieren in Basic-Assembler' in die Finger bekommen, das war Ende der Achtziger der Start meiner Modul- Frickeleien.
In den Supervisor-Mode kommt man, soweit ich mich erinnere, nur innerhalb eines Moduls, von daher ist das schon die notwendige Grundlage. Ich würde mal annehmen, dass damit auch der Zero-Page-Protection Mode 'Überschritten' wird - von daher sollte das gehen.

Bisher habe ich allerdings noch nicht versucht meinen alten Quellcode auf 32 Bit umzustellen, weil der Raspi natürlich auch nicht das Podule enthält, für das ich die Module damals geschrieben hatte. Könnte man aber auch mal probieren :-)..

Ansonsten wäre vermutlich das Module von 'Tank' der richtige Startpunkt um zu sehen, wie man Module heute selber schreibt, da damit die IO-Leitungen angesprochen werden, und sonst NIX. Das Modul lässt sich aber glaube ich nur mit dem Norcroft einfach so übersetzen..

Also alles nicht sooo einfach und im Zweifelsfalle mit Kosten für den Compiler verbunden..

Gruß,

Uwe
Uwe, 01. 08. 2016, 10:19 Link
Hat jemand vielleicht !Omni und !OmniSetup v2.04 oder kennt eine Bezugsquelle? Anscheinend war es Bestandteil der Acorn Browse CD, angeblich auch auf der Acorn Java CD. Hintergrund ist, daß spätere Versionen nicht für RO 3.11 geeignet sind und ich gerade einen neuen Versuch starte über FTP hinauszugehen, um mit meiner NAS zu kommunizieren.
Patric, 01. 08. 2016, 22:34 Link
Letzteres glaube ich eher nicht. Eher eine Frage der Bibliotheken und "gewusst wie".
Willi hat mir für ein ursprünglich mit GCC erzeugtes Module ein Makefile geschickt, dann könnte ich auch Norcroft nutzen. Ich habe aber keinen Plan was er genau getan hat ;-)
Raik, 01. 08. 2016, 22:59 Link
@patric Wenn Du es heute noch brauchst, kannst Du mal bei (click) vorbeischauen. Da ist es dabei. Ansonsten, wenn eine Adresse/Website mitgeteilt wird, kann ich es schicken (kommt dann aber auch nur als Kopie von dem Link, Hauptvorteil wäre dann also primär die kleinere Downloadgröße).
naitsabes, 01. 08. 2016, 23:46 Link
@naitsabes

Danke, hat sehr geholfen, was das Auffinden betrifft! Den Mist auf dem einzigen Rechner mit optischem Laufwerk zu brennen, auf den Server zu kopieren und dann via FTP auf den Archie zu schaufeln, dauerte schon etwas länger.
Wunderbarerweise lese ich jetzt, daß ich nicht Omni brauche sondern "LanManFS 2.38"...
Das würde auch erklären, warum ich bisher genausowenig Kontakt mit Omni bekomme wie bisher schon mit LM98.
Kann sein ich bin jetzt einfach nur zu müde.
patric, 02. 08. 2016, 01:22 Link
Soo, habe mal ein bißchen mit dem gcc unter riscos herumgespielt, ein paar kleine Unterschiede zum PC habe ich bereits festgestellt - aber ich muss mal sehen welche Sprachteile der g++ für den archie unterstützt.

Libraries werden für QT, (was ich derzeit täglich nutze) etwas anders angemeldet, da muss ich mal weiter einsteigen für Riscos, und bei manchen Headerdateien ist der gcc etwas strikter.
Beispiel:
//filename ist std::string
file.open(filename,std::ios_base::trunc); // geht am PC, aber nicht in RISCOS
// filename wird als std::string nicht ausgewertet - muss man daher explizit selbst tun
file.open(filename.c_str(),std::ios_base::trunc); // geht am PC und in RISCOS

das ist halt lästig, dürfte aber an den unterschiedlichen Compilern und dazugehöriger Version der Standard Library liegen.
Habe als 'Fingerübung' mal ein Programm angefangen das sich 'generator' nennt, und zunächst mal ein makefile aufgrund der vorhandenen Dateien in den c, cpp und h -Unterverzeichnissen erstellt, sodass man nur noch 'make' tippen muss um den Compilevorgang zu starten.
Mal sehen was da noch draus wird. Noch kann es sich aber nicht selbst erzeugen helfen, weil noch nicht fertig.
Das Ergebnis heisst im Moment immer 'runme' auf Riscos oder 'runme.exe' auf dem PC.
Perspektivisch wollte ich dann halt wie vorher mal herumgesponnen noch andere Dateien unterstützen und auch automatisch Programmcode erzeugen.

Schönes Wochenende,

Uwe
uwe, 12. 08. 2016, 15:46 Link
Hab ein Problem mit toter EDV (nicht Acorn aber steinalt). Dummerweise hat mein "CB Funk und Computerreparatur" Laden in der Nähe dicht gemacht :(
Kennt jemand eine Anlaufstelle für sowas in Berlin? Vermutlich muß nur die Sicherung auf der Platine ausgelötet und ersetzt werden aber da fehlen mir geeignete Geräte und Fähigkeiten für.
Patric, 19. 08. 2016, 16:26 Link
Guck mal bei VzEkC (click) nach Rauschdiagnose, Microprofessor oder Thunder.Bird. Die machen in BLN immer mal einen "Stammtisch", wo man sicher auch mal vorbeischauen kann und dann entsprechend weitergeleitet wird. Außerdem gibt es vom ccc auch so einen Treff, der regelmäßig stattfindet und erstmal offen für Neues ist. Wenns warten kann, ist im Herbst (wieder) die Veranstaltung VCFB, wo es auch einen Lötkurs gibt und Du unter fachkundiger Anleitung das selbst "richten" kannst.
Oder frag mal im Usenet auf Amateurfunker-Seiten, ob da jemand aus der Gegend ist. Die sind i.a. sehr nett und hilfsbereit, was solche Sachen angeht und haben normalerweise auch das nötige Zubehör.
naitsabes, 19. 08. 2016, 22:10 Link
@naitsabes

Danke, das wird wohl die bessere Möglichkeit sein. Mein Archie macht glücklicherweise keine Probleme aber wenn das irgendwann mal losgeht mit defekten Kondensatoren etc. geht der Spaß erst richtig los.
Patric, 23. 08. 2016, 09:56 Link
ArcSite   News   Magazin   Börse   Links   ArcArchie   Homepages