FileSplitter v2.0 (15)

[himitsu]

[add]
die aktuelle (Test)Vesion + einges an Erklärung ist im Beitrag #22 zu finden
[/add]

Sooo, ich hab inzwischen vieles nochmas (teils Grundlegend) überarbeitet und weitere Features eingefügt.

Der FileSplitter kann (jetzt)

• es werden vom Programm (abgesehn vom optionalen Setup mit Explorerintegration) nirgendwo Daten gespeichert, also nichts mit Registry, INIs und was es sonst noch gibt
• Unicode (war doch wohl klar :engel: )
• von der Bediehnung her ist es immernoch mehr an eine Konsolenanwendung angelehnt und läßt sich auch von dieser aus ansteuern
  
  die Parameter: Programm starten und H für Hilfe auswählen oder über filesplitter -h ansehn
• Dateien zerlegen/splitten (wär ja blöd, wenn nicht)
• die Dateien wieder zusammenfügen (alternativ über eine Batchfile mit Windows-Copy)
• Neu: Zieldatei/-pfad kann jetzt frei gewählt werden.
  dennoch wird ein Name/Verzeichnis vorgeschlagen, welcher aus der Quelldatei erstellt wird.
• Neu: Dateien prüfen (Datei oder Dateiteile anhand der MD5-Datei)
• kann im Explorer-PopupMenü eingetragen werden
  wer in der alten Version einfach die EXE austautsch kann das schon jetzt oder dann für alle nach der Testphase
• Dateien jeder Größe sind möglich (solange es das Dateisystem unterstützt)
  also Dateien/Dateiteile über 2 GB (ich denk mal bis theoretisch fast 8 PB sollten für alle ausreichen)
• ja und die EXE ist wirklich so klein oder meint einer hier würden sich UPX und Co. noch lohnen
• Wenn das Programm von einer Konsole oder einer Batchfile aus aufgerufn wurde, dann gibt es auch dort einige Infos aus.
• und zur Sicherheit ist das Programm selbstprüfend - bei Defekt/Veränderungen bricht es ab
  (z.B. bei unvollständigem Download)
  http://www.delphipraxis.net/internal_redirect.php?t=123395
• Screenshots gibt's noch keine, aber es sind eh nur ganz einfache Dialoge, wo man hintereinander nach den nötigen Werten gefragt wird.
  
  und es sieht fast noch so aus wie in der Vorgängerversion
  http://www.delphipraxis.net/internal...t.php?t=100632

Im Anhang sind derzeit

• eine Betaversion (wird sich vermutlich nicht mehr viel dran ändern)
  diese ist auch nochmal einzeln angehängt
• eine Testbeta mit 'ner art Benchmark und wo immer das Consolenfenster erstellt/verwendet wird
• eine Scriptdatei über welche die "normale" Beta in derKonsole gestartet wird
• und 4 Screenies vom Abschlußdialog
  wo ich auch mal defekte Dateiteile übergeben hab (was steht im Dateinamen)
  und keine Sorge, die DOS-Box ist nicht immer vorhanden

Es wäre vorallem nett, wenn ihr das Programm ausgiebig testet
und vorallem mal prüft wie/ob das Teilen/Zusammenfügen über Netzlaufwerke läuft.


Es wird beim Splitten wenn möglich eine Batchfile [.bat] (nur wenn die Dateinamen DOS-kompatibel sind)
und zusätzlich eine Prüfdatei [.md5] angelegt.

In der MD5-Datei ist als erstes natürlich der MD5-Hash der Datei (sollte von anderen MD5-Testprogrammen hoffentlich verstanden werden) und anschließend sind noch weitere Informationen.

Die Batchfile [.bat] versucht zuerst den FileSplitter zu finden und ihm den Zusammenfügenauftrag zu übergeben
und falls die Suche erfolglos bleibt, dann werden die Dateiteile über COPY zusammengefügt.

Beim Zusammenfügen vergleicht der FileSplitter die erstellte Datei mit den Werten aus der MD5-Datei (wenn diese gefunden wurde) und gibt das Resultat aus (z.B. fehlende/defekte Dateiteile).


Information: in .md5>PartCheck stehen natürlich nur Informationen über den Urzustand der gesplitteten Datei.
(Dateigröße, Infos über die einzelnen Dateiteile und einige Hash's)



Tja, ansonsten ist nur das vermutlich weitgehenst Optimalste eingebaut:

• Umgehung der WindowsFileCache (NonBuffered-Read/Write)
• Overlapped Read/Write (mehr Zeit für interne Berechnungen)
• und wenn verfügbar AWE (Address Windowing Extension muß im Windows für Programme freigegeben sein)

mit viel Glück könnte das der wohl schnellste FileSplitter auf UserEbene sein.

Man kann da wohl sagen ich hab mich hier voll ausgetobt (im Moment fällt mir auch nichts mehr ein).
Was den UserMode(Windows) betrifft geht es kaum noch schneller (es si denn ich nehm den MD5-Teil raus)
und nur hierfür extra einen Dateisystemtreiber zu entwickeln wäre wohl übertrieben (nur weil man damit dann beliebig große Dateien innerhalb einer Partition in wenigen Millisekunden teilen/zusammenfügen könnte).

[bigg]

Das liegt imho an den verwendeten Dateiroutinen, die das Cachen von Dateiinhalten unterbindet und erst ab Windows 2000 zur Verfügung stehen.

@Himitsu: Man könnte die benötigten Funktionen doch dynamisch laden, sofern verfügbar und andernfalls auf die "normalen Routinen" zurückgreifen.

[himitsu]

OK, was sowas wie FreeUserPhysicalPages betrifft, dann könnte ich sowas dynamisch laden (da dieses eh kaum verwendet wird und schon eine alternative eingebaut ist), aber es gibt noch andere Funktionen, welche aus der WinNT-Familie stammen ... mal sehn was sich da machen läßt.

Aber ich dachte ich hätt hier mal erwähnt, daß es ab Win2000pro läuft
(sieht aber wohl nicht so aus )
Das Zusammenfügen wird zwar auch per Programm gemcht, aber es geht auch ohne (per Batch-File) ... also im Grunde gibt' nur beim Teilen dieses Problem mit den alten, von vielen Firmen auch nicht mehr unterstützten Windowsversionen


So, die alternative GUI funktioniert anscheinend.

Nur blöd, daß so die Parameterkontrolle wesendlich aufwendiger ist, als bei sequentieller Abfrage.
und ganz nett ... dank neuer GUI gleich mal 14 KB (13%) größer (wenn ich bedenke, daß die "Alte" nur einen winzigen Bruchteil beanspruchte)

Dann war es ja so, daß manchmal die Buttonbeschriftung in der Taskleiste sich nicht aktualisierte.
und da dort unter Anderem der Fortschritt angezeigt wurde, war des nicht so gut ... dieses sollte nun weitgehend behoben sein.


Dann hab ich doch nochmal die alten BATCH-Files rausgeholt und angepaßt.
(solange bis der neue Installer fertig ist)

Über diese wird der FileSplitter nach "C:\Programme\FNS Enterprize's\FileSplitter" kopiert
und einiges in der Registry eingetragen (siehe .REG-Dateien).

Zum Intallieren eine dieser Dateien ausführen:
_Install.cmd
_Install_Extended.cmd
_Install_GUI.cmd
_Install_GUI_Extended.cmd
(beim ersten Install muß die Datei oftmals doppelt gestartet werden, da eine geänderte Umgebungsvariable nicht aktualisiert wurde ... wenn, dann steht es aber im Consolenfenster drin)

Die _Install_GUI-Versionen nutzen das neue GUI-Fenster.
Die _Extended-Versionen zeigen die im Explorer-Popupmenü eingabeiten Einträge "Split File" und "Create MD5" nur an, wenn [Shift] beim Aufruf des Menüs gedrückt wurde.
Bei Auswahl von *.001 und *.md5-Dateien wird zusätzlich (unabhängig der [Shift]-Taste) noch jeweils der Eintrag "Concat Files" oder "Verify (Splitted) File" im Explorer-Popupmenü angezeigt.
[siehe PopupMenue.jpeg]


Tja, und mit _Deinstall.cmd wird natürlich deinstalliert.
Vorm Installieren einer anderen Version muß nicht deinstalliert werden.

Nach dem Deinstallieren muß/kann das Installverzeichnis gelöscht werden (wird aber auch nochmal von Deinstall-Script gesagt)

Da der "Deinstaller" noch nicht erkennen kann ob bestimmte Einträge noch benötigt werden, läßt er einen winzigen Teil zurück.
(wenn ihr nicht selber Verknüpfungen zu *.001- und *.md5-Dateien erstellt habt, dann kann dieses entfernt werden)
- HKEY_CURRENT_USER\Software\FNS Enterprize's
- HKEY_CLASSES_ROOT\.001
- HKEY_CLASSES_ROOT\.md5
Zum vollständigen Entfernen "C:\Programme\FNS Enterprize's" löschen und DeinstAll.reg (im Anhang) ausführen.


Ansonsten kann der FileSplitter (also nur die EXE) auch einzeln verwendet werden.

die wichtigsten Parameter:

Code:

split:  FileSplitter -[g]s[m] FileName [o=OutFileName.001] SplitSize
concat: FileSplitter -[g]c FileName.001 [o=OutFileName]
verify: FileSplitter -[g]v FileName.md5 [o=VerifyFileName[.001]]
help:   FileSplitter -h

parameter extensions:
   m    only create the MD5 file
   g    use the new GUI

SplitSize:
   123          size of parts in byte
   123kb  123k  size of parts in KB
   123mb  123m  size of parts in MB
   123gb  123g  size of parts in GB
   x89          count of parts

Code:

Datei teilen:
FileSplitter -s  Datei [color=silver]o=Datei.001[/color] Teilegröße

MD5-Datei erstellen:
FileSplitter -sm Datei [color=silver]o=Datei.md5[/color] Prüfgröße

Datei zusammenfügen:
FileSplitter -c  Datei.001 [color=silver]o=Datei[/color]

Dateien per MD5-Datei prüfen:
FileSplitter -v  Datei.md5 [color=silver]o=Datei[/color]
FileSplitter -v  Datei.md5 [color=silver]o=Datei.001[/color]

Datei teilen incl. Kommentar:
[color=silver]der Kommentar wird nach jedem zusammensetzen/prüfen angezeigt[/color]
FileSplitter -st  Datei [color=silver]o=Datei.001[/color] Teilegröße c=Kommentar

MD5-Datei erstellen incl. Kommentar:
FileSplitter -smt Datei [color=silver]o=Datei.md5[/color] Prüfgröße  c=Kommentar



[color=silver]die Parameter können auch über die alte "GUI" eingegeben werten

das Grau hinterlegte wird vom Programm vorbelegt und kann direkt übernommen werden
> Verzeichnis = Verzeichnis der Quelldatei
> Dateiname   = Quellname mit passender Dateierweiterung versehn

z.B. Datei teilen: "s" [Enter] Datei auswählen [Enter] [Enter] Teilegröße [Enter][/color]

Weiteres über "h" oder "-h" als ersten Parameter (alte GUI)
oder per "FileSplitter.exe -h"


Wenn euer PC gerne Arbeitsspeicher auslagert und der FileSplitter ausgebremst wird, weil er ständig seine Daten zurückholen muß,
dann könnt ihr auch gern AWE (Address Windowing Extensions) aktivieren und der FileSplitter besorgt sich als Kopierpuffer nicht auslagerungsfähigen Speicher von dort.
Keine Ahnung wo dieses Privileg im Windows versteckt ist, aber in Luckie's XP-Usermanager findet man es im Gruppenmanager und es nennt sich "Sperren von Seiten im Speicher" (SeLockMemoryPrivilege).
(ist erst nach Neuanmeldung/Neustart aktiviert)


nochmal kurz das alte Geschriebene

Zitat:

• NonVCL und nix mit UPX und Co.
• läuft (glaub ich erst) ab Windows 2000 professional
  [add]gut, dann erwähn ich es jetzt erst [/add]
• mehrsprachig mit automatischer Sprachauswahl
  (auch wenn derzeit eigentlich nur Englisch integriert ist ... Übersetzer können sich gern melden)
• komplett Unicodefähig
• keine Probleme mit großen Dateien (weit über 4 GB)
• Drag&Drop bei Datei-Edit-Feldern (NewGUI und Datei-Öffnen/Speichern-Dialoge)
  es können Dateien z.B. vom Explorer direkt da reingezogen werden
• läßt sich im Explorer (PopupMenü) integrieren
• Steuerung per Parameter möglich
• umgeht vorwiegend die WindowsFileCache
  (ist also möglichst Resourcenschonend was den RAM betrifft)
• erstellt eine MD5-Prüfdatei
• prüft beim Zusammenfügen (per Programm) die Datei auf Datenfehler
• erstelle eine BATCH-Datei zum Zusammenfügen
  - nur wenn sich der Zieldateiname (OutFileName) in den OEM-Zeichensatz übersetzen läßt
• die BATCH-Datei sucht zuerst meinen FileSplitter und läßt diesen zusammenfügen
  wurde kein FileSplitter gefunden, dann wird per COPY zusammengefügt
• falls nötig auch mehr als 999 Teile möglich

einige Optimierungen und der Installer brauchen och etwas Zeit ... bin derzeit mit anderen Dingen etwas ausgelastet

Außerdem sieht es so aus, als wenn ich dieses Programm nur als FreeWare (ohne Source) weiterführen werde ... es wird also mit dem nächtem großem Relase ein ins FreeWareForum wandern [add]ist ja schon drüben @_@[/add], aber die alten Versioen werden weiterhin als OpenSource bleiben.

[himitsu]

und nun noch was Anderes/Zusätzliches...

TestPack:
verschiedene FileSplitter(Test)Dateien

* FileSplitter.exe > Eineldatei ohne Installer
* FileSplitter.cmd > zum Aufrufen im Consolenfenster und der Textausgabe darin
* FileSplitter_inclGUI.exe + .cmd > neue GUI und zusätzlich Constolenfenster
(nja, wenn man ihn von Console aufruft, macht er ja automatisch seine Ausgaben zusätzlich darin)
* FileSplitter_Sprachen_... > englisch und zusätzlich schlechtes Deutsch (hab's gestern mal schnell verucht zu übersetzen)
> EXE pur = automatische Sprachwahl | Start per .cmd = manuelle Sprachwahl
* FileSplitter_DradAndDrop_Edit.exe > Dateidialog mit Drag&Drop nur im Edit
* FileSplitter_DradAndDrop_Window.exe > Dateidialog mit Drag&Drop fast im ganzem Fenster (siehe Beitrag #19)

FileSplitter v2.0 (16) PHP
'ne kleine PHP-Version (ist Ende letztes Jahr aus Langer Weile und weil ich mal probieren wollte, ob's geht, entstanden)
man kann damit eine ganze Datei auf'm Server in kleinen Teilen zum Download anbieten (die Dateien sind kompatibel zur EXE-Version)
weiß zwar nich wofür man wirklich sowas brauchen kann, aber was soll's ... zum Wegschmeißen/Löschen war's mir aber zu Schade.

[himitsu]

Zitat von bigg:

@himitsu: Man könnte die benötigten Funktionen doch dynamisch laden, sofern verfügbar und andernfalls auf die "normalen Routinen" zurückgreifen.

wie schon gesagt, es dynamisch zu laden wäre eine Möglichkeit, aber so wie das Programm derzeit ist, läuft es nur auf NT-Ebene.

Windows 98, ME und früheres werde ich nach aktuellem Stand nicht so einfach unterstützen können,
denn aktuell arbeitet mein Programm ja komplett mit Unicode und Win98 kennt sowas noch nicht.
Und ich denk mal nicht, daß jemand sich jemand das rießige [msdn]Microsoft® Layer for Unicode[/msdn] (MSLU) und damit eine (pseudo)-Unicode-API installieren.


Ansonsten muß ich mal abwarten ... aktuell bin ich noch mit meinem kleinem Framework beschäftigt und wenn alles klappt und ich auch dieses Programm darauf umgestllt hab, dann müßt' ich auch leicht eine Ansi-Version (für Win98) erstellen können.

[bigg]

Hi himitsu,

Zitat von himitsu:

wie schon gesagt, es dynamisch zu laden wäre eine Möglichkeit, aber so wie das Programm derzeit ist, läuft es nur auf NT-Ebene.

ist ja auch nicht weiter schlimm. Die Arbeit, dass ganze Projekt umzustellen, nur um die Kompatibilität eines knapp 10-15 Jahre alten Betriebssystems zu gewährleisten, halte ich für nicht gerechtfertigt. Benutzt überhaupt noch jemand Win9x/ME? Ich glaube ja, dass das nur noch Entwickler in einer VM verwenden.

Zitat von himitsu:

Ansonsten muß ich mal abwarten ... aktuell bin ich noch mit meinem kleinem Framework beschäftigt und wenn alles klappt und ich auch dieses Programm darauf umgestllt hab, dann müßt' ich auch leicht eine Ansi-Version (für Win98) erstellen können.

Welches kleine Framework?

[bitsetter]

Zitat von bigg:

Benutzt überhaupt noch jemand Win9x/ME? Ich glaube ja, dass das nur noch Entwickler in einer VM verwenden.

Ja ich , habe es auf einem älteren Rechner installiert.
Aber vom Prinzip her hast du schon Recht, da sollte man sich schon überlegen, ob sich der Aufwand überhaupt lohnt. Außer man sieht das Ganze als eine Art Herausforderung an.

[himitsu]

Unicode<>Ansi sollte kein Problem darstellen, denn dieses läßt sich dodal einfach fast komplett per Kompilerschalter umstellen.

Und für den Rest muß ich mal sehn ... aber, wie gesagt, eigentlich konzentriere ich mich vorwiegend nur noch auf die neuere NT-Linie ab Windows 2000 professional und alles was daruner liegt wird erstmal nicht explizit unterstützt.


@bigg: ich hoffe mal Framework ist überhaupt das richtige Wort.
Es ist nur eine kleine, schlanke WinAPI-Kapselung zusammen mit einigen Code-Schnippseln.
Vorallem ist mal eine Art nonVCL-VCL, ein MemoryManager (abgespeckter FastMM-Clone ... siehe FastXMM), 'ne eigene möglichst nahe an die Windows-Header-Files angelegt WinAPI-Übersetzung und mal sehn was noch vorgesehn.
Und das Alles mit einheitlichen Typendefinitionen und einem einheitlichen CodeStyle.
Also eine Neuauflage einiger alter Projekte (z.B. UCC), welche ich endlich mal fertigstellen möchte.

Die nonVCL-Kapslung ist in etwa mit FStream.pas > TnFileStream zu vergleichen ... also möglichst alles schön klein, speichersparend, mit direktem WinAPI-Zugriff (also ohne verwirrende Umwege wie in der DelphiVCL) und ohne feste Bindung zwischen Windows-Objekt und Klasse/Record, so daß man beides jeder Zeit voneinander trennen kann, oder zusammenfügen kann und da der Record sozusagen nur einem Handle entspricht, kann man damit alles machen, was mit einem FileHandle sonst auch möglich ist ... hach, ich könnt mich glatt in die neuen Delphi-Funkionalitäten verlieben
[mindestens Delphi2006 nötig]