By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Upgrade from v15 to v21


I have a question about upgrading my v15 to the current v21.

Is TCC v21 backwards compatible with TCC v15 scripts? One point of my question is that I remember seeing some time back that pseudovariables were deprecated, and I use them in several of my scripts.

I'm only interested in the non-TotalCommandWindow side (tcc.exe) and not the Total Command Window side (tcmd.exe) side. I cut my teeth on 4DOS in the 1980s. (I have a wire-bound 4DOS manual that includes an Electronic contact [BIX "trawson"] which I don't think is still active.) I looked at the TCMD Window once but have never used it - I exclusively use stand-alone TCC scripts.

My motivation for upgrading is twofold: 1) it's about time, and 2) I have a need to read a Hexadecimal byte from a file in such a way as to do a "%@convert[16,10,%var]" on it. With v15 I can use TPIPE to put it (e.g. 1C) in a one-byte file, but I can't get it out as its literal content (1C) to put in a variable.

No, I'm not in the mood to be scolded for putting two unrelated issues in one Forum thread. If the convert one is deemed unacceptable - ignore it. I'm still interested in the compatibility question.


V21's help says, of both pseudovariables (= and +) ...
... was introduced to allow running batch files from COMMAND.COM and 4DOS, and has been obsolete for years. It is deprecated as of Take Command v17, and most support has been removed in v20.

I can't get %= to do anything. %+ works in a very simple test:
v:\> echo 123 %+ echo 456
Thank you Vefatica, your point is well taken. I’m glad my thread inspired you to RTFM v21 about pseudovariables: "It is deprecated as of Take Command v17, and most support has been removed in v20" which sets off alarm bells to everybody considering using pseudovariables and emphasizes the wisdom inherent in replacing all of them to avoid the disaster of having scrambled command lines if/when they are phased out. Your examples clearly depict a practice to be avoided and I’m sure everybody seeing your comments will be thankful to you for including them.

It also "corrects" my forum protocol infraction of putting two issues in one thread. With your kind efforts, the thread now has but one issue consistent with the theme of the Subject:

Except for pseudovariables for which most support has been removed, is all the rest of TCC v21 backwards compatible with TCC v15 scripts?
Except for pseudovariables for which most support has been removed, is all the rest of TCC v21 backwards compatible with TCC v15 scripts?
I'd like to say simply "Yes", but I haven't tested everything. The few scripts that I use often pre-date v15. I haven't used the pseudovariables since 4DOS so they have not been a problem. And over many years, I don't recall having to re-write batch files because of new versions (I have 4NTv8 through TCCv21 installed).

What's your OS, newbie? Support for older versions of Windows has dwindled. I'm still OK with Windows 7, but just barely. There's no reason to uninstall your older version of TCMD/TCC. Just install v21 in a different place. You get a 30-day trial. That should allow you to figure out if v21 is right for you; if it's not, you'll still have v15 to fall back on.
It occurred to me that I left this thread in a bit of a lurch by not addressing my dismissal of the rogue #2 issue. There were three values I was interested in, plus I wanted to know if any value changed. I created three one-byte binary files each with one of the three values. Anticipating TCC’s inability to provide the tools to get done what I wanted, I realized that I could just get the CRCs of those three reference binary file and use the CRCs of a subject one-byte file to determine if it contained one of the values of interest. And, I could just monitor the CRC of the subject file for changes to the file’s content.

Regarding Vefatica’s recent update, Well, yes, I am using Windows 7 Pro. However, I don’t hold it in any less of a viable OS status than any other System-Requirements OS - “TakeCommand and TCC/LE are compatible with the CMD prompt and command line applications in Windows 7, Server 2008R2, Windows 8, Server 2012, and Windows 10, and are available in 32-bit and 64-bit versions. ...” I expect Win7 to persevere as Win-XP did. In fact, I used XP until my monitor went screwy and I corrupted the OS trying to boot with a monitor that would not function reliably. That's when I got Win7.

I am VERY interested in how to deal with two versions of TCC on the same computer. I can handle the mechanics of the installation itself and (presumably) separate TCSTART.btm files, but I don’t know how the OS will distinguish between which version to use for *.btm files. It would PROBABLY just be a matter of changing the association between the tcc.exe in the v15 directory -or- the one in the v21 directory in the short-term for testing purposes.

I would be interested to know if you have actually done that or if it just seems like a good idea to try. It’s been my experience that The Devil is in the Digits, and the Registry Digits are the ones that I’m concerned about. I would expect (as is the norm) the new version to install itself over the old version - but maybe not? But, if they share resources and update changes in the resources, will that interfere with the other version?

Thank you for taking the time to participate in this thread, I do appreciate it.
As I said, I have 4NTv8 through TCC v21 installed. I have
v:\> assoc .btm

v:\> ftype tcc.batch
tcc.batch="G:\tc19\tcc.exe" /c "%1" %*

That could just as well be any TCC from v13 to v21 (they'd all work). But I never rely on those associations. When I want to run a BTM, I give its name on a TCC command line, and whatever is the current TCC runs it. I never double-click on a BTM.
Both v15 and v21 have TCCBATCH.BTM to facilitate changing the association. That script has sections for .BAT, .BTM, and .CMD. The .BTM section looks like this:
echos Do you want to make TCC the default handler for .BTM files [Y/N] ?
inkey /k"yn[enter]" %%var

iff "%var" eq "y" then
        assoc .btm=TCC.Batch
        ftype TCC.Batch="%_cmdspec" /c "%%1" %%*
"%_cmdspec" refers to the currently running TCC, so you could change the association by running TCCBATCH.BTM in whatever version you want to become the handler for BTMs.
In a moment of naiveté, I asked for free help via the "support" form. Here's what I got:

= = = = = = = = = = = = = = = = = = = = = = = = = = =
Extended Support can only be purchased (initially) in combination with a new or upgrade copy of Take Command or TCC. After the initial purchase, you can renew Extended Support each year without an upgrade order.

In terms of backwards compatibility, it’s impossible for v21 to be 100% compatible with v15, if only because of the new commands in v21 potentially interfering with aliases or external commands with the same names in v15. Also, we’ve made some minor changes in post-v15 versions to allow for compatibility with changes in CMD since v15.

That said, we have included TCMD.INI options to allow for backwards compatibility in 99.9% of the cases. It’s possible if you have extensively used (long) obsolete COMMAND.COM features, you might have to simplify a couple of lines of code in your batch files, though in all probability you can set an INI directive to continue using the obsolete / wrong syntax.

You can install v21 without affecting your v15 installation in any way, provided you don’t try to install it in the same directory.

Rex Conn
JP Software
= = = = = = = = = = = = = = = = = = = = = = = = = = =

I think the TCMD.INI approach will work with few adjustments to any v15 aliases or functions I've created. I can write a script in each version that will swap v15 and v21 TCMD.INI in-and-out in each version without problems. In each "From" version, the "Switch to Other Version.btm" will be in memory to change to the "Other" version on the fly. When that .btm in memory is done - voila!- TCC/TCMD are now the formerly "Other" version.

I think I can just -
1. Save off the v15 TCMD.INI to use later (with a secure copy tucked away somewhere).
2. Install v21, which will "upgrade" the TCMD.INI. Save the TCMD.INI somewhere.
3. Diddle with v21 enough to get it running with a "Hello World" script and a "Swap TCMDini v21 to v15.btm" script to swap the TCMD.INI.
4. Highlight the "Swap TCMDini v21 to v15.btm" and put a finger on the "Enter" key.
5. Close my eyes, Pinch my nose, Cross my fingers, Hold my breath.
6. Press the "Enter" key.

If that works, v15 should be - Should Be - (SHOULD BE) back up and running. I can write a script to go v15>>v21 and develop v21 slowly to check for compatibility.

A few things come to mind to wonder about.

1. I think the TCCBATCH.BTM will be okay. It's in the "C:\Program Files" installation directory [v15 -and- (presumably) v21], not in the TCMD.INI directory "C:\Users\Administrator\AppData\Local\JPSoft\TCMD.INI"
2. Likewise the TCMD.EXE is also in the installation directory.
3. Both Vefatica and Mssr. Conn have stated that multiple versions will work properly on one machine.

I welcome any comments or recommendations. The verbose nature of the thread update is to help me THINK thru the subject and to facilitate details and considerations by helpful forum contributor(s) based on the framework I've presented here.

Similar threads