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

May 24, 2010
855
0
Northlake, Il
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?
 

rconn

Administrator
Staff member
May 14, 2008
12,344
149
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).
 
May 24, 2010
855
0
Northlake, Il
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).
 
May 24, 2010
855
0
Northlake, Il
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.
 
Similar threads
Thread starter Title Forum Replies Date
M An oddity that's a little bit scary... Support 6
samintz WAD DO /s /a:d oddity Support 7
vefatica Registry oddity Support 14
D v23 environment oddity Support 3
gentzel CompletePercents oddity Support 1
MickeyF @filewrite oddity (to me) Support 5
Fross Build 46 Oddity Support 5
M Just a minor oddity... Support 9
M A real oddity but not a real problem... Support 8
Dan Glynhampton Documentation v15 help: Another mailto: link oddity Support 0
M WAD An oddity with the "Dir" command... Support 2
D Environment variable oddity Support 12
M An oddity... Support 5
Charles Dye @ERRTEXT oddity Support 6
Charles Dye INPUT prompt oddity Support 5
Peter Murschall Single-line Do-CMD is a bit uncooperative. Support 6
Joe Caverly VBEEP on 64-bit Support 3
vefatica SETP usually fails with a 32 bit process Support 4
rconn Dropping 32-bit support in Take Command & TCC? Support 14
dcantor How to? Can 32-bit TCC be run on a system with 64-bit TCMD and TCC installed? Support 6
T 32 and 64 bit simultaneous portable versions Support 2
vefatica Make FFIND a bit more friendly? Support 14
CWBillow Everything.exe - 64-bit? Support 8
S 32-bit Take Command v22 install for thumb drive Support 1
Per TCC/LE 14 64-bit won't start on Windows 10 Insider Preview 17063 (171213) Support 12
Joe Caverly SETP and 32-bit process Support 2
gworley How to? Take Command 20 64 bit vs 32 bit Support 1
mikea Documentation Consider expanding the docs for 'Everything' a bit Support 10
T 64 bit TCCLE appears to crash when opening tcc.exe from within tcc.exe window Support 7
vefatica Can a subroutine return a 64-bit integer? Support 4
M 64-bit plugins? Support 1
rconn News Take Command 16.03.54 32-bit installer Support 0
rconn News Take Command 16.03.54 32-bit installer fix Support 0
MickeyF problem using COM object in VBScript from v16 x64 TCC but not from v15 32-bit TCC Support 4
JohnQSmith Installing TCMD16 on 32 bit XP Support 12
D New 64-bit install goes to Program Files x86 Support 3
F How to install 64-bit after having installed 32-bit on Win7 Support 2
Dan Glynhampton Bad link to 64 bit RC1 download Support 0
C Advantages of 32 or 64 bit TCMD in 64 bit Windows 7 Support 3
C How to determine if system is 32 or 64 bit? Support 5
M How to? Identify 64-bit and 32-bit TCC sessions... Support 7
M WAD A bit of strangeness related to Unicode-marked file not being Unicode Support 2
M A bit of a complaint regarding @FileDate and @FileTime Support 3
K_Meinhard Take Command v13 64-bit Support 9
K_Meinhard 64-bit installer Support 3
M Another bit of weirdness.... Support 0
M A little bit of strangeness with @Char... Support 3
J CTRL-C does not work on Windows 7 64-bit Support 3
S Take Command LE (32 bit) locking up several times a day Support 14
S 64-bit version use? Support 5

Similar threads