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 :zwinker:
• 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).

[himitsu]

es geht weiter ._.

Hab hier vorwiegend mal versucht dem Datei-Öffnen/Speichern-Dialog etwas aufzurüsten.
- Labels/Buttons übersetzt
- Dateiname-Edit mit Drag&Drop ausgerüstet
wenn alles gut geht, dann kann man jetzt in dieses Editfeld eine Datei z.B. direkt aus'm Explorer reinziehen und muß nicht erst zur Datei hinsurfen

Also bitte mal die Bediehnung Testen und dabei etwas auf die Beschriftungen achen.


Währenddessen arbeite ich weiter an der Explorerintegration.




Nochmal in ganz Kurz die Bediehnung:
(einfach die Parameter nacheinander eingeben)

Zerteilen: "s" [Enter] Datei [Enter] Zieldatei [Enter] Größe [Enter]
Programm starten und dann "s" eingeben [Enter] Datei wählen [Enter] Zieldatei wählen [Enter] Größe eingeben [Enter] fertig
Zusammenfügen: "c" [Enter] Datei.001 [Enter] Zieldatei [Enter]

MD5-Datei erstelen: "sm" [Enter] Datei [Enter] Zieldatei [Enter] Größe [Enter]
einfache MD5-Datei: "sem" [Enter] Datei [Enter] Zieldatei [Enter]
Datei prüfen: "v" [Enter] MD5-Datei [Enter] Datei [Enter]

und/oder wenn der FileSplitter (mit Explorerintegration) installiert wurde:
Zerteilen: [Explorer>"Split File"] Zieldatei [Enter] Größe [Enter]
oder Explorer-Popup > "Split File" und dann Zieldatei wählen [Enter] Größe eingeben [Enter] fertig

* das Graue ist wird vom Programm vorgegeben, kann aber geändert werden
* Weiteres siehe Programmhilfe (Parameter H)


[edit]
EXE upgedatet ... hatte mich schon gewundert warum die plötzlich so groß war :shock:
nja ... die SysUtils war ausversehn mit eingebunden -.-''

[edit] Anhang entfernt

[bigg]

Hi himitsu, :wink:

die GUI-Oberfläche sollte dringend überarbeitet werden. Das ständige Eintippen eines Befehls in einer GUI kann für den Anwender ziemlich nervig sein, besonders wenn man dein Programm eh über die Konsole benutzen kann. (paramtergesteuert)

Das Programm macht imho auch keinen Sinn, wenn du mich fragst.
Fast jeder Packer bietet dir heute diese Funktionalität, das Teilen von Dateien/Archiven etc.


btw: Bei deinem Talent solltest du dich lieber um anspruchsvollere Dinge kümmern.
Wie wäre es da mit Spracherkennung, Sprachausgabe, OCR und so. weiter... :mrgreen:


Freundliche Grüße

[MagicAndre1981]

[OT]
bigg ist ja wieder da :shock:
[/OT]

[bigg]

btw.: Ich war doch nie wirklich weg, oder? :roll:
Soll ich wieder gehen? :mrgreen:

[MagicAndre1981]

doch, dein altes Profil + deine Tools waren mal weg. :gruebel: Nee, kannst ruhig bleiben ;)
So, genug OT, weiter im Text :warn:

[himitsu]

Also danke erstmal für die konstruktive Antwort ^^


Nja, hier geht's einfach mehr um Geschwindigkeit.
und Packer können auch keine Wunder z.B. eine große Videodatei läßt sich kaum noch komprimieren
(z.B. fallen bei 'ner GB-Datei ein paar gesparrte MBs nicht wirklich auf)

Hier ist nur 7Zip drauf und dazu ist der Rechner nicht grad gut/schnell... ob ich da jetzt eine 500MB-Datei in knapp 2 Stunden (selbst mit schwacher/keiner Komprimierung) Teile oder das ganze in wenigen Minuten Splitte ist da ein großer Unterschied.
Der Splitter arbeitet mir einem "maximum" an Datenrate was der PC/IDE-Treiber/Festplatte... und eventuell noch sowas wie Virenscanner durchlassen.


Zum ständigen Getippe ... die Eingaben müssen so oder so gemacht werden
egal ob alles zusammen am Anfang in einem rießigem Dialog (da muß man zwischen den Controls rumspringen)
oder ob nacheinander wo immer nur ein (das nötige) Control aktiv ist.

über die Explorerintegation muß dann noch weniger gemacht werden
> Datei und Option wird schon im Explorer gewählt
und ann bleibt eigentlich nur noch ein Wert einzustellen (beim Slitten die Größe)

Zusammenfügen (Batch) : nur Batch ausführen fertig
Zusammenfügen : nur Zieldateiname wird abgefragt, aber da dieser schon eingetragen ist, muß man nur Enter drücken
Splitten : nur Zieldateiname und Größe wird abgefragt ... also Enter+Größe+Enter und auch fertig

Zitat:

btw: Bei deinem Talent solltest du dich lieber um anspruchsvollere Dinge kümmern.

Anspruchsvolleres?
hier stecken genügend Grundlagenforschungen drin (welche ich übrigends in anderen Programmen weiterverwenden werde)

- schnelle ungepufferte Schreib-/Lesezugriffe
- Hashing (MD5 wird z.B. direkt von XP/Vista unterstützt)
- AWE ... physischer RAM ohne Auslagerung
- in Punkto nonVCL hab'sch och vieles gelernt/verbessert
- und den Windows-Dateidialog umzumoscheln is eigentlich ganz witzig

also ein gutes "einfaches" Projekt um schön mit Hardwärezugriffen zu üben :)

und du möchtest nicht wissen wieviele andere Dinge (auf welche man nebenbei ausversehn gestoßen ist) noch hieraus entstanden sind

[MrKnogge]

Hi himitsu,

ich verstehe zwar nicht ganz warum du an dieser Parameter-Steuerung festhälst, (ich persönlich finde sie ziemlich Benutzerunfreundlich, da man um die zu teilende Dateien im Dialog auszuwählein meist doch wieder zur Maus greifen muss) aber du wirst das sicher nicht ohne grund machen.

Allerdings habe ich einen kleinen Bug entdeckt, bzw. möchte eine Verbesserung vorschlagen.

Bei der Eingabe von "-sdm" wird ja nur die md5-Datei erstellt.
Wenn ich richtig gelesen habe, ist das so gewollt, aber warum ?
So muss ich 2mal durch das Programm, statt die md5-Datei gleich mit zu erstellen lassen.

Desweiteren werde ich dann aber gefragt in wie ich den meine Datei geteilt haben möchte.
Zumindest letztees ist dann sinnlos.

Gruß
Christian

[Luckie]

Und falls ein Paramter nicht erkannt wird, solltets du ein entsprechendes Feedback geben. Ih habe fünf Minuten probiert die Dateiteile mit -x5 anzugeben. Bei Klick auf OK ist nichts passiert. Irgendwann habe ich das "-" mal weggelassen und da ging es.

[himitsu]

- die MD5-Datei wird immer mit erstellt
- die alternative Battchfile für's zusammenfügen nur wenn möglich

Ja, das ist bei sm/sdm so gewollt.
Den Parameter M hab ich extra letzte Woche simplementiert,
damit kann man jetzt auch einfach nur eine Prüfdatei für eine Datei erstellen.
Und mit -V kann dann später geprüft werden, ob die Datei defekt ist oder nicht :zwinker:

Der MD5-Hash geht über die gesamte Datei und in der md5-Datei sind dann standardmäßig noch weitere Werte, womi dann auch noch die einzelnen Dateiteile einzeln geprüft werden können,
aber diese ganzen Prüfwerte sind auch auf die ganze Datei anwendbar.


Und ich hab alles so gemacht, daß alle Dateien wo gleich am Anfang ein hexadezimal MD5-Hash steht verwendet werden können. (die gibt's ja z.B. zu einigen Downloads mit dazu)

PS: bei -SEM wird nich nach der Größe gefragt, da dort der PartCheck-Abschnitt entfällt.


Nja sinnlos ist diese Abfrage nicht ... muß da wohl nur noch den Text etwas anpassen.

Die zusätzlichen Prüfdaten (Abschnitt PartCheck der md5-Datei) sind für jeden Dateiteil vorhanden.
Im Endefekt ist so erkennbar wo (in etwa) in der Datei ein Fehler vorliegt.


Hab aber bei -VN einen Fehler entdeckt ... eigentlich sollte der 3. Parameter nicht nochmals abgefragt werden, wenn der schon übergeben wurde :gruebel:
nee, nur fehlerhafter Parameter.


@Luckie: OK, werd ich machen :angel2:
bin ja eh noch mit vielen Texten beschäftigt und da stören ein paar Neue nicht ^^

[edit] Anhang entfernt

[MrKnogge]

Zitat:

Zitat von himitsu

PS: bei -SEM wird nich nach der Größe gefragt, da dort der PartCheck-Abschnitt entfällt.

:shock: Stimmt, bei "-SEM" wird nicht danach gefragt, bei "-sem" aber schon :wink:

[himitsu]

O_O eigentlich sollt Groß-/Kleinschreibung egal sein

du hattest übrigens -SDM

sDm = Splitt + fortschritsDialog + nurMD5erstellen
sEm = Splitt + einfache MD5erstellen

[MrKnogge]

Oh sorry,ich meinte "-sdm". Da kommt die Auswahl wie ich denn gern geteilt hätte.

[himitsu]

Wie gesagt, damit legt man dort fest wieviele Teile man für die Fehlerprüfung möchte.

Dieser Wert legt dort nur fest über wieviele Teile der PartCheck läuft.
Aus diesem Grund wurde dort (ist nur bei -SM, -SDM und ähnlichem so) ein Wert vorgegeben.
die MD5-Datei belegt ja immer mindestens einen gewissen Platz auf der Festplatte und der Vorgabewert wurde so festgelegt, daß meistens nicht unnötig mehr Platz belegt, aber der bereits Reservierte habwegs ausgenutzt wird.

2 Teile = ein Defekt kann nur auf den Dateianfang (erste 50%) oder das Dateiende (letzte 50%) eingegrenzt werden.

mehr Teile dann entsprehend.

[MrKnogge]

Ahh, jetzt hab ich's kapiert.

[himitsu]

- inzwischen gibt's 'ne Meldung bei falschen Parametern (möglichst mit Angabe des falschen Zeichens)
- einige Strings wurden überarbeitet
- die Parameterbehandlung wurde geändert
(die Reinfolge der Zusatzparameter ist jetzt beliebig)
- an der fehlerprüfung arbeite ich noch ...

... danach lad ich dann 'ne Neue Version hoch


Aber hier ersmal ein Frage:
hab das Editfeld (Dateiname) in den Open-/SaveDialogen ja um Drag&Drop erweitert,
so daß man da z.B. aus'm Explorer den Namen reinziehen kann.

Jetzt war ich auf die Idee gekommen dieses, für eine einfachere Bediehnung, auf den ganzen Dialog auszuweiten, aber leider bekomm ich das Drag&Drop der Dateiliste (ListView) nicht weg.
Ein einfaches DragAcceptFiles(...,False) reicht leider nicht aus.

Nun ja, hab mal 2 Versionen im Anhang:
- einmal nur das Edit
- und das Andere über die gesamte Form (bis auf die ListView/Dateiliste)

Beim Zweiten muß man zwar nicht so genau "ziehlen", aber dank der Listview ist es doch bestimm verwirrender,
oder was meint ihr?

bzw, weiß jemand wie man die Dateiliste von der Drag&Drop-Fähigkeit befreien kann?
(ein Explorerhook ist vorhanden und ein Windowhook auf diese ListView wäre möglich)


Anhänge:
Programme Springen direkt zum OpenDialog ... danach diesen einfach per [Cancel] oder [X] shließen
(Param -v hartcodiert ... also selbst bei [OK] würde nichts gespeichert oder irgendwo verändert)
Zum Testen einfach Dateien/Verzeichnisse (beim Drag&Drop wird noch nichts geprüft) z.B. aus einen Explorer oder auch der Dateiliste/ListView in das "Editfeld" ziehen

[turboPASCAL]

Ist mir pers. etwas Umständlich mit den Parameterzeugs. Eine nette GUI wäre da nicht ganz
Unvorteilhaft. Deine Beschreibungen zu den Programmen ist etwas dünn, was mach ich jetzt mit
den Exec. ? :stupid:

Aber Auseinandernehmen und Zusammenbasteln mach dein Tool.

[himitsu]

Die Beschreibung bau ich Stück für Stück auf. Hab hier auch schon seit einer Weile eine "große" Hilfedatei (aktuell RTF mit 2,5 MB dank der Bilder), aber diese ist noch für die alte Version ... kümmer mich halt erstmal mehr um das Programm bzw. die Funktionen und dieses kommt danach dran.

OK, eine GUI-Version könnte ich bestimmt noch erstellen, aber erstmal kümmer ich mich mal um die Funktionen :)
und so schlimm ist es doch garnicht ... vorallem im Zusammenhang mit der Explorerintegration, da bräuchte man im Grunde nur noch die SplitSize einzugeben und sonst ist eigentlich alles per Default vor-/festgelegt (Zieldatei bestätigen/ändern, SplitSize eingeben und fertig ... heißt die GUI wäre zum Großteil inaktiv)


Und ein Open-/Savedialog würde dort auch benötigt (nur daß man ihn in einer GUI erst aufrufen muß und hier kommt er sofort und nur da wo nötig)

[Add] MiniGUI-Vorschlag (Design noch änderbar)

[himitsu]

Bis zum update/veröffenlichung einer voll funktionsfähigen Version wird's noch etwas dauern :?

erstmal kämpf ich ja noch etwas hierran > mehrsprachige Resourcen nutzen
dann bastle ich mir grad 'nen Installer, um die alte Batchfile abzulösen.
und frühsetens mit Fertigstellung des Installers brin ich ein Final-Relase raus und dann auch weider mit Explorerintegration.


und noch eine Frage: hab mir ja den Opendialog um Drag&Drop erweitert ...
weiß zufällig jemand, wie man das Standard-Drag&Drop-Verhalten des FileList abschalten kann?

wenn ich das ganze Fenster als Ziel anlege, dann hat leider dieses Standardverhalten Vorrang :cry:
und da MS ja mal wieder an den IDs rumspielen könnte, ist auch des D&D für das Editfeld nicht ganz sicher.
(außerdem wär es schön, wenn des gesamte Fenster als Ziel diehnen könnte ... müßte man nicht unbedingt das Editfeld treffen)

derzeit hab ich es so implementiert, daß wenn das Edit nicht gefunden wird, das "ganze" Fenster mit D&D ausgestattet wird.


Dann hate ich die Steuerung per Parameter grundlegend überarbeitet ... jetzt ist unter anderem die reinfolge der Zusatzangaben im 1. Parameter egal.
Und zusätzlich wurde die Consolenausgabe erweitert.


Ja und da es viele unbedingt wollten .. hab ich eine zusammengefaßte GUI eingebaut (noch nicht fertig)
> wird aktuell über Paramter -g aufgerufen (bei Parametersteuerung dann einfach irgendwo ein G in den ersten Parameter einbauen)
!!! unferig: Dateiöffnendialoge, D&D und noch einiges Anderes fehlt noch
zusammen mit den alten Dialogen sollte das Programm aber soweit lauffähig sein (auch wenn noch einige Änderungen anstehen)


Wer die neue GUI mal sehn will > "FileSplitter.exe -g" in eine FileSplitter.bat reinschreiben.
(aber nicht wunder ... bei Aufruf per Batchfile öffnet sich ja ein Consolenfenster und der FileSplitter schreibt da rein)

[bitsetter]

Hallo,

wollte nur mal unauffällig darauf hinweisen, dass dein Programm nicht mehr Win98 unterstützt.
Konnte im 1. Beitrag kein Hinweis darauf finden.

Fehlermeldung: "verknüpft mit dem fehlenden Export-KERNEL32.DLL:FreeUserPhysicalPages."

[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 :gruebel:
(sieht aber wohl nicht so aus :wall: )
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 :cry:

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:

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:

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:

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? :mrgreen:

[bitsetter]

Zitat:

Zitat von bigg

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

Ja ich :stupid:, 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. :oops:
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 :love:
[mindestens Delphi2006 nötig]