Wow first of all thanks for replying and for having a deeper look and testing DFHL.
About the history of DFHL.
I need to say that I just ask 'Hans Schmidts' who did some enhancements for the source code. Converted the sources from Visual Studio 6 to Visual Studio 2015...and put it to Github.
Before receiving the sources for v2.5 I did just for fun a reverse engineering project using IDA 7 to decompile Version 2.5 and the sources from v 2.0 to recover restore the names and class structures.
Nice to see what is possible.
However when getting the source I discard this project. However by that i got some rough overview about the sources all classes and functions.
Some oddity about this source is that it included a copy of the Windows 'CreateHardLink' API in ('Hardlink.cpp') that can be uses instead of just calling this API. (It is though for old systems like Windows NT whose kernel already had the ability to do hard links but there was no really user API for it)
Usher wrote:I can't see any link to download exe there.
There is that pink/blue line (language bar) above in the middle it there is a link "3 releases". Just in between with branches and contributor.
There you can Dl the exe.
But yes sorry old problem this Exe won't run on Windows XP and below.
Mainly because of the OperatingSystemVersion that is set by the linker in the PE-Header.
[face=courier]->Optional Header
Magic: 0x010B (HDR32_MAGIC)
MajorLinkerVersion: 0x0E
MinorLinkerVersion: 0x00 -> 14.00
...
MajorOperatingSystemVersion: 0x0006
MinorOperatingSystemVersion: 0x0000 -> 6.00
MajorImageVersion: 0x0000
MinorImageVersion: 0x0000 -> 0.00
MajorSubsystemVersion: 0x0006
MinorSubsystemVersion: 0x0000 -> 6.00
Win32VersionValue: 0x00000000
SizeOfImage: 0x0005F000
SizeOfHeaders: 0x00000400
...
[/face]
I my care for that in further builds. Well as a quick hack open the Exe in a Hexeditor look for 'PE' at the beginning and then watch for two 06 00 00 00 as show below:
[face=courier]
00000060 74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20 t be run in DOS
00000070 6D 6F 64 65 2E 0D 0D 0A 24 00 00 00 00 00 00 00 mode. $
00000080 50 45 00 00 4C 01 05 00 CC 79 3E 5B 00 00 00 00 PE L Ìy>[
00000090 00 00 00 00 E0 00 02 01 0B 01 0E 00 00 3C 04 00 à <
000000A0 00 90 01 00 00 00 00 00 07 7D 00 00 00 10 00 00 }
000000B0 00 50 04 00 00 00 40 00 00 10 00 00 00 02 00 00 P @
000000C0 06 00 00 00 00 00 00 00 06 00 00 00 00 00 00 00
[/face]
change this two 06 to 04 and save it. Now the Window XP-Loader should at least go on. Well that's what editbin does.
Usher wrote:
1. Run DFHL 2.0 (old version) under Windows XP set to Polish.
- Doesn't display any Polish or Russian character, just ends lines in such places.
- Seems to support only 32 K files, for larger directories ends with a crash.
Okay proper char encoding decoding is always a hidden bug subject as well as proper exception handling. As far as I saw DFHL uses strictly unicode Strings and Api's. However what is probably missing is to also decode strings that are read and encode strings that are written out.
DFHL has some exception handling, but only for C++ exception - but any zero pointer or access violation is not trapped by that and just leads to a crash. I'm onto it adding some of this nasty Ms __try __except blocks at critical points so the program goes on.
... and of course I'll try to fix the bug and fix it.
please attach a zip file with some sample files to reproduce & test this bug
... or even better file an issue on the DFHL-Source codepage on GitHub.
Usher wrote:
- You can't select which file will be kept and which one will be replaced with link. I prefer to keep a copy with older timestamp, bot another user may prefer to keep files in a certain "master" directory.
Before hardlinking files are checked to be the same so it should not matter that much which of both file is picked. Okay regarding file fragmentation and assuming that old file are less fragmented than new ones it is maybe important which file DFHL picks.