WinAPI und C: Zukunftschancen und mehr
-
Mein Ziel ist einfach Spaß an der Sache zu haben. Der IT-Branche habe ich schon vor Jahren den Rücken gekehrt. aber privat mag ich mal wieder ein wenig C zu programmieren. Weg von OOP und den ganzen Generalisierungs Unsinn, ohne C++(allein deswegen https://youtu.be/rX0ItVEVjHc), weg von anderen Libs. Einfach so plain wie es halt unter Windows geht. Da es hier sicherlich einige Windows Experten gibt, frage ich halt interessenhalber nach der Einschätzung wie lange Visual Studio noch C und die WinAPI unterstützen wird und wie lange die Programme wohl noch laufen werden. Mit ist schon klar, dass es hier keine genauen Antwort geben kann. Kann ja sein, dass der eine mehr weiß aus erster oder zweiter Quelle oder sonst wo her.
Nicht ernst gemeinte Antworten überlese ich einfach, für so einen Quark bin ich zu alt.
-
Ja, es wird definitiv "immer" unterstützt werden. Du kannst alles auf eine C Api runterbrechen, mit was anderem wirds schwierig. Und außerdem gibts schon wahnsinnig viel Code, der darauf aufbaut. Da brauchst dir überhaupt keine Sorgen machen.
Aber wenn du "was programmieren" willst, was hat das mit der WinApi zu tun? Es ist doch unglaublich langweilig, GUIs zu programmieren. Mach doch eine Server Anwendung, oder einen Interpreter oder eine Datenbank, oder was weiß ich was... Gibt sehr viele interessante Projekte, die man machen könnte, die nichts mit GUI oder WinApi zu tun haben.
-
Ich will als erstes so Richtung Spieleentwicklung 2D wie 3D gehen, viel WinAPI wird das wahrscheinlich gar nicht sein. Da ich auch eine GUI oder 3D vom Scratch machen will, also ohne OpenGL oder DirectX. Wichtig soll ist mir vor allem die Optimierung sein, so dass wenig Cachemisses etc enthalten sind. Bei dem allem ist der Weg das Ziel und nicht so einfach oder so schnell wie möglich ein Ergebnis zu bekommen. Es ist die Freude die Dinge wirklich selbst zu machen und nicht nur Libs zusammen zu klatschen.
-
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
3D vom Scratch machen will, also ohne OpenGL oder DirectX.
Aha. Und womit bekommst Du Dein Zeugs auf den Bildschirm? Mit
SetPixel()?BitBlt()?
-
Alles wird in ein Stück Speicher geschrieben(Framebuffer) und ganz zum Schluss mit BitBlt auf den Bildschirm gebracht. Is ja keine Hexerei und auch nicht schwer. Viele Funktionen habe ich noch von früher fertig. Für Audio brauch ich auch nur ein Buffer füllen von z.B. WASAPI, die Softwaresynth Sachen dafür sind halbfertig. War auch nicht sonderlich aufwendig.
Daten nehmen, transformieren, Daten schreiben und das mit so wenig Generalisierung wie möglich. So wie ich das früher mal in Assembler gemacht habe. Nicht auf Erweiterbarkeit achten oder gar irgendwelche Objekte nach der wahren Welt modellieren, einfach strait forward. Ich habe Daten, will die verändern und neu schreiben, was ist die einfachste und cache freundlichste Art dies in purem C zu tun. Das YouTube Video von oben hat mir die Augen geöffnet, eben nicht die Arbeit dem Compiler machen zu lassen, denn der ist wohl recht dumm. 90% der Optimierung muss per Hand geschehen. Schaut euch das Video von Mike Acton mal an.
-
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
zum Schluss mit BitBlt auf den Bildschirm gebracht. Is ja keine Hexerei und auch nicht schwer.
Ja, so habe ich mir das vorgestellt. Mit Hardwarebeschleunigung ist da halt Essig.
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
Für Audio brauch ich auch nur ein Buffer füllen von z.B. WASAPI
Das ist doch wieder so grausig umständliches COM-Zeugs, oder? Einfach und unkompliziert geht da anders: PlaySound function. KISS!
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
Ich habe Daten, will die verändern und neu schreiben, was ist die einfachste und cache freundlichste Art dies in purem C zu tun.
Habe ich auch schon gehört, daß dieser ganze Objektmodellierquatsch mit Klassen großteils vermeidbarer Verwaltungsoverhead ist, der alles unnötig langsam macht. Von Templates will ich hinsichtlich Code-Bloat garnicht erst anfangen. Dazu kommt noch, daß OOP-Zeugs es dem Compiler noch schwieriger macht, wenigstens einigermaßen optimierten Code zu erzeugen - und genau wie Du sagst:
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
90% der Optimierung muss per Hand geschehen.
weil es Compiler einfach nichtmal ansatzweise vernünftig hinbekommen.
-
Ja, ist dann alles ohne Hardwarebeschleunigung, mit OpenGL bzw Vulkan will ich später mal anfangen. Beim Sound geht es mir nicht darum Wav Files abzuspielen, ich generiere die Samples in Echtzeit selbst mit meinem Software Synth. Das hatte ich noch in C++ vor einiger Zeit gemacht und werde das nach C portieren ohne die ganze OOP Sache. Ob ich Header Source Trennung mache muss ich mir noch überlegen, vielleicht werde ich auch alles gleich in Header lassen und mir das Doppeln vom Prototyp und Implementierung sparen. Bei meiner Projektgröße kann das ruhig immer alles auf einmal kompilieren.
-
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
werde das nach C portieren ohne die ganze OOP Sache.
@3xotherm sagte in WinAPI und C: Zukunftschancen und mehr:
ich generiere die Samples in Echtzeit selbst mit meinem Software Synth.
Und was ist das für ein Format, das dabei rauskommt?
-
Solange es Windows gibt , wird die kernel32.dll dafür sorgen das alle Funktionen erhalten bleiben.
MFC verkapselt diese nur. Andere frameworks nutzen am Ende des Tages die API funktionen- Oder Frameworks über OpenGL , ich persönlich bin sehr geneigt , das Programme aus Interface-Funktionen bestehen die über HTML oder sonst woher aufgerufen werden können, um sich modern zu geben.Siehe dazu : https://www.c-plusplus.net/forum/topic/348180/die-zukunft-der-entwicklung
Grüße
Karsten
-
@swordfish sagte in WinAPI und C: Zukunftschancen und mehr:
Und was ist das für ein Format, das dabei rauskommt?
Naja, Du erzeugst halt die 16 Bit samples und schiebst sie abwechselnd für den linken und rechten Kanal in die Soundkarte.
Gibt es Windows API Funktionen dafür:
#include <Audioclient.h>
#include <Mmdeviceapi.h>VG Martin
