Warum sind keine Windows-Konstanten in .net enthalten?

Question

Warum sind keine Windows-Konstanten in .net enthalten?

8

Jedesmal wenn ich Code sehe, der in kernel32.dll oder User32.dll aufruft, benötigt das Snippet immer, selbst auf MSDN, den Entwickler, um alle erforderlichen Konstanten (WM_SETREDRAW = 11 zum Beispiel) in die Routine zu schreiben. Da sich diese Konstanten niemals per Definition ändern und immer eine Standarddefinition haben, warum stellt .net sie nicht irgendwo zur Verfügung? Ich habe das Gefühl, dass wir alle unsere eigenen Bibliotheken von Konstanten und Standard-Windows-DLL-Aufrufe erstellen, so wie wir sie brauchen. Es scheint, dass diese Doppelarbeit verschwenderisch und fehleranfällig ist.

Vielleicht habe ich nicht hart genug gesucht und sie sind alle irgendwo da, wenn ja könnte jemand bitte ihren Standort angeben?

.net windows constants

J Collins 31.07.2012, 15:53

quelle

3 Antworten

Tags und Links .net windows constants

Django: Verwenden von Annotate, Count und Distinct in einem Queryset C ++ to Java: effizientes Durchsuchen einer Sammlung

score 2 · Answer 1

Nur das .NET-Team kann die tatsächliche Antwort liefern, denke ich, wir können nur Vermutungen anstellen.

Es gibt wahrscheinlich viele Gründe. Hier sind einige Vermutungen:

Die Win32-API ist zu fehleranfällig. Bei vielen Win32-Methoden muss der Entwickler unsichere Handles manipulieren (oft als IntPtr -Objekte dargestellt), was nicht die .Net-Methode ist (z. B. sollten Sie FileStream anstelle von CreateFile / ReadFile /% verwenden). co_de% / WriteFile )
Es hat keinen Sinn, die gesamte Win32-API in mscorlib hinzuzufügen, da nur 0,1% der Entwickler sie tatsächlich verwenden
Microsoft bevorzugen Entwickler schreiben verwalteten Code
Das .Net-Framework ist so konzipiert, dass es plattformunabhängig ist. Deshalb finden Sie zum Beispiel CloseHandle ( Environment.NewLine ) . Daher macht das Hinzufügen der gesamten Win32-API keinen Sinn.

Microsoft hat einige Windows-spezifische Klassen im A string containing "\r\n" for non-Unix platforms, or a string containing "\n" for Unix platforms. -Namespace hinzugefügt, aber es ist sehr begrenzt und diese Funktionen sind wichtig (Registrierung Operationen, filedialogs ...).

Bei pinvoke.net würde ich mich nicht zu sehr darauf verlassen. Ich sehe oft schlecht geschriebene Methodendeklarationen, die auf x64-Systemen abstürzen würden ( Microsoft.Win32 anstelle von int , struct layout issues ...). Ein anderes Beispiel: Die IntPtr Methodendeklarationen sind inkonsistent. WriteFile vs SafeHandle ... usw.

score 2 · Answer 2

Es gibt nicht nur einen einzigen Grund, es gibt viele. Ich kann mir vorstellen, dass einer der folgenden Faktoren eine Rolle bei der Entscheidung spielt, sie nicht einzubeziehen:

nicht einmal die Teams, die an den Framework-Assemblys arbeiteten, teilten eine gemeinsame Reihe von Pin-Voke-Deklarationen, jedes Team schrieb sein eigenes
Microsoft verwaltet nur eine einzige Quelle für das winapi, das Windows SDK
Die Betreuer des SDK sind eine andere Gruppe, die nicht eng mit einer der Gruppen verwandt ist, die an .NET
Es gibt nicht nur einen winapi, es hängt stark von der Windows-Zielversion ab, die Sie beim Erstellen eines C / C ++ - Programms angeben. Dies geht stark gegen .NET, es ist version agnostic
Der winapi ist enorm, niemand wird sich nur mit einer partiellen Version freuen
Die pinvoke-Deklaration für eine winapi-Funktion wird oft aus ihrer ursprünglichen Form umgeschrieben, um die Verwendung zu vereinfachen. Insbesondere bei der Art von Funktionen, die undurchsichtige Pointer verwenden, ist SendMessage () das klassische Beispiel
.NET wurde entwickelt, um sicherzustellen, dass Sie keine Abhängigkeit vom winapi benötigen. Sie können trotzdem mit eigenen Pinvoke-Deklarationen fehlende Teile nachfüllen, aber die Garantie, dass dies mit jeder Windows-Version funktioniert, die ein .NET-Programm ausführen kann, ist verloren. Windows 98 und 2000 werden weiterhin offiziell für 2.0 unterstützt

Sie können das Pinvoke Interop-Assistent verwenden. Die bereitgestellten Deklarationen werden automatisch aus den Windows SDK-Headern generiert.

score 0 · Answer 3

0

.NET wurde entwickelt, um ein komplettes Ökosystem zu sein. Das Einwerfen in die Windows-API ist ein Hack, und das Nichteinbeziehen der Konstanten ist Microsofts Weg, es zu entmutigen.

Mark Ransom 31.07.2012 16:30

quelle