And oddity re the 32-bit TCC on a 64-bit system...

[mathewsdw]

I've got some very old (the initial versions of some of them were written in the late 80's) C++ programs that not only are not 64-bit, they were initially written when the standard Intel processor still used segment registers. These programs all work perfectly except for one small constraint (coming up) and i use many of them on a several times a day basis so they are important to me, and I really don't want to mess with their code much less re-write them. The small constraint? Some functionality is broken when run in a 64-bit TCC session. (I won't go into the reasons why here, it's not that I'm trying to be mysterious, it's more that it's somewhat esoteric and really completely besides the point.) So I generally have a 32-bit TCC session running on this 64-bit system in which to run these programs.

So now on to the problem: In installing the latest 32-bit versions of Take Command/TCC (again, in parallel with the 64-bit version) the installation always fails with the following error: Could not set file security for file 'Y:\Config.Msi\'. Error 3. Verify that you have sufficient privileges to modify the security permissions for this file. Now I'll note that I had a drive Y: in the distant past (I do no longer) and the install process can not even successfully start unless I subst Y: to C:\ (I believe I need to do this both in Administrative mode and User mode) which I consider to be only a relatively minor problem. But even after doing that and changing the drive letter to "C:" in the "install to" location I still get the above error, and the install program rolls everything back. The bottom line result of this is that my 32-bit Take Command/TCC is rather old ("Ver" reports TCC 14.02.38 Windows 7 [Version 6.1.7601]) which sort of bugs me (no pun intended).

Any guesses as to what's going on here and what I can do about it?

 

[Charles Dye]

I think I'd begin by using RegEdit to search the registry for instances of "Y:\" ....

 

[rconn]

There isn't anything named "config.msi" in the Take Command installer (either 32-bit or 64-bit). Config.msi is a hidden folder created by the Windows Installer when files are being installed or updated (from any installer, not just Take Command's), so that they can be rolled back if an error occurs.

I don't know how you created this on your Y: drive, but you're going to have continuing problems trying to install anything until you remove that setting (probably in the registry).

 

[mathewsdw]

Thanks guys! Took me a while because there were more than 40 JPSoft references to drive Y: in the registry, but deleting them all fixed the problem and I've seen no bad results as of this minute.

Just an oddity: I don't have any recollection of ever installing anything on drive Y: and I don't know why I would have ever done that (it was I thumb drive, and I've never had any interest in a "portable" Take Command/TCC). But that was the facts. Just another case of my general incompetence due to bad memory, I suppose.

And another oddity I'd like to mention just because it's strange: there were also 7 or 8 drive Y: references by Mozilla Firefox registry entries. However, Firefox continued to (and always has) run fine. However, I changed all of the "Y:"'s to "C:"'s (which is and always was valid for this purpose).

 

[mathewsdw]

On thinking about it, I decided not to be too mysterious as to what these programs are trying to do and why they are failing (and why the fix really isn't trivial). What these programs do is to maintain "state data" of various kinds in environment variables of the "parent" process (TCC instances in this case). (This state data is unique to each instance of TCC.) In order to do this, and excuse me if this is a bit esoteric, it creates memory shared between the program and the parent process (TCC session), puts the data needed to set the environment variable into that shared memory, "injects" a DLL into a "remote thread" in the parent process, and executes a procedure in that DLL that reads the shared memory and uses the data contained therein to set the environment variable(s) in the "remote" TCC session. This fails because the program is 32-bit and both trying to open the 64-bit parent TCC process in 32-bit mode and creating a remote 32-bit thread in the 64-bit parent process fail (of course). And the DLL itself is 32-bit, also of course. If I were to fix this, it would have to be done by allowing a 32-bit program to detect the need for and do this stuff as I'm absolutely unwilling to create separate version(s) of the program(s) for both 32- and 64-bit modes. So there it is.

But one of the reasons I mention this is sadly humorous: my bad memory. It turns out that the programs are written so that if the above fail they will create a file in the %Temp directory whose name includes the PID of the parent TCC session that contains the data to be saved, and it does this automatically and without notice (other than the above mentioned error messages on first run in any given TCC session). And before trying to do anything with environment variable(s), it checks for the existence of this file and uses it if it exists (no messages are produced in this process). And since I hadn't remembered this I had completely forgotten that the program(s) were actually running fine. The only problem with this is that there is no easy and automatic way at the present moment to delete these temporary files - in principle they can last forever. However, and ironically, I have existing code (a TCC batch file, believe it nor not) that deletes specific PID-named files in any given directory for PIDS that do not currently exist, and I can rather quickly and easily modify this code to delete the files for any one of the programs.