Thema: eigene api erstellen

[jeb]

Wie kann ich eigentlich eine API für Betriebssysteme erstellen, die bereits existieren (denke da vorläufig an Win). SDL, Allegro und weitere API machen das ja auch. Ist das schwer?

mfg, jeb

[joachim_neu]

Eine Lib halt. Mach ne ASM-File mit den Funktionsnamen, kompilier sie als Lib (geht auch mit C) und mach Headers, die darauf verweisen, fertig.

[jeb]

Und wie mach ich, das ich auch Fenster und so öffnen kann? Muss ich da auf die WinAPI zurückgreifen? Wie macht man eine Lib?

[Svenska]

Du musst deine Lib (Win: DLL) mit Funktionen ausstatten, was die tun, ist deine Sache. Jedoch wirst du - bei Closed-Source-Systemen - nicht um die schon vorhandene Api herumkommen.
Ein Fenster öffnen ist z.B. eine Sache der MFC bzw. WinApi (die MFC greift auf diese zurueck).

Wenn du fuer ein eigenes OS die grundlegende Api codest, kannst bzw. musst du die Kernelfunktionen und die Treiber (bzw. die API's von Kernel und Treiber) direkt ansprechen.

Svenska

[jeb]

und wie greife ich auf diese funktionen zu bzw. kennst du ein gutes tut dazu?

[Svenska]

An die WinAPI kommst du mit C-Funktionen ran, da kann dir wer mit C-Kenntnissen helfen. Ich selbst hab davon keine Ahnung, da ich mich damit nicht wirklich beschäftigt habe.
Ich denke, dass jemand anders hier mehr Ahnung davon haben muesste bzw. Google duerfte auch das eine oder andere anbieten.

Soweit ich weiss, benötigt eine DLL mindestens DLLMain(), um von Windows benutzt werden zu können. Weiter weiss ich aber nichts, tut mir Leid.

Svenska

[jeb]

hab ein tut gefnunden: http://mitglied.lycos.de/b534463/kap19.htm.

Also kann ich bei Windows davon ausgehen das die eigene API zwangsweise langsamer ist als die WinAPI?

[DDR-RAM]

Also kann ich bei Windows davon ausgehen das die eigene API zwangsweise langsamer ist als die WinAPI?

Nicht zwingend.
Die WinAPI selber besteht auch nur aus einigen *.dll's, diese verwenden dann interrupts bzw. sysenter usw., um mit dem Kern zu kommunizieren, bzw. um diesem Befehle zu geben. Das könntest du also auch selber machen, wenn du die WinAPI umgehen willst.
Außerdem könntest du mit einer eigenen Lib auch ein schöneres Framework zu verfügung stellen, das schon mehr Aufgaben erledigt, als die WinAPI.
Als sinnvoll erachte ich es allerdings nicht, es gibt die WinAPI, nen Aufsatz dafür, die MFC's wenn man sowas macht, dann wahrscheinlich zu Lernzwecken. Außerdem wird .NET von Microsoft gepushed, WinAPI wird vielleicht schon in Longhorn nur noch emuliert (mit drunterliegendem dot net)

MfG
DDR-RAM

[Another Stupid Coder]

Nope, soweit ich informiert bin, hat Microsoft auch den Plan aufgegeben, Longhorn komplett auf .NET aufzubauen.

[Roshl]

Die haben doch nicht etwa eingesehn, dass das zu langsam wäre und dass nicht jeder einen 17GHZ Prozessor hat?    

[Another Stupid Coder]

Ach, wer weiß, wie das bis zum Release-Datum gewesen wäre? Nya, was mich wundert...was genau kommt jetzt neues? WinFS und so ist ja auch schon draußen. Außer der neuen GUI?

[Roshl]

Gibbet WinFS auch für XP?

[DDR-RAM]

Gibbet WinFS auch für XP?

Noch gibt es kein WinFS,
aber soweit ich weiß, wollen se des so machen, das man das für win xp nachrüsten kann.

[joachim_neu]

Wozu denken die sich eigendlich immer neue FSs aus? NTFS geht für Dateien bis zu 16 Exabyte, soweit ich weiß, warum halten die dann nicht daran fest? Machen die's absichtlich inkompatibel? Sollten sich lieber mal um ein gutes System kümmern.

[jeb]

Ich glaub die neue API heisst WinFX.
@.NET: Kann ich mit MSVC++ 6 für .NET verwenden?
@WinAPI: Mein Programm greift auf meine LibDLL zu, welche wiederum auf die WinAPIDLL zugreift. Das ist also ein Umweg.

[jeb]

.NET verwendet ja eine VM! Dann ist die Lib ja noch lahmer! Oder täusch ich mich da irgendwie?
@DDR-RAM: Wie kann ich denn die WinAPI umgehen? Soll ich die DLL decompilieren und mir den Code anschauen?

[Jidder]

@jeb: ich glaub du vermischt jetzt WinFX und WinFS. WinFX ist wie du gesagt hast eine API und WinFS ist ein Dateisystem, das auf NTFS und SQL aufbaut. Die haben eigentlich nicht besonders viel miteinander zu tun.

Die Geschwindigkeit von .NET ist vergleichbar von der mit Java unter einer Sun-VM und ich empfinde die beiden jetzt nicht als soooo lahm. Durch optimierte JIT-Compiler haben beide genug Geschwindigkeit für umfangreiche Anwendungen. Eher würde ich mir um den Speicherverbrauch sorgen machen. So ein etwas umfangreicheres Programm beansprucht schon mal

.NET-Compiler gibt es erst ab Visual Studio .NET. Also geht MSVC++ 6 nicht.

Die WinAPI kannst du nur umgehen indem du eigene Treiber schreibst. Oder dich an die NT Native API wendest. Die ist eine Ebene Tiefer als die WinAPI, es gibt es wie der Name es andeutet nur unter NT und Nachfolgern, ist nicht öffentlich dokumentiert und nur unmerklich näher an der Hardware dran als die WinAPI. Also wahrscheinlich nicht das, was du willst ...

[joachim_neu]

About WinFS: Heißt, die machen jetzt ein FS basierend auf einer SQL-Tabelle, die als Datei in NTFS gespeichert ist? Die haben sie doch nimmer alle! Da können sie auch das alte lassen.

[Jidder]

nein die nutzen sicherlich die zugriffrechte von NTFS aus und tun das nicht in eine einzige datei. das wäre sonst äußerst dämlich und außerdem nicht an NTFS gebunden.

schau dir einfach mal ein paar berichte über WinFS an. -> google hat ein paar interessante zu bieten.

[Legend]

NTFS kann ja zu einer Datei beliebiege Attribute speichern, das macht sowas gleich einfacher ...