Forum: PC-Programmierung Grafik unter Linux


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Zappenduster (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hi Folks, ich versuche mal mein Problem zu beschreiben. Früher in den 
80gern hatte ich verschiedene Homecomputer, mit Basic als 
Programmierersprache. Da konnte ich mit Befehlen wie PSET und LINE 
Punkte und Linien auf den Bildschirm zeichnen. Man konnte auch mit PEEK 
und POKE direkt in den Bildschirm schreiben. Jetzt sind mindestens 35 
Jahre vergangen und ich vermisse das, die Hard- und Software von damals 
existiert höchstens noch in meiner Erinnerung. Heute habe ich Linux Mint 
und den GCC Compiler. Ich programmiere kleine Progrämmchen in C, die 
irgendwas ausrechnen und das mit printf() anzeigen.
Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen?
Brauche mal echt Hilfe. Vielen Dank :-)

von Sven B. (scummos)


Bewertung
2 lesenswert
nicht lesenswert
Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann für 
einfache Fälle mit gnuplot, für komplexere Darstellung mit Python + 
matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es 
erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit 
wenigen (~10) Zeilen Code (inkl. Einlesen der Daten).

Klar kann man auch in C oder C++ Graphen malen, aber der Aufwand lohnt 
sich meines Erachtens nur als Teil einer größeren Desktop-Anwendung.

: Bearbeitet durch User
von Zappenduster (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ach, da ist mir noch eingefallen, in den 90gern hatte ich QBasic, damit 
habe ich viel gemacht. Unter SCREEN 12 ging 640x480 in 16 Farben. 
Seufz...

von Zappenduster (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann
> für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python +
> matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es
> erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit
> wenigen (~10) Zeilen Code (inkl. Einlesen der Daten).
>
Wenn ich denn Workflow richtig verstehe, müsste ich da mein  C Programm 
starten, ein paar Parameter eingeben, das Programm schreibt sowas wie 
HPGL in eine Datei, die ich mit Gnuplot anzeigen lassen.

Hübsch, aber ich wollte wirklich wie bei einem ZX81 Grafik in Echtzeit.

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Ok. Mit den C-Grafikframeworks kenne ich mich jetzt nicht so aus. Ich 
persönlich würde sowas wie QCustomPlot oder Qwt benutzen, was relativ 
stark abstrahierte Plotting-Frameworks auf Basis von Qt/C++ sind.

Vielleicht passt dir aber sowas wie SDL besser, das ist sehr einfach. 
Hier werden z.B. mit SDL ein paar Linien gemalt:
https://wiki.libsdl.org/SDL_RenderDrawLine

Kompilieren lässt sich das bei mir auch recht simpel mit
gcc -o test test.c -lSDL2 -I/usr/include/SDL2

von Tom (Gast)


Bewertung
1 lesenswert
nicht lesenswert

von karadur (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schau mal unter Linux nach der Xlib.

von Sven B. (scummos)


Bewertung
0 lesenswert
nicht lesenswert
Was immer du tust nimm nicht die Xlib, da ist sich jeder seit 15 Jahren 
einig, dass das nicht der Weg ist wie man Kram zeichnet.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Direkt auf der Linux Textkonsole geht es nicht so gut, man müsste auf 
framebuffer umschalten (oder geht da etwa sixel-Grafik?).

Heutzutage hat man eine grafische Oberfläche auf der man ein Fenster mit 
Kommandozeile starten kann auf der man mit
xterm -t
ein Tektronix-Grafikterminal tek4014 emulieren kann. Das kann man zwar 
nicht mit poke() ansprechen, aber mit Escape-Sequenzen. Ich glaube, die 
echten tek4014 aus Hardware konnten damals 4096x4096 Pixel, heute muss 
man nehmen, was der Monitor halt hergibt :)

von A. N. (bastelmaniac)


Bewertung
0 lesenswert
nicht lesenswert
Nimm sowas wie Colour Maximite 2 und ähnliche Projekte.

Die funktionieren im Grund noch so wie in den 80er Jahren.

So ein Verhalten unter Linux, Windows, MacOS, BSD und was auch immer 
heutzutage hinzubekommen ist im Grunde nur als VM oder Emulation 
möglich.

von Klaus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vielleicht ist Lua Quick Try Out was für dich: 
http://www.aaabbb.de/Lua-Quick-Try-Out/Lua-Quick-Try-Out.php

von Johannes U. (kampfradler)


Bewertung
0 lesenswert
nicht lesenswert
Schau Dir mal GLE an:

>http://www.gle-graphics.org/

Beispiele hier:
>http://www.gle-graphics.org/examples/index.html

Fand ich komfortabler als gnuplot.
Laesst sich scripten und produziert vectoroutput.

j

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
Zappenduster schrieb:

> Hi Folks, ich versuche mal mein Problem zu beschreiben.
> Früher in den 80gern hatte ich verschiedene Homecomputer,
> mit Basic als Programmierersprache. Da konnte ich mit
> Befehlen wie PSET und LINE Punkte und Linien auf den
> Bildschirm zeichnen. Man konnte auch mit PEEK und POKE
> direkt in den Bildschirm schreiben. Jetzt sind mindestens
> 35 Jahre vergangen und ich vermisse das, die Hard- und
> Software von damals existiert höchstens noch in meiner
> Erinnerung.

Ich glaube, ich kenne die Situation.
Um das Jahr 2000 herum war ich auf der Suche nach einer
Programmiersprache, die folgende drei Kriterien erfüllt:
- es sollte eine Interpretersprache ("Scriptsprache") sein,
- sie sollte reguläre Ausdrücke kennen,
- sie sollte einfache Graphik ermöglichen.


> Heute habe ich Linux Mint und den GCC Compiler. Ich
> programmiere kleine Progrämmchen in C, die irgendwas
> ausrechnen und das mit printf() anzeigen.
> Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen?

Indem Du kein C verwendest.

Ich bin damals nach einigem Suchen und Probieren bei Tcl/Tk
gelandet.
Wenn Du schon C kannst, wird Dir Tcl sehr leicht fallen;
anders ist nur, dass es
- keine Datentypen,
- keine Pointer und
- keine Arrays gibt,
dafür kann man hemmungslos mit Strings, Listen und assoziativen
Arrays herumhantieren.

Tk ist hübsch, weil man damit
- mausbedienbare ereignisgesteuerte GUIs bauen kann,
- Graphik-Canvases anlegen und auf denen nach Herzenslust
  zeichnen kann,
- den ganzen Graphik-Output mit einem Befehl als PostScript
  abspeichern kann, z.B. um es auszudrucken.

Fairerweise muss ich sagen, dass Tk wichtiger ist als Tcl;
es gibt nämlich auch perl/Tk, python/Tk und ruby/Tk. Eigene
Erfahrungen habe ich damit aber nicht.


> Brauche mal echt Hilfe. Vielen Dank :-)

HTH

von Lothar (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Homecomputer mit Basic als Programmierersprache
> konnte ich mit Befehlen wie PSET und LINE

Ein Pi mit RISC OS?

https://de.wikipedia.org/wiki/BBC_BASIC

> PEEK und POKE

https://www.riscosopen.org/wiki/documentation/show/*Memory

https://www.riscosopen.org/wiki/documentation/show/*MemoryA

> Linux Mint und den GCC Compiler

GCC gibt es auch für RISC OS. Grafik funktioniert in C genauso wie in 
BASIC

https://www.riscos.info/index.php/GCC_for_RISC_OS

von nnnnn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
X: sdl_gfx in C oder FreeBASIC
Framebuffer: laserboy

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Ich programmiere kleine Progrämmchen in C, die
> irgendwas ausrechnen und das mit printf() anzeigen.

Die einfachste Moeglichkeit das zu schaffen duerfte in der Tat das 
direkte ansprechen von xlib sein. Allerdings ist das auch so kacke das 
du das nicht wirklich willst.
Die zweiteinfachste Loesung ist dann xforms. Das ist ebenfalls noch 
ziemlich schlicht, aber damit solltest du nach 1-2h deinen ersten pixel 
blinken sehen.

Alles was darueber hinaus geht wird dann deutlich komplexer.

Olaf

von Programmierer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Man konnte auch mit PEEK und POKE direkt in den Bildschirm schreiben.

Um dem aus technologischer Sicht in einer Linux-Anwendung am Nächsten zu 
kommen müsste man Vulkan nutzen, was es erlaubt mehr oder weniger direkt 
in den Grafikspeicher zu schreiben. Das ist allerdings ziemlich 
aufwendig und komplex. Noch näher wäre wohl nur an den Grafiktreibern 
rumzuhacken.

Realistisch wäre z.B. Gtk+ und das GtkDrawingArea widget in welches man 
mittels Cairo diverse Grafikelemente zeichnen kann, oder eines der 
vielen anderen Toolkits wie Qt.

von sam (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit Processing als Sprache/Anzeigeframework. Bietet 
zahlreiche gute Grafik-primitive wie einzelne Pixel setzen oder Linien 
Zeichen.
Die Sprache ist C extrem ähnlich und kann man ohne umgewöhnung nutzen.
Processing ist genau für solche Anforderungen entwickelt worden und ist 
um Größenordnungen einfacher als wenn man ein großen Grafik-Framework 
mit C bespielen möchte.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Da konnte ich mit Befehlen wie PSET und LINE Punkte und Linien auf den
> Bildschirm zeichnen.

Wenn du mit so wenig zufrieden bist, kannst du dir mal das da anschauen:

  https://www3.nd.edu/~dthain/courses/cse20211/fall2013/gfx/

Das ist sehr primitiv, dafür aber auch sehr einfach in der Anwendung.

> Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen?

Wenn es dir mehr um die Darstellung von Funktionsgraphen geht (mit
Koordinatenachsen und -beschriftung, Legende usw.), würde ich – wie
schon von anderen vorgeschlagen – Matplotlib (mit Python) oder Gnuplot
nehmen. Gnuplot kann stand-alone (mit seiner eigenen Skriptsprache)
verwendet werden, du kannst die Befehle und Daten aber auch von einem
C-Programm hinüberpipen (bspw. mit popen). Eine Zwischendatei brauchst
du nicht unbedingt.

von Udo K. (udok)


Bewertung
0 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Hi Folks, ich versuche mal mein Problem zu beschreiben. Früher in den
> 80gern hatte ich verschiedene Homecomputer, mit Basic als
> Programmierersprache. Da konnte ich mit Befehlen wie PSET und LINE
> Punkte und Linien auf den Bildschirm zeichnen. Man konnte auch mit PEEK
> und POKE direkt in den Bildschirm schreiben. Jetzt sind mindestens 35
> Jahre vergangen und ich vermisse das, die Hard- und Software von damals
> existiert höchstens noch in meiner Erinnerung. Heute habe ich Linux Mint
> und den GCC Compiler. Ich programmiere kleine Progrämmchen in C, die
> irgendwas ausrechnen und das mit printf() anzeigen.
> Wie könnte ich Grafik, z.B. eine Sinusfunktion darstellen?
> Brauche mal echt Hilfe. Vielen Dank :-)

Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows
ausgeben kannst:

https://github.com/yottaawesome/programming-windows-5th-edition/blob/master/src/Chap05/SineWave/SineWave.c

Der Sinus wird mit der Funktion Polyline() in Zeile 84
in den Framebuffer geschrieben.
Die x und y Werte werden in der for Schleife berechnet,
und in das Punkte-Feld apt[] geschrieben.
 for (i = 0 ; i < NUM ; i++)
 {
     apt[i].x = i * cxClient / NUM ;
     apt[i].y = (int) (cyClient / 2 * (1 - sin(TWOPI * i / NUM))) ;
 }
          
 Polyline (hdc, apt, NUM) ;

Das kannst du auch mit dem Mingw gcc kompilieren,
oder mit dem beiliegenden VS2019 Project File unter Windows,
oder einfach auf der Kommandozeile mit:
cl.exe -O SineWave.c gdi32.lib user32.lib

Das läuft auch problemlos im Windows Subsystem für Linux
oder auf Linux mit dem Windows Emulator Wine.

In dem Github Verzeichnis findest du auch viele andere einfache
Beispiele, für Menüs, Rechtecke, Textausgabe und Mausinteraktion.

: Bearbeitet durch User
von Miro V. (miro_v)


Bewertung
0 lesenswert
nicht lesenswert

von Sven B. (scummos)


Bewertung
3 lesenswert
nicht lesenswert
Udo K. schrieb:
> Das läuft auch problemlos im Windows Subsystem für Linux
> oder auf Linux mit dem Windows Emulator Wine.

Naja, also man kann unter Linux auch Linien malen, ohne die 
plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und 
das Ergebnis mit Wine auszuführen. Danke für deine Mühe den Beitrag zu 
schreiben, aber sorry, das ist echt mal wieder eine krasse 
Frankenstein-Lösung.

von back from the future (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Udo K. schrieb:


>
> Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows
> ausgeben kannst:

Buuh,Buuuuuh!!!!  :-)




  

#!/bin/bash
# plotsine.sh
# A DEMO to display a sinewave inside a standard bash terminal.
# Issued as Public Domain, 2014, B.Walker, G0LCU.
# Device: Macbook Pro 13", OSX 10.7.5, default bash terminal.
# Use variables so that you can see how it works.
angle=0
step_angle=5
vert_plot=0
horiz_plot=5
centreline=12
amplitude=11
PI=3.14159
clear
# Do a single cycle, quantised graph.
while [ $angle -le 359 ]
do
  # Create each floating point value...
  # CygWin now catered for... ;o)
  vert_plot=$(awk "BEGIN{ printf \"%.12f\", ((sin($angle*($PI/180))*$amplitude)+$centreline)}")
  #vert_plot=$(bc -l <<< "{print ((s($angle*($PI/180))*$amplitude)+$centreline)}")
  # Truncate the floating point value to an integer then invert the plot to suit the x y co-ordinates inside a terminal...
  vert_plot=$((24-${vert_plot/.*}))
  # Plot the point(s) and print the angle at that point...
  printf "\x1B["$vert_plot";"$horiz_plot"f*"
  printf "\x1B[22;1fAngle is $angle degrees..."
  sleep 0.1
  # Increment values...
  angle=$((angle+step_angle))
  horiz_plot=$((horiz_plot+1))
done
printf "\x1B[23;1fSinewave plotted as a quantised text mode graph.\n"
exit 0


von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
Sven B. schrieb:
> Naja, also man kann unter Linux auch Linien malen, ohne die
> plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und
> das Ergebnis mit Wine auszuführen.

Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux?

Die Windows Lösung ist für einen Menschen, der mit C in den 90'ern
grossgeworden ist, einfach zu verstehen, und lässt sich leicht
mit Menüs, Dialogen oder Mauseingabe erweitern.
Und der Code ist effizient und knackig, so wie wir es hier gerne haben.
Das Programm ist unter 3 kByte unter Windows.

Die Performance dürfte selbst unter Linux x-mal schneller sein, als ein
Bash Skript, oder gnuplot, die ja nicht mal interaktiv sind.

Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows
Gui Api endlich mal "native" portieren würden,
so dass das Wine Geraffel unnötig wird.  Ich glaube, die GDI+ Bibliothek
läuft ja schon unter Mono/Cairo?
Dann hätte Linux endlich eine passable Gui Bibliothek :-)

: Bearbeitet durch User
von Linuxer (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Seit HTML5 und Canvas mach ich solche kleinen Programmchen immer in 
JavaScript.

von Gut gekaut ist halb gekackt (Gast)


Bewertung
0 lesenswert
nicht lesenswert
SVGAlib

https://en.wikipedia.org/wiki/SVGALib

Wobei ich aus Altersgründen heutzutage eher zu python rate: 
https://gertingold.github.io/pythonnawi/graphics.html

von back from the future (Gast)


Bewertung
0 lesenswert
nicht lesenswert
back from the future schrieb:

Just kidding aber forumsfreundlich ist das schon  :)
> ...
p450:$ ./sine.sh




                  *********
               ***         ***
              *               *
            **                 **
           *                     *
          *                       *
         *                         *
        *                           *
       *                             *
      *                               *
    **                                 **
                                         *                                 *
                                          *                               *
                                           *                             *
                                            *                           *
                                             *                         *
                                              *                       *
                                               *                     *
                                                **                 **
                                                  *               *
Angle is 355 degrees...                            ***         ***
Sinewave plotted as a quantised text mode graph.      *********
box://mnt/disk2/vid-tmp

---
Ernsthaft das tk toolkit ist immer noch gut.
Mit welcher Sprache auch immer incl. C

von Programmierer (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows
> ausgeben kannst:

Hier ein simples Beispiel mit dem Gtk+, welches direkt unter Linux und 
Windows geht. Zeigt statt des Sinus einen Kreis.

Udo K. schrieb:
> Die Windows Lösung ist für einen Menschen, der mit C in den 90'ern
> grossgeworden ist, einfach zu verstehen, und lässt sich leicht
> mit Menüs, Dialogen oder Mauseingabe erweitern.

Dito. Der Code ist aber nur halb so lang wie der Win32-Api-Code.

Udo K. schrieb:
> Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows
> Gui Api endlich mal "native" portieren würden,
> so dass das Wine Geraffel unnötig wird.

Hä, genau das ist doch Wine. Was will man mehr? Das direkt in den 
Kernel zu integrieren? Das wird wohl nie passieren. Wie wäre es damit, 
wenn Windows mal statt der kruden selbstgebastelten APIs die 
standardisierten POSIX-APIs unterstützten würde, genau wie Linux? Mit 
WSL haben sie das ja quasi bei Linux geklaut. Und das POSIX Subsystem 
für Windows ist ja auch keine Alternative.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Programmierer schrieb:
> Wie wäre es damit, wenn Windows mal statt der kruden
> selbstgebastelten APIs die standardisierten POSIX-APIs
> unterstützten würde, genau wie Linux?

Naja, POSIX ist jetzt aber nicht gerade grafikfähig, und wenn du dich 
mal bei den BSDs (oder Projekten wie Busybox/Toybox) umhörst, dann 
nutzen die meisten Linux-Anwendungen eben nicht POSIX-APIs, sondern 
verschiedene GNU- und Linux-Extensions.

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Udo K. schrieb:
> Sven B. schrieb:
>> Naja, also man kann unter Linux auch Linien malen, ohne die
>> plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und
>> das Ergebnis mit Wine auszuführen.
>
> Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux?

Auf dem niedrigsten Abstraktionsniveau unter X11 (mit der libX11) sieht
das so aus wie im Anhang.

von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
Programmierer schrieb:
> Udo K. schrieb:
>> Ok, hier ein einfaches Beispiel wie du einen Sinus unter Windows
>> ausgeben kannst:
>
> Hier ein simples Beispiel mit dem Gtk+, welches direkt unter Linux und
> Windows geht. Zeigt statt des Sinus einen Kreis.

Danke!

Ich sehe jetzt einen schwarzen Kreis, noch keinen Sinus.

Hat mich aber 2 Stunden gekostet, das unter Windows (Cygwin) zum
laufen zu bringen
(Schweissausbruch wenn ich dran denke, pkg-config ist ein Arschtool)

> Dito. Der Code ist aber nur halb so lang wie der Win32-Api-Code.

Dafür ist das Program 30x so gross, ohne die Libs, die man noch
irgendwo installieren muss, und die noch mal ein paar GB sind.
OK, Windows muss man auch erst installieren.
Es schaut auch irgendiwie ungewohnt aus (eher auf der hässlichen Seite).

Aber ok, mein Fehler, das unter Windows zum laufen bringen zu wollen.

Hier nur mal die Liste der benötigten Windows und Linux Libs:

ADVAPI32.dll => /cygdrive/c/Windows/System32/ADVAPI32.dll 
(0x7fffbba00000)
        COMCTL32.dll => 
/cygdrive/c/Windows/WinSxS/amd64_microsoft.windows.common-controls_6595b 
64144ccf1df_6.0.18362.900_none_e6beb9d913147d17/COMCTL32.dll 
(0x7fff91cb0000)
        DNSAPI.dll => /cygdrive/c/Windows/SYSTEM32/DNSAPI.dll 
(0x7fffb83c0000)
        GDI32.dll => /cygdrive/c/Windows/System32/GDI32.dll 
(0x7fffbb9d0000)
        IMM32.dll => /cygdrive/c/Windows/System32/IMM32.dll 
(0x7fffbb1c0000)
        IPHLPAPI.DLL => /cygdrive/c/Windows/SYSTEM32/IPHLPAPI.DLL 
(0x7fffb8380000)
        KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL 
(0x7fffbbce0000)
        KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll 
(0x7fffb9290000)
        MSIMG32.dll => /cygdrive/c/Windows/SYSTEM32/MSIMG32.dll 
(0x7fffb5a30000)
        NSI.dll => /cygdrive/c/Windows/System32/NSI.dll (0x7fffbb400000)
        OLEAUT32.dll => /cygdrive/c/Windows/System32/OLEAUT32.dll 
(0x7fffbb7c0000)
        PROPSYS.dll => /cygdrive/c/Windows/SYSTEM32/PROPSYS.dll 
(0x7fffb56b0000)
        RPCRT4.dll => /cygdrive/c/Windows/System32/RPCRT4.dll 
(0x7fffbab90000)
        SETUPAPI.dll => /cygdrive/c/Windows/System32/SETUPAPI.dll 
(0x7fffba030000)
        SHELL32.dll => /cygdrive/c/Windows/System32/SHELL32.dll 
(0x7fffba4a0000)
        SHLWAPI.dll => /cygdrive/c/Windows/System32/SHLWAPI.dll 
(0x7fffbb1f0000)
        UMPDC.dll => /cygdrive/c/Windows/System32/UMPDC.dll 
(0x7fffb8e40000)
        USER32.dll => /cygdrive/c/Windows/System32/USER32.dll 
(0x7fffbbda0000)
        USP10.dll => /cygdrive/c/Windows/SYSTEM32/USP10.dll 
(0x7fffb3cd0000)
        WINMM.dll => /cygdrive/c/Windows/SYSTEM32/WINMM.dll 
(0x7fff9c8f0000)
        WINSPOOL.DRV => /cygdrive/c/Windows/SYSTEM32/WINSPOOL.DRV 
(0x7fff8a660000)
        WS2_32.dll => /cygdrive/c/Windows/System32/WS2_32.dll 
(0x7fffbb750000)
        bcrypt.dll => /cygdrive/c/Windows/System32/bcrypt.dll 
(0x7fffb9fe0000)
        bcryptPrimitives.dll => 
/cygdrive/c/Windows/System32/bcryptPrimitives.dll (0x7fffb9f10000)
        cfgmgr32.dll => /cygdrive/c/Windows/System32/cfgmgr32.dll 
(0x7fffb9f90000)
        combase.dll => /cygdrive/c/Windows/System32/combase.dll 
(0x7fffbadd0000)
        combase.dll => /cygdrive/c/Windows/System32/combase.dll 
(0xe20000)
        comdlg32.dll => /cygdrive/c/Windows/System32/comdlg32.dll 
(0x7fffbb2b0000)
        cryptsp.dll => /cygdrive/c/Windows/System32/cryptsp.dll 
(0x7fffba010000)
        dwmapi.dll => /cygdrive/c/Windows/SYSTEM32/dwmapi.dll 
(0x7fffb7560000)
        gdi32full.dll => /cygdrive/c/Windows/System32/gdi32full.dll 
(0x7fffb8f40000)
        iconv.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/iconv.dll (0x63940000)
        kernel.appcore.dll => 
/cygdrive/c/Windows/System32/kernel.appcore.dll (0x7fffb8ec0000)
        libatk-1.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libatk-1.0-0.dll (0x62940000)
        libbz2-1.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libbz2-1.dll (0x626c0000)
        libcairo-2.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libcairo-2.dll (0x68dc0000)
        libcairo-gobject-2.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libcairo-gobject-2.dll 
(0x6cf40000)
        libepoxy-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libepoxy-0.dll (0x6df00000)
        libexpat-1.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libexpat-1.dll (0x68f40000)
        libffi-6.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libffi-6.dll (0x6b740000)
        libfontconfig-1.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfontconfig-1.dll 
(0x64f80000)
        libfreetype-6.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000)
        libfreetype-6.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000)
        libfreetype-6.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000)
        libfreetype-6.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000)
        libfreetype-6.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libfreetype-6.dll (0x150000)
        libgcc_s_seh-1.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgcc_s_seh-1.dll 
(0x61440000)
        libgdk-3-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgdk-3-0.dll (0x70ec0000)
        libgdk_pixbuf-2.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgdk_pixbuf-2.0-0.dll 
(0x65340000)
        libgio-2.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgio-2.0-0.dll (0x6d580000)
        libglib-2.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libglib-2.0-0.dll 
(0x685c0000)
        libgmodule-2.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgmodule-2.0-0.dll 
(0x6dd00000)
        libgobject-2.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgobject-2.0-0.dll 
(0x63a40000)
        libgtk-3-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libgtk-3-0.dll (0x66400000)
        libharfbuzz-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libharfbuzz-0.dll 
(0x61600000)
        libintl-8.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libintl-8.dll (0x61cc0000)
        libpango-1.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpango-1.0-0.dll 
(0x65580000)
        libpangocairo-1.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangocairo-1.0-0.dll 
(0x6d4c0000)
        libpangoft2-1.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangoft2-1.0-0.dll 
(0x6d700000)
        libpangowin32-1.0-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpangowin32-1.0-0.dll 
(0x6b280000)
        libpcre-1.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpcre-1.dll (0x69140000)
        libpixman-1-0.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpixman-1-0.dll (0x610000)
        libpng16-16.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/libpng16-16.dll (0x68b40000)
        libwinpthread-1.dll => 
/cygdrive/c/Microsemi/SoftConsole_v6.2/arm-none-eabi-gcc/bin/libwinpthre 
ad-1.dll  (0x64940000)
        msvcp_win.dll => /cygdrive/c/Windows/System32/msvcp_win.dll 
(0x7fffb90e0000)
        msvcrt.dll => /cygdrive/c/Windows/System32/msvcrt.dll 
(0x7fffbacb0000)
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll 
(0x7fffbbf80000)
        ole32.dll => /cygdrive/c/Windows/System32/ole32.dll 
(0x7fffbbab0000)
        powrprof.dll => /cygdrive/c/Windows/System32/powrprof.dll 
(0x7fffb8e50000)
        profapi.dll => /cygdrive/c/Windows/System32/profapi.dll 
(0x7fffb8ee0000)
        sechost.dll => /cygdrive/c/Windows/System32/sechost.dll 
(0x7fffbb120000)
        shcore.dll => /cygdrive/c/Windows/System32/shcore.dll 
(0x7fffbb6a0000)
        ucrtbase.dll => /cygdrive/c/Windows/System32/ucrtbase.dll 
(0x7fffb9540000)
        win32u.dll => /cygdrive/c/Windows/System32/win32u.dll 
(0x7fffb8f10000)
        windows.storage.dll => 
/cygdrive/c/Windows/System32/windows.storage.dll (0x7fffb9640000)
        winmmbase.dll => /cygdrive/c/Windows/SYSTEM32/winmmbase.dll 
(0x7fffa8820000)
        winmmbase.dll => /cygdrive/c/Windows/System32/winmmbase.dll 
(0x180000)
        zlib1.dll => /cygdrive/c/Program Files 
(x86)/Matlab/R2007b/bin/win32/zlib1.dll (0x78620000)
        zlib1.dll => /cygdrive/c/Program Files 
(x86)/Matlab/R2007b/bin/win32/zlib1.dll (0x78620000)
        zlib1.dll => 
/usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll (0x62e80000)

Hoffentlich stimmen da auch alle Versionen der Libs.
Ein echtes Wunder das sowas noch läuft, und dass wir mit solcher Technik
zum Mond fliegen wollen.

Aber ich will nicht lästern.  Es tut, was es soll.
Bis auf den Sinus, der ein schwarzer Kreis ist.

> Udo K. schrieb:
>> Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows
>> Gui Api endlich mal "native" portieren würden,
>> so dass das Wine Geraffel unnötig wird.
>
> Hä, genau das ist doch Wine. Was will man mehr?

Die meinsten kleinen Programme brauchen keine binäre 100% Windows
Emulation, genauso, wie die meisten Linux Programme kein Cygwin
bräuchten.  Eine kleine feine GUI Bibliothek, und eine Standard-C
Lib reicht meist aus.  Zumindest, wenn der Entwickler das Programm
neu übersetzt, und beim Entwickeln dran denkt (Wunschdenken).
Wahrschinelich könnte man sich die relevanten 5-6 Libs irgendwie
aus den Wine Sourcen rausziehen,
man müsste halt die Abhängigkeiten kappen.

 Das direkt in den
> Kernel zu integrieren? Das wird wohl nie passieren.

In den Kernel muss da doch nichts integriert werden.  Das sind User
Libs, die auf Cairo/Pango was auch immer zugreifen.
Ähnlich wie es Mono macht, nur halt für die Win32 GUI Libs.

: Bearbeitet durch User
von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux?

Wie ich schon in Beitrag 3 oder so schrieb, zum Beispiel mit SDL, wenn 
man schlanker sein möchte als Qt und Konsorten. Ansonsten: Qt und 
Konsorten.

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Dafür ist das Program 30x so gross, ohne die Libs, die man noch
> irgendwo installieren muss, und die noch mal ein paar GB sind.
> OK, Windows muss man auch erst installieren.

Genau. Außerdem hat das genau nichts mit dem Thema zu tun. Was bringt 
diese sinnlose Diskussion also? Ja: Windows und Linux haben 
unterschiedliche Konzepte, was Teil des Betriebssystems ist. Ja: das hat 
Konsequenzen dafür, was eine Userspace-Anwendung mitshippen muss. Ja: 
beide Konzepte haben Vor- und Nachteile. Und ja: das wird schon seit 30 
Jahren rauf und runter diskutiert. Können wir das also bitte einfach 
nicht nochmal tun? Sorry, aber deine Beiträge zum Thread sind nur 
sinnloser Noise, der irgendwelche halbgaren Lösungen präsentiert die 
kein vernünftiger Mensch so jemals nutzen würde.

: Bearbeitet durch User
von Zappenduster (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi Folks, ich bin zurück. Ich bin ja ganz erstaunt, wie viele Antworten 
ich bekommen habe. Manche ganz ausführlich, andere fast schon einsilbig. 
Welches ist denn nun die richtige Antwort?
Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie 
bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit 
Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des 
Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben 
darf. Der Speicher ist 1920 x 1080 x 3 Byte gross, das sind knapp 6 
MByte. Ich würde mir dann elementare Funktionen für PSET, LINE etc. 
schreiben. Natürlich muss ich darauf achten, auf keinen Fall außerhalb 
des erlaubten Speichers zu schreiben, sonst ist alles zappenduster!!!

von Udo K. (udok)


Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Udo K. schrieb:
>> Sven B. schrieb:
>>> Naja, also man kann unter Linux auch Linien malen, ohne die
>>> plattformabhängige Windows-API zu benutzen, dann zu cross-compilen und
>>> das Ergebnis mit Wine auszuführen.
>>
>> Ja sicher - davon gehe ich aus, aber wie macht man es jetzt unter Linux?
>
> Auf dem niedrigsten Abstraktionsniveau unter X11 (mit der libX11) sieht
> das so aus wie im Anhang.

Danke Yalu!
Läuft auch unter Cygwin / Windows, und zeichnet einen sehr schönen
Sinus :-)

Leider habe ich es nicht geschafft, das mit Mingw "native" zu 
übersetzen.
Das dürfte aber daran liegen, dass ich den Cygwin X11 Server verwende,
nehme ich jedenfalls an.

Das schaut vom Ergebnis sehr ähnlich wie der Windows Code aus
(Die Fensterrahmen werden vom X-Server dazugemacht).

Der Sourcecode ist praktisch 1:1 wie die Windows Version,
wenn man davon absieht, dass die Funktionsnahmen anders heissen.
Sehr interessant, wie ähnlich Windows und Linux unter Haube 
funktionieren.

Die Abhängigkeiten sind auch erträglich:
ldd ./sine_x11.exe
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll 
(0x7fffbbf80000)
        KERNEL32.DLL => /cygdrive/c/Windows/System32/KERNEL32.DLL 
(0x7fffbbce0000)
        KERNELBASE.dll => /cygdrive/c/Windows/System32/KERNELBASE.dll 
(0x7fffb9290000
)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
        cygX11-6.dll => /usr/bin/cygX11-6.dll (0x3f8a50000)
        cygxcb-1.dll => /usr/bin/cygxcb-1.dll (0x3e1250000)
        cygXau-6.dll => /usr/bin/cygXau-6.dll (0x3f8a20000)
        cygXdmcp-6.dll => /usr/bin/cygXdmcp-6.dll (0x3f8900000)

Das Progarm hat auch sehr annehmbare 9 kByte.
Schön, dass auch unter Linux nicht alles hoffnungslose Bloatware ist.

: Bearbeitet durch User
von Udo K. (udok)


Bewertung
0 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Hi Folks, ich bin zurück. Ich bin ja ganz erstaunt, wie viele
> Antworten
> ich bekommen habe. Manche ganz ausführlich, andere fast schon einsilbig.
> Welches ist denn nun die richtige Antwort?
> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie
> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit
> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des
> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben
> darf. Der Speicher ist 1920 x 1080 x 3 Byte gross, das sind knapp 6
> MByte. Ich würde mir dann elementare Funktionen für PSET, LINE etc.
> schreiben. Natürlich muss ich darauf achten, auf keinen Fall außerhalb
> des erlaubten Speichers zu schreiben, sonst ist alles zappenduster!!!

Na ja, wir haben hier schon drei brauchbare Sinus Programme 
geschrieben...
Suche dir eines aus :-)

von Udo K. (udok)


Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Udo K. schrieb:
>> Dafür ist das Program 30x so gross, ohne die Libs, die man noch
>> irgendwo installieren muss, und die noch mal ein paar GB sind.
>> OK, Windows muss man auch erst installieren.
>
> Genau. Außerdem hat das genau nichts mit dem Thema zu tun. Was bringt
> diese sinnlose Diskussion also? Ja: Windows und Linux haben
> unterschiedliche Konzepte, was Teil des Betriebssystems ist. Ja: das hat
> Konsequenzen dafür, was eine Userspace-Anwendung mitshippen muss. Ja:
> beide Konzepte haben Vor- und Nachteile. Und ja: das wird schon seit 30
> Jahren rauf und runter diskutiert. Können wir das also bitte einfach
> nicht nochmal tun? Sorry, aber deine Beiträge zum Thread sind nur
> sinnloser Noise, der irgendwelche halbgaren Lösungen präsentiert die
> kein vernünftiger Mensch so jemals nutzen würde.

Komisch nur, das von mir ein funktionierendes Program kommt,
und von dir nix.

von karadur (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@Zappenduster

Das sollte/darf kein Betriebssystem zulassen. Dafür gibt es Treiber und 
Libs.

Auf einem AppleII, C64 und Co. mit Singleuser Singletask geht das, aber 
nicht unter Windows und UNIX/Linux.

von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie
> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit
> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des
> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben
> darf. Der Speicher ist 1920 x 1080 x 3 Byte gross, das sind knapp 6
> MByte. Ich würde mir dann elementare Funktionen für PSET, LINE etc.
> schreiben. Natürlich muss ich darauf achten, auf keinen Fall außerhalb
> des erlaubten Speichers zu schreiben, sonst ist alles zappenduster!!!

Wenn du das so machen willst, dann kannst du unter Windows
in ein Bitmap reinschreiben.
Das Bitmap liegt im Speicher, und du hast einen Zeiger auf das erste
Byte.  Du kast darin nach Lust und Laune wüten.
Wenn du fertig bist, mappst du das Bitmap auf dein offenes Fenster.
Du kannst auch festlegen, dass dein Fenster der ganze Bildschirm ist.

Im Petzold steht, wie das genau geht, oder du nimmst die
Standard Funktionen zum Zeichnen von Linien etc.  Das gibt
es ja schon alles fertig.

Hier ein Tutorial dazu (ich habe es aber nicht selber durchgearbeitet):
https://www.codeproject.com/Articles/356/Bitmap-Basics-A-GDI-tutorial

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Komisch nur, das von mir ein funktionierendes Program kommt,
> und von dir nix.

Dein Programm war Unfug. Weil der Thread-Titel "Grafik unter Linux" ist 
und du die Windows-API benutzt hast. Ich habe auf das SDL-Wiki gelinkt, 
wo ein funktionierendes, sinnvolles Programm steht. In Post 3.

Egal. Zum Thema -- das mit der Adresse des Bildschirmspeichers wird so 
nix -- der ist heutzutage nichtmal mehr addressierbar, der steht nämlich 
im Grafikspeicher ;) Außerdem verwaltet das Betriebssystem die 
Ressourcen und lässt kein Usermode-Programm da direkt dran rumpfuschen.

Mit irgendeiner der genannten Lösungen wirst du dich also wohl oder übel 
auseinandersetzen müssen.

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> unter Windows

Kannst du bitte mal den Titel des Threads lesen? Da steht "unter Linux"!

von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
Und du solltest dich auf Version 0.01 updaten.

Die Zeiten, wo Linux Programme nicht unter Windows,
oder Windows Programme nicht unter Linux laufen,
sind zum Glück vorbei.

von back from the future (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Udo K. schrieb:
> Und du solltest dich auf Version 0.01 updaten.
>
> Die Zeiten, wo Linux Programme nicht unter Windows,
> oder Windows Programme nicht unter Linux laufen,
> sind zum Glück vorbei.

Also das konnte man mit tcl/tk spätestens zu W98 Zeiten haben.
Der  vermutlich kürzeste Weg zum Kreis falls man dringend einen braucht;


$wish
% canvas .c -width 200 -height 200 -background white; pack .c
% .c create oval 1 1 200 200 -fill red
%
% wm title . "Kreis in Rot"
%


Unter win geht/?ging? auch das Fenster transparent zu setzen ~wm . alpha 
0.0 dann hat man eben einen roten Fleck auf dem Schirm. Das ist 
vermutlich zu einfach ;) tcl/tk macht nicht Dick!

von Programmierer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Naja, POSIX ist jetzt aber nicht gerade grafikfähig

Für Grafik gibt's dann halt Sachen wie X.

S. R. schrieb:
> dann
> nutzen die meisten Linux-Anwendungen eben nicht POSIX-APIs, sondern
> verschiedene GNU- und Linux-Extensions.

Traue keiner Statistik... Ein ganzer Haufen GNU/Linux-Tools ist z.B. 
fixer Bestandteil von Mac OS X. Linux und BSDs versuchen immerhin 
Standards wie POSIX einzuhalten, und nicht wie Windows etwas völlig frei 
erfundenes absichtlich inkompatibles hinzuklatschen.

Udo K. schrieb:
> Ich sehe jetzt einen schwarzen Kreis, noch keinen Sinus.

Die 3 Zeilen für den Sinus sind dem Leser als Übung überlassen.

Udo K. schrieb:
> Hat mich aber 2 Stunden gekostet, das unter Windows (Cygwin) zum
> laufen zu bringen

Ja unter Windows ist Gtk+ weniger spaßig. Cygwin ist aber unnötig, das 
geht auch "nativ" mit MinGW.

Udo K. schrieb:
> Dafür ist das Program 30x so gross

MSVC macht kleinere Windows-Binaries, für falls deine HDD so klein ist 
dass es nicht passt.

Udo K. schrieb:
> die man noch
> irgendwo installieren muss, und die noch mal ein paar GB sind.
> OK, Windows muss man auch erst installieren.

Unter Linux ist das meist vorinstalliert.

Udo K. schrieb:
> Es schaut auch irgendiwie ungewohnt aus (eher auf der hässlichen Seite).

Installier das "Redmond" Theme. Unter Linux/Gnome fügt sich Gtk+ 
natürlich perfekt ein. b

Udo K. schrieb:
> Hier nur mal die Liste der benötigten Windows und Linux Libs:

Gtk+ ist halt Teil eines komplexen Ökosystems, mit Unterstützung für 
alle möglichen Sprachen, Rechts-Nach-Links-Skripte usw. Das braucht halt 
viele Libs.

Udo K. schrieb:
> Ein echtes Wunder das sowas noch läuft, und dass wir mit solcher Technik
> zum Mond fliegen wollen.

Die Logik zur Darstellung von Unicode-Text dürfte um einiges komplexer 
sein als der Code der Apollo-Missionen. Der konnte nur Englisch... Bei 
Windows ist der halt in C:\Windows mitgeliefert. Gtk+ könnte dynamisch 
unter Windows direkt die Windows-APIs nutzen statt Pango & Co, aber das 
hat halt noch keiner gemacht.

Udo K. schrieb:
> Die meinsten kleinen Programme brauchen keine binäre 100% Windows
> Emulation

Für kleine Programme ist das eh müßig. Die portiert man eben fix oder 
benutzt direkt was portables wie Java.

Udo K. schrieb:
> ine kleine feine GUI Bibliothek, und eine Standard-C
> Lib reicht meist aus.  Zumindest, wenn der Entwickler das Programm
> neu übersetzt, und beim Entwickeln dran denkt (Wunschdenken).

Von der Sorte wurden ja einige genannt. Für meine Zwecke habe ich immer 
lieber vollwertige Bibliotheken benutzt.

Udo K. schrieb:
> In den Kernel muss da doch nichts integriert werden.  Das sind User
> Libs, die auf Cairo/Pango was auch immer zugreifen.

Also die Winelib?

Zappenduster schrieb:
> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie
> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit
> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des
> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben
> darf.

Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig 
unmöglich. Der Kernel abstrahiert die Hardware, und Anwendungen können 
nur über "High-Level" APIs drauf zugreifen. Wie sonst sollen z.B. 
mehrere Fenster gleichzeitig dargestellt werden können?

Wie gesagt ist so etwas ähnliches über Vulkan möglich, aber der Aufwand 
ist in etwa das Hunderfache der anderen genannten Ansätze hier, also 
völlig unangemessen.

Udo K. schrieb:
> Wenn du das so machen willst, dann kannst du unter Windows
> in ein Bitmap reinschreiben.
> Das Bitmap liegt im Speicher, und du hast einen Zeiger auf das erste
> Byte.  Du kast darin nach Lust und Laune wüten.
> Wenn du fertig bist, mappst du das Bitmap auf dein offenes Fenster.
> Du kannst auch festlegen, dass dein Fenster der ganze Bildschirm ist.

Genau das geht unter Linux auch, ob mit Gtk+ oder Xlib oder whatever.

von Worggfloh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Sven B. schrieb:
>> Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann
>> für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python +
>> matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es
>> erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit
>> wenigen (~10) Zeilen Code (inkl. Einlesen der Daten).
>>
> Wenn ich denn Workflow richtig verstehe, müsste ich da mein  C Programm
> starten, ein paar Parameter eingeben, das Programm schreibt sowas wie
> HPGL in eine Datei, die ich mit Gnuplot anzeigen lassen.

Fast ganz richtig. Das Programm schreibt Zahlenkolonnen in die Datei, 
also eher wie eine Tabellenkalkulation.

GnuPlot plottet den Zahlenverlauf, sorgt für die Skalierung (i.d.R. 
automagisch).
Man kann zusätzlich GnuPlot anweisen die Skalenunterteilung, 
Skalenbeschriftung, Farbwahl, Titelstrings & Titelplatzierung nach 
eigenem Wunsch abweichend vom Default zu malen.

++++++

Die andere Variante geht natürlich auch, dann aber ohne GnuPlot.

Das Programm schreibt Steuersequenzen für ein damaliges, grafikfähiges 
Datensichtgerät. Z.B. DEC SIXEL, Tek4014, HPGL, usw. Fügen wir 
sporteshalber auch noch ESC/P und PostScript hinzu, in die Datei.

An die Stelle von GnuPlot treten dann Terminalemulator (z.B. XTerm) 
resp. Druckeremulator (z.B. GhostScript).

+++++

Der dritte Weg wurde auch genannt.
Das Programm schreibt HTML in die Datei. Ein Browser rendert aka 
visualisiert das dann.

+++++

Da Du offensichtlich auf frei adressierbare Pixels bestehst: schau dir 
doch den Aufbau von unkomprimierten Grafik(datei)formate an (z.B. BMP) 
resp. deren in C formulierte Äquivalenzen an. Du lässt dein Programm in 
diese "virtuellen" (besser: unsichtbaren) "Grafikspeicher" malen und zum 
Schluss speicherst das in die Datei.
Angezeigt wird die Datei von Bildbetrachtern, oder wenn nicht zu 
exotisches Format vom (Web)Browser.
Zuwenig interaktiv? Davon war keine Rede in den Anforderungen...

von Worggfloh (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Zappenduster schrieb:
>> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie
>> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit
>> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des
>> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben
>> darf.

Na gut, eine Möglichkeit ist da noch: du betreibst dein Linux auf deiner 
HW in einem "uralt" Modus, wo weder X-11 noch ein Fenstermanager 
gestartet werden. Erteile deinem Programm entsprechende Privilegien und 
sprich die Grafikkarte im entsprechend "uralten" Mode direkt als /frame 
buffer/ an. Unbeschleunigt, eben wie damals.
Seh zu dass du entsprechend Doku zu VGA "wie vor 30 Jahren" zur Hand 
hast und hoffe dass deine aktuelle Grafikkarte diese Modi auch noch 
beherrscht.

Kann man so machen, bloss will das heute nur noch du als einzigster...

von Sven B. (scummos)


Bewertung
-1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Und du solltest dich auf Version 0.01 updaten.
>
> Die Zeiten, wo Linux Programme nicht unter Windows,
> oder Windows Programme nicht unter Linux laufen,
> sind zum Glück vorbei.

Genauso wie die Zeiten, wo die Leute mit Xlib oder der Win32-API Grafik 
gemalt haben. Mann o mann. Das ist wirklich ganz schön desynchronisiert 
zur Realität, was du da von dir gibst.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Programmierer schrieb:

> Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig
> unmöglich. Der Kernel abstrahiert die Hardware, und Anwendungen können
> nur über "High-Level" APIs drauf zugreifen. Wie sonst sollen z.B.
> mehrere Fenster gleichzeitig dargestellt werden können?

Mit dem Windows-API ist es immerhin sehr einfach möglich, den 
Clientbereich eines Fensters quasi zu "Poken". OK, man benutzt eine 
Bitmap als Buffer, aber da sei drauf geschissen...

Es scheint also deutlich näher an den praktischen Erfordernissen zu sein 
als dein hochgelobter "POSIX-Standard"...

Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl 
daran sieht, dass alle für das Wirtschaftsleben wesentlichen 
Desktop-Anwendungen nur für genau dieses Target existieren...

> Genau das geht unter Linux auch, ob mit Gtk+ oder Xlib oder whatever.

Genau das ist das Problem unter Linux. Man kann auf alles mögliche 
treffen. Oder eben auch nicht...

Da muss man dann im Einzelfall mit klarkommen. Unter Windows muss man 
das nicht. Das Win32-API ist so konstant, dass es schon länger in kaum 
veränderter (allerdings erheblich erweiterter) Form existiert, als es 
Linux als OS überhaupt gibt...

Programmierer mögen langzeitstabile APIs und ABIs. Damit haben sie 
nämlich am wenigsten Arbeit bei der Pflege ihrer eigenen Produkte...

von karadur (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Mit der Xlib hab ich 1987 schon unter HP-UX gearbeitet. Da war nix mit 
Win-Api. Da war eher DOS3.3.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Worggfloh schrieb:
> Na gut, eine Möglichkeit ist da noch: du betreibst dein
> Linux auf deiner HW in einem "uralt" Modus, wo weder X-11
> noch ein Fenstermanager gestartet werden.

Alternativ drückst du "Strg+Alt+F1" und schreibst die Datenbytes nach 
/dev/fb0. Das ist vermutlich ziemlich genau das, was der TO will.

Ausprobieren:
- Strg+Alt+F1
- einloggen
- dd if=/dev/urandom of=/dev/fb0
- (den Bildschirm neu zeichnen mit Strg+L)

von Sven B. (scummos)


Bewertung
2 lesenswert
nicht lesenswert
c-hater schrieb:
> Programmierer mögen langzeitstabile APIs und ABIs. Damit haben sie
> nämlich am wenigsten Arbeit bei der Pflege ihrer eigenen Produkte...

Außer natürlich dass du halt das ganze Produkt neu schreiben musst, wenn 
du es auf Android, Linux oder macOS haben willst, wenn es mit der 
win32-API gebaut ist ...

von Olaf (Gast)


Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Im Anhang meine ersten Versuche von 1993 Grafik unter Linux mit xlib 
auszugeben.
Zu meinem erstaunen liess es sich sogar gerade noch uebersetzen und hat 
etwas
ausgegeben. Alles echtes pures C. :-)

Ich wuerde aber trotzdem eher das hier empfehlen:

http://xforms-toolkit.org/

Das ist zwar auch schon steinalt, aber ebenfalls C und funktioniert ganz 
gut.

Aber es war schon erstaunlich das man damals ein Grafikprogramm 
schreiben konnte das nur wenig kb gross war und nicht der aufgeblasene 
Mist der heute so Standard ist.

Olaf

von Olaf (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ich hab gerade noch was gefunden. Auch von 1993. :-)
Das malt mit xlib ein Apfelmaenchen.

Lies sich auch noch uebersetzen, allerding musste ich kurz noch was ins
Makefile reinhacken. Da fehlte eine Libary und wer weis ob Imakefile
heute noch funktioniert.

Damals konnte man dem Programm noch beim malen zuschauen. Das geht heute 
nicht mehr.

Olaf

p.s Und bitte keine beschwerden ueber die Qualitaet des Codes. :-D

von Programmierer (Gast)


Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Und natürlich kann das Windows-API noch sehr viel mehr.

Es kann aber das nicht, wofür X da ist: transparent Grafik übers Netz 
übertragen. Das war nämlich für Mainframes und Terminals erdacht. Dieser 
Use Case ist zwar überholt aber ist der Grund dafür. Gelegentlich ist es 
auch noch recht praktisch X Verbindungen über SSH Tunneln zu können.

c-hater schrieb:
> Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl
> daran sieht, dass alle für das Wirtschaftsleben wesentlichen
> Desktop-Anwendungen nur für genau dieses Target existieren...

Das liegt nicht daran dass das Win32 API so toll wäre. Sondern daran 
dass MS' extrem clevere Strategie zur Markt-Beherrschung und 
Konkurrenz-Unterdrückung Windows überall hin forciert hat. Natürlich 
laufen auch jede Menge Business Anwendungen auch, oder nur, auf Unix 
Systemen.

c-hater schrieb:
> Das Win32-API ist so konstant, dass es schon länger in kaum veränderter
> (allerdings erheblich erweiterter) Form existiert, als es Linux als OS
> überhaupt gibt...

Aber POSIX gibt es noch länger. Anstatt das zu implementieren hat MS was 
eigenes gefrickelt.

Und POSIX ist selbstverständlich auch API und ABI kompatibel.

karadur schrieb:
> Mit der Xlib hab ich 1987 schon unter HP-UX gearbeitet. Da war nix mit
> Win-Api. Da war eher DOS3.3.

Genau!

von aiai (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
SDL mit SDL_gfx kann auch direkt auf Framebuffer ausgeben. Am Programm 
ändert sich GAR NICHTS, nur eine Umgebungsvariable muss geändert werden. 
Wurde schon mehrfach genannt.

Und wer meint, Xlib sei das einfachste, der hat noch nichts anderes 
gesehen oder trollt.
Da ist VGA-register Programmierung fast noch einfacher...

Neben dem sdl wiki gibt's noch wikibooks - SDL_gfx auf Deutsch.

von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
Programmierer schrieb:
> c-hater schrieb:
>> Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl
>> daran sieht, dass alle für das Wirtschaftsleben wesentlichen
>> Desktop-Anwendungen nur für genau dieses Target existieren...
>
> Das liegt nicht daran dass das Win32 API so toll wäre. Sondern daran
> dass MS' extrem clevere Strategie zur Markt-Beherrschung und
> Konkurrenz-Unterdrückung Windows überall hin forciert hat. Natürlich
> laufen auch jede Menge Business Anwendungen auch, oder nur, auf Unix
> Systemen.

Leg mal die Propaganda Brille ab.

Zu der Zeit, als Win32 entstand, hatte
Unix (3D Profi CAD, Visualisierung auf Irix)
und Apple (Drucker, Postscript) die Dominanz im Grafikbereich.
MS mit Windows war damals eine kleine, aufstrebende Nummer.

Daher kommt es, das das Win32 Grafik Api im wesentlichen
dem Postscript Standard nachempfunden ist.
Windows GDI lässt sich Befehl für Befehl auf Postscript abbilden.
Wie 90% aller Grafik Api's aus der Zeit.
Ich glaube Postscript war von Xerox beeinflusst.
Und wie man oben am Sinus Beispiel sieht, ist Xlib
praktisch identisch zum Win32.

Jeder musste schliesslich irgendwann mal vom Bildschirm zum
Drucker laufen.  Und auf dem Drucker lief Postscript.
Das war gerade für die damals aufstrebenden
What-you-see-is-what-you-get Office Programme, mit denen
man im Profi Bereich richtig Geld machen konnte, wichtig.
Aber auch für einträgliche CAD Software, die SW Hersteller
forderten das von MS auch ein.
Ja, damals vor der Open Source Bewegung,
konnte man mit Software Anwendungen gut Geld verdienen.

Von daher ist auch der Aufwand ein Program von "native" Win32 auf
"native" Xlib zu portieren erstaunlich einfach.
Auch wenn es nicht automatisch geht, so sind doch immer ähnliche
Aufrufe vorhanden.

Wenn man sich auf ein komplexes Framework wie
WPF, GTK oder QT verlässt, dann ist man verlassen, wenn
man das portieren muss, oder wenn es aus irgendeinem
Grund mal nicht geht, oder wenn man ein Feature braucht, dass
es nicht unterstützt.
Gerade für den Bastler oder die 10 Mann Bude ist
das ein wichtiger Punkt.
Der kann nicht, wie MS oder IBM, schnell 50 Entwickler abstellen,
die nichts anderes machen, als Integrationstests, die aufpassen
das ein neues Feature/Update der Lib X.Y nicht die Lib A.B
zerschiesst.
Ein einzelner hat keine Change zu durchschauen, wie die Abhängigkeiten
der Libs in einem komplexen Framework sind, gerade wenn Zeitdruck da 
ist.
Er ist dazu verdammt, die Api immer wieder mal falsch
oder suboptimal anzuwenden.

Man sieht die Probleme schon schön an ven vielen DLLs, von denen das GTK
Sinus Program abhängig ist:
Da verwendet das GTK Sinus Program
(das ich weiter oben unter Windows mit Mingw compiliert hatte, und das 
nebenbei nur einen schwarzen Kreis malt)
doch glatt die zlib1 DLL der installierten Matlab Version 2007!
Die DLLs werden aus der PATH Umgebungsvariable geladen, und dynamisch
zur Laufzeit geladen.
Und die Matlab zlib1 DLL kommt vor der GTK eigenen zlib DLL...
Wie schon gesagt, ein Wunder das das funktioniert, bzw. Glück das sich
die zlib seit 20 Jahren nicht wesentlich geändert hat.

: Bearbeitet durch User
von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Wenn man sich auf ein komplexes Framework wie
> WPF, GTK oder QT verlässt, dann ist man verlassen, wenn
> man das portieren muss, oder wenn es aus irgendeinem
> Grund mal nicht geht, oder wenn man ein Feature braucht, dass
> es nicht unterstützt.

Diese Sichtweise ist in meinen Augen total verquer. Ich habe keine 
Ahnung, welchem Gedankengang man folgen muss, um zur Schlussfolgerung zu 
kommen, dass man mit der Windows-API besser dran ist, wenn man eine 
Anwendung portieren muss, als mit einer Qt-Anwendung. Das ergibt einfach 
keinerlei Sinn.

> Er ist dazu verdammt, die Api immer wieder mal falsch
> oder suboptimal anzuwenden.

Das würde natürlich mit der Win32-API NIEMALS passieren!

> Von daher ist auch der Aufwand ein Program von "native" Win32 auf
> "native" Xlib zu portieren erstaunlich einfach.

Bullshit. Das gilt vielleicht für jede einzelne Zeile, aber nimm doch 
bitte mal sowas wie Photoshop und portiere es auf Xlib. Damit wirst du 
in 30 Jahren nicht fertig.
Aus dem beruflichen Umfeld kenne ich Qt-Anwendungen mit Millionen 
Codezeilen. Die von Windows auf macOS zu portieren ist was, was ein paar 
einzelne Leute in ein paar Wochen machen können, weil im Wesentlichen 
alles schon geht und man nur ein paar Randfälle anfassen muss. Auf Linux 
läuft sowas eh ohne nennenswerten Zusatzaufwand, selbst wenn die meiste 
Entwicklung unter Windows passiert.

Hast du jemals an einem größeren Softwareprojekt gearbeitet, was mehrere 
Plattformen unterstützt hat und auch ein paar Jahre lang gewartet und 
benutzt wurde?

: Bearbeitet durch User
von Udo K. (udok)


Bewertung
-1 lesenswert
nicht lesenswert
Sven B. schrieb:
> Udo K. schrieb:

>> Er ist dazu verdammt, die Api immer wieder mal falsch
>> oder suboptimal anzuwenden.
>
> Das würde natürlich mit der Win32-API NIEMALS passieren!

Natürlich passiert das.  Aber das Win32 Api ist vergleichsweise
einfach zu durchschauen.  Zumindest das Win32 Api von Windows XP,
oder auch Xlib/XForms.

Für eine kleine Bude oder einen Hobbyentwickler, der sich nicht
100% mit GUI Entwicklung beschäftigt, kann das der einfachere
Weg zum Ziel sein.  Auch wenn das Progamm dann langweilig ausschaut,
dafür aber klar strukturiert, leicht verständlich
und funktional daherkommt.

>> Von daher ist auch der Aufwand ein Program von "native" Win32 auf
>> "native" Xlib zu portieren erstaunlich einfach.
>
> Bullshit. Das gilt vielleicht für jede einzelne Zeile, aber nimm doch
> bitte mal sowas wie Photoshop und portiere es auf Xlib. Damit wirst du
> in 30 Jahren nicht fertig.

Na ja, es reicht wahrscheinlich Photoshop in einer alten Version
neu für Linux zu übersetzen.
Immerhin lief es mal auf Mac OS, und das war im wesentlichen Unix.

>
> Hast du jemals an einem größeren Softwareprojekt gearbeitet, was mehrere
> Plattformen unterstützt hat und auch ein paar Jahre lang gewartet und
> benutzt wurde?

Ich habe mich auf einfache technisch orientierte Programme bezogen,
wo max. ein paar Leute dran arbeiten, und das auch nicht 100%.
Habe ich das nicht geschrieben?

Da verschiebt sich der Schwerpunkt weg von Komplexität (die viel 
Funktionalität mit sich bringt), zu simple and stupid.
Ansonsten läuft das nach 5-20 Jahren einfach nicht mehr.

Wenn Programme keine wesentlichen neuen Features im Vergleich
zur letzten Version bieten, oder mit bunter Werbung bezahlt werden,
dann verschiebt sich der Schwerpunkt natürlich woanders hin.

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Programmierer schrieb:
> Und POSIX ist selbstverständlich auch API und ABI kompatibel.

Nein, POSIX definiert nur eine API, keine ABI.
Viele grundlegende Datenstrukturen (z.B. "struct stat") weichen auf 
unterschiedlichen Systemen voneinander ab und dürfen das auch.

Binärkompatiblität gibt es nicht, war auch nie das Ziel.

Udo K. schrieb:
> Auch wenn das Progamm dann langweilig ausschaut,
> dafür aber klar strukturiert, leicht verständlich
> und funktional daherkommt.

Eine veraltete API zu benutzen führt keineswegs automatisch zu einer 
klaren Struktur, leichter Verständlichkeit und Funktionalität. Vor allem 
dann nicht, wenn die veraltete API die benötigte Funktionalität garnicht 
bietet...

Udo K. schrieb:
> Na ja, es reicht wahrscheinlich Photoshop in einer alten Version
> neu für Linux zu übersetzen.

Eine antike Version für ein System kompilieren zu können ist etwas 
völlig anderes als ein Port des Programms auf ebendieses System.

Udo K. schrieb:
> Immerhing lief es mal auf Mac OS, und das war im wesentlichen Unix.

Nein. Mac OS ist kein Unix, nichtmal im Ansatz. Und, wie ich bereits 
anmerkte, spezifiziert POSIX keinerlei grafische Funktionen und die Mac 
OS Toolbox unterscheidet sich deutlich von sowohl Win32 als auch X11.

von Sven B. (scummos)


Bewertung
1 lesenswert
nicht lesenswert
Udo K. schrieb:
> Na ja, es reicht wahrscheinlich Photoshop in einer alten Version
> neu für Linux zu übersetzen.
> Immerhin lief es mal auf Mac OS, und das war im wesentlichen Unix.

Das ist halt einfach Quatsch :/
Ja, macOS ist so mehr oder weniger POSIX, aber wie du vorher schon 
gesagt hast hat halt POSIX mit grafischer Ausgabe nix zu tun. Es gibt 
einfach keinerlei Überschneidung zwischen POSIX und grafischer Ausgabe. 
Und das Grafik-Layer von macOS ist völlig unterschiedlich von dem was 
Linux üblicherweise so hat.
Die "alte Version von Photoshop" wird mit Sicherheit schlicht keinen 
Code haben, der irgendeine der unter Linux verfügbaren APIs zur 
grafischen Ausgabe ansteuern kann.

von ChrisMicro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Da die Arduinowelt so schön einfach ist ... man kann den Graph an 
GnuPlot "pipen":
https://github.com/ChrisMicro/ArduinoOnPc/blob/master/examples/gnuPlot/gnuPlot.ino

von Rolf M. (rmagnus)


Bewertung
1 lesenswert
nicht lesenswert
Sven B. schrieb:
> Was immer du tust nimm nicht die Xlib, da ist sich jeder seit 15 Jahren
> einig, dass das nicht der Weg ist wie man Kram zeichnet.

Ja, der designierte Nachfolger ist XCB. Das ist schlanker und 
effizienter. Allerdings wird das selten direkt, sondern meist nur 
indirekt über komfortablere GUI-Frameworks verwendet. XCB ist halt wie 
die GDI-Sachen eher umständlich zu benutzen. Ja, ein minimales 
Beispiel-Programm für einen Sinus ist damit schnell gemacht, aber mach 
damit mal was größeres.

Udo K. schrieb:
> Wäre doch was, wenn die Linux Nerds wenigstens die Basics vom Windows
> Gui Api endlich mal "native" portieren würden,
> so dass das Wine Geraffel unnötig wird.  Ich glaube, die GDI+ Bibliothek
> läuft ja schon unter Mono/Cairo?
> Dann hätte Linux endlich eine passable Gui Bibliothek :-)

Die gibts ungefähr so lange wie es Windows gibt - also nicht Win32, 
sondern Windows überhaupt. xlib und Windows 1.0 kamen beide im Jahr 1985 
raus.

Programmierer schrieb:
> Zappenduster schrieb:
>> Am liebsten hätte ich eine C Funktion, ich starte sie einmal an, sie
>> bringt den Computer in den Grafikmode, sagen wir mal Full HD mit 24 Bit
>> Farbauflösung. Rückgabewert dieser Funktion ist die Adresse des
>> Bildschirmspeichers, in den ich dann in eigener Verantwortung schreiben
>> darf.
>
> Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig
> unmöglich.

Unter Linux geht das schon. Man muss den Zugriff auf den Speicherbereich 
halt vom Betriebssystem anfordern und braucht die dafür nötigen 
Berechtigungen.

> Wie gesagt ist so etwas ähnliches über Vulkan möglich, aber der Aufwand
> ist in etwa das Hunderfache der anderen genannten Ansätze hier, also
> völlig unangemessen.

Geht auch mit OpenGL über ein PixelBuffer-Objekt. Das kann man in sein 
Programm mappen und bekommt dann einen Zeiger, über den man beliebig auf 
die Pixeldaten zugreifen kann. Das ist zwar auch etwas umständlich, aber 
deutlich kompakter als der ganze Code, den man bei Vulkan braucht, um 
überhaupt mal was angezeigt zu bekommen.

c-hater schrieb:
> Mit dem Windows-API ist es immerhin sehr einfach möglich, den
> Clientbereich eines Fensters quasi zu "Poken". OK, man benutzt eine
> Bitmap als Buffer, aber da sei drauf geschissen...

Wie kommst du auf die unsinnige Idee, das ginge nur unter Windows?

> Es scheint also deutlich näher an den praktischen Erfordernissen zu sein
> als dein hochgelobter "POSIX-Standard"...

Ich würde es heute eher als wenig praxisrelevant einstufen. Kein Mensch 
schreibt heute auf dem PC noch Programme, die jeden Pixel einzeln selber 
setzen. Das ist viel zu ineffizient.

> Und natürlich kann das Windows-API noch sehr viel mehr. Was man wohl
> daran sieht, dass alle für das Wirtschaftsleben wesentlichen
> Desktop-Anwendungen nur für genau dieses Target existieren...

Das ist mit Sicherheit nicht in der Windows-API begründet, sondern 
darin, dass damals ein PC einfach viel billiger war als eine 
Unix-Workstation. Als man dazu überging, dass jeder Mitarbeiter einen 
Computer haben sollte, wurde das relevant.

>> Genau das geht unter Linux auch, ob mit Gtk+ oder Xlib oder whatever.
>
> Genau das ist das Problem unter Linux. Man kann auf alles mögliche
> treffen. Oder eben auch nicht...
> Da muss man dann im Einzelfall mit klarkommen. Unter Windows muss man
> das nicht.

Wenn man nicht drauf trifft, macht man ein "apt install libgtk3-dev", 
und nach 30 Sekunden ist alles fertig installiert, das man braucht, um 
damit eine Anwendung zu bauen.
Und wie viele verschiedene GUI-APIs hat alleine Microsoft selber im 
Laufe der Jahre angehäuft? GDI, MFC, WPF, Windows Forms, WinUI…

> Das Win32-API ist so konstant, dass es schon länger in kaum
> veränderter (allerdings erheblich erweiterter) Form existiert, als es
> Linux als OS überhaupt gibt...

Wie oben geschrieben, gibt es die auch heute noch nutzbare xlib ziemlich 
genau so lange wie es Windows überhaupt gibt und damit deutlich länger 
als Win32.

Udo K. schrieb:
> Ja, damals vor der Open Source Bewegung,
> konnte man mit Software Anwendungen gut Geld verdienen.

Die OpenSource-Bewegung ist entstanden, weil es irgendwann auf einmal 
nicht mehr selbstverständlich war, dass man zu seiner gekauften Software 
den Sourcecode dazu bekommen hat.

> Von daher ist auch der Aufwand ein Program von "native" Win32 auf
> "native" Xlib zu portieren erstaunlich einfach.
> Auch wenn es nicht automatisch geht, so sind doch immer ähnliche
> Aufrufe vorhanden.

Für ein Programm von 30 Zeilen Länge mag das gelten. Mach das aber mal 
mit einem Programm, das eine Million Zeilen hat. Da wirst du etliche 
Mannmonate, bzw. vermutlich eher im Bereich Mannjahre versenken müssen, 
bis das sauber läuft.

> Wenn man sich auf ein komplexes Framework wie
> WPF, GTK oder QT verlässt, dann ist man verlassen, wenn
> man das portieren muss, oder wenn es aus irgendeinem
> Grund mal nicht geht, oder wenn man ein Feature braucht, dass
> es nicht unterstützt.

Ich hab schon Qt-Programme, die für Linux geschrieben waren, nur durch 
ein paar Anpassungen an den Build-System-Einstellungen nach Windows, 
Andorid und WebAssembly portiert. Natürlich ist die Voraussetzung, dass 
das Zielsystem von Qt unterstützt wird. Ein Programm von einer API auf 
eine andere zu portieren, ist aber immer viel Aufwand.

> Da verwendet das GTK Sinus Program
> (das ich weiter oben unter Windows mit Mingw compiliert hatte, und das
> nebenbei nur einen schwarzen Kreis malt)
> doch glatt die zlib1 DLL der installierten Matlab Version 2007!

Das Programm verwendet die, die du ihm gibst. Wenn du das System so 
konfiguriert hast, dass es die nimmt, dann tut es das eben.

> Die DLLs werden aus der PATH Umgebungsvariable geladen, und dynamisch
> zur Laufzeit geladen.
> Und die Matlab zlib1 DLL kommt vor der GTK eigenen zlib DLL...
> Wie schon gesagt, ein Wunder das das funktioniert, bzw. Glück das sich
> die zlib seit 20 Jahren nicht wesentlich geändert hat.

Das ist ein vor allem unter Windows verbreitetes Problem, auch als "DLL 
Hell" bekannt. Es gibt halt keinen vernünftigen Paketmanager, der die 
Abhängigkeiten automatisch auflöst.

Sven B. schrieb:
> Hast du jemals an einem größeren Softwareprojekt gearbeitet, was mehrere
> Plattformen unterstützt hat und auch ein paar Jahre lang gewartet und
> benutzt wurde?

Ich vermute nicht. Ich glaube auch nicht, dass er jemals wirklich mit 
einem Framework wie z.B. Qt gearbeitet hat (zumindest nicht über 
irgendwelche kleinen Trivialprogrämmchen hinaus). Die Ansichten passen 
einfach so überhaupt nicht zur Realität.

von Debian user (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Worggfloh schrieb:
>> Na gut, eine Möglichkeit ist da noch: du betreibst dein
>> Linux auf deiner HW in einem "uralt" Modus, wo weder X-11
>> noch ein Fenstermanager gestartet werden.
>
> Alternativ drückst du "Strg+Alt+F1" und schreibst die Datenbytes nach
> /dev/fb0. Das ist vermutlich ziemlich genau das, was der TO will.
>
> Ausprobieren:
> - Strg+Alt+F1
> - einloggen
> - dd if=/dev/urandom of=/dev/fb0
> - (den Bildschirm neu zeichnen mit Strg+L)

Also unter Debian10 geht das nicht.
liegt aber evt. auch an der Grafikkarte

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
Udo K. schrieb:
> Und wie man oben am Sinus Beispiel sieht, ist Xlib praktisch identisch
> zum Win32.

In diesem sehr primitiven Beispiel mag das so erscheinen.

Beide Bibliotheken interagieren mit Anwendungsprogrammen über Events,
die von diesem üblicherweise in einer Schleife abgefragt werden, und
beide stellen die üblichen Grafikprimitive (Zeichnen von Punkten,
Linien, Kreisen usw.) zur Verfügung. Das war's aber auch schon mit den
Gemeinsamkeiten, und viel mehr wird von unseren Sinusprogrämmchen auch
nicht genutzt.

X11 hat im Gegensatz zu Windows eine Client-Server-Architektur, wobei
Client und Server auf verschiedenen Rechnern laufen können. Damit
verbunden ist auch das Konzept des "Displays" (die Kombination aus einem
oder mehreren Bildschirmen ("Screens"), einer Tastatur und einer Maus).
Auf einem Rechner oder in einem Netzwerk können beliebig viele Displays
mit jeweils beliebig vielen Screens existieren. Von daher kommt auch der
relativ komplizierte Ablauf, um ein Fenster zu öffnen.

Überträgt man die Begriffe Display und Screen auf Windows, gibt es dort
nur ein einziges Display mit einem einzigen Screen (inzwischen
unterstützt Windows zwar auch mehrere Bildschirme, diese bilden aber
immer noch einen einzigen logischen Screen). Dass in Win32 das Öffnen
eines Fensters dennoch so kompliziert ist wie in der libX11, hat andere
Gründe.

Im Gegensatz zu Windows trennt X11 klar zwischen dem eigentlichen
Window-System und dem Window-Manager. Der Window-Manager ist genauso wie
jede andere X11-Applikation ein X11-Client und kann damit auf einem
beliebigen Rechner innerhalb eines Netzwerks laufen. Aus Sicht der
libX11 sind Fenster nichts weiter als rechteckige, ggf. überlappende
Zeichenflächen auf einem Bildschirm. Die libX11 kennt weder
Fensterrahmen noch Widgets für das Verschieben, Vergrößern und Schließen
des Fensters. Das sind alles Dinge, die vom Window-Manager hinzugefügt
werden.

Auch sonst kennt die libX11 im Gegensatz zu Win32 keine Widgets. Diese
werden von zusätzlichen Bibliotheken aus anderen Quellen bereitgestellt.

In Windows bilden das Betriebssystem, das Window-System, der
Window-Manager und noch vieles mehr einen monolithischen Block, der
nicht auf mehrere Rechner verteilt werden kann. Mit X11 hingegen ist es
möglich, eine Applikation mit grafischer Oberfläche auch auf einem
schwachbrüstigen, speicherarmen Embedded-Rechner ohne Grafikhardware,
Tastatur und Maus laufen zu lassen, solange er per Netzwerk mit einem
externen Rechner verbunden ist, der über diese Hardware verfügt.

Die libX11 bietet also viele Funktionen, die Win32 nicht hat und
umgekehrt. Deswegen ist eine Portierung von nichttrivialen Anwendungen
zwischen den beiden Systemen i.Allg. mit viel Aufwand verbunden. Wenn
Portabilität wichtig ist, verwendet man eine GUI-Bibliothek auf höherer
Abstraktionsebene, die auf allen in Frage kommenden Zielsystemen
verfügbar ist. Dafür gibt es mittlerweile genügend Lösungen, so dass es
nur noch wenige Gründe gibt, sich in die Niederungen von Win32 oder
libX11 hinab zu begeben.

von Bernd W. (berndwiebus) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zappenduster.

Zappenduster schrieb:

>> Zum Plotten würde ich die Ausgabe in eine Datei umleiten, und dann
>> für einfache Fälle mit gnuplot, für komplexere Darstellung mit Python +
>> matplotlib visualisieren. Klar muss man sich da kurz reinlesen, aber es
>> erzeugt sehr schöne, auf Wunsch auch interaktiv zoombare Graphen mit
>> wenigen (~10) Zeilen Code (inkl. Einlesen der Daten).
>>
> Wenn ich denn Workflow richtig verstehe, müsste ich da mein  C Programm
> starten, ein paar Parameter eingeben, das Programm schreibt sowas wie
> HPGL in eine Datei, die ich mit Gnuplot anzeigen lassen.

Das siehst Du zu kompliziert.

A) Du könntest die Umlenkung der Ausgabe in Gnuplot schon im C-Programm 
machen. Wahlweise CSV-Datei oder gnuplot. Dann startest Du nur Dein 
C-Programm. Die Lenkung der Ausgabe könntest Du z.B. über 
Komandozeilenparameter machen, dann brauchst Du auch kein GUI.


B) Du startes ein Python Skript, welches dir Dein C-Programm startet, 
die Ausgabe übernimmt und entweder in eine Datei oder Gnuplot 
weiterschiebt. Wie bei dem C-Programm kämst Du ohne GUI aus, wenn Du das 
Python-Skript per kommandozeilenparameter lenkst.

C) Du hast ja ein C-Programm geschrieben, und weisst daher was Du machen 
must. Dann kannst Du das ganze auch in Python einfach neu schreiben. 
Mathplotlib als Bibliothek wurde ja oben schon erwähnt, ich füge noch 
tkinter als Bibliotheksempfehlung hinzu, wenn Du ein GUI dazu machst.

Diese reine Python Lösung hätte den Charm, auf jedem OS lauffähig zu 
sein, das Python unterstützt.


> Hübsch, aber ich wollte wirklich wie bei einem ZX81 Grafik in Echtzeit.

Aktuelle Hardware ist so flott, dass "Echtzeit" nicht mehr soooo wichtig 
ist. ;O)
Und schon gar nicht, wenn du einen menschlichen Betrachter hast

Nachtrag: Wenn Du was mit Python machst, mache es in Python 3. Zwei ist 
wirklich veraltet (Seit über 10 Jahren schon), und zwei und drei sind 
"leider" inkompatibel. Leider in Anführungszeichen, weil ich 
mittlerweile auch zu dem Kreis von Leuten gehöre, die meinen, der harte 
Schnitt sei besser als Kompatibilität um jeden Preis und dafür Unmengen 
von Inkonsistenzen in der Sprache in kauf zu nehmen. Im April dieses 
Jahres wurde die Entwicklung bzw. der support von Python 2 definitiv 
beendet. Siehe 
https://de.wikipedia.org/wiki/Python_(Programmiersprache)#Ende_von_Python_2

Python (3) ist ansonsten übrigens das "neue Basic" . Einfacher in der 
Handhabung, wesentlich mächtiger und zusätzlich sehr portabel über einen 
ganzen bunten Strauß verschiedener OS.


Mit freundlichem Gruß: Bernd Wiebus alias dl1eic
http://www.l02.de

: Bearbeitet durch User
von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Debian user schrieb:
> Also unter Debian10 geht das nicht.
> liegt aber evt. auch an der Grafikkarte

Ich hab das auf meinem System unter Debian10 getestet.
Funktioniert natürlich nur, wenn du auch einen Framebuffer-Treiber hast 
(KMS bringt einen mit), also effektiv "alles außer nvidia".

von Zappenduster (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi Folks, hier ist mal wieder der TO.
Hatte noch nicht wirklich Zeit, die ganzen Antworten zu lesen. Leider 
enthalten viele der Antworten so viele Begriffe, die ich nicht kenne, da 
habe ich Angst, da würde in meinem Fall wohl nicht mal ein 
Informatikstudium helfen. Ich habe wohl die letzten 30 Jahre verpennt 
und bin in den frühen 80gern hängengeblieben ;-)


Hier im Anhang ein Beispiel, was ich schon vor einiger Zeit hinbekommen 
habe. Dieses System Display meine_Datei.bmp ist nicht wirklich 
geschmeidig. Ich muss dieses Display mit einem Tastendruck beenden. In 
den 80ern hätte ich diesen Farbkreis zum rotieren gebracht...

von ChrisMicor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Farbkreis1.c

Also ... wenn du eine Datei schreiben willst, ist es besser, eine 
HTML-Datei mit SVG-Graphik zu schreiben und diese dann mit dem Browser 
zu öffnen.

Wenn du das ganze dynamisch willst, kannst du Java-Script einbinden, da 
ist im Browser sogar ein Debugger eingebaut:
https://www.w3schools.com/graphics/tryit.asp?filename=trysvg_polyline

SVG:
https://de.wikipedia.org/wiki/Scalable_Vector_Graphics

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Dafür gibt es mittlerweile genügend Lösungen, so dass es
> nur noch wenige Gründe gibt, sich in die Niederungen von Win32 oder
> libX11 hinab zu begeben.

Das ist natuerlich richtig. Allerdings ist es vermutlich eher schwierig 
wenn man das in C machen will wie es der TO eigentlich vorhat!

Wenn man es aber in C machen will und C++ Kenntnisse hat dann gibt es 
einen Trick. Ich hab vor kurzem sowas in Qt gemacht. Da habe ich ein 
Buffer in C++ erzeugt der von C beliebig beschrieben werden kann. Das 
nutze ich um eine Testumgebung fuer Mikrocontrollersoftware zu haben. 
Das koennte ich problemlos auf Linux oder Windows laufen lassen. So kann 
ich ein Program problemlos auf dem Mikrocontroller laufen lassen und 
durch einfach neu compilieren laeuft es auf dem PC.

Olaf

von ChrisMicro (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Wenn man es aber in C machen will und C++ Kenntnisse hat dann gibt es
>einen Trick. Ich hab vor kurzem sowas in Qt gemacht. Da habe ich ein
>Buffer in C++ erzeugt der von C beliebig beschrieben werden kann. Das
>nutze ich um eine Testumgebung fuer Mikrocontrollersoftware zu haben.
>Das koennte ich problemlos auf Linux oder Windows laufen lassen. So kann
>ich ein Program problemlos auf dem Mikrocontroller laufen lassen und
>durch einfach neu compilieren laeuft es auf dem PC.

Das gleiche Prinzip habe ich für die ArduinoOnPc Simulation gemacht. Der 
Bildschirm und die Maus ersetzen das TFT, das an einen Arduino 
angeschlossen wird. Der Vorteil: Man kann die Arduino-Tutorials nutzen.

https://github.com/ChrisMicro/ArduinoOnPc/blob/master/examples/Adafruit_touchpaint/Adafruit_touchpaint.ino

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Wie könnte ich Grafik... darstellen?

Hier ist mein Tutorial dazu: http://stefanfrings.de/qt_lernen/index.html

von Yalu X. (yalu) (Moderator)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Hier im Anhang ein Beispiel, was ich schon vor einiger Zeit hinbekommen
> habe. Dieses System Display meine_Datei.bmp ist nicht wirklich
> geschmeidig. Ich muss dieses Display mit einem Tastendruck beenden.

Das angehängte farbkreis-gfx.c benutzt die oben verlinkte gfx-Bibliothek
und zeigt den Farbkreis direkt in einem Fenster an. Das ist allerdings
ziemlich langsam, da X11 nicht darauf optimiert ist, ein Fenster
pixelweise mit Inhalt zu füllen.

> In den 80ern hätte ich diesen Farbkreis zum rotieren gebracht...

Siehe farbkreis-cv.cpp im Anhang. Das Programm benutzt die OpenCV, was
zwar ein wenig mit Kanonen auf Spatzen geschossen ist, dafür reduziert
sich das Fenstergedöns auf gerade mal eine Codezeile (imshow(...)). Da
die Pixeldaten des gesamten Bildes in einem Rutsch ausgegeben werden,
läuft die Sache auch wesentlich schneller als mit der gfx-Bibliothek und
ohne Anpassung auf Linux, Mac OS, Android und Windows.

Allerdings ist das Programm in C++ geschrieben, da die OpenCV in der
aktuellen Version C nicht mehr so richtig zu unterstützen scheint.

: Bearbeitet durch Moderator
von ChrisMicro (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Josef G. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich häng mich mal hier mit einer Frage dran,
vielleicht ist sie auch für den TO interessant.

Ich habe ein C-Programm, welches aus einem Konsolenfenster
gestartet wird mit ./name . Das Programm macht irgendwelche
Berechnungen und verwendet die Xlib um das Ergebnis anzuzeigen.
Dazu öffnet es ein Grafikfenster mit XCreateSimpleWindow und
wartet auf Eingaben von der Konsole, welche die Grafik steuern
und beenden mit XCloseWindow. Funktioniert auch alles.

Das Problem ist, dass das Grafikfenster in der Kopfleiste einen
Schließen-Knopf hat. Das Klicken auf diesen Schließen-Knopf ist
nicht vorgesehen. Wenn man es dennoch tut, schließt der Window-
Manager das Fenster. Es kommt eine Fehlermeldung "Fatal error",
vermutlich wenn das in der Konsole laufende Programm versucht,
Daten ins nicht mehr existierende Grafikfenster zu schreiben,
und das Programm wird beendet. Es ist auch nicht möglich, das
zu vermeiden, indem das Programm vor jeder Ausgabe abfragt ob
das Grafikfenster noch geöffnet ist, weil das Schließen durch
den Window-Manager asynchron erfolgt.

Weiss jemand eine Lösung für das Problem?

PS: Es geht um das Emulationsprogramm für mein bo8h-Projekt.

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
Wenn man ein Fenster öffnet, kann man normalerweise optionale Parameter 
angeben, die nicht nur die Größe sondern auch die verfügbaren Buttons 
vorgeben. Und an jeden Button kann man eventhandler hängen. Ich habe auf 
die Schneller aber nicht gefunden, wie man das bei xlib macht.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
Josef G. schrieb:
> Weiss jemand eine Lösung für das Problem?

Wie ich schon oben schrieb, weiß die libX11 von Hause aus wenig bis gar
nichts von Close-Buttons u.ä., weil diese zunächst einmal Sache des
Window-Managers sind. Dieser sendet beim Schließen aber ein Event, das
mit libX11-Funktionen verarbeitet werden kann. Hier steht wie (erste
Antwort):

  https://stackoverflow.com/questions/1157364/intercept-wm-delete-window-on-x11

von Markus K. (markus-)


Bewertung
0 lesenswert
nicht lesenswert
Ich möchte hier auch nochmal Javascript vorschlagen. Was mich dabei 
überzeugt hat, ist dieses Video:
Youtube-Video "Coding "Snake" in 4 min 30 sec (plain browser JavaScript)"

Da schreibt einer ein Snake-Spiel in unter 5 Minuten. Wenn man schon 
programmieren kann, dann lernt man halt die wichtigsten Basics für so 
etwas in wenigen Minuten.

von leo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Markus K. schrieb:
> Ich möchte hier auch nochmal Javascript vorschlagen.

JS / canvas im Browser wurde schon vorgeschlagen, ja. Kann ich nur 
zustimmen.

leo

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
leo schrieb:

> JS / canvas im Browser wurde schon vorgeschlagen, ja. Kann ich nur
> zustimmen.

Sog. "Web-Technologien" zu verwenden, ist der sicherste Weg, um 
Programme zu schreiben, die u.U. schon in wenigen Monaten nicht mehr 
funktionieren...

Man braucht sich doch bloß die Geschichte eben diese Technologien und 
der Browser, die sie umsetzen, anzuschauen...

Da wird heute die eine Kuh durch's Dorf getrieben und schon morgen ist 
sie obsolete...

Nur Leute mit einem verdammt kleinen zeitlichen Erfahrungshorizont 
können sowas ernsthaft empfehlen...

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Da wird heute die eine Kuh durch's Dorf getrieben und schon morgen ist
> sie obsolete...

Canvas ist jedoch so generisch, dass ich mir nicht vorstellen kann, dass 
es wieder abgeschafft wird. Es werden wohl eher neue Funktionen 
hinzugefügt.

von leo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Nur Leute mit einem verdammt kleinen zeitlichen Erfahrungshorizont
> können sowas ernsthaft empfehlen...

Der TO schrieb:

> Ich programmiere kleine Progrämmchen in C, die
> irgendwas ausrechnen und das mit printf() anzeigen.
> Wie könnte ich Grafik, z.B. eine Sinusfunktion

Ich empfehle das nicht allgemein, sondern wegen diesen Anforderungen.

Und so kurzfristig ("Monate") sind Webstandards dann doch wohl auch 
nicht. Aber du kannst sicher eine nachhaltige Assembler-Alternative 
einwerfen ;-)

leo

von maxiMite (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Zappenduster schrieb:
> Ich habe wohl die letzten 30 Jahre verpennt
> und bin in den frühen 80gern hängengeblieben ;-)

Deshalb brauchst du auch kein Linux sondern einen Colour Maximite 2 
kostet keine 100€
https://geoffg.net/maximite.html
Youtube-Video "Colour Maximite 2: Mandelbrot using an embedded C routine - blink and you will miss it"

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Programmierer schrieb:
> Das ist unter aktuellen Betriebssystemen wie Windows und Linux völlig
> unmöglich.

Endlich mal einer mit Ahnung von der Materie. ;-)

von Brühpolnische (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Zappenduster schrieb:
> ch, da ist mir noch eingefallen, in den 90gern hatte ich QBasic, damit
> habe ich viel gemacht. Unter SCREEN 12 ging 640x480 in 16 Farben.
> Seufz...
Wenn C:
Nimm SDL2, das abstrahiert den ganzen X-Schrott weg und man hat ein paar 
generische Grafikfunktionen, wenn man was grundlegendes ohne viel 
Ballast haben will.

Ansonsten nimmt man heute gleich was mit einem Canvas, jedes GUI-Toolkit 
bietet sowas an und bekommt auch gleich ne GUI dazu, will man in der 
Regel sowieso haben.

Speziell um mit nur mit Grafik rumzuschmieren ist auch processing ganz 
nett, das gibts für Java und für den Browser (als JS-Variante) und musst 
dich nicht mit den Eigenheiten einer Sprache, den Libs und anderem 
lästigen Schrott rumplagen. Um schnell mal was auszuprobieren ideal. Der 
Arduino-Entwicklungsstyle ist von Processing inspiriert worden.

Und gewöhn dir mal langsam ab direkt auf der Hardware in Speicher 
rumzufuchteln, die Zeiten sind lange vorbei.

Ansonsten nimm:
qb64.net
freebasic.net
Das tut dann so als wärs ne VGA-Karte, nutzt aber (wahlweise) OpenGL,
fühlt sich aber immer noch wie das Original an, bietet aber auch 
moderenere Arten mit Grafik herumzuhantieren wie OpenGL-bindings,...

Oder fummel in der dosbox mit den Originalen rum, da kannst du dann 
weiterhin mit VGA-Paletten, Registergefrickel, Timming und so nem Mist 
deine Zeit verplempern.

von Mike (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>Ansonsten nimm:
>qb64.net
>freebasic.net

Wenn schon: Besser PureBasic https://www.purebasic.com/german/

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.

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