drfat32 unter drdos 7.03
Holger Schwabe
ich teste für unsere Anwendung z.Zt. ein neues DOS aus, da wir ohne "große"
Partitionen nicht mehr auskommen, es demzufolge ein DOS mit Fat32
Unterstützung sein muß.
Habe mir daher DRDOS 7.03 von ftp.lineo.com runtergeladen und dazu den
drfat32 Treiber. Nur tut unsere Anwendung leider mit dem Fat32 Laufwerk
nicht so wie sie soll:
Die verwendete Platte ist eine IBM 6.49 GB mit folgender Partitionierung:
- Primary Dos mit Fat 16 und 258.3 MB, darauf liegen DRDOS und die Anwendung
- Extended Dos der gesamte Rest, darauf sind folgende logische Laufwerke mit
FDisk eingerichtet worden:
- 2000.7 MB mit Fat16 (das ist LW D:)
- 3927.6 MB mit Fat32 (das ist LW F:)
- E: ist meine RAMDISK.
Auf D: und F: liegen identische Kopien der Daten, auf die ich wahlweise aus
meiner Anwendung den Zugriff auf eine der beiden Kopien einstellen kann.
Leider läuft der Zugriff auf das Fat32-Laufwerk viel langsamer als auf Fat16
und bestimmte Datentypen werden gar nicht dargestellt. Unter Fat16 sind
Funktionalität und Performance zufriedenstellend. Hier sind meine
Startdateien:
config.sys
=======
DEVICE=C:\DRDOS\EMM386.EXE DPMI=OFF FRAME=NONE
DEVICEHIGH=C:\DRDOS\DRFAT32.SYS
DEVICEHIGH=C:\DRDOS\VDISK.SYS 4096 256 256 /e:1 /x
DEVICE=C:\DRDOS\DPMS.EXE
DEVICE=C:\DRDOS\SETVER.EXE
rem DEVICEHIGH=C:\DRDOS\DRFAT32.SYS /f /v:1
rem DEVICEHIGH=C:\DRDOS\DRFAT32.SYS /u:128,136 /v:2
SHELL=C:\COMMAND.COM C:\ /E:512 /P
BREAK=OFF
BUFFERS=30
FILES=40
FCBS=4,4
LASTDRIVE=F
HISTORY=ON,512,ON
COUNTRY=1,,C:\DRDOS\COUNTRY.SYS
DOS=HIGH,UMB
das Laden des drfat32-Treibers habe ich an allen 3 Stellen probiert -
gleiches Ergebnis.
autoexec.bat
=========
@ECHO Off
PATH C:\DRDOS;C:\;C:\<Testprogramme>;C:\<Anwendungspfad>
VERIFY OFF
PROMPT $P$G
SET DRDOSCFG=C:\DRDOS
rem lh NWCACHE e 2048 2048 /LEND=OFF /DELAY=OFF
lh nwcache 7670 1024 /lend=on /delay=off
lh KEYB GR
lh drfat32
c:\<Pfad>\<Anwendung.exe>
Leider liegt darüber hinaus unsere ramdisk zwischen den Plattenlaufwerken,
da ja das Fat32-LW erst in der autoexec.bat gemountet wird.
Hat jemand Erfahrungen mit dem DRFAT32-Treiber und wie er noch optimiert
werden kann? Oder kennt sich jemand mit PTS-DOS von Paragon aus. Ich habe
die Version 6.8 und sie leider nicht installiert bekommen.
Hoffe auf Hilfe. Danke
Holger Schwabe
Matthias Paul
> Leider läuft der Zugriff auf das Fat32-Laufwerk viel langsamer
> als auf Fat16 und bestimmte Datentypen werden gar nicht
> dargestellt.
? Was meinst Du damit, daß bestimmte Datentypen gar nicht
dargestellt werden können? Lange Dateinamen?
FAT32 ist /grundsätzlich/ sehr viel langsamer als FAT16 oder FAT12,
das ist auch bei MS-DOS so und liegt ganz einfach am Design des
Dateisystems - die FAT-Tabellen sind halt riesengroß und müssen
ständig durchsucht werden. Die einzige Abhilfe dafür ist ein
sehr großer Cache, der diese Tabellen möglichst komplett im
Speicher hält.
Der Grund, warum FAT32 auf manchen Rechnern unter /Windows/
trotzdem schneller ist als FAT16 unter Windows, liegt darin, daß
der Cache dort auf nahezu unbegrenzten Speicher zurückgreifen kann
und auf höheren Abstraktionsebenen bestimmte Cache-Optimierungen
möglich sind, die unter DOS einfach nicht machbar sind, weil das
System dafür zu offen ist und das viel zu gefährlich wäre, wenn
eine Anwendung an DOS vorbei arbeiten würde (was unter Windows
so nicht möglich ist).
> config.sys
> =======
> DEVICEHIGH=C:\DRDOS\DRFAT32.SYS
U.U. lohnt es sich noch etwas mit den Optionen zu experimentieren,
z.B. kannst Du mit
/B allow client sided asynchronous read/write buffering
/S[:number] use CHS multi sector access in %A mode (number =
0,2,4,8,16)
noch etwas rausholen. Achtung: /B solltest Du nur verwenden, wenn
es sich um fixe Laufwerke handelt, nicht für Floppies etc.
> BUFFERS=30
Falls die Puffer aufgrund ihrer Größe nicht mehr in die HMA
geladen werden, kannst Du die ruhig etwas reduzieren.
BUFFERS=10 sollte es genauso tun, da Du ja NWCACHE einsetzt.
> FILES=40
> FCBS=4,4
> LASTDRIVE=F
> HISTORY=ON,512,ON
> COUNTRY=1,,C:\DRDOS\COUNTRY.SYS
Hier sollte 1,437,... stehen.
Ansonsten kannst Du noch FASTOPEN verwenden, z.B. FASTOPEN=4096
baut 4 KB Hash-Tabellen für schnellen wiederholten Dateizugriff
auf. FASTOPEN ist bei DR-DOS intern völlig anders realisiert
als bei MS-DOS/PC DOS. Zum einen wird deutlich weniger Speicher
pro Datei verwendet (2 Bytes anstelle von 48 Bytes). Die Zahlenangabe
steht bei DR-DOS wirklich für den Speicherplatz, nicht für die Anzahl
der Dateien. Zum anderen ist die DR-DOS FASTOPEN Implementation
nicht ganz so effizient wie die von MS-DOS/PC DOS, dafür aber
in sich konsistent und sicher.
Solltest Du FASTOPEN verwenden, empfehle ich Dir ebenfalls eine
größere Anzahl FILES, z.B. 80 oder 100, unbenutzte Einträge werden
nämlich bei DR-DOS für FASTOPEN "zweckentfremdet". Die Angabe von
FCBS ist hingegen überflüssig, da DR-DOS FCBS und FILES sowieso
dynamisch aus einem gemeinsamen Pool bedient.
Eine weitere mögliche Optimierung betrifft DEBLOCK bzw. MULTITRACK.
Probier mal DEBLOCK=FFFF in CONFIG.SYS. Das setzt die Deblocking-
Grenze auf FFFFh hoch, kann allerdings in Verbindung mit ganz wenigen,
nicht VDS-fähigen Disk-Treibern und Speichermangern zu Problemen
führen. Normalerweise ermittelt der DR-DOS-Kern während der
Initialisierung schon den richtigen Wert, aber im Zweifel kann es
nicht schaden, das mal auf FFFF zu forcieren. Wenn stabil läuft
(was in 99% der Fälle so sein dürfte), dann kannst Du es so lassen.
> autoexec.bat
> =========
> VERIFY OFF
Sehr wichtig für NWCACHE, ok. Aber auch in Verbindung mit
DRFAT32.SYS sinnvoll.
> rem lh NWCACHE e 2048 2048 /LEND=OFF /DELAY=OFF
> lh nwcache 7670 1024 /lend=on /delay=off
Wenn Du genug Speicher hast, würde ich stattdessen schreiben:
NWCACHE 7670 7670 /LEND=OFF /DELAY=5000
Du solltest NWCACHE erst nach DRFAT32 laden, sonst kann NWCACHE
keine FAT32-Laufwerke cachen. Ob das funktioniert, hängt aber
sowieso von der Version von DRFAT32.EXE ab, die Du verwendet.
Bitte schau Dir mal NWCACHE /S an. Sind da die FAT32-Laufwerke
gelistet?
> lh KEYB GR
Stattdessen:
KEYB GR /MH
> lh drfat32
LH DRFAT32 /V /M:64
Nach oben in AUTOEXEC.BAT verschieben.
> Leider liegt darüber hinaus unsere ramdisk zwischen den
> Plattenlaufwerken, da ja das Fat32-LW erst in der autoexec.bat
> gemountet wird.
Abhilfe kannst Du schaffen, indem Du die RAM-Disk erst nach
DRFAT32.EXE in AUTOEXEC.BAT lädst, z.B. mit DEVLOAD.
Eine andere Möglichkeit besteht u.U. im Einsatz von OEM DR-DOS 7.05,
allerdings nur dann, wenn Du die Rename-Funktion nicht brauchst,
die hat nämlich einen Bug. Der Vorteil dieser Version ist, daß für
FAT32 keine Zusatztreiber benötigt werden und daß sich die Zugriffe
mit NWCACHE sehr gut cachen lassen, so daß der Performance-Verlust
von FAT32 gegenüber FAT16 gering ausfällt.
Weitere Optimierungsmöglichkeiten ergeben sich durch gezieltes
Tunen der Zugriffsstrategien in Eurer Anwendung, z.B. sollte diese
Dateien, auf die häufig zugegriffen wird, von der RAM-Disk holen.
Viele kleine Dateien sollte man auch besser auf die RAM-Disk legen
und nur wenige große Dateien auf die FAT32-Laufwerken. D.h. bevor
man etwas auf dem FAT32-Laufwerk schreibt, sollte man auf der
RAM-Disk erst mal eine Zeitlang inkrementelle Änderungen sammeln,
damit sich das auch wirklich lohnt.
Viele Grüße,
Matthias
--
<mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
"Programs are poems for computers."
Holger Schwabe
"Matthias Paul" <Matthi...@post.rwth-aachen.de> schrieb im Newsbeitrag
news:ansinq$jbf$1...@nets3.rz.RWTH-Aachen.DE...
> ? Was meinst Du damit, daß bestimmte Datentypen gar nicht
> dargestellt werden können? Lange Dateinamen?
Unsere Anwendung ist ein Navigationssystem, welches in Hubschraubern
eingesetzt wird. Ein bestimmter Kartentyp, in dem besonders viele Elemente
im
untersten Zoomlevel dargestellt wird, erscheint unter FAT32 gar nicht.
>
> FAT32 ist /grundsätzlich/ sehr viel langsamer als FAT16 oder FAT12,
> das ist auch bei MS-DOS so und liegt ganz einfach am Design des
> Dateisystems - die FAT-Tabellen sind halt riesengroß und müssen
> ständig durchsucht werden. Die einzige Abhilfe dafür ist ein
> sehr großer Cache, der diese Tabellen möglichst komplett im
> Speicher hält.
...
>
> NWCACHE 7670 7670 /LEND=OFF /DELAY=5000
>
> Du solltest NWCACHE erst nach DRFAT32 laden, sonst kann NWCACHE
> keine FAT32-Laufwerke cachen. Ob das funktioniert, hängt aber
> sowieso von der Version von DRFAT32.EXE ab, die Du verwendet.
> Bitte schau Dir mal NWCACHE /S an. Sind da die FAT32-Laufwerke
> gelistet?
Leider ist das FAT32 Laufwerk hier nicht gelistet.
Ein kleines Tool eines unserer Programmierer hat eine ca. 10x geringere
Schreibgeschwindigkeit auf FAT32 als auf FAT16 ergeben - also WELTEN
dazwischen!
Der von mir eingesetzte drfat32-Treiber ist die Version 1.00 vom 18.08.00
(geladen von
www.disvr.cjb.net auf der DRDOS-Seite). Gibt es da was neueres?
>
> > lh KEYB GR
>
> Stattdessen:
>
> KEYB GR /MH
Was sagt mir das MH ?
>
> > lh drfat32
>
> LH DRFAT32 /V /M:64
>
> Nach oben in AUTOEXEC.BAT verschieben.
>
> > Leider liegt darüber hinaus unsere ramdisk zwischen den
> > Plattenlaufwerken, da ja das Fat32-LW erst in der autoexec.bat
> > gemountet wird.
>
> Abhilfe kannst Du schaffen, indem Du die RAM-Disk erst nach
> DRFAT32.EXE in AUTOEXEC.BAT lädst, z.B. mit DEVLOAD.
Danke, hat geklappt.
>
> Eine andere Möglichkeit besteht u.U. im Einsatz von OEM DR-DOS 7.05,
> allerdings nur dann, wenn Du die Rename-Funktion nicht brauchst,
> die hat nämlich einen Bug. Der Vorteil dieser Version ist, daß für
> FAT32 keine Zusatztreiber benötigt werden und daß sich die Zugriffe
> mit NWCACHE sehr gut cachen lassen, so daß der Performance-Verlust
> von FAT32 gegenüber FAT16 gering ausfällt.
Wo bekommt man die Version 7.05? Ist das eine Vollversion oder OEM oder
Beta?
Ich hatte mal gelesen, das V7.05 von ONTRACK als Betriebssoftware ihrer
Anwendungen eingesetzt wird und nicht fpür den Einsatz auf HDs vorgesehen
ist ???
>
> Weitere Optimierungsmöglichkeiten ergeben sich durch gezieltes
> Tunen der Zugriffsstrategien in Eurer Anwendung, z.B. sollte diese
> Dateien, auf die häufig zugegriffen wird, von der RAM-Disk holen.
> Viele kleine Dateien sollte man auch besser auf die RAM-Disk legen
> und nur wenige große Dateien auf die FAT32-Laufwerken. D.h. bevor
> man etwas auf dem FAT32-Laufwerk schreibt, sollte man auf der
> RAM-Disk erst mal eine Zeitlang inkrementelle Änderungen sammeln,
> damit sich das auch wirklich lohnt.
>
> Viele Grüße,
>
> Matthias
>
> --
> <mailto:Matthi...@post.rwth-aachen.de>; <mailto:mp...@drdos.org>
> http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org
>
> "Programs are poems for computers."
>
>
Viele Grüße
Holger
Markus Humm
> Erst einmal vielen Dank für die kompetente Antwort.
Der kennt sich da aus gutem Grund aus...
>
> Wo bekommt man die Version 7.05? Ist das eine Vollversion oder OEM oder
> Beta?
Das ist eine weiterentwicklung des Kernels und keine volle Version. Die
benutzt u.a. die firma Ontrack. leider hat diese Version einen kleinen
fehler: Datei umbenennen geht nicht. Das schlägt immer fehl. Ansonsten
hat die aber FAT32 Support im kernel. Leider wird das aber nicht mehr
weiterentwickelt, Lineo "ziert sich da" leider etwas. Auf e-mails wird
zwar reagiert, aber Weiterentwicklung gibt es da keine und die 7.05
Version ist eigentlich nicht offiziell.
Es gibt diese u.a. auf: http://www.elk.almnet.de/ger/download/bugfix.htm
Gruß
Markus
Matthias Paul
>> ? Was meinst Du damit, daß bestimmte Datentypen gar nicht
>> dargestellt werden können? Lange Dateinamen?
>
> Unsere Anwendung ist ein Navigationssystem, welches in Hubschraubern
> eingesetzt wird. Ein bestimmter Kartentyp, in dem besonders viele
> Elemente im untersten Zoomlevel dargestellt wird, erscheint unter
> FAT32 gar nicht.
Sorry, das ist mir immer noch nicht klar. Sind diese Dateien besonders
groß (vielleicht größer als 2 Gb?). Haben die ein bestimmtes Muster
im Dateinamen? Unter welchem Betriebssystem wurden diese Dateien
ursprünglich erzeugt (für den Fall, daß das ein Problem mit VFAT-
LFNs ist)?
Äußert sich das Problem in allen Programmen oder nur innerhalb
Eurer Anwendung? Falls nur in Eurer Anwendung, bei welcher INT 21h
API-Funktion tritt das Problem auf?
> Ein kleines Tool eines unserer Programmierer hat eine ca. 10x
> geringere Schreibgeschwindigkeit auf FAT32 als auf FAT16 ergeben -
> also WELTEN dazwischen!
Ja, das kann gut sein. Hängt natürlich von vielen Faktoren ab.
Tiefe Unterverzeichnisse oder viele Dateien pro Verzeichnis
machen die Sache extra langsam.
>> KEYB GR /MH
> Was sagt mir das MH ?
/MH weist KEYB an, sich in die HMA zu laden (das dürfte aber
sowieso schon die Default-Einstellung sein). Soll der Treiber
in UMBs geladen werden, kannst Du stattdessen /MU angeben.
Der Unterschied zwischen LH KEYB [/ML] und KEYB /MU besteht
darin, daß im ersten Fall der Treiber von der Shell (also
COMMAND.COM) in UMBs geladen wird und sich dort als klassisches
TSR installiert, im Prinzip kein Unterschied zum Laden in
den konventionellen Speicher.
Mit /MU reloziert sich der Treiber jedoch in Eigenregie in
sog. XMSUMBs. Unter der Voraussetzung, daß XMSUMBs existieren
(hängt vom Speichermanager und seiner Konfiguration ab -
unter DR-DOS EMM386 normalerweise ja, unter MS-DOS/PC DOS
HIMEM + EMM386 normalerweise nein), ist die zweite Lösung
flexibler, da der Installer des Treibers während der
Installation woanders liegen kann und sich der residente
Teil des Treiber damit in kleinere freie Lücken quetschen
läßt. Außerdem wird in diesem Fall auch das PSP verworfen
(was bei einem klassischen TSR-Load nicht möglich ist),
d.h. man spart 256 Bytes Speicherplatz ein.
Das Laden in die HMA ist mit LH sowieso nicht möglich, das
ist eine Spezialität des DR-DOS KEYB.
>> Eine andere Möglichkeit besteht u.U. im Einsatz von OEM DR-DOS 7.05,
>> allerdings nur dann, wenn Du die Rename-Funktion nicht brauchst,
>> die hat nämlich einen Bug. Der Vorteil dieser Version ist, daß für
>> FAT32 keine Zusatztreiber benötigt werden und daß sich die Zugriffe
>> mit NWCACHE sehr gut cachen lassen, so daß der Performance-Verlust
>> von FAT32 gegenüber FAT16 gering ausfällt.
> Wo bekommt man die Version 7.05? Ist das eine Vollversion oder OEM
> oder Beta?
Das ist eine OEM-Version, die LBA und FAT32 ab Haus unterstützt,
aber leider noch nicht ganz perfekt ist. (Die externe DRFAT32-Lösung
ist übrigens ebenfalls eine OEM-Version und keinesfalls Bestandteil
der Desktop-Version.)
Die aktuelle DR-DOS-Release für Desktop-Systeme ist immer noch
DR-DOS 7.03 - aber die unterstützt eben weder LBA noch FAT32.
Holger Schwabe
nochmals danke für die detaillierten Infos.
"Matthias Paul" <Matthi...@post.rwth-aachen.de> schrieb im Newsbeitrag
news:anvuom$hkg$1...@nets3.rz.RWTH-Aachen.DE...
> Am 2002-10-08 schrieb Holger Schwabe:
>
> >> ? Was meinst Du damit, daß bestimmte Datentypen gar nicht
> >> dargestellt werden können? Lange Dateinamen?
> >
> > Unsere Anwendung ist ein Navigationssystem, welches in Hubschraubern
> > eingesetzt wird. Ein bestimmter Kartentyp, in dem besonders viele
> > Elemente im untersten Zoomlevel dargestellt wird, erscheint unter
> > FAT32 gar nicht.
>
> Sorry, das ist mir immer noch nicht klar. Sind diese Dateien besonders
> groß (vielleicht größer als 2 Gb?). Haben die ein bestimmtes Muster
> im Dateinamen? Unter welchem Betriebssystem wurden diese Dateien
> ursprünglich erzeugt (für den Fall, daß das ein Problem mit VFAT-
> LFNs ist)?
>
> Äußert sich das Problem in allen Programmen oder nur innerhalb
> Eurer Anwendung? Falls nur in Eurer Anwendung, bei welcher INT 21h
> API-Funktion tritt das Problem auf?
könnte ein timeout-Problem sein. Vielleicht ist es ja behoben, wenn die
Geschwindigkeitsprobleme gelöst sind !?
> > Ein kleines Tool eines unserer Programmierer hat eine ca. 10x
> > geringere Schreibgeschwindigkeit auf FAT32 als auf FAT16 ergeben -
> > also WELTEN dazwischen!
>
> Ja, das kann gut sein. Hängt natürlich von vielen Faktoren ab.
> Tiefe Unterverzeichnisse oder viele Dateien pro Verzeichnis
> machen die Sache extra langsam.
>
> >> Eine andere Möglichkeit besteht u.U. im Einsatz von OEM DR-DOS 7.05,
> >> allerdings nur dann, wenn Du die Rename-Funktion nicht brauchst,
> >> die hat nämlich einen Bug. Der Vorteil dieser Version ist, daß für
> >> FAT32 keine Zusatztreiber benötigt werden und daß sich die Zugriffe
> >> mit NWCACHE sehr gut cachen lassen, so daß der Performance-Verlust
> >> von FAT32 gegenüber FAT16 gering ausfällt.
> > Wo bekommt man die Version 7.05? Ist das eine Vollversion oder OEM
> > oder Beta?
>
> Das ist eine OEM-Version, die LBA und FAT32 ab Haus unterstützt,
> aber leider noch nicht ganz perfekt ist. (Die externe DRFAT32-Lösung
> ist übrigens ebenfalls eine OEM-Version und keinesfalls Bestandteil
> der Desktop-Version.)
>
> Die aktuelle DR-DOS-Release für Desktop-Systeme ist immer noch
> DR-DOS 7.03 - aber die unterstützt eben weder LBA noch FAT32.
Wie ist die lizenzrechtliche Lage bei drfat32 und DR-DOS 7.05, zum
kostenlosen Download steht ja beides zur Verfügung ...
Viele Grüße
Holger
Matthias Paul
>> Sorry, das ist mir immer noch nicht klar. Sind diese Dateien
>> besonders groß (vielleicht größer als 2 Gb?). Haben die ein
>> bestimmtes Muster im Dateinamen? Unter welchem Betriebssystem
>> wurden diese Dateien ursprünglich erzeugt (für den Fall, daß
>> das ein Problem mit VFAT-LFNs ist)?
>>
>> Äußert sich das Problem in allen Programmen oder nur innerhalb
>> Eurer Anwendung? Falls nur in Eurer Anwendung, bei welcher INT 21h
>> API-Funktion tritt das Problem auf?
>
> könnte ein timeout-Problem sein. Vielleicht ist es ja behoben, wenn
> die Geschwindigkeitsprobleme gelöst sind !?
Auf keinen Fall, das Verhalten des Betriebssystems und seiner Treiber
ist deterministisch. Wenn bestimmte /Dateien/ nicht gefunden werden
(warum auch immer), dann ist das immer ein logisches, kein
physikalisches Problem. Und solche Sachen dürfen natürlich nie eine
Frage von Geschwindigkeit vom Rechner oder Festplatte, oder gar von
Lust und Laune sein. ;-)
Anders wäre es, wenn Du eine Fehlermeldung wie "Sektor not found"
oder "Timeout error" oder auch "Abort, Retry, Ignore, Fail" oder
sowas bekommen würdest. Das würde dann auf ein hardwarenahes Problem
hindeuten. Aber diese unteren Schichten von DOS und BIOS arbeiten
nicht mit /Dateien/, sondern auf einer viel niedrigeren Abstraktions-
ebene mit /Sektoren/.
D.h. wenn Du bestimmte Dateien nicht siehst, dann liegt das
normalerweise daran, daß diese Dateien das Hidden- und/oder
System-Attribut gesetzt haben. Das wäre natürlich trivial,
deshalb gehe ich mal davon aus, daß Du das schon überprüft
hast und als Ursache ausschließen kann.
Ansonsten gäbe es - unter DR-DOS - noch zwei Spezialfälle, in denen
ebenfalls kein Zugriff auf eine Datei möglich wäre:
Entweder die Datei ist gelöscht und hängt in der Löschverfolgung
von DR-DOS oder die Datei ist mit einem Paßwort und bestimmten
Zugriffsrechten geschützt.
Dateien in der Löschverfolgung solltest Du normalerweise gar nicht
sehen können (außer mit DELWATCH, DELPURGE).
Im Fall von paßwortgeschützten Dateien sind diese je nach Anwendung
sichtbar oder unsichtbar, aber ohne das richtige Paßwort kannst Du
nicht darauf zugreifen. Globale Paßwörter und Zugriffsrechte verwaltet
man mit dem PASSWORD-Utility, individuelle Paßwörter kann man auch
mit einem Semikolon (seit DR-DOS 7.02+ alternativ dazu auch zwei
Semikoli) getrennt an den jeweiligen Dateinamen anhängen, also z.B:
c:\protdir[.ext][;[;]dirpwd]\protfile[.ext][;[;]filepwd]
Das funktioniert aus jeder beliebigen DOS-Anwendung heraus, solange
die das Semikolon nicht als ungültiges Zeichen herausfiltert wird
oder die Path-Crunching-Routinen die 8.3-Regeln nicht falsch anwenden
(wie die leider in vielen RTL geschieht).
Alles andere deutet auf eine Fehlfunktion in der Software hin.
Das heißt noch lange nicht, daß es an DRFAT32 oder DR-DOS selbst
liegen muß, es kann auch an einem anderen Treiber im System liegen -
das sollten wir dann versuchen zu isolieren und zu analysieren.
Deshalb meine Fragen...
- Kannst Du diese Dateien wenigstens mit ATTRIB "sehen"?
- Sind sie mit anderen Tools sichtbar oder nie?
- Benutzt Eure Anwendung noch die alten DOS 1.x-FCB-Funktionen?
- Wo liegen diese Dateien im Verzeichnisbaum?
- Haben diese Dateien Gemeinsamkeiten im Namen, den Attributen,
oder dem Datumsstempel?
- Wurden diese Dateien unter DR-DOS geschrieben oder unter
einem anderen Betriebssystem?
- Was passiert, wenn Du diese Dateien in ein anderes, frisch
erzeugtes Verzeichnis kopierst? Kannst Du sie dann lesen?
- Habt Ihr die Systemabsicherung von DR-DOS aktiviert?
- Habt Ihr noch andere Redirektor-Software geladen? Z.B. NWCDEX,
MSCDEX, Netzwerk-Treiber?
>>> Wo bekommt man die Version 7.05? Ist das eine Vollversion oder OEM
>>> oder Beta?
>>
>> Das ist eine OEM-Version, die LBA und FAT32 ab Haus unterstützt,
>> aber leider noch nicht ganz perfekt ist. (Die externe DRFAT32-Lösung
>> ist übrigens ebenfalls eine OEM-Version und keinesfalls Bestandteil
>> der Desktop-Version.)
>>
>> Die aktuelle DR-DOS-Release für Desktop-Systeme ist immer noch
>> DR-DOS 7.03 - aber die unterstützt eben weder LBA noch FAT32.
>
> Wie ist die lizenzrechtliche Lage bei drfat32 und DR-DOS 7.05, zum
> kostenlosen Download steht ja beides zur Verfügung ...
Da ich kein Angestellter oder Sprecher von Lineo bin, versteht es
sich von selbst, daß ich dazu keine rechtlich verbindliche Auskunft
geben kann. Dafür mußt Du schon Lineo selbst fragen.
Meinem Verständnis nach handelt es sich um "Duldware", d.h. die
Versionen sind nicht offiziell für Desktop-Systeme freigegeben und
wurden nur an bestimmte OEMs verkauft, z.B. an Ontrack. Wer die
entsprechende OEM-Software legal besitzt, kann natürlich auch die
darin enthaltenen DR-DOS Dateien benutzen - der jeweilige OEM zeichnet
für die Software verantwortlich und ist Ansprechpartner bei Problemen.
Wer sich die Dateien nur aus der Evaluation Release extrahiert hat
(wie die im Web kursierenden Dateien), hat eigentlich keine gültige
Lizenz der Software.
Ich denke, daß das (zumindest im Moment) von Lineo geduldet wird,
solange es sich um private Anwender handelt, die das nur für Non-Profit-
Anwendungen einsetzen, wenn diese im Gegenzug dafür Lineo "in Ruhe"
lassen, sollten irgendwelche Probleme mit der Software auftreten.
Ich denke, das ist nur fair.
Der wie auch immer geartete Einsatz im kommerziellen Umfeld erfordert
selbstredend die entsprechende kommerzielle Lizenz. Bei einem
Navigationssystem für Hubschrauber handelt es sich mit Sicherheit
um eine kommerzielle Lösung, d.h. Ihr braucht in jedem Fall
eine Lizenz, aber das dürfte dann natürlich für Euch auch
kein Problem sein.
Das ändert aber nichts daran, daß mich als einem der Entwickler des
Betriebssystems (und auch des FAT32-Treibers) jegliche Probleme im
Umfeld von DR-DOS sehr interessieren, um ggfs. den möglichen Ursachen
auf den Grund zu gehen und ggfs. Lösungen/Workarounds/Fixe entwickeln
zu können. Von daher bin ich nach wie vor an aussagekräftigen Bug-
reporten interessiert, auch wenn das für Lineo wohl leider nicht
mehr gilt.
Holger Schwabe
"Matthias Paul" <Matthi...@post.rwth-aachen.de> schrieb im Newsbeitrag
news:aofh8e$60u$1...@nets3.rz.RWTH-Aachen.DE...
> Am 2002-10-14 schrieb Holger Schwabe:
>
> >> Sorry, das ist mir immer noch nicht klar. Sind diese Dateien
> >> besonders groß (vielleicht größer als 2 Gb?). Haben die ein
> >> bestimmtes Muster im Dateinamen? Unter welchem Betriebssystem
> >> wurden diese Dateien ursprünglich erzeugt (für den Fall, daß
> >> das ein Problem mit VFAT-LFNs ist)?
Alle Karten werden unter Windows / durch Konsolenapplikationen erzeugt,
erfüllen jedoch immer die 8+3 Regeln, Dateigrößen ca. zwischen 2 KB und 2
MB.
> >>
> >> Äußert sich das Problem in allen Programmen oder nur innerhalb
> >> Eurer Anwendung? Falls nur in Eurer Anwendung, bei welcher INT 21h
> >> API-Funktion tritt das Problem auf?
Muß ich mit unserem Systemprogrammierer klären, damit er eine DEBUG-Routine
einbaut.
Die Dateien liegen normal in einem Unterverzeichnis 3. Ordnung nach dem
Muster vectmaps\maps3\df_5, d.h. Ordner und Files erfüllen die 8+3 Regeln,
sind im Norton-Commander und im DOS normal zugänglich. Der Ordner umfaßt
etwa 1500 Dateien. Der Inhalt eines anderen Ordners mit über 10000 files
wird jedoch dargestellt. Dieser Kartentyp umfaßt zwei Ordner, also neben dem
df_5 noch ein df_u, wo die warnungssensitiven Objekte drin liegen - z.B.
Hochspannungsmasten. Diese werden dargestellt, darüber hinaus legt das
System im Gebiet dieser Karten unter FAT32 eine Denkpause ein, klappert in
der Zeit auf der Platte und bringt dann die Masten und nix weiter von diesen
Karten. Der Fall ist reproduzierbar, auch wenn ich die Daten erneut kopiere.
Es ist nix geschütztes auf dieser Partition und auf der völlig identischen
(aber viel schnelleren) Partition werden diese Karten dargestellt.
Primär ist jedoch das Geschwindigkeitsproblem, es nützt nix wenn diese
Karten mal nach 1 Minute sich aufbauen würden statt normalerweise nach
vielleicht 5 Sekunden. Bestückt werden unsere HDs unter WIN95, habe die
Karten meines Testsystems auf der FAT16-Partition zusammengestellt und dann
alles (unter WIN95, Servant Salamander) markiert und auf das FAT32 LW
kopiert.
Lineo habe ich bereits angeschrieben, die fühlen sich dafür nicht mehr
zuständig und geben keinerlei Auskünfte zu beiden Komponenten. Ist nicht
mehr unseres also hilf dir selbst...
Viele Grüße
Holger
Matthias Paul
>>>> Sorry, das ist mir immer noch nicht klar. Sind diese Dateien
>>>> besonders groß (vielleicht größer als 2 Gb?). Haben die ein
>>>> bestimmtes Muster im Dateinamen? Unter welchem Betriebssystem
>>>> wurden diese Dateien ursprünglich erzeugt (für den Fall, daß
>>>> das ein Problem mit VFAT-LFNs ist)?
> Alle Karten werden unter Windows / durch Konsolenapplikationen
> erzeugt, erfüllen jedoch immer die 8+3 Regeln, Dateigrößen ca.
> zwischen 2 KB und 2 MB.
Enthalten die Dateien auch nur Großbuchstaben A..Z und keine anderen
Sonderzeichen? Viele Leute, die Dateien unter Windows schreiben,
achten zwar darauf, daß die Namen im 8.3-Format sind, aber wenn
die Software die LFN-Funktionen benutzt (was die meisten Programme
machen, die LFNs unterstützen) und die Dateinamen dann Kleinbuchstaben
enthalten, handelt es sich faktisch immer noch um lange Dateinamen,
auch wenn sie nicht so aussehen. Nur wenn man die Dateinamen groß
schreibt, ist (zumindest theoretisch) kein LFN-Eintrag nötig.
Ich würde Euch bitten, die Dateien unter reinem DOS (egal ob MS-DOS
oder DR-DOS) zu schreiben, auf keinen Fall unter Windows, auch
nicht aus einer Windows-Konsolenanwendung heraus - das ist
schließlich auch nur eine normale 32-bit-Windows-Anwendung ohne GUI.
Sollte das nicht möglich sein, probiert folgendes Workaround:
Die Dateien unter Windows in Zwischenverzeichnis X schreiben und
danach unter reinem DOS in das Zielverzeichnis Y kopieren und die
Temporärdatei löschen (REName oder MOVE funktionieren hier nicht
wie gewünscht, also bitte COPY benutzen).
So wird sichergestellt, daß die Dateien wirklich keine LFNs enthalten.
Wenn das Problem damit gelöst sein würde, wüßten wir zumindest, woran
es liegt. Dann könnten wir im nächsten Schritt überlegen, wie man das
Problem direkt vermeidet.
> Die Dateien liegen normal in einem Unterverzeichnis 3. Ordnung nach
> dem Muster vectmaps\maps3\df_5, d.h. Ordner und Files erfüllen die
> 8+3 Regeln, sind im Norton-Commander und im DOS normal zugänglich.
Schon mal sehr gut zu wissen. Wohlgemerkt: Unter DR-DOS, nicht wahr?
> Der Ordner umfaßt etwa 1500 Dateien. Der Inhalt eines anderen Ordners
> mit über 10000 files wird jedoch dargestellt.
Das ist der Grund, warum das so langsam ist. Das müßt Ihr in
jedem Fall anders organisieren, 1.500 Dateien und erst recht
10.000 (!) Dateien in einem Verzeichnis ist absoluter Overkill
für das FAT-Dateisystem.
Wenn Du Dir die Strukturen des Dateisystems einmal vergegenwärtigst,
dürfte schnell klar sein, was das für ein riesiger Overhead erzeugt,
den hier *jeder* Zugriff auf eine solche Datei erzeugt. Und bei
FAT32 ist das noch schlimmer als bei FAT16B, erst recht ohne Cache.
(Eigentlich müßte Eure Kombination der Versionen von DRFAT32 und
NWCACHE in der Lage sein, DRFAT32-Laufwerke zu cachen. Das müßte
ich nochmal nachschauen.)
In jedem Fall: Entweder alles in eine größere Datei schreiben
(Meta-Dateisystem) oder zumindest in mehrere möglichst flache
Unterverzeichnisse verteilen.
> Dieser Kartentyp umfaßt zwei Ordner, also neben dem df_5 noch ein
> df_u, wo die warnungssensitiven Objekte drin liegen - z.B.
> Hochspannungsmasten.
Kleinbuchstaben oder Großbuchstaben?
> Diese werden dargestellt, darüber hinaus legt das System im Gebiet
> dieser Karten unter FAT32 eine Denkpause ein, klappert in der Zeit
> auf der Platte und bringt dann die Masten und nix weiter von diesen
> Karten. Der Fall ist reproduzierbar, auch wenn ich die Daten erneut
> kopiere.
> Es ist nix geschütztes auf dieser Partition und auf der
> völlig identischen (aber viel schnelleren) Partition werden diese
> Karten dargestellt.
Ok, das Problem ist, daß lange Dateinamen u.U. als gesetzter Paßwort-
Schutz fehlinterpretiert werden könnten - dafür müßt ihr Euch bei
Microsoft bedanken, die sich beim Design ihrer VFAT-LFNs wissentlich
nicht um die Kompatibilität mit sehr viel älteren DR-DOS-Features
gekümmert haben (das wäre technisch ohne Probleme möglich gewesen).
Es gibt zwar eine interne DR-DOS-Kernel-Version, die ein paar
heuristische Methoden anwendet, um dennoch ziemlich sicher solche
LFNs von paßwortgeschützten Dateien zu unterscheiden, aber DR-DOS 7.03
und 7.05 können das noch nicht. Also muß in jedem Fall verhindert
werden, daß lange Dateinamen geschrieben werden. Allerdings sollten
die betreffenden Dateien dann auch im Norton Commander nicht zu
öffnen sein. Kannst Du die betreffenden Dateien dort mit F4 öffnen,
schreiben und löschen? Falls ja, dann kann es nicht an einer Kollision
mit dem Paßwortschutz von DR-DOS liegen.
Ich habe eine Vermutung: Greift Ihr direkt auf die Datei zu (über
ihren vollständigen Namen) oder benutzt Ihr da FindFirst/FindNext-
Funktionen? Da könnte nämlich das Problem liegen, daß bestimmte
Dateien mit speziellen reservierten Attribut-Kombinationen bei
FindFirst/FindNext einfach nicht auftauchen.
> Primär ist jedoch das Geschwindigkeitsproblem, es nützt nix wenn
> diese Karten mal nach 1 Minute sich aufbauen würden statt normaler-
> weise nach vielleicht 5 Sekunden.
Klar, aber das ist - leider - ein Problem im Design oder der
Organisation Eurer Software. Das müßte aber eigentlich Euren
Entwicklern schon vorher klar gewesen sein, denn das ist ja
schließlich keine neue Erkenntnis, sondern gilt so seit den
Anfängen von DOS...
Das FAT-Dateisystem ist einfach nicht für den effizienten
Zugriff auf solche übervollen Verzeichnisse ausgelegt,
egal unter welcher Betriebssystemimplementation. Es kommt -
natürlich - damit zurecht (zumindest sollte es das), aber
es ist systembedingt extrem langsam.
Daß Du den Unterschied unter MS-DOS 7.10 (oder DR-DOS 7.05)
vielleicht nicht so drastisch bemerkst, liegt einfach daran,
daß der Cache das in gewissen Grenzen cachiert - trotzdem
bleibt es äußerst ineffizient.
> Bestückt werden
> unsere HDs unter WIN95, habe die Karten meines Testsystems auf der
> FAT16-Partition zusammengestellt und dann alles (unter WIN95, Servant
> Salamander) markiert und auf das FAT32 LW kopiert.
Mach' das besser unter reinem DOS, damit Du sicher sein kannst,
daß keine langen Dateinamen erzeugt werden.
> Lineo habe ich bereits angeschrieben, die fühlen sich dafür nicht mehr
> zuständig und geben keinerlei Auskünfte zu beiden Komponenten. Ist
> nicht mehr unseres also hilf dir selbst...
Hm, Lineo ist nach wie vor Rechtinhaber von DR-DOS. Wäre mir neu,
wenn die das jüngst verkauft haben sollten.
Kann sein, daß die keinen Support mehr anbieten (das ist sogar
wahrscheinlich - außer für Groß-OEMs), aber ohne eine *explizite*
schriftliche Erlaubnis von denen würde ich DR-DOS oder Komponenten
davon besser nicht in einer kommerziellen Lösung verwenden - für
die Evaluierungsphase ist das noch was anderes, aber später nicht...
Uwe Borchert
Matthias Paul <Matthi...@post.rwth-aachen.de> wrote:
>Am 2002-10-15 schrieb Holger Schwabe:
>
...[...]...
>> Alle Karten werden unter Windows / durch Konsolenapplikationen
>> erzeugt, erfüllen jedoch immer die 8+3 Regeln, Dateigrößen ca.
>> zwischen 2 KB und 2 MB.
>
...[Wuerg_around geloescht]...
>
>> Die Dateien liegen normal in einem Unterverzeichnis 3. Ordnung nach
>> dem Muster vectmaps\maps3\df_5, d.h. Ordner und Files erfüllen die
>> 8+3 Regeln, sind im Norton-Commander und im DOS normal zugänglich.
>
>Schon mal sehr gut zu wissen. Wohlgemerkt: Unter DR-DOS, nicht wahr?
>
>> Der Ordner umfaßt etwa 1500 Dateien. Der Inhalt eines anderen Ordners
>> mit über 10000 files wird jedoch dargestellt.
>
>Das ist der Grund, warum das so langsam ist. Das müßt Ihr in
>jedem Fall anders organisieren, 1.500 Dateien und erst recht
>10.000 (!) Dateien in einem Verzeichnis ist absoluter Overkill
>für das FAT-Dateisystem.
>
Auch bei anderen Dateisystemen kommt man da schnell an die Grenzen des
Schlafes. OS/2 HPFS wird da auch erheblich langsamer, bei ext2fs habe
ich es nie expliziet probiert, aber es wird wohl auch so sein.
>Wenn Du Dir die Strukturen des Dateisystems einmal vergegenwärtigst,
>dürfte schnell klar sein, was das für ein riesiger Overhead erzeugt,
>den hier *jeder* Zugriff auf eine solche Datei erzeugt. Und bei
>FAT32 ist das noch schlimmer als bei FAT16B, erst recht ohne Cache.
>
Hab ich nicht. Geht der Aufwand linear oder exponetiell nit der Anzahl
der Dateien? Wie kann man so was ausrechnen?
>(Eigentlich müßte Eure Kombination der Versionen von DRFAT32 und
>NWCACHE in der Lage sein, DRFAT32-Laufwerke zu cachen. Das müßte
>ich nochmal nachschauen.)
>
>In jedem Fall: Entweder alles in eine größere Datei schreiben
>(Meta-Dateisystem) oder zumindest in mehrere möglichst flache
>Unterverzeichnisse verteilen.
>
Und jetzt geht es ueber zum Programmieren! Unter IBM Groszrechnern und
DEC-VMS habe ich mal an Kuestenlinien rumgebastelt. Die Vektordaten
waren mit fixed record length in ein paar Dateien (4 fuer die gesamte
Welt) gehalten und zu jeder dieser Dateien gab es ein Indexfile. In
diesem wurden die einzelnen Polygonzuege den jeweiligen Datensaetzen
in den Datenfiles zugeordnet. Wichtig ist hierbei nur das Indexfile
zuerst komplett abzuarbeiten, alle Polygonzuege rauszusuchen und dann
die HDD (Kopf) neu auf das Datenfile zu setzen. Der Reihenfolge nach
sortiert waere das vielleicht eine sichere Garantie fuer kleine Kopf-
spruenge, das ist auch nicht unerheblich.
...[LFN Einzelheiten]...
>
>> Primär ist jedoch das Geschwindigkeitsproblem, es nützt nix wenn
>> diese Karten mal nach 1 Minute sich aufbauen würden statt normaler-
>> weise nach vielleicht 5 Sekunden.
>
>Klar, aber das ist - leider - ein Problem im Design oder der
>Organisation Eurer Software. Das müßte aber eigentlich Euren
>Entwicklern schon vorher klar gewesen sein, denn das ist ja
>schließlich keine neue Erkenntnis, sondern gilt so seit den
>Anfängen von DOS...
Aehm, ein aehnliches Problem hatte ich auch unter DEC-VMS. Hier half es
zuerst die Indexe der Datensaetze zusammenzusuchen und dann erst diese
datensaetze einzulesen. Jeden Datensatz direkt nach der Suche anzusprechen
fuehrt nur zu _Haedbangers Ball_.
>Das FAT-Dateisystem ist einfach nicht für den effizienten
>Zugriff auf solche übervollen Verzeichnisse ausgelegt,
>egal unter welcher Betriebssystemimplementation. Es kommt -
>natürlich - damit zurecht (zumindest sollte es das), aber
>es ist systembedingt extrem langsam.
>
>Daß Du den Unterschied unter MS-DOS 7.10 (oder DR-DOS 7.05)
>vielleicht nicht so drastisch bemerkst, liegt einfach daran,
>daß der Cache das in gewissen Grenzen cachiert - trotzdem
>bleibt es äußerst ineffizient.
>
Bei GIS-Anwendungen kannst Du davon ausgehen dass Du immer einen neuen
oder anderen Satz einlesen musst als Du vorher schon mal eingelesen
hast. Ich kenne die Gesamtdatenmenge nicht, aber u.U. koennte man mit
einer RAM-Disk passender Groesse die Kompletten Indizes und auch noch
einige wichtige Datensaetze halten.
...[...]...
>
>Kann sein, daß die keinen Support mehr anbieten (das ist sogar
>wahrscheinlich - außer für Groß-OEMs), aber ohne eine *explizite*
>schriftliche Erlaubnis von denen würde ich DR-DOS oder Komponenten
>davon besser nicht in einer kommerziellen Lösung verwenden - für
>die Evaluierungsphase ist das noch was anderes, aber später nicht...
>
IBM verkauft das PC-DOS noch fleissig. Es gibt auch FreeDOS. Einige
Hersteller von HW scheinen das fuer Diagnosezwecke einzusetzen.
MfG
Uwe Borchert
Holger Schwabe
wollte nur mal ein kurzes Update bzgl. meiner Bemühungen mit DRDOS liefern.
Habe heute die Version 7.05 getestet (download von
http://www.drdos.net/files/drdos705.zip; die bootfiles sind vom 26.07.00.
Ich habe sie einfach mit sys a: c: auf die bestehende Installation
übertragen.
Hier die Ergebnisse:
- mein FAT32-drive ist jetzt fast so schnell wie das FAT16-drive und wird
jetzt auch von nwcache mit gecacht.
- der Kartentyp welcher mir so viel trouble bereitet hat wird jetzt
angezeigt obgleich ich hier mit der Geschwindigkeit nicht ganz zufrieden bin
(im Gegensatz zum Rest der Daten), auch die Daten aus dem Ordner mit
11000 Objekten werden schnell genug aufgebaut !!!
- leider gibt es einige gravierende Inkonsistenzen im Filehandling unter
Version 7.05:
- bestimmte Dateien können manchmal plötzlich nicht erstellt werden,
dann habe ich die Originaldatei und eine gleichnamige (!) Datei mit 0 Byte
im Ordner
stehen,
- wenn ich 3x hintereinander eine gleichnamige Datei erstelle, wird die
alte Datei nicht etwa überschrieben sondern im Zielordner werden 3
gleichnamige
Dateien erstellt, zugreifbar ist nur die erste
- bei der Objektsuche werden die Suchergebnisse zunächst in ein
tempfile auf der Ramdisk geschrieben, mitten beim Suchen kommt es spontan
bei
unterschiedlichem Fortschritt der Suche zum Abbruch: "Error opening
<searchtempfile>". Files werden auch auf der Ramdisk mehrfach erstellt und
nicht
überschrieben, wenn ich nach Suchabbruch mir die Tempdatei auf der
Ramdisk ansehe, enthält sie die korrekten Suchergebnisse bis zum Abbruch.
Kennt jemand Abhilfe gegen die 3 letztgenannten Bugs? Der aktuelle Zustand
ist leider für uns ziemlicher "Schrott" !!
"Matthias Paul" <Matthi...@post.rwth-aachen.de> schrieb im Newsbeitrag
news:aoibjp$jb1$1...@nets3.rz.RWTH-Aachen.DE...
> Am 2002-10-15 schrieb Holger Schwabe:
>
> Enthalten die Dateien auch nur Großbuchstaben A..Z und keine anderen
> Sonderzeichen? Viele Leute, die Dateien unter Windows schreiben,
> achten zwar darauf, daß die Namen im 8.3-Format sind, aber wenn
> die Software die LFN-Funktionen benutzt (was die meisten Programme
> machen, die LFNs unterstützen) und die Dateinamen dann Kleinbuchstaben
> enthalten, handelt es sich faktisch immer noch um lange Dateinamen,
> auch wenn sie nicht so aussehen. Nur wenn man die Dateinamen groß
> schreibt, ist (zumindest theoretisch) kein LFN-Eintrag nötig.
Nur Großbuchstaben und Ziffern nach 8+3 Regel!
Leider kann die Datenstruktur nicht verändert werden, Ziel ist ja gerade;
daß unser System nur die gerade geografisch relevanten sehr kleinen Dateien
lesen muß (die Kacheln, welche rund um die aktuelle GPS / bzw.
Fensterposition liegen), so also die Kartenaufbauzeit erheblich reduziert
werden kann - also immer nur ganz wenige Sekunden unter MSDOS.
Mit den LFN's gibt es Klärungsbedarf, durch den Versuch mit DRDOS 7.05 habe
ich wohl sowieso einigen "Schrott" produziert, was eine Neubestückung
nahelegt...
Viele Grüße - in Hoffnung auf fachkundige Auskunft
Holger Schwabe
Markus Humm
Soweit mir bekannt hat die 7.05 Kernelversion eh' Probleme mit LFNs,
aber da meldet sich Matthias Paul sicher eh'.
Ansonsten: die interne Datei-Umbenennen Funktion von DR DOS 7.05 ist
total unbrauchbar. Liefert immer einen Fehlercode und macht auch nix
sinnvolles. Viele brauchen sowas z.B. für das INI-Datei Handling.
Datei auf, weitere temporäre Datei erzeugen. Benötigte Teile
rüberkopieren. Alte INI löschen. Temporäre Datei umbenennen. Nur das der
letzte Schritt beim 7.05er Kernel halt nicht klappt...
Lineo ist da ja leider auch keine Hilfe. Was die mit DR DOS momentan
treiben ist eher eine Katastrophe. Warum nicht jemanden der einfach nur
Interesse daran hat zur Weiterentwicklung authorisieren? Die jeweils
entstehenden verbesserungen kann Lineo ja dann immer noch verkaufen. SO
bliebe das besser auf dem Laufenden. bringt dem Benutzer halt nix, dass
Matthias Paul irgendwelche weiterentwickelten sachen daheim hat. Die
darf er nämlich leider nicht rausrücken. Dank Lineo!
Gruß
Markus
Kweires
Warum um den heissen Brei rumreden ?
Wer's noch nicht kapiert hat, es wird von DR-DOS keine gefixte bzw. erweiterte
Version mehr geben, DR-DOS wird "ab Palette" verkauft, die werden wohl bei dem
Umsatz mit DR-DOS keine festangestellten Programmierer sich dafuer halten.
Warum auch FAT32 ? Es gibt doch von www.sysinternals.com einen NTFSDOS Treiber,
kostet
zwar 299 $ mit r/w Zugriff, aber das ganze ist doch fuer
ein kommerzielles Projekt ?
MfG
Klaus Weires
Matthias Paul
> wollte nur mal ein kurzes Update bzgl. meiner Bemühungen mit DRDOS
> liefern. Habe heute die Version 7.05 getestet (download von
> http://www.drdos.net/files/drdos705.zip; die bootfiles sind vom
> 26.07.00. Ich habe sie einfach mit sys a: c: auf die bestehende
> Installation übertragen.
Danke für das Update.
> Hier die Ergebnisse:
> - mein FAT32-drive ist jetzt fast so schnell wie das FAT16-drive und
> wird jetzt auch von nwcache mit gecacht.
Ja, das ist nicht anders zu erwarten gewesen. Nichtsdestotrotz bleibt
es extrem ineffizient - aber wenn's reicht, mir soll's egal sein...
> - der Kartentyp welcher mir so viel trouble bereitet hat wird jetzt
> angezeigt obgleich ich hier mit der Geschwindigkeit nicht ganz
> zufrieden bin (im Gegensatz zum Rest der Daten), auch die Daten
> aus dem Ordner mit 11000 Objekten werden schnell genug aufgebaut !!!
Aha, was ist denn an diesem Kartentyp, bzw. den bezüglichen Dateien
besonders? Werden da besonders viele Dateien ständig geöffnet und
wieder geschlossen? Vielleicht hilft ein extrem großer FASTOPEN-
Wert wie FASTOPEN=10000?)
> - leider gibt es einige gravierende Inkonsistenzen im Filehandling
> unter Version 7.05:
> - bestimmte Dateien können manchmal plötzlich nicht erstellt
> werden, dann habe ich die Originaldatei und eine gleichnamige (!)
> Datei mit 0 Byte im Ordner stehen,
> - wenn ich 3x hintereinander eine gleichnamige Datei erstelle,
> wird die alte Datei nicht etwa überschrieben sondern im Zielordner
> werden 3 gleichnamige Dateien erstellt, zugreifbar ist nur die erste
Wie gesagt, leider enthält OEM DR-DOS 7.05 noch ein paar kleinere Fehler
(mit großen Auswirkungen), die es nicht für den generellen Einsatz auf
Desktop-Systemen geeignet machen. Für die spezielle OEM-Anwendung,
für die es entwickelt wurde, war das allerdings unerheblich. So ist
das halt (leider) mit OEM-Versionen, die müssen nur das können, was
von dem jeweiligen OEM gefordert wird.
(Übrigens bin ich für /diese/ Fehler nicht verantwortlich. ;-)
Ich finde diesen halbfertigen Zustand genauso unbefriedigend wie Du...)
> - bei der Objektsuche werden die Suchergebnisse zunächst in ein
> tempfile auf der Ramdisk geschrieben, mitten beim Suchen kommt es
> spontan bei unterschiedlichem Fortschritt der Suche zum Abbruch:
"Error
> opening <searchtempfile>". Files werden auch auf der Ramdisk mehrfach
> erstellt und nicht überschrieben, wenn ich nach Suchabbruch mir die
> Tempdatei auf der Ramdisk ansehe, enthält sie die korrekten
Suchergebnisse
> bis zum Abbruch.
Darauf kann ich mir im Moment keinen Reim machen. Kannst Du das bitte
noch etwas genauer ausführen? Ich gehe mal davon aus, daß die RAM-Disk
FAT16 unterstützt.
> Kennt jemand Abhilfe gegen die 3 letztgenannten Bugs?
> Der aktuelle Zustand ist leider für uns ziemlicher "Schrott" !!
Leider nein, es sei denn, Ihr würdet den Quelltext von DR-DOS 7.05
von Lineo lizensieren und z.B. mich als Entwickler dransetzen, um
die Fehler auszumerzen. Ein Workaround ohne die Quelltexte dieser
Version gibt es nicht.
Eine Alternative dazu wäre es, DRFAT32 bei Euch ans Laufen zu
bringen. Das geschilderte Verhalten, daß Du bestimmte Dateien
nicht sieht, ist in *diesem* Zusammenhang absolut untypisch,
jedenfalls höre ich davon zum ersten Mal. Deshalb würde mich
nach wie vor interessieren, wann das genau auftritt, sprich,
bei welcher API-Funktion und für welche Dateien. Dazu hast
Du leider noch nichts gesagt...
Ein Problem bleibt das Caching von Redirektor-Laufwerken,
das ist eigentlich nicht möglich, jedenfalls nicht mit einem
normalen Cache. Aber DRFAT32 hat einen speziellen Hook und
eigentlich müßte die ausgelieferte Version damit ausgestattet
sein, es kann aber sein, daß Ihr NWCACHE explizit überreden
müßt, das betreffende Laufwerk zu cachen. Es kann auch sein,
daß das nur mit einer leicht modifizierten internen Version
von NWCACHE geht, das hab ich jetzt nach all den Jahren nicht
mehr so genau im Kopf (kann das aber bei Bedarf nachschauen)...
Eine weitere Alternative dazu könnte FreeDOS sein. Das hängt
davon ab, was Ihr sonst noch braucht. FreeDOS ist bei weitem
nicht so DOS-kompatibel wie DR-DOS, aber seit einiger Zeit
unterstützt auch FreeDOS LBA und FAT32. Wenn Eure Anwendung
also auch unter FreeDOS läuft und Ihr Eure kommerzielle
Anwendung mit der GPL, unter der FreeDOS steht, in Einklang
bringen könnt, könnt Ihr das natürlich auch verwenden.