Defragmentier- oder datenrecovery programm realisieren?

[mael]

Zitat von Luckie:

Früher gab es auch noch kein Windows NT, wo Windows NT selber keine direkten Hardwarezugriffe erlaubt und APIs bereitstellt, führt kein Weg an einem Treiber vorbei, denn nur der darf direkt auf die Hardware zugreifen. Was die Lesbarkeit und Wartbarkeit angeht ist Geschmackssache. Frag mal einen C++ Programmierer der noch nie mit Delphi gearbeitet hat, der wird dir deine begins und ends um die Ohren hauen.

Mit den verschiedenen Vorlieben habe ich keine Probleme, es gibt sicherlich C++ features die ich gerne in Delphi sehen würde. Allerdings sind diese High-Level und helfen hier nicht und ich finde man sollte nicht in einem Delphi Forum permanent (richtet sich ja nicht nur an Olli) andere Sprachen als besser bezeichnen.

Zitat von Luckie:

Guck dir das DDK an. Was hatte Nico da noch mal zu geschrieben? Moment:

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.

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) ... )

Darum ging es nicht, sondern man braucht keinen Treiber.

Zitat:

Und zum Schluss: Olli und NicoDE wissen wo von sie sprechen.

Mag sein, aber man braucht keine native API, siehe einfach die in Delphi geschriebene Software an(RawWrite und Software bei Torry). Ich habe es auch schon gemacht und weder C++ noch Assembler gebraucht und mich auch nicht verkünsteln müssen. Also kann ich so eine Behauptung nicht stehen lassen, dazu habe ich auch Links in meinen vorigen Beiträgen geliefert.
Dieses "es geht nicht und Punkt so ist es" ist einfach nicht zutreffend.

[Luckie]

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 habe ich in diesem Fall auch nicht bestritten, weil nämlich Window sin diesem fall eine API zur verfügung stellt, die dies erlaubt.

[mael]

Zitat von Luckie:

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 habe ich in diesem Fall auch nicht bestritten, weil nämlich Window sin diesem fall eine API zur verfügung stellt, die dies erlaubt.

Unter 9x keine API aber durch 16 bit DLL per BIOS und DPMI erreichbar. Naja, egal. Sicherlich gibt es Fälle wo man Treiber braucht, aber die sind doch eher selten (Parallelport vielleicht). Jedenfalls denke ich sind wir uns einig, daß für die im Thread gefragte Aufgabenstellung sehrwohl Delphi geeignet ist.

[Olli]

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!

[mael]

Zitat von Olli:

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?

Ob ich jetzt als Admin eingeloggt bin oder RunAS verwende ist hier ja wohl egal. Es ändert nichts daran, das man Adminrechte braucht, also was soll das hier?

Zitat von Olli:

Ähem ... hast du da auch selber mal reingeguckt?

aber du verstehst anscheinend immer noch nicht, daß ich hier bestehende Treiber verwende und keine schreiben muß.

Zitat:

Schau dir nochmal meinen Wortlaut an. Und wenn du behauptest, daß "Low Level" mit Delphi empfehlenswert sei, dann frage ich mich umgekehrt was ...

sehe hier den Sinn der Aussage nicht...

Zitat:

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.

darauf bin ich schon eingegangen

Zitat:

Äpfel und Birnen? Hatten wir nicht eben noch von Delphi und 32bit-Betriebssystemen gesprochen? Früher ... jetzt haben wir aber Sommer.

Da du ja anscheinend sooo viel Ahnung hast (bitte sagen wenn du angebetest werden willst) solltest du wissen, daß unter Windows 9x DOS gerade noch eine sehr wichtige Rolle spielt. Z.B. der genannte Festplattenzugriff.

Zitat:

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

Natürlich pauschal, denn du sagst Delphi ist nicht empfehlenswert, wahrscheinlich weil man mit Delphi keine Treiber implementieren kann, ist hier aber nicht notwendig ergo, kein Argument.

Zitat:

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 ...

Du bietest eine Lösung an die schwerer als nötig ist, und sagst dann dies geht nicht mit Delphi. Vielleicht ist dein Ansatz falsch und hier nur Overkill, schonmal darüber nachgedacht?

Oh Gott der Rest ist ja noch schlimmer. Wenn es hier um Status und Ruhm geht, tut mir Leid daß ich hier jemanden kritisiere.

Der Punkt ist Delphi kann es, Code Beispiele habe ich geliefert, setz dich mit der Realität auseinander oder lass es. Durch blosen Status und ich oder jener ist bekannt, wirst du daran nichts ändern. Schade...

[Olli]

Zitat von mael:

Zitat von Olli:

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?

Ob ich jetzt als Admin eingeloggt bin oder RunAS verwende ist hier ja wohl egal. Es ändert nichts daran, das man Adminrechte braucht, also was soll das hier?

Ähem? Habe ich mich auch gefragt. Wer von uns beiden hat Services zur Delegation von Aufgaben aus niedrigprivilegiertem Kontext infragegestellt? Nur aus diesem Grund habe ich Services oben erwähnt. Du hast gleich aus vollen Rohren gegen diese Aussage geschossen.

Zitat von mael:

Zitat von Olli:

Ähem ... hast du da auch selber mal reingeguckt?

aber du verstehst anscheinend immer noch nicht, daß ich hier bestehende Treiber verwende und keine schreiben muß.

Doch. Ich habe auch nie das Gegenteil geschrieben. Du versteifst dich aus irgendeinem Grund auf Treiber, obwohl ich die nur im Zusammenhang mit Wiederherstellung von Daten erwähnte.

Zitat von mael:

Zitat:

Schau dir nochmal meinen Wortlaut an. Und wenn du behauptest, daß "Low Level" mit Delphi empfehlenswert sei, dann frage ich mich umgekehrt was ...

sehe hier den Sinn der Aussage nicht...

Dann werde ich mal nachhelfen. Du unterstellst mir Unwissenheit, wenn ich sage, daß ich Delphi im Zusammenhang mit Native API usw. nicht empfehlen kann. "Nicht empfehlen" heißt nichts anderes, als daß es bessere Alternativen gibt. Es besagt noch nichtmal, daß Delphi dazu nicht in der Lage wäre!

Zitat von mael:

(bitte sagen wenn du angebetest werden willst)

Bitte bescheidgeben wenn du unterschwellig oder auch offen beleidigend werden willst.

Zitat von mael:

solltest du wissen, daß unter Windows 9x DOS gerade noch eine sehr wichtige Rolle spielt. Z.B. der genannte Festplattenzugriff.

Eben. 32bit-Windows. Davon kann man bei Windows 9x wohl kaum reden. Ich sage nur Thunking.
Abgesehen davon bietet natürlich auch Windows 9x/Me Möglichkeiten zum kontrollierten (aber weniger als in NT) "direkten" Festplattenzugriff.

Zitat von mael:

Natürlich pauschal, denn du sagst Delphi ist nicht empfehlenswert, wahrscheinlich weil man mit Delphi keine Treiber implementieren kann, ist hier aber nicht notwendig ergo, kein Argument.

Lies lieber nochmal nach.
Wenn ich "Treiber" und "Delphi" im selben Beitrag benutze und du das als rotes Tuch auffaßt, dann tut es mir leid. In diesem Falle solltest du statt zu unterstellen lieber die gegebenen Aussagen aufgreifen. Das bringt auch dem Fragesteller mehr.

Zitat von mael:

und sagst dann dies geht nicht mit Delphi.

... ich wiederum gebe dir bescheid, wenn es dir erlaubt ist mir Worte in den Mund zu legen die ich nie gesagt habe. Du kannst mich gerne für meine Aussagen angreifen, aber Angriff für Sachen die ich nicht gesagt habe (sondern die du mir unterstellst gesagt zu haben), ist grundloser Angriff!

Zitat von mael:

Vielleicht ist dein Ansatz falsch und hier nur Overkill, schonmal darüber nachgedacht?

Ja und ja.

Zitat von mael:

Oh Gott der Rest ist ja noch schlimmer. Wenn es hier um Status und Ruhm geht, tut mir Leid daß ich hier jemanden kritisiere.

Du mußt mich nicht Gott nennen. Ich bin ja selber nicht sonderlich religiös und hatte auch nicht vor eine neue Religion zu gründen. Es geht hier ums Fachliche, nicht mehr und nicht weniger. Und wenn du mal richtig lesen würdest, würdest du nicht zu solchen Unterstellungen kommen. Klar Treiber sind in Delphi nicht möglich, Native API ist möglich - oft aber nicht empfehlenswert. Der Unterschied scheint allen hier im Thema klar zu sein, außer dir.

Zitat von mael:

Der Punkt ist Delphi kann es,

Trotz all der Unterstellungen deinerseits; gegenteiliges habe ich nie behauptet!

Zitat von mael:

Code Beispiele habe ich geliefert, setz dich mit der Realität auseinander oder lass es.

Code? Sprechen wir von diesem hier? Ich sagte ich will von dir Code zur Datenwiederherstellung auf einem laufenden System und ohne Treiber sehen. Den hast du noch nicht gebracht. Ich frage mich auch was du dann noch mit "direktem Festplattenzugriff" willst, wenn du die Struktur von NTFS nicht aus dem Effeff kennst (würdest du sie kennen, hättest du ein NDA mit MS unterschrieben und dürftest hier nicht helfen). Schonmal bei DriveImage 8 (aka Norton Ghost 9) unter die Haube geguckt? Kann ich nur empfehlen. Und dann sage mir nochmal "ohne Treiber". Frisch gelöschte Dateien kann man hingegen u.U. auch ohne Treiber wiederherstellen (alles undokumentiert und mit "direktem" Festplattenzugriff wird's schwerer nicht leichter - zumindest auf NTFS). Da hast du ganz recht. Gibt's sogar OpenSource zum Thema.


Aber wenn du hier fixiert bist auf "Längenvergleich", dann laß uns doch das über PN machen. Da kannst du mich dann auch so richtig beleidigen ... aber bitte nur auf Basis meiner Aussagen, nicht auf Basis deiner eigenen.

Nachtrag: Hier nochmal dieses Thema mit dem Wort "Treiber" hervorgehoben. Dann kannst du vielleicht nochmal über deine Unterstellungen nachsinnen.

[alcaeus]

Hallo ihr beiden,

Zitat von Olli:

dann laß uns doch das über PN machen.

bitte macht genau das. So bringt das wirklich nichts, und langsam ist das Thema auch OT genug. Das hilft keinem.

Greetz
alcaeus

[generic]

ja unkaputtbar :

Zitat:

Note that the FSCTLs are implemented such that you CANNOT corrupt data on your drive by using them.

[Olli]

Zitat von generic:

ja unkaputtbar :

Zitat:

Note that the FSCTLs are implemented such that you CANNOT corrupt data on your drive by using them.

Wenn du es so meinst, stimmt es (alles andere wäre schlimm ). Du sprachst aber von APIs, daher wohl das Mißverständnis. Sorry.

[starY]

Gut danke an alle, auch wenn der Thread mehr zum Streitthema über Delphi geworden ist.
Maels Methode geht und diese finde ich auch einfacher. Aber wie so immer gibt es mehrere Methoden

Delphi-Quellcode:

DeviceIoControl(DeviceHandle, IOCTL_DISK_GET_DRIVE_GEOMETRY, nil, 0,
    @DiskGeometry, sizeof(DiskGeometry), Dummy, nil);

Ich hab nochmal eine Frage zu dieser Funktion... irgendwie will mein Delphi IOCTL_DISK_GET_DRIVE_GEOMETRY und Dummy nicht Welche uses muss ich dafür einbinden?

NTFS läuft außerdem nur unter NT (von haus aus) und höher deswegen bringt es nichts wenn ich 9x Unterstützung mache.