Hallo,
für eine Konsolenanwendung (Programmiersprache C) möchte ich einzelne
Pixel auf einem Grafikbildschirm ansprechen bzw. auslesen (analog
Quickbasic-Befehle "Screen x" und "Pset(u,v),w" bzw. "a = Point(u,v)").
Welche Ein-/Ausgabe-Bibliothek benötige ich da, weiß das jemand?
sdl, opencv, opengl, glut...
Ich kenne QuickBasic aber nicht und ja, zugegebenermaßen sind die
letzten beiden, wohl ein wenig viel für das Setzen eines Pixels. ;-)
Wenn du einen halbwegs aktuellen Rechner hast, geht das gar nicht.
Da wird Zeichnen nur noch in Fenstern gehen, und wie das wiederum
geht, hängt davon ab, womit du arbeitest.
PS: dachte, du willst auch Punkte setzen. Auslesen sollte gehen,
hängt aber auch wieder davon ab, womit du arbeitest.
Danke für die Antworten!
Mein Programmier- und Bastelrechner hat CPU PIII und eine 128MB große
Grafikkarte, ist also recht alt, BS ist Win2k.
Im Fenster ist ok. Will ein bißchen mit selbstgeschriebenen
Fraktalprogrammen experimentieren.
Dann meine Empfehlung:
Fang mit Qt an.
Ist gut gemacht, portabel (man lernt etwas, was man recht breit nutzen
kann), es gibt bei trolltech.com gute Tutorials und gute Doku.
Es gibt auch viele andere Möglichkeiten natürlich, jeder wird etwas
anderes raten.
Hi,
wenn es nur unter Windows lauffähig sein soll empfehle ich Dir Gdi+ .
Die DLL liegt in deinem SYSTEM32 Ordner von Windows und auch Microsoft
arbeitet damit, siehe z.B. PAINT.
Ansonsten würde ich auch zu QT greifen , wie Klaus schon sagte.
Gruß
Klaus Wachtler schrieb:> C64
Oder ein Edding? Gibt es auch als trocken abwischbar. ;-)
Ansonsten, Qt klingt gut, aber nur zum Setzen eines Pixels... wobei ich
vermute, dass da noch mehr kommt. Nur ein Pixel bringt es ja nicht
wirklich. ;-)
ikarus schrieb:> Ansonsten, Qt klingt gut, aber nur zum Setzen eines Pixels... wobei ich> vermute, dass da noch mehr kommt. Nur ein Pixel bringt es ja nicht> wirklich. ;-)
Für ein Pixel würde ich glatt zum Edding greifen, aber bei rund 600000
Pixeln macht das eher keinen Sinn ;-)
Es soll mit zwei Schleifen ein x-y-Koordinatensystem abgefahren werden,
also 2D-Grafik. Für jede x-y-Koordinate wird ein Wert aus x und y
errechnet, wenn eine vorgegebene Bedingung erfüllt ist, wird der Punkt
(das Pixel) gesetzt, sonst nicht (unter Umständen wird noch eine
bestimmte Farbe für den Punkt gewählt).
Habe die hier vorgeschlagenen Sachen gegoogelt und bei Wikipedia
nachgeschaut. Es sieht ein bißchen so aus, als wäre es ein ziemlicher
Aufwand, mit C solche Pixel zu zeichnen.
Dachte, es gibt vielleicht eine einfache Bibliothek wie z.B. die
stdio.h, mit deren Hilfe man so etwas direkt umsetzen kann.
Es gibt noch GTK als Alternative zu Qt, das ist zumindestens nativ in C
geschrieben.
>Es sieht ein bißchen so aus, als wäre es ein ziemlicher Aufwand, mit C>solche Pixel zu zeichnen.
Muss das Ergebnis sofort sichtbar sein? Wenn nicht könnte das Programm
einfach eine Bilddatei erzeugen, das BMP-Format z.B. ist ziemlich simpel
und sollte sich relativ schnell und einfach implementieren lassen. Für
andere Formate dürfte es Bibliotheken geben, wobei JPG und andere
verlustbehaftete Formate wohl nicht geeignet sind.
GB schrieb:> Für ein Pixel würde ich glatt zum Edding greifen, aber bei rund 600000> Pixeln macht das eher keinen Sinn ;-)
Es gibt auch breite Eddings.
dreikleinepunkte schrieb:> Muss das Ergebnis sofort sichtbar sein?
Definitiv ja!
Bei Wiki findet man übrigens folgende Alternativen zu GTK
-Qt
-WxWidgets
-FLTK
-WinBinder
-Ultimate++
QT hatten wir ja schon...
Gibt es nicht eine erweiterte stdio.h, mit der man auch einzelne Pixel
darstellen kann?
PS: die Idee mit der Erzeugung der Bilddatei ist gut! Leider will ich in
dem Fall direkt sehen, wie die Fraks entstehen.
Dort geht es um das Erkennen der Pixelfarbe an Position x,y. Das Prinzip
ist aber ähnlich...
Wie mag wohl der Befehl für Pixel-Setzen lauten?
??? SetPixel(Farbe,x,y); ???
Unter Linux geht so etwas mit einem Framebuffer-Device. Unter DOS
eventuell mit einer VESA-Bibliothek. Unter Windows gibt es nichts
vergleichbares. Man kann es vielleicht mit Allegro probieren, einer
Bibliothek, die vor allem für die Spieleprogrammierung empfohlen wird.
GB schrieb:> Sebastian schrieb:>> Unter DOS>> eventuell mit einer VESA-Bibliothek.> Die Konsolenanwendung läuft meines Wissens unter DOS, dann könnte das ja> gehen...
DOS gibts schon lange nicht mehr, korrekt heißt das Win32-Konsole!
http://www.c-plusplus.de/forum/39310
GB schrieb:>> Unter DOS>> eventuell mit einer VESA-Bibliothek.> Die Konsolenanwendung läuft meines Wissens unter DOS, dann könnte das ja> gehen...
Sicher nicht.
Ich würde SDL empfehlen, Tutorials gibt es zu Hauf im Netz. Bindet man
die Bibliothek spät (also per DLL-Datei) hat man auch keinen Ärger mit
dem kompilieren.
Regnes schrieb:> Ich würde SDL empfehlen, Tutorials gibt es zu Hauf im Netz. Bindet man> die Bibliothek spät (also per DLL-Datei) hat man auch keinen Ärger mit> dem kompilieren.
SDL sieht gut aus! Schaue ich mir am WE genauer an.
Klaus Wachtler schrieb am 02.12.2010 18:57:
> Wenn du einen halbwegs aktuellen Rechner hast, geht das gar nicht.
Das stimmt doch gar nicht!
Ich verwende dafür zur Zeit einen Intel Q9550 mit einer Colorfull Nvidia
GTX295(PCIe) und einen HannsG 28"-LCD-Monitor. Das ist doch wohl noch
ein halbwegs aktuellen Rechner, oder etwa nicht?
> Da wird Zeichnen nur noch in Fenstern gehen, ....
Auch das stimmt nicht!
Wie auf jeden 80386+(ohne EFI-Bios) kann man dort z.B. ein MS-DOS 6.xx,
oder ein MS-DOS 7(von W98/ME), oder ein FREEDOS booten. Ich verwende
dafür ein 2GB-USB-Stick. Nachdem ich DOS gebootet habe kann ich nun z.B.
verschiede VESA-Bild-Modi, die meine GraKa in seinem VBE3-Bios mitbringt
einschalten. Mit einer Auflösung von bis zu 1920x1200x32(native
Auflösung meines Monitors) kann ich nun auch einzelne Pixel setzen.
Ich bevorzuge dafür Bildmodi mit einen Zugriff auf den linearen
Framebuffer(LFB). Um einen Zugriff auf den LFB(im 4.GB) zu ermöglichen
verwende ich den Unrealmode/Bigrealmode.
Siehe dazu auch das vbe3.pdf von vesa.org (register and/or login).
> PS: dachte, du willst auch Punkte setzen. Auslesen sollte gehen,> hängt aber auch wieder davon ab, womit du arbeitest.
Das Auslesen des Grafikrams sollte man aber besser nicht machen, da ein
Lesezugriff dort extrem langsam ist und der Grafikram nur für
Schreibzugriffe optimiert wurde.
Mail me to: freecrac at web.de
Dirk
Wenn du schon QBasic kennst wieso nimmst du dann nicht einfach
FreeBASIC?
screenres 640,480,32 'Besser wie screen wasauchimmer
pset (1,1),rgb(32,64,128)
sleep -1
Dirk Wolfgang Glomp schrieb:> Klaus Wachtler schrieb am 02.12.2010 18:57:>> Wenn du einen halbwegs aktuellen Rechner hast, geht das gar nicht.>> Das stimmt doch gar nicht!>> Ich verwende dafür zur Zeit einen Intel Q9550 mit einer Colorfull Nvidia> GTX295(PCIe) und einen HannsG 28"-LCD-Monitor. Das ist doch wohl noch> ein halbwegs aktuellen Rechner, oder etwa nicht?>>> Da wird Zeichnen nur noch in Fenstern gehen, ....>> Auch das stimmt nicht!>> Wie auf jeden 80386+(ohne EFI-Bios) kann man dort z.B. ein MS-DOS 6.xx,> oder ein MS-DOS 7(von W98/ME), oder ein FREEDOS booten. Ich verwende> dafür ein 2GB-USB-Stick.
Rechner = HW+SW
Ergo: eine aktuelle HW alleine mit DOS drauf macht noch lange keinen
aktuellen Rechner.
Dem TO ist ja wohl nicht damit gedient, wenn man ihm DOS empfiehlt.
Mit Quickbasic weiß er ja schon, wie es geht.
Und bevor gleich der Einwand kommt: natürlich kann man auch
unter aktuellen OS ins root-Fenter pinseln.
Hilfreich ist das aber auch nicht in diesem Fall.
GB schrieb:> Wie auf jeden 80386+(ohne EFI-Bios) kann man dort z.B. ein MS-DOS 6.xx,> oder ein MS-DOS 7(von W98/ME), oder ein FREEDOS booten. Ich verwende> dafür ein 2GB-USB-Stick. Nachdem ich DOS gebootet habe kann ich nun z.B.> verschiede VESA-Bild-Modi, die meine GraKa in seinem VBE3-Bios mitbringt> einschalten. Mit einer Auflösung von bis zu 1920x1200x32(native> Auflösung meines Monitors) kann ich nun auch einzelne Pixel setzen.> Ich bevorzuge dafür Bildmodi mit einen Zugriff auf den linearen> Framebuffer(LFB). Um einen Zugriff auf den LFB(im 4.GB) zu ermöglichen> verwende ich den Unrealmode/Bigrealmode.>> Siehe dazu auch das vbe3.pdf von vesa.org (register and/or login).
Und warum so umständlich? Mit SDL kann man das auch unter moderneren
Betriebssystemen im Fenster oder Fullscreen machen. Mir wäre das
jedenfalls zu blöd, jedesmal DOS zu booten, um ein bischen Grafik
auszugeben.
>> PS: dachte, du willst auch Punkte setzen. Auslesen sollte gehen,>> hängt aber auch wieder davon ab, womit du arbeitest.>> Das Auslesen des Grafikrams sollte man aber besser nicht machen, da ein> Lesezugriff dort extrem langsam ist und der Grafikram nur für> Schreibzugriffe optimiert wurde.
Es war der AGP, der für Schreibzugriffe optimiert ist. Den benutzt aber
heute eh kaum noch jemand. Bei PEG ist auch das Lesen schnell. Abgesehen
davon ist "extrem langsam" auch relativ.
GB schrieb:> Danke für die Antworten!>> Mein Programmier- und Bastelrechner hat CPU PIII und eine 128MB große> Grafikkarte, ist also recht alt, BS ist Win2k.>> Im Fenster ist ok. Will ein bißchen mit selbstgeschriebenen> Fraktalprogrammen experimentieren.
Ich vermute das deine GraKa ein VBE2-Bios oder VBE3-Bios mitbringt.
Unter purem DOS gebootet ist es damit möglich verschiedene
VESA-Bild-Modi zu benutzen und damit auch einzelne Pixel zu setzen.
Unter Win2k ist das aber leider nicht möglich, da dort kein echtes DOS
mehr enthalten ist. Das letzte MSDOS(7) war in Windows98/ME enthalten.
Alternative kann man aber auch ein aktuelles FREEDOS verwenden.
Mit einer MSI Geforce 4 TI4200(VBE3,AGPx4,64MB) habe ich begonnen
verschiedene VESA-Bild-Modi zu verwenden. Ab VBE3 gibt es die
Möglichkeit Vesamodi mit eigenem Videotiming(höhere Refreshrate als
60hz), mit einem linearen Zugriff auf den Framebuffer(im 4.GB), mit
hardware triple bufferring und für Stereostopic-Anwendungen
(Shutterbrille) zu verwenden.
Siehe dazu auch das vbe3.pdf von vesa.org (register and/or login).
Lieder habe ich keine Kenntnisse über C-Programmierung und so
programmiere ich daher lieber alles in Assembler. Um einen kleinen
Eindruck davon zu vermitteln wie ich es genau mache schaue dir bitte
meine Beiträge hier einmal an:
http://www.astahost.com/info.php/Vesa-Programming_t3849.html
Dort habe ich u.A. eine kleine 16Bit-DOS-Anwendung gepostet die es zeigt
wie man unter purem DOS einen Vesamodi mit 1024x768x32@100hz einschaltet
die den linearen Framebuffer mit vesa hardware triple buffering
verwendet. Benötigt wird dafür eine voll funktionstüchtige VBE3-GraKa
(wie z.B. eine GF4) und ein CRT-Monitor (mit DDC) der 96khz/160hz (wie
z.B. ein 19" CRT) bereitstellt und eine CPU mit MMX (wie z.B. ein P3).
Mail me to: freecrac at web.de
Dirk
Dirk Wolfgang Glomp schrieb:> Ich vermute das deine GraKa ein VBE2-Bios oder VBE3-Bios mitbringt.> Unter purem DOS gebootet ist es damit möglich verschiedene> VESA-Bild-Modi zu benutzen
Irgendewann muss man auch einmal akzeptieren, dass sich die Welt seit
DOS Zeiten und direkten GraKa Zugriffen weitergedreht hat.
Die DOS-Demos mit ihren sauschnellen Animationen sind zugegebenermassen
toll und wunderschön, aber in Zeiten in denen graphische Oberflächen
regieren, haben die Dinger so nichts mehr verloren.
Das ist alles am aussterbenden Ast. In der heutigen Zeit bringt es ihm
mehr, wenn er lernt, wie man kooperativ mit dem Betriebssystem bzw.
dessen Window-Manager zusammenarbeitet. Da führt kein Weg daran vorbei.
Die große Hürde und das was es kompliziert macht, ist nicht das Zeichnen
an sich, sondern das Aushandeln mit dem Window-Manager wie und wo er
jetzt ein Fenster erzeugen soll, wie das zb mit Scrollen ist, auf
Redraw/Resize Requests vom Window-Manager reagieren, alles für einen
Drucker aufzubereiten, beschicken des Clipboards etc.
Das eigentliche Pixelsetzen, egal ob direkt oder über eine
Offscreen-Bitmap und blitten, ist das kleinste Problem.
Rolf Magnus schrieb:> Und warum so umständlich? Mit SDL kann man das auch unter moderneren> Betriebssystemen im Fenster oder Fullscreen machen. Mir wäre das> jedenfalls zu blöd, jedesmal DOS zu booten, um ein bischen Grafik> auszugeben.
Und mir wäre es zu blöd um ein bischen Grafik auszugeben jedesmal
Windows booten zu müssen. Pures DOS hat danaben auch den Vorteil das man
einen uneingeschränkten Zugriff auf seine gesamte Hardware behält,
während man bei einem Protected-Mode-OS leider selber nicht mehr auf
seine Hardware direkt zugreifen darf. So kann man dann nur noch auf
Treiberfunktionen ausweichen und muss sich mit den Unzulänglichkeiten
diverser Biblotheken herumplagen. Wie schon erwähnt, nur um einen Pixel
setzen zu können braucht man dafür doch keine riesigen Biblotheken. Die
Benutzung des Vesa-Bios ist im Verhältniss dazu sehr leicht zu erlernen
und die DOS-Anwendungen selber bleiben damit auch relativ klein.
>>> PS: dachte, du willst auch Punkte setzen. Auslesen sollte gehen,>>> hängt aber auch wieder davon ab, womit du arbeitest.>>>> Das Auslesen des Grafikrams sollte man aber besser nicht machen, da ein>> Lesezugriff dort extrem langsam ist und der Grafikram nur für>> Schreibzugriffe optimiert wurde.>> Es war der AGP, der für Schreibzugriffe optimiert ist. Den benutzt aber> heute eh kaum noch jemand.
Eine GraKa mit 128MB kann aber sehr wohl auch eine AGP-GraKa sein.
Auch glaube ich das die meisten PC-Besitzer immer noch AGP-GraKas
verwenden.
> Bei PEG ist auch das Lesen schnell. Abgesehen> davon ist "extrem langsam" auch relativ.
Ja relativ zum Schreibzugriff wohl um einiges langsamer(bei
ISA/PCI/AGP).
Dirk
Dirk Wolfgang Glomp schrieb:> Und mir wäre es zu blöd um ein bischen Grafik auszugeben jedesmal> Windows booten zu müssen.
Äh, Du "arbeitest" unter DOS? Schreibst Deine Texte unter DOS, surfst
unter DOS im Internet?
Dirk Wolfgang Glomp schrieb:> Pures DOS hat danaben auch den Vorteil das man> einen uneingeschränkten Zugriff auf seine gesamte Hardware behält,
Jaja, die Mär hält sich. Gerade was die Ansteuerung von Graphikkarten
betrifft, ist das natürlich eher Humbug; die von Dir genutzten
VESA-Funktionen sind sehr rudimentäre und vor allem langsame Routinen,
um überhaupt was mit der Graphikkarte anzustellen, jedwede
Hardwarebeschleunigung ist dann inaktiv. Um die nutzen zu können,
müsstest Du die Funktionen selbst nachbilden, die in den Graphiktreibern
der Betriebssysteme untergebracht sind. Das ist a) ein riesiger Aufriss
und b) ziemlich sinnlos, weil dein tolles DOS-Programm dann auch nur mit
genau dieser Graphikhardware funktioniert.
Also wirst Du nur die VESA-BIOS-Routinen nutzen, und die sind ein
langsamer Notbehelf.
Dirk Wolfgang Glomp schrieb:> Auch glaube ich das die meisten PC-Besitzer immer noch AGP-GraKas> verwenden.
Die, die museale PCs verwenden. Seit mindestens 5 Jahren werden
PCIe-Graphikkarten verwendet.
Karl heinz Buchegger schrieb:> Dirk Wolfgang Glomp schrieb:>>> Ich vermute das deine GraKa ein VBE2-Bios oder VBE3-Bios mitbringt.>> Unter purem DOS gebootet ist es damit möglich verschiedene>> VESA-Bild-Modi zu benutzen>> Irgendewann muss man auch einmal akzeptieren, dass sich die Welt seit> DOS Zeiten und direkten GraKa Zugriffen weitergedreht hat.
DOS stirbt nicht aus, solange wir es benutzen und es auch Hardware dafür
gibt. Auch macht es mir keinen Spaß nur einen Lichtschalter zu benutzen
ganz ohne zu Wissen was sich hinter dem Deckel verbirgt. Aus diesem
Grund mag ich weder Hochsprachen(zum Programmieren) besonders gerne
verwenden, noch fremde Bibliotheken in meine Anwendung einbinden.
> Die DOS-Demos mit ihren sauschnellen Animationen sind zugegebenermassen> toll und wunderschön, aber in Zeiten in denen graphische Oberflächen> regieren, haben die Dinger so nichts mehr verloren.
Es gibt aber auch keinen triftigen Grund DOS nicht mehr zu benutzen. Ich
habe ja keine gewerbliche/finanzille Interessen und betrachte meine
Aktivitäten am PC als ein rein privates Vergnügen.
> Das ist alles am aussterbenden Ast.
Das ist mir eigentlich völlig egal, solange es immer noch Hardware gibt
mit den man DOS benutzen kann. Vor ein paar Jahren las ich einen Artikel
im CT-Magazin das es eher unwarscheinlich sei, das neuere GraKas
überhaupt noch ein VESA-Bios mitbringen. Meine Colorfull Nvidia GTX 295
hat aber immer noch ein voll funktionstüchtiges VBE3-Bios integriert.
> In der heutigen Zeit bringt es ihm> mehr, wenn er lernt, wie man kooperativ mit dem Betriebssystem bzw.> dessen Window-Manager zusammenarbeitet.
Für Windows-Programmierung konnte ich mich noch nie so richtig erwärmen.
Dann schon eher für Linux, auch schon deswegen weil es Opensource ist
und nach meiner Einschätzung auch um einiges stabiler läuft als Windows.
> Da führt kein Weg daran vorbei.
Ich benutze Windows hauptsächlich nur zum Spielen. Eine gewerblich
Nutzung von Windows betrachte ich als fahrlässig.
> Die große Hürde und das was es kompliziert macht, ist nicht das Zeichnen> an sich, sondern das Aushandeln mit dem Window-Manager wie und wo er> jetzt ein Fenster erzeugen soll, wie das zb mit Scrollen ist, auf> Redraw/Resize Requests vom Window-Manager reagieren, alles für einen> Drucker aufzubereiten, etc.
Tja eben, alles Dinge die man unter DOS überhaupt gar nicht benötigt.
> Das eigentliche Pixelsetzen, egal ob direkt oder über eine> Offscreen-Bitmap und blitten, ist das kleinste Problem.
Dann kann ich ja gleich bei DOS bleiben und nur das machen was wirklich
nötig ist um ein Pixel zu setzen. Logisch das man sich es auch
umständklicher machen kann, als es eigentlich sein muss.
Dirk
Dirk Wolfgang Glomp schrieb:>> In der heutigen Zeit bringt es ihm>> mehr, wenn er lernt, wie man kooperativ mit dem Betriebssystem bzw.>> dessen Window-Manager zusammenarbeitet.>> Für Windows-Programmierung konnte ich mich noch nie so richtig erwärmen.
Ich hab auch absichtlich nicht von Windows an sich gesprochen, sondern
vom Window-Manager. Jedes graphische BS bzw. jeder Aufsatz wie zb
X-Windows hat so etwas.
> Ich habe ja keine gewerbliche/finanzille Interessen und betrachte> meine Aktivitäten am PC als ein rein privates Vergnügen.
Siehst du: da scheiden sich dann die Geister.
Dir genügt es schöne Bilder zu sehen. Dagegen ist auch nichts zu sagen.
Aber die meisten legen dann doch auch Wert darauf, dass man zb eine
vernünftige File-Select-Box bekommt um die Machwerke abzuspeichern, dass
man Grafiken ins Clipboard übernehmen kann um sie dann in anderen
Applikationen wieder einsetzen zu können, dass man Dinge ausdrucken
kann, dass man mehrer Grafiken 'gleichzeitig' am Schirm hat um sie zb
vergleichen zu können, etc. etc.
Es gibt viele gute Gründe, warum moderne Oberflächen den klassischen
'Ich hab den Schirm für mich alleine' Ansätzen überlegen sind.
> Ich benutze Windows hauptsächlich nur zum Spielen. Eine gewerblich> Nutzung von Windows betrachte ich als fahrlässig.
Das mag schon sein.
Tatsache ist aber auch, dass geschätzte 90% aller industriell
eingesetzten PC mit Windows fahren. Das mag Einem gefallen oder nicht,
ändert aber nichts.
> Dann kann ich ja gleich bei DOS bleiben und nur das machen was wirklich> nötig ist um ein Pixel zu setzen. Logisch das man sich es auch> umständklicher machen kann, als es eigentlich sein muss.
Das was du umständlich nennst, ist für viele andere wichtiger
Bestandteil um ihre Programme in eine Umgebung zu integrieren, die davon
lebt, dass Datenaustausch zwischen Programmen möglich ist und möglich
sein muss. Und zwar für den Benutzer einfach und simpel.
Du argumentierst, wie jemand der mit Laubsäge und Nadelfeile aus
Messingblech die tollsten feinmechanischen Messgeräte im Stile des 16
oder 17. Jahrhunderts fertigt. Um nicht falsch verstanden zu werden: Ich
habe große Hochachtung vor solchen Leuten. Sowohl damals wie auch heute.
Aber wenn es dann darum geht, wie man solche Dinge heute fertigt (mit
CNC Maschinen) dann hilft dir diese Fertigkeit nichts bis nur sehr
wenig. Der Fertigungsprozess hat sich nun mal verändert und dann heißt
es "Friß Vogel oder stirb". Du wirst mit derartigen Spielereien zwar
jeden zukünftigen Boss zu tiefst beeindrucken, wenn dann aber auf die
Frage nach zeitgemässer Fertigung nichts kommt, wirst du den Job
trotzdem nicht kriegen.
Dirk Wolfgang Glomp schrieb:> Und mir wäre es zu blöd um ein bischen Grafik auszugeben jedesmal> Windows booten zu müssen.
Mir auch. Aber mein primär verwendetes Betriebssystem ist auch weder DOS
noch Windows.
> Pures DOS hat danaben auch den Vorteil das man einen uneingeschränkten> Zugriff auf seine gesamte Hardware behält, während man bei einem> Protected-Mode-OS leider selber nicht mehr auf seine Hardware direkt> zugreifen darf.
Ob das ein Vorteil ist, ist Ansichtssache. Ein falscher Registerzugriff
bringt dann ggf. gleich alles zum Absturz. Und wenn du eine andere
Hardware hast, die das gleiche macht, aber auf die man anders zugreifen
muß, darf man den ganzen Sch* nochmal programmieren. Siehe auch die
alten DOS-Spiele, wo jedesmal Dutzende bis Hunderte von Soundtreibern
dabei waren. Ein gescheites OS abstrahiert das, so daß ich ein
einheitliches Interface hab und es mir egal sein kann, welche konkrete
Hardware nun dahinter steckt.
> Wie schon erwähnt, nur um einen Pixel setzen zu können braucht man dafür> doch keine riesigen Biblotheken.
Braucht man auch nicht. Die Bibliotheken braucht man nur, um mal den
Framebuffer aufzusetzen.
> Die Benutzung des Vesa-Bios ist im Verhältniss dazu sehr leicht zu> erlernen und die DOS-Anwendungen selber bleiben damit auch relativ klein.
Was bringt mir eine "relativ kleine" Anwendung, wenn ich mangels
Multitasking die dadurch gesparten Ressourcen für nichts anderes
benutzen kann? Dann bleiben halt 3,9999 von meinen 4 GB RAM ungenutzt.
Geld bekomme ich dafür nicht zurück.
>>> Das Auslesen des Grafikrams sollte man aber besser nicht machen, da ein>>> Lesezugriff dort extrem langsam ist und der Grafikram nur für>>> Schreibzugriffe optimiert wurde.>>>> Es war der AGP, der für Schreibzugriffe optimiert ist. Den benutzt aber>> heute eh kaum noch jemand.>> Eine GraKa mit 128MB kann aber sehr wohl auch eine AGP-GraKa sein.> Auch glaube ich das die meisten PC-Besitzer immer noch AGP-GraKas> verwenden.
Daß das die meisten sind, bezweifle ich.
Dirk Wolfgang Glomp schrieb:> DOS stirbt nicht aus, solange wir es benutzen und es auch Hardware dafür> gibt. Auch macht es mir keinen Spaß nur einen Lichtschalter zu benutzen> ganz ohne zu Wissen was sich hinter dem Deckel verbirgt. Aus diesem> Grund mag ich weder Hochsprachen(zum Programmieren) besonders gerne> verwenden, noch fremde Bibliotheken in meine Anwendung einbinden.>>> Die DOS-Demos mit ihren sauschnellen Animationen sind zugegebenermassen>> toll und wunderschön, aber in Zeiten in denen graphische Oberflächen>> regieren, haben die Dinger so nichts mehr verloren.>> Es gibt aber auch keinen triftigen Grund DOS nicht mehr zu benutzen.
Wenn es alles bietet, was du brauchst (was mich echt erstaunt), dann
kann man es natürlich weiterhin benutzen. Es gibt ja auch Leute, die
noch mit einem C64 arbeiten.
>> Das eigentliche Pixelsetzen, egal ob direkt oder über eine>> Offscreen-Bitmap und blitten, ist das kleinste Problem.>> Dann kann ich ja gleich bei DOS bleiben und nur das machen was wirklich> nötig ist um ein Pixel zu setzen. Logisch das man sich es auch> umständklicher machen kann, als es eigentlich sein muss.
Umständlich ist, wenn ein Windows-Benutzer erstmal sein System
runterfahren und DOS booten muß, um sein Programm starten zu können.
Rufus Τ. Firefly schrieb:> Dirk Wolfgang Glomp schrieb:>> Und mir wäre es zu blöd um ein bischen Grafik auszugeben jedesmal>> Windows booten zu müssen.>> Äh, Du "arbeitest" unter DOS? Schreibst Deine Texte unter DOS, surfst> unter DOS im Internet?
Surfen tue ich mit Windows und mit Linux. Zum Programmieren und zum
Schreiben von Texten genügt mir auch ein DOS.
> Dirk Wolfgang Glomp schrieb:>> Pures DOS hat danaben auch den Vorteil das man>> einen uneingeschränkten Zugriff auf seine gesamte Hardware behält,>> Jaja, die Mär hält sich. Gerade was die Ansteuerung von Graphikkarten> betrifft, ist das natürlich eher Humbug; die von Dir genutzten> VESA-Funktionen sind sehr rudimentäre und vor allem langsame Routinen,> um überhaupt was mit der Graphikkarte anzustellen, jedwede> Hardwarebeschleunigung ist dann inaktiv.
Das von mir benutze Vesa hardware triple buffering ist gar nicht so
langsam. Stereoskopische Modi habe ich aus Mangel einer Shutterbrille
allerdings noch nicht selber ausprobiert. Pixel setze ich aber doch
lieber selber direkt im GraKa-Ram, die langsame Vesa-funktion zum Setzen
von Pixeln braucht man ja nicht verwenden.
> Um die nutzen zu können,> müsstest Du die Funktionen selbst nachbilden, die in den Graphiktreibern> der Betriebssysteme untergebracht sind.
Richtig, dann hat man es aber auch gelernt wie man es machen muss.
Nur einen Lichtschalter zu benutzen ist ja im Vergleich dazu voll
langweilig. Mir geht es ja auch nicht darum das Rad neu zu erfinden,
sondern es zu lernen sich selber ein Rad zu bauen.
> Das ist a) ein riesiger Aufriss
Ja das stimmt.
> und b) ziemlich sinnlos,
Lernen ist nie sinnlos.
> weil dein tolles DOS-Programm dann auch nur mit> genau dieser Graphikhardware funktioniert.
Damit habe ich kein Problem, bzw. ich habe gar nicht den Anspruch
plattformübergreifend zu Programmieren und wenn ich x86er-Opcodes
verwende, dann soll meine Anwendeung auch nur auf einem x86er lauffähig
sein. Falls ich mal einen nicht mehr x86-compatiblen Rechner benutzen
sollte, dann kann ich ja die dortigen Opcodes verwenden.
Wie ich schon erwänht habe, ich habe keine gewerblichen Absichten und
benutze Computer ausschlieslich zum privatem Vergnügen aus purem Spaß.
> Also wirst Du nur die VESA-BIOS-Routinen nutzen, und die sind ein> langsamer Notbehelf.
Ich benutze das VESA-BIOS nur zum Programmieren und ich programmiere nur
zum Lernen. Der Hauptzweck ist damit schon zu 100% erfüllt. Von einem
Notbehelf kann somit überhaupt nicht die Rede sein, weil ich eine eigene
Zielsetzung verfolge und ich mich hierbei auch nicht an anderen Zielen
orientieren brauche. Mir genügt das völlig und voraussichtlich habe ich
nicht einmal genügend Zeit dazu auf diesem Weg all das zu lernen was ich
alles gerne noch lernen möchte. Ganz bestimmt gehören
Unzulänmglichkeiten von Windows nicht zu diesen Dingen die ich gerne
lernen möchte.
> Dirk Wolfgang Glomp schrieb:>> Auch glaube ich das die meisten PC-Besitzer immer noch AGP-GraKas>> verwenden.>> Die, die museale PCs verwenden. Seit mindestens 5 Jahren werden> PCIe-Graphikkarten verwendet.
Also ich kaufe mir nicht alle 5 Jahre einen neuen PC. Auch deswegen weil
mir der Geschwindigkeitszuwachs nach 5 Jahren einfach immer noch viel zu
gering ist.
Dirk
Karl heinz Buchegger schrieb:> Dirk Wolfgang Glomp schrieb:>>>> In der heutigen Zeit bringt es ihm>>> mehr, wenn er lernt, wie man kooperativ mit dem Betriebssystem bzw.>>> dessen Window-Manager zusammenarbeitet.>>>> Für Windows-Programmierung konnte ich mich noch nie so richtig erwärmen.>>> Ich hab auch absichtlich nicht von Windows an sich gesprochen, sondern> vom Window-Manager. Jedes graphische BS bzw. jeder Aufsatz wie zb> X-Windows hat so etwas.
Genau dieses zu Lernen wie man Window-Manager(ob in Windows oder Linux)
zu benutzen hat, das macht mir überhaupt keinen Spaß um nur das zu
programmieren was ich eigentlich programmieren möchte. Eher würde ich
mir dann meinen eigenen Window-Manager programmieren, also falls ich so
einen Window-Manager überhaupt brauche.
>> Ich habe ja keine gewerbliche/finanzille Interessen und betrachte>> meine Aktivitäten am PC als ein rein privates Vergnügen.>> Siehst du: da scheiden sich dann die Geister.> Dir genügt es schöne Bilder zu sehen. Dagegen ist auch nichts zu sagen.> Aber die meisten legen dann doch auch Wert darauf, dass man zb eine> vernünftige File-Select-Box bekommt um die Machwerke abzuspeichern, dass> man Grafiken ins Clipboard übernehmen kann um sie dann in anderen> Applikationen wieder einsetzen zu können, dass man Dinge ausdrucken> kann, dass man mehrer Grafiken 'gleichzeitig' am Schirm hat um sie zb> vergleichen zu können, etc. etc.
Solche Dinge kann man sich auch alles unter DOS selber programmieren
ganz ohne es zu lernen wie man einen Window-Manager benutzen muss.
> Es gibt viele gute Gründe, warum moderne Oberflächen den klassischen> 'Ich hab den Schirm für mich alleine' Ansätzen überlegen sind.
Ich benutze eher selten mehrere Anwendungen gleichzeitig.
>> Ich benutze Windows hauptsächlich nur zum Spielen. Eine gewerblich>> Nutzung von Windows betrachte ich als fahrlässig.>> Das mag schon sein.> Tatsache ist aber auch, dass geschätzte 90% aller industriell> eingesetzten PC mit Windows fahren. Das mag Einem gefallen oder nicht,> ändert aber nichts.
Solange ich dadurch keinen Schaden erleide ist für mich das quasi
irrelevant wofür andere ihre Computer benutzen.
>> Dann kann ich ja gleich bei DOS bleiben und nur das machen was wirklich>> nötig ist um ein Pixel zu setzen. Logisch das man sich es auch>> umständklicher machen kann, als es eigentlich sein muss.>> Das was du umständlich nennst, ist für viele andere wichtiger> Bestandteil um ihre Programme in eine Umgebung zu integrieren, die davon> lebt, dass Datenaustausch zwischen Programmen möglich ist und möglich> sein muss. Und zwar für den Benutzer einfach und simpel.
Ich habe schon damit begonnen eine Linux-Anwendung für die Konsole zu
programmieren die nur den Framebuffer(fb0) verwendet. Damit ist es mir
ebenfalls möglich Datenpakete über IP an eine zweite Anwendung auf einem
zweiten Linux-Rechner zu versenden. Dafür brauche ich also keinen
X-Server.
> Du argumentierst, wie jemand der mit Laubsäge und Nadelfeile aus> Messingblech die tollsten feinmechanischen Messgeräte im Stile des 16> oder 17. Jahrhunderts fertigt.
Ja mit diesem Vergleich bin ich bestens zufrieden.
> Um nicht falsch verstanden zu werden: Ich> habe große Hochachtung vor solchen Leuten. Sowohl damals wie auch heute.
Ja wenn ich so etwas könnte, dann habe ich meine Erwartungen schon
übertroffen. Ich würde mich jetzt selber nicht als ein Blitzmerker
oder als einen Menschen bezeichnen der schnell lernt. Ganz im Gegenteil,
ich brauche doch ganz schön lange und je älter ich werde wird das auch
nicht besser.
> Aber wenn es dann darum geht, wie man solche Dinge heute fertigt (mit> CNC Maschinen) dann hilft dir diese Fertigkeit nichts bis nur sehr> wenig.
Eine eigene CNC Maschine kann ich mir auf Grund meiner bescheidenen
Lebensweise gar nicht erst leisten. So bin ich eher bemüht, mit den
wenigen Mitteln die ich zur Verfügung habe, das Beste daraus zu machen.
Auch habe ich wirklich keine Lust mein Hobby zum Beruf zu machen.
> Der Fertigungsprozess hat sich nun mal verändert und dann heißt> es "Friß Vogel oder stirb".
Als Handwerker(Bäcker) schmecken mir von Hand gefertigte Produkte um ein
vielfaches besser, als solche die nicht von Hand bearbeitet werden.
> Du wirst mit derartigen Spielereien zwar> jeden zukünftigen Boss zu tiefst beeindrucken, wenn dann aber auf die> Frage nach zeitgemässer Fertigung nichts kommt, wirst du den Job> trotzdem nicht kriegen.
Als Rentner habe ich keinerlei Ambitionen irgendeinen Boss beeindrucken
zu müssen.
Dirk
Dirk Wolfgang Glomp schrieb:
[vieles]
Alles das was du schreibst ist ok.
Aber denkst du nicht, dass du persönlich in einer Situation bist, die
man keineswegs als 'den Normalfall' ansehen kann (damit ist jetzt keine
Wertung gut/schlecht verbunden).
Du (genauso Dinosaurier wie ich *) arbeitest gerne mit der Karte direkt,
weil du keine darüber hinausgehenden Ambitionen hast. Das ist für sich
gesehen auch ok.
Aber einem Neuling sollte man derartige Techniken nicht mehr versuchen
schmackhaft zu machen. Das ist für ihn nicht sinnvoll sondern
kontraproduktiv.
Ganz abgesehen, dass es dir höchst wahrscheinlich sowieso nicht gelingen
wird :-)
Für jemanden der heute 'einsteigt', ist DOS-Programmierung kein Thema
mehr.
*) Ich bin insofern Dinosaurierer als ich meine ersten
Windows-Applikationen auch noch direkt mit dem WinAPI geschrieben habe.
Danach MFC. Mit beiden steh ich mitlerweile weitgehend allein auf weiter
Flur. Und so wie ich eine MFC-App schneller hochgezogen habe als du mit
deinem Assembler "Pap" sagen kannst, genauso sticht mich die
nachfolgende Generation der .Net Programmierer aus, die in ihrem
Framework Bausteine zur Verfügung hat, von denen ich zu MFC Zeiten noch
nicht einmal träumen konnte.
Klar kann ich das auch alles selber machen, aber es ist ganz einfach
nicht sinnvoll das zu tun. Ich will mich auf meine Problemstellung
konzentrieren können und mich nicht erst stundenlang mit einer
Fileselektion oder Eingebainstrumenten rumschlagen müssen, die andere
mit der richtigen Bibliothek in 20 Sekunden fertig zur Hand haben. Für
meine Zwecke tut es das, was ich in der MFC zur Verfügung habe, mehr
brauch ich nicht (und dann hat man ja auch noch seinen Fundus zur
Verfügung). Wenn mich aber jemand fragt, womit er anfangen soll, dann
rate ich ihm nicht zur MFC. Warum? Weil es im Grunde genommen ein totes
Pferd ist.
Dirk Wolfgang Glomp schrieb:> Das von mir benutze Vesa hardware triple buffering ist gar nicht so> langsam. Stereoskopische Modi habe ich aus Mangel einer Shutterbrille> allerdings noch nicht selber ausprobiert. Pixel setze ich aber doch> lieber selber direkt im GraKa-Ram, die langsame Vesa-funktion zum Setzen> von Pixeln braucht man ja nicht verwenden.
Das ist extrem langsam, egal ob Vesa-Funktion oder direkt in den
Speicher der Grafikkarte geschrieben.
Die GTX295 hat bspw. eine Speicherbandbreite von 223.8 GB/s
(Gigabyte/s), selbst wenn man die volle PCIE 16 Bandbreite von 4 GB/s
(pro Richtung) ausnutzen könnte, wäre das ein Witz.
>> Um die nutzen zu können,>> müsstest Du die Funktionen selbst nachbilden, die in den Graphiktreibern>> der Betriebssysteme untergebracht sind.>> Richtig, dann hat man es aber auch gelernt wie man es machen muss.
Nein und man lernt auch nichts, was man nicht auch mit einem normalen
Fenster-Manager und einer Bitmap (+ BitBlt) lernen könnte.
Die Hardware selber kannst du nicht ansteuern, da die Dokumentation
nicht frei verfügbar ist (abgesehen von rudimentären Sachen und bei
einigen veralteten GPUs).
> Also ich kaufe mir nicht alle 5 Jahre einen neuen PC. Auch deswegen weil> mir der Geschwindigkeitszuwachs nach 5 Jahren einfach immer noch viel zu> gering ist.
Dann würde ich mir mal ein paar Benchmarks ansehen (kleiner Tip: das
sind nicht 10% bis 20% (die man tatsächlich so gut wie nicht bemerkt),
sondern je nach Aufgabe Faktor 10 - 20).
> Dirk
Ich habe ja auch unter DOS angefangen, erst MS QBASIC, danach Pascal mit
dem Borland-Graphik-Interface-Zeugs (diese tollen BGI-Treiber...).
Verglichen mit der Fummelei ist aber selbst X11 noch ein Kinderspiel.
Genauso zahlreiche Graphikbibliotheken, um einfach nur in eine Bilddatei
zu schreiben. Oder schlicht und ergreifend ein textbasiertes
Pixelformat, etwa PPM, zu welchem es nur noch printf() braucht.
Aber ernsthaft: Schlägst du dich Tag für Tag mit den Nickeligkeiten der
DOS-Konsole herum? Das ist die primitivste Konsole, die ich kenne --
programmierbar wie Legoklötze...
Ich kann dich voll verstehen, da ich auch stets einen Hang zum Damals
habe. Genauso habe ich keine Lust, mich in KDE oder Gnome oder Windows
einzuarbeiten, damit meine Programme sich irgendwie integrieren -- es
werden halt flexible Konsolenprogramme. Da kann ich immer noch ein GUI
drumherumflicken, wenn ichs denn irgendwann mal brauche.
Das letzte, was ich graphisch gemacht habe, enthielt bestenfalls zehn
aus der Anleitung kopierte Zeilen zur Initialisierung, bis ich meine
Pixel setzen und lesen konnte -- aber dafür schlage ich mich doch nicht
mehr mit einer Krücke wie DOS herum, die bei ihrer Geburt schon ein
Jahrzehnt veraltet war?!
Sven P. schrieb:> Ich habe ja auch unter DOS angefangen, erst MS QBASIC, danach Pascal mit> dem Borland-Graphik-Interface-Zeugs (diese tollen BGI-Treiber...).>> Verglichen mit der Fummelei ist aber selbst X11 noch ein Kinderspiel.> Genauso zahlreiche Graphikbibliotheken, um einfach nur in eine Bilddatei> zu schreiben. Oder schlicht und ergreifend ein textbasiertes> Pixelformat, etwa PPM, zu welchem es nur noch printf() braucht.>>> Aber ernsthaft: Schlägst du dich Tag für Tag mit den Nickeligkeiten der> DOS-Konsole herum? Das ist die primitivste Konsole, die ich kenne --> programmierbar wie Legoklötze...>> Ich kann dich voll verstehen, da ich auch stets einen Hang zum Damals> habe. Genauso habe ich keine Lust, mich in KDE oder Gnome oder Windows> einzuarbeiten, damit meine Programme sich irgendwie integrieren -- es> werden halt flexible Konsolenprogramme. Da kann ich immer noch ein GUI> drumherumflicken, wenn ichs denn irgendwann mal brauche.
So sehen dann auch viele Anwendungen aus... scnr
Ernsthaft, wenn der TO wirklich hardwarenah programmieren will, dann
würde ich ein halbwegs leistungsstarkes Board mit AVR32, PIC24, dsPIC
oder Cortex-M3 und kleinem TFT vorschlagen. Zum einen ist die
Dokumentation vollständig, man kann (so gut wie) alle Algorithmen
implementieren und bis zum letzten Taktzyklus optimieren, hat den
Vorteil einer modernen Entwicklungsumgebung auf dem PC und lernt u.U.
mit wenig Ressourcen umzugehen.
Rolf Magnus schrieb:> Dirk Wolfgang Glomp schrieb:>> Und mir wäre es zu blöd um ein bischen Grafik auszugeben jedesmal>> Windows booten zu müssen.>> Mir auch. Aber mein primär verwendetes Betriebssystem ist auch weder DOS> noch Windows.
Nicht das mir ein paar Sekunden mehr oder weniger Bootzeit etwas
ausmachen würde (solche Vergleiche mit wenigen Sekunden Unterschied
empfinde ich geradezu schon belustigend), aber DOS bootet auch sehr
schnell.
>> Pures DOS hat danaben auch den Vorteil das man einen uneingeschränkten>> Zugriff auf seine gesamte Hardware behält, während man bei einem>> Protected-Mode-OS leider selber nicht mehr auf seine Hardware direkt>> zugreifen darf.>> Ob das ein Vorteil ist, ist Ansichtssache.
Ok, mag sein das es kein Vorteil ist, aber für mich ist es definitiv ein
Nachteil gegenüber DOS wenn ich auf meine Hardware nicht selber direkt
zugreifen darf. Wieso sollte ich mich vor mir selber beschützen lassen,
denn ich kann die Folgen einer Fehlbenutzung auf jeden Fall immer noch
selber verantworten. Als Beispiel dafür betrachte ich es als völlig
unsinnig das ich dafür Root-Rechte brauche um auf Port-Adressen
zuzugreifen die man nur auslesen aber nicht beschreiben kann, etwa wie
beim Port 3DAh.
> Ein falscher Registerzugriff> bringt dann ggf. gleich alles zum Absturz.
Das ist doch prima wenn man es so lernen kann die Register richtig zu
benutzen. Ich bin mein halbes Leben lang ohne Sicherheitsgurt LKW
gefahren und habe noch nie selber einen Auffahrunfall zu verantworten
gehabt. Sollen wir jetzt alle das Fahren komplett verlernen und es
völlig den Computern überlassen uns ans Ziel zu bringen? Dann ist aber
auch der Spaß zum Fahren bei mir auf jeden Fall nicht mehr da.
Dieser Vergleich hinkt zwar etwas, denn bei einem PC zu Hause wird nicht
mal ein Menschenleben riskiert, aber trotzdem versucht man hier aus
Sicherheitsgründen dem Benutzer zu beschützen während es danaben auf der
Autobahn sehr viele Opfer zu beklagen gibt. Wenn das nicht als
unverhältnissmäßig bezeichnen werden kann, dann weiss ich auch nicht was
denn sonst unverhältnissmäßig sein könnte.
> Und wenn du eine andere> Hardware hast, die das gleiche macht, aber auf die man anders zugreifen> muß, darf man den ganzen Sch* nochmal programmieren.
Es ist ja nicht so das man alles immer von Grund auf neu entwickeln
muss. Oft genügt es sich die nötigen Dinge die man schon entwickelt hat
zusammen zu kopieren und ein paar Änderungen vorzunehmen.
> Siehe auch die> alten DOS-Spiele, wo jedesmal Dutzende bis Hunderte von Soundtreibern> dabei waren. Ein gescheites OS abstrahiert das, so daß ich ein> einheitliches Interface hab und es mir egal sein kann, welche konkrete> Hardware nun dahinter steckt.
Mit Soundkarten kenne ich mich zwar nicht wirklich aus, aber auch dort
gibt es Emulationen um einen gemeinsamen Nenner den Programmierern zur
Verfügung zu stellen.
>> Wie schon erwähnt, nur um einen Pixel setzen zu können braucht man dafür>> doch keine riesigen Biblotheken.>> Braucht man auch nicht. Die Bibliotheken braucht man nur, um mal den> Framebuffer aufzusetzen.
Ja das ist doch vergleichsweise so schrecklich so viel Last
mitzuschleppen. Ich füge nur solchen Subroutinen in meine Anwendung ein,
die auch mindestens zwei Mal aufgerufen werden. Anderfalls baue ich den
nötigen Code innerhalb der Hauptschleife direkt mit ein.
>> Die Benutzung des Vesa-Bios ist im Verhältniss dazu sehr leicht zu>> erlernen und die DOS-Anwendungen selber bleiben damit auch relativ klein.>> Was bringt mir eine "relativ kleine" Anwendung, wenn ich mangels> Multitasking die dadurch gesparten Ressourcen für nichts anderes> benutzen kann? Dann bleiben halt 3,9999 von meinen 4 GB RAM ungenutzt.> Geld bekomme ich dafür nicht zurück.
Huch, ich glaube du hast etwas missverstanden.
Von DOS aus kann man ebenso in den PM selber schalten, wenn kein
Memorymaanger ala emm386.exe gestartet wurde. So kann man seine Hardware
damit ebenso wie Windows/Linux es macht im vollem Umfang selber
benutzen, aber ganz ohne die Einschränkung denen
Windows/Linux-Anwendungen unterliegen. Unsere Anwendung befindet sich
nun selber im Ring 0, vergleichsweise wie der Kernel von Windows/Linux.
So kann man ebenso das Pageging, preemptives Multitasking und den
gesamten Adressbereich im 16Bit/32Bit/64Bit-Mode nach eigenen Reglen
benutzen. Die Einschränkung von WindowsXP(32Bit) nur 2GB Speicher für
eine Anwendung zu bekommen gibt es damit nicht mehr. Auf meinem MoBo
kann ich dann mit dem eingesteckten 4GB-Ram davon 2,6 GB für meine
Anwendung benutzen (der Rest ist belegt.)
Weil ich unter DOS aber auch weiterhin DOS- und BIOS-Funktionen, die für
den 16Bit-RM entwickelt wurden benutzen möchte, deswegen schalte ich in
den PM und erweitere nur das DS-Segment auf 4GB, bleibe im 16Bit-Mode
und schalte dann zurück in den so genannten Unrealmode. Danach schalte
ich dann noch die 21. Adressleitung frei und kann danach mit jedem
32Bit-Register den gesamten 4GB-Bereich adressieren und den oberen Ram
als Datenspeicher verwenden. Wenn ich es dann endlich mal gelernt habe
alle weiteren CPUs meines verwendeten Quadcores zu initialisieren, dann
kann man diese sogar auch auch unter 16-Bit-DOS benutzen.
Mit REX ist es auch möglich 64 bit-Befehle und damit noch mehr Ram zu
benutzen.
>>>> Das Auslesen des Grafikrams sollte man aber besser nicht machen, da ein>>>> Lesezugriff dort extrem langsam ist und der Grafikram nur für>>>> Schreibzugriffe optimiert wurde.>>>>>> Es war der AGP, der für Schreibzugriffe optimiert ist. Den benutzt aber>>> heute eh kaum noch jemand.>>>> Eine GraKa mit 128MB kann aber sehr wohl auch eine AGP-GraKa sein.>> Auch glaube ich das die meisten PC-Besitzer immer noch AGP-GraKas>> verwenden.>> Daß das die meisten sind, bezweifle ich.
Ok, das ist ja auch eher unwichtig für mich.
> Dirk Wolfgang Glomp schrieb:>> DOS stirbt nicht aus, solange wir es benutzen und es auch Hardware dafür>> gibt. Auch macht es mir keinen Spaß nur einen Lichtschalter zu benutzen>> ganz ohne zu Wissen was sich hinter dem Deckel verbirgt. Aus diesem>> Grund mag ich weder Hochsprachen(zum Programmieren) besonders gerne>> verwenden, noch fremde Bibliotheken in meine Anwendung einbinden.>>>>> Die DOS-Demos mit ihren sauschnellen Animationen sind zugegebenermassen>>> toll und wunderschön, aber in Zeiten in denen graphische Oberflächen>>> regieren, haben die Dinger so nichts mehr verloren.>>>> Es gibt aber auch keinen triftigen Grund DOS nicht mehr zu benutzen.>> Wenn es alles bietet, was du brauchst (was mich echt erstaunt), dann> kann man es natürlich weiterhin benutzen. Es gibt ja auch Leute, die> noch mit einem C64 arbeiten.
Vom C64 habe ich mich getrennt. Mit nur drei 8Bit-CPU-Register ist es
wirklich eine Qual hardwarenah zu programmieren, weil man eigentlich
extrem of 16Bit-Werte und größere Werte verarbeiten möchte, von den
Adressen im Ram mal ganz zu schweigen.
>>> Das eigentliche Pixelsetzen, egal ob direkt oder über eine>>> Offscreen-Bitmap und blitten, ist das kleinste Problem.>>>> Dann kann ich ja gleich bei DOS bleiben und nur das machen was wirklich>> nötig ist um ein Pixel zu setzen. Logisch das man sich es auch>> umständklicher machen kann, als es eigentlich sein muss.>> Umständlich ist, wenn ein Windows-Benutzer erstmal sein System> runterfahren und DOS booten muß, um sein Programm starten zu können.
Beides hat seine Vor- und Nachteile. Manche der kleinen DOS-Programme
kann man aber auch noch in XP zum laufen bekommen. Leider gibt es keine
vollständige Emulation für VESA.
Dirk
Ich respektiere deine Ausdauer, dich so intensiv mit der Krücke von x86
und dazu noch DOS herumzuschlagen. Das macht sicherlich auch Spaß für
kleine Bastelprojekte und so weiter.
Aber meinst du garnicht, dass es vielleicht so ganz langsam mal an der
Zeit wäre, den Weg von der Steinzeit in die Neuzeit zu beschreiten?
Einerseits sagst du, dass es für Soundkarten extra Emulatoren gibt, dann
beschreibst du selbst die Anpassungsarbeiten für andere Architekturen.
Und dann ist dir eine Abstraktionsschicht so winzig wie jene der SDL
schon zu viel?
All deine Klimmzüge, um irgendwie auf topaktueller Hardware dennoch
steinzeitlich programmieren zu können -- ich bewundere, wie du damit
herumjonglieren kannst -- sind doch immens verglichen mit den drei
Zeilen Quelltext, die es unter einem aktuellen Betriebssystem zusätzlich
bräuchte.
Wenn dich die Zugriffsrechte unter Linux so sehr stören (obwohl auch die
mit einem einzigen Befehl abzustellen wären), dann schreib doch z.B.
deine Anwendung als Modul im Kernelspace.
Versteh mich nicht falsch, ich hab auch schon meinen Spaß mit ASM auf
diversen Maschinen gehabt. Aber spätestens, als die Maschine moderner
wurde und begann, mir Steine in den Weg zu legen (21. Adressleitung per
Tastaturcontroller...), fand ichs doch interessanter, mich in die
aktuellen Gegebenheiten einzuarbeiten, als mir 100 Tricks und Kniffe
anzueignen.
Karl heinz Buchegger schrieb:> Dirk Wolfgang Glomp schrieb:>> [vieles]>>> Alles das was du schreibst ist ok.> Aber denkst du nicht, dass du persönlich in einer Situation bist, die> man keineswegs als 'den Normalfall' ansehen kann (damit ist jetzt keine> Wertung gut/schlecht verbunden).
Ich verstehe nicht so ganz was du mit 'Normalfall' eigentlich genau
meinst. Fast alle x86-Rechner(bis auf solche mit EFI-Bios) starten immer
noch im 16Bit-RM und können somit auch DOS booten. Auch vermute ich das
viele der modernen GraKas immer noch ein VESA-Bios mitbringen. Von der
verwendeten Hardware bin ich also immer noch im Normal-Bereich.
Wenn du mich aber selber nicht als Otto-Normal-Bürger einschätzt, dann
liegst du damit völlig richtig, denn das wollte ich auch niemals sein
und mag es eigentlich auch nicht besonders gerne, wenn man mich in eine
solche Schublade steckt.
> Du (genauso Dinosaurier wie ich *) arbeitest gerne mit der Karte direkt,> weil du keine darüber hinausgehenden Ambitionen hast. Das ist für sich> gesehen auch ok.
Ja genau so ein Dinosaurier bin ich auch.
> Aber einem Neuling sollte man derartige Techniken nicht mehr versuchen> schmackhaft zu machen. Das ist für ihn nicht sinnvoll sondern> kontraproduktiv.
Das sehe ich grundlegend anders. Jeder Anwender sollte es doch besser
schon vorher lernen wie eine CPU funktioniert noch bevor er überhaupt
eine Anwendung benutz. Ich habe die ersten Monate nur debug.exe
verwendet um die Funktionsweise der CPU kennen zu lernen, noch bevor ich
andere DOS-Befehle ausprobiert habe. Windows(3.11) habe ich erst Jahre
später installiert und mich auch dann noch lange geweigert ein neueres
Windows98 auszuprobieren, obwohl es schon lange verbreitet war.
> Ganz abgesehen, dass es dir höchst wahrscheinlich sowieso nicht gelingen> wird :-)
Ich Handel meistens mehr aus Überzeugung heraus und im Glauben das
Richtige zu tun, weniger darum ein bestimmtes Ziel damit auch erreichen
zu können. Wichtig ist doch nur der Weg selber, die Richtung die man
einschlägt, die innere Haltung während man agiert, ob man die Folgen
seiner Handlung auch tragen kann und den Spaß den man dabei hat. Da ich
die Verbreitung von Wissen als sehr wertvoll betrachte, aber nicht jedes
Mittel gerechtfertigt ist verwendet zu werden, darum ist es schon
unerlässlich das jeder Mensch sich manchmal auch etwa mehr dabei
anstrengt sich in die Gedanken von anderen Menschen hineinzudenken,
damit bei einem Gedankenaustausch keine zu grossen Missverständnisse
auftreten.
> Für jemanden der heute 'einsteigt', ist DOS-Programmierung kein Thema> mehr.
Das würde ich so nicht behaupten. Es gibt auch junge Menschen die sich
auch für DOS interessieren.
> *) Ich bin insofern Dinosaurierer als ich meine ersten> Windows-Applikationen auch noch direkt mit dem WinAPI geschrieben habe.> Danach MFC. Mit beiden steh ich mitlerweile weitgehend allein auf weiter> Flur. Und so wie ich eine MFC-App schneller hochgezogen habe als du mit> deinem Assembler "Pap" sagen kannst, genauso sticht mich die> nachfolgende Generation der .Net Programmierer aus, die in ihrem> Framework Bausteine zur Verfügung hat, von denen ich zu MFC Zeiten noch> nicht einmal träumen konnte.
Ja das kenne ich. Viel Spaß beim Wettrennen. Ich persöhnlich schaffe es
nie und nimmer so schnell neue Sachen zu lernen. Ich kapituliere.
> Klar kann ich das auch alles selber machen, aber es ist ganz einfach> nicht sinnvoll das zu tun.
Doch, denn nur das ist wirklich sinnvoll für mich, denn so verwende ich
meine Kräfte so wie ich damit am besten haushalten kann.
> Ich will mich auf meine Problemstellung> konzentrieren können und mich nicht erst stundenlang mit einer> Fileselektion oder Eingebainstrumenten rumschlagen müssen, die andere> mit der richtigen Bibliothek in 20 Sekunden fertig zur Hand haben.
Ok, wenn du dich damit dann zufrieden geben kannst so einen
Lichtschalter nur an und aus zu knipsen ohne zu wissen wie das
Innenleben sich gestaltet. Ich kenne auch noch sehr viele Dinge die ich
lernen möchte, aber ich arbeite lieber ohne jeden Zeitdruck. Wenn ich es
dann nie schaffe, dann kann ich damit auch gut leben.
> Für> meine Zwecke tut es das, was ich in der MFC zur Verfügung habe, mehr> brauch ich nicht (und dann hat man ja auch noch seinen Fundus zur> Verfügung). Wenn mich aber jemand fragt, womit er anfangen soll, dann> rate ich ihm nicht zur MFC. Warum? Weil es im Grunde genommen ein totes> Pferd ist.
Ich bin jetzt nicht so der Typ der in der Masse gerne mitschwimmt. So
geben mir Massenveranstaltungen nicht so den Kick wie anderen Menschen
die sich darüber sogar definieren können (Wir sind Weltmeister). Wenn
man jetzt aber immer nur den neusesten Entwicklungen hinterher hinkt und
nicht wirklich mithalten kann, dann soll mir das was genau für eine
Zufriedenheit geben etwas unvollstängig gelassen zu haben, nur weil ich
mir nie genug Zeit für eine Sache genommen habe?
Dirk
Sven P. schrieb:> Ich respektiere deine Ausdauer, dich so intensiv mit der Krücke von x86> und dazu noch DOS herumzuschlagen.
Mein für DOS verwendeter Intel Quadcore 9550 würde ich nicht als
x86-Krücke bezeichnen und DOS ist zwar eine alte Krücke, aber dafür
leichter bis tief in die untersten Schichten zu erlernen. Ich habe ja
auch nicht vor gleich ein eigenes OS zu programmieren.
> Das macht sicherlich auch Spaß für> kleine Bastelprojekte und so weiter.
Ja genau, es soll relativ beschaulich bleiben.
> Aber meinst du garnicht, dass es vielleicht so ganz langsam mal an der> Zeit wäre, den Weg von der Steinzeit in die Neuzeit zu beschreiten?
Ich will mich ja auch nicht grundsätzlich davor verschliessen, so habe
ich schon damit begonnen etwas für Linux zu programmieren.
> Einerseits sagst du, dass es für Soundkarten extra Emulatoren gibt, dann> beschreibst du selbst die Anpassungsarbeiten für andere Architekturen.
Die Emulation betraf hierbei eigentlich nur das BIOS der Soundkarten.
Bisher habe ich nur drei mal die Architektur gewechselt. Begonnen habe
ich auf einem TI-99-4a (von Texas Instruments), danach kam ein C64er und
dann ein 80286er. Ob ich überhaupt noch einmal wechsel ist bei näherer
Betrachtung doch eher unwahrscheinlich.
> Und dann ist dir eine Abstraktionsschicht so winzig wie jene der SDL> schon zu viel?
Es geht mir eher darum es zu lernen wie man alles selber macht, ich habe
kein spezielles Ziel vor Augen für eine bestimmte Anwendung. Es gibt
doch schon fast alles.
> All deine Klimmzüge, um irgendwie auf topaktueller Hardware dennoch> steinzeitlich programmieren zu können -- ich bewundere, wie du damit> herumjonglieren kannst -- sind doch immens verglichen mit den drei> Zeilen Quelltext, die es unter einem aktuellen Betriebssystem zusätzlich> bräuchte.
Ein einzener Printbefehl ist doch so etwas von langweilig, wo ich doch
nicht mal einen wirklichen Bedarf dafür habe etwa auszugeben. Wenn ich
lieber hardwarenah programmiere dann nur deswegen weil es mir Freude
bereitet neue Dinge zu lernen.
Wenn ich jedoch so manch einen C-Qellcode versuche zu lesen, dann
erkenne ich die Funktion darin nur sehr schwer (wenn überhaupt)
verglichen mit einem Assembler-Quellcode. Für mich gibt es nichts
Leichteres als Assembler und bevor ich mich mit solchen Widrigkeiten
auseinander gesetzt habe manche Dinge mit einer Hochsprache (die ich
nicht so gut kenne) zu programmieren, da habe ich es bereits schon in
Assembler fertig programmiert. Selbst mit Batchbefehlen bekomme ich es
manchmal nicht so schnell hin und programmiere es dann doch viel
schneller in Assembler als herauszufinden wie ein Kommando-Interpreter
es nun genau haben möchte.
> Wenn dich die Zugriffsrechte unter Linux so sehr stören (obwohl auch die> mit einem einzigen Befehl abzustellen wären), dann schreib doch z.B.> deine Anwendung als Modul im Kernelspace.
Als wie schwer schätzt du es denn ein so etwas zu lernen?
> Versteh mich nicht falsch, ich hab auch schon meinen Spaß mit ASM auf> diversen Maschinen gehabt. Aber spätestens, als die Maschine moderner> wurde und begann, mir Steine in den Weg zu legen (21. Adressleitung per> Tastaturcontroller...), fand ichs doch interessanter, mich in die> aktuellen Gegebenheiten einzuarbeiten, als mir 100 Tricks und Kniffe> anzueignen.
Auch mein Intel Q9550 hat immer noch so eine 21. Adressleitung im
Tastaturcontroller sitzen die darüber noch angeschaltet werden muss.
Das sind also immer noch aktuelle Gegebenheiten der meist genutzten
PC-Hardware. Und auch unter DOS kann man selber in den Long-Mode
schalten und alle weiteren CPUs selber initialisieren um die neuen Dinge
hardwarenah kenenzulernen und nicht nur theoretisch wie Programmierer
vom Userland im Ring 3.
Dirk
Die Achitektur um x86 herum ist eine Krücke, das weißt du ja selbst --
nicht, weil sie nicht modern ist, sondern weil sie z.B. immernoch
Altlasten mit herumschleppt, die man längst hätte beseitigen
sollen/können.
Es ist zwar schön, dass etwa der Prozessor heute noch mit
16-Bit-Instruktionen klarkommt, aber hilft das? Irgendwie wärs doch
sinnvoller, den Platz auf dem Silizium gescheiter zu verwenden --
notfalls emuliert heute jeder PC mit 100MHz aufwärts den alten Kram
schneller, als er ursprünglich laufen sollte. Die ganze Architektur ist
eben von Kompatibilität geprägt, was anfangs unbestreitbar sinnvoll war.
Allerdings wäre es m.M.n. schon mehr als einmal an der Zeit gewesen,
aufzuräumen.
Ich predige auch, Mikrocontroller mit Assembler zu beginnen, um die
Architektur kennen zu lernen. In fast allen Projekten auf dem AVR war
und ist Assembler unumgänglich gewesen: weil der Compiler Fehler
hat(te), weil der Optimierer total daneben greift oder, oder.
Aber dass du in Assembler schneller zurate kommst, als andere auf der
Konsole (bash z.B.) oder in einer Hochsprache, halte ich für
übertrieben. Natürlich, mir sind auch solche Fälle untergekommen: Fang
mal in C ganz simpel einen Übertrag (Carry-Bit im Statusregister) ab...
Was gehört denn dazu? Unter Linux ioperm() bis 0x3FF. Mit iopl() erhält
man Vollzugriff bis 0xFFFF. Danach gehts weiter, wie gewohnt, mit inb(),
outb() und Konsorten. Damit erlangst du Zugriff aus dem Userspace
heraus.
Arc Net schrieb:> Dirk Wolfgang Glomp schrieb:>> Das von mir benutze Vesa hardware triple buffering ist gar nicht so>> langsam. Stereoskopische Modi habe ich aus Mangel einer Shutterbrille>> allerdings noch nicht selber ausprobiert. Pixel setze ich aber doch>> lieber selber direkt im GraKa-Ram, die langsame Vesa-funktion zum Setzen>> von Pixeln braucht man ja nicht verwenden.>> Das ist extrem langsam, egal ob Vesa-Funktion oder direkt in den> Speicher der Grafikkarte geschrieben.
Das stimmt, verglichen mit anderen Möglichkeiten die aber nicht
hardwarenah bekannt gegeben werden ist das natürlich langsamer z.B. eine
Bresenham-Linie mit der CPU in den GraKa-Ram zeichenen zu lassen.
> Die GTX295 hat bspw. eine Speicherbandbreite von 223.8 GB/s> (Gigabyte/s), selbst wenn man die volle PCIE 16 Bandbreite von 4 GB/s> (pro Richtung) ausnutzen könnte, wäre das ein Witz.
Wie schon gesagt, es geht mir mehr darum zu lernen, ich habe keinen
wirklichen Bedarf für mich eine Anwendung zu programmieren. Und wenn ich
nur die Anfangs- und End-Koordinaten einer Linie angeben brauche, dann
kann ich ja auch gleich QBasic benutzen. Mir ist es doch egal wie lange
es dauert, denn ich habe genügend Zeit sogar das Setzen eines einzelnen
Pixels dabei mir anzusehen, wenn es so lange dauert. Also wenn ich es
nicht hardwarenah programmieren kann, weil solche Dinge immer noch unter
Verschluss gehalten werden, dann brauche ich es auch nicht wissen wie
man einen Closed-Source-Graka-Treiber benutzt um damit eine Anwendung zu
beschleunigen, weil es mir kein Spaß macht solche Rösser aus einem mir
fremden Stall zu reiten.
>>> Um die nutzen zu können,>>> müsstest Du die Funktionen selbst nachbilden, die in den Graphiktreibern>>> der Betriebssysteme untergebracht sind.
Ja genau, wenn die Qellen dafür (am besten gut dokumnteiert)
veröffentlicht werden, dann versuche ich es genauso auch in DOS zu
machen.
>> Richtig, dann hat man es aber auch gelernt wie man es machen muss.>> Nein und man lernt auch nichts, was man nicht auch mit einem normalen> Fenster-Manager und einer Bitmap (+ BitBlt) lernen könnte.
Ein leerer Bildschirm genügt mir vollauf wenn ich dann über Portadressen
die GraKa dazu bewwegen könnte solche Dinge zu machen.
> Die Hardware selber kannst du nicht ansteuern, da die Dokumentation> nicht frei verfügbar ist (abgesehen von rudimentären Sachen und bei> einigen veralteten GPUs).
Die meterlange Liste mit Portadressen von der Voodoo3 hat mich quasi
erschlagen weil ich damit immer noch keine Ahnung davon habe welche
Dinge man wofür benutzen muss und was und wie man damit etwas machen
kann.
Zur Zeit interessiert es mich auch wie man einen secondary display
device einer GraKa dazu bewegen kann den Inhalt des zweiten Framebuffers
anzuzeigen. In den Linux-Quellen habe ich mir einen Wolf gesucht.
Eigentlich müßte es dort doch enthalten sein, ebenso wie BitBlt.
>> Also ich kaufe mir nicht alle 5 Jahre einen neuen PC. Auch deswegen weil>> mir der Geschwindigkeitszuwachs nach 5 Jahren einfach immer noch viel zu>> gering ist.>> Dann würde ich mir mal ein paar Benchmarks ansehen (kleiner Tip: das> sind nicht 10% bis 20% (die man tatsächlich so gut wie nicht bemerkt),> sondern je nach Aufgabe Faktor 10 - 20).
Zu wenig um mich zu reizen. Ich brauche eine bezahlbare CPU mit 100.000
ghz je core und mit deutlich mit weniger Energieverbrauch.
Dirk
Sven P. schrieb:> Die Achitektur um x86 herum ist eine Krücke, das weißt du ja selbst --> nicht, weil sie nicht modern ist, sondern weil sie z.B. immernoch> Altlasten mit herumschleppt, die man längst hätte beseitigen> sollen/können.
Ja das stimmt und wenn ich es richtig vertanden habe, dann starten
MoBos mit einem EFI-Bios im 32/64 Bit-Mode und haben keine
16Bit-Routinen mehr im BIOS enthalten.
> Es ist zwar schön, dass etwa der Prozessor heute noch mit> 16-Bit-Instruktionen klarkommt, aber hilft das? Irgendwie wärs doch> sinnvoller, den Platz auf dem Silizium gescheiter zu verwenden --> notfalls emuliert heute jeder PC mit 100MHz aufwärts den alten Kram> schneller, als er ursprünglich laufen sollte. Die ganze Architektur ist> eben von Kompatibilität geprägt, was anfangs unbestreitbar sinnvoll war.> Allerdings wäre es m.M.n. schon mehr als einmal an der Zeit gewesen,> aufzuräumen.
Wenn die neuen Dinge dann auch genauso ausführlich dokumentiert werden
bin ich auch dafür. Aber nur zum Spielen würde ich mir gar keinen neuen
PC mehr kaufen.
> Ich predige auch, Mikrocontroller mit Assembler zu beginnen, um die> Architektur kennen zu lernen. In fast allen Projekten auf dem AVR war> und ist Assembler unumgänglich gewesen: weil der Compiler Fehler> hat(te), weil der Optimierer total daneben greift oder, oder.>> Aber dass du in Assembler schneller zurate kommst, als andere auf der> Konsole (bash z.B.) oder in einer Hochsprache, halte ich für> übertrieben. Natürlich, mir sind auch solche Fälle untergekommen: Fang> mal in C ganz simpel einen Übertrag (Carry-Bit im Statusregister) ab...
Die bash kenne ich so gut wie gar nicht und C auch nur marginal. Mit
Pascal komme ich besser klar ohne damit je selber gearbeitet zu haben.
> Was gehört denn dazu? Unter Linux ioperm() bis 0x3FF. Mit iopl() erhält> man Vollzugriff bis 0xFFFF. Danach gehts weiter, wie gewohnt, mit inb(),> outb() und Konsorten. Damit erlangst du Zugriff aus dem Userspace> heraus.
Aber nur mit Adminrechte kann man ioperm benutzen um zb. Port 3DAh
abzufragen. Das ist doch erbärmlich.
...
Ich bedanke mich bei euch Allen für eure Antworten. Für heute mache ich
Schluß. Einen schönen Abend wünsche ich euch.
Dirk
Dirk Wolfgang Glomp schrieb:> Aber nur mit Adminrechte kann man ioperm benutzen um zb. Port 3DAh> abzufragen. Das ist doch erbärmlich.
Nein, das ist Pflicht.
Es ist es unter DOS und war unter Windows vielleicht so üblich
(gewesen), dass derjenige alle Rechte hat, der vor der Tastatur sitzt.
Als DOS auf den Markt kam, hatten die Architekten ja sogar die primitive
Benutzerverwaltung, die von CP/M geerbt wurde, rausgeschmissen.
Unter UNIX/Linux allerdings hatte man schon etwas früher Netzwerk und
Multiuserbetrieb. Wenn da jeder Benutzer willkürlich im Arbeitsspeicher
hätte wüten dürfen... Du bist eben nicht der einzige im System. Selbst
wenn du alleine davor sitzt, arbeiten Dämonen im Hintergrund. Heb dein
Privilegienniveau mit iopl() an und schon darfst du schalten und walten.
Allerdings passt auch niemand mehr auf dich auf -- wenn du irgendeinem
anderen Programm das Speicherabbild plattmachst, ist das dein Bier.
Du schließt doch auch die Haustüre auf, bevor du eintrittst. Du gibst
auch eine Geheimzahl ein, bevor du Geld aus der Wand schlagen darfst.
Hmmm. Der Thread ist von Anfang des Monats. Und immernoch keine
zufriedenstellende Antwort für "GB"(hoffe, ich hab das richtig
überflogen).
Mein Vorschlag: Ein Fullscreen-Fenster erstellen, bei dem der OT dann
jeden Pixel einzeln setzten kann.
Jetzt nennt nur noch eine Bibliothek, mit der das einfach zu
bewerkstelligen ist.
(Ich hab auch mal mit der WinAPI hantiert. Das Ergebnis war nicht so
berrauschend und ich fand es seeehr kompliziert. Gut zu wissen, dass es
einfacher geht.)
Moin, moin.
Sven P. schrieb:> Dirk Wolfgang Glomp schrieb:>> Aber nur mit Adminrechte kann man ioperm benutzen um zb. Port 3DAh>> abzufragen. Das ist doch erbärmlich.> Nein, das ist Pflicht.
Dann nenne doch mal den Grund dafür warum nicht jeder Benutzer den Port
3DAh einfach nur auslesen kann und warum man dafür überhaupt spezielle
Rechte für braucht. Weder ist damit die Sicherheit gefährdet, noch kann
jemand damit kompromierende Informationen erhalten. Ich sehe dafür
einfach keinen Sinn das Auslesen des Ports 3DAh zu verhindern.
> Es ist es unter DOS und war unter Windows vielleicht so üblich> (gewesen), dass derjenige alle Rechte hat, der vor der Tastatur sitzt.> Als DOS auf den Markt kam, hatten die Architekten ja sogar die primitive> Benutzerverwaltung, die von CP/M geerbt wurde, rausgeschmissen.>> Unter UNIX/Linux allerdings hatte man schon etwas früher Netzwerk und> Multiuserbetrieb. Wenn da jeder Benutzer willkürlich im Arbeitsspeicher> hätte wüten dürfen... Du bist eben nicht der einzige im System. Selbst> wenn du alleine davor sitzt, arbeiten Dämonen im Hintergrund.
Das finde ich ja auch ganz praktisch, doch ich bestehe darauf mit meinen
Rechner alles machen zu dürfen was mir gefällt.
> Heb dein> Privilegienniveau mit iopl() an und schon darfst du schalten und walten.> Allerdings passt auch niemand mehr auf dich auf -- wenn du irgendeinem> anderen Programm das Speicherabbild plattmachst, ist das dein Bier.
Damit ist dann vermutlich aber auch das gesamte Schutzkonzept
ausgehebelt. Also wenn ich unbekannte Dritte die Möglichkeit einräumen
möchte meine Anwendung auszuführen, dann muss die Tür so weit offen
stehen, nur damit ein Port 3DAh ausgelesen werden kann.
> Du schließt doch auch die Haustüre auf, bevor du eintrittst.
Auf dem Land werden nicht überall die Türen verschlossen, aber hier in
der Stadt eigentlich schon.
> Du gibst> auch eine Geheimzahl ein, bevor du Geld aus der Wand schlagen darfst.
Nun kann man den Geldautomat der Bank nicht wirklich mit meinen eigenen
PC zu hause vergleichen, denn der gehört ja mir selber und der
Bankdirektor darf ganz gewiss auch ohne eine Geiheimzahl einzutippen an
seinen Geldautomat heran. Vergleichbar mit dem Auslesen des Ports 3DAh
muss der Bankdirecktor an jeden den Tresorschlüssel aushändigen, damit
der Aushang mit den allgemeinen Geschäftsbedingeungen gelesen werden
kann. Ich finde so eine Regel schon etwas sonderbar.
Dirk
Nun habe ich mal ein älteres Beispiel herausgekramt das bei mir auch
unter WinXP läuft und keinerlei Bibliotheken/Librarys benötigt (siehe
Dateianhang).
Dirk
Dirk Wolfgang Glomp schrieb:> Moin, moin.>> Sven P. schrieb:>> Dirk Wolfgang Glomp schrieb:>>> Aber nur mit Adminrechte kann man ioperm benutzen um zb. Port 3DAh>>> abzufragen. Das ist doch erbärmlich.>> Nein, das ist Pflicht.>> Dann nenne doch mal den Grund dafür warum nicht jeder Benutzer den Port> 3DAh einfach nur auslesen kann und warum man dafür überhaupt spezielle> Rechte für braucht.
Wie viele Ausnahmen möchtest du denn noch machen? Das Pufferregister vom
UART darf man dann wieder nicht lesen, denn dann würde das empfangene
Byte verloren gehen. Das Statusregister aber wieder schon. Bei den
Timern darf man dann wieder nicht, denn das würde die Lesereihenfolge
durcheinanderwerfen, wenn einfach jedermann zwischendurch lesen dürfte.
> Weder ist damit die Sicherheit gefährdet, noch kann> jemand damit kompromierende Informationen erhalten. Ich sehe dafür> einfach keinen Sinn das Auslesen des Ports 3DAh zu verhindern.
Es ist ja nicht nur Port 0x3DA, sondern es sind generell erst einmal
alle Ports, denn niemand außer den Treibern hat da etwas verloren.
>> Es ist es unter DOS und war unter Windows vielleicht so üblich>> (gewesen), dass derjenige alle Rechte hat, der vor der Tastatur sitzt.>> Als DOS auf den Markt kam, hatten die Architekten ja sogar die primitive>> Benutzerverwaltung, die von CP/M geerbt wurde, rausgeschmissen.>>>> Unter UNIX/Linux allerdings hatte man schon etwas früher Netzwerk und>> Multiuserbetrieb. Wenn da jeder Benutzer willkürlich im Arbeitsspeicher>> hätte wüten dürfen... Du bist eben nicht der einzige im System. Selbst>> wenn du alleine davor sitzt, arbeiten Dämonen im Hintergrund.>> Das finde ich ja auch ganz praktisch, doch ich bestehe darauf mit meinen> Rechner alles machen zu dürfen was mir gefällt.
Darfst du ja. Geb dein gottverdammtes Root-Passwort ein und du hast
alles im Griff. Im Gegensatz zu Windows darfst du ja dann mit dem
Rechner dann machen, was du möchtest, sogar auf höchster Ebene. Du
kannst dir von der Konsole aus dem Userspace den Graphikspeicher
vollschreiben und niemand wundert sich.
>> Heb dein>> Privilegienniveau mit iopl() an und schon darfst du schalten und walten.>> Allerdings passt auch niemand mehr auf dich auf -- wenn du irgendeinem>> anderen Programm das Speicherabbild plattmachst, ist das dein Bier.>> Damit ist dann vermutlich aber auch das gesamte Schutzkonzept> ausgehebelt. Also wenn ich unbekannte Dritte die Möglichkeit einräumen> möchte meine Anwendung auszuführen, dann muss die Tür so weit offen> stehen, nur damit ein Port 3DAh ausgelesen werden kann.
Ja und nein. Man kann auch Rechte für einen Bereich von Registern
einfordern. Aber ja, wenn du Rechte bekommen hast, bist du auch dafür
verantwortlich.
Unter DOS hast du das ja ohnehin -- gar keine Kontrolle, freie Bahn für
alles, was irgendwie schädlich sein kann und will.
> Nun kann man den Geldautomat der Bank nicht wirklich mit meinen eigenen> PC zu hause vergleichen, denn der gehört ja mir selber und der> Bankdirektor darf ganz gewiss auch ohne eine Geiheimzahl einzutippen an> seinen Geldautomat heran. Vergleichbar mit dem Auslesen des Ports 3DAh> muss der Bankdirecktor an jeden den Tresorschlüssel aushändigen, damit> der Aushang mit den allgemeinen Geschäftsbedingeungen gelesen werden> kann. Ich finde so eine Regel schon etwas sonderbar.
Und verglichen mit deinem DOS steht die Tresortür permanent für
jedermann offen.
Wenn ich Schadsoftware starte, plättet die mir schlimmstenfalls mein
Arbeitsverzeichnis, denn für alles weitere habe ich keine Rechte. Wenn
du Schadsoftware startest, formatiert sie dir ungehindert die
Festplatte, nagelt dir (je nach Alter der Platte) die Leseköpfe ins
Gehäuse und fackelt dir (je nach Alter des Monitores) den Zeilentrafo
mit falschen Frequenzen am VGA-Anschluss ab.
Auch recht sonderbar, finde ich. Vorallem auf einer Plattform, bei der
man in aller Regel nicht in die Quelltexte reingucken konnte, da
Shareware und nicht Open Source angesagt sind/waren.
http://www.qb64.net/forum/
qb64 ... ist wunderbar geeignet.
Ist 100% QB-BASIC ausser den Interpreterbefehlen und ist als Exe noch
schneller wie FreeBasic.
Läuft unter Windows im Fenster ab.
Kannste sogar mit "DEF SEG" arbeiten, Punkte setzen usw.
Die Maschine ist SDL, der Compiler ist C++...
Sven P. schrieb:> Dirk Wolfgang Glomp schrieb:>> Moin, moin.>>>> Sven P. schrieb:>>> Dirk Wolfgang Glomp schrieb:>>>> Aber nur mit Adminrechte kann man ioperm benutzen um zb. Port 3DAh>>>> abzufragen. Das ist doch erbärmlich.>>> Nein, das ist Pflicht.>>>> Dann nenne doch mal den Grund dafür warum nicht jeder Benutzer den Port>> 3DAh einfach nur auslesen kann und warum man dafür überhaupt spezielle>> Rechte für braucht.> Wie viele Ausnahmen möchtest du denn noch machen?
Überall dort wo der Schutz keinen Sinn macht.
> Das Pufferregister vom> UART darf man dann wieder nicht lesen, denn dann würde das empfangene> Byte verloren gehen. Das Statusregister aber wieder schon. Bei den> Timern darf man dann wieder nicht, denn das würde die Lesereihenfolge> durcheinanderwerfen, wenn einfach jedermann zwischendurch lesen dürfte.
Also da wäre der Port 3DAh und wohl auch die Ports 200h-208h.
>> Weder ist damit die Sicherheit gefährdet, noch kann>> jemand damit kompromierende Informationen erhalten. Ich sehe dafür>> einfach keinen Sinn das Auslesen des Ports 3DAh zu verhindern.> Es ist ja nicht nur Port 0x3DA, sondern es sind generell erst einmal> alle Ports, denn niemand außer den Treibern hat da etwas verloren.
Es macht aber keinen Sinn das Auslesen des Ports 3DAh zu verhindern.
>>> Es ist es unter DOS und war unter Windows vielleicht so üblich>>> (gewesen), dass derjenige alle Rechte hat, der vor der Tastatur sitzt.>>> Als DOS auf den Markt kam, hatten die Architekten ja sogar die primitive>>> Benutzerverwaltung, die von CP/M geerbt wurde, rausgeschmissen.>>>>>> Unter UNIX/Linux allerdings hatte man schon etwas früher Netzwerk und>>> Multiuserbetrieb. Wenn da jeder Benutzer willkürlich im Arbeitsspeicher>>> hätte wüten dürfen... Du bist eben nicht der einzige im System. Selbst>>> wenn du alleine davor sitzt, arbeiten Dämonen im Hintergrund.>>>> Das finde ich ja auch ganz praktisch, doch ich bestehe darauf mit meinen>> Rechner alles machen zu dürfen was mir gefällt.> Darfst du ja. Geb dein gottverdammtes Root-Passwort ein und du hast> alles im Griff.
Schon klar, aber dann muss ich ja jedem Anwender spezielle Rechte geben
nur damit die Anwendung Port 3DAh auslesen darf.
> Im Gegensatz zu Windows darfst du ja dann mit dem> Rechner dann machen, was du möchtest, sogar auf höchster Ebene. Du> kannst dir von der Konsole aus dem Userspace den Graphikspeicher> vollschreiben und niemand wundert sich.
Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung
Port 3DAh auslesen möchte.
>>> Heb dein>>> Privilegienniveau mit iopl() an und schon darfst du schalten und walten.>>> Allerdings passt auch niemand mehr auf dich auf -- wenn du irgendeinem>>> anderen Programm das Speicherabbild plattmachst, ist das dein Bier.>>>> Damit ist dann vermutlich aber auch das gesamte Schutzkonzept>> ausgehebelt. Also wenn ich unbekannte Dritte die Möglichkeit einräumen>> möchte meine Anwendung auszuführen, dann muss die Tür so weit offen>> stehen, nur damit ein Port 3DAh ausgelesen werden kann.> Ja und nein. Man kann auch Rechte für einen Bereich von Registern> einfordern.
Was ist damit genau gemeint?
> Aber ja, wenn du Rechte bekommen hast, bist du auch dafür> verantwortlich.
Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut
sein soll, wenn ich dann eh wie unter DOS alles machen darf.
> Unter DOS hast du das ja ohnehin -- gar keine Kontrolle, freie Bahn für> alles, was irgendwie schädlich sein kann und will.
Es geht ja mehr darum eigene Anwendungen auszuführen oder solche die
Opensource sind. Mit dieser Verantwortung kann ich bestens leben.
Von den wichtigsten eigenen Daten hat man ja eh eine Kopie und der Rest
kann immer wieder neu installieren.
>> Nun kann man den Geldautomat der Bank nicht wirklich mit meinen eigenen>> PC zu hause vergleichen, denn der gehört ja mir selber und der>> Bankdirektor darf ganz gewiss auch ohne eine Geiheimzahl einzutippen an>> seinen Geldautomat heran. Vergleichbar mit dem Auslesen des Ports 3DAh>> muss der Bankdirecktor an jeden den Tresorschlüssel aushändigen, damit>> der Aushang mit den allgemeinen Geschäftsbedingeungen gelesen werden>> kann. Ich finde so eine Regel schon etwas sonderbar.> Und verglichen mit deinem DOS steht die Tresortür permanent für> jedermann offen.>> Wenn ich Schadsoftware starte, plättet die mir schlimmstenfalls mein> Arbeitsverzeichnis, denn für alles weitere habe ich keine Rechte. Wenn> du Schadsoftware startest, formatiert sie dir ungehindert die> Festplatte, nagelt dir (je nach Alter der Platte) die Leseköpfe ins> Gehäuse und fackelt dir (je nach Alter des Monitores) den Zeilentrafo> mit falschen Frequenzen am VGA-Anschluss ab.
Solche alten Monitore/Festplatten betreibe ich schon lange nicht mehr
und alle für mich wichtige Daten habe ich auf CD/DVD gebrannt.
> Auch recht sonderbar, finde ich. Vorallem auf einer Plattform, bei der> man in aller Regel nicht in die Quelltexte reingucken konnte, da> Shareware und nicht Open Source angesagt sind/waren.
Wer MSDOS deswegen nicht mag kann ja auf Freedos ausweichen.
Dirk
Dirk Wolfgang Glomp schrieb:> Sven P. schrieb:>> Wie viele Ausnahmen möchtest du denn noch machen?>> Überall dort wo der Schutz keinen Sinn macht.
Und wenn dann eine weitere Steckkarte dazukommt, fügen wir wieder neue
Ausnahmen hinzu und wieder und wieder.
> Also da wäre der Port 3DAh und wohl auch die Ports 200h-208h.
S.u.
> Es macht aber keinen Sinn das Auslesen des Ports 3DAh zu verhindern.
Es ist aber konsistent. UNIX-Leute streuben sich seit jeher dagegen,
tausend Ausnahmen zu machen.
Viele Dinge aus der DOS-Welt sind auch total sinnlos:
- Laufwerke und Ordner unterschiedlich verwalten,
- Ordner und Dateien unterschiedlich zu verwalten,
- Schnittstellen anders als Dateien (COM1 oder /dev/ttyS0) behandeln,
- ...
>> Darfst du ja. Geb dein gottverdammtes Root-Passwort ein und du hast>> alles im Griff.>> Schon klar, aber dann muss ich ja jedem Anwender spezielle Rechte geben> nur damit die Anwendung Port 3DAh auslesen darf.
Es ist unter Linux nicht üblich, dass Anwendungen direkt auf Ports
zugreifen. Eben weil es in aller Regel (Großrechner!) noch andere
Benutzer im System gab, was sich DOS-Leute damals garnicht vorstellen
konnten. Deshalb schreibt man einen Treiber, auf den dann Programme im
Userspace zugreifen. Dadurch lassen sich Rechte an Geräten so vergeben,
wie man auch Dateirechte vergibt, denn Geräte tauchen klassischerweise
als Gerätedateien unter /dev auf.
>> Im Gegensatz zu Windows darfst du ja dann mit dem>> Rechner dann machen, was du möchtest, sogar auf höchster Ebene. Du>> kannst dir von der Konsole aus dem Userspace den Graphikspeicher>> vollschreiben und niemand wundert sich.>> Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung> Port 3DAh auslesen möchte.
Nein, du darfst das weiterhin nur als Superuser (root) oder mit
entsprechenden Rechten an den Gerätedateien. S.u.
Auch wenn man mit ioperm() aus einem Programm heraus Rechte anfordert,
erhält nur diese Instanz des Programmes diese Rechte. Wenn du das
gleiche Programm noch zehnmal startest, dabei aber keine Rechte
einforderst, dürfen die zehn anderen Instanzen nicht auf den Port
zugreifen.
>> Ja und nein. Man kann auch Rechte für einen Bereich von Registern>> einfordern.>> Was ist damit genau gemeint?
Damit ist gemeint, dass man sich nicht unbedingt eine Freikarte für alle
Ports holen muss, sondern angeben kann, welche man denn benötigt. Man
kann sich z.B. Rechte für 0x3BC und die folgenden 2 Ports besorgen und
hätte dann den ersten Parallelport im Griff.
>> Aber ja, wenn du Rechte bekommen hast, bist du auch dafür>> verantwortlich.>> Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut> sein soll, wenn ich dann eh wie unter DOS alles machen darf.
Es ist z.B. dafür da, dass nicht jeder dämliche Pufferüberlauf sofort in
eine Katastrophe mündet. Wenn unter DOS eine Anwendung durchdreht und im
Speicher herumfeuert, kann sie auch Ports treffen. Mit dem Schutzkonzept
stürzt bestenfalls die Anwendung ab, weil sie keine Schreibrechte mehr
hat.
Auch das ist wieder wichtig, damit andere Benutzer im System nicht
leiden müssen.
>> Unter DOS hast du das ja ohnehin -- gar keine Kontrolle, freie Bahn für>> alles, was irgendwie schädlich sein kann und will.>> Es geht ja mehr darum eigene Anwendungen auszuführen oder solche die> Opensource sind. Mit dieser Verantwortung kann ich bestens leben.> Von den wichtigsten eigenen Daten hat man ja eh eine Kopie und der Rest> kann immer wieder neu installieren.
Erweitere einmal deinen DOS-Horizont...
Für ein bisschen Frickeln daheim -- genau das tust du ja: verstehen, wie
die Kiste funktioniert -- ist das alles in Ordnung. Für
Mehrbenutzerbetrieb ist es aber einfach unbrauchbar. Für ein Terminal,
an dem hundert verschiedene Benutzer arbeiten, wäre das ein Super-GAU,
wenn jeder überall reinpfuschen dürfte. Auch ist der Aufwand für 'mal
eben neu installieren' Irrsinn. Schlimmstenfalls ist die Maschine eine
Stunde gar nicht mehr verfügbar -- denk mal an Server.
> Solche alten Monitore/Festplatten betreibe ich schon lange nicht mehr> und alle für mich wichtige Daten habe ich auf CD/DVD gebrannt.
Du bist aber nicht der einzige auf der Welt. Selbst Microsoft hat das
irgendwann mal erkannt und ist zurückgerudert. Auch unter Windows
findest du mittlerweile eine ausgefeilte Rechteverwaltung.
Linux ist, wie UNIX auch, ein vollwertiges Mehrbenutzer-Betriebssystem.
Es kommt deshalb auch mit einer vollwertigen Rechteverwaltung daher.
Du kannst ja alle Beschränkungen aufheben (als Superuser arbeiten,
Treiber im Kernelspace schreiben, ioperm(), iopl() und so weiter), wenn
du das brauchst. Das ist aber die absolute Ausnahme, in aller Regel
arbeiten eben nur Treiber mit erweiterten Rechten.
Klar, wenn so ein Treiber abraucht, geht das auch böse aus. Allerdings
kann nicht jeder Depp einen Treiber laden, denn dazu braucht man wieder
genügend Rechte im System. Damit ist die Auswahl an gefährlichem
Programmcode (idealerweise..) beschränkt, denn normale Benutzer können
herumschießen, so viel sie wollen -- mangels Rechte passiert nichts.
Dirk Wolfgang Glomp schrieb:>>> Dann nenne doch mal den Grund dafür warum nicht jeder Benutzer den Port>>> 3DAh einfach nur auslesen kann und warum man dafür überhaupt spezielle>>> Rechte für braucht.>> Wie viele Ausnahmen möchtest du denn noch machen?>> Überall dort wo der Schutz keinen Sinn macht.
Dann müßte man eine umfassende Datenbank aller PCs und Einsteckkarten
hinterlegen, weil es ja nicht nur die paar uralten Ports gibt, die
eigentlich nur noch aus Kompatibilitätsgründen geblieben sind. Und das
nur, damit man, statt die schon im System eingebauten Funktionen zu
verwenden, seine eigenen basteln kann, um darauf zuzugreifen?
>>> Weder ist damit die Sicherheit gefährdet, noch kann>>> jemand damit kompromierende Informationen erhalten. Ich sehe dafür>>> einfach keinen Sinn das Auslesen des Ports 3DAh zu verhindern.>> Es ist ja nicht nur Port 0x3DA, sondern es sind generell erst einmal>> alle Ports, denn niemand außer den Treibern hat da etwas verloren.>> Es macht aber keinen Sinn das Auslesen des Ports 3DAh zu verhindern.
Genausowenig, wie ihn überhaupt selbst auslesen zu wollen, wenn das
System schon bessere Mittel zur Verfügung stellt. Das ist, als ob du den
Motor unbedingt per Kurbel starten willst, obwohl es doch einen Anlasser
gibt.
Auf einem Multitasking-Betriebssystem kann man den Port ohnehin nicht
sinnvoll einsetzen.
>> Im Gegensatz zu Windows darfst du ja dann mit dem>> Rechner dann machen, was du möchtest, sogar auf höchster Ebene. Du>> kannst dir von der Konsole aus dem Userspace den Graphikspeicher>> vollschreiben und niemand wundert sich.>> Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung> Port 3DAh auslesen möchte.
Naja, diese eine Anwendung darf dann mit root-Rechten arbeiten. Da sie
Sicherheitslücken enthalten kann, ist es potenziell möglich, damit das
System zu kompromittieren. Man kann noch über entsprechende
Capability-Einstellungen dem Prozess nur die Möglichkeit geben, sich
Berechtigungen für I/O-Ports zu holen und sonst nichts.
>>> Damit ist dann vermutlich aber auch das gesamte Schutzkonzept>>> ausgehebelt. Also wenn ich unbekannte Dritte die Möglichkeit einräumen>>> möchte meine Anwendung auszuführen, dann muss die Tür so weit offen>>> stehen, nur damit ein Port 3DAh ausgelesen werden kann.>> Ja und nein. Man kann auch Rechte für einen Bereich von Registern>> einfordern.>> Was ist damit genau gemeint?
Der Funktion ioperm() übergibst du ein Startregister und eine Länge.
Danach kannst du genau auf diese Register zugreifen. Wenn der Prozess
gleich am Anfang ioperm() aufruft und danach sofort seine Rechte
abtritt, läuft er abgesehen von den angeforderten Ports ohne besondere
Berechtigungen.
>> Aber ja, wenn du Rechte bekommen hast, bist du auch dafür>> verantwortlich.>> Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut> sein soll, wenn ich dann eh wie unter DOS alles machen darf.
Dafst du ja normalerweise nicht. Nur wenn du irgendwelche speziellen
Sachen tun willst, für die du am Betriebssystem vorbei direkt auf
irgendwelche Hardware zugreifen willst, mußt du eben die entsprechenden
Rechte haben. Auch dann kann man es noch stark einschränken, aber du
hast ja explzit geschrieben, daß du alles dürfen willst. Auch das ist
eben möglich.
> Dirk Wolfgang Glomp schrieb:>> Sven P. schrieb:>>> Wie viele Ausnahmen möchtest du denn noch machen?>>>> Überall dort wo der Schutz keinen Sinn macht.> Und wenn dann eine weitere Steckkarte dazukommt, fügen wir wieder neue> Ausnahmen hinzu und wieder und wieder.
Alle Geräte die unterstütz werden sind doch eh mit diversen Geräte-Daten
registriert und können damit auch mit speziellen Ausname-Rechten
versehen werden, wenn das Auslesen wie beim Port 3DAh keine Probleme
machen kann. Wo ist das Problem?
>> Also da wäre der Port 3DAh und wohl auch die Ports 200h-208h.> S.u.>>> Es macht aber keinen Sinn das Auslesen des Ports 3DAh zu verhindern.> Es ist aber konsistent.
Konsistent ohne jeden Sinn.
> UNIX-Leute streuben sich seit jeher dagegen,> tausend Ausnahmen zu machen.
Das ist ein schwaches Agrument.
> Viele Dinge aus der DOS-Welt sind auch total sinnlos:> - Laufwerke und Ordner unterschiedlich verwalten,> - Ordner und Dateien unterschiedlich zu verwalten,> - Schnittstellen anders als Dateien (COM1 oder /dev/ttyS0) behandeln,> - ...
Wie DOS selber die Geräte verwaltet ist beinahe unerheblich, weil jeder
DOS-Anwendung steht es frei den Plattencontroller direkt mit
Portzugriffen zu steuern und mit den Daten beliebig zu verfahren. Diese
Wahlfreiheit beliebig verschiedene Konzepte bei der Verwaltung der
Geräte benutzen zu können ohne in Abhängigkeit einer Norm zu stehen
macht DOS eben einzigartig.
>>> Darfst du ja. Geb dein gottverdammtes Root-Passwort ein und du hast>>> alles im Griff.>>>> Schon klar, aber dann muss ich ja jedem Anwender spezielle Rechte geben>> nur damit die Anwendung Port 3DAh auslesen darf.> Es ist unter Linux nicht üblich, dass Anwendungen direkt auf Ports> zugreifen.
Damit sind die Anwendungen eingeschränkt.
> Eben weil es in aller Regel (Großrechner!) noch andere> Benutzer im System gab, was sich DOS-Leute damals garnicht vorstellen> konnten.
Es sind wohl mehr Benutzer als Geräte und jeder Benutzer braucht
spezielle Rechte wenn es Ausnahmen geben soll?
> Deshalb schreibt man einen Treiber, auf den dann Programme im> Userspace zugreifen. Dadurch lassen sich Rechte an Geräten so vergeben,> wie man auch Dateirechte vergibt, denn Geräte tauchen klassischerweise> als Gerätedateien unter /dev auf.
Dort könnte man auch den Port 3DAh als Gerät generell freigeben so das
kein Anwender und keine Anwendung hierbei Rechte einfordern braucht?
>>> Im Gegensatz zu Windows darfst du ja dann mit dem>>> Rechner dann machen, was du möchtest, sogar auf höchster Ebene. Du>>> kannst dir von der Konsole aus dem Userspace den Graphikspeicher>>> vollschreiben und niemand wundert sich.>>>> Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung>> Port 3DAh auslesen möchte.> Nein, du darfst das weiterhin nur als Superuser (root) oder mit> entsprechenden Rechten an den Gerätedateien. S.u.>> Auch wenn man mit ioperm() aus einem Programm heraus Rechte anfordert,> erhält nur diese Instanz des Programmes diese Rechte. Wenn du das> gleiche Programm noch zehnmal startest, dabei aber keine Rechte> einforderst, dürfen die zehn anderen Instanzen nicht auf den Port> zugreifen.
Mein Vorschlag wäre es PORT 3DAh aus dieser Rechteverwaltung
herauszunehmen und bei der Geräterwaltung diesen Port als allgemein
zugänglich zu markieren.
>>> Ja und nein. Man kann auch Rechte für einen Bereich von Registern>>> einfordern.>>>> Was ist damit genau gemeint?> Damit ist gemeint, dass man sich nicht unbedingt eine Freikarte für alle> Ports holen muss, sondern angeben kann, welche man denn benötigt. Man> kann sich z.B. Rechte für 0x3BC und die folgenden 2 Ports besorgen und> hätte dann den ersten Parallelport im Griff.
Ach so meinst du das. Ja genau hier kann man ja spezielle Portzugriffe
mit Aunahmeregeln versehen, so das diese keine weiteren Zugriffrechte
mehr brauchen.
>>> Aber ja, wenn du Rechte bekommen hast, bist du auch dafür>>> verantwortlich.>>>> Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut>> sein soll, wenn ich dann eh wie unter DOS alles machen darf.> Es ist z.B. dafür da, dass nicht jeder dämliche Pufferüberlauf sofort in> eine Katastrophe mündet. Wenn unter DOS eine Anwendung durchdreht und im> Speicher herumfeuert, kann sie auch Ports treffen. Mit dem Schutzkonzept> stürzt bestenfalls die Anwendung ab, weil sie keine Schreibrechte mehr> hat.
Der Preis dafür nur normgerechte Anwendungen ausführen zu können ist
aber extrem hoch, wenn man auf eigene Konzepte die Daten zu verwalten
damit so umfassend verzichtet.
> Auch das ist wieder wichtig, damit andere Benutzer im System nicht> leiden müssen.
Mit einer Ausnahmeregel das jeder Anwender und jede Anwendung auf Port
3DAh jederzeit zugreifen darf ohne spezille Rechte dafür einforderen zu
müssen leidet doch gar keiner wirklich.
>>> Unter DOS hast du das ja ohnehin -- gar keine Kontrolle, freie Bahn für>>> alles, was irgendwie schädlich sein kann und will.>>>> Es geht ja mehr darum eigene Anwendungen auszuführen oder solche die>> Opensource sind. Mit dieser Verantwortung kann ich bestens leben.>> Von den wichtigsten eigenen Daten hat man ja eh eine Kopie und der Rest>> kann immer wieder neu installieren.> Erweitere einmal deinen DOS-Horizont...> Für ein bisschen Frickeln daheim -- genau das tust du ja: verstehen, wie> die Kiste funktioniert -- ist das alles in Ordnung. Für> Mehrbenutzerbetrieb ist es aber einfach unbrauchbar.
Was wäre dann daran so unbrauchbar wenn jeder Anwender/Anwendung auf
Port 3DAh zugreifen darf?
> Für ein Terminal,> an dem hundert verschiedene Benutzer arbeiten, wäre das ein Super-GAU,> wenn jeder überall reinpfuschen dürfte.
Von überall war ja auch nicht die Rede, es geht ja nur um Portzugriffe
wie etwa beim Port 3DAh und damit kann eben gar kein Super-GAU ausgelöst
werden, schlimmstenfalls kann dadurch eine Anwendung eine saubere
Bildschirmausgabe hinbekommen, mehr aber auch nicht. Dein hier
beschriebenes Super-GAU-Szenario ist also gar keins.
> Auch ist der Aufwand für 'mal> eben neu installieren' Irrsinn. Schlimmstenfalls ist die Maschine eine> Stunde gar nicht mehr verfügbar -- denk mal an Server.
Auch dort ist der Zugriff auf Port 3DAh mit keiner besonderen Gefahr für
das System behaftet, falls derartige Hardware dort vorhanden ist und
eine Anwendung auf Port 3DAh zugreifen kann.
>> Solche alten Monitore/Festplatten betreibe ich schon lange nicht mehr>> und alle für mich wichtige Daten habe ich auf CD/DVD gebrannt.> Du bist aber nicht der einzige auf der Welt.
Das Auslesen von Port 3DAh bleibt auch bei beliebig vielen Anwendern
völlig gefahrlos.
> Selbst Microsoft hat das> irgendwann mal erkannt und ist zurückgerudert. Auch unter Windows> findest du mittlerweile eine ausgefeilte Rechteverwaltung.> Linux ist, wie UNIX auch, ein vollwertiges Mehrbenutzer-Betriebssystem.> Es kommt deshalb auch mit einer vollwertigen Rechteverwaltung daher.> Du kannst ja alle Beschränkungen aufheben (als Superuser arbeiten,> Treiber im Kernelspace schreiben, ioperm(), iopl() und so weiter), wenn> du das brauchst. Das ist aber die absolute Ausnahme, in aller Regel> arbeiten eben nur Treiber mit erweiterten Rechten.> Klar, wenn so ein Treiber abraucht, geht das auch böse aus. Allerdings> kann nicht jeder Depp einen Treiber laden, denn dazu braucht man wieder> genügend Rechte im System. Damit ist die Auswahl an gefährlichem> Programmcode (idealerweise..) beschränkt, denn normale Benutzer können> herumschießen, so viel sie wollen -- mangels Rechte passiert nichts.
Trotzdem bleibt es sinnlos das man für das Auslesen von Port 3DAh
spezielle Rechte braucht und der Zugriff auf solche Ports nicht
allgemein frei zugänglich ist und daran ändert der Umstand das man es
schon immer so gemacht hat auch nichts.
Dirk
Rolf Magnus schrieb:> Dirk Wolfgang Glomp schrieb:>>>> Dann nenne doch mal den Grund dafür warum nicht jeder Benutzer den Port>>>> 3DAh einfach nur auslesen kann und warum man dafür überhaupt spezielle>>>> Rechte für braucht.>>> Wie viele Ausnahmen möchtest du denn noch machen?>>>> Überall dort wo der Schutz keinen Sinn macht.>> Dann müßte man eine umfassende Datenbank aller PCs und Einsteckkarten> hinterlegen, weil es ja nicht nur die paar uralten Ports gibt, die> eigentlich nur noch aus Kompatibilitätsgründen geblieben sind.
Diese Datenbank existiert doch eh und braucht doch nur ergänzt werden.
> Und das> nur, damit man, statt die schon im System eingebauten Funktionen zu> verwenden, seine eigenen basteln kann, um darauf zuzugreifen?
Ja wenn die vom System eingebauten Funktionen eben wie beim Port 3DAh
völlig sinnlos sind wenn man dafür spezielle Rechte einfordern muss
um darauf zuzugreifen.
>>>> Weder ist damit die Sicherheit gefährdet, noch kann>>>> jemand damit kompromierende Informationen erhalten. Ich sehe dafür>>>> einfach keinen Sinn das Auslesen des Ports 3DAh zu verhindern.>>> Es ist ja nicht nur Port 0x3DA, sondern es sind generell erst einmal>>> alle Ports, denn niemand außer den Treibern hat da etwas verloren.>>>> Es macht aber keinen Sinn das Auslesen des Ports 3DAh zu verhindern.>> Genausowenig, wie ihn überhaupt selbst auslesen zu wollen, wenn das> System schon bessere Mittel zur Verfügung stellt.
Wenn eine Anwendung die Aufgabe zu 100% erfüllt wofür sie entwickelt
wurde und sie dabei auch wenig Resourcen verbraucht, dann kann man
hierbei nichts mehr besser machen, auch dann wenn mehrere Wege zum
gleichen Ziel führen.
> Das ist, als ob du den> Motor unbedingt per Kurbel starten willst, obwohl es doch einen Anlasser> gibt.
Es ist ja nicht so das es mehr Resorcen verschlingt wenn man die Kurbel
selber am Port 3DAh ansetzt.
> Auf einem Multitasking-Betriebssystem kann man den Port ohnehin nicht> sinnvoll einsetzen.
Wenn eine Anwendung damit einen saubere Ausgabe hinbekommt, dann ist es
durchaus sinnvoll.
>>> Im Gegensatz zu Windows darfst du ja dann mit dem>>> Rechner dann machen, was du möchtest, sogar auf höchster Ebene. Du>>> kannst dir von der Konsole aus dem Userspace den Graphikspeicher>>> vollschreiben und niemand wundert sich.>>>> Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung>> Port 3DAh auslesen möchte.>> Naja, diese eine Anwendung darf dann mit root-Rechten arbeiten.
Diese Anwendung muss dann mit root-Rechten arbeiten, obwohl es keinen
guten Grund dafür gibt das Auslesen von Port 3DAh zuz verhindern.
> Da sie> Sicherheitslücken enthalten kann, ist es potenziell möglich, damit das> System zu kompromittieren.
Durch das Auslesen des Ports 3DAh kann kein System kompromittiert
werden.
> Man kann noch über entsprechende> Capability-Einstellungen dem Prozess nur die Möglichkeit geben, sich> Berechtigungen für I/O-Ports zu holen und sonst nichts.
Ich betrtachte es als eine völlig unsinnige Einschränkung.
>>>> Damit ist dann vermutlich aber auch das gesamte Schutzkonzept>>>> ausgehebelt. Also wenn ich unbekannte Dritte die Möglichkeit einräumen>>>> möchte meine Anwendung auszuführen, dann muss die Tür so weit offen>>>> stehen, nur damit ein Port 3DAh ausgelesen werden kann.>>> Ja und nein. Man kann auch Rechte für einen Bereich von Registern>>> einfordern.>>>> Was ist damit genau gemeint?>> Der Funktion ioperm() übergibst du ein Startregister und eine Länge.> Danach kannst du genau auf diese Register zugreifen. Wenn der Prozess> gleich am Anfang ioperm() aufruft und danach sofort seine Rechte> abtritt, läuft er abgesehen von den angeforderten Ports ohne besondere> Berechtigungen.
Achso, ja das kenne ich zum Teil schon.
>>> Aber ja, wenn du Rechte bekommen hast, bist du auch dafür>>> verantwortlich.>>>> Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut>> sein soll, wenn ich dann eh wie unter DOS alles machen darf.>> Dafst du ja normalerweise nicht. Nur wenn du irgendwelche speziellen> Sachen tun willst, für die du am Betriebssystem vorbei direkt auf> irgendwelche Hardware zugreifen willst, mußt du eben die entsprechenden> Rechte haben. Auch dann kann man es noch stark einschränken, aber du> hast ja explzit geschrieben, daß du alles dürfen willst. Auch das ist> eben möglich.
Ok.
Dirk
Dann bleibe du bei deinem DOS, würde ich sagen, und schreib weiterhin
Wegwerf-Software.
Währenddessen verwenden wir unsere Zeit, um Treiber zu schreiben, die
sich nahtlos ins Betriebssystem integrieren und auch anderen Leuten
hilfreich sind.
Was ist für dich so schwer daran, zu begreifen, dass eine
Ausnahmen-Datenbank totaler Schwachsinn ist?
Wer soll die Pflegen?
- Die wird bald verwahrlosen und stellt selbst ein Risiko dar.
Wie groß ist die mittlerweile, inklusive sämtlicher Mess- und
Steuerkarten privater Anbieter?
- Unüberschaubar.
Was ist mit all den anderen Architekturen? Hast du eine Vorstellung
davon, wo UNIX überall zu finden ist/war?
Was ist mit Performance, wenn kilometerlange Tabellen durchsucht werden
müssen?
Was mache ich, wenn meine Karte nicht dabei ist?
- Pech gehabt oder Sicherheitsrisiko, da ich die Ausnahmen als User
selbst festlegen darf.
Was mache ich, wenn Karten die gleichen Ports benutzen?
- Pech gehabt.
Was bringt sie? Wer braucht sie?
- Niemand, denn du vertauschst Ausnahme und Regel.
Wenn 99% aller Programme sich nicht um Ports kümmern und die restlichen
1% Treiber sind, dann ist es mehr als sinnvoll, erst alle Zugriffe zu
sperren und dann dediziert freizugeben.
Wenn du weiter auf deinem Dinosaurier herumreiten möchtest, hindert dich
niemand daran. Aber deshalb sind nicht alle anderen Konzepte, die sich
seit 30 Jahren gehalten haben, schlecht und unflexibel.
Eher im Gegenteil: An die Frickelei und Ausnahmensammlung und
Inkonsistenz, die DOS verkörpert, kommt fast kein anderes Betriebssystem
heran.
<°))3DAh)))><
Sven P. schrieb:> Dann bleibe du bei deinem DOS,
Es ist auch möglich ganz ohne ein OS eine Anwendung zu starten.
> würde ich sagen, und schreib weiterhin> Wegwerf-Software.
Nur weil man keine finanziellen Absichten vefolgt und nur zum Lernen und
aus Spaß programmiert ist eine solche Freeware-Software nicht weniger
wertvoll.
> Währenddessen verwenden wir unsere Zeit, um Treiber zu schreiben, die> sich nahtlos ins Betriebssystem integrieren und auch anderen Leuten> hilfreich sind.
Wenn dir es Spaß macht unter den strengen Regeln eines OS dich
programmtechnisch einzuschränken, dann habe ich nichts dagegen. Ich
dagegen schätze es mehr wenn man sich frei von den starren Regeln eines
OS entfalten kann und ich habe auch keine besondere Lust wegen diverser
Sicherheitsbedenken aus der Wirtschaft mich privat einzuschränken.
Ich habe es weder vor irgendeine Schadsoftware auf einem fremden Rechner
einzuschleusen, noch bin ich als Opfer interessant genug um ein Ziel
eines solchen Angriffes zu werden.
> Was ist für dich so schwer daran, zu begreifen, dass eine> Ausnahmen-Datenbank totaler Schwachsinn ist?
Der Sinn besteht darin das dann jede Anwendung auch ohne spezielle
Rechte auf einen Port wie z.B. 3DAh zugreifen kann und In der
Geräte-Datenbank die eh schon existiert wird ja wohl noch ein Platz für
ein einzelnes Bit dafür übrig sein.
> Wer soll die Pflegen?
All jene die jetzt auch die Gerätedatenbank pflegen.
> - Die wird bald verwahrlosen
Warum sollte die Gerätedatenbank verwahrlosen nur weil dort ein
zusätzliches Bit verwaltet wird?
> und stellt selbst ein Risiko dar.
Das Risiko wird dadurch auch nicht so viel höher und der Aufawang erhöht
sich dadurch doch auch nur marginal.
> Wie groß ist die mittlerweile, inklusive sämtlicher Mess- und> Steuerkarten privater Anbieter?> - Unüberschaubar.
Trotzdem müssen diese Geräte ja in das System eingebunden werden und
dabei ist dann der Aufwand eines zusätzliches Bits dann ja wohl keine
besondere Hürde.
> Was ist mit all den anderen Architekturen? Hast du eine Vorstellung> davon, wo UNIX überall zu finden ist/war?
Solche anderen Architekturen die ich nicht verwende interessieren mich
daher auch sehr wenig.
> Was ist mit Performance, wenn kilometerlange Tabellen durchsucht werden> müssen?
Diese Aufgabe kann man getrost dem jeweiligen Gerätetriber überlassen,
der seine Gräte ja bestens kennt und dem man ja eh vertraut wenn man ihn
in das System einbindet.
> Was mache ich, wenn meine Karte nicht dabei ist?
Ohne Gerätetreiber werden solche Geräte doch eh nicht unterstützt.
> - Pech gehabt oder Sicherheitsrisiko, da ich die Ausnahmen als User> selbst festlegen darf.
Wer Gerätetreiber in ein System einbinden darf hat dann auch die nötigen
Rechte dazu.
> Was mache ich, wenn Karten die gleichen Ports benutzen?> - Pech gehabt.
Port sharing?
> Was bringt sie? Wer braucht sie?> - Niemand, denn du vertauschst Ausnahme und Regel.
Ich habe mich nur aus dieser verbreiteten engen Sichtweise etwas befreit
und ja wenn ich den Port 3DAh abfragen möchte, dann brauche ich das
auch.
> Wenn 99% aller Programme sich nicht um Ports kümmern und die restlichen> 1% Treiber sind, dann ist es mehr als sinnvoll, erst alle Zugriffe zu> sperren und dann dediziert freizugeben.
Jetzt tue doch nicht so als wenn eine Quantität etwas über die Qualität
aussagen könnte. Vergleichbar mit: Eine milliarde Fliegen können sich ja
nicht täuschen, Fäkalien schmecken gut.
> Wenn du weiter auf deinem Dinosaurier herumreiten möchtest, hindert dich> niemand daran.
Daneben habe ich auch die Vorzüge davon aufgezeigt, das man sich dann
programmtechnisch frei entfalten kann und sich eben nicht mit bereits
vorgekauten Speisen und ausgetrampelten Pfaden zufrieden geben muss.
Zieleort und Heimathafen sind dann frei wählbar und nich nur jene mit
schon fertig spezifizierten Containerterminals.
> Aber deshalb sind nicht alle anderen Konzepte, die sich> seit 30 Jahren gehalten haben, schlecht und unflexibel.
Das ein Bedarf an DOS und DOS-Programierung vorhanden ist, das zeigt ja
auch schon der Umstand das FreeDOS entwickelt wurde.
> Eher im Gegenteil: An die Frickelei und Ausnahmensammlung und> Inkonsistenz, die DOS verkörpert, kommt fast kein anderes Betriebssystem> heran.
Was du hier als Inkonsistenz deklarierst ist die freie
Entscheidungsmöglichkeit und die Vielfalt mit dem ein gut erzogener
Konsument möglicherweise nichts mehr anfangen kann, wenn er schon zu
lange nur sein Fertigbrei aus der Konserve bekommen hat und er auch
nicht mehr weiss wie man sich selber ein schmackhaftes Gericht ein
eigener Kraft zubereitet. Das ist doch eher ein Armutszeugniss als ein
Privileg.
Es ist ja nicht so das mir solche Dinge völlig fremd sind, aber ich bin
immer noch bemüht mir mein eigenes Urteil zu bilden und die Eckpunkte
aus verschiedenen Blickwinkel heraus selber zu beurteilen.
Wenn für dich der Anbau von etwas Gemüse und das Zubereiten eigener
Speisen nur zum wegwerfen ist, dann hast du dich aber schon enorm an die
Essgewohnheiten der Allgemeinheit angepasst und verzichtest eben auf
eine enorme Bandbreite an Geschmack, der in dieser Fülle nicht in ein
finanzielles Raster passt um damit auch noch Gewinne zu erzielen.
Dirk
Dirk Wolfgang Glomp schrieb:>> Und das>> nur, damit man, statt die schon im System eingebauten Funktionen zu>> verwenden, seine eigenen basteln kann, um darauf zuzugreifen?>> Ja wenn die vom System eingebauten Funktionen eben wie beim Port 3DAh> völlig sinnlos sind wenn man dafür spezielle Rechte einfordern muss> um darauf zuzugreifen.
Um die Funktion zu nutzen, braucht man gar keinen direkten Zugriff auf
den Port und daher auch keine speziellen Rechte. Und da das für so
ziemlich jeden Port gilt, sieht auch keiner eine Notwendigkeit, sich die
Mühe zu machen, eine Ausnahmen-Datenbank einzuführen.
>>> Es macht aber keinen Sinn das Auslesen des Ports 3DAh zu verhindern.>>>> Genausowenig, wie ihn überhaupt selbst auslesen zu wollen, wenn das>> System schon bessere Mittel zur Verfügung stellt.>> Wenn eine Anwendung die Aufgabe zu 100% erfüllt wofür sie entwickelt> wurde und sie dabei auch wenig Resourcen verbraucht, dann kann man> hierbei nichts mehr besser machen, auch dann wenn mehrere Wege zum> gleichen Ziel führen.
Das ist aber der Punkt. Die Verwendung des Port 3DAh ist sehr
ressourcenfressend. Unter DOS macht dir das halt nix aus, weil du eh
alleine auf dem Prozessor wütest.
>> Das ist, als ob du den>> Motor unbedingt per Kurbel starten willst, obwohl es doch einen Anlasser>> gibt.>> Es ist ja nicht so das es mehr Resorcen verschlingt wenn man die Kurbel> selber am Port 3DAh ansetzt.
Doch, ist es.
>> Da sie Sicherheitslücken enthalten kann, ist es potenziell möglich,>> damit das System zu kompromittieren.>> Durch das Auslesen des Ports 3DAh kann kein System kompromittiert> werden.
Nein, aber durch Sicherheitslücken, wie ich ja schon schrieb. Du hattest
allerdings geschrieben, daß du alles dürfen willst.
>> Man kann noch über entsprechende>> Capability-Einstellungen dem Prozess nur die Möglichkeit geben, sich>> Berechtigungen für I/O-Ports zu holen und sonst nichts.>> Ich betrtachte es als eine völlig unsinnige Einschränkung.
Ja was denn nun? Zuerst willst du volle Freiheit haben, dann beschwerst
du dich, daß du dann ja alles darfst und damit das Sicherheitssystem
umgangen wird. Wenn man dir sagt, daß es auch Möglichkeiten gibt, nur
gezielt ganz bestimmte einzelne Sachen freizuschalten, findest du das
dann wieder völlig unsinnig. Entscheide dich mal!
Dirk Wolfgang Glomp schrieb:> Wenn dir es Spaß macht unter den strengen Regeln eines OS dich> programmtechnisch einzuschränken, dann habe ich nichts dagegen.
Mir macht es Spaß, die ganzen zusätzlichen Funktionen zu nutzen, die mir
ein OS bietet und freue mich über die gewonnene Flexibilität und den
verrigerten Aufwand dadurch, daß ich das System für mich arbeiten lassen
kann, statt jeden Mist selbst machen zu müssen. Und ich freue mich
darüber, daß mein Programm auch ohne Änderung auf dem billigen
ARM-Netbook läuft.
>> Was ist für dich so schwer daran, zu begreifen, dass eine>> Ausnahmen-Datenbank totaler Schwachsinn ist?>> Der Sinn besteht darin das dann jede Anwendung auch ohne spezielle> Rechte auf einen Port wie z.B. 3DAh zugreifen kann und In der> Geräte-Datenbank die eh schon existiert wird ja wohl noch ein Platz für> ein einzelnes Bit dafür übrig sein.
Wo soll so eine Datenbank existieren?
>> Wie groß ist die mittlerweile, inklusive sämtlicher Mess- und>> Steuerkarten privater Anbieter?>> - Unüberschaubar.>> Trotzdem müssen diese Geräte ja in das System eingebunden werden und> dabei ist dann der Aufwand eines zusätzliches Bits dann ja wohl keine> besondere Hürde.
Was denn jetzt? Willst du direkt auf die Ports zugreifen oder einen
Treiber nutzen? Beides gleichzeitig ist wohl ziemlich sinnlos.
>> Was ist mit all den anderen Architekturen? Hast du eine Vorstellung>> davon, wo UNIX überall zu finden ist/war?>> Solche anderen Architekturen die ich nicht verwende interessieren mich> daher auch sehr wenig.
Tja, und die meisten Entwickler von Linux interessieren sich nicht so
sehr dafür, ob jemand Programme schreiben will, die ohne sinnvollen
Grund durch direkte Portzugriffe auf eine einzelne Hardwareplattform
eingeschränkt werden.
>> Was bringt sie? Wer braucht sie?>> - Niemand, denn du vertauschst Ausnahme und Regel.>> Ich habe mich nur aus dieser verbreiteten engen Sichtweise etwas befreit> und ja wenn ich den Port 3DAh abfragen möchte, dann brauche ich das> auch.
Meines Erachtens hast du ganz im Gegenteil deine Sichtweise stark
eingeengt, was natürlich dein Recht ist. Was Sven dir damit sagen
wollte, war, daß du die Ausnahme bist und nicht die Regel. Alle anderen
brauchen die von dir gewünschte Funktionalität nicht, und deshalb ist
nicht anzunehmen, daß sich jemand die Mühe macht, sie einzubauen.
> Jetzt tue doch nicht so als wenn eine Quantität etwas über die Qualität> aussagen könnte. Vergleichbar mit: Eine milliarde Fliegen können sich ja> nicht täuschen, Fäkalien schmecken gut.
Mir fällt da eher der Spruch ein: "Auf der A8 Richtung Singen ist ein
Falschfahrer unterwegs" - "Einer? Hunderte!"
>> Wenn du weiter auf deinem Dinosaurier herumreiten möchtest, hindert dich>> niemand daran.>> Daneben habe ich auch die Vorzüge davon aufgezeigt, das man sich dann> programmtechnisch frei entfalten kann und sich eben nicht mit bereits> vorgekauten Speisen und ausgetrampelten Pfaden zufrieden geben muss.
Ich bevorzuge es, bequem mit meinem Auto auf einer gut ausgebauten
Straße zu fahren, statt erst mit Säge und Machete einen Weg durchs
Gebüsch freischlagen zu müssen, um dann auf dem Dino quer durch die
Pampa geschüttelt zu werden.
>> Aber deshalb sind nicht alle anderen Konzepte, die sich>> seit 30 Jahren gehalten haben, schlecht und unflexibel.>> Das ein Bedarf an DOS und DOS-Programierung vorhanden ist, das zeigt ja> auch schon der Umstand das FreeDOS entwickelt wurde.
Die Entwicklung begann vor 16 Jahren. Ich habe bisher FreeDOS nur zum
Einsatz von Firmware-/BIOS-Upgradern gesehen.
>> Eher im Gegenteil: An die Frickelei und Ausnahmensammlung und>> Inkonsistenz, die DOS verkörpert, kommt fast kein anderes Betriebssystem>> heran.>> Was du hier als Inkonsistenz deklarierst ist die freie> Entscheidungsmöglichkeit und die Vielfalt mit dem ein gut erzogener> Konsument möglicherweise nichts mehr anfangen kann, wenn er schon zu> lange nur sein Fertigbrei aus der Konserve bekommen hat und er auch> nicht mehr weiss wie man sich selber ein schmackhaftes Gericht ein> eigener Kraft zubereitet. Das ist doch eher ein Armutszeugniss als ein> Privileg.>> Es ist ja nicht so das mir solche Dinge völlig fremd sind, aber ich bin> immer noch bemüht mir mein eigenes Urteil zu bilden und die Eckpunkte> aus verschiedenen Blickwinkel heraus selber zu beurteilen.
Und nur, weil andere nicht deine Meinung sind, streitest du denen die
Fähigkeit ab, das auch zu können?
> Wenn für dich der Anbau von etwas Gemüse und das Zubereiten eigener> Speisen nur zum wegwerfen ist, dann hast du dich aber schon enorm an die> Essgewohnheiten der Allgemeinheit angepasst und verzichtest eben auf> eine enorme Bandbreite an Geschmack, der in dieser Fülle nicht in ein> finanzielles Raster passt um damit auch noch Gewinne zu erzielen.
Du kaust alles Roh, weil du das Feuer noch nicht entdeckt hast.
Jungs. Lasst es gut sein.
Das letzte mal, als über die Notwendigkeit von Betriebssystemen und die
damit verbundene Aufgabe von scheinbaren 'Programmierer-Rechten'
gestritten wurde, schrieb man das Jahr 1965 (oder so). Seither hat sich
viel getan und es ist eigentlich weitgehend akzeptiert worden, das
Anarchie in einem Computer genausowenig funktioniert, wie sie im realen
Leben funktioniert.
Für geordnetes, gesichertes Ablaufen von Dingen in einem Computer muss
man eben ein klein wenig Freiheit aufgeben und nach den Regeln spielen.
Das muss man überall im Leben. Auch wenn viele es nicht wahr haben
wollen: Eine rote Ampel gilt auch nachst um 3 Uhr, wenn ausser dir kein
Mensch auf der Strasse ist.
Entweder das BS hat die Oberhoheit, oder es hat das nicht.
DOS ist da ein Sonderfall, indem es zwar Regeln gab, sich viele aber
immer wieder darüber hinweggesetzt haben. Wer in der DOS-Zeit
industriell programmieren musst, weiß ein Lied davon zu singen, wieviel
Zeit und Mühe es immer wieder gekostet hat, all die kleinen 'cleveren
Hacks' von 'Ich bin so toll - Programmierern' zu identifizieren und nach
Möglichkeit abzustellen, die einem das Leben schwer machten. Denn: Den
Kunden interessierte das nicht, ob da wieder mal ein Plotter-Treiber
sich mit dem EGA-Treiber bekriegte und ein Terminate-Stay-Resident
Programm die IRQ Vektoren verbogen hatte. Das Ding musste laufen - und
du musstest das ausbaden und Wege finden, dem Programm die Seriell-Karte
unterjubeln die zwar an einer ganz anderen I/O Adresse als normal lag,
aber der 'Ich bin so toll - Programmierer' hat wieder mal auf alles
gepfiffen und die I/O Adresse hartcodiert. Und so stehst du jetzt da mit
einer Hardware, 90% der Software (die nach den Regeln programmiert
wurde) funktioniert anstandslos damit. Nur ausgerechnet das Programm das
der Kunde haben will, funktioniert natürlich wieder mal nicht, weil es
ja die Hacker-Ehre des Programmierers nicht zugelassen hat, nach den
Regeln zu spielen. Ich kann mich noch gut daran erinnern wie das war als
man in vielen Programmen beim Drucker nur Seriel/Parallel einstellen
konnte aber zb keinen Com-Port. Als dann die ersten Mäuse (ebenfalls an
der Seriellen) aufkamen - oh da war was los! Das war ein Jonglieren, bis
man alle unter einem Hut hatte.
Been there - done that
Und ich bin nicht der einzige, der in solchen Situationen aus dem
Fluchen und Schimpfen auf diese A...löcher nicht mehr herausgekommen
ist.
Was bin ich froh, dass diese Zeit vorbei ist, und endlich
Betriebssysteme 'Njet' sagen.
Irgendwie erinnert mich die Diskussion an die ewig gleiche Diskussion
"Hochsprache - Assembler". Meine Meinung dazu kennt ihr ja.
Dirk Wolfgang Glomp schrieb:> Nur weil man keine finanziellen Absichten vefolgt und nur zum Lernen und> aus Spaß programmiert ist eine solche Freeware-Software nicht weniger> wertvoll.
Bestreitet ja auch niemand. Aber die Software, die du in deiner Art
produzierst, ist weitestgehend Wegwerf-Software, weil du dich völlig
unnötig an deinen x86-Dino betonierst.
> Wenn dir es Spaß macht unter den strengen Regeln eines OS dich> programmtechnisch einzuschränken, dann habe ich nichts dagegen.> [...]
Ganz im Gegenteil: Ich öffne mich viel weiter, als du. Indem ich mich
z.B. an POSIX halte oder auf etablierte und abstrakte Schnittstellen
setze, läuft meine Software nahezu ohne Änderung auf einer vielzahl von
Plattformen, während du bei jedem Umzug wieder in deine Bitfrickelei
eintauchen musst.
Es ist mir doch egal, wie ich eine Linie auf den Bildschirm bekomme.
Ich formuliere, dass ich eine Linie malen möchte, den Rest vertraue
ich z.B. dem Treiber an.
Natürlich, zu Lernzwecken frickele ich auch gerne herum. Aber dabei löse
ich mich von dem Anspruch, 'brauchbare' Software zu schrebein, denn das
tue ich dabei ganz und garnicht.
> [...]> Solche anderen Architekturen die ich nicht verwende interessieren mich> daher auch sehr wenig.
Siehe Wegwerf-Software.
>> Was ist mit Performance, wenn kilometerlange Tabellen durchsucht werden>> müssen?>> Diese Aufgabe kann man getrost dem jeweiligen Gerätetriber überlassen,> der seine Gräte ja bestens kennt und dem man ja eh vertraut wenn man ihn> in das System einbindet.
Welchem denn? Du wolltest doch direkt an den Ports fummeln, ohne
Treiber!
>> - Pech gehabt oder Sicherheitsrisiko, da ich die Ausnahmen als User>> selbst festlegen darf.>> Wer Gerätetreiber in ein System einbinden darf hat dann auch die nötigen> Rechte dazu.
Er macht es aber nur einmal, danach kann er die Rechte wieder abtreten.
>> Wenn 99% aller Programme sich nicht um Ports kümmern und die restlichen>> 1% Treiber sind, dann ist es mehr als sinnvoll, erst alle Zugriffe zu>> sperren und dann dediziert freizugeben.>> Jetzt tue doch nicht so als wenn eine Quantität etwas über die Qualität> aussagen könnte. Vergleichbar mit: Eine milliarde Fliegen können sich ja> nicht täuschen, Fäkalien schmecken gut.
Tu ich auch nicht. Es ist aber technologisch einfach sinnvoller und
effizienter, für 99% der Programme eine einheitliche Regel ('verboten')
einzubauen und die Ausnahmen für den Rest festzulegen, als für 99% der
Programme gezielte Ausnahmen zu verbauen.
>> Wenn du weiter auf deinem Dinosaurier herumreiten möchtest, hindert dich>> niemand daran.>> Daneben habe ich auch die Vorzüge davon aufgezeigt, das man sich dann> programmtechnisch frei entfalten kann und sich eben nicht mit bereits> vorgekauten Speisen und ausgetrampelten Pfaden zufrieden geben muss.
Und das sagst du, der du auf einer Architektur herumreitest, die man vor
zehn Jahren bereits hätte ausmustern sollen? Neue Pfade beschreite ich,
wenn ich meine Programme mit wenigen Änderungen auf den ARM bringe, oder
sogar auf den AVR.
Selbst als ich mich noch mit DOS herumschlagen musste, gab es schon
Treiber. Für GBIB-Karten habe ich schon nicht mehr an Registern
herumgefrickelt, sondern ein abstraktes API benutzt. Dadurch konnte ich
die Steuersoftware später problemlos von DOS auf Win2000 katapultieren.
Klar, den Original-Treiber gabs nicht mehr. Ein paar Funktionen des
neuen Treibers hatten anderen Namen bekommen, einige verhielten sich
anders oder fehlten. Gut, die habe ich ersetzt und die Sache lief
wieder.
Was machst du denn, wenn du umziehen musst?
Nun habe ich fertig und keine Lust mehr. Du weißt ja offenbar, wie toll
DOS ist...
Rolf Magnus schrieb:> Dirk Wolfgang Glomp schrieb:>> Wenn eine Anwendung die Aufgabe zu 100% erfüllt wofür sie entwickelt>> wurde und sie dabei auch wenig Resourcen verbraucht, dann kann man>> hierbei nichts mehr besser machen, auch dann wenn mehrere Wege zum>> gleichen Ziel führen.>> Das ist aber der Punkt. Die Verwendung des Port 3DAh ist sehr> ressourcenfressend.
Im Vergleich wozu genau ist es mehr ressourcenfressend?
>>> Man kann noch über entsprechende>>> Capability-Einstellungen dem Prozess nur die Möglichkeit geben, sich>>> Berechtigungen für I/O-Ports zu holen und sonst nichts.>>>> Ich betrtachte es als eine völlig unsinnige Einschränkung.>> Ja was denn nun?
Ich finde es unsinnig das Port 3DAh nur mit speziellen Rechten verwendet
werden kann.
> Zuerst willst du volle Freiheit haben, dann beschwerst> du dich, daß du dann ja alles darfst und damit das Sicherheitssystem> umgangen wird.
Das hast du missverstanden, ich habe mich nicht darüber beschwert wenn
ich alles machen darf und einen so hohen Sicherheitsbedarf habe ich
persöhnlich doch auch nicht.
> Wenn man dir sagt, daß es auch Möglichkeiten gibt, nur> gezielt ganz bestimmte einzelne Sachen freizuschalten, findest du das> dann wieder völlig unsinnig. Entscheide dich mal!
Ich finde halt das gesamte Sicherheitssystem für mich völlig
übertreiben.
>>> Was ist für dich so schwer daran, zu begreifen, dass eine>>> Ausnahmen-Datenbank totaler Schwachsinn ist?>>>> Der Sinn besteht darin das dann jede Anwendung auch ohne spezielle>> Rechte auf einen Port wie z.B. 3DAh zugreifen kann und In der>> Geräte-Datenbank die eh schon existiert wird ja wohl noch ein Platz für>> ein einzelnes Bit dafür übrig sein.>> Wo soll so eine Datenbank existieren?
Bei den Installationsdaten?
>>> Wie groß ist die mittlerweile, inklusive sämtlicher Mess- und>>> Steuerkarten privater Anbieter?>>> - Unüberschaubar.>>>> Trotzdem müssen diese Geräte ja in das System eingebunden werden und>> dabei ist dann der Aufwand eines zusätzliches Bits dann ja wohl keine>> besondere Hürde.>> Was denn jetzt? Willst du direkt auf die Ports zugreifen oder einen> Treiber nutzen? Beides gleichzeitig ist wohl ziemlich sinnlos.
Was soll daran sinnlos sein, wenn man das eine Mal den Treiber benutzen
möchte und ein anderes Mal den Port (von gleichzeitig war doch gar nicht
die Rede)?
>>> Was bringt sie? Wer braucht sie?>>> - Niemand, denn du vertauschst Ausnahme und Regel.>>>> Ich habe mich nur aus dieser verbreiteten engen Sichtweise etwas befreit>> und ja wenn ich den Port 3DAh abfragen möchte, dann brauche ich das>> auch.>> Meines Erachtens hast du ganz im Gegenteil deine Sichtweise stark> eingeengt, was natürlich dein Recht ist.
In dem ich mir dir Freiheit bewahren möchte auf die Hardware selber
zugreifen zu dürfen enge ich damit auf welche Weise meine Sichtweise
denn ein?
> Was Sven dir damit sagen> wollte, war, daß du die Ausnahme bist und nicht die Regel.
Das ist mir nicht neu.
> Alle anderen> brauchen die von dir gewünschte Funktionalität nicht, und deshalb ist> nicht anzunehmen, daß sich jemand die Mühe macht, sie einzubauen.
Es gibt immer noch DOS-Programmierer, somit ist deine Angabe das alle
anderen diese Funktionalität nicht mehr wünschen definitiv falsch.
>>> Wenn du weiter auf deinem Dinosaurier herumreiten möchtest, hindert dich>>> niemand daran.>>>> Daneben habe ich auch die Vorzüge davon aufgezeigt, das man sich dann>> programmtechnisch frei entfalten kann und sich eben nicht mit bereits>> vorgekauten Speisen und ausgetrampelten Pfaden zufrieden geben muss.>> Ich bevorzuge es, bequem mit meinem Auto auf einer gut ausgebauten> Straße zu fahren, statt erst mit Säge und Machete einen Weg durchs> Gebüsch freischlagen zu müssen, um dann auf dem Dino quer durch die> Pampa geschüttelt zu werden.
Mit DOS ist man ja auch kein Fussgänger, dann wohl eher ein Autobastler.
Und na klar macht es nicht nur mir einen riesigen Spaß solche Oldies auf
der Landstrasse zu fahren.
>>> Aber deshalb sind nicht alle anderen Konzepte, die sich>>> seit 30 Jahren gehalten haben, schlecht und unflexibel.>>>> Das ein Bedarf an DOS und DOS-Programierung vorhanden ist, das zeigt ja>> auch schon der Umstand das FreeDOS entwickelt wurde.>> Die Entwicklung begann vor 16 Jahren. Ich habe bisher FreeDOS nur zum> Einsatz von Firmware-/BIOS-Upgradern gesehen.
Aaaach, noch vor wenigen Sätzen hast du behauptet das alle anderen so
eine Funktionalität gar nich mehr wünschen. Ich gebe die Frage zurück:
Was denn nun, kannst du dich mal entscheiden?
>>> Eher im Gegenteil: An die Frickelei und Ausnahmensammlung und>>> Inkonsistenz, die DOS verkörpert, kommt fast kein anderes Betriebssystem>>> heran.>>>> Was du hier als Inkonsistenz deklarierst ist die freie>> Entscheidungsmöglichkeit und die Vielfalt mit dem ein gut erzogener>> Konsument möglicherweise nichts mehr anfangen kann, wenn er schon zu>> lange nur sein Fertigbrei aus der Konserve bekommen hat und er auch>> nicht mehr weiss wie man sich selber ein schmackhaftes Gericht ein>> eigener Kraft zubereitet. Das ist doch eher ein Armutszeugniss als ein>> Privileg.>>>> Es ist ja nicht so das mir solche Dinge völlig fremd sind, aber ich bin>> immer noch bemüht mir mein eigenes Urteil zu bilden und die Eckpunkte>> aus verschiedenen Blickwinkel heraus selber zu beurteilen.>> Und nur, weil andere nicht deine Meinung sind, streitest du denen die> Fähigkeit ab, das auch zu können?>>> Wenn für dich der Anbau von etwas Gemüse und das Zubereiten eigener>> Speisen nur zum wegwerfen ist, dann hast du dich aber schon enorm an die>> Essgewohnheiten der Allgemeinheit angepasst und verzichtest eben auf>> eine enorme Bandbreite an Geschmack, der in dieser Fülle nicht in ein>> finanzielles Raster passt um damit auch noch Gewinne zu erzielen.>> Du kaust alles Roh, weil du das Feuer noch nicht entdeckt hast.
Manche Dinge schmecken mir ungekocht aber am besten und das DOS-Feuer
kann sogar notfalls so hoch entflammen und selber in den PM schalten um
ganze Wildschweine damit zu braten. Tja, wer nur fertige Grills aus dem
Katalog benutzt, der kann es damit nur schwer lernen wie man sich seine
eigenen Feuerstelle einrichtet. Das ist vermutlich wohl auch der Grund
dafür, warum sehr viele Windows/Unix-Programmieren den Unterschied
zwischen dem 32bit-Mode und den 16bit-mode nicht richtig verstanden
haben und so viel Nonsens darüber verbreitet wird.
Dirk
Karl heinz Buchegger schrieb:> Jungs. Lasst es gut sein.>> Das letzte mal, als über die Notwendigkeit von Betriebssystemen und die> damit verbundene Aufgabe von scheinbaren 'Programmierer-Rechten'> gestritten wurde, schrieb man das Jahr 1965 (oder so). Seither hat sich> viel getan und es ist eigentlich weitgehend akzeptiert worden, das> Anarchie in einem Computer genausowenig funktioniert, wie sie im realen> Leben funktioniert.
Was heist denn hier Anarchie, ich bin an meinem Rechner der Diktator.
> Für geordnetes, gesichertes Ablaufen von Dingen in einem Computer muss> man eben ein klein wenig Freiheit aufgeben und nach den Regeln spielen.
Nö, das muss ich nicht. Ich nehme mir das Recht mit meinen Computer
alles zu machen was im Rahmen der Gesetze erlaubt ist.
> Das muss man überall im Leben.
Auch das stimmt nicht, denn über rein private Dinge entscheide ich ganz
alleine.
> Auch wenn viele es nicht wahr haben> wollen: Eine rote Ampel gilt auch nachst um 3 Uhr, wenn ausser dir kein> Mensch auf der Strasse ist.
Es geht mir ja hiebei nicht so sehr um Verhaltensregeln im öffentlichen
Raum und/oder das eine gewisse Notwendigkeit besteht eine Übereinkunft
zu finden wie man sich in der Öffentlichkeit zu verhalten hat. Aber auch
eine Kritik über unsere Solidargemeinschaft muss erlaubt sein und soll
dazu dienen einen Weg zu finden um unser gemeinsames Zusammenleben zu
harmonisieren und menschlicher zu gestalten. In diesem Sinne ist es auch
erforderlich für individuelle Rechte zu kämpfen um demokratische
Verhältnisse nicht nur zu etablieren, sondern auch sicher zu stellen
das sie erhalten bleiben. Eine Portion Konfliktbereitschaft gehört ganz
bestimmt auch dazu.
> Entweder das BS hat die Oberhoheit, oder es hat das nicht.
Bei mir im privaten Umfeld versuche ich natürlich die Oberhoheit zu
behalten.
> DOS ist da ein Sonderfall, indem es zwar Regeln gab, sich viele aber> immer wieder darüber hinweggesetzt haben.
Dafür kann es verschiedene Gründe geben. Entweder waren die Regeln nicht
gut, oder viele waren noch nicht reif genug dafür den Sinn der Regel zu
verstehen, oder beides, oder der Gesellschaftliche Rahmen rundherum
passte nicht zu den Regeln.
> Wer in der DOS-Zeit> industriell programmieren musst, weiß ein Lied davon zu singen, wieviel> Zeit und Mühe es immer wieder gekostet hat, all die kleinen 'cleveren> Hacks' von 'Ich bin so toll - Programmierern' zu identifizieren und nach> Möglichkeit abzustellen, die einem das Leben schwer machten. Denn: Den> Kunden interessierte das nicht, ob da wieder mal ein Plotter-Treiber> sich mit dem EGA-Treiber bekriegte und ein Terminate-Stay-Resident> Programm die IRQ Vektoren verbogen hatte. Das Ding musste laufen - und> du musstest das ausbaden und Wege finden, dem Programm die Seriell-Karte> unterjubeln die zwar an einer ganz anderen I/O Adresse als normal lag,> aber der 'Ich bin so toll - Programmierer' hat wieder mal auf alles> gepfiffen und die I/O Adresse hartcodiert.
Solche Probleme sind mir auch bekannt. Trotzdem halte ich es für besser
das alle Menschen Fehler machen können, denn nur so können sie es lernen
verantwortungsvoll miteinander umzugehen. Im anderen Fall bleiben sie
auf jeden Fall unreif und verlernen es vollständig selbständig die
Verantwortung für ihr Handeln zu übernehmen. So bin ich auch kein Freund
von zu vielen Gesetzen und überbordernden Bestimmungen und betrachte die
Strafjustiz als ein völliges Versagen unserer Solidargemeinschaft.
> Und so stehst du jetzt da mit> einer Hardware, 90% der Software (die nach den Regeln programmiert> wurde) funktioniert anstandslos damit. Nur ausgerechnet das Programm das> der Kunde haben will, funktioniert natürlich wieder mal nicht, weil es> ja die Hacker-Ehre des Programmierers nicht zugelassen hat, nach den> Regeln zu spielen. Ich kann mich noch gut daran erinnern wie das war als> man in vielen Programmen beim Drucker nur Seriel/Parallel einstellen> konnte aber zb keinen Com-Port. Als dann die ersten Mäuse (ebenfalls an> der Seriellen) aufkamen - oh da war was los! Das war ein Jonglieren, bis> man alle unter einem Hut hatte.>> Been there - done that
Ja das war schon ein buntes Treiben.
> Und ich bin nicht der einzige, der in solchen Situationen aus dem> Fluchen und Schimpfen auf diese A...löcher nicht mehr herausgekommen> ist.
Ich verstehe diese Situation sehr gut. Doch wie ist man mit diesem
Problem umgegangen, wurden die Ursachen der Bewegründe mit dem
Verschliessen etwa behoben?-> NEIN. Es hat sich nur auf andere Bereiche
verlagert und genau das passiert immer wenn man nur die Symptome
versucht zu untersdrücken, aber die eigentlichen Ursachen nicht
behandeln möchte. Sicherlich ist ein enormer Kraftaufwand dafür nötig
solche Krankheiten zu kurieren. Doch mit einer Symptomunterdrückung wird
man das Grundübel so nie los.
> Was bin ich froh, dass diese Zeit vorbei ist, und endlich> Betriebssysteme 'Njet' sagen.
Diese Zeit ist leider immer noch gar nicht wirklich vorbei, es zeigen
sich nur andere Symptome der selben Krankheit.
> Irgendwie erinnert mich die Diskussion an die ewig gleiche Diskussion> "Hochsprache - Assembler". Meine Meinung dazu kennt ihr ja.
Betov <http://rosasm.org>; :
"The price of freedom, so to say, and one of the reasons i am
used to say that Assembly is an anarchist Language, whereas
C (typicaly) is a fascist Language."
Dirk
Sven P. schrieb:> Dirk Wolfgang Glomp schrieb:>> Nur weil man keine finanziellen Absichten vefolgt und nur zum Lernen und>> aus Spaß programmiert ist eine solche Freeware-Software nicht weniger>> wertvoll.> Bestreitet ja auch niemand. Aber die Software, die du in deiner Art> produzierst, ist weitestgehend Wegwerf-Software, weil du dich völlig> unnötig an deinen x86-Dino betonierst.
Ich würde sie dann eher als Lernsoftware bezeichnen und der Sinn liegt
darin zu lernen und das Lernen würde ich niemals als unnötig bezeichnen.
>> Wenn dir es Spaß macht unter den strengen Regeln eines OS dich>> programmtechnisch einzuschränken, dann habe ich nichts dagegen.>> [...]> Ganz im Gegenteil: Ich öffne mich viel weiter, als du. Indem ich mich> z.B. an POSIX halte oder auf etablierte und abstrakte Schnittstellen> setze, läuft meine Software nahezu ohne Änderung auf einer vielzahl von> Plattformen, während du bei jedem Umzug wieder in deine Bitfrickelei> eintauchen musst.
Ich frickel lieber an Bits herum, als an den beschränkten Möglichkeiten
eines von mir verwendeten OS.
> Es ist mir doch egal, wie ich eine Linie auf den Bildschirm bekomme.
Mir aber nicht, weil es mir wenig Spaß macht nur einen Lichtschalter zu
bedienen und ich dann doch lieber im Dunkeln sitzend den Mondschein
betrachte.
> Ich formuliere, dass ich eine Linie malen möchte, den Rest vertraue> ich z.B. dem Treiber an.
Ich finde es einfach nur langweilig.
> Natürlich, zu Lernzwecken frickele ich auch gerne herum.
Prima.
> Aber dabei löse> ich mich von dem Anspruch, 'brauchbare' Software zu schrebein, denn das> tue ich dabei ganz und garnicht.
Diesen Anspruch habe ich erst gar nicht 'brauchbare' Software zu
schrebein.
>> Daneben habe ich auch die Vorzüge davon aufgezeigt, das man sich dann>> programmtechnisch frei entfalten kann und sich eben nicht mit bereits>> vorgekauten Speisen und ausgetrampelten Pfaden zufrieden geben muss.> Und das sagst du, der du auf einer Architektur herumreitest, die man vor> zehn Jahren bereits hätte ausmustern sollen?
Diese Meinung das man DOS ausmustern sollte teile ich nicht.
> Neue Pfade beschreite ich,> wenn ich meine Programme mit wenigen Änderungen auf den ARM bringe, oder> sogar auf den AVR.
Solange es nicht hardwarenah geschieht, sind es doch gar keine neuen
Pfade die man beschreitet wenn man nur marginale Änderungen in seinem
Code vornimmt um seine Anwendung auf anderen Plattformen zum laufen zu
bekommen. Das hört sich zwar zunächst toll an wenn man so etwas liest,
es ist aber nur eine billiger Etikettenschwindel und mit solchen
selbstgelobten Schulterklopfern kann man mich wenig beeindrucken.
Dazu passsend ein Zitat von Robert Anton Wilson in seinem Werk "Die neue
Inquisition" im Artikel über Geist, Materie und Monoismus:
"Der fundamentalistische Materialismus scheint kein zeitlich begrenzter
Rückfall zu sein, sondern eine chronische neurosemantische Entgleisung."
> Selbst als ich mich noch mit DOS herumschlagen musste, gab es schon> Treiber.
Ja das ist gut.
> Für GBIB-Karten habe ich schon nicht mehr an Registern> herumgefrickelt, sondern ein abstraktes API benutzt. Dadurch konnte ich> die Steuersoftware später problemlos von DOS auf Win2000 katapultieren.
Ok.
> Klar, den Original-Treiber gabs nicht mehr. Ein paar Funktionen des> neuen Treibers hatten anderen Namen bekommen, einige verhielten sich> anders oder fehlten. Gut, die habe ich ersetzt und die Sache lief> wieder.>> Was machst du denn, wenn du umziehen musst?
Was meinst du damit?
> Nun habe ich fertig und keine Lust mehr. Du weißt ja offenbar, wie toll> DOS ist...
Es hat für mich auf jeden Fall entscheidende Vorteile.
Dirk
Dirk Wolfgang Glomp schrieb:> Ich würde sie dann eher als Lernsoftware bezeichnen und der Sinn liegt> darin zu lernen und das Lernen würde ich niemals als unnötig bezeichnen.
Das Erlernen nutzlosen Wissens ist nur von eingeschränkter
Notwendigkeit.
Und das Programmieren und Herumfrickeln von DOS-Programmen ist nicht mit
dem erlernen "toter" Sprachen wie Altgriechisch oder Latein zu
vergleichen, das ist eher damit zu vergleichen, verschiedene Varianten
von Schlangenöl herstellen zu können, weil im 19. Jahrhundert so etwas
in den USA durchaus noch als Medikament verkauft werden konnte.
Ein anderer Verglich ist das Trainieren von Dodos.
Dirk Wolfgang Glomp schrieb:> Rolf Magnus schrieb:>> Dirk Wolfgang Glomp schrieb:>>> Wenn eine Anwendung die Aufgabe zu 100% erfüllt wofür sie entwickelt>>> wurde und sie dabei auch wenig Resourcen verbraucht, dann kann man>>> hierbei nichts mehr besser machen, auch dann wenn mehrere Wege zum>>> gleichen Ziel führen.>>>> Das ist aber der Punkt. Die Verwendung des Port 3DAh ist sehr>> ressourcenfressend.>> Im Vergleich wozu genau ist es mehr ressourcenfressend?
Im Vergleich zu den Methoden, die dir das OS stattdessen bietet. Unter
OpenGL z.B. rendere ich in meinen Backbuffer, und wenn ich fertig bin,
sage ich dem Treiber das. Der macht dann von selber beim nächsten
Retrace einen Bufferswap. Zusätzlich kann ich ihm sagen, daß ich so
lange warten möchte, bis der fertig ist, und dann wird mein Prozess bis
dahin schlafen gelegt. Die CPU steht während dieser Zeit komplett
anderen Prozessen zur Verfügung. Und wenn der Retrace fertig ist, werde
ich wieder aufgeweckt.
Bei Verwendung des Port 3DAh müßte ich stattdessen in einer Schleife
warten und pollen und damit 100% CPU-Last verursachen, was anderen
Programmen viel CPU-Zeit klaut und sogar den Stromverbrauch erhöht, weil
das System die CPU nicht schlafen legen kann. Dazu kommt noch das
Problem, daß mein Prozess während des Wartens ja trotzdem unterbrochen
werden kann und ein anderer drankommt. Bis ich wieder dran bin, ist
evtl. der Retrace schon vorbei und ich habe ihn verpaßt.
Abgesehen davon kommen noch andere Sachen dazu, die da Probleme
bereiten, wie z.B. Multimonitor-Betrieb.
Und aus diesen Gründen würde ich sagen, daß der Port 3DAh auf einen
Multitasking-System nicht sinnvoll verwendbar ist.
>>> Der Sinn besteht darin das dann jede Anwendung auch ohne spezielle>>> Rechte auf einen Port wie z.B. 3DAh zugreifen kann und In der>>> Geräte-Datenbank die eh schon existiert wird ja wohl noch ein Platz für>>> ein einzelnes Bit dafür übrig sein.>>>> Wo soll so eine Datenbank existieren?>> Bei den Installationsdaten?
Was für Installationsdaten?
>>>> Wie groß ist die mittlerweile, inklusive sämtlicher Mess- und>>>> Steuerkarten privater Anbieter?>>>> - Unüberschaubar.>>>>>> Trotzdem müssen diese Geräte ja in das System eingebunden werden und>>> dabei ist dann der Aufwand eines zusätzliches Bits dann ja wohl keine>>> besondere Hürde.>>>> Was denn jetzt? Willst du direkt auf die Ports zugreifen oder einen>> Treiber nutzen? Beides gleichzeitig ist wohl ziemlich sinnlos.>> Was soll daran sinnlos sein, wenn man das eine Mal den Treiber benutzen> möchte und ein anderes Mal den Port (von gleichzeitig war doch gar nicht> die Rede)?
Na entweder lädst du einen Treiber, dann verwaltet der die Ports, oder
eben nicht, dann weiß das System nichts von den Ports. Also müßtest der
Treiber die Ports freigeben, die mit seiner Arbeit nicht interferieren,
und auf den Rest mußt du über den Treiber zugreifen.
>> Meines Erachtens hast du ganz im Gegenteil deine Sichtweise stark>> eingeengt, was natürlich dein Recht ist.>> In dem ich mir dir Freiheit bewahren möchte auf die Hardware selber> zugreifen zu dürfen enge ich damit auf welche Weise meine Sichtweise> denn ein?
Du verzichtest auf jede Menge interessante Dienste und Möglichkeiten,
die dir das OS anbietet, auch auf Möglichkeiten der Hardware, die
entweder zu kompliziert zum selbermachen oder mangels Dokumentation gar
nicht nutzbar sind. Oder wie greifst du z.B. unter DOS auf die
USB-Webcam zu? Wie nutzt du einen 3D-Beschleuniger, auf dem man
mittlerweile auch selbst geschriebenen Code ausführen kann? Du schränkst
dich auf eine einzelne Plattform ein, ohne einen echten Vorteil daraus
zu ziehen. Du beschränkst deinen Rechner darauf, nur dein eines Programm
auszuführen. Du zwingst dich dazu, alles selber zu machen, wodurch du
viel weniger tun kannst, weil du das alles in einem Leben nicht
programmieren kannst, was das System dir schon bieten würde. Unter Linux
gibt es viel weitere Felder, wo man viel basteln kann, als unter DOS.
Aber es wird eben von der Hardware abstrahiert. Wobei man natürlich auch
in die Linux-Treiberprogrammierung einsteigen und damit dann auch wieder
direkt mit der Hardware arbeiten kann.
Nicht daß wir uns falsch verstehen: Ich mag es auch gerne, direkt am
"rohen Eisen" zu arbeiten, aber das finde ich auf einem µC interessanter
als auf dem PC.
>> Alle anderen>> brauchen die von dir gewünschte Funktionalität nicht, und deshalb ist>> nicht anzunehmen, daß sich jemand die Mühe macht, sie einzubauen.>> Es gibt immer noch DOS-Programmierer, somit ist deine Angabe das alle> anderen diese Funktionalität nicht mehr wünschen definitiv falsch.
Da hast du mich falsch verstanden. Es ging mir um Linux und die
Möglichkeit, auf deinen Port 3DAh und ein paar andere steinzeitliche
Ports zugreifen zu können, ohne spezielle Bereichtigungen zu haben. Das
braucht keiner unter_ _Linux, weil es da bessere Methoden gibt, das
Gewünschte zu bewerkstelligen. Daß für ein paar Spezialfälle noch DOS
benötigt wird, bestreite ich nicht.
Rufus Τ. Firefly schrieb:> Dirk Wolfgang Glomp schrieb:>> Ich würde sie dann eher als Lernsoftware bezeichnen und der Sinn liegt>> darin zu lernen und das Lernen würde ich niemals als unnötig bezeichnen.>> Das Erlernen nutzlosen Wissens ist nur von eingeschränkter> Notwendigkeit.
Das ist nicht weiter verwunderlich, denn jedes Wissen hat nur eine
eingeschränkte Notwendigkeit. Auch geht es mir doch nicht nur um das
Wissen selber, sondern auch darum die Lernfähigkeit zu erhalten.
Dirk
Dirk Wolfgang Glomp schrieb:> Auch geht es mir doch nicht nur um das> Wissen selber, sondern auch darum die Lernfähigkeit zu erhalten.
Nun gut. Das ist also Programmierung als Alternative zum Sudoku-Lösen.
Da ich meinen Lebensunterhalt mit der Softwareentwicklung verdiene, ist
das ein Denkmodell, mit dem ich mich nicht so recht identifizieren kann,
aber bitte, wenn's schee macht.
Rolf Magnus schrieb:> Dirk Wolfgang Glomp schrieb:>> Rolf Magnus schrieb:>>> Dirk Wolfgang Glomp schrieb:>>>> Wenn eine Anwendung die Aufgabe zu 100% erfüllt wofür sie entwickelt>>>> wurde und sie dabei auch wenig Resourcen verbraucht, dann kann man>>>> hierbei nichts mehr besser machen, auch dann wenn mehrere Wege zum>>>> gleichen Ziel führen.>>>>>> Das ist aber der Punkt. Die Verwendung des Port 3DAh ist sehr>>> ressourcenfressend.>>>> Im Vergleich wozu genau ist es mehr ressourcenfressend?>> Im Vergleich zu den Methoden, die dir das OS stattdessen bietet. Unter> OpenGL z.B. rendere ich in meinen Backbuffer, und wenn ich fertig bin,> sage ich dem Treiber das.
Wenn man also sagt, der Treiber ist eh schon da und gehört zum OS, dann
ist das bestimmt schon ein schwergewichtiges Argument. Aber der Treiber
verschlingt doch selber auch Resourcen und diese müsste man doch
eigentlich zum Vergleich noch dazurechnen, wenn man einen gesamten
Resourcenvergleich aufstellt.....
> Der macht dann von selber beim nächsten> Retrace einen Bufferswap.
.....und das wäre dann auch der Fall wenn man VBE3 hardware triple
buffering(siehe vbe3.pdf von vesa.org) verwendet, das die Ausführung der
Vesafunktion selber dafür im BIOS auch mit angerechnet werden müßte.
Zugegeben, mit der alleinigen Abfrage von Port 3DAh ist es nicht immer
möglich eine saubere Ausgabe hinzubekommen.
> Zusätzlich kann ich ihm sagen, daß ich so> lange warten möchte, bis der fertig ist, und dann wird mein Prozess bis> dahin schlafen gelegt. Die CPU steht während dieser Zeit komplett> anderen Prozessen zur Verfügung. Und wenn der Retrace fertig ist, werde> ich wieder aufgeweckt.> Bei Verwendung des Port 3DAh müßte ich stattdessen in einer Schleife> warten und pollen und damit 100% CPU-Last verursachen,
Auch unter DOS kann man in den PM schalten und Multitasking verwenden
und ggf. weitere Cores initialisieren.
> was anderen> Programmen viel CPU-Zeit klaut und sogar den Stromverbrauch erhöht, weil> das System die CPU nicht schlafen legen kann.
Der Stromverbrauch ist für mich beim PC nahezu irrelevant. Mit ein paar
mal weniger in die Badewanne und/oder stattdessen Duschen könnte ich
locker noch weitere PCs betreiben, da unser Durchlauferhitzer maßgeblich
unsere Stromrechnung bestimmt. Die Taler im Jahr die ich so beim PC
damit einsparen könnte sind da eher vergleichsweise gering.
> Dazu kommt noch das> Problem, daß mein Prozess während des Wartens ja trotzdem unterbrochen> werden kann und ein anderer drankommt. Bis ich wieder dran bin, ist> evtl. der Retrace schon vorbei und ich habe ihn verpaßt.
Bei DOS kann ich alle solche Unterbrechungen unterbinden.
> Abgesehen davon kommen noch andere Sachen dazu, die da Probleme> bereiten, wie z.B. Multimonitor-Betrieb.
Leider habe ich keine Kenntniss darüber wie man eine GraKa dazu selber
überedet unter DOS auf dem "secondary display device" den Inhalt des
zweiten linearen Framebuffers anzuzeigen. In den Linux-Sourcen habe ich
darüber nichts Konkretes finden können. Ich suche weiter, auch wenn es
mir schon quasi Kopfschmerzen bereitet diesen C-Code zu lesen. Für eine
Hilfe dabei wäre ich sehr dankbar.
> Und aus diesen Gründen würde ich sagen, daß der Port 3DAh auf einen> Multitasking-System nicht sinnvoll verwendbar ist.
Die Treiber verwenden wohl eher MMIOs?
> Was für Installationsdaten?
Die Installationsdaten des OS und/oder der Geräte-Treiber.
>> Was soll daran sinnlos sein, wenn man das eine Mal den Treiber benutzen>> möchte und ein anderes Mal den Port (von gleichzeitig war doch gar nicht>> die Rede)?>> Na entweder lädst du einen Treiber, dann verwaltet der die Ports, oder> eben nicht, dann weiß das System nichts von den Ports. Also müßtest der> Treiber die Ports freigeben, die mit seiner Arbeit nicht interferieren,> und auf den Rest mußt du über den Treiber zugreifen.
Ja das wäre doch kein Problem, oder?
>>> Meines Erachtens hast du ganz im Gegenteil deine Sichtweise stark>>> eingeengt, was natürlich dein Recht ist.>>>> In dem ich mir dir Freiheit bewahren möchte auf die Hardware selber>> zugreifen zu dürfen enge ich damit auf welche Weise meine Sichtweise>> denn ein?>> Du verzichtest auf jede Menge interessante Dienste und Möglichkeiten,> die dir das OS anbietet, auch auf Möglichkeiten der Hardware, die> entweder zu kompliziert zum selbermachen oder mangels Dokumentation gar> nicht nutzbar sind.
Ja genau.
Die Geheimhaltung von technischen Errungenschaften ist als
lebensfeindlich einzustufen und sollte daher umfassend verboten werden.
Und bitte wo bleiben die Rechte der gesamten Menschheit, die über
Generationen hinweg an unser aller kulturellem Erbe von Beginn an
tausende Jahre zuvor mitgewirkt haben? Ohne unser gemeinsames Erbe kann
kein Mensch auch nur eine einzige Idee haben, oder diese Idee in Worte
fassen. Wieso hat dann ein einzelner Mensch das alleinige Recht eine
Idee, an der wir alle zusammen gearbeitet haben, bzw. die Arbeit unserer
Vorfahren mit drin steckt, das alleinige Recht darüber zu verfügen? Die
Menschheit wird um ihr kulturelles Erbe betrogen. Wer behauptet es gäbe
ein geistiges Eigentum, der soll das doch bitte schön erst mal beweisen.
Es ist ja nicht so das ich nicht neugierig bin solche Dinge zu lernen,
auch bin ich ein Benutzer, denn einen eigenen Webbrowser habe ich mir in
diesem Fall ja auch noch nicht selber programmiert um hier zu posten.
Aber wenn ich programmieren möchte, dann doch bitte hardwarenah.
> Oder wie greifst du z.B. unter DOS auf die> USB-Webcam zu?
Huch ertappt, meine Webcam habe ich schon seit Ewigkeiten nicht mehr
benutzt und unter DOS noch gar nicht.
> Wie nutzt du einen 3D-Beschleuniger, auf dem man> mittlerweile auch selbst geschriebenen Code ausführen kann?
Nur als Benutzer. Die GPUs sind heute mächtig schnell und könnte ja
eigentlich auch unter DOS für Berechnungen (zweckentfremdet) benutzt
werden.
> Du schränkst> dich auf eine einzelne Plattform ein, ohne einen echten Vorteil daraus> zu ziehen.
Von einen Mangel an Dingen die ich für DOS noch lernen möchte kann
eigentlich nicht die Rede sein.
> Du beschränkst deinen Rechner darauf, nur dein eines Programm> auszuführen.
Ja selbst als Benutzer tue ich das meistens. OK ich könnte mal etwas
Musik anschalten während ich hier schreibe. Wenn ich spiele oder mir
Filme anschaue beschränke ich mich auch nur jeweils darauf. Datenbanken
finde ich völlig langweilig und ich wüßte auch nicht was ich hier
nebenbei noch downloaden oder sonst etwas am Laufen haben sollte.
Telefonieren und Chatten mag ich überhaupt nicht leiden und vermeide das
möglichst.
> Du zwingst dich dazu, alles selber zu machen,
Ja genau.
> wodurch du> viel weniger tun kannst,
Irrtum, ich kann immer nur in vergleichbarer Geschwindigkeit lernen.
Mein Aufwand wird davon also nicht berührt und es gibt immer noch
gewaltig viel zu lernen.
> weil du das alles in einem Leben nicht> programmieren kannst, was das System dir schon bieten würde.
Du vermutest das ich alles lernen könnte was mir das System bietet?
Ich vermute weder das eine, noch das andere. So versuche ich gar nicht
erst Alles zu lernen und habe mir einige für mich interessante Dinge
ausgewählt und dann schauen wir mal wie weit ich komme. Beim
Programmieren lernt man ganz nebenbei und hin und wieder auch mal
menschliche Dinge kennen, so das Schlüsselmomente auftreten können die
einem in Errinnerung hängen bleiben.
> Unter Linux> gibt es viel weitere Felder, wo man viel basteln kann, als unter DOS.
Unter DOS hat man hierbei doch noch viel mehr zu basteln weil es noch
viel weniger gibt, die Herausforderung liegt damit auch noch höher.
> Aber es wird eben von der Hardware abstrahiert. Wobei man natürlich auch> in die Linux-Treiberprogrammierung einsteigen und damit dann auch wieder> direkt mit der Hardware arbeiten kann.
Ja daran dachte ich gerade.
> Nicht daß wir uns falsch verstehen: Ich mag es auch gerne, direkt am> "rohen Eisen" zu arbeiten, aber das finde ich auf einem µC interessanter> als auf dem PC.
Aha. Das ist für mich noch völliges Neuland.
>>> Alle anderen>>> brauchen die von dir gewünschte Funktionalität nicht, und deshalb ist>>> nicht anzunehmen, daß sich jemand die Mühe macht, sie einzubauen.>>>> Es gibt immer noch DOS-Programmierer, somit ist deine Angabe das alle>> anderen diese Funktionalität nicht mehr wünschen definitiv falsch.>> Da hast du mich falsch verstanden.
Oh verdammt.
> Es ging mir um Linux und die> Möglichkeit, auf deinen Port 3DAh und ein paar andere steinzeitliche> Ports zugreifen zu können, ohne spezielle Bereichtigungen zu haben. Das> braucht keiner unter_ _Linux, weil es da bessere Methoden gibt, das> Gewünschte zu bewerkstelligen. Daß für ein paar Spezialfälle noch DOS> benötigt wird, bestreite ich nicht.
Achso, dann habe ich dich tatsächlich hierbei falsch verstanden, Sorry.
Dirk
Rufus Τ. Firefly schrieb:> Dirk Wolfgang Glomp schrieb:>> Auch geht es mir doch nicht nur um das>> Wissen selber, sondern auch darum die Lernfähigkeit zu erhalten.>> Nun gut. Das ist also Programmierung als Alternative zum Sudoku-Lösen.>> Da ich meinen Lebensunterhalt mit der Softwareentwicklung verdiene, ist> das ein Denkmodell, mit dem ich mich nicht so recht identifizieren kann,> aber bitte, wenn's schee macht.
Ich kann nur hoffen das du deswegen beim Programmieren nicht zu sehr
eingeschränkt wirst und du deine Auftraggeber durch deine Ideen auch
genug beflügeln kannst. Auf jeden Fall ist es toll das du Zeit und auch
die Lust dazu hast hier zu helfen. Das gilt natürlich auch für alle
Anderen die sich hier einbringen.
Dirk
Dirk Wolfgang Glomp schrieb:> Ich kann nur hoffen das du deswegen beim Programmieren nicht zu sehr> eingeschränkt wirst und du deine Auftraggeber durch deine Ideen auch> genug beflügeln kannst.
Ist nicht das Problem. Die Phase des
Ich-will-meinen-Rechner-bis-aufs-letzte-Bit-kennen-wollens habe ich halt
vor bald 25 Jahren mit einem Selbstbausystem gelöst, bei dem jede
einzelne Verbindung von mir handgelötet war.
Auch schön, das damit erworbene Wissen hat mir damals letztlich meinen
Job eingebracht, aber auf der Ebene möchte ich mich mit so lausiger
Hardware wie der des PCs einfach nicht mehr beschäftigen.
Wenn ich aufs Bit gucken will, nehme ich einen µC, der mir --vom
eingeschränkten zur Verfügung stehenden Speicher abgesehen-- erheblich
mehr Möglichkeiten bietet als ein PC, gerade wenn es um schnelle
Reaktionen auf externe Ereignisse geht. Zwar läuft ein ein PC mit
abartigen Taktfrequenzen, aber diese stehen überhaupt nicht mehr in
Relation zur Zeit, mit der der PC auf ein externes Ereignis reagieren
kann, oder per "Bitbanging" an irgendeiner zur Verfügung stehenden und
hardwaremäßig noch halbwegs handhabbaren* Schnittstelle Ereignisse
steuern kann.
Da bin ich mit µCs erheblich besser dran, auch wenn diese mit
Taktfrequenzen betrieben werden, über die vor 20 Jahren PC-Anwender
schon lachten.
*) PCI- und PCIe-Karten möchte ich jetzt gerade nicht selbsstricken
müssen.
Dirk Wolfgang Glomp schrieb:>> Da ich meinen Lebensunterhalt mit der Softwareentwicklung verdiene, ist>> das ein Denkmodell, mit dem ich mich nicht so recht identifizieren kann,>> aber bitte, wenn's schee macht.>> Ich kann nur hoffen das du deswegen beim Programmieren nicht zu sehr> eingeschränkt wirst
Entschuldige.
Aber jetzt musste ich ob deines naiven Weltbildes lachen.
Deine Vorstellung davon, wie industrielle Softwareentwicklung
funktioniert ist völlig an der Realität vorbei. Die Zeiten, in denen
Softwareentwickler gesucht waren, die auch noch das letzte Bit in
letzten Register beim Vornamen kannten sind lange vorbei. Ganz im
Gegenteil. Die wenigsten wollen so einen in ihrem Team haben, weil es
meistens bis oft nur Ärger mit ihnen gibt. Der Grund: Sie wollen und
können sich nicht an Konventionen halten und entwickeln am Rest des
Teams und deren Bibliotheken vorbei ihr eigenes Ding. Sozusagen ein Team
im Team. Das was bei ihnen rauskommt, ist zwar für sich gesehen super,
passt aber zum Rest des Systems oft nicht dazu, ist daher im
Gesamtkontext gesehen unbrauchbar und muss dann erst recht wieder von
jemand anderem neu gemacht werden. Keine Entwicklungsfiirma kann sich so
eine Zweigleisigkeit auf Dauer leisten.
Mal Hand aufs Herz, wie lange hat es gedauert, bis deine Fraktalendemo
da oben gelaufen ist.
Abgesehen davon, dass man mit einer derart eingeschränkten
Funktionalität keinen Kunden mehr locken kann, darf so etwas nicht
länger als 10 bis höchsten 15 Minuten dauern. Dann muss so etwas in
dieser Komplexitätsstufe fertig sein. Mehr Zeit zahlt dir dein Kunde für
etwas derartig Banales nicht.
Und nein: Die Framerate ist ihm dabei erst mal völlig egal, solange es
flüssig genug abläuft.
> Du vermutest das ich alles lernen könnte was mir das System bietet?
Nein.
Du bekämpfst und verdammst so vehement das System, dass du gar nicht
merkst welche Möglichkeiten dir das 'System' sonst noch bietet. Würdest
du das System als deinen Partner ansehen und nicht als deinen Feind, der
dir in die Suppe spucken will, wärst du schon viel weiter. Du reibst
dich an der falschen Stelle auf.
> Ich vermute weder das eine, noch das andere. So versuche ich gar> nicht erst Alles zu lernen und habe mir einige für mich> interessante Dinge ausgewählt und dann schauen wir mal wie weit> ich komme.
Du weißt gar nicht, was du, gerade im Bereich Computer Graphik, alles
verpasst, in dem du versuchst auf möglichst tiefer Ebene an der Wurzel
zu kratzen. Dein Beharren auf den letzten paar Nanosekunden (wobei
selbst das noch zu beweisen wäre, würde mich interessieren ob du zb
OpenGL bei einem hinreichend realen Anwendungsbeispiel schlagen kannst),
steht dir selbst bei den tatsächlich interessanten Dingen im Wege.
Aber jeder wie er mag.
> Wenn du einen halbwegs aktuellen Rechner hast, geht das gar nicht.
Das hat nix damit zu tun wie alt der Rechner ist. Eher welche Software
installiert ist.
Karl heinz Buchegger schrieb:> Dirk Wolfgang Glomp schrieb:>>>> Da ich meinen Lebensunterhalt mit der Softwareentwicklung verdiene, ist>>> das ein Denkmodell, mit dem ich mich nicht so recht identifizieren kann,>>> aber bitte, wenn's schee macht.>>>> Ich kann nur hoffen das du deswegen beim Programmieren nicht zu sehr>> eingeschränkt wirst>> Entschuldige.> Aber jetzt musste ich ob deines naiven Weltbildes lachen.> Deine Vorstellung davon, wie industrielle Softwareentwicklung> funktioniert ist völlig an der Realität vorbei.
Das kann nicht sein, denn ich habe doch überhaupt noch keine Vorstellung
davon wie industrielle Softwareentwicklung funktioniert.
> Die Zeiten, in denen> Softwareentwickler gesucht waren, die auch noch das letzte Bit in> letzten Register beim Vornamen kannten sind lange vorbei.
Das habe ich mir schon gedacht.
> Ganz im> Gegenteil. Die wenigsten wollen so einen in ihrem Team haben, weil es> meistens bis oft nur Ärger mit ihnen gibt. Der Grund: Sie wollen und> können sich nicht an Konventionen halten und entwickeln am Rest des> Teams und deren Bibliotheken vorbei ihr eigenes Ding. Sozusagen ein Team> im Team. Das was bei ihnen rauskommt, ist zwar für sich gesehen super,> passt aber zum Rest des Systems oft nicht dazu, ist daher im> Gesamtkontext gesehen unbrauchbar und muss dann erst recht wieder von> jemand anderem neu gemacht werden. Keine Entwicklungsfiirma kann sich so> eine Zweigleisigkeit auf Dauer leisten.
Das verstehe ich nicht so ganz warum sich solche Mitarbeiter nicht in
das Team einbringen können. Ich vermute eher das so etwas die Ausnahme
ist und es sehr wohl auch Mitarbeiter gibt die beides beherschen, also
Bibliotheken verwenden, an den Bits herumfrickeln können und dabei auch
teamfähig sind.
> Mal Hand aufs Herz, wie lange hat es gedauert, bis deine Fraktalendemo> da oben gelaufen ist.
Das Demo ist schon etwas älter, aber sehr viel Zeit steckt da ja nicht
drin.
> Abgesehen davon, dass man mit einer derart eingeschränkten> Funktionalität keinen Kunden mehr locken kann, darf so etwas nicht> länger als 10 bis höchsten 15 Minuten dauern. Dann muss so etwas in> dieser Komplexitätsstufe fertig sein. Mehr Zeit zahlt dir dein Kunde für> etwas derartig Banales nicht.
Ich denke auch das ist durchaus zu schaffen. Das Demo soll ja nur dazu
dienen um zu zeigen wie man Pixel setzt.
> Und nein: Die Framerate ist ihm dabei erst mal völlig egal, solange es> flüssig genug abläuft.
Verständlich.
>> Du vermutest das ich alles lernen könnte was mir das System bietet?>> Nein.> Du bekämpfst und verdammst so vehement das System, dass du gar nicht> merkst welche Möglichkeiten dir das 'System' sonst noch bietet.
Du übertreibst jetzt aber ein bischen und wenn wir bei DOS bleiben, dort
gibt es nicht so viele Möglichkeiten vom OS selber. Bei allen anderen OS
bin ich überwiegend ja nur ein Benutzer.
> Würdest> du das System als deinen Partner ansehen und nicht als deinen Feind, der> dir in die Suppe spucken will, wärst du schon viel weiter. Du reibst> dich an der falschen Stelle auf.
Wenn ich hardwarenah programmieren kann, dann habe ich damit auch kein
Problem wenn ich nicht dabei so eingeschränkt werde. Es kommt ja immer
auf die Zielsetzung an und ich stehe nun bei der Programmierung in
keiner wirtschaftlichen Abhängigkeit und kann daher das Ziel meiner
Wünsche was ich wie programmieren möchte immer völlig frei auswählen.
>> Ich vermute weder das eine, noch das andere. So versuche ich gar>> nicht erst Alles zu lernen und habe mir einige für mich>> interessante Dinge ausgewählt und dann schauen wir mal wie weit>> ich komme.>> Du weißt gar nicht, was du, gerade im Bereich Computer Graphik, alles> verpasst, in dem du versuchst auf möglichst tiefer Ebene an der Wurzel> zu kratzen.
Stimmt, denn wenn ich das ganz genau wüßte, dann würde ich keinen
Closed-Source-Grafiktreiber mehr brauchen und könnte es ohne die
Unterstützung selber machen. Alle anderen Dinge haben noch keinen
besonderen Reiz auf mich ausüben können für einen
Closed-Source-Grafiktreiber etwas zu programmieren.
> Dein Beharren auf den letzten paar Nanosekunden (wobei> selbst das noch zu beweisen wäre, würde mich interessieren ob du zb> OpenGL bei einem hinreichend realen Anwendungsbeispiel schlagen kannst),
OpenGL kann ich ganz bestimmt nicht schlagen. Hiebei geht es mir weniger
darum ob meine Routinen in Software lagsamer sind, sondern darum das es
mir keine Spaß macht für einen Closed-Source-Treiber etwas zu
programmieren.
> steht dir selbst bei den tatsächlich interessanten Dingen im Wege.
Du gehst dabei aber von der Annahme aus, das mich solche Dinge die man
mit der Hilfe eines Closed Treibers erzielen kann als Programmierer
interessieren würde. Das stimmt aber nicht. Ich finde es einfach nur
langweilig einen Schalter hier und dort zu betätigen ohne zu wissen wie
es genau hardwarenah umgesetzt wird.
> Aber jeder wie er mag.
So ist es.
Dirk
Rufus Τ. Firefly schrieb:> Dirk Wolfgang Glomp schrieb:>> Ich kann nur hoffen das du deswegen beim Programmieren nicht zu sehr>> eingeschränkt wirst und du deine Auftraggeber durch deine Ideen auch>> genug beflügeln kannst.>> Ist nicht das Problem.
Prima.
> Die Phase des> Ich-will-meinen-Rechner-bis-aufs-letzte-Bit-kennen-wollens habe ich halt> vor bald 25 Jahren mit einem Selbstbausystem gelöst, bei dem jede> einzelne Verbindung von mir handgelötet war.> Auch schön, das damit erworbene Wissen hat mir damals letztlich meinen> Job eingebracht, aber auf der Ebene möchte ich mich mit so lausiger> Hardware wie der des PCs einfach nicht mehr beschäftigen.
Ich hatte noch nie vor ein Hobby zum Beruf zu machen.
> Wenn ich aufs Bit gucken will, nehme ich einen µC, der mir --vom> eingeschränkten zur Verfügung stehenden Speicher abgesehen-- erheblich> mehr Möglichkeiten bietet als ein PC, gerade wenn es um schnelle> Reaktionen auf externe Ereignisse geht. Zwar läuft ein ein PC mit> abartigen Taktfrequenzen, aber diese stehen überhaupt nicht mehr in> Relation zur Zeit, mit der der PC auf ein externes Ereignis reagieren> kann, oder per "Bitbanging" an irgendeiner zur Verfügung stehenden und> hardwaremäßig noch halbwegs handhabbaren* Schnittstelle Ereignisse> steuern kann.>> Da bin ich mit µCs erheblich besser dran, auch wenn diese mit> Taktfrequenzen betrieben werden, über die vor 20 Jahren PC-Anwender> schon lachten.>>> *) PCI- und PCIe-Karten möchte ich jetzt gerade nicht selbsstricken> müssen.
Gut zu wissen.
Dirk
pixelschupser schrieb:>> Wenn du einen halbwegs aktuellen Rechner hast, geht das gar nicht.>> Das hat nix damit zu tun wie alt der Rechner ist. Eher welche Software> installiert ist.
Genau.
Ich habe mir bisher immer alle x86-Rechner aus Einzelteilen selber
zusammengebastelt und ich habe noch nie einen Rechner mit einem bereits
installiertem OS erworben. Und selbst mit installiertem OS kann (fast)
jeder x86-Rechner(alle ohne EFI-Bios) immer noch ein DOS booten und ist
damit deswegen ja nicht weniger aktuell. Somit stimmt die Angabe es
würde mit halbwegs aktuellen Rechner gar nicht mehr gehen auch nicht,
denn auch wenn kein Diskettenlaufwerkskontroller mehr vorhanden ist wie
bei meinem ASUS-Striker-II, dann kann man ja trotzdem inmmer noch über
CD, oder USB-Stick ein DOS booten, wenn man kein DOS auf Platte
verwenden möchte.
Dirk
Hand aufs Herz, fährst du gelegentlich Auto, Bus oder Bahn? Oder hast du
in deinem Häusle Türen und Treppen?
Ehrlich, diese Dinge müssten deine Freiheit doch ganz erheblich
einschränken, oder?
Was Karl-heinz mit Teamfähigkeit meinte, trifft voll und ganz zu.
Du beschreibst dich ja selbst bereits als nicht teamfähig. Du vertraust
weder deinem eigenen Arsch noch irgendeinem anderen Programmierer.
Sobald jemand anderes, etwa die Entwickler von Treiber und
Betriebssystem, dir ausgereifte, getestete und konsistente
Schnittstellen auf dem Silbertablett servieren, beginnst du mit der
Ihr-schränkt-mich-doch-alle-nur-ein-Jammerei.
Solltest du mit der Einstellung irgendwann mal in die große weite Welt
gehen, werden dir zuerst hundert Leute sagen: Dein Wissen auf dem Gebiet
ist in erster Näherung wertlos, alt, unnütz, verschenkte Zeit,
überflüssig und ungefragt.
Es interessiert sich keine Sau dafür, wie toll du an irgendwelchen Bits
herumpfriemeln kannst. Heute nicht mehr. Gefragt ist, wie du deine
Fummelei verpacken kannst, in Treibern und APIs, sodass andere etwas
davon haben, sodass der Text wiederverwertbar und wartbar wird. Gefragt
ist, wie du die Arbeit anderer Programmierer integrieren kannst, indem
du deren Treiber und APIs benutzt. Niemand bezahlt dich dafür, dass du
glaubst -- aus Paranoia oder Ego -- hunderte Arbeitsstunden anderer
Programmierer selbst nachprogrammieren zu müssen.
In zweiter Näherung wird man dann darauf kommen, dass du z.B. Treiber
entwickeln könntest. Und auch da wird man dir wieder sagen, dass sich
keine Sau dafür interessiert, wie man auf Register 0x3DA zugreifen kann,
denn das haben andere schon herausgefunden. Selbst wenn man dich dann
auf die Graphikkarte loslässt, stellst du fest, dass sich seit den
Dinosauriern etwas getan hat, und dein Wissen über 0x3DA nicht mehr
zutrifft.
Versteh das nicht falsch -- ich hab auch schon Timer auf x86
programmiert und mich mit der Billiglösung Interrupt-Controller
geschlagen. War interessant. Aber man, das durchdenkt man einmal und
hakt es man danach ab! Heute sieht jeder ein, dass die
Interrupt-Controller eine Bastellösung sind und das Daisy-Chain
eigentlich besser gewesen wäre, als Kaskade. Genauso wie 99% der
Steckverbinder praktisch der Griff in die nächste Wühlkiste waren.
Vorallem bleibt man nicht stehen bei diesem Stand von vor 20 Jahren.
Deine Freiheit, die du da andauernd beschreist, ist nämlich ansonsten
garkeine.
Du hast die dollste Hardware unterm Tisch stehen. Dann startest du sie
und das erste, was du machst, ist alles zwanzig Jahre in die
Vergangenheit zu katapultieren, weil du dich gegen jede Form von
'Moderne' wehrst. Ist das dann Freiheit?
Ich bin froh, wenn ich so früh wie irgendwie möglich weg komme, von so
einem Müll, und ab dann abstrakt programmieren kann. Und das geht den
meisten anderen Programmierern auch so. Das BIOS ist längst tot!
Ansonsten: Viel Erfolg bei dem Bestreben, alles selbst lösen zu wollen.
Himmel, erkenn mal, dass nicht alle Programmierer dir was Böses wollen.
Dann gibt es auch noch FREEBASIC:
http://www.freebasic-portal.de/
Kurzinfo über FreeBASIC:
FreeBASIC ist ein kostenloser Open-Source-Compiler, dessen Entwicklung
im Jahr 2004 begann. FreeBASIC verbindet die Einfachheit von QBASIC mit
modernen Funktionen und vielen neuen Sprachelementen wie z. B. Zeigern,
auf die man in QB einstmals verzichten musste. Mit FreeBASIC erstellen
Sie im Handumdrehen plattformübergreifend Programme für Microsoft
Windows, DOS und Linux. [Mehr lesen]->
FreeBASIC ist ein OpenSource-Compiler für eine Microsoft QBasic ähnliche
Sprache, dessen Entwicklung 2004 begann. FreeBASIC steht unter der
OpenSource-Lizenz GPL, manche Komponenten auch unter der LGPL. Das
bedeutet, dass FreeBASIC von jedermann frei verändert und verbessert
werden kann.
Mit FreeBASIC lassen sich Anwendungen für Microsoft Windows, Linux und
DOS erstellen. FreeBASIC vereint die Einfachheit von QBasic mit modernen
Sprachelementen wie z.B. der Möglichkeit, beliebige Bibliotheken in die
eigenen Programme zu integrieren: Neben der WinAPI, der
Standard-Programmierschnittstelle für Windows-Anwendungen, lassen sich
diverse andere, vorgefertigte Bibliotheken mit FreeBASIC benutzen: So
zum Beispiel das plattformübergreifende GUI-Toolkit GTK, das C-API zu
MySQL, die Soundbibliothek FMOD oder beinahe jede andere
DLL-Programmbibliothek.
Damit kann man SDL, OpenGL und auch Multithreading verwenden.
Dirk
Sven P. schrieb:> Hand aufs Herz, fährst du gelegentlich Auto, Bus oder Bahn?
Ja alles gelegentlich mal, aber Fahradfahren macht mir doch mehr Spaß.
Ein eigenes Auto brauche ich hier in HH eigentlich nicht und wenn doch,
dann kann ich mir eins ausleihen. Doch das kommt so gut wie nie vor.
> Oder hast du> in deinem Häusle Türen und Treppen?
Na sicher.
> Ehrlich, diese Dinge müssten deine Freiheit doch ganz erheblich> einschränken, oder?
Mit dem Fahrrad ist man da schon freier und man kann sogar die Wege
verlassen.
> Was Karl-heinz mit Teamfähigkeit meinte, trifft voll und ganz zu.> Du beschreibst dich ja selbst bereits als nicht teamfähig.
Wie kommst du denn auf diese Idee, bzw. woraus lässt sich das denn
ableiten?
> Du vertraust> weder deinem eigenen Arsch noch irgendeinem anderen Programmierer.
Wieso sollte ich denn keinem Programmierer trauen?
> Sobald jemand anderes, etwa die Entwickler von Treiber und> Betriebssystem, dir ausgereifte, getestete und konsistente> Schnittstellen auf dem Silbertablett servieren, beginnst du mit der> Ihr-schränkt-mich-doch-alle-nur-ein-Jammerei.
Ich habe lediglich meine Vorliebe für die DOS-Programmierung deutlich
gemacht und dabei erwähnt das es mir kein Spaß macht undurchsichtige
Geschenke auf dem Silbertablett anzunehmen. Dir scheint das aber wohl
nicht zu genügen und jetzt jammerst du herum wenn ich nicht die gleichen
Ziele verfolge wie du es tust.
> Solltest du mit der Einstellung irgendwann mal in die große weite Welt> gehen, werden dir zuerst hundert Leute sagen: Dein Wissen auf dem Gebiet> ist in erster Näherung wertlos, alt, unnütz, verschenkte Zeit,> überflüssig und ungefragt.
Ach und deswegen soll ich mich diesen anderen Meinungen lieber
anschliessen und Dinge die für mich wertlos sind machen?
Und wenn alle Menschen es für wertlos halten was ich mache, meinst du
deswegen ist es für mich weniger wertvoll?
> Es interessiert sich keine Sau dafür, wie toll du an irgendwelchen Bits> herumpfriemeln kannst.
Das stimmt doch auch nicht und wenn es mich nur alleine interessiert,
mir genügt es. Du kannst ja gerne mit deinen Zielen die du erreichen
möchtest so viele Menschen wie du finden kannst damit beglücken, für
mich ist es eher irrelevant was andere Menschen davon halten, denn ich
muss mich ja nicht damit beliebt machen, oder mich darüber definieren.
Für mich soll es nur ein Hobby bleiben. Hast du damit etwa Probleme?
> Heute nicht mehr.
Derartige Kriterien sind für dich möglicherweise wichtig, doch für mich
nicht.
> Gefragt ist, wie du deine> Fummelei verpacken kannst, in Treibern und APIs, sodass andere etwas> davon haben, sodass der Text wiederverwertbar und wartbar wird.
In der eigentlichen Anfrage wie man Pixel setzen kann war weder die Rede
von Treibern oder APIs, noch wie man eine Fumelei einpacken kann. Diese
Dinge kannst du ja gerne verwenden, aber überlasse es uns selber für was
wir uns letztendlich entscheiden. Dafür kannst du dann auch gerne die
Vor- und Nachteile der Möglichkeiten aufzeigen, aber bitte verschone
mich mit dem Versuch mir deine Ziele als besser zu verkaufen in dem du
meine Ziele als weniger wertvoll für mich darstellst. Damit wirst du
keinen Erfolg haben.
> Gefragt> ist, wie du die Arbeit anderer Programmierer integrieren kannst, indem> du deren Treiber und APIs benutzt.
Nein das wurde nicht gefragt.
> Niemand bezahlt dich dafür, dass du> glaubst -- aus Paranoia oder Ego -- hunderte Arbeitsstunden anderer> Programmierer selbst nachprogrammieren zu müssen.
Habe ich denn jemals um eine Bezahlung gebeten? NEIN. Also versuche mir
bitte nicht einzureden das ich es nötig hätte für das Programieren eine
Bezahlung zu bekommen. Deine Kriterien zu programmieren unterscheiden
sich erheblich von meinen Kriterien. Begreife das nun endlich mal!
> In zweiter Näherung wird man dann darauf kommen, dass du z.B. Treiber> entwickeln könntest. Und auch da wird man dir wieder sagen, dass sich> keine Sau dafür interessiert, wie man auf Register 0x3DA zugreifen kann,> denn das haben andere schon herausgefunden. Selbst wenn man dich dann> auf die Graphikkarte loslässt, stellst du fest, dass sich seit den> Dinosauriern etwas getan hat, und dein Wissen über 0x3DA nicht mehr> zutrifft.
Dein Gedankenfehler besteht schon darin das du vermutest ich würde mich
daran orientieren was Auftraggeber gerne programmiert haben möchten.
Das insteressiert mich aber überhaupt nicht.
> Versteh das nicht falsch -- ich hab auch schon Timer auf x86> programmiert und mich mit der Billiglösung Interrupt-Controller> geschlagen. War interessant. Aber man, das durchdenkt man einmal und> hakt es man danach ab! Heute sieht jeder ein, dass die> Interrupt-Controller eine Bastellösung sind und das Daisy-Chain> eigentlich besser gewesen wäre, als Kaskade. Genauso wie 99% der> Steckverbinder praktisch der Griff in die nächste Wühlkiste waren.> Vorallem bleibt man nicht stehen bei diesem Stand von vor 20 Jahren.> Deine Freiheit, die du da andauernd beschreist, ist nämlich ansonsten> garkeine.
Ich habe aber die Freiheit auch noch Hardware die vor 20 Jahren
entwickelt wurden zu verwenden. Wenn du diese Freiheit auf Grund deiner
Tätigkeit nicht mehr hast dann ist das deine Sache, aber ich brauche
mich nicht mit solchen Problemen die du hierbei erwähnst herumschlagen.
> Du hast die dollste Hardware unterm Tisch stehen. Dann startest du sie> und das erste, was du machst, ist alles zwanzig Jahre in die> Vergangenheit zu katapultieren, weil du dich gegen jede Form von> 'Moderne' wehrst. Ist das dann Freiheit?
Ja sicher, ich kann mit meiner Hardware alles machen und brauch mich
nicht darum zu kümmern was deine Auftraggeber gerne möchten. Ich bin so
frei.
> Ich bin froh, wenn ich so früh wie irgendwie möglich weg komme, von so> einem Müll, und ab dann abstrakt programmieren kann. Und das geht den> meisten anderen Programmierern auch so. Das BIOS ist längst tot!
Für mich ist da eher eine abstrakte Programmierung Müll, auch dann wenn
das alle Programmierer von der Welt anders sehen würden.
> Ansonsten: Viel Erfolg bei dem Bestreben, alles selbst lösen zu wollen.
Danke, das wünsche ich dir auch.
> Himmel, erkenn mal, dass nicht alle Programmierer dir was Böses wollen.
Ich verstehe nicht so ganz was dich dazu veranlasst hat zu glauben, das
ich es glauben würde das alle Programmierer mir etwas böses antun
wollen.
Allerdings empfinde ich es schon als etwas sonderbar zu behaupten, das
ich nicht teamfähig sei, das ich mir selber nicht trauen würde und das
du meine Arbeit als wertlos darzustellst. Damit zeigst du uns nur das du
dir deiner Sache wohl selber nicht so ganz sicher bist, wenn du es nötig
hast mit solchen eher persöhlichen Unterstellungen deine Postion zu
stärken. Das ist doch eher peinlich für dich.
Dirk
Um klarzustellen: Es ist mir (und vermutlich auch allen anderen hier)
ziemlich egal, was und wie du programmierst.
Dirk Wolfgang Glomp schrieb:> [...]> Allerdings empfinde ich es schon als etwas sonderbar zu behaupten, das> ich nicht teamfähig sei, das ich mir selber nicht trauen würde und das> du meine Arbeit als wertlos darzustellst. Damit zeigst du uns nur das du> dir deiner Sache wohl selber nicht so ganz sicher bist, wenn du es nötig> hast mit solchen eher persöhlichen Unterstellungen deine Postion zu> stärken. Das ist doch eher peinlich für dich.
Siehe oben; es ist mir egal, was du tust, das hatten wir ja bereits.
Aber ich finde es frech von dir, wenn du unzähligen Programmierern, die
viele, viele Stunden Arbeit und Hirnschmalz in ein System gesteckt
haben, unterstellst, dass sie dich einschränken wollen und das ihre
Ideen sinnlos oder von wirtschaftlichem Interesse sind. Vorallem, wenn
du dann noch versuchst, mit einer Leiche wie DOS zu argumentieren. Und
nur, weil du dich aus irgendwelchen völlig aus der Luft gegriffenen
Gründen weigerst, sich mit den Gedanken dieser anderen Programmierer
auseinanderzusetzen.
Aber natürlich, wenn man nicht dazu bereit ist, ist es viel einfacher,
alles von vornherein zu verdammen, wie du es hier tust. Zumindest konnte
ich von deiner Seite keinerlei Reaktion dahingehend erkennen, die über
das Abnicken von dem hinausgeht, was man dir hier nahelegte.
Und genau das entspricht ziemlich gut dem Gegenteil von 'Teamfähigkeit'.
Nicht mehr und nicht weniger. Alles andere von mir sollte dich, mal mehr
und mal weniger provokant, dazu ermuntern, auch mal einen Blick über
deinen Tellerrand zu werfen.
Bevor die Diskussion hier weiter abdriftet:
Dirk Wolfgang ist wohl ein deutlich älteres Semester und betreibt das,
was er macht, als reinen Zeitvertreib. Daher sieht er etliches ganz
anders als wir, die wir mit anderen zusammenarbeiten (müssen oder
wollen) und unsere Arbeit auch zum Zwecke des Gelderwerbes einsetzen
wollen, oder mit der Perspektive, unser Wissen auch in den nächsten
20-30 Jahren dazu verwenden zu können.
Rufus Τ. Firefly schrieb:> Bevor die Diskussion hier weiter abdriftet:> Dirk Wolfgang ist wohl ein deutlich älteres Semester und betreibt das,> was er macht, als reinen Zeitvertreib. Daher sieht er etliches ganz> anders als wir, die wir mit anderen zusammenarbeiten (müssen oder> wollen) und unsere Arbeit auch zum Zwecke des Gelderwerbes einsetzen> wollen, oder mit der Perspektive, unser Wissen auch in den nächsten> 20-30 Jahren dazu verwenden zu können.
Mag sein, nur hätte hier niemand nach dem Sinn gefragt, wenn es um
Grafikprogrammierung auf Mikrocontrollern gegangen wäre. Bei derartigen
Low-Level-Sachen auf PCs fragt man sich aber schon nach dem Sinn (außer
man schreibt 256-Byte Demos ala Puls
http://www.youtube.com/watch?v=R35UuntQQF8 von
http://rrrola.wz.cz/downloads.html (inkl. Quelltext)).
Sven P. schrieb:> Um klarzustellen: Es ist mir (und vermutlich auch allen anderen hier)> ziemlich egal, was und wie du programmierst.
Das war mir auch schon vorher klar.
> Dirk Wolfgang Glomp schrieb:>> [...]>> Allerdings empfinde ich es schon als etwas sonderbar zu behaupten, das>> ich nicht teamfähig sei, das ich mir selber nicht trauen würde und das>> du meine Arbeit als wertlos darzustellst. Damit zeigst du uns nur das du>> dir deiner Sache wohl selber nicht so ganz sicher bist, wenn du es nötig>> hast mit solchen eher persöhlichen Unterstellungen deine Postion zu>> stärken. Das ist doch eher peinlich für dich.> Siehe oben;
Und deswegen glaubst du, das du das Recht dazu hättest mir derartige
Unterstellungen wie etwas "ich wäre nicht teamfähig, oder ich würde mir
selber nicht glauben" an den Kopf werfen zu dürfen?
> es ist mir egal, was du tust, das hatten wir ja bereits.
Nee, das hatten wie vorher noch nicht.
> Aber ich finde es frech von dir, wenn du unzähligen Programmierern, die> viele, viele Stunden Arbeit und Hirnschmalz in ein System gesteckt> haben, unterstellst, dass sie dich einschränken wollen und das ihre> Ideen sinnlos....
Du lügst. Derartiges habe ich gar nicht unterstellt, ich habe lediglich
darauf hingewiesen das mir das Proagrammieren unter Windows/Linux keinen
Spaß macht und für mich daher auch keinen Sinn macht.
> ...oder von wirtschaftlichem Interesse sind.
Diese "Vermutung" habe ich tatsächlich aufgestellt.
> Vorallem, wenn> du dann noch versuchst, mit einer Leiche wie DOS zu argumentieren.
DOS ist gar keien Leiche wie du schon an FREEDOS erkennen kanst,
als erzähle hier keinen Müll.
> Und> nur, weil du dich aus irgendwelchen völlig aus der Luft gegriffenen> Gründen weigerst, sich mit den Gedanken dieser anderen Programmierer> auseinanderzusetzen.
Was habe ich denn aus der Luft gegriffen, etwa das unter Windows nur
Closed Source-Grafik-Treiber verwendet werden? Solche gewichtigen
Argumente für mich, nichts für Windows programmieren zu wollen,
schmecken dir vieleicht nicht, aber deswegen sind sie ganz bestimmt
nicht aus der Luft gegriffen. Und mit solchen eher dümmlichen Lügen hast
du dich gerade selber als Teamplayer disqualifiziert. Was sollen solchen
Lügen?
> Aber natürlich, wenn man nicht dazu bereit ist, ist es viel einfacher,> alles von vornherein zu verdammen, wie du es hier tust.
Dieses Grund ist für mich ausreichend genug und ich habe diese
Entscheidung auch noch nie bereut. Was verlangst du nun eigentlich genau
von mir, das ich etwa Dinge mache wozu ich keine Lust habe, was soll
das?
> Zumindest konnte> ich von deiner Seite keinerlei Reaktion dahingehend erkennen, die über> das Abnicken von dem hinausgeht, was man dir hier nahelegte.
Du phanatsierst dir eine ganze Menge über mich zusammen, was nicht den
Tatsachen entsprechen. Was versprichst du dir davon?
> Und genau das entspricht ziemlich gut dem Gegenteil von 'Teamfähigkeit'.
Für eine derartige Beurteilung kennst du mich viel zu wenig, vermutlich
hast DU damit ein Problem und projezierst es nun auf beliebige andere
Menschen.
> Nicht mehr und nicht weniger.
Du machst dich mit solchen persöhnlichen Fehlurteilen einfach nur
lächerlich.
> Alles andere von mir sollte dich, mal mehr> und mal weniger provokant, dazu ermuntern, auch mal einen Blick über> deinen Tellerrand zu werfen.
Ich habe keine Lust Anwendungen für ein Closed-Source-Treiber zu
programmieren. Kannst du das nicht, oder willst du das nicht begreifen?
Dirk
Rufus Τ. Firefly schrieb:> Bevor die Diskussion hier weiter abdriftet:> Dirk Wolfgang ist wohl ein deutlich älteres Semester
Das kann ich noch nicht beurteilen. Ich habe im Oktober mein 51.
Lebensjahr begonnen.
> und betreibt das,> was er macht, als reinen Zeitvertreib.
Zeit habe ich eigentlich nie genug, aber es stimmt schon, ich
programmiere aussschlieslich um Spaß zu haben.
> Daher sieht er etliches ganz> anders als wir, die wir mit anderen zusammenarbeiten (müssen oder> wollen) und unsere Arbeit auch zum Zwecke des Gelderwerbes einsetzen> wollen, oder mit der Perspektive, unser Wissen auch in den nächsten> 20-30 Jahren dazu verwenden zu können.
Die Zielsetzung was wir erreichen wollen unterscheidet sich somit
grundlegend. Aber natürlich bin ich auch für jede Hilfe die ich auf
meinem Weg bekommen kann dankbar und versuche auch gerne Anderen zu
helfen, wenn ich helfen kann.
Dirk
Es ist deine Einstellung, die mich ganz erheblich stört. Nicht, weil ich
die nicht teilen möchte -- ganz im Gegenteil:
Ich zitiere sie nun, du bist in der Lage, die betreffenden Stellen zu
finden, damit nicht alles sinnentstellt wird.
- Konsistenz:
> Konsistent ohne jeden Sinn.
- portable Standards:
> Damit sind die Anwendungen eingeschränkt.
- die Möglichkeit, sich Rechte zu beschaffen:
> Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut> sein soll, wenn ich dann eh wie unter DOS alles machen darf.
- Möglichkeiten durch Geräte(treiber)-orientierte Verwaltung:
> Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung> Port 3DAh auslesen möchte.
Es stört mich ganz ungemein, dass du auf DOS die letzten 20 Jahre mehr
oder weniger verpennt zu haben scheinst und nun glaubst, Möglichkeiten
und Probleme beurteilen zu können. Dort stecken unzählige Mannstunden
und Ideen drin, die wir hier wirklich nur am äußersten Rande beschreiben
konnten. Und du machst alles zunieder, ohne überhaupt einmal weiter
darüber nachgedacht zu haben.
Falls du dich zu arg angegriffen fühlst, bitte ich um Verzeihung, denn
dazu habe ich weder Grund noch Recht. Ich werde aber schnell stinkig,
wenn man die Leistungen anderer Leute so zerschmettert, ohne
nachzudenken.
Und ich respektiere weiterhin deine Mühe und Ausdauer, wie ich oben
schrob (
Beitrag "Re: C: Pixel auf dem Bildschirm ausgeben" ).
Dennoch beschreibst du ziemlich genau das Sinnbild eines Einzelgängers
in der IT-Abteilung, wie er im Lehrbuch steht.
Arc Net schrieb:> Rufus Τ. Firefly schrieb:>> Bevor die Diskussion hier weiter abdriftet:>> Dirk Wolfgang ist wohl ein deutlich älteres Semester und betreibt das,>> was er macht, als reinen Zeitvertreib. Daher sieht er etliches ganz>> anders als wir, die wir mit anderen zusammenarbeiten (müssen oder>> wollen) und unsere Arbeit auch zum Zwecke des Gelderwerbes einsetzen>> wollen, oder mit der Perspektive, unser Wissen auch in den nächsten>> 20-30 Jahren dazu verwenden zu können.>> Mag sein, nur hätte hier niemand nach dem Sinn gefragt, wenn es um> Grafikprogrammierung auf Mikrocontrollern gegangen wäre. Bei derartigen> Low-Level-Sachen auf PCs fragt man sich aber schon nach dem Sinn (außer> man schreibt 256-Byte Demos ala Puls> http://www.youtube.com/watch?v=R35UuntQQF8 von> http://rrrola.wz.cz/downloads.html (inkl. Quelltext)).
Es ging ja auch hierbei zunächst ganz schlicht nur darum einen Pixwl zu
setzen, verglichsweise wie mit dem Quickbasic-Befehl "Pset(u,v),w" und
dafür genügt gewöhnlich schon so ein nahezu eigenständiges
"256-Byte"-Demos voll und ganz.
Dirk
Sven P. schrieb:> Es ist deine Einstellung, die mich ganz erheblich stört. Nicht, weil ich> die nicht teilen möchte -- ganz im Gegenteil:>> Ich zitiere sie nun, du bist in der Lage, die betreffenden Stellen zu> finden, damit nicht alles sinnentstellt wird.>> - Konsistenz:>> Konsistent ohne jeden Sinn.> - portable Standards:>> Damit sind die Anwendungen eingeschränkt.
Diese Dinge sind für "mich" ohne jeden Sinn und für "mich" nur
eingeschränkt sinnvoll und im Zusammenhang war das eigentlich auch zu
erkennen, wie ich es meinte.
> - die Möglichkeit, sich Rechte zu beschaffen:>> Dann frage ich mich allerdings wofür das Schutzkonzept überhaupt gut>> sein soll, wenn ich dann eh wie unter DOS alles machen darf.>> - Möglichkeiten durch Geräte(treiber)-orientierte Verwaltung:>> Und damit ist dann das Schutzkonzept ausgehebelt nur weil eine Anwendung>> Port 3DAh auslesen möchte.>> Es stört mich ganz ungemein, dass du auf DOS die letzten 20 Jahre mehr> oder weniger verpennt zu haben scheinst und nun glaubst, Möglichkeiten> und Probleme beurteilen zu können.
Dann stört dich das eben, daran werde ich auch nichts ändern können,
denn das ist nun mal meine Sichtweise der Dinge und ich habe keine Lust
mich mit den Möglichkeiten für Windows/Linux etwas zu programmieren zu
beschäftigen, weil ich mich damit zu eingeschränkt fühle, um damit meine
Ziele zu erreichen. Die Tatsache das ich dort nur Closed-Source-Treiber
verwenden kann ist für mich Grund genug mich damit nicht zu
beschäftigen.
> Dort stecken unzählige Mannstunden> und Ideen drin, die wir hier wirklich nur am äußersten Rande beschreiben> konnten. Und du machst alles zunieder, ohne überhaupt einmal weiter> darüber nachgedacht zu haben.
Wenn du deine Arbeit jetzt damit verunglimpft siehst, dann tut es mir
schrecklich leid, aber es lag niemals in meiner Absicht deine Arbeit
auch nur in irgendeiner Weise herabzuwürdigen, auch dann nicht wenn es
für "mich" keinen Wert darstellt etwas für Windows/Linux zu
programmieren.
> Falls du dich zu arg angegriffen fühlst, bitte ich um Verzeihung, denn> dazu habe ich weder Grund noch Recht.
Gut das wir uns hierüber einig sind. Es gab wohl beidseitig ein paar
Mißverständnisse.
> Ich werde aber schnell stinkig,> wenn man die Leistungen anderer Leute so zerschmettert, ohne> nachzudenken.
Das lag aber nicht in meiner Absicht. Ich habe nur versucht meine
Sichtweise darzulegen.
> Und ich respektiere weiterhin deine Mühe und Ausdauer, wie ich oben> schrob (> Beitrag "Re: C: Pixel auf dem Bildschirm ausgeben" ).
Ich danke dir dafür und respektiere auch deine Arbeit.
> Dennoch beschreibst du ziemlich genau das Sinnbild eines Einzelgängers> in der IT-Abteilung, wie er im Lehrbuch steht.
Da ich keine einzige IT-Abteilung jemals von innen gesehen habe, darum
kann ich das nur schwer nachvollziehen wie man sich dort einen
Einzelgänger vorstellt. Möglicherweise sind solche Dinge auch nur
Vorurteile die aus der Zeit stammen, als man gerade von DOS auf Windows
umstellte und sich dann einige Programmierer aus dem Beruf
verabschiedeteten. Hast du denn überhaupt jemals so einen reinen
DOS-Programmierer in der IT-Abteilung kennengelernt, der sich nicht in
das Team einfügen konnte?
Zuletzt möchte ich noch einmal ausdrücklich darauf hinweisen das alle
meine Ausserungen ausschlieslich dazu dienen sollten meine Sichtweise
darzulegen und es nicht in meiner Absicht liegt jemanden persöhnlich zu
verletzen. Wenn es hierüber mißverständnisse gibt, dann möchte ich auch
dafür bei allen Beteiligten um Verzeihung bitten. Meine Kritik galt
allenfalls den verschiedenen OS, aber nicht den Arbeiten eines einzelnen
Programmierers.
Dirk
Sven P. schrieb:> Um klarzustellen: Es ist mir (und vermutlich auch allen anderen hier)> ziemlich egal, was und wie du programmierst.
Ist mir völlig wurscht.
Mir geht es nur darum, dass ein Fragesteller nicht den falschen Eindruck
bekommt, dass es unbedingt notwendig ist, zum Einzelpixelsetzen auf DOS
und Assembler zurückzugreifen und das dieses das einzig selig machende,
bzw. überhaupt das selig machende ist. Die Empfehlung "Zum lernen der
Grafik-Programmierung musst du auf DOS und Assembler ausweichen" ist für
mich das eigentlich grenzwertige, das nicht mehr sinnvoll ist.
Ab Dirk damit glücklich ist oder nicht .... ist mir eigentlich komplett
egal. Nur sollen sowohl Fragesteller aber auch spätere Leser keinen
falschen Eindruck bekommen, dass diese Art der Programmierung irgendwie
sinnvoll wäre.
Dirk mag in einer speziellen Situation sein. Er ist älter und muss seine
Brötchen nicht mit SW-Entwicklung verdienen. Von daher ist 'Liebhaberei'
schon ok. Wer aber nicht nur aus Liebhaberei mit einem PC arbeitet,
sondern einigermassen auf der höhe der Zeit arbeiten muss (aus welchen
Gründen auch immer), für den ist der Rat sich doch mal DOS+Assembler
anzusehen einfach nur ein schlechter Rat. Denn er ist nicht tragfähig
genug um damit in der Realität des Heute noch etwas zu reißen. Es ist
wie die Empfehlung an einen Elektronik-Lernwilligen, sich seine ersten
Digitalschaltungen aus Röhren aufzubauen.
> Es ging ja auch hierbei zunächst ganz schlicht nur darum einen> Pixwl zu setzen, verglichsweise wie mit dem Quickbasic-Befehl> "Pset(u,v),w"
Wenn du gleich mit der Empfehlung für Quickbasic angefangen hättest,
hätte ich mich zurückgehalten und nichts gesagt.
Karl heinz Buchegger schrieb:
> Die Empfehlung "Zum lernen der> Grafik-Programmierung musst du auf DOS und Assembler ausweichen" ist für> mich das eigentlich grenzwertige, das nicht mehr sinnvoll ist.
Das ist ehrlich gesagt sogar ziemlich bescheuert. Wenn ich
Grafikprogrammierung machen möchte, dann brauche ich auch einen Unterbau
der Grafik gescheit darstellen kann und mir die nötigen Funktionen zum
Zeichen von Linien, Kurven, Laden von Bitmaps und dergleichen in
EINFACHHEIT ermöglicht. Wass soll da Assembler? Was soll da DOS? Das ist
beispielsweise in C# ohne viel Einarbeitung erledigt und selbst in good
old Win32 kein Problem und sicher auch in Linux mit QT oder GTK+ kein
Thema (und macht Spass ;)). Wer kommt denn da auf die Idee überhaupt den
Begriff DOS noch anzuführen?
Sachen gibt's?!
Dirk Wolfgang Glomp schrieb:> chris schrieb:>> Wurde das hier schon mal erwähnt:>> http://www.henkessoft.de/OS_Dev/OS_Dev1.htm>> "Eigene Betriebssystementwicklung am PC - Teil 1"> Diese "deutschsprachige" Seite kannte ich noch nicht. Danke für den> Hinweis.
Wenn dich das Thema interessiert, google auch mal nach "Andrew
Tannenbaum" und "Minix"
>> http://www.henkessoft.de/OS_Dev/OS_Dev1.htm>"Eigene Betriebssystementwicklung am PC - Teil 1">Diese "deutschsprachige" Seite kannte ich noch nicht. Danke für den>Hinweis.
Keine Ursache. Ich bin mal darauf gestoßen, weil es mich interessiert
hat, ob man ein Programm ohne Betriebssystem laufen lassen kann.
Henkessoft ist ja relativ schnell zu einem Ergebnis gekommen. Allerdings
zeigt sich beim durchlesen des Forums zum OS, dass das Ganz wohl doch
ein ziemlich hartes Brot ist. Bei der Umsetzung stoßen die
Projektteilnehemer doch immer wieder auf recht harte "Programmiernüsse".
Karl heinz Buchegger schrieb:> Sven P. schrieb:>> Um klarzustellen: Es ist mir (und vermutlich auch allen anderen hier)>> ziemlich egal, was und wie du programmierst.>> Ist mir völlig wurscht.>> Mir geht es nur darum, dass ein Fragesteller nicht den falschen Eindruck> bekommt, dass es unbedingt notwendig ist, zum Einzelpixelsetzen auf DOS> und Assembler zurückzugreifen und das dieses das einzig selig machende,> bzw. überhaupt das selig machende ist.
Nach meiner Einschätzung wird das doch eh keiner jemals so vermuten.
> Die Empfehlung "Zum lernen der> Grafik-Programmierung musst du auf DOS und Assembler ausweichen" ist für> mich das eigentlich grenzwertige, das nicht mehr sinnvoll ist.
Es gibt aber noch so einige Programmierer die es sinnvoll genug finden.
Auch ist in meiner GTX295 auch immer noch ein VBE3-Bios enthalten, wovon
die meisten Funktionen dort für den RM entwickelt wurden. wie etwa auch
das Einschalten verschiedener Vesamodi. Bei mir bis zu einer Auflösung
von 1920x1200x32. Zu DOS-Zeiten gab es derartig hohe Modi doch noch gar
nicht.
> Ab Dirk damit glücklich ist oder nicht .... ist mir eigentlich komplett> egal. Nur sollen sowohl Fragesteller aber auch spätere Leser keinen> falschen Eindruck bekommen, dass diese Art der Programmierung irgendwie> sinnvoll wäre.
Ob es sinnvoll ist kann ja nur jeder für sich selber entscheiden und es
gibt ja auch noch genug Unterstützung für DOS von anderen Sprachen wie
etwa C z.B.: http://www.delorie.com/djgpp/> Dirk mag in einer speziellen Situation sein. Er ist älter und muss seine> Brötchen nicht mit SW-Entwicklung verdienen. Von daher ist 'Liebhaberei'> schon ok. Wer aber nicht nur aus Liebhaberei mit einem PC arbeitet,> sondern einigermassen auf der höhe der Zeit arbeiten muss (aus welchen> Gründen auch immer), für den ist der Rat sich doch mal DOS+Assembler> anzusehen einfach nur ein schlechter Rat.
Wie aber kommst du auf die Idee das es beim Fragesteller, der nach dem
Setzen von Pixeln fragte, nicht nur um eine reine Liebhaberei sich
handelt, oder anders herum gefragt, ist das denn eine typische Frage die
man stellt, wenn man es vor hat es mehr als eine Liebhaberei werden zu
lassen?
Ich kann mich zwar auch täuschen, aber für mich sieht die Frage doch
schon eher wie eine Frage aus, die aus dem Bereich Liebhaberei stammt
und genau deswegen habe ich meine DOS-Beispiele hier erwähnt.
> Denn er ist nicht tragfähig> genug um damit in der Realität des Heute noch etwas zu reißen.
Für eine reine Liebhaberei, die es nach meiner Vermutung auch ist,
dafür genügen solche DOS-Beispiele doch voll und ganz, um es zu lernen
wie man einen Pixel setzt.
> Es ist> wie die Empfehlung an einen Elektronik-Lernwilligen, sich seine ersten> Digitalschaltungen aus Röhren aufzubauen.
Von Elektronik habe ich leider aber überhaupt keine Kenntnisse.
>> Es ging ja auch hierbei zunächst ganz schlicht nur darum einen>> Pixwl zu setzen, verglichsweise wie mit dem Quickbasic-Befehl>> "Pset(u,v),w">> Wenn du gleich mit der Empfehlung für Quickbasic angefangen hättest,> hätte ich mich zurückgehalten und nichts gesagt.
Das Beispiel mit Quickbasic hat doch der Fragesteller schon selber
erwähnt und wollte darüber hinaus einfach mal erfahren, wie man es denn
sonnst noch machen kann. Somit scheidet eine Quickbasic-Antwort aus und
ist meine DOS-Anwort eine Alternative, die für eine Liebhaberei völlig
ausreichen könnte.
Dirk
chris schrieb:> Autor:> Hier der Link: Beitrag "Programm für PC ohne Betriebssystem"
Ah, danke schön. Dort schreibe ich auch gleich noch etwas dazu.
Dirk
chris schrieb:>>> http://www.henkessoft.de/OS_Dev/OS_Dev1.htm>>>"Eigene Betriebssystementwicklung am PC - Teil 1">>Diese "deutschsprachige" Seite kannte ich noch nicht. Danke für den>>Hinweis.>> Keine Ursache. Ich bin mal darauf gestoßen, weil es mich interessiert> hat, ob man ein Programm ohne Betriebssystem laufen lassen kann.>> Henkessoft ist ja relativ schnell zu einem Ergebnis gekommen. Allerdings> zeigt sich beim durchlesen des Forums zum OS, dass das Ganz wohl doch> ein ziemlich hartes Brot ist. Bei der Umsetzung stoßen die> Projektteilnehemer doch immer wieder auf recht harte "Programmiernüsse".
Ich selber habe damit eigentlich noch keine eigenen Erfahrungen
gesammlt, aber ein paar Haken und Ösen gibt es damit ganz bestimmt.
Dirk
Senfdazugeber schrieb:> Karl heinz Buchegger schrieb:>>> Die Empfehlung "Zum lernen der>> Grafik-Programmierung musst du auf DOS und Assembler ausweichen" ist für>> mich das eigentlich grenzwertige, das nicht mehr sinnvoll ist.>> Das ist ehrlich gesagt sogar ziemlich bescheuert.
Ja natürlich gibt es auch andere Möglichkeiten und davon das man
auf DOS und Assembler ausweichen "muss" war ja auch eigentlich nie die
Rede.
> Wenn ich> Grafikprogrammierung machen möchte, dann brauche ich auch einen Unterbau> der Grafik gescheit darstellen kann und mir die nötigen Funktionen zum> Zeichen von Linien, Kurven, Laden von Bitmaps und dergleichen in> EINFACHHEIT ermöglicht. Wass soll da Assembler? Was soll da DOS?
Es ist doch gar nicht so schwer zu lernen wie man mit Assembler und DOS
ein paaar Pixel setzt, eine Linie und Kurven zeichnet und ein Bild
einläd und zum Bildschirm bringt.
> Das ist> beispielsweise in C# ohne viel Einarbeitung erledigt und selbst in good> old Win32 kein Problem und sicher auch in Linux mit QT oder GTK+ kein> Thema (und macht Spass ;)). Wer kommt denn da auf die Idee überhaupt den> Begriff DOS noch anzuführen?
Na ich mache das und auch noch Andere die DOS immer noch benutzen.
DOS stirbt nicht aus, solange es noch Hardware dafür gibt.
> Sachen gibt's?!
Tja, mit Klickibunti kann sich nun mal nicht jeder anfreunden.
So habe ich auch eine Weile nur die Linux-Konsole (mit fb0-device und
PCI-Matrox(4MB)) verwendet und damit selber in den gemapten framebuffer
des 1024x768x32 Bildbereichs hinein geschrieben. Leider konnte ich
bisher keine andere GraKa dazu überreden FB-Modi mit 32Bit/Color zu
verwenden, obwohl die verwendeten GraKas Vesamodi mit 32Bit zur
Verfügung stellen und dafür auch mehr als genug GraKa-Ram mitbringen.
Die liefen alle nur mit 24Bit/Color mit dem fb0-Device. Wie blöd ist das
denn heute überhaupt noch 24Bit/Color-Modi zu verwenden?
Kennt jemand eine Möglichkeit das fb0-Device auf 32Bit/Color
umzustellen?
Dirk
Der Unterschied zwischen 24 und 32 Bit liegt hier nur daran, daß bei
24-Bit nicht ein ungenutztes Byte für jedes Pixel herumliegt, was die
Berechnung der Adressen der einzelnen Pixel natürlich einen Hauch
komplizierter macht.
Mehr als 8 Bit je Grundfarbe geben Graphikkarten üblicherweise nicht
aus, welches Anzeigegerät sollte die auch verarbeiten? Der analoge
Signalweg (der leider immer noch nicht ausgestorben ist) ist damit
komplett überfordert, und Monitore mit mehr als 8 Bit Auflösung je
Grundfarbe sind ziemlich selten.
Ja, zu DOS-Zeiten war alles viel einfacher, besonders die autoexec.bat
und config.sys so hinzubekommen, das alle Programme damit liefen, war
nie ein Problem :-) Und keine gigabytegroßen Programme, da kann man
schon in 181 Bytes was schönes machen:
http://www.frank-buss.de/automaton/arabeske.html
Ab Windows Vista tat es das bei meinem Rechner aber leider nicht mehr,
Windows XP ging noch.
> Es ist doch gar nicht so schwer zu lernen wie man mit Assembler und DOS> ein paaar Pixel setzt, eine Linie und Kurven zeichnet und ein Bild> einläd und zum Bildschirm bringt.
Ohne einen ordentlichen 32-bit Betriessystemunterbau (ob der Windows,
Linux, Mac oder sonstwie heißt) wird das nun mal nix. Da bleiben dir nur
langsame DOS oder VESA BIOS Extensions. Grafikprogrammierung ist auch
mehr als nur ein paar Pixel zum leuchten zu bringen. Schau mal was C#
für ein mannigfaltiges Konglomerat von Zeichenfunktionen bereitstellt
inkl. diverser Transformationen usw. und das noch dazu für die
verschiedensten Ausgabegeräte. Das alles bietet dir kein DOS. Überhaupt,
was willst du denn andauend mit DOS? Wo habe ich noch gleich mein eagle
für DOS? Wo habe ich noch gleich meinen PDF reader für DOS? Wo habe ich
noch gleich mein Bildbearbeitungsprogramm für DOS? Wo habe ich noch
gleich ..
> Tja, mit Klickibunti kann sich nun mal nicht jeder anfreunden.
Erst die klickbaren Oberflächen haben massenhafte Verbreitung von
Computern ermöglicht, hast du das schon vergessen? Du magst wohl lieber
die Steinzeit-EDV von vorvorvor .. gestern was? :-)
Selbst Arztpraxen haben immer seltener noch DOS Software im Turbo-Vision
Mantel laufen. Da hat Windows längst einzug gehalten, sonst würde kein
moderner Drucker/Scanner mehr laufen etc. Nix mit DOS.
Verstehe mich bitte nicht falsch. Ich persönlich stehe durchaus auf
"oldschool" Assembler und co. Ist alles sehr interessant. Aber bitte
versuche mir nicht ein altes DOS von Anno Dunnemals als die bessere
Alternative zu heutigen Hochleistungsrechnern wie wir sie alle permanent
nutzen (HW+SW) zu "verkaufen". Bitte nicht ..
;-)
> Eagle gab es schon für DOS, habe damit noch gearbeitet.
Ich weiß. Ich kann mich auch noch an die nette "Aktion" von Cadsoft
erinnern. Fast wäre ich auch dabei gewesen. War glaube ich die v2.6.
Davon abgesehen, gegen die Win Version würde ich die nicht mehr
vorziehen.
Ohne jetzt unbedingt abtrifften zu wollen: Es gibt jetzt Ersatz für
Eagle. Nämlich KiCad ....
http://kicad.sourceforge.net/wiki/index.php/DE:Main_Page
Hat angeblich schon ein große Community. Hat es von euch schon mal
jemand probiert?
Mal eine Frage an den TE (um die DOS/Windows Diskussion mal
abzuschwächen):
Warum muss es denn DOS sein?
Ist es eine selbstgewählte Aufgabenstellung oder kommt sie vom Kunden
oder Ausbilder oder was auch immer?
Der arme Threadstarter hat wahrscheinlich ob der endlosen Diskussion an
seinem Thema vorbei schon kapituliert. ;-)
Dabei ist Pixelsetzen selbst unter Win32 eigentlich ein Kinderspiel.
Einfaches Beispiel zum weiteren experimentieren. Die IDE zum compilieren
gibt's von Pelle Orinius. Das geht am einfachsten für simple, schnelle
Experimente:
Klar, geht alles mit Win32. Bei deinem Beispiel fehlt übrigens noch ein
EndPaint. Außerdem wollte er ja was mit Fraktalen experimentieren. Das
dann jeweils in WM_PAINT neu zu berechnen und zu zeichnen ist wohl keine
gute Idee. Kann man auch noch erweitern, z.B. eine Offscreen-Bitmap,
habe ich auch schon gemacht, aber man muß sich mit Pixelformaten usw.
herumschlagen, was man eigentlich nicht will.
So geht es z.B. mit SDL, inklusiv Caching der Bitmap, Window-Anzeige und
Tastaturabfrage:
http://www.friedspace.com/cprogramming/SDLTest.c
Das Programm läuft dann ohne Änderungen, nur Neucompilierung, unter
Windows, MacOSX und Linux.
Rufus Τ. Firefly schrieb:> Der Unterschied zwischen 24 und 32 Bit liegt hier nur daran, daß bei> 24-Bit nicht ein ungenutztes Byte für jedes Pixel herumliegt, was die> Berechnung der Adressen der einzelnen Pixel natürlich einen Hauch> komplizierter macht.
Ja genau und das ist der entscheidende Punkt meiner Kritik. Denn bei
32Bit-Truecolor genügt ein einziger MOV-Befehl um ein Pixel zu setzen,
während man bei 24Bit-Truecolor mindestens zwei MOV-Befehle benötigt, da
es keine 24Bit-Befehle gibt. Dazu lassen sich 32 bittige Adressenangaben
auch besser skalieren, da die die CPU(ab 80386+) dafür spezielle Befehle
bereitstellt. Siehe dazu das "Scaled Index byte":
http://www.sandpile.org/ia32/opc_sib.htm
Dirk
> Bei deinem Beispiel fehlt übrigens noch ein> EndPaint.
Oh ja, hab ich mir "weggepastet". Sollte nicht fehlen!
> Außerdem wollte er ja was mit Fraktalen experimentieren. Das> dann jeweils in WM_PAINT neu zu berechnen und zu zeichnen ist wohl keine> gute Idee.
In WM_PAINT braucht man das auch nicht zu berechnen. Nur die
Grafikausgabe für das Neuzeichnen gehört dort hinein. Er kann in eine
Bitmap zeichnen und diese dann in der Paintnachricht ausgeben.
Nur der Vollständigkeit halber und per cut&paste direkt benutzbar:
Senfdazugeber schrieb:>> Es ist doch gar nicht so schwer zu lernen wie man mit Assembler und DOS>> ein paaar Pixel setzt, eine Linie und Kurven zeichnet und ein Bild>> einläd und zum Bildschirm bringt.>> Ohne einen ordentlichen 32-bit Betriessystemunterbau (ob der Windows,> Linux, Mac oder sonstwie heißt) wird das nun mal nix. Da bleiben dir nur> langsame DOS oder VESA BIOS Extensions.
Der RM ist doch selber gar nicht langsmaer als der PM, besonders die
Segmentzugriffe sind im PM sogar langsamer.
> Grafikprogrammierung ist auch> mehr als nur ein paar Pixel zum leuchten zu bringen. Schau mal was C#> für ein mannigfaltiges Konglomerat von Zeichenfunktionen bereitstellt> inkl. diverser Transformationen usw. und das noch dazu für die> verschiedensten Ausgabegeräte. Das alles bietet dir kein DOS.
Ja das ist ärgerlich das es keine umfassende Puplic-Dokumente mehr gibt
für moderne Hardware.
>> Tja, mit Klickibunti kann sich nun mal nicht jeder anfreunden.>> Erst die klickbaren Oberflächen haben massenhafte Verbreitung von> Computern ermöglicht, hast du das schon vergessen?
Das ist ja das Übel.
> Du magst wohl lieber> die Steinzeit-EDV von vorvorvor .. gestern was? :-)
Nö das nicht, doch bitte die neue Hardware auch umfassend dokumentieren.
Es ist ja nicht so das ich privat ein Rechner zum Leben unbeding
brauche.
> Selbst Arztpraxen haben immer seltener noch DOS Software im Turbo-Vision> Mantel laufen. Da hat Windows längst einzug gehalten, sonst würde kein> moderner Drucker/Scanner mehr laufen etc. Nix mit DOS.
Als Arztpraxis würde ich lieber auf Nixen setzen.
> Verstehe mich bitte nicht falsch. Ich persönlich stehe durchaus auf> "oldschool" Assembler und co. Ist alles sehr interessant. Aber bitte> versuche mir nicht ein altes DOS von Anno Dunnemals als die bessere> Alternative zu heutigen Hochleistungsrechnern wie wir sie alle permanent> nutzen (HW+SW) zu "verkaufen". Bitte nicht ..
Für mich ist es die bessere Alternative zum Programmieren geblieben.
Dirk
Rufus Τ. Firefly schrieb:> Der Threadstarter hat sich überhaupt nicht über DOS ausgelassen, das hat> alles Dirk Wolfgang losgetreten.
Ja ich bekenne mich schuldig im Sinne der Anklage.
Dirk
Dirk Wolfgang Glomp schrieb:> Senfdazugeber schrieb:>>> Es ist doch gar nicht so schwer zu lernen wie man mit Assembler und DOS>>> ein paaar Pixel setzt, eine Linie und Kurven zeichnet und ein Bild>>> einläd und zum Bildschirm bringt.>>>> Ohne einen ordentlichen 32-bit Betriessystemunterbau (ob der Windows,>> Linux, Mac oder sonstwie heißt) wird das nun mal nix. Da bleiben dir nur>> langsame DOS oder VESA BIOS Extensions.>> Der RM ist doch selber gar nicht langsmaer als der PM, besonders die> Segmentzugriffe sind im PM sogar langsamer.
Der springende Punkt ist:
Das interessiert im Grunde die wenigsten.
Wenn ich einen Funktionsplotter mache, dann ist mir die
Malgeschwindigkeit aber sowas von gleichgültig. Ob der Rechner jetzt 3
oder 5 Millisekunden braucht um die Kurve hinzumalen ist sowas von
uninteressant. Ich kann als Mensch den Unterschied sowieso nicht
feststellen. Wenns schnell genug ist, dann ist es schnell genug. Noch
schneller muss es nicht sein.
Was mich aber interessiert sind Dinge wie Zoomen, im gezooomten Bereich
scrollen, Positionen identifizieren mit der Maus, Beschriftungen
anbringen, Masstäbe berechnen lassen und einstellen, auf jeden
beliebigen Drucker ausgeben (auch im Netzwerk), etc.
Und das ganze möglichst so, dass mir nicht der Entwickler erst mal 15
Minuten lang erklären muss, wies funktioniert und über welch
verschrobenen Wege icdh welche Funktionalität erreichen kann.
>> für ein mannigfaltiges Konglomerat von Zeichenfunktionen bereitstellt>> inkl. diverser Transformationen usw. und das noch dazu für die>> verschiedensten Ausgabegeräte. Das alles bietet dir kein DOS.>> Ja das ist ärgerlich das es keine umfassende Puplic-Dokumente mehr gibt> für moderne Hardware.
Das ist auch gar nicht notwendig. Denn >95% der kompletten
Grafik-Programmierung ist nicht hardwareabhängig. Wie senfdazugeber
schon schrieb: Grafikprogrammierung ist mehr als nur ein paar Pixel da
und dort setzen. Viel mehr!
Senfdazugeber schrieb:> SetPixel(hdc, cxClient/2 + 1, cyClient/2, RGB(255,0,0));
Super, endlich wird mal eine konketes Beispiel gepostet, auch wenn es
mir keinen Spaß machen würde auf diese Weise ein Pixel zu setzen.
Dirk
Und es geht einfacher als Frank Buss' Beispiel, wo man erst man die SDL
korrekt einbunden muss (für Anfänger womöglich die erste
"unüberwindbare" Hürde). ;)
Und wieso kein Spass? Die Zeile ist doch schön selbsterklärend. Das
Pixelkreuz erscheint in der Mitte mit dem (24-bit) Farbwert rot.
Karl heinz Buchegger schrieb:> Dirk Wolfgang Glomp schrieb:>> Senfdazugeber schrieb:>>>> Es ist doch gar nicht so schwer zu lernen wie man mit Assembler und DOS>>>> ein paaar Pixel setzt, eine Linie und Kurven zeichnet und ein Bild>>>> einläd und zum Bildschirm bringt.>>>>>> Ohne einen ordentlichen 32-bit Betriessystemunterbau (ob der Windows,>>> Linux, Mac oder sonstwie heißt) wird das nun mal nix. Da bleiben dir nur>>> langsame DOS oder VESA BIOS Extensions.>>>> Der RM ist doch selber gar nicht langsmaer als der PM, besonders die>> Segmentzugriffe sind im PM sogar langsamer.>> Der springende Punkt ist:> Das interessiert im Grunde die wenigsten.
Das wollte ich nur anmerken weil hier die Rede vom angeblich langsamen
DOS war und auch vom DOS aus gesartet kann eine Anwendung ebenso in den
PM schalten und die dortigen Funktionalität der CPU genauso nutzen wie
Windows/Linux es macht. DOS ist hierbei eben gar nicht langsamer.
> Wenn ich einen Funktionsplotter mache, dann ist mir die> Malgeschwindigkeit aber sowas von gleichgültig. Ob der Rechner jetzt 3> oder 5 Millisekunden braucht um die Kurve hinzumalen ist sowas von> uninteressant. Ich kann als Mensch den Unterschied sowieso nicht> feststellen. Wenns schnell genug ist, dann ist es schnell genug. Noch> schneller muss es nicht sein.
Da gebe ich dir Recht, oft wartet die CPU einfach nur.
> Was mich aber interessiert sind Dinge wie Zoomen, im gezooomten Bereich> scrollen, Positionen identifizieren mit der Maus, Beschriftungen> anbringen, Masstäbe berechnen lassen und einstellen,
Das ist auch alles unter DOS möglich.
> auf jeden> beliebigen Drucker ausgeben (auch im Netzwerk), etc.
Mit der Hardware und den fehlenden Dokumenten bzw. Treiber für DOS wird
es schwer bis unmöglich.
> Und das ganze möglichst so, dass mir nicht der Entwickler erst mal 15> Minuten lang erklären muss, wies funktioniert und über welch> verschrobenen Wege icdh welche Funktionalität erreichen kann.
So etwas ist nicht vom verwendeten OS abhängig.
>>> für ein mannigfaltiges Konglomerat von Zeichenfunktionen bereitstellt>>> inkl. diverser Transformationen usw. und das noch dazu für die>>> verschiedensten Ausgabegeräte. Das alles bietet dir kein DOS.
Trotzdem kann man auch dort so etwas programmieren. Nur weil es so gut
wie keiner macht bedeutet das ja nicht das es nicht gehen würde. Das
selbe Dilemma ist doch mit Linux und den 3D-Spielen. Ich vermute mal das
wenn einige der großen Spieleschmiede erst einmal auf Linux ausweichen,
dann werden schon einige Gamer mehr sich schon früher von Windows
komplett verabschieden. Ich betrachte Windows eh nur als Spiele-OS.
>> Ja das ist ärgerlich das es keine umfassende Puplic-Dokumente mehr gibt>> für moderne Hardware.>> Das ist auch gar nicht notwendig. Denn >95% der kompletten> Grafik-Programmierung ist nicht hardwareabhängig. Wie senfdazugeber> schon schrieb: Grafikprogrammierung ist mehr als nur ein paar Pixel da> und dort setzen. Viel mehr!
Nur die andere 5% braucht man eben dafür um es auch darzustellen.
Dirk
Senfdazugeber schrieb:> Und wieso kein Spass? Die Zeile ist doch schön selbsterklärend. Das> Pixelkreuz erscheint in der Mitte mit dem (24-bit) Farbwert rot.
Ja eben, weil ich stehe ja eigentlich nicht so gerne nur an einem
Lichtschalten und knipse ihn an und wieder aus, das ist mir einfach zu
langweilig.
Mit Assembler programmiert gibt es eine erheblich größere Anzahl an
Möglichkeiten ein Ziel zu erreichen und genau hier liegt der Reiz
verborgen, z.B das man die eine Routine an eine andere Routinen
entsprechend anpassen kann und damit auch einen effizienterer Code für
beide Routinen erzielen kann. Also wenn schon Windows dann MASM32, auch
wenn mich das persöhnlich auch nicht sehr reizt überhaupt etwas für
Windows zu programmieren. http://www.masm32.com/
Dirk
Rufus Τ. Firefly schrieb:
Dirk Wolfgang Glomp schrieb:
>> Also wenn schon Windows dann MASM32> Um Gottes Willen!
hehe, köstlich! :-)
eigentlich doch auch nicht so viel anders, läuft doch alles über invoke
ab
invoke CreateWindowEx, ..
invoke GetModuleHandle, NULL
mov hInstance, eax
invoke GetSystemMetrics,SM_CXSCREEN
mov sWid, eax
Ob's was bringt? (außer dem Gefühl für echte Männer, die Schweiße ihres
Angesichts den Assembler befüttern .. ;))
Wenn man nicht zur Befriedigung der eigenen Lust am Erwerb arkanen
Wissens programmiert, dann lässt man bei PC-Programmierung die Finger
von Assembler.
Die Gründe entsprechen denen, aus denen man auch von solchen Dingen wie
DOS die Finger lässt.
Rufus Τ. Firefly schrieb:> Wenn man nicht zur Befriedigung der eigenen Lust am Erwerb arkanen> Wissens programmiert, dann lässt man bei PC-Programmierung die Finger> von Assembler.
Du meinst wohl eher, wenn man keine Ahnung von Assembler und von 32 Bit
Windows API hat, dann lässt man besser die Finger von MASM32?
> Die Gründe entsprechen denen, aus denen man auch von solchen Dingen wie> DOS die Finger lässt.
Von welchen gemeinsamen Gründen redest du jetzt genau?
http://www.codingcrew.de/masm32/index.php
Warum in 32 Bit Assembler programmieren?
1] Hochleistungsprogramme
Programme, welche mit dem Macro Assembler erstellt wurden, haben
Vorteile sowohl in der Dateigröße als auch in ihrer
Ausführungsgeschwindigkeit, welche weit über die Möglichkeiten der
besten Compiler hinaus gehen. Programme welche auf Hochleistung getunt
werden müssen, sind daher meist immer ein Produkt von reinen
Assembler-Programmen.
2] Dynamic Link Libraries
Der Macro Assembler ist in der Lage äußerst leistungsfähige DLL Dateien
zu erstellen, welche von MASM selbst, Visual C/C++ und Visual Basic
sowie jeder anderen Programmiersprache die DLL Prozeduren aufrufen kann
verwendet werden können. Das erlaubt dem Programmierer rechenintensive
Algorithmen zu schreiben, welche außergewöhnlich weit über dem Horizont
von normalen Programmiersprachen liegen.
3] Library Module für Microsoft Visual C/C++ Anwendungen
Der Macro Assembler produziert genau das selbe Object Module Format,
welches von Visual C/C++ Compilern verwendet wird, so dass der C/C++
Programmierer Module oder Bibliotheken in MASM schreiben und diese
direkt in sein eigenes C/C++ Programm einbinden kann. Dies erlaubt dem
C/C++ Programmierer ihre kritischen Teile des Programmcodes in einer
sehr effizienten und angenehmen Weise zu realisieren:
Grafikverarbeitung, Spiele, Datenverarbeitung mit extrem hoher
Geschwindigkeit, Parsing-Speed welche die meisten Programmierer noch nie
gesehen haben, Verschlüsselung, Komprimierung und jegliche andere Form
von prozessorintensiver Informationsverarbeitung.
Dirk
http://www.codingcrew.de/masm32/masm32_faq.php
MASM32-Support: FAQ
Assemblerprogramme sollen sehr schnell bzw. die schnellsten überhaupt
sein. Sind die Programme auch schneller als C++?
Assembler hat deutliche Vorteile gegenüber Hochsprachen (wie z.B. C++).
Wie schnell die Assemblerprogramme im Endeffekt sind hängt aber vom
Programmierer ab. Wenn man äußerst umständlich programmiert, dann kann
man natürlich nicht mit einem großen Geschwindigkeitsvorteil rechnen.
Dasselbe gilt für ein Assemblerprogramm, welches hauptsächlich
Windows-API-Funktionen aufruft. In diesem Fall bietet Assembler keinen
merklichen Geschwindigkeitsgewinn, da die Windows-API-Funktionen
schließlich von Windows ausgeführt werden (welches bis auf wenige Teile
nicht in Assembler geschrieben ist).
Wenn man aber Programmcode hat, welcher seinen Zweck zum größten Teil
ohne API-Aufrufe realisiert (z.B. Berechnungen bei Grafikprogrammen,
Komprimierverfahren, Sortierverfahren bei großen Datenmengen, etc.),
dann ist es besser diesen Code in Assembler umzusetzen um die
Geschwindigkeitsvorteile der Assemblersprache zu nutzen.
Das soll aber nicht heißen, dass C++-Programme langsam sind. In der
IT-Branche wird zum Beispiel kaum eine Software komplett in Assembler
geschrieben, weil die entsprechenden Problemlösungen in den Hochsprachen
oft schneller, bzw. einfacher entwickelt werden können.
Dirk
Nein. Assemblerprogramme sind sehr schlecht wartbar und nicht
portierbar. Obendrein sind sie wegen der nichtexistenten Typüberprüfung
und Runtimechecks sehr fehlerträchtig.
Deswegen programmiert man nur noch, wenn es wirklich nicht anders geht,
in Assembler.
Das hat nichts mit "Ahnung haben" zu tun, sondern mit Effizienz.
Wenn man den Erwerb arkanen Wissens als Lebensziel hat, dann kann man
sich damit gerne beschäftigen, aber für andere ist das so nutzlos wie
das von mir bereits in diesem Kontext erwähnte Trainieren von Dodos.
Richtig.
Ansonsten ist das sehr optimistisch formuliert. Ich bezweifle
jedenfalls, dass ein einziger Mensch noch in der Lage ist, alle
Möglichkeiten bei einem modernen Prozessor auszunutzen, die ein Compiler
berücksichtigt:
- branch prediction,
- Hypterthreading,
- Befehlsumsortierung (reservation stage!),
- MMX, SSE, ...
- Pipeline-Hemmnisse,
- ...
Größere Programme in Assembler umzusetzen ist Käse. Dabei verschwendet
man viel zu viel Zeit auf Programmteile, deren Effizienz nebensächlich
ist. Effizienz in der Softwareentwicklung bedeutet daneben nicht nur,
dass ein Programm 'schnell' läuft, sondern auch, dass es wartbar,
wiederverwertbar, haltbar ist.
Bei der WinAPI ist Hopfen und Malz ohnehin größtenteils verloren, da
hilft auch kein Assembler mehr... das fängt bei der Fehlinterpretation
der ungarischen Notation an.
Dirk Wolfgang Glomp schrieb:> 1] Hochleistungsprogramme> Programme, welche mit dem Macro Assembler erstellt wurden, haben> Vorteile sowohl in der Dateigröße als auch in ihrer> Ausführungsgeschwindigkeit, welche weit über die Möglichkeiten der> besten Compiler hinaus gehen. Programme welche auf Hochleistung getunt> werden müssen, sind daher meist immer ein Produkt von reinen> Assembler-Programmen.
Das ist nur bedingt der Fall bei heutigen Systemen. Ich habe z.B. mal
aus einem ARM-Referenzhandbuch eine handoptimierte Assembler-Routine für
FIR-Filterberechnung gesehen. Hatte ich dann in C nachprogrammiert und
war immer noch halb so schnell, was nicht die Welt ist und für viele
Fälle ausreicht. Der Assembler-Code war allerdings mehrere Seiten lang,
das C Programm nur wenige Zeilen. Lohnt sich in den meisten Fällen
nicht.
Auf dem PC sieht es noch schlimmer aus: Gute C Compiler kennen alle
möglichen Tricks mit MMX, optimaler Pipeline-Ausnutzung und was es sonst
noch so alles gibt. Sowas kann man von Hand kaum noch überbieten.
Aber es geht sogar schneller, als ein für einen Prozessor
handgeschriebenes Assembler-Programm: In Java ist ein Just-In-Time
Compiler eingebaut. Der kann je nach CPU (theoretisch) optimalen Code
erzeugen. Von Hand müsste man das für die verschiedenen CPUs jeweils neu
schreiben für dieselben optimalen Ergebnisse.
Fazit: auch wenn man viel Zeit hat, lohnt es sich heutzutage nicht mehr,
in Assembler zu programmieren. Außer vielleicht für einige Low-Level
Dinge, wie DSP-Programmierung und sehr zeitkritischen Schleifen, für die
man keinen guten C-Compiler hat oder wo es von Hand vielleicht
tatsächlich für genau diese eine DSP-Architektur schneller ist.
DLL und statische Libraries schreiben geht mit C auch.
Dirk Wolfgang Glomp schrieb:> Wenn man aber Programmcode hat, welcher seinen Zweck zum größten Teil> ohne API-Aufrufe realisiert (z.B. Berechnungen bei Grafikprogrammen,> Komprimierverfahren, Sortierverfahren bei großen Datenmengen, etc.),> dann ist es besser diesen Code in Assembler umzusetzen um die> Geschwindigkeitsvorteile der Assemblersprache zu nutzen.
oo, ich habe nicht den ganzen Thread vollständig gelesen, aber oben
zitierte Bemerkung schlägt jetzt doch etwas seltsam in meinem Gehirn
ein....
Jetzt mal im Ernst Dirk, wenn man solch einen Spruch los lässt negiert
man alles, was Generationen von Informatiker und Programmierer
geschaffen haben. Damit stellt du sämtliche Dinge, die jemals auf Basis
der alt bekannten PC-Hardware geschrieben wurden in Frage... selbst dein
soviel gelobtes DOS ist damit außen vor!
Wenn das deine ernsthafte Meinung sein sollte, fange am besten gleich
heute an dein eigenes Betriebssystem zu schreiben. Die Frage ist dann
halt nur, wann du damit fertig bist!
Mahlzeit
>Wenn das deine ernsthafte Meinung sein sollte, fange am besten gleich>heute an dein eigenes Betriebssystem zu schreiben.
ja, da muss doch glatt nochmal das hier erwähnt werden:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm
Rufus Τ. Firefly schrieb:> Nein. Assemblerprogramme sind sehr schlecht wartbar und nicht> portierbar.
Assemblerprogramme sollen ja auch gar nicht portierbar sein, weil sie ja
eben nur für eine bestimmte Reihe von CPUs optimiert wurden.
Das sie schlechter wartbar sind glaube ich allerdings eher weniger.
> Obendrein sind sie wegen der nichtexistenten Typüberprüfung> und Runtimechecks sehr fehlerträchtig.
Das kommt ja wohl ebenso wie bei der Wartbarkeit auf die jeweiligen
Fähigkeiten des Programmierers an, ob sich Fehler einschleichen und der
Code wartbar ist.
> Deswegen programmiert man nur noch, wenn es wirklich nicht anders geht,> in Assembler.
Ich denke eher das es halt nur länger dauert in Assembler etwas zu
entwickeln.
> Das hat nichts mit "Ahnung haben" zu tun, sondern mit Effizienz.
Wenn du die Effizienz in Hinblick auf die Eintwicklungszeit betrachtest
mag das stimmen, doch der Code selber kann effizienter gestaltet werden
als jeder Compiler dazu in der Lage ist. Ob so eine hohe Effizienz dann
auch immer benötigt wird ist eine andere Frage.
> Wenn man den Erwerb arkanen Wissens als Lebensziel hat, dann kann man> sich damit gerne beschäftigen, aber für andere ist das so nutzlos wie> das von mir bereits in diesem Kontext erwähnte Trainieren von Dodos.
Über Nutzlosigkeit braucht man in diesem Zusammenhang eigentlich doch
gar nicht reden, Fakt ist das man mit MASM32 eben genauso gut
Anwendungen erstellen kann, wenn man mit der Materrie genug vertraut ist
und auch die nötige Zeit dafür hat.
Dirk
Sven P. schrieb:> Richtig.>> Ansonsten ist das sehr optimistisch formuliert. Ich bezweifle> jedenfalls, dass ein einziger Mensch noch in der Lage ist, alle> Möglichkeiten bei einem modernen Prozessor auszunutzen, die ein Compiler> berücksichtigt:>> - branch prediction,> - Hypterthreading,> - Befehlsumsortierung (reservation stage!),> - MMX, SSE, ...> - Pipeline-Hemmnisse,> - ...
Ja aber sicher kann auch ein einzelner Mensch solche Dinge
berücksichtigen wenn genügend Zeit vorhanden ist und es eben nicht auf
eine schnelle Fertigstellung so drauf an kommt. Eine hohe Qualität
braucht nun mal eine gewisse Zeit.
> Größere Programme in Assembler umzusetzen ist Käse.
Lecker, als Liebhaber von Käse betrachte ich das jetzt mal als ein
Anreiz.
> Dabei verschwendet> man viel zu viel Zeit auf Programmteile, deren Effizienz nebensächlich> ist.
Eigentlich benutzt man solche Fein-Werkzeuge ja nicht nur um damit
Kohlen im Keller zu schippen. Sondern man begibt sich damit auch an die
Baustellen deren Effizienz in Form von Auführungsgeschwindigkeit eben
höher liegt.
> Effizienz in der Softwareentwicklung bedeutet daneben nicht nur,> dass ein Programm 'schnell' läuft, sondern auch, dass es wartbar,> wiederverwertbar, haltbar ist.
Ist es doch alles wenn man nur den Code betrachtet, nur eben mit einem
höheren zeiltlichen Aufwand bei der Entwicklung.
> Bei der WinAPI ist Hopfen und Malz ohnehin größtenteils verloren, da> hilft auch kein Assembler mehr... das fängt bei der Fehlinterpretation> der ungarischen Notation an.
Auch aus diesem Grund tue ich mir das persöhnlich erst gar nicht an,
mich mit solchen Widrigkeiten abzuplagen.
Dirk
Frank Buss schrieb:> Dirk Wolfgang Glomp schrieb:>> 1] Hochleistungsprogramme>> Programme, welche mit dem Macro Assembler erstellt wurden, haben>> Vorteile sowohl in der Dateigröße als auch in ihrer>> Ausführungsgeschwindigkeit, welche weit über die Möglichkeiten der>> besten Compiler hinaus gehen. Programme welche auf Hochleistung getunt>> werden müssen, sind daher meist immer ein Produkt von reinen>> Assembler-Programmen.>> Das ist nur bedingt der Fall bei heutigen Systemen.
Na klar kann man auch mit Assembler weniger effizient arbeiten.
> Ich habe z.B. mal> aus einem ARM-Referenzhandbuch eine handoptimierte Assembler-Routine für> FIR-Filterberechnung gesehen. Hatte ich dann in C nachprogrammiert und> war immer noch halb so schnell, was nicht die Welt ist und für viele> Fälle ausreicht.
Ja wenn so eine hohe Ausführungsgeschwindigkeit nocht erforderlich ist,
dann genügt auch eine weniger effiziente Methode. Aber es gibt nun mal
auch Baustellen wo es genau anders herum ist und man eben jeden
Geschwindikeitsvorteil nutzen möchte.
> Der Assembler-Code war allerdings mehrere Seiten lang,> das C Programm nur wenige Zeilen. Lohnt sich in den meisten Fällen> nicht.
Im Hinblick auf die Entwicklungszeit und die damit verbundenen Kosten
mag das ja stimmen, nur brauche ich doch solche wirtschaftlichen
Störfaktoren doch gar nicht als Kriterium mit berücksichtigen bei der
Frage, ob sich ein qualitätiv höherwertigerer Code auch bezahlt macht.
Mir ist schon klar das unser globales Wirtschaftssystem extrem
mangelhaft in Hinblick auf unsere Entwicklung einwirkt und davon
ausgehend mehr Elend in der Welt verbreitet wird, als das es der
Menschheit dienlich wäre. Als mittelbare Folge davon sind jetzt schon
bereits über eine milliarde an Menschen ihrem Hungertod sehr nahe und
mit der explodierenden Zunahme des Raubbaus der letzten verbleibenden
Resourcen werden einzigartige Lebensräume unwiederbringlich zerstört.
Hiebei kann man schon sehr deutlich erkennen welche mittelbaren Folgen
auf uns zu kommen, wenn hier nicht aller schleunigst ein Umdenken
beginnt und wir baldigtst intervenieren um einer fortschreitenden
Verelendung mit allen uns zur Verfügung stehenden Mitteln gemeinsam
entgegenzuwirken. Logisch das so etwas nicht mit einem nationalem
Alleingang bewältigt werden kann. Die jeweilige Wertigkeit ist somit von
einer langfristigen Zielsetzung abhängig und weniger davon ob unter den
inflationären marktwirtschaftlichen Seiltänzen über dem Vulkan
abgeschöpft, das schnelle Geld damit verdient werden kann.
> Auf dem PC sieht es noch schlimmer aus: Gute C Compiler kennen alle> möglichen Tricks mit MMX, optimaler Pipeline-Ausnutzung und was es sonst> noch so alles gibt. Sowas kann man von Hand kaum noch überbieten.
So etwas kann man per Hand sehr wohl überbieten.
> Aber es geht sogar schneller, als ein für einen Prozessor> handgeschriebenes Assembler-Programm: In Java ist ein Just-In-Time> Compiler eingebaut. Der kann je nach CPU (theoretisch) optimalen Code> erzeugen. Von Hand müsste man das für die verschiedenen CPUs jeweils neu> schreiben für dieselben optimalen Ergebnisse.
Von optimal kann doch hierbei gar kein Rede sein und nein eine
Portierbarkeit spielt hier eben keine so bedeutende Rolle wenn man die
wirtschaftlich bedingten Widrigkeiten einmal ausser acht läßt.
> Fazit: auch wenn man viel Zeit hat, lohnt es sich heutzutage nicht mehr,> in Assembler zu programmieren. Außer vielleicht für einige Low-Level> Dinge, wie DSP-Programmierung und sehr zeitkritischen Schleifen, für die> man keinen guten C-Compiler hat oder wo es von Hand vielleicht> tatsächlich für genau diese eine DSP-Architektur schneller ist.
Ob es sich langfristig lohnt mit qualitativ minderwertigen Produkten das
schnelle Geld zu verdienen bezweifel ich grundlegend, wobei meine
Beteiligung und meine wirtschaftliche Situation in diesem Rahmen ganz
bestimmt nicht maßgeblich ausschlaggebend ist, um repräsentativ die
Folgen für den Großteil der Menschen zu gewichten.
Dirk
mitlesender schrieb:> Dirk Wolfgang Glomp schrieb:>> Wenn man aber Programmcode hat, welcher seinen Zweck zum größten Teil>> ohne API-Aufrufe realisiert (z.B. Berechnungen bei Grafikprogrammen,>> Komprimierverfahren, Sortierverfahren bei großen Datenmengen, etc.),>> dann ist es besser diesen Code in Assembler umzusetzen um die>> Geschwindigkeitsvorteile der Assemblersprache zu nutzen.>> oo, ich habe nicht den ganzen Thread vollständig gelesen, aber oben> zitierte Bemerkung schlägt jetzt doch etwas seltsam in meinem Gehirn> ein....
Dann hat mein Posting ja tatsächlichen einen positiven Aspekt.
> Jetzt mal im Ernst Dirk, wenn man solch einen Spruch los lässt negiert> man alles, was Generationen von Informatiker und Programmierer> geschaffen haben. Damit stellt du sämtliche Dinge, die jemals auf Basis> der alt bekannten PC-Hardware geschrieben wurden in Frage... selbst dein> soviel gelobtes DOS ist damit außen vor!
Solche Bekundungen kann man eigentlich gar nicht ernst nehmen und wenn
du darüber noch weiter nachdenkst, dann fällt dir das möglicher Weise
auch noch auf.
> Wenn das deine ernsthafte Meinung sein sollte, fange am besten gleich> heute an dein eigenes Betriebssystem zu schreiben. Die Frage ist dann> halt nur, wann du damit fertig bist!
Ich habe aber gar nicht vor ein eigenes Betriebssystem zu entwickeln.
Dirk
Dirk Wolfgang Glomp schrieb:> mitlesender schrieb:>> Dirk Wolfgang Glomp schrieb:>>> Wenn man aber Programmcode hat, welcher seinen Zweck zum größten Teil>>> ohne API-Aufrufe realisiert (z.B. Berechnungen bei Grafikprogrammen,>>> Komprimierverfahren, Sortierverfahren bei großen Datenmengen, etc.),>>> dann ist es besser diesen Code in Assembler umzusetzen um die>>> Geschwindigkeitsvorteile der Assemblersprache zu nutzen.>>>> oo, ich habe nicht den ganzen Thread vollständig gelesen, aber oben>> zitierte Bemerkung schlägt jetzt doch etwas seltsam in meinem Gehirn>> ein....>> Dann hat mein Posting ja tatsächlichen einen positiven Aspekt.>
ich würder eher sagen einen negativen...!
>>>> Jetzt mal im Ernst Dirk, wenn man solch einen Spruch los lässt negiert>> man alles, was Generationen von Informatiker und Programmierer>> geschaffen haben. Damit stellt du sämtliche Dinge, die jemals auf Basis>> der alt bekannten PC-Hardware geschrieben wurden in Frage... selbst dein>> soviel gelobtes DOS ist damit außen vor!>> Solche Bekundungen kann man eigentlich gar nicht ernst nehmen und wenn> du darüber noch weiter nachdenkst, dann fällt dir das möglicher Weise> auch noch auf.>
mir fällt nur auf, dass du die mühsame Arbeit anderer vollkommen in
Frage stellst und diese Leute, um mal deine Behauptungen in den Klartext
zu übersetzen, als Idioten und Unwissende darstellst (mich
eingeschlossen), weil sie sich die Mühe machen standardisierte Software
zu erstellen auf die andere Leute aufsetzen können. In Teams nennt man
so etwas Arbeitsteilung...
>>>> Wenn das deine ernsthafte Meinung sein sollte, fange am besten gleich>> heute an dein eigenes Betriebssystem zu schreiben. Die Frage ist dann>> halt nur, wann du damit fertig bist!>> Ich habe aber gar nicht vor ein eigenes Betriebssystem zu entwickeln.>
letztendlich läuft es aber darauf hinaus! Du hast die Behauptung in den
Raum gestellt, dass alles was du nicht selbst (in Assembler)
programmiert hast uneffizienter Mist ist. Wenn du konsequent bist,
müsstest du also schon damit anfangen die INT21-Routinen des DOS zu
redesignen. Die könnten ja auch vollkommen unnötig aufgebläht sein, weil
sie auf mehreren Prozessoren laufen sollen.
Dirk Wolfgang Glomp schrieb:> Mir ist schon klar das unser globales Wirtschaftssystem extrem> mangelhaft in Hinblick auf unsere Entwicklung einwirkt und davon> ausgehend mehr Elend in der Welt verbreitet wird, als das es der> Menschheit dienlich wäre. Als mittelbare Folge davon sind jetzt schon> bereits über eine milliarde an Menschen ihrem Hungertod sehr nahe und> mit der explodierenden Zunahme des Raubbaus der letzten verbleibenden> Resourcen werden einzigartige Lebensräume unwiederbringlich zerstört.>
Menschen, deren Wissen und deren Arbeitszeit ist auch eine Ressource,
deren Verschwendung in einem Teufelskreis endet! Wenn jeder das Rad neu
erfinden würde (so wie du), wer hat dann noch die Zeit sich um Dinge zu
kümmern, die du gelöst haben möchtest?
Mahlzeit
Dirk Wolfgang Glomp schrieb:>> Fazit: auch wenn man viel Zeit hat, lohnt es sich heutzutage nicht mehr,>> in Assembler zu programmieren. Außer vielleicht für einige Low-Level>> Dinge, wie DSP-Programmierung und sehr zeitkritischen Schleifen, für die>> man keinen guten C-Compiler hat oder wo es von Hand vielleicht>> tatsächlich für genau diese eine DSP-Architektur schneller ist.>> Ob es sich langfristig lohnt mit qualitativ minderwertigen Produkten das> schnelle Geld zu verdienen bezweifel ich grundlegend,
Ach Gott.
Mit solchen Aussagen disqualifizierst du dich selber.
Kleiner Hint: Natürlich gibt es im Hochsprachenbereich qualitativ
minderwertige Lösungen. Das liegt allerdings nicht an der Sprache,
sondern am Programmierer. In Assmbler würde der allerdingd gar nichts zu
stande bringen, wenn er schon in einer Hochsprache nix vernünftiges
hinkriegt.
Und für den Rest: Die Sache ist wohl eher umgekehrt. Bis auf weltweit
vielleicht 3 Handvoll Spezialisten, sind es die Assembler-Lösungen die
von PC-Ebene aufwärts qualitativ nicht mithalten können. Du darfst nicht
von deinen kleinen Programmen auf das schliessen, womit sich die
Mehrzahl der Programmierer rumschlägt. Wir reden hier von 500tausend bis
weit über 1 Million Lines of Code. Und das in Hochsprache! In Assembler
könntest du da locker noch ein Faktor 5 drauf legen. Kein Mensch kann
das mehr überblicken. Ein doppelt so umfangreiches Programm ist nicht
doppelt so schwer zu warten und zu pflegen, sondern der Zusammenhang ist
eher quadratisch. Also 4 mal so schwer. Eine 3 fach umfangreiche hat
dann Schiwerigkeitsgrad 9, etc. etc. Du kannst dir dann ausmalen wie
groß der Unterschied deiner 300 oder 400 Zeilen Programme zu 300-tausend
oder 400-tausend ist. Ohne ausgeklügelte Organisation und einer
Einrichtung, die einem bei Nichteinhalten der Regeln auf die Finger
klopft, wird das nichts.
Qualität in der Softwareentwicklung hat in den seltensten Fällen etwas
mit Laufzeit zu tun, sondern mit Korrektheit. Dort liegt das Problem in
der SW-Entwicklung! Dazu braucht man Hilfsmittel, die einem Arbeit
abnehmen und automatisieren. Bei derartigen Projekten kannst du nicht
mehr händisch Registerzuteilungen machen. Spätestens bei den ersten
Änderungen ist das ein sicherer Weg ins Desaster. Das muss ein Automat
übernehmen (ein Compiler), der das überwacht und durchführt. Ist erst
mal nachgewiesen, dass der das immer korrekt macht, dann hat man die
Gewissheit, dass dieser Automat das bei jeder Funktion, egal wie sie
aussieht, egal wie man sie ändert wieder korrekt macht. Und der
Programmierer hält sich da raus, selbst wenn das ab und an den einen
oder anderen unnötigen Taktzyklus kostet. Denn Korrektheit ist wichtiger
als ein paar Taktzyklen da und dort. Auch der kleinste Fehler kann sehr
schnell sehr teuer werden. Je mehr Dinge man Automaten überlassen kann,
die nachweislich ihren Teil fehlerfrei erledigen, desto besser.
Andernfalls erschlägt einen die Komplexität durch die unüberschaubare
Masse an Anweisungen, die man nicht mehr beherrscht.
Anders ausgedrückt:
Natürlich kann man ein Schiffsmodell aus Streichhölzern zusammenkleben.
Und ich bewundere jeden der die Geduld dazu hat.
Nur werden diese Schiffe immer Vitrinenmodelle sein, die man tunlichst
nicht aufs Wasser lässt. Der Aufwand, diese Dinger ausreichend dicht zu
bekommen ist einfach zu hoch.
Man kann aber auch natürlich zu Sperrholztafeln greifen und Spanten
aussägen und die beplanken. Das geht in einem Bruchteil der Zeit der
Streichholzlösung und ist viel einfacher abzudichten.
Oder aber man baut eine Stahlform und benutzt Kunststoffe um die
Produktion noch weiter zu beschleunigen.
Das mag nicht so abenteuerlich und interessant aussehen, wie eine
Streichholzlösung. Dafür ist sie aber qualitativ insofern besser, da der
Rumpf von Anfang an schon dicht ist.
Die meisten von uns können es sich nämlich nicht leisten, wenn die
Schiffe nach Fertigstellung in einer Vitrine rumstehen. Unsere Schiffe
müssen raus aufs Wasser und dort Arbeit verrichten! Und zwar viele Jahre
lang. Es spielt dabei keine Rolle ob du für jede Position am Rumpf das
dafür optimal geeignete Streichholz mit der Briefwaage herausgewogen
hast und entsprechend der Belastung verjüngt hast (= Pseudo-'Qualität'),
während wir einfach Glasgewebe und Harz in eine Form klatschen und hart
werden lassen. Diese Pseudo-Qualität macht die Streichholzlösung
deswegen nämlich auch nicht alltagstauglicher. Sie macht sie höchstens
anfälliger gegen Störungen bzw. anfälliger bei Änderungen.
Hallo Dirk Wolfgang,
ich verfolge diese "Diskussion" seit längerem, mit wachsendem Befremden.
Es drängt sich mit die Frage auf, weshalb Du denn überhaupt auf BIOS/DOS
aufsetzt! Unter Auslassung derselben lässt sich sicher noch der eine
oder andere Taktzyklus rauskitzeln... ;-)
Dein Hobby-Forscherdrang in Ehren, wie viele andere bereits geschrieben
hatten: Ziel professioneller Software-Entwicklung ist es i.d.R. nicht,
bei einer Desktop-Software das letzte Quäntchen an Laufzeit
rauszukizeln. Die meisten Rechner langweilen sich sowieso beim Warten
auf irgendwelche I/O-Operationen.
Es ist wesentlich interessanter (in mehrerlei Hinsicht), die
Datenstrukturen in der Software derart zu gestalten, dass diese
effizient sind in Bezug auf Laufzeit, Speicherbedarf, ... Meist ist es
eine Entweder-/Oder-Frage und der Entwickler muß das Optimum oder auch
kleinste Übel finden. Dies erfolgt auf einer wesentlich abstrakteren
Ebene als die Bit- und Byte-Pfriemelei, wie Du sie betreibst und auch
bevorzugst.
Ich arbeite seit nun etwa 25 Jahren professionell in der
Software-Entwicklung. Performance-Probleme waren immer ein Thema (bei
der Verarbeitung großer Datenmengen). "Schuld" waren immer ungeeignete
Datenstrukturen, sei es durch irgendwelche Gegebenheiten oder auch
Know-How-Lücken seitens der Entwicklung. Schuld waren niemals
Programmteile, die implementiert in Assembler plötzlich um den Faktor
10, 100, 1000 schneller gewesen wären.
Sicherlich gibt es auch Bereiche, in denen es evtl. sinnvoll sein kann,
irgendwelche in Assembler zu implementieren (i.d.R. kleine, abgegrenzte
Teile). Das Gros der Software wird aber dann trotzdem in irgendeiner
Hochsprache implementiert. Der Grund dafür ist recht einfach: Die
Hochsprachen ermöglichen einen wesentlich höheren Grad der Abstraktion.
Bis man mit Assembler dort hin gelangt, muß man viele, viele Mannjahre
an Entwicklung investieren, was niemand bereit ist zu bezahlen.
Gruß
Markus
mitlesender schrieb:> Dirk Wolfgang Glomp schrieb:>> mitlesender schrieb:>>> Dirk Wolfgang Glomp schrieb:>>>> Wenn man aber Programmcode hat, welcher seinen Zweck zum größten Teil>>>> ohne API-Aufrufe realisiert (z.B. Berechnungen bei Grafikprogrammen,>>>> Komprimierverfahren, Sortierverfahren bei großen Datenmengen, etc.),>>>> dann ist es besser diesen Code in Assembler umzusetzen um die>>>> Geschwindigkeitsvorteile der Assemblersprache zu nutzen.>>>>>> oo, ich habe nicht den ganzen Thread vollständig gelesen, aber oben>>> zitierte Bemerkung schlägt jetzt doch etwas seltsam in meinem Gehirn>>> ein....>>>> Dann hat mein Posting ja tatsächlichen einen positiven Aspekt.>>> ich würder eher sagen einen negativen...!
Das will ich nicht hoffen.
>>> Jetzt mal im Ernst Dirk, wenn man solch einen Spruch los lässt negiert>>> man alles, was Generationen von Informatiker und Programmierer>>> geschaffen haben. Damit stellt du sämtliche Dinge, die jemals auf Basis>>> der alt bekannten PC-Hardware geschrieben wurden in Frage... selbst dein>>> soviel gelobtes DOS ist damit außen vor!>>>> Solche Bekundungen kann man eigentlich gar nicht ernst nehmen und wenn>> du darüber noch weiter nachdenkst, dann fällt dir das möglicher Weise>> auch noch auf.>>> mir fällt nur auf, dass du die mühsame Arbeit anderer vollkommen in> Frage stellst und diese Leute, um mal deine Behauptungen in den Klartext> zu übersetzen, als Idioten und Unwissende darstellst (mich> eingeschlossen), weil sie sich die Mühe machen standardisierte Software> zu erstellen auf die andere Leute aufsetzen können.
Also verstehe mich bitte nicht falsch, es liegt mir fern die Arbeit von
anderen Programmierer herabzuwürdigen. Warum sollter ich das auch tun.
Es geht mir doch eher darum, verschiedene Methoden miteinander zu
vergleichen, um ein bestimmtes Ziel zu erreichen. Dabei zeichnen sich
die Vor- und Nachteile ab, die sich je nach Anwendungsszenario mit den
bereits vorhandenen Lösungen ausgeprägen. Im Detail gibt es dazu
bestimmte Mittel die auf dem Weg zur Volleindung eingesetzt werden
können und einen mehr oder minder hohen Aufwand erfordern. Darüber
braucht man jetzt nicht unbedingt einen Glaubenskrieg führen.
>>> Wenn das deine ernsthafte Meinung sein sollte, fange am besten gleich>>> heute an dein eigenes Betriebssystem zu schreiben. Die Frage ist dann>>> halt nur, wann du damit fertig bist!>>>> Ich habe aber gar nicht vor ein eigenes Betriebssystem zu entwickeln.>>> letztendlich läuft es aber darauf hinaus!
Nur weil mir bestimmte Äpfel nicht schmecken werde ich doch nicht gleich
ein Obstbauer.
> Du hast die Behauptung in den> Raum gestellt, dass alles was du nicht selbst (in Assembler)> programmiert hast uneffizienter Mist ist.
Da must du etwas falsch verstanden haben.
> Wenn du konsequent bist,> müsstest du also schon damit anfangen die INT21-Routinen des DOS zu> redesignen.
Um Kritik zu üben braucht man selber auch gar nicht so konseqent zu
sein, es genügt zu erkennen das es besser gemacht werden könnte. Ob und
wer es nun besser macht ist dabei doch eher unwichtig. Und das es besser
geht, das haben schon genug Assemblerprogrammierer bewiesen in dem sie
es immer wieder anhand von konkreten Beispielen gezeigt haben das ihr
Code, ob nun eingebettet in eine Anwendung oder in eigenständigen
Anwendungen effizienter arbeitet. Diese Effizienz zeigt sich dabei in
der kleineren Größe der Anwendung, um Resoucen einzusparen und in der
schnelleren Abarbeitung des verwendeten Codes, bzw. damit das ein
Ergebniss schon schneller damit erzielt werden kann.
> Die könnten ja auch vollkommen unnötig aufgebläht sein, weil> sie auf mehreren Prozessoren laufen sollen.
Sicherlich.
> Dirk Wolfgang Glomp schrieb:>> Mir ist schon klar das unser globales Wirtschaftssystem extrem>> mangelhaft in Hinblick auf unsere Entwicklung einwirkt und davon>> ausgehend mehr Elend in der Welt verbreitet wird, als das es der>> Menschheit dienlich wäre. Als mittelbare Folge davon sind jetzt schon>> bereits über eine milliarde an Menschen ihrem Hungertod sehr nahe und>> mit der explodierenden Zunahme des Raubbaus der letzten verbleibenden>> Resourcen werden einzigartige Lebensräume unwiederbringlich zerstört.>>> Menschen, deren Wissen und deren Arbeitszeit ist auch eine Ressource,> deren Verschwendung in einem Teufelskreis endet!
Der Wert eines menschlichen Lebens darf aber nicht in Arbeitszeit
aufgerechnet werden wenn wir unsere eigene Menschlichkeit nicht
verlieren wollen.
> Wenn jeder das Rad neu> erfinden würde (so wie du), wer hat dann noch die Zeit sich um Dinge zu> kümmern, die du gelöst haben möchtest?
Es geht nicht "nur" darum das jeder ein neues Rad erfindet, sondern
auch darum dieser Rad selber zu fahren....
> Mahlzeit
...freihändig und notfalls auch mit Schluckauf.
Dirk
Dirk Wolfgang Glomp schrieb:>> Menschen, deren Wissen und deren Arbeitszeit ist auch eine Ressource,>> deren Verschwendung in einem Teufelskreis endet!>> Der Wert eines menschlichen Lebens darf aber nicht in Arbeitszeit> aufgerechnet werden wenn wir unsere eigene Menschlichkeit nicht> verlieren wollen.
Eben.
Drum möchten wir gerne für das Erstellen einer Applikation X die
geringstmögliche Arbeitszeit einsetzen, die nötig ist.
Mit Assembler setzt du die maximalst mögliche Arbeitszeit ein.
Du verwendest also einen Teil deiner Lebenszeit für eine Arbeit, die du
durch Verwendung eines Compiler viel schneller hättest erledigen können.
Dirk Wolfgang Glomp schrieb:>> Wenn jeder das Rad neu>> erfinden würde (so wie du), wer hat dann noch die Zeit sich um Dinge zu>> kümmern, die du gelöst haben möchtest?>> Es geht nicht "nur" darum das jeder ein neues Rad erfindet, sondern> auch darum dieser Rad selber zu fahren....
Dazu muss ich es aber nicht selber bauen.
Radfahren kann ich mit jedem Rad aus dem Fachhandel genausogut. Im
schlimmsten Fall sag ich dem Spezialisten dort, was ich haben möchte und
der Spezialist baut das dann zusammen.
Nicht anders hier:
Ich sage dem CPU-Spezialisten 'Compiler', dass ich diese Berechnung
benötige:
c = sqrt( a * a + b * b );
und der Compiler stellt dann den Maschinencode zusammen, der meinen
Wunsch erfüllt (*). Und da dieser Spezialist nicht ganz auf den Kopf
gefallen ist, merkt der auch, dass es bei
c = sqrt( a * a + b * b );
d = sqrt( a * a + e * e );
gemeinsame Ausdrücke gibt, die er nur einmal berechnen lassen muss und
die er irgendwo zwischenspeichern kann um sie dann wiederzuverwenden.
Darum muss ich mich als Programmierer nicht kümmern. Für mich erhebt
sich die Frage auf einer viel höheren Ebene: Ist ein Phythagoras an
dieser Stelle überhaupt angebracht oder kann ich nicht eine
Manhatten-Distanz benutzen, die schneller zu berechnen geht?
Oder noch anders ausgedrückt:
Egal wie sehr du deinen Assmebler-BubbleSort auch optimierst und die
Befehlspipeline durchspielst etc. Gegen einen maschinell übersetzten
C-Quicksort wird er ab ein paar Zehn zu sortierende Datensätze aufwärts
niemals eine Chance haben. Dort liegt das Optimierungspotential, und
dort liegt ein riesiges Potential! Dagegen ist das was du da auf
Assemblerebene veranstaltest alles uninteressant.
(*) und damit wir uns nicht falsch verstehen.
Ich weiss schon, dass diese 1 Zeile relativ einfach in Assmebler
abzubilden ist. Aber das ist ja auch nicht der Regelfall, dass man nur 1
Zeile hat. Denn ....
Karl heinz Buchegger schrieb:> Dirk Wolfgang Glomp schrieb:>>>> Fazit: auch wenn man viel Zeit hat, lohnt es sich heutzutage nicht mehr,>>> in Assembler zu programmieren. Außer vielleicht für einige Low-Level>>> Dinge, wie DSP-Programmierung und sehr zeitkritischen Schleifen, für die>>> man keinen guten C-Compiler hat oder wo es von Hand vielleicht>>> tatsächlich für genau diese eine DSP-Architektur schneller ist.>>>> Ob es sich langfristig lohnt mit qualitativ minderwertigen Produkten das>> schnelle Geld zu verdienen bezweifel ich grundlegend,>> Ach Gott.> Mit solchen Aussagen disqualifizierst du dich selber.>> Kleiner Hint: Natürlich gibt es im Hochsprachenbereich qualitativ> minderwertige Lösungen.
Und deswegen habe ich mich nun disqualifizierst, von was eigentlich?
> Das liegt allerdings nicht an der Sprache,> sondern am Programmierer. In Assmbler würde der allerdingd gar nichts zu> stande bringen, wenn er schon in einer Hochsprache nix vernünftiges> hinkriegt.
Stimmt daran liegt es.
> Und für den Rest: Die Sache ist wohl eher umgekehrt. Bis auf weltweit> vielleicht 3 Handvoll Spezialisten, sind es die Assembler-Lösungen die> von PC-Ebene aufwärts qualitativ nicht mithalten können.
Die aber mithalten könnten, wenn mehr Auifwand betreiben werden würde.
> Du darfst nicht> von deinen kleinen Programmen auf das schliessen, womit sich die> Mehrzahl der Programmierer rumschlägt. Wir reden hier von 500tausend bis> weit über 1 Million Lines of Code. Und das in Hochsprache! In Assembler> könntest du da locker noch ein Faktor 5 drauf legen. Kein Mensch kann> das mehr überblicken.
Kein Mensch kann das ...alleine... mehr überblicken.
Und jetzt komme mir nicht mit dem Gerücht Assemblemr-Programmierer und
Teamfähigkeit würden sich mehr beissen als mit C-Programmierern.
Warum sollte es?
> Ein doppelt so umfangreiches Programm ist nicht> doppelt so schwer zu warten und zu pflegen, sondern der Zusammenhang ist> eher quadratisch. Also 4 mal so schwer. Eine 3 fach umfangreiche hat> dann Schiwerigkeitsgrad 9, etc. etc. Du kannst dir dann ausmalen wie> groß der Unterschied deiner 300 oder 400 Zeilen Programme zu 300-tausend> oder 400-tausend ist. Ohne ausgeklügelte Organisation und einer> Einrichtung, die einem bei Nichteinhalten der Regeln auf die Finger> klopft, wird das nichts.
Den höhreren Aufwand habe ich nie bestritten.
> Qualität in der Softwareentwicklung hat in den seltensten Fällen etwas> mit Laufzeit zu tun, sondern mit Korrektheit. Dort liegt das Problem in> der SW-Entwicklung! Dazu braucht man Hilfsmittel, die einem Arbeit> abnehmen und automatisieren. Bei derartigen Projekten kannst du nicht> mehr händisch Registerzuteilungen machen. Spätestens bei den ersten> Änderungen ist das ein sicherer Weg ins Desaster.
Dieses jas wohl eher heraufbeschworen Desaster kannn sich ebenso als
hartnäckiger Fehler in einer C-Anwendung verbergen und dafür braucht es
nicht einmal so gewaltige Mengen an Code die du hier in die Diskussion
einschüttest.
> Das muss ein Automat> übernehmen (ein Compiler), der das überwacht und durchführt.
Der heilige Gral..oooohmmmm.
> Ist erst> mal nachgewiesen, dass der das immer korrekt macht, dann hat man die> Gewissheit, dass dieser Automat das bei jeder Funktion, egal wie sie> aussieht, egal wie man sie ändert wieder korrekt macht.
Diese funktionelle Zuverlässigkeit beflügelt mich beim Programmieren
jetzt eigentlich weniger.
> Und der> Programmierer hält sich da raus, selbst wenn das ab und an den einen> oder anderen unnötigen Taktzyklus kostet.
Von solchen starren Regeln brauchen wir uns aber gar nicht weiter
aufhalten lassen.
> Denn Korrektheit ist wichtiger> als ein paar Taktzyklen da und dort. Auch der kleinste Fehler kann sehr> schnell sehr teuer werden. Je mehr Dinge man Automaten überlassen kann,> die nachweislich ihren Teil fehlerfrei erledigen, desto besser.> Andernfalls erschlägt einen die Komplexität durch die unüberschaubare> Masse an Anweisungen, die man nicht mehr beherrscht.
Für mich ist es weniger einer Frage der Machbarkeit, als eine Frage der
Zeit wann langfristig solchen komplexeren Dinge optimiert werden können.
> Anders ausgedrückt:> Natürlich kann man ein Schiffsmodell aus Streichhölzern zusammenkleben.> Und ich bewundere jeden der die Geduld dazu hat.> Nur werden diese Schiffe immer Vitrinenmodelle sein, die man tunlichst> nicht aufs Wasser lässt. Der Aufwand, diese Dinger ausreichend dicht zu> bekommen ist einfach zu hoch.> Man kann aber auch natürlich zu Sperrholztafeln greifen und Spanten> aussägen und die beplanken. Das geht in einem Bruchteil der Zeit der> Streichholzlösung und ist viel einfacher abzudichten.> Oder aber man baut eine Stahlform und benutzt Kunststoffe um die> Produktion noch weiter zu beschleunigen.> Das mag nicht so abenteuerlich und interessant aussehen, wie eine> Streichholzlösung. Dafür ist sie aber qualitativ insofern besser, da der> Rumpf von Anfang an schon dicht ist.
Ich kann dir trotz deiner sehr bildlicher Darstellung nicht so recht
folgen. Was soll bitte noch mal genau an einer Assembler-Lösung weniger
stählern sein?
> Die meisten von uns können es sich nämlich nicht leisten, wenn die> Schiffe nach Fertigstellung in einer Vitrine rumstehen.
Da hast du einen sehr wichtigen Punkt angesprochen. Die Fertigung
unterliegt marktwirtschlicher Belange und ist damit nicht nur auf
Qualität ausgerichtet.
> Unsere Schiffe> müssen raus aufs Wasser und dort Arbeit verrichten!
Ob sie die Arbeit aber wirklich so gut erledigen wie sie es könnnten ist
mit dem Wettbewerb alleine unter dem Turbulenzen am globalen Markt als
eher unscharf zu definieren. Damit sinkt die Qualität nicht gerade
selten unter dem technisch machbaren Möglichkeiten zurück.
> Und zwar viele Jahre> lang.
Ich merke schon, dieser Anker wurde im Hafen einbetoniert.
> Es spielt dabei keine Rolle ob du für jede Position am Rumpf das> dafür optimal geeignete Streichholz mit der Briefwaage herausgewogen> hast und entsprechend der Belastung verjüngt hast (= Pseudo-'Qualität'),> während wir einfach Glasgewebe und Harz in eine Form klatschen und hart> werden lassen. Diese Pseudo-Qualität macht die Streichholzlösung> deswegen nämlich auch nicht alltagstauglicher. Sie macht sie höchstens> anfälliger gegen Störungen bzw. anfälliger bei Änderungen.
Wir reden ja hierbei auch nicht um flüchtige Luftgebilde in der Wüste,
sondern um Möglichkeiten die nicht ausgeschöpft werden. Und wennn es da
nicht hin und wieder eine Oase einer sprudelnden Assemblequelle geben
würde, dann kann die gesamte Karawane aber lange noch im Sandsturm
herumirren bis sie an ihr ziel kommt.
Dirk
Dirk Wolfgang Glomp schrieb:>> Und für den Rest: Die Sache ist wohl eher umgekehrt. Bis auf weltweit>> vielleicht 3 Handvoll Spezialisten, sind es die Assembler-Lösungen die>> von PC-Ebene aufwärts qualitativ nicht mithalten können.>> Die aber mithalten könnten, wenn mehr Auifwand betreiben werden würde.
Hier liegt dein Trugschluss.
Das kann er eben nicht.
Mit deinem Sandkastenschäufelchen kannst du eben nicht mithalten, wenn
es darum geht, den Gottharttunnel zu bauen. Egal wie gut du damit in der
Sandkiste arbeiten kannst.
> Und jetzt komme mir nicht mit dem Gerücht Assemblemr-Programmierer> und Teamfähigkeit würden sich mehr beissen als mit C-Programmierern.> Warum sollte es?
Weil es zu teuer ist.
Oder bist du bereit, wie vor 40 Jahren, für eine Textverarbeitung 20000
Euro zu bezahlen?
Software ist billig geworden, weil die Werkzeuge besser geworden sind.
> Dieses jas wohl eher heraufbeschworen Desaster kannn sich ebenso> als hartnäckiger Fehler in einer C-Anwendung verbergen und dafür> braucht es nicht einmal so gewaltige Mengen an Code die du hier> in die Diskussion einschüttest.
Natürlich.
Aber in
c = sqrt( a * a + b * b );
liegt viel weniger Potential für mögliche Fehler als auf Assembler
ebene, in der eine vergessene oder falsche Abfrage des Carry Bits schon
zum Problem werden kann.
Industriell rechnet man mit ca 10 bis 15 Zeilen Code pro Mann und Tag.
Das interessante daran: Das ist ziemlich unabhängig von der
Programmiersprache.
D.h. Ob Assembler oder C spielt keine Rolle. 10 bis 15 Zeilen.
Nur kann ich in 10 Zeilen C-Code viel mehr ausdrücken als in 10 Zeilen
Assembler Code.
Das wirkt sich wiederrum auf die Gestehungskosten aus und die wiederrum
auf die Verkaufspreise.
Und damit wir uns nicht falsch verstehen. Auch wenn es mitlerweile viele
presigünstige Stadardanwendungen gibt (die ohne Hochsprache gar nicht
möglich gewesen wären), SW Entwicklung kostet immer noch reichlich Geld.
Mit einer halben Mio Euro hast du nicht viel ausgerichtet, wenn du
Entwicklunsgzeit für ein Spezialprodukt einkaufen musst. Da willst du
doch möglichst viel kriegen für dein Geld :-)
@Dirk
Schön langsam habe ich das Gefühl, du trollst nur noch rum.
Viele haben dir mitlerweile erklärt, dass Software-Entwicklung anders
funktioniert, als du dir das in deinem Kämmerchen zurechtlegst.
Das was du als 'Qualitätsmangel' ansiehst, ist in Wirklichkeit keiner.
Qualität macht sich in der SW-Branche zuallererst an der Korrektheit
eines Programms fest, an der Termintreue, von mir aus auch am Preis.
Geschwindigkeit, dein heiliger Gral, rangiert da erst viel weiter
hinten. Solange die Geschwindigkeit akzeptabel ist, interessiert sich
kein Aaas dafür.
Ich bin jetzt weg, denn wie gesagt: Ich habe das Gefühl du trollst nur
noch. X professionelle Entwickler sagen dir, dass du am falschen Dampfer
bist, und trotzdem beharrst du auf deiner Sichtweise. Mit nicht mehr im
Gepäck als einer vagen Vorstellung davon, was Qualität sein könnte und
wie man sie erreicht. Einer vagen Vorstellung, die du nicht aufgeben
darfst, weil du dir dann eingestehen müsstest, dass du 'Liebhaberei' und
nicht Softwareentwicklung betreibst.
Einer vagen Vorstellung, die hauptsächlich darin besteht, dass du völlig
falsche Vorstellungen davon hast, was die Laufzeitdifferenzen von
Hochsprache Programmen und Assemblerprogrammen in der Praxis anbelangt.
Markus V. schrieb:> Sicherlich gibt es auch Bereiche, in denen es evtl. sinnvoll sein kann,> irgendwelche in Assembler zu implementieren (i.d.R. kleine, abgegrenzte> Teile).
Genau darum geht es mir.
> Das Gros der Software wird aber dann trotzdem in irgendeiner> Hochsprache implementiert. Der Grund dafür ist recht einfach: Die> Hochsprachen ermöglichen einen wesentlich höheren Grad der Abstraktion.> Bis man mit Assembler dort hin gelangt, muß man viele, viele Mannjahre> an Entwicklung investieren, ...
Der Aufwand ist unbestritten höher.
>...was niemand bereit ist zu bezahlen.
Auf inflationäre Kosten die abseit der technischen Möglichkeiten liegen
wollte ich eigentlich nicht so genau abzielen.
Dirk
Karl heinz Buchegger schrieb:> @Dirk>> Schön langsam habe ich das Gefühl, du trollst nur noch rum.
Es lag nicht in meiner Absicht ein Mißtrauen zu verbreiten und wenn dich
meine Worte gefühlsmäßig zu sehr belasten, dann verabschiede ich mich
hier wohl lieber. Dir und allen anderen Beteiligten wünsche ich noch
viel Spaß miteinander.
freecrac at web dot de
Dirk Wolfgang Glomp
Vierbergen 10 b
22111 Hamburg Horn
Karl heinz Buchegger schrieb:> Oder noch anders ausgedrückt:> Egal wie sehr du deinen Assmebler-BubbleSort auch optimierst und die> Befehlspipeline durchspielst etc. Gegen einen maschinell übersetzten> C-Quicksort wird er ab ein paar Zehn zu sortierende Datensätze aufwärts> niemals eine Chance haben. Dort liegt das Optimierungspotential, und> dort liegt ein riesiges Potential! Dagegen ist das was du da auf> Assemblerebene veranstaltest alles uninteressant.
....siiiicher so völlig uninteressant wie Jan Bruns Quicksort:
http://www.foonews.info/de-comp-lang-assembler-x86/2263680-quicksort.html
Ok, ab nun verschone ich deine Nerven, du willst anscheinend meine Worte
nicht verstehen.
Dirk
Dirk Wolfgang Glomp schrieb:>> ....siiiicher so völlig uninteressant wie Jan Bruns Quicksort:> http://www.foonews.info/de-comp-lang-assembler-x86/2263680-quicksort.html
Schönes Beispiel, warum man das nicht in Assembler machen sollte. Wie in
dem Thread geschrieben, funktioniert es nur für signed integer. Außerdem
kannst du mir nicht sagen, daß der Code einfach lesbar oder wartbar
wäre.
Für Quicksort gibt es übrigens ein schönes Beispiel, wie man das in
Haskell lösen kann:
Vorteil daran: Das verstehen sogar nicht-Programmierer (sofern
mathematisch vorgebildet) und man kann viel leichter theoretisch
nachweisen, daß der Algorithmus auch das macht, was er machen soll.
Gerade wenn dir die Resourcen der Erde so am Herzen liegen, solltest du
weniger in Assembler programmieren, da du dafür länger brauchst, und
somit mehr Resourcen für dieselbe Arbeit verschwendest, sodaß du weniger
dazu beitragen kannst, daß es allen Menschen besser geht :-)
Frank Buss schrieb:> Dirk Wolfgang Glomp schrieb:>>>> ....siiiicher so völlig uninteressant wie Jan Bruns Quicksort:>> http://www.foonews.info/de-comp-lang-assembler-x86/2263680-quicksort.html>> Schönes Beispiel, warum man das nicht in Assembler machen sollte. Wie in> dem Thread geschrieben, funktioniert es nur für signed integer. Außerdem> kannst du mir nicht sagen, daß der Code einfach lesbar oder wartbar> wäre.>> Für Quicksort gibt es übrigens ein schönes Beispiel, wie man das in> Haskell lösen kann:>>
>> Vorteil daran: Das verstehen sogar nicht-Programmierer (sofern> mathematisch vorgebildet) und man kann viel leichter theoretisch> nachweisen, daß der Algorithmus auch das macht, was er machen soll.
Das sieht zwar schön aus, sollte aber nicht als Quicksort verkauft
werden, auch wenn es so mehr oder weniger auf haskell.org steht (davon
abgesehen ist diese Variante auch noch richtig langsam)
http://www.reddit.com/r/programming/comments/2h0j2/real_quicksort_in_haskellhttp://www.haskell.org/haskellwiki/Introduction/Direct_Translation> Gerade wenn dir die Resourcen der Erde so am Herzen liegen, solltest du> weniger in Assembler programmieren, da du dafür länger brauchst, und> somit mehr Resourcen für dieselbe Arbeit verschwendest, sodaß du weniger> dazu beitragen kannst, daß es allen Menschen besser geht :-)
Dirk Wolfgang Glomp schrieb:> ....siiiicher so völlig uninteressant wie Jan Bruns Quicksort:> http://www.foonews.info/de-comp-lang-assembler-x86/2263680-quicksort.html>> Ok, ab nun verschone ich deine Nerven, du willst anscheinend meine Worte> nicht verstehen.
Doch doch, ich versteh dich schon.
Bau doch diesen Quicksort mal um auf Strings die in einer
Datensatzbeschreibung sitzen.
In C wäre das zb
struct Person
{
char* FirstName;
char* FamilyName;
};
mach dir ein Assemblerequivalent eines Arrays dazu, wobei die
eigentlichen Namen mittels Adressen der Strings in den Strukturen
eingetragen werden.
Und dann sortierst du das sowohl nach dem Familiennamen, als auch nach
dem Vornamen. Und wenn dir fad ist, dann machst du noch ein Geburtsdatum
mit rein und sortierst auch noch danach.
Wirst du diese (Arbeits-) Woche noch fertig damit, oder doch erst
nächste?
(PS: Die Könner sortieren das, indem sie nicht das Array selber
sortieren, sondern einen zusätzliches Indexarray umsortieren und die
Daten selber in Ruhe lassen. Auch diese Variante hätte ich gerne
gesehen)
Denn genau das nenn ich nämlich Resourcenverschwendung. In C ist das
alles trivial.
Karl heinz Buchegger schrieb:> Und dann sortierst du das sowohl nach dem Familiennamen, als auch nach> dem Vornamen.>> (PS: Die Könner sortieren das, indem sie nicht das Array selber> sortieren, sondern einen zusätzliches Indexarray umsortieren und die> Daten selber in Ruhe lassen. Auch diese Variante hätte ich gerne> gesehen)
So fertig.
Und zwar mit allen 3 Teilaufgaben.
Jetzt machst du deine Assemblerlösung(en), dann spielen wir da ein
halbes Telefonbuch an Daten rein und dann machen wir mal
Laufzeitvergleiche.
Oder sollten wir Daten lesen von einem File auch noch mit dazunehmen?
Sinnvoll wäre es, dann könnten wir beide die gleiche Datendatei benutzen
und tippen uns nicht mit Namen die Finger wund. Wie willst du es haben?
Übergabe des Dateinamens per Commandline oder Abfrage im Programm?
PS: Diese C-Lösung ist durchaus zu schlagen. In C++ ginge es noch einen
Tick schneller.
Aber lass uns doch erst mal sehen, um wieviel schneller deine
Assemblerlösung ist. Und wie lange du dafür brauchst um sie zu
erstellen. Meine Vorgabe steht: 8 Minuten "Entwicklung" für alle 3
Varianten.
Und sie ist als Bonus leicht erweiterbar.
Du willst den Thomas Gottschalk noch mit rein haben? Kein Problem. Füg
ihn in die Datenfelder ein ...
1
structPersonmember[]={
2
{"Hans","Meiser"},
3
{"Peter","Frankenfeld"},
4
{"Hans Joachim","Kuhelnkampf"},
5
{"Hans","Rosenthal"},
6
{"Barbara","Salesch"},
7
{"Thomas","Gottschalk"}
8
};
... den Rest des Programms passt der Compiler an die geänderte Anzahl
der Datensätze an.
Oder willst du lieber was aus dem Bereich Computergrafik? Können wir
auch machen. Aber es sollte schon etwas einigermassen realistisches
sein. Wahllos 10000 Linien hinklatschen ist nicht sehr sinnvoll da
praxisfremd. Wie wäre es mit einem kleinen Ray Tracer? Nichts
aufwändiges. Ein paar Kugeln im Raum, ein paar ebene Flächen, 1 oder 2
Lichtquellen. Einfaches Lichtmodell mit Schatten, kein Antialiasing oder
Depth Bluring.
Das wir als Ehrenmänner bei den Entwicklungsziten nicht schummeln
versteht sich wohl von selber.
> Meine Vorgabe steht: 8 Minuten für alle 3 Varianten
Sensationell! Karl heinz Buchegger, du überholst dich noch selbst :-).
Solange bräuchte ich bereits, um erst mal zu überlegen, woher ich mir
den Code zusammenkopiere. ;)
Es ist schön deine Postings mitzulesen! Respekt!
Senfdazugeber schrieb:>> Meine Vorgabe steht: 8 Minuten für alle 3 Varianten>> Sensationell! Karl heinz Buchegger, du überholst dich noch selbst :-).> Solange bräuchte ich bereits, um erst mal zu überlegen, woher ich mir> den Code zusammenkopiere. ;)
OK.
Ich geb zu, das war jetzt ein wenig unfair. Als ich weiter oben den
qsort erwähnte, geschah das ohne Hintergedanken. Ich brauchte nur etwas,
bei dem der algorithmische Unterschied eklatant und leicht
nachzuvollziehen ist. Als ich dann heut Nacht die Assembler Entgegnung
gelesen hatte, ist mir ein paar Minuten später eingefallen, dass C ja in
der Standard-Lib einen qsort mitbringt. Ist ein wenig unfair. Auf der
anderen Seite aber auch ein schönes Beispiel dafür, wieviel
Entwicklungszeit man sparen kann, wenn man fertige Libraries hat.
Allerdings. So unfair ist das auch wieder nicht. Er hat ja einen Link
auf einen fertigen Quick-Sort. Ich kann halt den aus der C-Lib mit 3
Zeilen Code auf meine Daten anpassen. Bei seiner Lösung wird das ein
weniger aufwändiger :-)
Daher auch das Angebot etwas zu machen, wo jeder bei 0 anfangen muss
(Ausser natürlich die Grafik-Lib)
So, und jetzt möchte ich sehen, um wieviel er das tatsächlich schlagen
kann. Er tut ja die ganze Zeit so, als ob C Programme gegenüber seinen
Assembler Programmen in Zeitlupe laufen. Dafür hätte ich jetzt gerne mal
einen handfesten Beleg. Und zwar mit etwas was ein bischen komplexer und
näher an der Realität liegt, als 3 Zahlen zusammenzählen ist.
Vielleicht kommt ja auch raus, das wir alle falsch liegen. Mag sein.
Aber ich kann einfach nicht hinnehmen, dass hier auf einem
'Qualitätsbegriff' herumgeritten wird, der meiner Meinung nach mit der
Realität nichts oder nicht sehr viel zu tun hat.
Karl heinz Buchegger schrieb:> Vielleicht kommt ja auch raus, das wir alle falsch liegen. Mag sein.> Aber ich kann einfach nicht hinnehmen, dass hier auf einem> 'Qualitätsbegriff' herumgeritten wird, der meiner Meinung nach mit der> Realität nichts oder nicht sehr viel zu tun hat.>>>> Beitrag melden | Bearbeiten | Löschen |
Letztenendes ist ja die Frage, wie Qualität definiert wird. Dirk
Wolfgang versteht darunter offensichtlich "möglichst wenige Taktzyklen".
Unter der Voraussetzung, dass eine Software das tut, was sie soll
(korrekte Erledigung der Aufgabe in einer für den Benutzer annehmbaren
Zeit), ist - wie bereits mehrfach erwähnt - das Einsparen des letzten
überflüssigen Taktzyklus völlig irrelevant. Wichtig sind da Wartbarkeit
und "Einsparen von Taktzyklen" beim Erstellen der Software.
Da die beiden Diskussionsparteien aber unterschiedliche Vorstellungen
von Softwarequalität haben, dürfte diese Diskussion noch endlos
weitergehen... ;-)
Gruß
Markus
Thread beobachten
Seitenaufteilung abschalten