Lowlevel
OffZone => Offtopic => Thema gestartet von: jeb am 30. May 2005, 22:06
-
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
-
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.
-
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?
-
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
-
und wie greife ich auf diese funktionen zu bzw. kennst du ein gutes tut dazu?
-
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
-
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?
-
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
-
Nope, soweit ich informiert bin, hat Microsoft auch den Plan aufgegeben, Longhorn komplett auf .NET aufzubauen.
-
Die haben doch nicht etwa eingesehn, dass das zu langsam wäre und dass nicht jeder einen 17GHZ Prozessor hat? :lol: :lol: :lol:
-
Ach, wer weiß, wie das bis zum Release-Datum gewesen wäre? :D Nya, was mich wundert...was genau kommt jetzt neues? WinFS und so ist ja auch schon draußen. Außer der neuen GUI?
-
Gibbet WinFS auch für XP?
-
Gibbet WinFS auch für XP?
Noch gibt es kein WinFS, :D
aber soweit ich weiß, wollen se des so machen, das man das für win xp nachrüsten kann.
-
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. ;)
-
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.
-
.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?
-
@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 ...
-
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.
-
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.
-
NTFS kann ja zu einer Datei beliebiege Attribute speichern, das macht sowas gleich einfacher ...
-
Also ich hab mir das mal in Wikipedia angeguckt. Bin dabei zu dem Entschluss gekommen, sowas nie zu benutzen. Ich mag es nicht, wenn jemand meine Daten indiziert, nur um "schneller suchen zu können". Ich habe meine Struktur und suche nicht. ;) Auch einer der Gründe, warum ich GoogleToolBar und GoogleDesktopSearch ablehne. Und das irgendwer irgendwo unkontrolliert irgendwelche Informationen sammelt gefällt mir nicht. ;)
-
Tja, zudem kann ich unter meinem Debian Dateien schon seit Jahren so schnell suchen ;D locate ^_^ Und Beagle ist ja auch grade in Entwicklung.
-
@PorkChicken: Ist mir schon klar das WinFX und WinFS nicht das selbe ist.
Funktioniert den .NET auch auf LINUX/BSD? Ist der Compiler (ohne IDE) gratis?
-
Für Unix-Systeme gibt's Mono...ist grad in entwicklung.
Ansonsten sind mit dem "Plattformübergreifend" eher die verschiedenen Windows-Versionen (Windows CE z.B.) gemeint, denke ich mal.
-
Jo, wird wohl so sein, jetzt wirds aber OT ;)
-
Schlussfolgerung: Ihr empfehlt mir, .NET zu verwenden anstelle der WinAPI (für andere Plattformen schau ich dann in Version 1.0). Der .NET Compiler wird nicht gratis sein. Sonst verwende ich WinAPI.
Hab ich das richtig verstanden?
-
Der .Net Compiler ist afaik sogar gratis. Ich glaube der ist im .Net Framework enthalten. Nur die Entwicklungsumgebung kostet Geld. Du musst den Compiler dann halt per Command Line bedienen, aber es gibt auch eine kostenlose Entwicklungsumgebung (deren Name ich gerade vergessen hab) die das macht.
-
hi,
ich glaube SharpDevelop gibts kostenlos.
im Microsoft .NET SDK gibts einen C#, VB und java-ähnlichen Compiler mitgeliefert, außerdem noch ein IL-Assembler (sowas wie Assembler bloß für .NET) und ein Disassemblierungstool, und und und ...
cu,
stefan2005
-
nix für C++?
-
hi,
nein,
es soll zwar sowas wie Managed C++ für .NET geben aber ich find in meinem .NET SDK Ordner nix ... nur C#, J# (Java), JScript.NET, VB.NET.
C# find ich aber auch nicht schlecht, vor allem, da die Dateigrößen klein sind :D , ist halt ne Mischung aus C/C++ (vor allem die Syntax), Java und Delphi Language.
cu,
stefan2005
-
:(
Dann werd ich wohl WinAPI verwenden müssen und dann alles auf WinFX umschreiben :( .
Ist C# empfehlenswert zum lernen? Die meisten libs sind ja für C++.
mfg, jeb
-
:(
Dann werd ich wohl WinAPI verwenden müssen und dann alles auf WinFX umschreiben :( .
Die WinAPI wird weiterhin unterstützt werden müssen, um abwärtskompatibel zu bleiben, ein _muss_ existiert also nicht ;-)
Ist C# empfehlenswert zum lernen? Die meisten libs sind ja für C++.
Ich mag C# nicht und kenn mich da auch nicht so aus.
Wer mehr kann, ist immer besser gestellt.
Und ms, wird .NET nicht übern Haufen werfen, es hat also Zukunft.
Und, was für Libs brauchsten du?
Also um standard windows appz zu basteln reicht es voll und ganz aus.
MfG
DDR-RAM
-
Eigentlich gibts auch einen C++ Compiler. Aber in aktuellen Versionen ist das Verwenden von .Net in C++ noch nicht wirklich optimal. Das soll in der Version 2005 besser werden (die ist afaik im Beta-Stadium).
-
Also ich kann C# nur empfehlen gegenüber C++ wegen a) Garbage Collection b) Aufgeräumtere Objektorientierung c) Keine Probleme wegen Compiler ABI oder ähnlichem (Name Mangling usw.).
-
Was für mich am wichtigsten ist sind Grafiklibs. Also 3D und 2D. Mag einfache libs (z.b. http://irrlicht.sourceforge.net).
Wie stehts mit OpenGL support für C#?
-
hi,
OpenGL für .NET, hmm.. ehrlich gesagt noch nie was davon gehört !
man könnte natürlich die ganz normalen DLL dateien einbinden wie in C++ aber dann würde es das ganze .NET nicht bringen und es ist wieder mit WinAPI in Verbindung.
Es gibt Managed DirectX9, das auch im Microsoft DirectX9 SDK enthalten ist, aber die Demos von Microsoft für C# waren allesamt um einiges langsamer (von den FPS her) als normale C++ Anwendungen.
cu,
stefan2005
-
WAS WILL DENN MICROSCHROTT (sry, nervt mich langsam).
WinAPI geht verloren, C++ ebenfalls, OpenGL wird nicht mehr Supportet, .NET ist langsam und man kann nur DirectX (MS Exclusive) verwenden!!!!
Was konkret soll ich jetzt machen? Ich glaub ich bleib bei WinAPI
-
OpenGL gibts für CSharp (weiss nicht mehr wo)
Sonst schreibst du dir die Funktionen selbst. C# kann Funktionen aus koventionellen DLLs aufrufen.
-
CSharp?
Ich will eine Lib für Windows (und ev. ab V1.0 für Linux) schreiben. Ich suche die beste möglichkeit, eine Lib für Win umzusetzten.
-
OpenGL gibts für CSharp (weiss nicht mehr wo)
Sonst schreibst du dir die Funktionen selbst. C# kann Funktionen aus koventionellen DLLs aufrufen.
Bei Mono, Seite an Seite mit dem bekannterem Gtk#.
Aber C# erledigt sich eigentlich selber für diese Aufgabe - da gibt es eigentlich nicht mehr viel (nichts?) umzusetzen.
Deswegen wäre eher die Frage: "Welche Programmiersprache willst du denn nun benutzen?"
-
C++
-
Von M$ gibts ein Visual C++ 2005 Toolkit für .NET is allerdings quatsch das erzeugt weder .NET IL noch gibts bis jetz im Rahmen von Mono oda so was für Linux...
-
naja, ich hab jetzt ein anderes Problem:
Wenn ich meine eigene Lib schreib, dann nehm ich ja standardmässig "main()". Doch WinAPI will "WinMain(..)". Wie kann ich nun ein Fenster erstllen, wenn ich gar kein "WinMain(..)" verwende?
-
In einer DLL nimmst du glaubich DLLMain() oder so, diese Funktion wird dann aufgerufen, wenn die DLL an einen Process angehängt wird. In deinen DLL Funktionen solltest du ganz normal winapi funktionen aufrufen können, man kann ja auch von Konsolenprogrammen aus Winapi Funktionen aufrufen.
-
GetModuleHandle (NULL); hilft dir in diesem Fall, ich glaub so hiess die Funktion.