Grafik unter Linux

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...

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.

Beitrag "QT oder WxWidgets für Anfänger"

Schau mal unter Linux nach der Xlib.

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

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

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

X: sdl_gfx in C oder FreeBASIC
Framebuffer: laserboy

> 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

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.

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.

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.

1

 for (i = 0 ; i < NUM ; i++)

2

 {

3

     apt[i].x = i * cxClient / NUM ;

4

     apt[i].y = (int) (cyClient / 2 * (1 - sin(TWOPI * i / NUM))) ;

5

 }

6

7

 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.

Udo K. schrieb:


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

Buuh,Buuuuuh!!!!  :-)

1

2

3

#!/bin/bash

4

# plotsine.sh

5

# A DEMO to display a sinewave inside a standard bash terminal.

6

# Issued as Public Domain, 2014, B.Walker, G0LCU.

7

# Device: Macbook Pro 13", OSX 10.7.5, default bash terminal.

8

# Use variables so that you can see how it works.

9

angle=0

10

step_angle=5

11

vert_plot=0

12

horiz_plot=5

13

centreline=12

14

amplitude=11

15

PI=3.14159

16

clear

17

# Do a single cycle, quantised graph.

18

while [ $angle -le 359 ]

19

do

20

  # Create each floating point value...

21

  # CygWin now catered for... ;o)

22

  vert_plot=$(awk "BEGIN{ printf \"%.12f\", ((sin($angle*($PI/180))*$amplitude)+$centreline)}")

23

  #vert_plot=$(bc -l <<< "{print ((s($angle*($PI/180))*$amplitude)+$centreline)}")

24

  # Truncate the floating point value to an integer then invert the plot to suit the x y co-ordinates inside a terminal...

25

  vert_plot=$((24-${vert_plot/.*}))

26

  # Plot the point(s) and print the angle at that point...

27

  printf "\x1B["$vert_plot";"$horiz_plot"f*"

28

  printf "\x1B[22;1fAngle is $angle degrees..."

29

  sleep 0.1

30

  # Increment values...

31

  angle=$((angle+step_angle))

32

  horiz_plot=$((horiz_plot+1))

33

done

34

printf "\x1B[23;1fSinewave plotted as a quantised text mode graph.\n"

35

exit 0

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

Seit HTML5 und Canvas mach ich solche kleinen Programmchen immer in 
JavaScript.

SVGAlib

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

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

back from the future schrieb:

Just kidding aber forumsfreundlich ist das schon  :)
> ...

1

p450:$ ./sine.sh

2

3

4

5

6

                  *********

7

               ***         ***

8

              *               *

9

            **                 **

10

           *                     *

11

          *                       *

12

         *                         *

13

        *                           *

14

       *                             *

15

      *                               *

16

    **                                 **

17

                                         *                                 *

18

                                          *                               *

19

                                           *                             *

20

                                            *                           *

21

                                             *                         *

22

                                              *                       *

23

                                               *                     *

24

                                                **                 **

25

                                                  *               *

26

Angle is 355 degrees...                            ***         ***

27

Sinewave plotted as a quantised text mode graph.      *********

28

box://mnt/disk2/vid-tmp

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

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.

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.

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!!!

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.

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

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.

@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.

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

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.

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!

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.

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...

> 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...

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...

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

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

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

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!

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.

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.

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.

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

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

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...

>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

> 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

>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

Zappenduster schrieb:
> Wie könnte ich Grafik... darstellen?

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

Das hier sieht einfach aus:
https://www.youtube.com/watch?v=3cmd6k3VGZQ

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.

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.

Markus K. schrieb:
> Ich möchte hier auch nochmal Javascript vorschlagen.

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

leo

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...

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.

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

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
https://www.youtube.com/watch?v=G3wzseh3Wh0

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.

>Ansonsten nimm:
>qb64.net
>freebasic.net

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