VT.entpackeArchive: =================== Stand: 30.09.95 * Bitte versuchen Sie nicht ZOOM-, DMS-Archive usw. nach DS0: * * zu entpacken. Die Disk-Struktur ist VERSCHIEDEN !!! * * Rufen Sie bitte zuerst avail flush oder VTFlush3 auf, um * * den Speicher aufzurauemen !!! * * Wenn Sie es sich leisten koennen (8Mb), dann legen Sie bitte * * das Packer-Verzeichnis im RAM: an. Das schont ihre Festplat- * * te. * * Mind. ein 68020iger darfs schon sein. * * 4-8 Mb Speicher sollten es schon sein. * * Wenn Sie die Ergebnisse in ein File sichern wollen, brauchen * * Sie Fastmem. * Neu September 95: - Entpacke MDC-Disk-Archiv (braucht XPK) Sept. 95 Fuer die notwendigen Vorbereitungen lesen Sie bitte weiter unten nach. Probleme: siehe ganz unten WICHTIGER HINWEIS !!!!! DMS1.11 u. 1.51 erkennt einige BB-Viren SELBST. Bitte schauen Sie mit einem Filemonitor in DMS nach. Aus dem VT-Entpackfenster schreibt DMS dann einen Original-BB UND NICHT den BB-Virus auf das Ziel-Medium. VT kann dann auf dem Ziel-Medium auch nur einen DOS0-BB finden. Im VT-Entpackfenster gibt aber DMS z.B. Byte Bandit aus. Bei DMS2.04 darf auch bootblock.brainfile und bootblock.library NICHT erreichbar sein. WICHTIGER HINWEIS !!!!! Einzelfile entpacken und testen: ================================ Mounten Sie die gewuenschten Ziellaufwerke. Formatieren Sie diese LWe lang Stellen sie im VT-Icon moeglichst IHRE WB-Aufloesung ein. Starten Sie VT Gehen Sie in den VT-FileRequester (Sp->File->Sp) Gehen Sie in E-Prefs Aktivieren Sie entpacke Disk- und/oder FileArchive Waehlen Sie jeweils das gewuenschte Ziellaufwerk. Es kann auch immer das gleiche LW sein. Wenn Sie allerdings viel Speicher haben, sollten Sie fuer FileArchive ein Ersatz-HD-LW waehlen, da immer mehr LHA-Archive auftauchen, die nicht auf eine DD-Disk passen. Das Ziellaufwerk darf NICHT auch die Quelle sein !!! formatiere Ziel NICHT steht in der Grundeinstellung auf aus. d.h. das Ziel wird vorher immer schnell formatiert. Falls Sie nun mehrere LHA-Archive auf EINE Disk entpacken wollen (reicht der Platz auf der Disk?), so muessen Sie das Formatieren verhindern, indem Sie den Haken setzen. Auch bei DMS-Archiven kann dies notwendig sein. Es tauchen immer wieder gesplittete DMS-Archive (ANWENDERFEIND- LICH) auf, die auf EINE Disk entpackt werden muessen, bevor ein Test moeglich ist !!!!! Aktivieren Sie CheckDisk Waehlen Sie, wie getestet werden soll (mit dem BlockKetteTest kann noch etwas gefunden werden, was mit dem Filetest nicht gefunden wer- den konnte. vgl. Denistro-Commander-Vorfall). Aus diesem Grund ent- packt der VT auch NICHT nach RAM: !!! Verlassen Sie E-Prefs Waehlen Sie mit devs das Quell-LW Aktivieren Sie durch klicken das gewuenschte Unterverzeichnis Waehlen Sie durch Klicken das gewuenschte File Klicken Sie auf Entpack Ein Shell-Fenster wird geoeffnet und der Entpackvorgang dort ange- zeigt. Bitte achten Sie in diesem Fenster auf Fehlermeldungen. Danach fuehrt VT auf dem Ziel-LW die Tests aus, die Sie angewaehlt haben. Danach koennen Sie das naechste Archiv testen. Die E-Prefs-Ein- stellungen bleiben erhalten. Wenn Sie in Prefs "Drucke alle Meldungen in File" gewaehlt haben, koennen Sie bis zu 999 Archive mitprotokollieren. Der Pfad fuer diese Files darf aber weder das Quell- noch das Ziel-LW enthalten. Also Quelle: z.B. HD0 Ziel : z.B. RAD MeldeFile : z.B. HD2:meinFile ABER NICHT HD0:meinFile oder RAD:meinFile Unterverzeichnisse entpacken und testen: ======================================== Versuchen Sie BITTE NICHT, eine ganze CD in EINEM Durchgang zu entpacken !!!!!! Oder doch ??? Gehen Sie in Prefs Seite 2 (NICHT in Eprefs) und nehmen Sie ihre Einstellungen vor (Wohin, Was, mit "Drucke" in File usw.). Gehen Sie in den Filerequester und waehlen Sie das gewuenschte Unterver- zeichnis der CD. (Die Meldung zuviele Eintraege ist nicht wichtig) Klicken Sie auf DirFTest. Sie koennen jetzt schlafen gehen, wenn es das Unterverzeichnis Files (enthaelt alle DMS- oder LHA-gepackte Files einer CD) ist. Bei aktivem DiskArchive-Gadget werden entpackt: DMS, Zoom, CrunchDisk, XDisk, PackDev, PackDisk, S-Pack, LHWarp, XMASH (.XMS) Probleme siehe unten, Warp (.WRP) Probleme siehe unten Bei aktivem FileArchive-Gadget werden entpackt: Lha, lha.run (z.B. AmigaPlus-Disk), AmiPack-X (AmigaMagazinDisk), xpk-Nuke (u.a.), DMS.SFX (nur DMSPro), DMS.FMS, LhArc-Archive (.LZH) mit LHA, LZ-Archive (.lzh) mit LHA, Shrink-Archive (.shr), Zip-Archive (.zip) mit UnZip, dimpl (2 Var.), ARC (.ARC sehr alt, aber es sind auf vielen CDs solche Archive), LZX (.LZX), Hinweise: Die Return-Aufforderungen koennen Sie in der Regel vergessen. Warten Sie einen Moment, dann sollte das Fenster schliessen. Einige Packer verlangen eine Handeingabe im Shell-Fenster. - z.B. AmiPack-X im Fehlerfall Abbruch j VORSICHT !!!! AmiPack-X steigt manchmal auf A4000/40 voellig unmotiviert mit "User Break" aus. Diesen Abbruch bekommen Sie NICHT mit, wenn Sie AmiPack-X ueber Icon starten. Sie koennen das nur nachvollziehen, wenn Sie AmiPack-X in einem Shell-Fenster starten. Es ist KEIN VT-Fehler. Geben Sie endcli Return ein, dann testet VT weiter. Aus diesem Grund werden AmiPack-X Files bei der Einstellung in Prefs "... OHNE Halt" NICHT entpackt. Meldung: "Hier nicht moeglich". Sollten Sie in Prefs "..ALLES aktiv" ge- waehlt haben, so werden die Files entpackt, da Sie ja an der Maschine sitzen und reagieren koennen. - dimp bei einer Variante y - LHWarp: der geforderte DiskChange wird von VT uebernommen. - XMash V1.0 BRAUCHT die Returntaste - Warp V1.11 BRAUCHT die Returntaste. Nach dem Entpacken kommt eine Fehlermeldung. Diese koennen Sie uebergehen. Sie MUESSEN aber endcli eingeben, damit VT weitertestet. Dieser Fehler kommt NICHT von VT, sondern kann von Ihnen mit execute ram:xx nachvoll- zogen werden. xx sollte enthalten: warp write ram:test.WRP (return) . - LHA.run manchmal die A- und Return-Taste. Es sind LHA.run-Files aufgetaucht, die einen Text ausgeben und dann die RETURN-Taste brauchen. Aus diesem Grund werden diese Files bei der Einstellung in Prefs "... OHNE Halt" NICHT entpackt. Meldung: "Hier nicht moeglich". Sollten Sie in Prefs "..ALLES aktiv" ge- waehlt haben, so werden die Files entpackt, da Sie ja an der Maschine sitzen und reagieren koennen. Vorbereitungen: --------------- Im C-Verzeichnis muessen bei aelteren KS-Versionen die Befehle run, format, endcli und DiskChange vorhanden sein. Im Devs-Verzeichnis: diskspare.device (V3.0 Laenge:5928 Quelle: neuere Time oder SAARAG) FMS.device (V1.0 Laenge:4424 Quelle: Getit-Disk-Mag) (Hinweis: entfernen Sie bitte mit PP die Debug-Hunks) (Diese veraenderte Version duerfen Sie aber NICHT weitergeben!!!!) ramdrive.device (Laenge:2128 bei neueren KS im ROM) statram.device (V3.1 Laenge:2480 Quelle:FF-CD7) Falls notwendig eine Erweiterung der mountlist fuer KS1.3 . Aber statram und diskspare laufen erst ab KS2.04 Im Storage-Verzeichnis: /* 1968 kB disk mount entry */ /* DS0 als Ersatz fuer DF0: erkennt DD- und HD-Disks selbststaendig) */ /* Mind. KS2.04 */ Device = diskspare.device Mount = 1 Unit = 0 Flags = 7 /* enable HD */ Surfaces = 2 BlockSize = 512 BlocksPerTrack = 12 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 81 Buffers = 50 BufMemType = 0 StackSize = 600 Priority = 10 GlobVec = -1 DosType = 0x444F5301 /* Mountlist entry for FF0 Unit 0 DD-Ersatz auch KS1.3*/ Device = fmsdisk.device Unit = 0 mount = 1 Flags = 1 Surfaces = 2 BlocksPerTrack = 11 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 79 Buffers = 2 BufMemType = 0 DosType = 0x444F5300 /* Mountlist entry for FFH Unit 1 HD-Ersatz*/ Device = fmsdisk.device Unit = 1 mount = 1 Flags = 1 Surfaces = 2 BlocksPerTrack = 22 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 79 Buffers = 2 BufMemType = 0 DosType = 0x444F5301 /* Mountlist entry for FH2 Unit 2 4xDD-Disk*/ Device = fmsdisk.device Unit = 2 mount = 1 Flags = 1 Surfaces = 2 BlocksPerTrack = 22 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 159 /* Platz 4xDD-Disk */ Buffers = 2 BufMemType = 0 DosType = 0x444F5301 /* Mountlist entry for FH3 Unit 3 6xDD-Disk*/ Device = fmsdisk.device Unit = 3 mount = 1 Flags = 1 Surfaces = 2 BlocksPerTrack = 22 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 239 /* Platz 6xDD-Disk */ Buffers = 2 BufMemType = 0 DosType = 0x444F5301 /* Mountlist for RAD Unit 0 DD-Ersatz auch KS1.3*/ Device = ramdrive.device Unit = 0 mount = 1 Flags = 0 Surfaces = 2 BlocksPerTrack = 11 BlockSize = 512 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 79 Buffers = 5 BufMemType = 1 /* Mountlist for RHD Unit 1 HD-Ersatz */ Device = ramdrive.device Unit = 1 mount = 1 Flags = 0 Surfaces = 2 BlocksPerTrack = 22 BlockSize = 512 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 79 Buffers = 5 BufMemType = 1 /* Mountlist for RH2 Unit 2 HD-Ersatz * da sehr viele lha-Archive auf CDs gerade nicht auf eine HD-Disk * passen, kann eine 3xDD-Disk vom Platz hier angewaehlt werden. * 8 Mb Speicher sollten Sie dann aber schon haben. */ Device = ramdrive.device Unit = 2 mount = 1 Flags = 0 Surfaces = 2 BlocksPerTrack = 22 BlockSize = 512 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 119 /* Platz 3xDD-Disk */ Buffers = 5 BufMemType = 1 /* Mountlist for RH3 Unit 3 HD-Ersatz */ Device = ramdrive.device Unit = 3 mount = 1 Flags = 0 Surfaces = 2 BlocksPerTrack = 22 BlockSize = 512 Reserved = 2 Interleave = 0 LowCyl = 0 HighCyl = 239 /* Platz 6xDD-Disk */ Buffers = 5 BufMemType = 1 /* $VER: SD0 37.2 (29.1.94) Unit 0 DD-Ersatz mind. KS2.04 */ Device = statram.device Flags = 0 Surfaces = 2 Reserved = 2 Interleave = 0 LowCyl = 0 Buffers = 5 StackSize = 600 Priority = 5 Mount = 1 /* The Unit, BlocksPerTrack, HighCyl, BufMemType and DosType fields are * controlled by tooltypes in the icon. * * Unit = 0 * BlocksPerTrack = 11 * HighCyl = 79 * BufMemType = 1 * DosType = 0x444F5300 */ /* $VER: SHD 37.2 (29.1.94) Unit 1 HD-Ersatz mind. KS2.04 */ Device = statram.device Flags = 0 Surfaces = 2 Reserved = 2 Interleave = 0 LowCyl = 0 Buffers = 5 StackSize = 600 Priority = 5 Mount = 1 /* The Unit, BlocksPerTrack, HighCyl, BufMemType and DosType fields are * controlled by tooltypes in the icon. * * Unit = 1 * BlocksPerTrack = 22 * HighCyl = 79 * BufMemType = 1 * DosType = 0x444F5300 */ /* $VER: SH2 37.2 (29.1.94) Unit 2 4xDD-Disk mind. KS2.04 */ Device = statram.device Flags = 0 Surfaces = 2 Reserved = 2 Interleave = 0 LowCyl = 0 Buffers = 5 StackSize = 600 Priority = 5 Mount = 1 /* The Unit, BlocksPerTrack, HighCyl, BufMemType and DosType fields are * controlled by tooltypes in the icon. * * Unit = 2 ;MUSS in Icon eingetragen werden * BlocksPerTrack = 22 * HighCyl = 159 * BufMemType = 1 * DosType = 0x444F5301 */ /* $VER: SH3 37.2 (29.1.94) Unit 3 6xDD-Disk mind. KS2.04 */ Device = statram.device Flags = 0 Surfaces = 2 Reserved = 2 Interleave = 0 LowCyl = 0 Buffers = 5 StackSize = 600 Priority = 5 Mount = 1 /* The Unit, BlocksPerTrack, HighCyl, BufMemType and DosType fields are * controlled by tooltypes in the icon. * * Unit = 3 ;MUSS in Icon eingetragen werden * BlocksPerTrack = 22 * HighCyl = 239 * BufMemType = 1 * DosType = 0x444F5301 */ Im libs-Verzeichnis: XPKmaster.library (V2.4 Laenge: 13456 Quelle: Aminet-CD oder FF-CD) Sie muessen in Libs: noch ein Unterverzeichnis Compressors anlegen und dahinein z.B. xpkNUKE.library kopieren. Einige dieser Libs werden schon im xpk-Archiv mitgeliefert. Andere wurden einzeln veroeffentlich (z.B. xpkRAKE FF-CD7). Diese Libs brauchen mind. KS2.04) In s/startup-sequence Tragen Sie bitte ein: assign >NIL: PACKER: HD1:Packer ;(oder wie Ihre Festplatte heisst) assign >NIL: FMS: HD3:FMS ;FF0 und FHD ;das Unterverzeichnis muss existieren ;in diesem Unterverzeichnis legt fmsdisk.device dann ;den disk-Ersatz Unit 0 und Unit 1 an. Sie brauchen ;also auf Ihrer Festplatte noch 3 Mb Platz ;bitte klicken Sie in Storage auf beide Icons und ;formatieren Sie die Units einmal LANG !!! Im Packer-Verzeichnis: Warum VT ein eigenes Packer-Verzeichnis fordert? Weil einige Viren (vgl. z.B. Viewtek) im c-Verzeichnis nach Packern suchen und diese ge- zielt verseuchen. Wenn Sie diese Massnahme nicht einsehen moegen, dann verwenden Sie bitte ein anderes AntiVirusProgramm Ihrer Wahl. AmiPack-x (V1.0 Laenge:19716 Quelle:Amiga-Magazin-Disk Hinweis: entpacken Sie das File und entfernen Sie mit Powerpacker/Hunklab die Debug-Hunks) VORSICHT !!!! AmiPack-X steigt manchmal auf A4000/40 voellig unmotiviert mit "User Break" aus. Diesen Abbruch bekommen Sie NICHT mit, wenn Sie AmiPack-X ueber Icon starten. Sie koennen das nur nachvollziehen, wenn Sie AmiPack-X in einem Shell-Fenster starten. Es ist KEIN VT-Fehler. Geben Sie endcli Return ein, dann testet VT weiter. Hinweis: AmiPack-gepackte Archive (bis Mitte 93 verwendet) koennen mit AmiPack-X NICHT entpackt werden. ARC (V0.23 Laenge: 50328 sehr alt, aber man findet immer wieder diese Archive. Quelle: FF-Disk70 ) CrunchDisk (V1.3 Laenge:20300 braucht xpkmaster.lib und/oder power- packer.lib. Mind. Ks2.04 Quelle: Diskspare3-Archiv z.B. neuere Time-Disk (ueber300) DMS (V1.51Turbo Laenge:83876 Quelle: ????? Sie brauchen diese Version um DMS-MaPuS zu entpacken !!! Falls Sie diese Version nicht finden, koennen Sie auch DMS111 von FF-CD nehmen.). DMS111 MUSS dann DMS genannt werden !!! DMS111 Wird gebraucht fuer Archive, die mit Ver. kleiner als DMS1.11 gepackt wurden. DMS1.51 versagt hier. z.B. Archiv auf Auge 56 . DMS MUSS dann DMS111 genannt werden !!! Laenge: 53576 DMSPRO (V2.04 Laenge:96284 Quelle: ????? Falls Sie diese Version nicht finden, koennen Sie zur Not auch undms von 17BITD-CD nehmen, aber Sie erhalten keine Ausgabe im Entpackfenster. Das File MUSS den Namen DMSPRO haben !!! Meiden Sie DMS-FMS und DMS-run (DMSPro2.04). Ich kann auf A4000/40/Warp mit diesen Optionen beim Packen und Ent- packen IMMER einen Total-Absturz (also mit HD-Validate) erzeugen !!! DMSPRO V2.04 IMMER sofort GURU 3 auf 68000 . 68030 geht. Loesungsansaetze fuer 68000 s.o. DMSPRO V2.02 ist fuer VT NICHT geeignet, da immer ein Return erwartet wird. Sie koennen auch DMS111 noch einmal als DMSPRO in Packer ablegen. Nachteil: Sie verlieren die HD-Disk-Funktion. Auf CDs habe ich aber bis Maerz95 noch keine HD-DMS-Archive gefunden. Bitte aendern Sie das Schreib-Bit auf NICHT-Write . Dimp (Diskimploder .dmp und .dex V2.27 Laenge:18596 Quelle: Imploder4-Archiv auf FF-CD) LHA (V1.38e Laenge: 53592 Quelle: FF-CD) Hinweis: Ersetzen Sie bitte Lha NICHT durch LX103. Auf Aminet4-CD sind mehrere Files, bei denen LX mit Level-2- Error aussteigt. (Diese Fehlermoeglichkeit steht aber so auch in den LX-Docs). LhArc (NICHT notwendig, macht LHA ) LHWarp (V1.40 Laenge:47880 Quelle:FF-CD7 . Bitte verwenden Sie keine aelteren Versionen. Beispiel V1.03 = sofort GURU auf A4000/40 mit und ohne Cache) LZ (NICHT notwendig, macht LHA ) LZX (V1.20 68000EC Laenge:67012 68040 Laenge: 64716 Quelle: vermutlich Aminet oder FF MDC (V1.43 MDC.000 Laenge:10432 Bytes) braucht xpkmaster.lib und natuerlich die compr. PackDev V1.4 Laenge 23384 . Entfernen Sie bitte V1.1, da damit V1.2-gepackte Archive NICHT entpackt werden koennen. Das Teil braucht eine y-Taste. PackDisk (V1.1 Laenge: 10504 braucht xpkmaster.lib Quelle: FF-CD) S-Pack (V1.1 Laenge: 28012 Quelle: FF-CD) Shrink (V1.1 Laenge: 38888 Quelle: ????) UnZip (es MUSS mind. V5.1 7.Feb.94 sein, da aeltere Versionen NICHT in ein anderes Verzeichnis entpacken koennen !!!! Laenge: 85900 Quelle: Aminet-CD 4 ) WARP (V1.11 Laenge: 22728 Quelle: Time-PD NUR DF0: weitere Probleme siehe unten) XDisk (V1.2 Laenge: 10252 braucht xpkmaster.lib und mind. KS2.04 Quelle: AmigaPlus-Disk 9/92) xlin (V1.0 Laenge: 48256 Quelle: FF-CD10 XMash (V1.0 Laenge: 24288 Quelle 17BIT-CD Probleme siehe unten) Xpackit (V1.6 Laenge: 5676 Quelle ?? braucht xpkmaster.lib) ZAP (V1.40 Laenge: 6684 Quelle Time-PD Ziel NUR DF0: weitere Probleme siehe unten) ZOO (V2.10 Laenge: 52716 91/07/09 Es scheint verschiedene Laengen mit aehnlichem Datum zu geben. Quelle: dt.Edition-CD ) Lesen Sie bitte auch Probleme mit ZOO (unten). Zoom (V5.4 Laenge: 82180 Quelle: FF-CD oder Aminet-CD) Zoom4 (V4.2 Laenge: 61300 Quelle: ???? oder V4.1 Laenge: 55200 Quelle: Auge55 auf CD. Eine dieser Versionen brauchen Sie fuer aeltere Zoom-Archive z.B. Archiv auf Auge 55 ) . Bitte benennen Sie die Files genau so wie es vorgegeben ist, sonst findet VT die Packer nicht. Biite packen Sie die Packer NICHT (AUCH NICHT mit pploadseg !!!!). Das kostet Zeit und was viel schlimmer sein kann bei Speichermangel, auch noch Entpackspeicher. Diese Files sind sehr gefaehrdet. Bilden Sie deshalb in diesem Unter- verzeichnis Pruefsummen (wie das mit VT geht, steht in VT.Prefs) UND ueberpruefen Sie bitte diese Pruefsummen AUCH REGELMAESSIG (wie das geht, steht in VT.Prefs). Danke Probleme: --------- - Sie kommen nicht an die verschiedenen Packer-Versionen heran. Wenden Sie sich an einen PD-Haendler, vielleicht stellt er bei ent- sprechender Nachfrage eine Disk zusammen. - Sie haben weniger als 8Mb Speicher Entpacken Sie nach DF0:, oder immer in die RAD: , d.h. verzichten Sie auf RHD: Sie haben eine Festplatte? Dann sollten Sie ueberlegen, ob Sie 3Mb fuer das fms.device (FF0: und FHD:) bereitstellen. - Warum zwei verschiedene Ziellaufwerke fuer Disk- und FileArchive Sie koennen auch immer das gleiche LW waehlen, aber leider hat sich gezeigt, dass viele LHA- und auch AmiPack-X-Archive NICHT MEHR auf ein 1760-Block-LW (=DD) passen. - Fehlermeldungen im Execute-Shell-Fenster Ich habe KEINE Moeglichkeit gefunden, Fehlermeldungen (disk full) aus diesem Fenster abzufragen und VT gibt "Fertig entpackt" aus obwohl lha abgebrochen hat aus Platzmangel. Deshalb wurde auch die Wahl eines 3520-Block-LWs (=HD) ermoeglicht. Falls jemand eine Loesung fuer die Fehlerabfrage kennt, waere ich fuer einen Tip SEHR DANKBAR. Nachtrag: es gibt jetzt in VTPrefs-Seite2 ein Gadget, mit dem man bei File-Entpackfehlern 10 u. 20 das Fenster anhalten kann. Um weiter zu testen, muessen Sie dann allderdings von Hand endcli ein- geben. - Graphikkarten Bitte stellen Sie im VT-Icon Ihre WB-Aufloesung ein. Sie vermeiden dadurch das nervige Umschalten der Graphikausgabe beim Oeffnen der Entpack-Shell. - nichtentpackbare Archive Es scheint sich immer noch nicht herumgesprochen zu haben, dass manche Entpacker (z.B. lha usw.) im Pfad und/oder im Filenamen keine Leerzeichen vertragen. Bei LHA helfen leider auch keine An- fuehrungszeichen, sonst haette ich die schon eingebaut. Beispiel: FF-Fonts-CD:BBS/Fonts/Adobe/San Diego.lha ^ Versuchen Sie das einmal in der Commodore-Shell mit vollem Pfad in die RAM: zu entpacken. Auf anderen CDs finden Sie dafuer Unterver- zeichnisnamen mit Sonder- und/oder Leerzeichen. Echt stark !!! - VT findet die RAD: nicht Verlassen Sie VT und formatieren Sie ihre RAD: lang . VT sucht beim Start nur nach einer Amiga-DOS-RAD:. Wenn Sie von der 17BIT-CD eine Spiele-Disk auf die RAD: entpacken, so kann durchaus eine NDOS-RAD: entstehen. Ich kenne sogar zwei Faelle, bei denen nach dem Entpacken das RAD:-Icon KOMPLETT verschwunden ist. Habe ich vorher noch nie erlebt. Die Rad: musste in der Shell neu formatiert werden, da ja kein Icon mehr da war. Eine andere PD-Serie lagert aus dem Disk-Icon ein anderes Icon aus. Dadurch haengt ein Lock. Ein Exclusive-Lock ist also nicht mehr moeglich. Die Sache glauben Sie nicht, dann entpacken Sie eine Disk dieser Serie in die RAD: und kontrollieren Sie danach die Locks mit ARTM oder Xoper. Diese Beispiele stoeren VT NUR beim Start. Spaeter kann bei Tests mit VT durchaus eine NDOS-Rad: entstehen und es kann weiter getestet werden. - Rechtliche Probleme: XDisk gehoert AmigaPlus. Sie muessten sich also erst die Erlaubnis einholen, um das Teil auf eine PD-Disk zu kopieren. Ob die "Weiterentwicklung" von DMS111 nach DMS1.51 bis DMSPRO 2.04 erlaubt ist, darueber wurde in den Netzen viel gestritten. Ich haette das Entpacken von DMS-Files weglassen koennen, aber es hat sich gezeigt, dass die Entpackroutine in VT dann "wertlos" ge- worden waere, da halt auf vielen CDs und in vielen BBS DMS-Files auftauchen, die mit DMS111 NICHT zu entpacken sind. Ich versuche mich aus der Sache zu schleichen, indem ich KEINE Packer auf die VT-Disk kopiere !!!!!!! - DMS Durcheinander: Es werden unzaehlige Versions-Nummern weitergereicht. Viele davon sind Fakes oder gar mit einem Virusteil verseucht. Bitte verwenden Sie die Versionsnummern und Filelaengen, die ich angegeben habe. Damit entpackt der VT. Sie wollen sich einmal richtig aergern. Dann nehmen Sie die EuroScene-CD. Da finden Sie Files mit der internen Kennung DMS, entpacken koennen Sie die Files aber nur mit DMSPro. DMSPro schreibt aber beim Packen die interne Kennung DMSPro. Wie sind diese Files aber dann entstan- den. Oder Sie finden halbe Disketten mit der Kennung A u. B . Sie muessen erst BEIDE DMS-Files auf EINE Disk entpacken, bevor Sie Tests durchfuehren koennen. Damit die Sache aber nicht zu einfach wird, gibt es selbstverstaendlich DMS-Files mit der Kennung A u. B, die aber auf ZWEI VERSCHIEDENE Disks entpackt werden muessen. Was DMS-Files mit halben Disks bringen sollen. Keine Ahnung !!! Dann finden Sie wieder DMSMaPuS-Files. Die koennen Sie nun wieder mit DMSPro nicht entpacken. Fuer diese Files brauchen Sie nun das alte DMS. DMS-FMS und DMS-SFX (von DMSPro) erzeugen auf meinen A4000/40/Warp beim Entpacken nur TOTAL-Abstuerze !!!! Nachtrag 03.02.95: DMSPRO V2.04 zeigt auf 68000 sofort GURU 3. Mit 68030 geht es. - Probleme mit AmiPack-X: VORSICHT !!!! AmiPack-X steigt manchmal auf A4000/40 voellig unmotiviert mit "User Break" aus. Diesen Abbruch bekommen Sie NICHT mit, wenn Sie AmiPack-X ueber Icon starten. Sie koennen das nur nachvollziehen, wenn Sie AmiPack-X in einem Shell-Fenster starten. Es ist KEIN VT-Fehler. Geben Sie endcli Return ein, dann testet VT weiter. - Probleme mit lha: Es sind inzwischen einige Files bekannt, die erst mit join zu- sammengesetzt werden muessen. LHA meldet beim Entpacken von z.B. part1 am Ende einen Fehler. - Probleme mit lha.run (LHA.SFX) Es sind inzwischen einige Archive bekannt, die auf 68030 und 68040 immer mit GURU5 enden. Das hat nichts mit VT zu tun. GURU5 sehen Sie auch wenn Sie einen Entpackversuch aus der shell starten. Beispiel: CAM2/871-Telecomm/MaxsDoorsII/MaxsDoorsII.run - Probleme mit XMash: Das Teil meldet sich mit: The Ultimate Disk Cruncher 1994 LSD Aber: Das Teil ist NICHT in der Lage in die RAD: zu entpacken, da bei neueren KS dieses Device im ROM liegt. Das Teil packt HD-Disks, aber halt falsch UND ohne Fehlermeldung. Es werden pro Zylinder IMMER 11264 Bytes gesichert. Ein HD-Zylinder hat aber nicht 22 Blocks sondern 44. Bemerkbar macht sich das aber erst beim Entpacken. Meine Empfehlung: meiden Sie dieses Tool. VT kann deshalb bei XMash nur mit den LWen DF0:, DF1:, DF2:, FF0: und SD0: arbeiten UND es ist im Execute-Fenster die Return-Taste fuer den Start notwendig !!!! Ich habe derart gepackte Disketten bis jetzt in keiner Serie gefunden. - Probleme mit WARP V1.11: Dieses Teil kann nur nach DF0: entpacken. HD-Disks werden FALSCH be- handelt. Meiden Sie das Teil. Im Execute-Fenster werden die Return- Taste und nach dem Entpacken endcli gebraucht. Ich habe derart ge- packte Disketten bis jetzt in keiner Serie gefunden. - Probleme mit ZAP V1.40: Dieses Teil kann nur nach DF0: entpacken. HD-Disks werden FALSCH be- handelt. Meiden Sie das Teil. Dieses Teil bricht mit einem 68040 das Entpacken ab. Mit einer GVP-30iger-Karte im A2000 entpackt das Teil. Im Execute-Fenster wird am Schluss ein Fehler 168 ausgegeben. Diese Meldung koennen Sie ueberlesen. VT schliesst das Fenster selbst. Die anschliessenden Tests sollten gelingen. Ich habe derart gepackte Disketten in keiner Serie gefunden. - Auch bei einigen Disk-Archiven wird das Ziel zuerst formatiert (z.B. DMS). Dies ist NICHT nutzlos, sondern vermeidet haeufig bei DMS-Ab- bruch (Data corrupt usw.) einen Filetest, da der Root-Block von DMS noch nicht erreicht wurde. - Probleme mit ZOO: Leider wurden einige defekte Zoo-Archive gefunden vgl. z.B. CD-AmigaPlus/FF767 . Es kann zu einem Endlosloop fuehren. Deshalb wurde im Einzelfilemodus (VT-FileReq.) das Entpackfenster bei ZOO-Archiven aktiviert. Vorteil: Sie koennen mit Ctrl-C abbrechen. Nachteil: Sie muessen nach dem Entpacken IMMER endcli eingeben. Beim FileTestLoop ist dies NICHT moeglich. Falls es weitere Probleme gibt, rufen Sie an oder schreiben Sie mir. Fehlermeldungen: ================ - von Packer erzeugt (z.B. lha): Auf FF-CDs (aber auch anderen CDs !!!!) sind VIELE lha-Files, die GERADE NICHT auf eine DD- oder HD-Disk passen. Es handelt sich IMMER um 1 File fuer das der Platz fehlt !!!! Dies ist fuer den Normalverbraucher WENIG hilfreich. Es handelt sich NICHT um einen VT-Fehler. Sie koennen das selbst nach- vollziehen, indem Sie mit lha einen Entpackversuch unternehmen. z.B. FishGold2/2:BBS/GNU/ixemul-40.4-env-bin.lha . Das Teil bekommen Sie auf keine HD-Disk VOLLSTAENDIG entpackt. - nach dem Entpacken beim Test: files/1019.dms D-Masher >> Nicht-Standard-BB >>RAD: Root LEER ?? files/1026.dms D-Masher >> Nicht-Standard-BB >> keine Dos-Disk Disk-Archiv: Wenn es sich um ein Disk-Archiv (z.B. DMS) gehandelt hat, muss das nicht unbedingt ein Fehler sein. Es koennte sich um ein Intro handeln, das nur bis Zyl. 39 geht. Bitte entpacken Sie das Teil noch einmal von Hand. File-Archiv: Es hat sich um ein File-Archive gehandelt. Dann ist etwas schief ge- gangen. Kontrollieren Sie bitte das File UNBEDINGT nach. Fehler tritt z.B. auf mit LX103 Level-2-Error (steht aber auch in den Docs). files/117.dms D-Masher >> DOS0-OFS-BB ;= normaler DOS0 BB >> keine Dos-Disk Kommt vorher aber noch die Ausgabe "normaler DOS-BB", dann wird es sich um einen Fehler handeln. Wie soll man auf so einer Disk etwas laden, wenn das Inhaltsverzeichnis leer ist. Entpacken Sie bitte das Archiv noch einmal von Hand. >> DOS0-OFS-BB >> Bitmap ungueltig Diese Disk muessen Sie unbedingt nachkontrollieren. Probieren Sie VT-Rootblock . >>RAD:!ANC!ANC!ANC! >> LeseSchutzBit VT versucht nach dem Entpacken zuerst selbst ein File lesbar zu machen. Falls dies nicht gelingt, erzeugt VT diese Ausgabe. Sie muessen die Disk nachkontrollieren. >>RAD: zuviele SubDirs In sehr fruehen Zeiten, gab es auf dem Amiga die Unsitte der End- los-Dirs. Meist hatten diese Teile einen Zeiger auf sich selbst. Ein Dir-Befehl bei alten KS-Versionen hat also das Unterverzeichnis immer wieder aufgerufen. So ein Teil glaubt VT gefunden zu haben. Entpacken Sie die Disk von Hand und versuchen Sie das entsprechende Unterverzeichnis mit einem Dir-Utility (SID) zu loeschen. >>RAD: EndlosDir andere Variante auf CD in DMS-Archiv gefunden z.B.: 0000: 00000002 00000381 00000000 00000000 ................ ;........ 01f0: 00000381 00000370 00000000 00000002 .......p........ Der Hash-Zeiger $1f0 zeigt auf sich selbst $4 . Copy DF0: DF1: all begibt sich mit KS3.1 in eine Endlosschleife. Setzen Sie bitte mit einem Filemonitor $1f0 auf $0. Vergessen Sie bitte nicht die Block- checksum neu zu berechnen. >> DOS0-OFS-BB >>RAD:N{DLT.DAT >>bad BloCheckSum Bei DOS0/2/4 wird ueber den Datablock eine Pruefsumme gebildet. Eine Nachbesserung ist hier vertretbar (.txt), da es sich um ein Textfile handelt. Durch Aufruf des Files mit ED koennen Sie leicht nachpruefen, ob der Block nur Muell enthaelt. Bei Bedarf schneiden Sie den Muell mit ED aus und sichern den Rest. ABER !!!!! Wenn es sich um ein Prg-File handelt, wie wollen Sie dann entscheiden, ob der Block guten Prg-Code oder Muell enthaelt. Gehen Sie lieber auf sicher und besorgen Sie sich das Diskarchiv NEU !!!! >>RAD:times.dat >> bad HEADERKEY Ein Zeiger im Fileheader stimmt nicht. Meist koennen Sie den Fehler beheben, indem Sie mit EINZEL-FileCopy alle File kopieren. Also Copy DF0: RAD: all und danach wieder zurueck. Sollte dieser Fehler mehr als 5x auf EINER Disk auf tauchen, so bricht VT den Test dieser Disk ab, um einer Endlos-Schleife zu entgehen. Sie muessen selbst nachkontrollieren. >> DOS0-OFS-BB >>RAD:IFF2PS/IFF2PS >> File defekt ? Diese Disk MUESSEN Sie kontrollieren. Entpacken Sie das Archiv bitte in VT-FileReq UND fuehren SIE einen FileTest UND einen BlockKetteTest durch. Es besteht die Gefahr, dass noch mehr Files in diesem Archiv defekt sind. Versuchen Sie zu retten, was noch zu retten ist. >>RAD:* >> *-Filename ?? Der Filename kann beim Einzel-Filecopy Aerger machen. PD-Versender sollten das Sternchen deshalb nicht auf ihren Disks haben. >> Boot-Girl.BB (H) >>RAD:BootGirl.data >>IFF-Bild UNWICHTIGE Meldung. Der Disk-Bereich, der vom Boot-Girl.BB nachge- laden wird, wurde gefunden. >>RAD:BootGirl.data >>bad T.DATA ;KEIN Fehler Jemand hat fuer das Bild einen Pseudo-Fileheader angelegt, um die Bild-Datenbloecke vor dem Ueberschreiben zu schuetzen. >> Boot-Girl.BB (H) >> keine Dos-Disk oder >> Deluxe.BB (H) >> keine Dos-Disk oder >> INTERFERON.BB (L) >> keine Dos-Disk usw. Diese Disk MUSS nachkontrolliert werden. VT meldet keine Dos-Disk. Der Boot-Girl.BB ist aber KEIN Disk-Lader, also stimmt etwas nicht. >> Nicht-Standard-BB >>RAD:023 PP-Data VT kennt den BB NICHT. Es handelt sich aber um eine DOS-Disk, da Files gefunden wurden. Also kann es kein NON-DOS-Spiele-Lader sein. Den BB sollten Sie sich anschauen. >> DOS0-OFS-BB >>RAD:IconiSer2.info >> bad T.DATA Das File sollten Sie sich anschauen. Es koennte defekt sein. Probieren Sie Einzel-Filecopy und vergleichen Sie die Laengen. Es koennte auch nachtraeglich ein falscher BB aufgespielt worden sein. Ersetzen Sie probeweise auf einer KOPIE einen FFS-BB (z.B. DOS1) durch einen OFS-BB (z.B. DOS0) und gegengleich. Fuehren Sie danach einen neuen Filetest durch. >> DOS4-OFS-N.BB >>RAD:Pics/gameback.iff >> bad T.SHORT Die File-Struktur entspricht NICHT den Commodore-Richtlinien. Sie sollten das Archiv von Hand entpacken und die Disk dann AUCH mit BlockKetteTest untersuchen. Es hat sich leider gezeigt, dass dann noch mehr Fehler gefunden werden. Versuchen Sie mit copy ALL zu retten, was noch zu retten ist. >>TuBu-Disk-defekt-BB >> keine Dos-Disk Dieses Archiv ist sicher defekt. Es enthaelt eine Disk, die mit TurboBackup kopiert wurde. Beim Kopieren wurde von TB ein Fehler festgestellt und die Fehlermeldung im BB belassen. >> DOS5-FFS-N.BB >> keine Dos-Disk Wenn Sie die CD unter KS2.0x testen, wird VT nach DOS4/5-BB keine DOS-Disk ausgeben, weil KS2.0x DOS4/5 formatierte Disks nicht lesen kann. Also wird die Disk wahrscheinlich in Ordnung sein. Sollten Sie aber mit KS3.x getestet haben, so muessen Sie das Archiv von Hand nachkontrollieren. >>RAD:l/disk-validator >>fal. Disk-Validator (Disk-Val. n.Orig) Dieses Archiv MUESSEN Sie sich genauer anschauen. Mit etwas Glueck brauchen Sie nur einen neuen sauberen Disk-Validator aufzuspielen. Mit etwas Pech finden Sie codierte Bloecke. >> DOS0-OFS-BB >>RAD:c2 >>Text-Hunk am Anfang Dieses Archiv sollten Sie noch einmal im VT-FileReq. entpacken und VT dann den Text-Hunk entfernen lassen. Hinter solchen Text-Hunks waren schon Commander-Linkviren versteckt !!!! Lesen Sie bitte in VTkennt_L-Z nach. >> Mini-Nuke (H) >>RAD:L/loader.sc >>Hunkstruktur defekt (Hunkstruk. n. Orig) Dieses Archiv MUESSEN Sie genauer untersuchen. Es besteht leider die Gefahr, dass mit BlockKette noch mehr Fehler gefunden werden. VT findet bei diesem File kein $3F2 am Fileende. Das File muesste also falls es ein Prg. ist nach den Commodore-Richtlinien DEFEKT sein. Leider gibt es aber einige URALT-Packer, die die Kennung weg- lassen und das Entpacken geht auf Grund des eigenwilligen Stils auf 68000 gut (auf 68040 SOFORT Guru bei mir). Sie muessen also selbst einen Test durchfuehren. oder: ein aelterer Compiler ???? oder: AMINET/COMM/MISC/PBILL32.LHA >>RH2:Phonebill/Phonebill >>Hunkstruktur defekt Im File sind im 3.Langwort 4 Hunks eingetragen, bis zum 3E9 sind aber Werte fuer 5 Hunks zu finden: 0000: 000003f3 00000000 00000004 00000000 ................ ^^ 0010: 00000003 00006a76 c0000ea2 00010000 ......jv........ ^1 ^2 ^3 0020: 40000001 0000004f 000003e9 00006a76 @......O......jv ^4 ^5 A/Leisure/DiskDemos/DDI-F01.DMS DMSMaPuS >> Mount.BB Virus Dieses Archiv sollten Sie nur mit einer "Zange" untersuchen. Der Mount-Virus kann auch die Festplatte schaedigen. Lesen Sie in VTkennt_L-Z nach. >>RAD:Getem/Getem1.0 3E8-Hunk Dieses File sollten Sie genauer untersuchen. Lesen Sie bitte in VTkennt_A-K nach. Gilt auch fuer 3F1-Hunk. >>RAD:tankgame >>$4EB9-$4EF9-Link ?? Dieses File sollten Sie genauer untersuchen. Lesen Sie bitte in VTkennt_A-K nach. >>RAD:Except_CLI >> $4EB9-Link ?? Dieses File sollten Sie genauer untersuchen. Lesen Sie bitte in VTkennt_A-K nach. >>RAD:BVK >> HunkLab Dieses File sollten Sie genauer untersuchen. Lesen Sie bitte in VTkennt_A-K nach. >>RAD:dinosaurs >>Block: 1162 DataBlockList <> FirstDataBl Im Fileheaderblock stimmen der Inhalt von $10 und $134 NICHT ueberein. Kann meist durch copy df0: df1: all behoben werden. Bei Bloecken groesser 512 Bytes (neuere Filesysteme) MUSS anders gerechnet werden. >>RAD:MODULES/mod.5 >>Block: 737 bad SEQNUMBER Bei DOS0/2/4 werden die Datenbloecke intern mit Nummern versehen. VT hat einen Block mit falscher Nummer gefunden. Das File ist nicht zu retten, aber probieren Sie ruhig selbst nach dem Ent- packen copy df0: df1: all . Time/Time_ungepackt/Time_291_320/Time319/MCalc (MUI)/Source.lha -lh5- ^ >>RH2: Root LEER ?? LHA konnte das File nicht entpacken, da im Pfad Leerzeichen vor- kommen. Entpacken Sie das Archiv bitte von Hand. Vielleicht lesen eines Tages die Programmierer und die PD-Ersteller im Benutzerhand- buch AmigaDOS (Teilenummer:368766-01) Kap. 1-8 nach: "Es ist vorteilhafter, wenn Sie Unterstreichungszeichen als Trenn- zeichen verwenden." AUDIO/MUSICIAN/TSECTOR/KAUKOMETSASTYKSEN_AAMIAINE >>RHD: Root LEER ?? ;LHA Rueckgebewert 20 .LHA fehlt ??? >>RAD:Modules/mod.waste.my.time >>Block: 183 Lamer! zerst. In diesem File wurde ein Block mit "Lamer!" vollgeschrieben. Da ist NICHTS mehr zu retten. Besorgen Sie sich bitte das Archiv neu. >>RAD:devs/        >>Prg v. BGS9/1 vers. oder >>RAD:Devs/         >>Prg von TER versch. oder >>RAD:  >>Prg v. BGS9/3 vers. Falls VT auch das Virusteil findet, wird automatisch Rename angeboten. Falls VT nur das "verschobene Programm" findet, gibt es 2 Moeglich- keiten. Fertigen Sie deshalb bitte eine Kopie von der Disk an. Danke Fall A: Jemand hat zwar das Virusfile geloescht, aber vergessen das ver- schobene Programm umzubenennen. Holen Sie das bitte nach. Fall B: In sehr fruehen Zeiten haben Programmierer "Unsichtbare Files" nach- geladen. Dann duerfen Sie das File NICHT loeschen, sonst laeuft das Hauptprogramm nicht mehr. Diese "Unsitte" wurde aber nur sehr selten von mir gefunden. Betroffen war nur das kurze (1x $A0) unsichtbare File. Arbeiten Sie also beim Fall "Prg v. BGS9/3 vers." bitte mit einer Kopie und pruefen Sie bitte danach die Lauffaehigkeit. Bei den langen unsichtbaren Filenamen hat es sich immer um ein vergessenes File gehandelt. >> DOS1-FFS-BB >>RAD:View >>Block: 981 Fehler in BlockListe VT findet MEHR oder WENIGER Bloecke als nach der Filelaenge not- wendig sind. In diesem Fall hier wurden mehrere Files im Old-File- System aufgespielt und dann der BB in Fast-Filesystem umgeaendert. Setzen Sie bitte mit VT einen OFS-BB und kopieren Sie dann mit copy df0: df1: all auf eine neue Disk. Die Files sind haeufig zu retten. >>RAD:Iterlaced/Coastline >>Block: 963 bad T.LIST VT hat einen Fehler im Filelistblock gefunden. Bei diesem Beispiel liegt an 963 KEIN Listblock wie im Fileheader eingetragen. Probieren Sie copy df0: df1: all . AmigaDOS wird eine Fehlermeldung ausgeben. Das File ist NICHT zu retten. Besorgen Sie sich das Archiv neu. >>RAD:G19 >>Block: 149 Block- o. ByteAnzahl falsch VT hat beim Test festgestellt, dass MEHR oder WENIGER Bloecke vor- handen sind, als von der Filelaenge notwendig sind. Moegliche Fehlerquelle (trifft bei diesem Archiv zu): Im Fileheader- block stimmt der Wert in $8 nicht mit der Anzahl, der im Fileheader- block aufgefuehrten Bloecke ueberein. Haeufig hilft ein copy df0: df1: all . >>RHD:TEK.Bootro >> BOOTJOB File So ein File muessen Sie IMMER untersuchen. Es koennte ein BB-Virus installiert werden !!! Bei TEK handelt es sich aber um ein BB-Intro. >> DMS-GURU z.B. CD-HOTTEST5 VAR1647.DMS Das Archiv wird OHNE Probleme entpackt. Aber danach ist die MemList defekt. Versuchen Sie Availmem FLUSH . Sie erhalten sofort einen GURU. JEDES Programm, das Speicher anfordert, wird fuer einen GURU sorgen !!!! Es wurden Versuche mit DMS1.11, DMS1.51 und DMS2.04 durchgefuehrt. IMMER das gleiche Ergebnis -> GURU . >>RH2:852-Langages/MultiPlot_XLNf_v1.06/MultiPlot_XLNf_v1.06.run A-defekt VT glaubt ein lha.run-Archiv gefunden zu haben, das beim Entpacken auf 68040 mit GURU5 abstuerzt. >>RH3:groff-1.09/include/unix.h >>FileL 0? VT glaubt ein File mit der Laenge 0 gefunden zu haben. Hier muessen Sie nun selbst entscheiden. Ist es ein "Platzhalter" fuer z.B. highscore eines Spieles, dann kann ja noch nicht gespielt worden sein. Also ist auch noch NICHTS abgespeichert. Hat das File mit der Laenge 0 aber z.B. den Namen game.main, dann besteht die Gefahr, dass das Spiel defekt ist. Im Beispiel "unix.h" wird das Programm wohl laufen. Aergerlich fuer Sie nur, wenn Sie in unix.h was nach- schauen wollen. Wenn Sie ALLE Files mit der Laenge 0 sehen wollen, muessen Sie in VT-Prefs S.1 einen Haken bei "zeige Filelaenge 0 immer" setzen. Ist der Haken nicht gesetzt, dann zeigt VT bei bestimmten File- Namen die Laenge 0 NICHT an: z.B.: Disk.info, .info, BootGirl.Data, Shell, .DUMMY, dummy Neu Juli 95: - Entpacke Archiv im Archiv im Archiv. Damit sollten Juli 95 sollten sich 99% aller CDRom-Files testen lassen. Die Laufwerke der 3. Ebene FF8: und FH9: sind fest vorgegeben. Sie brauchen dafuer also fms.device . Neu Mai/Juni 95: - LZX bitte verwenden Sie Vers. 1.20 Juni 95 - XPackit bitte verwenden Sie Vers. 1.3 Mai 95 - Entpacke Archiv im Archiv Mai 95 Sie brauchen SEHR viel Speicher oder Sie weichen auf Mai 95 fms.device (FHx) auf Festplatte aus. siehe unten - Halt bei Fehler in File-Archiv . Das Entpackfenster Mai 95 bleibt bei einem Fehler offen, bis Sie endcli eingeben. Machen Sie sich eine Notiz und untersuchen Sie das Archiv genauer, wenn die Filetest-Schleife fertig ist. Danke Neu April 95: - PackDev Ersetzen Sie bitte V1.1 durch V1.2, da V1.1 25.04.95 gepackte Archive von V1.2 NICHT entpacken kann. - Entpack-Optionen in VT-Prefs nach Seite2 ausgelagert. April 95 - Bei Disk-Archiven jetzt Blocktest moeglich. April 95 Wenn kein Fehler gefunden wird, wird nur der Fileheader (FH) angezeigt. Der Block-Kettentest wird nur gestartet, wenn das File mind. drei Bloecke lang ist. Neu Feb 95: - LZX File-Archive 17.02.95 verwenden Sie bitte mind. V1.01 (Mitte Maerz 95) - ZOO V2.10 Laenge: 52716 91/07/09 05.02.95 Es scheint verschiedene Laengen mit aehnlichem Datum zu geben. Mein ZOO ist von dt.Edition-CD Hinweis: Leider wurden einige defekte Zoo-Archive gefunden vgl. z.B. CD-AmigaPlus/FF767 . Es kann zu einem Endlosloop fuehren. Deshalb wurde im Einzelfilemodus (VT-FileReq.) das Entpackfenster bei ZOO-Archiven aktiviert. Vorteil: Sie koennen mit Ctrl-C abbrechen. Nachteil: Sie muessen nach dem Entpacken IMMER endcli eingeben. - ARC V0.23 FF 70 Laenge: 50328 04.02.95 Ich habe keine neuere Version gefunden - DMSPRO V2.04 03.02.95 Es hat sich leider herausgestellt, dass das Teil auf 68000 mit GURU 3 abstuerzt. Mit 68030/40 geht es. Das hat NICHTS mit VT zu tun. Nehmen Sie ihr Original-DMS und geben Sie z.B. ein: ram:dms ? . Wenn Sie das mit 68000 probieren, Sehen Sie sofort den GURU !!!!!! Loesungsansaetze fuer 68000: (also NICHT fuer 68020/30/40) a) Sie kopieren DMS111 !!!! noch einmal nach Packer: als DMSPRO Nachteil: Sie koennen NUR FAST alle DMSPro-Archive entpacken. Es geht Ihnen nach meinen Tests aber nur die HD-Disk- Option verloren. Auf CDs habe ich bis jetzt (Maerz95) noch keine HD-DMS-Archive gefunden. b) Sie loeschen (wichtig!!!) DMSPRO in Packer: und verwenden UNDMS (Laenge: 18364 z.B. 17BIT-D-CD) . Vorteil: "echte" DMSPro-Files werden von VT entpackt. Nachteil: Es erfolgt waehrend des Entpackens KEINE Ausgabe. Beim Filetest werden die Files dann natuerlich angezeigt. DMSPRO V2.02 ist fuer VT NICHT geeignet, da immer ein Return er- wartet wird. Neu Dez 94: - ZAP V1.40 Probleme siehe oben - Warp V1.11 Probleme siehe oben - XMASH V1.0 Probleme siehe oben - UnZip (V5.1 7.Feb.94) - Shrink (V1.1) - LHWarp (V1.40) - Zoom4 (V4.1 o. V4.2) wird gebraucht fuer aeltere Archive z.B. auf Auge 55 Ein Archiv auf Auge 55 kann mit Zoom = Zoom5.4 nicht entpackt werden. - DMS111 (V1.11) wird gebraucht fuer aeltere Archive z.B. auf Auge 56 auf CD. Ein Archiv auf Auge 56 kann mit DMS = DMS151 nicht entpackt werden. Viel Spass Heiner Schneegold