FileSplitter v2.0 (15)

[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]