4. Device-Treiber erstellen?

Device-Treiber erstellen?

  • N

    dEUs schrieb:

    Würde es sich von der Bezahlung her denn lohnen, sich in dieses Thema einzuarbeiten?

    wenn man nicht vorbelastet ist zum thema 'windoof device drivers' dann kann das wohl keiner bezahlen

    0
  • D

    Wieso? Wenn die Bezahlung halbwegs anständig ist, würde ich mich in das Thema einarbeiten und wenn ich denke, ich könnte es schaffen, würde ich Bescheid geben. Nicht umgekehrt: Sagen ich mach's und dann hoffen, dass ich das Thema kapier.

    Btw: Es heisst Windows nicht windoof, ja?

    0
  • T

    Hi,

    mit dem einfügen von eigenen Fehlermeldungen währ ich etwas vorsichtig.

    1. ggf Handelst du dier inkompatibilitäten zu noch erscheinenden windows versionen ein ( windows liefert selber die gleiche fehler id, was passiert dann???)

    2. Wie reagiert windows auf neue Fehlercods die es selber nicht kennt? einfach weiterreichen durch die eigene API, absturtz, einfach unterbinden ???

    3. Wie soll sich eigentlich windows verhalten wenn aus versehen ein benutzer auf dein im netzwerk freigegebenes laufwerk zugreift und einen solchen fehler produziert? Es kennt ja den Fehlercode nicht und kann auch nicht entsprechend drauf reagieren. ( wie ferhält sich dann dein treiber? )

    also wenn ich das jetzt richtig verstanden hab. dein treiber will mitbekommen was auf dem laufwerk gelesen und geschrieben wird. Fehlschläge werden vom Treiber abgefangen und gegebenenfals zu einem spähteren zeitpunkt nachgeholt werde. Werden daten angefordert die z.B. in einer Datenbank existieren aber momentan nicht verfügbar sind ( z.B. gelockt ) wird deine besondere Fehlermeldung zurückgegeben, Dein Treiber versucht dann zum nächstmöglichen zeitpunkt die daten in einer datei bereitzustellen, damit die applikation drauf zugreifen kann.

    Allein punkt 3 würde mich eher veranlassen eine art eigenes netzwerk protokoll zu implementieren. anstelle windows neue fehlercods beizubringen.

    gruss Termite

    0
  • N

    wenn man keinen eigenen filesystem driver entwickeln will, weil's zuviel aufwand bedeutet etc. dann könnte man auch die funktion 'CreateFile' systemweit 'hooken'.
    guckt ihr hier: http://research.microsoft.com/~galenh/Publications/HuntUsenixNt99.pdf

    0
  • V

    @dEUs: Den Preis weiss ich noch nicht. Ich wollte zuerst wissen wie gross der Aufwand ist. Es ist schon richtig, dass sowas am besten von jemandem gemacht wird der sowas Ähnliches schonmal realisiert hat. Ich will definitiv nur für das Entwickeln bezahlen und nicht für das Einarbeiten in's Thema. 🙄

    @Termite: Was Du verstanden hast ist soweit korrekt. Windows selbst soll sich nicht anderst verhalten. Ich weiss nur, wenn ich mit I/O-Funktionen auf ein Laufwerk zugreife, dann erhalte ich meistens 53 wenn die Datei nicht da ist. Ich möchte diese Zahl eben beeinflussen können. Ebenso möchte ich die Fehlermeldung herauszögern können da ich die Datei evtl. noch schnell erstellen kann. Danach kann Sie ja ganz normal geliefert werden.
    Ein eigenes Protokoll würde nur ganz speziellen Anwendungen erlauben mit diesem 'Laufwerk' zu arbeiten. Es muss aber allgemein zugänglich bleiben.

    @Net: Schon. Kann man auch einen 'FileNotFound' hooken? Soweit ich weiss nicht. Sonst könnte ich auch mit dem API Befehl ReadDirectoryChangesW() und GetOverlappedResult() arbeiten. Da fehlen mir aber die angesprochenen Funktionen.

    Wer traut sich das Zu und mit welchem Aufwand müsste ich rechnen? Evtl. eine Stundenschätzung? 😕

    Grüsse,

    Volker

    0
  • N

    Volker Schmid schrieb:

    @Net: Schon. Kann man auch einen 'FileNotFound' hooken? Soweit ich weiss nicht.

    doch, ungefähr so

    HANDLE MyCreateFile (...
{
    HANDLE h = CreateFile (....
    if (h != INVALID_HANDLE_VALUE)
       return h;
    /*
     *  hier fehler behandeln
     */
}
    0
  • H

    brauchste doch eigentlich nur eine Wrapper DLL, die die Dateizugriffsfunktionen enthält (weiß grad nicht, welche das ist).

    Damit kann man sogar leicht ein Laufwerk simulieren. Ich weiß nur nicht, in wie weit der Dateiexplorer auf diese Funktionen zugreift, müsste er aber eigentlich.

    0
  • N

    Loggy schrieb:

    brauchste doch eigentlich nur eine Wrapper DLL, die die Dateizugriffsfunktionen enthält (weiß grad nicht, welche das ist).

    kernel32.dll. die heisst aber nur so, hat wohl historische gründe. ist nicht der kernel von windows.

    Loggy schrieb:

    Ich weiß nur nicht, in wie weit der Dateiexplorer auf diese Funktionen zugreift, müsste er aber eigentlich.

    letztendlich gehen alle windoof-proggis über CreateFile/ReadFile/WriteFile, egal ob sie 'fopen', 'ostream' oder sonstwas benutzen.

    0
  • H

    dann ist es doch kein Problem...

    0
  • T

    Hi

    @Volker Schmid

    Genau diese neuen Fehlermeldungen machen mir am meisten kopfzerbrechen. Du solltest sicherstellen, das dann der normale zugriff auf das laufwerk fehlerfrei funktioniert.

    anders herum könnte man auch bei einem eigenen netzwerk protokoll einen eigenen kleinen treiber schreiben, der ein Windowslaufwerk auf das netzwerkprotokoll mapt. diser treiber versteht deine ganz speziellen fehlermeldungen und kann daraus dan windows konforme generieren. Problem dabei ist, das nur rechner die den treiber installiert haben auf das laufwerk zugreifen können.

    gruss Termite

    0
  • V

    Ok,

    Ich mache es nochmals kurz. Ich möchte folgendes Erreichen:

    1. Anforderung
    Ich mappe ein Verzeichnis auf einen Laufwerksbuchstaben (alternativ würde auch die Überwachung eines Verzeichnisses incl. Unterverzeichnissen ausreichen wenn ich denn dann vor allem den FileNotFound hooken könnte).

    2. Anforderung
    Ich muss ALLES mitbekommen was hier passiert. Dazu zählt vor allem, dass ich mitbekommen muss wenn eine Datei erstellt oder nicht gefunden wird. Im zweiten Fall muss ich etwas tun können:
    a. Die Datei generieren und dann normal liefern
    b. oder einen Fehlercode liefern der sich vom normalen 'file not found' unterscheidet.

    3. Anforderung
    Nutzbar unter VB6. Ich kann ja eine Callback-Routine angeben oder eine Art Messagepuffer auslesen (zweites wäre mir lieber. Könnte das dann in einem Timer machen).

    Evtl. hilft es, wenn ich den Sinn erkläre. Ich möchte aber nicht zu viel von meiner Programm-Idee preisgeben um Nachahmer zu bremsen (habe da schon schlechte Erfahrung).
    Immer dann wenn in meinem Szenario eine Datei nicht gefunden wird, kann ich diese zu 90% anderst generieren. Das kann aber durchaus auch 10 Minuten dauern. Wenn ich es schnell kann, möchte ich die Datei generieren. Wenn nicht, möchte ich einen Code zurückgeben der es anderen Anwendungsentwicklern erlaubt darauf anderst zu reagieren als auf einen normalen FileNotFound. Der Code könnte bedeuten 'Versuche es in 10 Minuten nochmal' etc. Wenn auch ich die Datei nicht generieren kann, dann darf gerne ein normales FileNotFound kommen.

    Grüsse,

    Volker

    0
  • H

    Wann brauchst du das denn?

    0
  • V

    @loggy: Es ist nicht sehr Eilig. Allerding schon noch dieses Jahr.

    Volker

    0
  • H

    Wenn du bist mitte Oktober niemanden gefunden hast, würde ich es mal versuchen.

    Ich habe Erfahrung im Ausspionieren von Systemaktivitäten (konkret hatte ich das mal für CD-Rom Aktivitäten implementiert). Deine Erweiterungen sollten da kein Problem sein.

    0
  • N

    Loggy schrieb:

    (konkret hatte ich das mal für CD-Rom Aktivitäten

    mit einem filter driver oder mit 'FindFirstChangeNotification'?
    mit letzterem kriegst du's aber erst mit, wenn's schon zu spät ist.

    0
  • H

    Ne, ich hatte die ASPI DLL neu geschrieben (natürlich die Funktionalität dann auf die alte DLL weitergeleitet).

    0
  • V

    Vergesst FindFirstChangeNotification() oder auch ReadDirectoryChangesW() sofort. Es ist nicht möglich damit herauszufinden ob eine Datei NICHT gefunden wurde. Da habe ich schon wochenlang experimentiert. Ebenso kann ich die Rückgabe einer Datei in keinster Weise beeinflussen (zB innerhalb einer Minute generieren und dann zurückgeben).

    Volker

    0
  • N

    Loggy schrieb:

    Ne, ich hatte die ASPI DLL neu geschrieben (natürlich die Funktionalität dann auf die alte DLL weitergeleitet).

    ja, cool.

    0
  • N

    Volker Schmid schrieb:

    Vergesst FindFirstChangeNotification() oder auch ReadDirectoryChangesW() sofort. Es ist nicht möglich damit herauszufinden ob eine Datei NICHT gefunden wurde.

    insofern sind die namen der funktionen ganz passend 😉

    0
  • V

    Na - und?

    Wer kann mir das jetzt anbieten? Preisvorschläge? Gerne auch per e-Mail an:

    VSchmid(AT)Inspirant(Punkt)de

    Volker

    0
Anmelden zum Antworten