Archiv verlassen und diese Seite im Standarddesign anzeigen : Grafikprogrammierung ohne API
RattuS
2008-04-04, 18:27:55
Seid gegrüßt,
mein Chef ist heute auf die verrückte Idee gekommen, jegliche externe APIs der grafischen Oberfläche von Win32 zu boykottieren. Demnach soll ich jetzt zusehen, wie ich ein primitives Fenster mit Assembler (386) ohne APIs darstelle (also auch ohne OpenGL). Im Netz konnte ich bisher keine entsprechende Dokumentation finden. Die einzigste Möglichkeit, die ich bisher in Erfahrung bringen konnte, funktioniert nur mit Interrupts im DOS (direkte Adressierung über BIOS). Allerdings konnte ich selbst das bisher nicht zum laufen bringen, da mir die int 10h Privilegien fehlen (auch 368P schmeißt mir Zugriffsverletzung) und ich teilweise Differenzen zwischen 16 und 32 Bit hatte.
Welche Möglichkeiten bleiben? Man muss doch irgendwie den Grafikkartentreiber direkt ansprechen können oder?
Mit freundlichen Grüßen
Alex
Unter aktuellen Windows-Versionen kann man ohne API-Aufrufe zu verwenden keinerlei Eingaben oder Ausgaben machen.
Man kann die API-Aufrufe beliebig umständlich kapseln (z.B. Virtualisierung oder PC-Emulation), aber wenn irgendwas passieren soll geht es nicht daran vorbei.
Demirug
2008-04-04, 18:58:17
Die besagten Interrupts sind das API des BIOS und funktionieren natürlich nicht in einer 32/64 Bit Umgebung.
Ansonsten ist die Idee deines Chefs nicht nur einfach verrückt. Sie zeigt schlicht und ergreifend dass er 0,0 Ahnungen von der Materie hat.
Natürlich kannst du den Grafiktreiber auch direkt ansprechen (Habe ich auch schon mal gemacht). Allerdings musst du dafür auch eine API benutzten. Was die Sache nun noch schlimmer macht ist die eigentlich nicht vorhanden Dokumentation dieser sowie die Tatsache dass diese API sich von Windows Version zu Windows Version verändern kann. Im Gegensatz zu den üblichen APIs wird hier keine Kompatibilität geboten.
Demnach soll ich jetzt zusehen, wie ich ein primitives Fenster mit Assembler (386) ohne APIs darstelle (also auch ohne OpenGL).
LOL
Troll?
RattuS
2008-04-04, 19:20:59
LOL
Troll?
Was zum Teufel? Ein Gast unterstellt mir ein Troll zu sein? Wo liegt dein Problem? Wenn du nicht mitreden kannst, antworte erst gar nicht.
OnTopic:
Ich dachte mir schon, dass das nicht umsetzbar ist. Mein Chef hat tatsächlich nicht sehr viel technische Erfahrung in diesem Bereich, aber im Zuge unseres Projektes war es eine Überlegung wert.
Demirug
2008-04-04, 19:50:55
Ich dachte mir schon, dass das nicht umsetzbar ist. Mein Chef hat tatsächlich nicht sehr viel technische Erfahrung in diesem Bereich, aber im Zuge unseres Projektes war es eine Überlegung wert.
Was wollt ihr den machen? Vielleicht findet sich ja eine andere Lösung die nicht so weltfremd ist.
Man könnte auch einen Treiber schreiben und dann auf IRQL Dispatch gehen und den ganzen scheduler kram ignorieren und einfach mit VGA rummalen!
Mit EXE-Codes geht es!!!
http://www.c-plusplus.de/forum/viewtopic-var-t-is-41456.html
Grestorn
2008-04-04, 21:10:38
Darf ich fragen welchen Grund Dein Chef hat, so etwas anzustreben?
Unabhängigkeit vom OS und jeglichem Hersteller?
Grestorn
2008-04-04, 21:12:01
Mit EXE-Codes geht es!!!
http://www.c-plusplus.de/forum/viewtopic-var-t-is-41456.html
Das ist ja nur die ASCII Darstellung von Binären Dateien, die - wenn sie ausführbar sind - selbstverständlich auch APIs nutzen.
Die einzige Möglichkeit wäre wirklich einen Device-Treiber zu installieren und dann direkt in den VRAM zu schreiben. Die Sache ist nur, dass man dazu entweder für jede GPU die Register kennt oder doch wieder den Treiber nach dem Framebuffer fragt (Offset, Pitch, Farbtiefe, usw.) und dann sich noch mit zig anderen Sachen rumschlagen muss.
Kurz: Die Idee ist völliger Scheißdreck, vor allem weil es einem keinerlei Performancevorteil bringen wird ggü. DirectDraw z.B. und man die Platformunabhängigkeit auch mittels SDL machen kann z.B. Ich stimme Demirug zu mit der 0,0 Ahnung.
Nicht das es nicht gehen würde: http://rr0d.droids-corp.org/ http://rr0d.droids-corp.org/screenshots/rr0d_win.PNG
RattuS
2008-04-04, 21:41:42
Es klingt... nein es ist auch bescheuert, aber mein Chef verlangt absolute Plättbarkeit und Reflexivität der von unserem System verwendeten Prozesse. Da APIs in den seltensten Fällen offen sind bzw. das Disassembly zu viel Zeit beanspruchen würde, verlangt mein Chef tatsächlich, dass wir Grundfunktionen, wie in diesem Falle z.B. Fenster und deren Handling, Stück für Stück gemäß unserer Ontologie "nachbauen"/optimieren. Das IST bescheuert, aber eben mein Job. ^^
del_4901
2008-04-04, 21:48:07
Ich hoffe ihr habt einen guten SW-Architekten, oder sind die alle schon geflüchtet? ;D
Dann schreibt besser gleich euer eigenes OS, sonst ist das sowieso Blödsinn.
Der Typ hat schwer ein Rad ab. Allein der Begriff des "Fensters" ohne OS-API ergibt schon keinen Sinn. Ist der schon senil oder was?
Demirug
2008-04-04, 22:19:19
Meine Güte so einen BS habe schon lange nicht mehr gehört.
Bei dieser Forderung könnt ihr erst mal damit anfangen ein neues BIOS zu schreiben. Ich weiß ja nicht wer der Kunde für das ganze am Ende sein wird. Aber bezahlen kann das keiner mehr.
Wenn es über deinem Chef noch jemanden gibt würde ich mir mal dringend einen Termin dort geben lassen. Falls nicht tue dir selbst einen Gefallen und sagt deinem Chef was für einen Blödsinn er da gerade „plant“. Das Leben ist zu kurz um sich sowas anzutun.
del_4901
2008-04-04, 22:19:36
Dann schreibt besser gleich euer eigenes OS, sonst ist das sowieso Blödsinn.
Der Typ hat schwer ein Rad ab.
Sowas macht man nur bei besonders Zeitkritischen Sachen. (Raketensteuerung, Flugzeuge etc.) Aber selbst für solche Sachen gibs derweil speziell angepasste Betriebssysteme.
Ectoplasma
2008-04-05, 08:56:44
Seid gegrüßt,
mein Chef ist heute auf die verrückte Idee gekommen,
...
Alex
Wenn das kein verspäteter Aprilscherz sein soll, dann kann ich dir zwei Dinge raten. Entweder du kündigst bei der Firma oder euer Chef begibt sich einmal in ärztliche Behandlung ...
Die Aufgabe ist viel zu groß, fehleranfällig, nicht wartbar und viel zu teuer.
"Mein Chef hat tatsächlich nicht sehr viel technische Erfahrung in diesem Bereich". Der hat noch weniger als technische Erfahrung. Der hat mächtig ein an der Bimmel und scheint sich lieber auf Sternkonstelationen zu verlassen.
The_Invisible
2008-04-05, 09:10:59
ich würde lieber nachforschen wer an diesem tag dem chef was ins essen/trinken gekippt hat :D
mfg
jtkirk67
2008-04-05, 09:33:06
Arbeitest Du eventuell bei der Firma, die auch den Duke entwickelt? Dann verstehe ich langsam, warum das ewig dauert...
SGT.Hawk
2008-04-06, 03:28:31
Die Frage, so blödsinnig auch der Chef sein mag, ist, ob das überhaupt möglich ist. Wo würde man ansetzen und welche Sprache mit welcher IDE würde zum Einsatz kommen?
PS: Ich verstehe was von programmieren, aber solche eine Frage hat ich mir nie selbst gestellt.
Die Frage, so blödsinnig auch der Chef sein mag, ist, ob das überhaupt möglich ist. Wo würde man ansetzen und welche Sprache mit welcher IDE würde zum Einsatz kommen?
Das wurde hier doch schon hinlänglich erklärt. Mit Sprache hat das erst mal nichts zu tun. Bei einem heutigen 32Bit System kannst du nicht mehr direkt auf die HW zugreifen. Selbst wenn du einen eigenen Grafikkartentreiber schreibst, greifst du auf ein abstraktes Treiberinterface vom OS zu, um mit der HW zu kommunizieren. Auf irgend eine API musst du letztendlich zugreifen.
Wenn du einen Treiber schreibst kannst du auch direkt auf die Hardware zugreifen. Im Ring 0 kann das OS nichts dagegen unternehmen.
Wenn du einen Treiber schreibst kannst du auch direkt auf die Hardware zugreifen. Im Ring 0 kann das OS nichts dagegen unternehmen.
Das stellst du dir IMO zu leicht vor. Es ist ja nicht so, dass Software im Kernelmode einfach so läuft und sich dann nicht mal gegenseitig beeinflusst.
Damit der Treiber überhaupt funktioniert und mit dem OS zusammenarbeitet, musst du ein spezifisches Treiberframework vom OS implementieren und da hast du nur über APIs Zugriff. Bei Windows ist doch alles von unten bis oben abstrahiert. Selbst der Kernel greift ja nicht mal direkt auf die CPU zu.
ScottManDeath
2008-04-06, 23:09:02
http://www.internals.com/
Ich hab mal mit WinIO den Parallelport direkt programmiert über x86 IO Befehle, da die WindowsAPI für Parallelports mein eigenes Protokoll zur Ansteuerung von Custom Hardware nicht unterstützt hat.
Zum Spass hab ich mal Speicher ab 0x000a000 physikalischer Addresse in den virtuellen Addressraum meines Prozesses gemappt und dann fleissig mit Grütze vollgeschrieben. Ergebniss waren überschriebene Pixel am oberen Bildschirmrand.
Ectoplasma
2008-04-07, 02:10:40
Selbst der Kernel greift ja nicht mal direkt auf die CPU zu.
Der Satz ist jetzt doch ein wenig seltsam. Jedes User-Mode Programm greift schon dadurch auf die CPU zu, dass es Code ausführt und das sehr direkt. Es dürfen nur einige Befehle, die für die Integrität des Systems zuständig sind, nicht ausgeführt werden. Im Kernel-Mode darf ich so ziemlich alles mit der CPU machen. Also erkläre mal deinen Satz da oben.
Das stellst du dir IMO zu leicht vor.
Nö tu ich nich. Du darfst im Ring 0 alles. Ob's dann auch funktioniert ist was anderes.
Also erkläre mal deinen Satz da oben.
Der Windows Kernel greift nicht direkt auf die CPU zu, sondern auf den HAL.
Und wenn du Code schreibst, wird dieser ja nicht von Zauberhand alleine auf der HW ausgeführt, sondern der Kernel schaufelt die Daten in die CPU Register. Und das macht er auch über den HAL. Gut, im Kernelmode kann man direkt auf die CPU Register zugreifen und könnte das umgehen, aber ob das mit dem OS so ohne Probleme funktioniert, wage ich zu bezweifeln. Und wenn, dann sicher nur in Kombination mit OS APIs, um synchron zu bleiben.
robobimbo
2008-04-07, 14:07:50
sondern der Kernel schaufelt die Daten in die CPU Register. Und das macht er auch über den HAL.
öhm, ich glaub da solltest Du nochmal ganz scharf darüber nachdenken...
jeder aktuelle prozess, egal ob er nun im userspace oder im kernel läuft hat die cpu zu 100% und lädt sich selbst die register voll wie er will.
Ectoplasma
2008-04-07, 14:11:49
Der Windows Kernel greift nicht direkt auf die CPU zu, sondern auf den HAL.
Und wenn du Code schreibst, wird dieser ja nicht von Zauberhand alleine auf der HW ausgeführt, sondern der Kernel schaufelt die Daten in die CPU Register. Und das macht er auch über den HAL. Gut, im Kernelmode kann man direkt auf die CPU Register zugreifen und könnte das umgehen, aber ob das mit dem OS so ohne Probleme funktioniert, wage ich zu bezweifeln. Und wenn, dann sicher nur in Kombination mit OS APIs, um synchron zu bleiben.
Ich glaube das wird jetzt eine ziemlich spezielle Diskussion. Du hast nicht beantwortet, welche CPU Register du meinst. Der HAL gehört zum Kernel, nur mal so nebenbei. Die allgemeinen Register wie EAX, EBX, etc. kannst du nicht meinen, diese werden immer direkt angesprochen. Da gibt es keine Abstraktion. Stell dir mal vor wie lahm ein System wäre, wenn der Zugriff auf die CPU über einen Abstraktions-Layer laufen würde. Es gibt IMO nur previlegierte Befehle, die nur im Kernel-Mode ausgeführt werden dürfen. Ansonstern sorgt der Scheduler dafür, welche Anwendung die CPU erhält. Die Register eines Prozesses werden vor jedem Context-Switch (Umschalten des Schedulers auf einen anderen Prozess) gesichert.
Du meinst vielleicht eine Virtualisierung ala VMVare, aber auch dort greift eine Anwendung direkt auf die CPU zu, bzw. wird der Code direkt darauf ausgeführt. Aber vielleicht reden wir wirklich nur aneinander vorbei. Vielleicht können die anderen Member auch eine Meinung dazu abgeben.
Edit: Ah robobimbo hat schon etwas geschrieben.
Der Windows Kernel greift nicht direkt auf die CPU zu, sondern auf den HAL.
Und wenn du Code schreibst, wird dieser ja nicht von Zauberhand alleine auf der HW ausgeführt, sondern der Kernel schaufelt die Daten in die CPU Register. Und das macht er auch über den HAL. Gut, im Kernelmode kann man direkt auf die CPU Register zugreifen und könnte das umgehen, aber ob das mit dem OS so ohne Probleme funktioniert, wage ich zu bezweifeln. Und wenn, dann sicher nur in Kombination mit OS APIs, um synchron zu bleiben.
Bei der CPU gibt es keine HAL. Nicht mal für Userprogramme. Code wird immer direkt auf der CPU ausgeführt.
Das einzige was passiert ist, dass der Speicher virtualisiert wird und im Userspace bestimmte Instructions nicht ausgeführt werden können. Das war's.
[ ] Autocogito
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=207674
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.