candera / hobocopy

An open source backup tool for Windows
http://candera.github.com/hobocopy/
MIT License
176 stars 52 forks source link

Command line switch for Version #37

Open techuser opened 13 years ago

techuser commented 13 years ago

Since there is four different versions of hobocopy that current exsists, for each OS and stable versus unstable. It would be helpful if there was a command line switch for version. "/version" so that users could know which version they are on.

Additionally, it would be helpful if a check for the Visual C++ Runtime version could be performed to inform the user that they need to install that particular version of the build.

candera commented 13 years ago

We appreciate the suggestion! I've been thinking about how nice it would be to have a single executable that had all four versions and the C runtime, and would just work for everyone.

techuser commented 13 years ago

I am not 100%, but I think you might be able to just detect the System Archtexture (32 or 64) and then do whatever is needed for the 32 bit flavor versus the 64 bit flavor. I have been using the "unstable" version for sometime, and it seems to be working okay. I would suggest just doing away with the prior two versions. That will at least simply things to some degree.

candera commented 13 years ago

I need to support at least three flavors: 32, 64, and 32 for XP. The issue is that there are different VSS libraries for each of those flavors.

candera commented 13 years ago

The related feature, BTW, is issue #21. I'll probably close this one in favor of that one, but I'll leave this one open for a while just in case I change my mind.

techuser commented 13 years ago

I see. Yeah, I am not sure how difficult it would be, but what about changing the various Functions to reflect the OS flavor and Volume Shadow Copy Service. So within the code of the single executable it would make a call for FunctionXP32 Blah, and then FunctionWin764Blah or whatever. It would be a pain to administer the different versions of the code, but I guess that would be the same as managing four different and separate builds.

I'm sure ideally, the optimal thing would be for Microsoft to release a Volume Shadow that works on all four that is somewhat standardized.

candera commented 13 years ago

That would work if there were one library with different entry points with those names. But the VSS SDK ships with four different libraries, and all the function names are the same.