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

SignUp Now!

Dropping 32-bit support in Take Command & TCC?


Staff member
I'm starting on the core of the v26 update, and I'm thinking that it's time to drop x86 support in future versions. It's (considerable) extra aggravation to build, test, & create the installer code for x86, and the latest installer analytics are showing 32-bit installs hovering a bit below 2% of the total. (Most of those seem to be pirated copies in China, Russia, Iran, and a handful of other countries.)

If you have any compelling arguments why I should maintain x86 support, now's the time to present them!
Had there been a straight-forward method of installing the 32-bit version of TCC/TCMD on a 64-bit version of Windows, I would have installed the 32-bit version of TCC/TCMD.

It is fortunate that Microsoft still provides a 32-bit version of CMD EXE and a 32-bit version of PowerShell EXE on their 64-bit OS.

For these (and other) reasons:

PSHELL and out-of-process servers

PSHELL: Use 32-bit from 64-bit

32-bit out-of-process servers from 64-bit TCC via PSHELL

PSHELL switch for 32- or 64-bit

Using a 32-bit In-Process COM Server DLL from 64-bit TCC

Can 32-bit TCC be run on a system with 64-bit TCMD and TCC installed?

Had there been a straight-forward method of installing the 32-bit version of TCC/TCMD on a 64-bit version of Windows, I would have installed the 32-bit version of TCC/TCMD.
It's not hard if you have an installation on a 32-bit machine (virtual maybe?) ... just copy the install to the 64-bit machine, start it up, and register it. The first time you'll probably need to edit TCMD.INI a bit (maybe TCSTART/TCEXIT). Thereafter just don't copy those files. I'm pretty sure updating must be done on the 32-bit machine.

I have them both on Windows 10. But I have no reason to use the 32-bit one except to compare it to the 64-bit one. As Rex said, the 64-bit version is faster. Often the speed difference is only 1-2%. But for some things it can be over 10%.

Rex, is there anything internal to TCC that will tell me whether it's 32 or 64 bit?
These are actually some arguments against continuing to support it:

1) Some background--I work at a lawfirm where the owner insists on using a hobbyist DIY DOS database manager that was never popular, to write a database system even though she's not a programmer. Symantec abandoned the database manager in 1995, and we use an earlier version developed 1986-1991. The database manager has a proprietary file format, doesn't allow multiple tables or screen sets, has no query language, no programming language, no IDE, cannot read or write any data format other than plain ASCII, does not have strong data typing, and on and on and on. And she's not gonna get anything modern even though since mid-2014 she's been told by me and every consultant that she needs a modern Windows-based program written by a developer.

I'm 69, a lawyer with no formal I.T. training. I've told her straight out "Whenever I leave, you won't be able to find any competent I.T. person. No one under 55 knows anything about DOS--and they won't be interested in learning. Plus, any I.T. person will know that working with this stuff 2-3 years would be career suicide. "At your current job, do you work with C? No. C++? No. Java? No. SQL? No. Python? No. ..." They couldn't even list DOS on a resumé."

2) Related to that (and relevant to this topic), I've told her, "Microsoft is fully integrating Linux into Windows--but only in 64-bit Windows. They're doing it to get access to billions of lines of Linux code and hundreds of thousands of routines. Within 2 years, ... maybe 3 at most ... some client (major hospital systems) is going to tell us they've upgraded their system and we need to use a different on-line interface program--that only runs on 64-bit Windows.

"Plus, most major software vendors are no longer supporting 32-bit or already plan to phase it out. Once WSL is an integral part of Windows, within 2 major versions the software companies' developers will start using that--they won't bother writing separate equivalent routines for 32-bit versions."

3) Yes, there are "mission critical" applications that only run under 32-bit and no longer have vendor support and there is no equivalent replacement. But does that mean that a relatively small company with a narrow specialized customer base should continue manufacturing 5-1/4" floppy disk drives? Or 19" CRT monitors? Or VCR's? Or 1MB RAM sticks?

(For "You young-uns" that's one MEGABYTE sticks, not one GIGABYTE. ... Ask your grandpa ...)

And does that mean the company should continue developing and manufacturing for the customers who could get something equivalent but just "continue to hang on"?

4) Realistically, at some point Microsoft is going to stop developing and supporting 32-bit Windows. They have already publicly indicated they want to move to "Windows As A Service". Can you really see Windows 10 ver 2410 still having a 32-bit version--that can't tie in to WSL? And that's just 5 years down the line.
We're getting off-topic, but have you tried running it in DOSBox? I use that, with the D-Fend Reloaded frontend to run some old DOS industrial control with great success.
It's a multi-user database. She really needs to get something modern ... "ain't gonna happen" ... The basic program is garbage -- re-read the description of all the things it doesn't have.

Keep in mind--we're not talking FoxPro or dBase or Paradox, or Lotus 1-2-3, or a program that was ever somewhat popular. Even when it was under active development--"Nobody's ever heard of this! Who puts this out? Symantec has a database product??"

Continuing development of 32-bit applications and utilities for more than maybe 1-2 more versions is basically just a waste of limited development resources. Once WSL is fully integrated, any organization expecting to continue with 32-bit as a core part of its tech long term is just heading off a cliff.

Similar threads