Vollständigste Api-Referenz gesucht

[GuybrushThreepwood]

Liebe DPLer,

ich bin es nun mal wieder und ich wollte euch mal fragen, ob eine vollständige Api-Referenz auf Erden existiert, wenn nein, welche ist die vollständigste ?

Danke im voraus.
GuybrushThreepwood

[Chewie]

Die absolut vollständige existiert wohl nur im Hause Microsoft, aber die gaballte Ladung als PSDK (da ist das meiste drin), DDK und IFK sollte so ziemlich alles umfassen.

[GuybrushThreepwood]

Also, das Platform SDK lade ich gerade von MS runter, aber ich habe keinen Link zum IFK, kannst du eventuell einen Link zum Download posten ?

Danke für die Antwort
Guybrush Threepwood

[Chewie]

Zitat von GuybrushThreepwood:

aber ich habe keinen Link zum IFK, kannst du eventuell einen Link zum Download posten ?

Da gibts leider keinen
Das DDK zum Entwickeln von Treibern gibt es leider auch nicht mehr zum Download. Dieses und das Installable Fileystems Development Kit (sorry, IFS, nicht IFK) dokumentieren noch einige Funktionen der NT Native API, die auf NT-basierten Systemen die Grundlage der "normalen" WinAPI bilden. Die NativeAPI kann auch direkt benutzt werden, allerdings ist dies bis auf wenige Ausnahmefälle nicht nötig.
Mit dem PSDK hast du eine Referenz aller offiziell dokumentierten Funktionen.

Aber falls du die NativeAPI wirklich brauchst: Es gibt auch Bücher darüber. Kuck einfach mal bei Amazon nach Native API oder sowas.

[GuybrushThreepwood]

Ok, danke schön.

Ich blätter mal ein bisschen durch das PSDK, und hoffe, dass die Verwendung einfach gehalten ist, denn ich bin mir sicher, dass die API ein sehr wichtiger bestandteil der Programmierung ist und man ohne sie, nicht wirklich auskommt. Da gibt es ja eigentlich noch Jedi, worauf ich aber verzichten will, weil sie eigentlich, denke ich, falls man die Api versteht, total unnötig sind.

Danke für die Hilfe

Auf bald
GuybrushThreepwood

[Bernhard Geyer]

Zitat von GuybrushThreepwood:

Da gibt es ja eigentlich noch Jedi, worauf ich aber verzichten will, weil sie eigentlich, denke ich, falls man die Api versteht, total unnötig sind.

Denke ich nicht (und ich glaube Du meinst primär den Win32-API-Teil der Jedi). Folgende Vorteile bietet dir die Jedi:

- Delphi-Frendly Syntax (WideString/String-Parameter statt umständliches Handling mit PWide-/PChar)
- Vorbereitung von Dynamic Linking (Anwendung läuft auch unter alten Win32-Versionen, auch wenn Funktionen von neuen BS-Versionen verwendet werden
- Objekt-Orientierterer Ansatz in Teilbereichen
- Ausgleich von Win32-API-Unterschieden zwischen diversen Betriebssystem-Versionen

[GuybrushThreepwood]

Naja, man hat mir mal erzählt, dass die Datei durch nutzung der Jedi's größer wird.
Da in Delphi entwickelte Programme ohne UPX oder sonstiges zirka 450kb(Korregiert mich, wenn ich falsch liege) groß sind, wäre es ziemlich extrem, wenn sie noch größer werden würde.
Ich lege viel Wert auf darauf, dass mein Programm schnell und klein ist, naja sicher solte es auch sein.

Von daher bin ich der Meinung, dass es sich, für Entwickler, die erst noch kleinere Sachen entwickeln wollen einfach nicht lohnt, aber ich bin überzeugt von der Meinung, dass es sich für größere Projekte lohnen könnte.

Cya
GuybrushThreepwood

[Bernhard Geyer]

Zitat von GuybrushThreepwood:

Naja, man hat mir mal erzählt, dass die Datei durch nutzung der Jedi's größer wird.
Da in Delphi entwickelte Programme ohne UPX oder sonstiges zirka 450kb(Korregiert mich, wenn ich falsch liege) groß sind, wäre es ziemlich extrem, wenn sie noch größer werden würde.

Alleine das hinzufügen einer Unit zu deinem Programm vergrößert dies nicht unbedingt. Vom Delphi-Compiler werden nur die Teile der Unit in die Exe mit aufgenommen, die auch wirklich benötigt werden. Den Overhead von ca. 1/2 MB für die VCL nimm ich gerne in kauf.

Zitat von GuybrushThreepwood:

Ich lege viel Wert auf darauf, dass mein Programm schnell und klein ist, naja sicher solte es auch sein.

Ich auch. Aber die Kosten<->Nutzen-Analyse spricht meißt für den VCL/objektorientierter Ansatz.

[MathiasSimmack]

Ich glaube, wer beruflich mit Delphi entwickelt und an Zeitpläne gebunden ist, der kann es sich gar nicht erlauben, API-Spielchen zu machen. So gesehen würde ich Bernhard zustimmen wollen. Das wäre unrentabel und würde die Firma schnell in den Ruin treiben.

Aber wenn du, @Guybrush, ein Hobby-Entwickler hat, der es nicht so eilig hat, und der auch nicht von Termindruck geplagt wird, dann ist gegen ein kleines API-Programm auch nichts einzuwenden.