Zitat von
mael:
Es gibt dafür BartPE.
Was BartPE damit zu tun hat, weiß ich nun zwar nicht, da IMO ein Defragmentierung- ebenso wie ein Datenrettungstool auch in einem laufenden System einiges können sollte. Aber ist schon okay. Unter BartPE (oder WinPE allgemein) hat man es natürlich leicht, weil man mit SYSTEM-Rechten läuft.
Zitat von
mael:
Ein Gast hat nicht zu defragmentieren und auch nicht Daten wiederherzustellen. Das ist Adminarbeit, deswegen ist direkter Festplattenzugriff Admins vorbehalten.
Wir reden hier nicht von Gast, sondern davon, daß du als Nichtadmin eingeloggt bist (z.B. Hauptbenutzergruppe) und defragmentieren willst ohne jedesmal mit RunAs zu hantieren.
Es ist auch nicht die Aufgabe von Gast die MMC aufzurufen, warum gibt es dann überhaupt RunAs?
Zitat von
mael:
Du brauchst keinen Service und unter Windows NT keinen Treiber.
Zum Defragmentieren nicht. Ich weiß auch nicht warum du das immer wieder aufwirfst, denn ich habe es nie behauptet.
Zitat von
mael:
NativeAPI sind genauso wenig nötig! Ab Windows 2000 gibt es ziemlich bequeme Funktionen um zu Defragmentieren
File Defragmentation Ähem
... hast du da auch selber mal reingeguckt? Ob ich einen *CTL nun mit der einen oder der anderen Funktion schicke ist oft egal. Die *CTLs sind aber die gleichen wie oben im Artikel von Sysinternals beschrieben. Das ganze läuft wieder durch eine einzige Funktion. So wie man eben nunmal mit Treibern kommuniziert, über IOCTLs, FSCTLs und wie sie alle heißen. Und wenn du genau aufgepaßt hättest, wüßtest du, daß diese Funktionen zwar erst jetzt richtig dokumentiert sind, daß sie aber seit Windows NT 4.0 existieren (siehe Artikel von Sysinternals).
Zitat von
mael:
"Low-Level <> Delphi" zeugt von Unwissenheit.
Schau dir nochmal meinen Wortlaut an. Und wenn du behauptest, daß "Low Level" mit Delphi
empfehlenswert sei, dann frage ich mich umgekehrt was ...
Zitat von
mael:
Zitat von
Olli:
Zweitens: schreib doch was du willst in Delphi.
Es ist und bleibt meine Ansicht. Schließlich ist hier nicht die
GUI das Problem sondern der Unterbau.
Delphi hat andere Vorzüge als die
GUI-Programmierung,
Nur leider ging es hier eben nicht um die
GUI und auch nicht um Lesbarkeit und Wartbarkeit (welche
sehr subjektiv sind
).
Zitat von
mael:
einer der Hauptvorteile von Pascal ist die bessere Lesbarkeit und Wartbarkeit.
Hängt vom Programmierer und seinem Stil ab. Gleiches gilt für jede andere Sprache. Ich erinnere nur an die Obfuscated [C/C++/Perl/...]-Wettbewerbe.
Zitat von
mael:
Früher haben viele Demo-Groups in Pascal programmiert, gerade wo es um low-level Hardware-Zugriffe wegen der Geschwindigkeit ging.
Äpfel und Birnen? Hatten wir nicht eben noch von Delphi und 32bit-Betriebssystemen gesprochen? Früher ... jetzt haben wir aber Sommer.
Zitat von
mael:
Wenn Meinungen gegen eine Sprache, dann präzise Gründe und nicht diese pauschalen Aussagen!
Wenn ich sage, daß Native
API besser nicht mit Delphi und daß es eben nicht um die
GUI geht, wo Delphi besser wäre, dann ist das pauschal? Na gut
... konkrete Fallbeispiele sind pauschal
Zitat von
mael:
Zitat von
Olli:
Einige Sachen, besonders bei Nutzung der Native
API, sind in Delphi zwischen unmöglich und "unangenehm" zu realisieren.
Abgesehen davon, daß ich keinen Vorteil darin sehe jede Windows Haupt-, Unter- und Nebenversion extra unterstützen zu müssen, wüßte ich jetzt nicht was mir eine andere Sprache dabei erleichtert. Header alleine bringen einem herzlich wenig.
Schon was von Präprozessormakros gehört? Einige sog. Native APIs existieren eigentlich garnicht, sondern sind als Makros deklariert. Da kommt man dann mit Delphi ziemlich ins Schwitzen. Zumal die Implementierung dann teilweise uneffektiver wird. Aber ich bin ja unwissend, von daher ...
Zitat von
Luckie:
Guck dir das
DDK an. Was hatte Nico da noch mal zu geschrieben? Moment:
Zitat:
...selbst wenn sich jemand die Arbeit macht das Device Driver Kit (
DDK) in Delphi Language zu 'übersetzen', wird er feststellen, das selbige Sprache einige Features nicht hat, die dort ausgiebig benutzt werden ( z.B. Makros, 'fastcall' (Microsoft-spezifische Aufrufkonvention, vergleichbar mit 'register' in Pascal) und Unions (bedingt übersetzbar) ... )
Nach zu lesen hier:
Wo hat Delphi seine Grenzen Du machst Delphi damit schlecht, Luckie!
Zitat von
Luckie:
Ich kenn niemanden im der deutschsprachigen Delphi Community mit so viel Ahnung was die Interna von Windows angeht.
Ich sage nur w3seek. Thomas ist Mitglied im ReactOS-Projekt, als solches kennt er sich natürlicherweise damit aus
Zitat von
mael:
ich finde man sollte nicht in einem Delphi Forum permanent (richtet sich ja nicht nur an Olli) andere Sprachen als besser bezeichnen.
In meinem Duden von 1967 steht:
permanent (dauernd, anhaltend, ununterbrochen, ständig) <lat>
... hat sich die Bedeutung geändert? Wenn ich mal wenigstens etwas als besser bezeichnet hätte! Ich sehe zwar z.B., um bei einer prominenten Sprache zu bleiben, einige Buchstaben "C" oben im Text, aber vor Luckie hat niemand C++ oder C angesprochen. Es war eine (berechtigte) Kritik an Delphi! (Warum berechtigt? Weil die Erfahrung damit durchaus zu einer solchen Aussage berechtigt. Wir hatten mit Marcel van Brakel auch darüber diskutiert, ob die
DDK Header noch übersetzt werden sollten, uns aber dagegen entschieden. Aus naheliegenden Gründen. Machen wir damit Delphi schlecht? Macht man Delphi schlecht, wenn man feststellt, daß man printf() nicht sinnvoll in Delphi nutzen kann? Nein - wir stoßen nur an die Grenzen und zeigen sie auf.)
Warum arbeitet der Uhrmacher nicht mit einer Axt, der Bauer nicht mit einem Schraubenzieher und der Raumfahrer nicht mit einem Taucheranzug? Eben, weil es für jedes Ding das richtige Werkzeug gibt. In manchen Fällen sind es auch mehrere Werkzeuge die zur Verfügung stehen, oder Werkzeuge verschiedener Firmen mit ähnlicher Funktion. Wo ist dein Problem? Wer nicht in der Lage ist das korrekte Werkzeug auszuwählen sollte es sein lassen.
Zitat von
mael:
Ich habe nicht von Treiberentwicklung geschrieben, ich habe auf funktionierenden Delphi-Quellcode verwiesen, man kann ohne Treiber auskommen (siehe RawWrite) oder mit (ist in Assembler geschrieben).
Das heißt direkter Festplattenzugriff braucht keinen Treiber (wenn man unbedingt einen braucht gibt es wie gesagt einen im Code von Alexander Grau) und daher ist Delphi perfekt dazu geeignet.
Das ist korrekt. Direkt würde ich das zwar nicht nennen, aber man kann zumindest sektorenweise schreiben und lesen. Das ist wiederum aber nur mit bestimmten Privilegien möglich. Um das zu umgehen, muß man den Job an einen Service delegieren. Dazu kann ich dir nur das entsprechende Wiki-Buch (oder das Vorgängerbuch) von Keith Brown empfehlen.
Zitat von
mael:
Darum ging es nicht, sondern man braucht keinen Treiber.
Hier ging es auch um die verwendeten Funktionen. All diese Funktionen bezeichnet man als
Native API. Schau einfach mal in die JwaNative.pas - dort sind sogar die Präfices erklärt.
Zitat von
mael:
Dieses "es geht nicht und Punkt so ist es" ist einfach nicht zutreffend.
Für die Datenwiederherstellung (und es ging hier eben
nicht nur um Defragmentierung) würde ich dann gern Beweise in Form von Code von dir sehen. Danke im Voraus.
Zitat von
mael:
Jedenfalls denke ich sind wir uns einig, daß für die im Thread gefragte Aufgabenstellung sehrwohl Delphi geeignet ist.
Nein!