XYplorer Beta Club

nas8e9 wrote:

anatter wrote:But no one how replace WE with XY would complain if XY don't show an item in a context menu when it was not shown in WE.

I'm not quite sure what you mean by this last sentence. If I read back your posts, you'd like two things:
1. Supporting the same shell extensions as WE. I think we agree that the different bitness of WE vs. XYplorer makes that impossible. As posted earlier, replacing HashTab with the similar HashCheck Shell Extension and the 64-bit version of 7-Zip with the 32-bit one should relieve some of the pain; I do understand those are not your only missing shell extensions and replacement won't always be possible or affordable.
2. As for pruning XYplorer's context menu (I think that's what you also requested?), did you take a look at Configuration > Extended > Context Menus?

nas8e9 wrote:The other way is to have the checksum (copied from a web page or whatever) and comparing it to the file checksum. Combined with different case being used sometimes, it would be very useful to be able to paste it in XYplorer and see whether it matches (comparing two hashes by sight is slightly awkward, again especially if different case is used).

nas8e9 wrote:Regardless of the above, an easy way to copy the hash from XYplorer would be great.

admin wrote:

nas8e9 wrote:The other way is to have the checksum (copied from a web page or whatever) and comparing it to the file checksum. Combined with different case being used sometimes, it would be very useful to be able to paste it in XYplorer and see whether it matches (comparing two hashes by sight is slightly awkward, again especially if different case is used).

So pop an input dialog, user pastes Hash and clicks OK, then pop a msg "Same" or "Different", right?

nas8e9 wrote:Regardless of the above, an easy way to copy the hash from XYplorer would be great.

You mean create e.g. md5 hash of the current file and copy it to clipboard?

nas8e9 wrote:

admin wrote:

nas8e9 wrote:The other way is to have the checksum (copied from a web page or whatever) and comparing it to the file checksum. Combined with different case being used sometimes, it would be very useful to be able to paste it in XYplorer and see whether it matches (comparing two hashes by sight is slightly awkward, again especially if different case is used).

So pop an input dialog, user pastes Hash and clicks OK, then pop a msg "Same" or "Different", right?

nas8e9 wrote:Regardless of the above, an easy way to copy the hash from XYplorer would be great.

You mean create e.g. md5 hash of the current file and copy it to clipboard?

Yes, please to both.

admin wrote:

nas8e9 wrote:

admin wrote:

nas8e9 wrote:The other way is to have the checksum (copied from a web page or whatever) and comparing it to the file checksum. Combined with different case being used sometimes, it would be very useful to be able to paste it in XYplorer and see whether it matches (comparing two hashes by sight is slightly awkward, again especially if different case is used).

So pop an input dialog, user pastes Hash and clicks OK, then pop a msg "Same" or "Different", right?

nas8e9 wrote:Regardless of the above, an easy way to copy the hash from XYplorer would be great.

You mean create e.g. md5 hash of the current file and copy it to clipboard?

Yes, please to both.

Back from the lab: I wrote a nice interface but then had to learn how slow the MD5-hashing is. What speeds do you expect say for a 10MB file?

nas8e9 wrote:I'm seeing times of less than 0.2 seconds (on a fairly speedy quad core) using 2BrightSpark's HashOnClick for both MD5 and SHA1 for 10 MB files. 1 GB files average around 11 seconds.

I hate to say this, but I'm wondering whether it's a good idea for XYplorer to offer hashing given it being limited to a single thread. I'm seeing a run time of over 30 seconds for an average-sized Linux DVD (my main use for this), during which time XYplorer presumably wouldn't be able to do anything else. If XYplorer's implementation were slower than the above, it might get a bit unworkable?

admin wrote:Yes, I have to agree. I will still see if I can improve the speed of my MD5 a bit...

Anyway, I have added an undocumented scripting function called comparehash [file=curfile]. Select a file and run ::comparehash. You should quickly understand what it can do for you.

admin wrote:Anyway, I have added an undocumented scripting function called comparehash [file=curfile]. Select a file and run ::comparehash. You should quickly understand what it can do for you.

nas8e9 wrote:

admin wrote:Yes, I have to agree. I will still see if I can improve the speed of my MD5 a bit...

Anyway, I have added an undocumented scripting function called comparehash [file=curfile]. Select a file and run ::comparehash. You should quickly understand what it can do for you.

It's very nicely done, but somehow VB doesn't seem to be the best language to write a hash function in (10 times slower for the same file size)... Nevertheless, thank you!

nas8e9 wrote:

admin wrote:Anyway, I have added an undocumented scripting function called comparehash [file=curfile]. Select a file and run ::comparehash. You should quickly understand what it can do for you.

There does seem to be a size limitation? Running comparehash on a 1,56 GB file raises an error 7 (Out of memory).

Assuming this is due to a limitation rather than a bug, would it be an idea to have comparehash check the file size and aborting more gracefully if it's too large?

admin wrote:Ah, the old myth again... No, this has nothing to do with language. VB is compiled to native code like any other serious language.

The reason is that I took the MD5 code I'm using from some website without optimizing it (speed was not important here up to now). Wait till I'm done with my tuning...

nas8e9 wrote:

admin wrote:Ah, the old myth again... No, this has nothing to do with language. VB is compiled to native code like any other serious language.

I was assuming more along the lines of a sprinkling of assembly code in other apps . Having said that, I had forgotten previous posts in which you provided that information.

The reason is that I took the MD5 code I'm using from some website without optimizing it (speed was not important here up to now). Wait till I'm done with my tuning...

If you do want to beef up this area of functionality, I'd personally have use for the SHA family. I'm just not sure I'd use it for large files given that hashing blocks XYplorer until completion and even dedicated hashing apps take a non-trivial amount of time. Taking it out-of-process would solve that, but that's probably too large an investment for a niche function.