DOS und Laufwerk B:
Gerd Roethig
in einem kleinen Programm verwende ich die folgende Routine zur
Überprüfung der im System vorhandenen Laufwerke:
Function DriveExists( drv: byte ): Boolean;
(*
Laufwerke: von 0 .. 26 fuer A .. Z, ist True, wenn Laufwerk
existiert, False, wenn nicht
*)
Var
Test: byte;
begin
DriveExists := False;
Test := $0;
asm
push DS
mov dl, drv
mov ah, 0Eh {Funktion 0E : Laufwerk auswaehlen}
int 21h
mov ah, 19h
int 21h
mov Test, al {Funktion 19 : Aktuelles Laufwerk holen}
pop DS
end;
if Test = drv then DriveExists := true;
end; {function}
Diese Funktion liefert mir allerdings unter DOS auch ein TRUE für
Laufwerk B:, obwohl dieses hardwaremäßig nicht existiert. Wird
trotzdem darauf zugegriffen, gibt DOS die Meldung
"Diskette in Laufwerk B: einlegen und beliebige Taste drücken"
aus. Nach Tastendruck wird auf Laufwerk A: (das im konkreten Fall
einzige Diskettenlaufwerk) zugegriffen, jedoch ohne Erfolg, es können
keine Daten gelesen werden.
Wie kann ich vermeiden, daß ein nicht vorhandenes Laufwerk B: gefunden
wird? Für alle anderen Laufwerke funktioniert die obige Routine
einwandfrei, außer B: werden auch keine Laufwerke zuviel gefunden.
Vielen Dank für jeden Tip im voraus und noch alles Gute für 1999 sowie
Beste Grüße
Gerd
Hubert Seidel
Gerd Roethig schrieb in Nachricht <3691d379...@news.uni-leipzig.de>...
>Hallo allerseits,
>
>in einem kleinen Programm verwende ich die folgende Routine zur
>Überprüfung der im System vorhandenen Laufwerke:
>
>Function DriveExists( drv: byte ): Boolean;
>[...]
> if Test = drv then DriveExists := true;
>
>end; {function}
>
>Diese Funktion liefert mir allerdings unter DOS auch ein TRUE für
>Laufwerk B:, obwohl dieses hardwaremäßig nicht existiert. Wird
>trotzdem darauf zugegriffen, gibt DOS die Meldung
>[...]
>Wie kann ich vermeiden, daß ein nicht vorhandenes Laufwerk B: gefunden
>wird? Für alle anderen Laufwerke funktioniert die obige Routine
>einwandfrei, außer B: werden auch keine Laufwerke zuviel gefunden.
>
Versuche es einfach mit DriveSize
0 ist das aktuelle Laufwerk
1 bis 26 ebtspricht A: bis Z:
Natürlich wird A: auch nicht erkennt, wenn keine Diskette eingelegt ist
function DriveExist(LwNr:Byte):Boolean;
begin
DriveExist:=(DriveSize(LwNr)<>-1);
end;
var
i:byte;
begin
for i:=1 to 26 do if DriveExist(i) then write(char(i+64));
writeln;
end.
mfg. Herby
P.S.: Jetzt kommt es darauf an, was Du überhaupt machen willst . . .
Gerd Roethig
Am 5. Jan 1999 13:11:48 +0100 schrieb herby....@t-online.de
(Hubert Seidel) :
>Gerd Roethig schrieb in Nachricht <3691d379...@news.uni-leipzig.de>...
>>in einem kleinen Programm verwende ich die folgende Routine zur
>>Überprüfung der im System vorhandenen Laufwerke:
>>
>>Function DriveExists( drv: byte ): Boolean;
>>[...]
>> if Test = drv then DriveExists := true;
>>
>>end; {function}
>>
>>Wie kann ich vermeiden, daß ein nicht vorhandenes Laufwerk B: gefunden
>>wird? Für alle anderen Laufwerke funktioniert die obige Routine
>>einwandfrei, außer B: werden auch keine Laufwerke zuviel gefunden.
>>
>Versuche es einfach mit DriveSize
[...]
>
>Natürlich wird A: auch nicht erkennt, wenn keine Diskette eingelegt ist
Genau das nützt mir nur begrenzt etwas, denn
>P.S.: Jetzt kommt es darauf an, was Du überhaupt machen willst . . .
ich habe ein Dateiauswahlfenster gebastelt, über das sich der Benutzer
des Programms die zu bearbeitende Datei aussuchen kann. Zusätzlich
werden die vorhandenen Laufwerke angezeigt, die man dann durch Drücken
der Taste mit dem jeweiligen Buchstaben anwählen kann.
Das funktioniert, eben bis auf die Sache mit dem nicht vorhandenen
Laufwerk B:, recht gut.
Trotzdem Danke für Deinen Tip, denn jetzt habe ich eine einfache
Möglichkeit gefunden, Fehler abzufangen, wenn mit dieser
Auswahlroutine auf das leere Laufwerk A: zugegriffen wird...
Ciao
Gerd
Gerd Roethig
Am Thu, 07 Jan 1999 21:04:56 +0100 schrieb Wolf Behrenhoff
<wolf.be...@gmx.net> :
>> in einem kleinen Programm verwende ich die folgende Routine zur
>> Überprüfung der im System vorhandenen Laufwerke:
>>
>> Function DriveExists( drv: byte ): Boolean;
>> [...]
>> Diese Funktion liefert mir allerdings unter DOS auch ein TRUE für
>> Laufwerk B:, obwohl dieses hardwaremäßig nicht existiert. Wird
>> trotzdem darauf zugegriffen, gibt DOS die Meldung
>>
>> "Diskette in Laufwerk B: einlegen und beliebige Taste drücken"
>>
>> aus. Nach Tastendruck wird auf Laufwerk A: (das im konkreten Fall
>> einzige Diskettenlaufwerk) zugegriffen, jedoch ohne Erfolg, es können
>> keine Daten gelesen werden.
>>
>> Wie kann ich vermeiden, daß ein nicht vorhandenes Laufwerk B: gefunden
>> wird? Für alle anderen Laufwerke funktioniert die obige Routine
>> einwandfrei, außer B: werden auch keine Laufwerke zuviel gefunden.
>Hallo Gerd,
>versuch es mal mit Funktion 440Eh des int 21h. (GetLogicalDriveMap, ab
>MS-DOS 3.2)
>
>eine Funktion sieht dann so aus:
[...]
Wie schon in dem anderen Posting von mir bemerkt, sieht diese Funktion
der in der PASCAL-FAQ auf
http://home.tu-clausthal.de/~inas/computer/FAQ/pasfaq.html
nicht nur sehr ähnlich, sie kann wie diese das Auftauchen des
Phantom-Laufwerks B: nicht vermeiden. Offenbar verarscht INT21 hier
den Programmierer gründlich :( .
>Für weitere Fragen, die mit Interrupts bzw. Systemprogrammierung zu tun
>haben, empfehle ich Ralf Browns Interruptliste unter
>http://www.pobox.com/~ralf
Vielen Dank für den Tip! Werd ich mal durchlesen.
>
>Viel Erfolg noch mit Deinem Dateiauswahlfenster (wie wärs mit
>TurboVision???)
Brr...es gibt noch einen weiteren Grund, nicht auf Turbo Vision
umzusteigen - deren Dateiauswahldialog (mir gefällt er einfach nicht,
denn es ist ziemlich mühsam, das aktuelle Verzeichnis zu wechseln,
wenn viele Verzeichniseinträge zur Auswahl stehen und man gezwungen
ist, zu scrollen.
Und das aus einem simplen Grund: Die Verzeichnisse sind nicht
alphabetisch sortiert, sondern werden in der Reihenfolge angegeben,
wie sie auch im Dateisystem stehen. Da wird es schnell fummelig, wenn
man in einem Verzeichnis mit vielen Einträgen ist.
Ich verstehe aber auch, warum das so gelöst wurde:
In den FAT-basierten Dateisystemen darf es unendlich viele
Verzeichniseinträge geben (ich wollte es erst nicht glauben), deren
maximale Anzahl ist nur durch den zur Verfügung stehenden
Speicherplatz auf dem Datenträger begrenzt (bzw. durch die maximale
Partitionsgröße). Da bringt man bei FAT32 und heutigen Festplatten
schon einiges unter - und das ist ein ziemliches Problem für ein
Programm, das möglichst sämtliche Verzeichniseinträge anbieten soll,
und das am besten noch sortiert.
Für DOS-Programme wächst sich das offenbar zu einem ziemlichen Problem
aus, der Norton Commander beispielsweise steigt auch bei einigen
tausend Verzeichniseinträgen aus. Wie weit es der Windows-Explorer
oder der Dateimanager schaffen , konnte ich mangels ausreichend vieler
Dateien noch nicht abschließend testen :) .
Fragt sich sicher manch einer jetzt: Wozu braucht der Mensch soviele
Dateien in einem einzigen Verzeichnis? Die Antwort ist simpel: Bei den
zu bearbeitenden Dateien handelt es sich um Protokolldateien einer
Meßsoftware, die automatisch bei jeder Messung erstellt und in ein und
dasselbe Verzeichnis abgelegt werden. Da die Dateien in ihrem Header
ausführliche Informationen über den Zeitpunkt der Messung, das
verwendete Meßprotokoll usw. tragen, ist eine Unterteilung ihres
Verzeichnisses in viele kleine Unterverzeichnisse nicht sehr sinnvoll.
Aber zurück zu dem Thema Laufwerke - irgendwie muß das doch zu lösen
sein, jeder primitive Dateimanager-Klone kann es. Welche Möglichkeiten
gibt es noch, zu prüfen, ob das Laufwerk B: vorhanden ist?
Zu dem in einem anderen Posting geäußerten Vorschlag, die Anzahl
installierter Diskettenlaufwerke auszulesen, bleibt zu sagen, daß es
genau dann Probleme geben kann, wenn jemand auf die Idee kommt, etwas
anderes als ein Diskettenlaufwerk als B: in sein System einzubinden.
Ciao
Gerd
Arno Fleck
> Fragt sich sicher manch einer jetzt: Wozu braucht der Mensch soviele
> Dateien in einem einzigen Verzeichnis? Die Antwort ist simpel: Bei den
> zu bearbeitenden Dateien handelt es sich um Protokolldateien einer
> Meßsoftware, die automatisch bei jeder Messung erstellt und in ein und
> dasselbe Verzeichnis abgelegt werden. Da die Dateien in ihrem Header
> ausführliche Informationen über den Zeitpunkt der Messung, das
> verwendete Meßprotokoll usw. tragen, ist eine Unterteilung ihres
> Verzeichnisses in viele kleine Unterverzeichnisse nicht sehr sinnvoll.
Aaahhh ! Hilfe !
Ich hoffe, Dir ist das Cluster-Problem bekannt: 1000 Dateien bei einer
Cluster-Größe von 8 K belegen 8 Megs, bei 64 K sinds schon 64 Megs. Du
solltest also aufpassen, daß die Festplatte nicht voll wird.
Sinvoller wäre es IMHO, alle Meßdaten in einer großen Datei abzuspeichern.
Ist zwar beim Programmieren mehr Aufwand, dafür ist der Speicherbedarf
wesentlich geringer und Programme wie Defrag, Scandisk etc. werden auch nicht
so stark verlangsamt.
Bye,
Arno
P.S.: Ich kriege jedesmal Krämpfe, wenn ich ein Programm sehe, das mehr als
200 Dateien hat !
--
http://afleck.home.pages.de (English and German)
Software, Links, C&C, Chartbreaker and more
http://pangea.home.pages.de (German only)
Mach mit bei einem Spiele-Projekt im Internet
Gerd Roethig
Am Mon, 18 Jan 1999 20:04:32 +0100 schrieb Arno Fleck
<fl...@lycosmail.com> :
[ > 1000 Dateien in einem Verzeichnis; Meßsoftware]
>
>Aaahhh ! Hilfe !
>Ich hoffe, Dir ist das Cluster-Problem bekannt: 1000 Dateien bei einer
>Cluster-Größe von 8 K belegen 8 Megs, bei 64 K sinds schon 64 Megs. Du
>solltest also aufpassen, daß die Festplatte nicht voll wird.
>
Die Dateien sind zwischen einigen 10 K und etwas 1 MB groß, der
clusterbedingte Verschnitt dürfte sich also in Grenzen halten.
>Sinvoller wäre es IMHO, alle Meßdaten in einer großen Datei abzuspeichern.
>Ist zwar beim Programmieren mehr Aufwand, dafür ist der Speicherbedarf
>wesentlich geringer und Programme wie Defrag, Scandisk etc. werden auch nicht
>so stark verlangsamt.
Mag alles sein, nur:
<offtopic>
1. ist das besagte Programm eine kommerzielle Software, zu der es
_leider_ keinen Quelltext zum Umprogrammieren gibt
2. ist es wahrscheinlich für das Programm günstiger, mit einzelnen
Dateien zu arbeiten, als mit einer Riesendatei (ich denke nur mit
Grausen an den Krampf bei der Speicherallokation, wenn man mal mit
Variablen > 64 kB oder dynamischen Arrays arbeiten will).
3. wäre vermultich bei einem wie auch immer gearteten Fehler in der
Riesendatei (Programm spinnt oder Dateisystemfehler) die gesamte
gespeicherte Arbeit verloren. Ich kenne solche Sperenzchen von
NetScapes Mailer; ab einer gewissen Größe bekommt er seine Archive
nicht mehr auf und stürzt gerne dabei ab, nicht ohne die Datei vorher
noch zu verhunzen, so daß sich der Inhalt nur noch mit Hilfe eines
Editors, der sich von den Sonderzeichen nicht beirren läßt, zu
extrahieren ist. Oder - fast noch besser: Corel Draw, wenn man clever
sein wollte und ein mehrseitiges Dokument in einer Datei gespeichert
hat - im Falle eines Fehlers sind meist _alle_ Informationen aus der
Datei verloren, und Corel schrottet dann auch gerne noch das restliche
Windows.
Mir ist es lieber, ich habe viele Dateien (jede Messung = 1 Datei),
und bei einem Fehler erwischt es eben nur maximal eine Messung, als
daß ich zwar komfortabel und schnell, dafür aber immer mit der
Aussicht eines kompletten Datenverlusts arbeite.
</offtopic>
Mir ging es einfach nur darum, ein Dateiauswahlfenster zu basteln,
damit ich nicht jedesmal den Dateinamen auf einer readln-Zeile
eingeben muß (das Programm soll übrigens auch noch mehr können, als
nur Dateien auszuwählen, aber ich betrachte das als kleine Übung).
Also: An den Meßdateien und der sie erzeugenden Software kann ich
nichts ändern, ich möchte nur die dort gespeicherten Werte
analysieren.
>
>P.S.: Ich kriege jedesmal Krämpfe, wenn ich ein Programm sehe, das mehr als
>200 Dateien hat !
Tja, manchmal kann man das aber nicht ändern - und muß sehen, wie man
damit zurechtkommt.
Ciao
Gerd
Arno Fleck
> Die Dateien sind zwischen einigen 10 K und etwas 1 MB groß, der
> clusterbedingte Verschnitt dürfte sich also in Grenzen halten.
Ach so. Ich war davon ausgegangen, daß die Meßdateien einige Bytes groß sind. Nun
ja...
> 1. ist das besagte Programm eine kommerzielle Software, zu der es
> _leider_ keinen Quelltext zum Umprogrammieren gibt
Ein weiteres Mißverständnis. Ich dachte, daß Du die Software programmierst.
> 3. wäre vermultich bei einem wie auch immer gearteten Fehler in der
> Riesendatei (Programm spinnt oder Dateisystemfehler) die gesamte
> gespeicherte Arbeit verloren. Ich kenne solche Sperenzchen von
> NetScapes Mailer; ab einer gewissen Größe bekommt er seine Archive
> nicht mehr auf und stürzt gerne dabei ab, nicht ohne die Datei vorher
> noch zu verhunzen, so daß sich der Inhalt nur noch mit Hilfe eines
> Editors, der sich von den Sonderzeichen nicht beirren läßt, zu
> extrahieren ist.
Ähh, wie bitte ?
Ab welcher Größe denn ? Also bis 5 Megs hatte mein Netscape 4.5 keinerlei
Probleme.
> (zu >200 Dateien)
> Tja, manchmal kann man das aber nicht ändern - und muß sehen, wie man
> damit zurechtkommt.
So ist es... leider. Man schaue sich beispielsweise einmal die "Favoriten" und
"Verlauf"-Ordner des IE4 an. Graus !! Mehr Speicherplatzverschwendung hat
Microsoft wohl nicht auf die Schnelle hinbekommen.
Da freut man sich doch gleich doppelt über sein Netscape ! :-)
Bye,
Arno
Gerd Roethig
Am Tue, 19 Jan 1999 18:18:16 +0100 schrieb Arno Fleck
<fl...@lycosmail.com> :
>> 3. wäre vermutlich bei einem wie auch immer gearteten Fehler in der
>> Riesendatei (Programm spinnt oder Dateisystemfehler) die gesamte
>> gespeicherte Arbeit verloren. Ich kenne solche Sperenzchen von
>> NetScapes Mailer; ab einer gewissen Größe bekommt er seine Archive
>> nicht mehr auf und stürzt gerne dabei ab, nicht ohne die Datei vorher
>> noch zu verhunzen, so daß sich der Inhalt nur noch mit Hilfe eines
>> Editors, der sich von den Sonderzeichen nicht beirren läßt, zu
>> extrahieren ist.
>
>Ähh, wie bitte ?
>Ab welcher Größe denn ? Also bis 5 Megs hatte mein Netscape 4.5 keinerlei
>Probleme.
>
Hier ging es (schon ein Weilchen her) um Netscape 3.0.irgendwas, und
die Datei war 10 MB groß (viele Attachments in den einzelnen Mails).
Seitdem verwende ich lieber ein extra Mailprogramm - alle Attachments
in "Sent" mit abzuspeichern, muß doch nicht sein, oder?
>> (zu >200 Dateien)
>> Tja, manchmal kann man das aber nicht ändern - und muß sehen, wie man
>> damit zurechtkommt.
>
>So ist es... leider. Man schaue sich beispielsweise einmal die "Favoriten" und
>"Verlauf"-Ordner des IE4 an. Graus !! Mehr Speicherplatzverschwendung hat
>Microsoft wohl nicht auf die Schnelle hinbekommen.
>Da freut man sich doch gleich doppelt über sein Netscape ! :-)
Microsoft hat es sich einfach gemacht - die "Verwaltung" der
"Favoriten" übernimmt das Dateisystem (ähnlich wie beim Startmenü von
Win9x auch), während NetScape eine HTML-Datei immer mal wieder
umsortieren muß, was leider bei gewisser Komplexität oder einem
Netscape-Absturz (wie wir wissen, gab es nie ein absturzfreies
Netscape, gibt es nicht und wird es nie geben) mitunter zu deren
völligem Verschwinden führt (erlebt mit Netscape 4.01 für Win95) -
vielleicht auch ein Problem eines kleinen, aber durch das Programm
nicht behebbaren Fehlers inmitten der Datei.
Andererseits gebe ich Dir recht: Mir ist Netscape trotz gelegentlicher
Abstürze (mittlerweile "nur" noch bei Java- und sonsthin
ressorcenfessenden Seiten) lieber als der IE, aber aus einem anderen
Grund. IE liefert immer so hinreißende Meldungen wie:
Die Verbindung konnte nicht hergestellt werden. Der Server lieferte
eine unbekannte oder ungültige Rückmeldung.
(bei "We have moved to..." Seiten oder Fehlern im URL)
oder
Die Verbindung zu ... konnte nicht hergestellt werden. Der Server
lieferte erweiterte Informationen.
(Wenn der FTP-Server einen zu langen Begrüßungstext hat)
Nervt halt einfach...
Ciao
Gerd
Martin Beck
> >
> >Aaahhh ! Hilfe !
> >Ich hoffe, Dir ist das Cluster-Problem bekannt: 1000 Dateien bei einer
> >Cluster-Größe von 8 K belegen 8 Megs, bei 64 K sinds schon 64 Megs. Du
> >solltest also aufpassen, daß die Festplatte nicht voll wird.
> >
> clusterbedingte Verschnitt dürfte sich also in Grenzen halten.
>
Wenn ich hier mal anfügen darf:
Die Größe der Datei ist egal. Auch bei Dateien, die über 1 MB groß,
wird so gut wie immer der letzte Cluster nur teilweise ausgefüllt.
Die Verschwendung bleibt die gleiche, wie bei ganz kleinen Dateien.
Beispiel: 1,5 GB-Festplatte -> 32 KB Clustersize (wenn ich mich
nicht irre)
1000 Dateien, mit jeweils 1/2 Cluster am Ende:
1000*16 KB= fast 16 MBs
Martin
--
E-Mail: Spi...@t-online.de
ICQ : 16102775
Dupe that floppy -- Spread the wealth and copy (Joe Koss)
Thomas Rehm
Du schriebst am 20.01.99 zum Thema "Re: DOS und Laufwerk B:":
> > Die Dateien sind zwischen einigen 10 K und etwas 1 MB groß, der
> > clusterbedingte Verschnitt dürfte sich also in Grenzen halten.
> Offtopic
Interessante Einschätzung. Für welche Newsgroup / Gruppe / Brett
gilt dies?
> Wenn ich hier mal anfügen darf:
> Die Größe der Datei ist egal. Auch bei Dateien, die über 1 MB groß,
> wird so gut wie immer der letzte Cluster nur teilweise ausgefüllt.
Schon klar[tm]. ;-)
Aber: 100 Dateien mit 1 MB brauchen mehr Platz als 1 Datei mit
100 MB. Und zwar genau aus den von Dir erwähnten Gründen.
Thomas.