API: Substituierte Laufwerke erkennen ?

[delph5]

103 API: Substituierte Laufwerke erkennen ?

1) Situation: Den Meisten wird es ähnlich wie mir gehen: Man hält sich an die Vorgaben von DELPHI. So ist bei mir aller Unit-QuellCode in einem Ordner namens c:programmeborlanddelphi5projects mit UnterVerzeichnissen für die einzelnen Projekte oder Programme.

Beim Disketten-Backup war die *.EXE-Datei schon immer störend, weil viel zu groß. Das konnte man sich aber in der IDE so einstellen, daß alle *.EXE-Dateien in eineM extra Verzeichnis außerhalb dieser Struktur landeten.

Der Job der DatenSicherung ist bei mir ein XCOPY ....*.* nach A: . Dabei war der lange Verzeichnis-Pfad-Name immer noch lästig, auch bei der Klick-Klick-Technik von WIN. Deshalb ist dieser Pfad durch das Kürzel p: substituïert.

Jedoch: Seitdem taucht dieses "Laufwerk" (in AnführungsZeichen, weil eher eine Pfad-Abkürzung) als "LaufWerk p:" sogar im WIN-Explorer auf mit dem VolumeLabel der FestPlatte. Und auch in meineM DiskScan-Delphi-Programm.

Win-API liefert zwar Informationen über die gültigen LaufWerks-Buchstaben, aber (soweit ich das über-blicke:) Keine Infos über die Tatsache, daß es kein "echtes" Laufwerk ist mit einem Motor drin und Kabeln dran.

[FONT COLOR="red"]2) Frage:[/FONT] Wer weiß, wie man per API erkennt, was ein Laufwerk ist und was eine Pfad-Abkürzung ?

3) Eigene Tests: Mittlerweile bin ich ausgiebig durch das Win-API gestreift und kenne die von WIN vergebenen Typen fast auswendig. Da brauche ich jetzt nicht nachzuschlagen: Null und Eins sind irgendwelche Fehler-Bedingungen, Typ_2 ist eine Floppy, Typ_3 ist eine FestPlatte und so weiter bis hin zu Typ_CD-ROM und _NetzLaufwerk. Aber für "substituiert" finde ich rein gar-nichts, obwohl man sogar für den RAM-Drive einen eigenen Typ hat.

Weiß jemand, wie man an die richtigen Informationen heran-kommt ?

Danke für alle / "any" Tips.

.

[Thomas Stutz]

[font size=2 face="Courier New"][font color="#000000"]Hi,

Hab Code gefunden zum Erstellen  von
virtuellen Laufwerken und hab dann daraus eine Funktion IsSubstDrive erstellt.

Funktioniert unter Win 9x/NT/2000/XP.

[font color="#000080"]{
 Original Code: Freware with source.
 Copyright © 2000-2002, SoftLab MIL-TEC Ltd
 Web:   http://www.softcomplete.com
}

[/font]procedure VxDCall; external kernel32 Index 1

implementation

[font color="#000080"]{$R *.DFM}


// IsSubstDrive liefert einen leeren String zurück,
// wenn das mit dem Buchstaben verknüpfte Laufwerk
// nicht existiert oder nicht virtuell ist.
// Sonst liefert es den Pfad der Laufwerkbezeichnung.

[/font]function IsSubstDrive(DriveLetter: Char): string;
var 
  drvno: byte;
  buff: array[0..256] of char;
  lbuff: array[0..256] of char;
begin
  [font color="#000080"]{ Für Windows NT }
  [/font]if Win32Platform = VER_PLATFORM_WIN32_NT then
  begin
    lbuff[0] := DriveLetter;
    lbuff[1] := ':';
    lbuff[2] := #0;
    buff[0]  := #0;
    QueryDosDevice(lbuff, buff, 256);
    Result := StrPas(buff);
    if Copy(Result, 1, 4) = '??' then
      Result := Copy(Result, 5, Length(Result))
    else
      Result := '';
  end 
  else
  [font color="#000080"]{ Für Windows 9x/ME }
  [/font]begin
    drvno   := Ord(UpperCase(DriveLetter)[1]) - 64;
    buff[0] := #0;
    asm
       pushad
       push    es
       xor     ebx, ebx
       mov     bh,2
       mov     bl,drvno
       lea     edx,buff
       push    0       [font color="#000080"]//ECX (unused)
       [/font]push    71AAh
       push    2A0010h
       call    VxDCall
       pop     es
       popad
    end;
    Result := StrPas(buff);
  end;
end;


procedure TForm1.Button1Click(Sender: TObject);
var
  strPath: string;
begin
  strPath := IsSubstDrive('h');
  if strPath <> '' then
  begin
    ShowMessage('Dies ist ein virtuelles Laufwerk! ---> ' + strPath);
  end;
end;
[/font][/font]

[delph5]

danke.

[delph5]

119 Pfad-Substitution: Wer oder was ist ein "VxDCall" ?

Zitat:
----------------------------
'delph5_103' schrieb:[FONT COLOR="purple"]
Win-API liefert zwar Informationen über die gültigen LaufWerks-Buchstaben, aber (soweit ich das über-blicke:) Keine Infos über die Tatsache, daß es kein "echtes" Laufwerk ist mit einem Motor drin und Kabeln dran.

Frage: Wer weiß, wie man per API erkennt, was ein Laufwerk ist und was eine Pfad-Abkürzung ?
[/FONT]----------------------------
Der Lösungsvorschlag bestand u.a. im Aufruf (siehe oben) einer

procedure VxDCall; external kernel32 Index 1

Zitat:
----------------------------
'Thomas Stutz' schrieb:[FONT COLOR="purple"]
Hab Code gefunden zum Erstellen von virtuellen Laufwerken und hab dann daraus eine Funktion IsSubstDrive erstellt...
[/FONT]----------------------------
Leider funktioniert die Sache bei mir nicht: DELPHI-5-prf unter WIN-98SE. Es ist nicht so einfach, heraus-zufinden, warum diese Funktion für beliebige LaufwerksBuchstaben immer nur den leeren String liefert, auch bei PfadNamen, welche durch einen virtuëllen LaufwerksBuchstaben substituiert (ersetzt) sind:

Laut DELPHI-Debugger sind die beiden ersten Bytes von BUFF (siehe oben) stets je #0, der Rest ist wirr. Daraus macht dann die Umwandlung in einen Pascal-String den LeerString.

Irgendwelche Informationen über den Begriff "VxDCall" gibt es nicht: Sowohl die Index- als auch die EinzelWort-Suche in der DELPHI-WIN-Hilfe ergeben die Meldung:

"Das angegebene Wort ist nicht im Index enthalten."

Könnte es sein, daß der Code zwar ursprünglich "zum Erstellen von virtuellen Laufwerken" taugte, daß dabei aber möglicher-weise sich ein Bug eingeschlichen haben könnte ?

Rein gefühls-mäßig vermute ich, daß WIN intern einen direkteren Weg benutzt, um bei allen möglichen Gelegenheiten die Zwei-Zeichen-Folge von beispielsWeise P: durch eine Pfad-Zeichen-Kette von beispielsWeise C:.........  zu ersetzen, oder ?

Danke für alle / "any" Tips !

.

[Thomas Stutz]

Es ist nicht so einfach, heraus-zufinden, warum diese Funktion für beliebige LaufwerksBuchstaben immer nur den leeren String liefert,

Es steht ja oben, dass die Funktion für nicht virtuelle Laufwerke einen leeren String zurück gibt.

auch bei PfadNamen, welche durch einen virtuëllen LaufwerksBuchstaben substituiert (ersetzt) sind:

Da komm ich nicht draus. Übergibst du der Funktion einen Pfad ?
Kannst ja nur ein Zeichen (Char) übergeben.

[delph5]

120 Pfad-Substitution: Wie WIN die virtuëllen Laufwerke verwaltet

Zitat:
----------------------------
'Thomas Stutz' schrieb:[FONT COLOR="purple"]
Übergibst du der Funktion einen Pfad ? Kannst ja nur ein Zeichen (Char) übergeben.
[/FONT]----------------------------
Siehe erster Beitrag, ganz oben: Man übergibt das Zeichen p und würde erwarten, daß die Funktion den String 'c:programmeborlanddelphi5projects' o.ä.zurück-liefert, weil WIN selbst im EXPLORER das (virt.) Laufwerk P: anzeigt.

Leider liefert die Funktion für p immer nur den Leeren String zurück. Im Debugger kann man sich etwas darüber informieren; allerdings blendet der Debugger die Einzelheiten der Routine "VxDCall" aus.

Einer meinte: Vermutlich verwaltet WIN noch immer wie sein Vorläufer DOS im Speicher eine Pfad-Tabelle, wo für jedes Laufwerk der aktuëlle Pfad eingetragen ist. Dort steht dann am Platz des Laufwerks p einfach der Eintrag 'c:programmeborlanddelphi5projects' .

•   Vielleicht wissen Sie, wie man dem WINDOWS den Zeiger auf diese Tabelle entlockt ?

•   Oder jemand weiß, wie man die SUBST.EXE-Datei analysiert:
    Da steht es nämlich drin als Quasi-Assembler-Code (den ich noch nicht kann),

•   oder jemand weiß, wie man das Programm SUBST.EXE von DELPHI aus auf-ruft und
    seinen OutPut in einem Stream o.ä. speichert. Denn es heißt bei SUBST /?

"SUBST.EXE ohne Parameter zeigt die mit SUBST erstellten, virtuellen Laufwerke an."

Ich würde mich schon selbst durch die Beschreibung der WIN_API-Schnittstelle durch-buddeln, wenn mir jemand sagt, wo man zu studieren an-fangen muß. Die Schlagwort-Suche ist bei WIN anscheinend NICHT Bücher-übergreifend organisiert; davon gibt es immerhin mind. 21 Stück, die namentlich im Programm-Menü gelistet sind.

Danke für alle / "any" Tips !

.