MKS Source Integrity 7.5 compatibility
Windows visual diff and merge for files and directories
Brought to you by:
christianlist,
grimmdp
Menu
▾
▴
#1515 MKS Source Integrity 7.5 compatibility
I'm stuck using a ropey old version of MKS Source
Integrity (7.5) at work at the moment. This comes with
a really miserable differ. The only way to properly
replace it is to swap the "vdiff32.exe" executable with
another of the same name. Unfortunately, the command
line provided to it by MKSSI looks like this:
[ 0] C:\mks\mkssi\vdiff32.exe
[ 1] -n-t1|Revision
[ 2] 1.4|
[ 3] -t2|Revision
[ 4] 1.5|
[ 5] -d2
[ 6] |C:/WINDOWS/TEMP\Bui00001.bat|
[ 7] |C:/WINDOWS/TEMP\Bui00000.bat|
(Yes, it really does use both kinds of slash in pathnames!)
This patch looks for "vdiff32.exe" in argv[0], and then
constructs a new argv which WM can understand. Strings
are simply pulled out from between the pipe characters
and stuck in as either description tags or paths. The
new arg array is then processed as normal.
It's probably not the best solution, but it works. I
haven't tested it with any other versions; I don't even
know if later versions have the same problems. Maybe
someone will find this useful, though.
Patch to src/Merge.cpp in 2.4.2
Logged In: YES
user_id=631874
Thanks for a patch.
I don't think we want this patch as is - just for one tool.
But this is good idea to have as an configurable workaround.
Maybe simple .ini file to WinMerge folder with commandline
argument mappings per tool.
Logged In: YES
user_id=895855
You're right, it is really too specific to put in every build.
Having thought about it, what I would love would be a configurable list of
regular expressions that WM would try to match against if it can't understand
the command line given. It could then substitute a corresponding
replacement string, so then I could say:
match: -n-t1|([^|]+)|-t2|([^|]+)|-d2|([^|]+)| |([^|]+)|
replace: -dl"$1" -dr"$2" "$3" "$4"
But then that's quite a lot overhead for what is still (I guess) a niche problem.
Logged In: YES
user_id=1195173
Could you just write your own custom vdiff32.exe, which
parses its arguments, and then invokes WinMerge.exe?
Logged In: YES
user_id=895855
Well quite; and if fifty other people had the same problem as me, they could all
write their own glue program too. I'm sure I'm not the only Windows user who
has spent a frightening amout of time writing glue code; wouldn't it be nice if,
just once, there was a better way?
Logged In: YES
user_id=1195173
The better way is to reuse the solution, yes? That is, after
you do the work, let fifty other people copy or share you
solution.
But, you appear to be arguing that the only possible way to
reuse the solution is with a monolithic exe -- this is like
arguing that the only way to extend the linux kernel is to
add all new drivers in the kernel, not as modules -- it is
assuming that plugins (modules), wrappers, and so forth are
useless.
In this instance, in fact, I think a wrapper is probably the
best solution -- it surely seems the most obvious to me.
Can you explain why you dismiss that solution?
Being as you've already written almost all the necessary
code (the argument parsing), I don't think you're afraid of
the coding :)
Logged In: YES
user_id=895855
Well, I tend to believe that software should "just work." If a user has two
reasonably complimentary pieces of software (say, an SCM tool and a differ),
they should expect to be able to use them together without heading off to
Google to look for compatibility hacks. When you leave barriers like this up,
people just tend to give up and stick with what kinda-works. I think that
added complexity is sometimes (not always!) justified on the back end if it
saves the user messing around. After all, you only have to write the code once
(well, three or four times at most :-) , but many people will be using it many
times thereafter.
Since we're throwing out examples, consider the unix tar program. You can
get it to unarchive gzipped tars by piping the input through gunzip. Or,
latterly, you can just give it the gzipped file directly, and it will figure out the
right thing to do. Better or worse? I'd go out on a limb and say the only
people who might say "worse" would be those who maintain the project.
Of course I understand your argument, though. It's one of those issues where
there's no right or wrong answer, since both ways have advantages or
disadvanteges. Naturally I have no illusions of changing anyone's mind with
regards this this matter, and yes, you can rest easy with the knowledge that I
won't fork the project and try to embed an email client in it :-)
Logged In: YES
user_id=1195173
I was kind of assuming -- and I'm working out of ignorance
because I don't now MKS -- that MKS is somewhat of a small
market -- so that the analogous example would be adding
support for some less common compression format to tar. To
my knowledge tar only supports (the big) two compression
formats, and you have to pipe for any others. Actually I
don't know why tar supports bzip2 and gzip -- as piping is
so easy, if I were in charge of tar, I'd sure be inclined to
keep the compression isolated in the compression programs.
But I guess they went with the single-box - out-of-the-box
easy for newbies -- solution, which has an obvious appeal &
benefit. Hopefully behind the scenes, "tar -czf" is invoking
code from the gzip project, and not code someone copied and
pasted into the tar project :)
I'd offer to help you code a frontend solution, except, I
looked at the code you submitted, and it really likes like
almost what you need for a front end wrapper.
I don't think we can make it work out-of-the-box anyway,
probably, because the MKS users would have to tune
something, because we want to keep WinMerge working for the
larger group not using MKS. Well, I'm wrong, if we put in a
special hack just for vdiff32.exe invocations, which you do
mention, then yes it probably could work out of the box. But
I feel that clutters it too much with special-purpose code
that could be handled outside WinMerge.exe.
But to get close, if we had a wrapper that made invoking
WinMerge work for MKS -- just like what you did, only it
could be a frontend exe, then we'd just have to figure out
how it gets onto the user's computer. Maybe the wrapper
could be shipped with WinMerge, to get as convenient as is
reasonable?
Logged In: YES
user_id=895855
Well, if you're willing to include an additional "wrapper"
executable in the release (which would surprise me!) we
could have an almost ideal solution via the installer
program. The advantages of having an installer take care of
the ugly business of swapping the vdiff32.exe file outweigh
any reservations I have about the wrapper concept. If you
have a checkbox on a page of the installer (which defaults
to 'off' and doesn't even appear unless the user has MKS
installed) to control the installation of the wrapper, and a
corresponding uninstall which restores the original differ,
that's about as simple and unobtrusive as it can get from
the end user's point of view.
Logged In: YES
user_id=1195173
Kimmo, do you see any problem with this? I think that
including a wrapper to make it work more easily for MKS
doesn't really hurt the people who don't have MKS, and helps
the people who do have it.
Logged In: YES
user_id=631874
Sorry, I haven't been able to follow most of tracker items
past days (been busy at work).
I've nothing against adding wrapper executable. Its few
kilobytes or so, we have a lot more bloat elsewhere. Adding
new option to installer (and enabled only when MKS is
installed) sounds like a optimal solution. Unfortunately I'm
not very familiar with InnoSetup scripting - seier wrote
scripts to detect TortoiceCVS and other funny installer
stuff. And unfortunately he is not active novadays.
So if somebody can wrote installer script or help me with it
I'm all for it.
I agree we should have this kind of things working without
hours of googling and tweaking.
Logged In: YES
user_id=1195173
Donna/marijne,
Do you feel like writing the wrapper code for this? If not,
I could probably do it--let me know.
Logged In: YES
user_id=895855
Yes, sorry, I forgot about this one - I'll dig out the code on Monday. I think
the only problem I had was determining the installed location of WinMerge in
order to launch it. Do you know if there's a good way of doing this?
Logged In: YES
user_id=1195173
I don't know any way to find the installed location--I don't
usually install it myself, I usually put it onto a machine
with xcopy (just copying the directory to where I want it).
I was thinking you might put the vdiff32.exe in the same
directory as WinMerge(U), and then call it with a bare (or
relative) path?
Logged In: YES
user_id=895855
The problem is, vdiff32.exe has to be in the MKS directory (C:\mks\mkssi),
otherwise there's no way of invoking it.
Other than putting a copy of WinMerge in the MKS directory, I can't think of
any way for this launcher program to find WinMerge without knowing the
installed path. Perhaps the installer could write the path to the registry?
Logged In: YES
user_id=1195173
I agree the installer should write the path to the registry.
But, unfortunately, I don't think any of us current
developers are really skilled with the InnoSetup installer
source.
There is a kind of a workaround that I've found. I believe
that if the user runs the program interactively, and goes to
Edit/Options and goes to the system tab, then the code will
write an entry to the HKCU which contains the exe name. Yes,
it's kind of a weird set of requirements, but... :)
HKEY_CURRENT_USER\Software\Thingamahoochie\WinMerge
Name: Executable
Logged In: NO
Shell extension needs to know WinMerge executable location,
so it stores it. Since shell extension is installed by
installer there is no requirement for first to open
Options-dialog. Registry value should be there by installer.
-Kimmo
(don't want to loging for just this one message)
Logged In: YES
user_id=631874
Installer always writes that key mentioned. Not just for
shell extension. So only case it doesn't exist is user
didn't use installer and hasn't enabled shell extension from
options.
Options dialog writes this value when shell extension is
enabled. So if value didn't exist (user didn't install
WinMerge with installer) Shell Extension works. And it also
helps in cases one wants to use WinMerge.exe from other
folder than installation folder.
Logged In: YES
user_id=1195173
So... where is the installer key?
I tried grepping the ShellExtension source for
HKEY_LOCAL_MACHINE, but the only code I saw was for registry
keys like this:
Software\\Microsoft\\Windows\\CurrentVersion\\Shell
Extensions\\Approved"),
Is it set by the installer somewhere? I tried grepping the
InnoSetup directory for HKEY_LOCAL_MACHINE and got no
promising hits, but they might call it something else in
InnoSetup language -- I duno :)
Logged In: YES
user_id=631874
Line 449 of WinMerge.iss:
Root: HKCU; SubKey: Software\Thingamahoochie\WinMerge;
ValueType: string; ValueName: Executable; ValueData:
{app}\{code:ExeName}
Logged In: YES
user_id=1195173
That "HKCU" in that line doesn't look very promising -- I
mean, installer has to be run in Admin profile, I think, so
stuff in HKCU for Admin is inaccessible to normal users, so
that won't be any use for programs by regular users? Don't
we need to get path from a HKLM key, where it is accessible
to WinMerge and other programs when run by regular users?
Logged In: YES
user_id=895855
I've attached a project for the wrapper program. It looks in HKCU\Software
\Thingamahoochie\WinMerge for the installed location - hopefully that's ok.
There's also a driver program in there which invokes the wrapper in the same
way as MKS for testing purposes.
Logged In: YES
user_id=1195173
Kimmo, if we fix this wrapper to look first for that key in
HKLM and then if it's not there, look for it in HKCU, then
this wrapper should work against both current broken setup
and future fixed setup (when/if someone fixes installer to
work on NT/2000/XP systems, where path must be written to HKLM).