www.mikrocontroller.net

Forum: PC-Programmierung C: Pixel auf dem Bildschirm ausgeben


Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: ikarus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es auch irgendwas ganz einfaches?

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SDL

Kann ein Fenster aufmachen, dessen Pixel du dann um schlimmsten Fall als 
Array beharken kannst.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
C64

Autor: Jean Payer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: ikarus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: dreikleinepunkte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GB schrieb:
> Gibt es nicht eine erweiterte stdio.h, mit der man auch einzelne Pixel
> darstellen kann?
ASCII Art??

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe hier etwas ähnliches gefunden:

http://www.wer-weiss-was.de/theme9/article4548770.html

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>
int main(int argc, char *argv[])
{
HDC hdc;
COLORREF col;
hdc=GetDC(0);
col=GetPixel(hdc,100,100);
printf("%d %d %d  ",GetRValue(col),GetGValue(col),GetBValue(col));
system("PAUSE"); 
return 0;
}


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);  ???

Autor: Sebastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Läubi .. schrieb:
> ASCII Art??
Fraktale mit Text-Auflösung? Spannend ;-)

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian schrieb:
> Unter DOS
> eventuell mit einer VESA-Bibliothek.
Die Konsolenanwendung läuft meines Wissens unter DOS, dann könnte das ja 
gehen...

Autor: dreikleinepunkte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GB schrieb:
> Wie mag wohl der Befehl für Pixel-Setzen lauten?
> ??? SetPixel(Farbe,x,y);  ???

Kurzes Googlen bringt 
http://msdn.microsoft.com/en-us/library/dd145078%2... zu 
tage, wenn du dir das (Win-API) wirklich antun willst...

Autor: dreikleinepunkte (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Regnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Lauert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Silvan König (silvan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: roboter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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++...

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>       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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)))><

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: pixelschupser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
GB schrieb:
> Läubi .. schrieb:
>> ASCII Art??
> Fraktale mit Text-Auflösung? Spannend ;-)

Klar, das ist gar kein Problem. Hier mal ein Beispiel von mir, mit einem 
Common Lisp programm generiert:

Youtube-Video "Mandelbrot set zoom in ASCII"

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 
Youtube-Video "puls" von 
http://rrrola.wz.cz/downloads.html (inkl. Quelltext)).

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurde das hier schon mal erwähnt:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
> Youtube-Video "puls" 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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Dirk

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> 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".

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 ..

;-)

Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eagle gab es schon für DOS, habe damit noch gearbeitet.

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Soviel hat sich mit der Windows-Version nicht geändert. Immer noch 
dasselbe intuitiv bedienbare Benutzerinterface :-)

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Anfrage nach alten DOS-Lizenzen wird sich wohl in überschaubaren 
Grenzen halten bei Cadsoft. ;)

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Valentin Buck (nitnelav) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich.
Komme damit besser klar, als mit Eagle!
Umbedingt ausprobieren!
Mit fruendlichen Grüßen,
Valentin Buck

Autor: hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Threadstarter hat sich überhaupt nicht über DOS ausgelassen, das hat 
alles Dirk Wolfgang losgetreten.

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

/* SetPixel() Win32 Programming code 
   simply compile with PellesC (or MS)
   http://www.smorgasbordet.com/pellesc/index.htm */
 

#include <windows.h>

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
                    PSTR szCmdLine, int iCmdShow)
     {
     static char szAppName[] = "SetPixelFunc" ;
     HWND        hwnd ;
     MSG         msg ;
     WNDCLASSEX  wndclass ;

     wndclass.cbSize        = sizeof (wndclass) ;
     wndclass.style         = CS_HREDRAW | CS_VREDRAW ;
     wndclass.lpfnWndProc   = WndProc ;
     wndclass.cbClsExtra    = 0 ;
     wndclass.cbWndExtra    = 0 ;
     wndclass.hInstance     = hInstance ;
     wndclass.hIcon         = LoadIcon (NULL, IDI_APPLICATION) ;
     wndclass.hCursor       = LoadCursor (NULL, IDC_ARROW) ;
     wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;
     wndclass.lpszMenuName  = NULL ;
     wndclass.lpszClassName = szAppName ;
     wndclass.hIconSm       = LoadIcon (NULL, IDI_APPLICATION) ;

     RegisterClassEx (&wndclass) ;

     hwnd = CreateWindow (szAppName, "SetPixel()-Function",
                          WS_OVERLAPPEDWINDOW,
                          CW_USEDEFAULT, CW_USEDEFAULT,
                          CW_USEDEFAULT, CW_USEDEFAULT,
                          NULL, NULL, hInstance, NULL) ;

     ShowWindow (hwnd, iCmdShow) ;
     UpdateWindow (hwnd) ;

     while (GetMessage (&msg, NULL, 0, 0))
          {
          TranslateMessage (&msg) ;
          DispatchMessage (&msg) ;
          }
     return msg.wParam ;
     }

LRESULT CALLBACK WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
     {
     static int  cxClient, cyClient ;
     HDC         hdc ;
     PAINTSTRUCT ps ;

     switch (iMsg)
          {
          case WM_SIZE:
               cxClient = LOWORD (lParam) ;
               cyClient = HIWORD (lParam) ;
               return 0 ;

          case WM_PAINT:
               hdc = BeginPaint (hwnd, &ps) ;
               
         SetPixel(hdc, cxClient/2, cyClient/2, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2 - 1, cyClient/2, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2 - 2, cyClient/2, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2 + 1, cyClient/2, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2 + 2, cyClient/2, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2, cyClient/2 - 1, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2, cyClient/2 - 2, RGB(255,0,0));  
         SetPixel(hdc, cxClient/2, cyClient/2 + 1, RGB(255,0,0));  
             SetPixel(hdc, cxClient/2, cyClient/2 + 2, RGB(255,0,0));           
         return 0 ;

          case WM_DESTROY:
               PostQuitMessage (0) ;
               return 0 ;
          }

     return DefWindowProc (hwnd, iMsg, wParam, lParam) ;
     }


Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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:

/* SetPixel() Win32 Programming code 
   simply compile with PellesC
   http://www.smorgasbordet.com/pellesc/index.htm */
 

#include <windows.h>

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
                    PSTR szCmdLine, int iCmdShow)
     {
     static char szAppName[] = "SetPixelFunc" ;
     HWND        hwnd ;
     MSG         msg ;
     WNDCLASSEX  wndclass ;

     wndclass.cbSize        = sizeof (wndclass) ;
     wndclass.style         = CS_HREDRAW | CS_VREDRAW ;
     wndclass.lpfnWndProc   = WndProc ;
     wndclass.cbClsExtra    = 0 ;
     wndclass.cbWndExtra    = 0 ;
     wndclass.hInstance     = hInstance ;
     wndclass.hIcon         = LoadIcon (NULL, IDI_APPLICATION) ;
     wndclass.hCursor       = LoadCursor (NULL, IDC_ARROW) ;
     wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;
     wndclass.lpszMenuName  = NULL ;
     wndclass.lpszClassName = szAppName ;
     wndclass.hIconSm       = LoadIcon (NULL, IDI_APPLICATION) ;

     RegisterClassEx (&wndclass) ;

     hwnd = CreateWindow (szAppName, "SetPixel()-Function",
                          WS_OVERLAPPEDWINDOW,
                          CW_USEDEFAULT, CW_USEDEFAULT,
                          CW_USEDEFAULT, CW_USEDEFAULT,
                          NULL, NULL, hInstance, NULL) ;

     ShowWindow (hwnd, iCmdShow) ;
     UpdateWindow (hwnd) ;

     while (GetMessage (&msg, NULL, 0, 0))
          {
          TranslateMessage (&msg) ;
          DispatchMessage (&msg) ;
          }
     return msg.wParam ;
     }

LRESULT CALLBACK WndProc (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
     {
     static int  cxClient, cyClient ;
     HDC         hdc ;
     PAINTSTRUCT ps ;

     switch (iMsg)
          {
          case WM_SIZE:
               cxClient = LOWORD (lParam) ;
               cyClient = HIWORD (lParam) ;
               return 0 ;

          case WM_PAINT:
               hdc = BeginPaint (hwnd, &ps) ;
               
               SetPixel(hdc, cxClient/2, cyClient/2, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2 - 1, cyClient/2, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2 - 2, cyClient/2, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2 + 1, cyClient/2, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2 + 2, cyClient/2, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2, cyClient/2 - 1, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2, cyClient/2 - 2, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2, cyClient/2 + 1, RGB(255,0,0));  
               SetPixel(hdc, cxClient/2, cyClient/2 + 2, RGB(255,0,0));           
               EndPaint (hwnd, &ps) ;   
      return 0 ;

          case WM_DESTROY:
               PostQuitMessage (0) ;
               return 0 ;
          }

     return DefWindowProc (hwnd, iMsg, wParam, lParam) ;
     }


Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk Wolfgang Glomp schrieb:
> Also wenn schon Windows dann MASM32

Um Gottes Willen!

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 .. ;))

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rufus Τ. Firefly schrieb:
> Dirk Wolfgang Glomp schrieb:
>> Also wenn schon Windows dann MASM32
>
> Um Gottes Willen!

Wiso, gibt es damit Probleme?

Dirk

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mitlesender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
chris schrieb:
>>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

Danke schön. Auch ich habe gestern mal etwas herum gesucht und folgende 
Seite gefunden: http://www.lowlevel.eu/wiki/Hauptseite

Dirk

Autor: mitlesender (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ....
  // Kreisboegen in Liniensegmente zerlegen
  outContur.ArcsToLines(ifcIter.Precision().SegAng(),ifcIter.Precision().DistEps());
  inConturs.ArcsToLines(ifcIter.Precision().SegAng(),ifcIter.Precision().DistEps()); 

  // falls Extruderichtung nicht xy - parallel ist [und das Profil keine Kreisboegen ent-
  // haelt], kann das IfcExtrudedAreaSolid auf eine schraege Box umgerechnet werden

  RPT3 proDirX = {-extDir.Ry,extDir.Rx,0.}, proDirY;

  Ve3dEinheitsVek(proDirX,&proDirX);
  VE3D_EX_PROD(extDir,proDirX,proDirY) 

  // ermittle neue Extrudematrix, "extDir" werde zu neuer z - Richtung
  UT_MAT44 proMat;
  Mt44Ident(proMat);
  RPT3_TO_REALVEC(proDirX,proMat[0])
  RPT3_TO_REALVEC(proDirY,proMat[1]) 
  RPT3_TO_REALVEC(extDir, proMat[2])

  // setze neue Extrudematrix
  Mt44Concat(proMat,extMat,extMat);
  Mt44Invert(proMat,proMat);

  // ermittle neue untere und obere Ebenennormalen aus Sicht der neuen Extrudematrix
  REAL len = sqrt(pow(proMat[2][0],2) + pow(proMat[2][1],2) + pow(proMat[2][2],2));

  if (len < ifcIter.Precision().RealEps())
    return E_ILL_PARAM;


... (um jetzt einfach mal einen Ausschnitt zu nehmen), übersetzt du 
nämlich nicht mal eben locker in Assembler mit einer optimalen 
Registerausnutzung.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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 :-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Dirk Wolfgang Glomp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Ok, ab nun verschone ich deine Nerven, du willst anscheinend meine Worte 
nicht verstehen.

Dirk

Autor: Frank Buss (foobar)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk Wolfgang Glomp schrieb:
>
> ....siiiicher so völlig uninteressant wie Jan Bruns Quicksort:
> http://www.foonews.info/de-comp-lang-assembler-x86...

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:
qsort :: Ord a => [a] -> [a]
    qsort []     = []
    qsort (x:xs) = qsort kleiner ++ [x] ++ qsort groesser
                   where
                      kleiner  = [y | y <- xs, y < x]
                      groesser = [y | y <- xs, y >= x]

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 :-)

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...
>
> 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:
>
>
> qsort :: Ord a => [a] -> [a]
>     qsort []     = []
>     qsort (x:xs) = qsort kleiner ++ [x] ++ qsort groesser
>                    where
>                       kleiner  = [y | y <- xs, y < x]
>                       groesser = [y | y <- xs, y >= x]
> 
>
> 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...
http://www.haskell.org/haskellwiki/Introduction/Di...

> 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 :-)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk Wolfgang Glomp schrieb:

> ....siiiicher so völlig uninteressant wie Jan Bruns Quicksort:
> http://www.foonews.info/de-comp-lang-assembler-x86...
>
> 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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Und dann sortierst du das sowohl nach dem Familiennamen, als auch nach
> dem Vornamen.

Ich fang dann mal an.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

struct Person
{
  char* FirstName;
  char* FamilyName;
};

struct Person member[] = {
  { "Hans",         "Meiser" },
  { "Peter",        "Frankenfeld" },
  { "Hans Joachim", "Kuhelnkampf" },
  { "Hans",         "Rosenthal" },
  { "Barbara",      "Salesch" }
};

#define ARRAY_SIZE(x)  (sizeof(x) / sizeof(*x))


int sortFirstName( const void *elem1, const void *elem2 )
{
  return strcmp( ((struct Person*)elem1)->FirstName, ((struct Person*)elem2)->FirstName );
}

int sortFamilyName( const void *elem1, const void *elem2 )
{
  return strcmp( ((struct Person*)elem1)->FamilyName, ((struct Person*)elem2)->FamilyName );
}

int sortByIndex( const void *elem1, const void *elem2 )
{
  int Index1 = *(int*)elem1;
  int Index2 = *(int*)elem2;

  return strcmp( member[Index1].FirstName, member[Index2].FamilyName );
}


int main()
{
  int i;

  ///
  qsort( member, ARRAY_SIZE( member ), sizeof( *member ), sortFirstName );

  for( i = 0; i < ARRAY_SIZE( member ); ++i )
    printf( "%s %s\n", member[i].FirstName, member[i].FamilyName );
  printf( "\n" );

  ///
  qsort( member, ARRAY_SIZE( member ), sizeof( *member ), sortFamilyName );

  for( i = 0; i < ARRAY_SIZE( member ); ++i )
    printf( "%s %s\n", member[i].FirstName, member[i].FamilyName );
  printf( "\n" );

  ///
  int* Indices = malloc( ARRAY_SIZE( member ) * sizeof( *Indices ) );
  for( i = 0; i < ARRAY_SIZE( member ); ++i )
    Indices[i] = i;

  qsort( Indices, ARRAY_SIZE( member ), sizeof( *Indices ), sortByIndex );

  for( i = 0; i < ARRAY_SIZE( member ); ++i )
    printf( "%s %s\n", member[Indices[i]].FirstName, member[Indices[i]].FamilyName );
  printf( "\n" );

  free( Indices );

  return 0;
}

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 ...
struct Person member[] = {
  { "Hans",         "Meiser" },
  { "Peter",        "Frankenfeld" },
  { "Hans Joachim", "Kuhelnkampf" },
  { "Hans",         "Rosenthal" },
  { "Barbara",      "Salesch" },
  { "Thomas",       "Gottschalk" }
};
... 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.

Autor: Senfdazugeber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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!

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus V. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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