tpipe and MSVCR110.dll TCC x64 Build 44??

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
Reference previous thread on this subject:
<http://jpsoft.com/forums/threads/tpipe-requires-msvcr110-dll.4989/>

The problem still exists after installation of TCC x64 build 44 [AND the Visual Studio redistributable]!

Code:
[]ver /r
 
TCC  15.01.44 x64  Windows 7 [Version 6.1.7601]
TCC Build 44  Windows 7 Build 7601  Service Pack 1
Registered to . . .
[]find \windows\msvcr110*
C:\windows\System32\msvcr110.dll    <=====
 
      1 file
 
[]tpipe /h
Immediately following [ENTER] for the 'tpipe' command, a system error popup occurs with the message
Code:
    The program can't start because MSVCR110.dll is missing from
    your computer. Try reinstalling the program to fix this problem.
 

rconn

Administrator
Staff member
May 14, 2008
10,291
90
#2
This is new behavior from Microsoft. Apparently they're ramping up their "XP must die" activities -- they've now killed XP compatibility in three different places in VS 2012. I think the only workable solution is to drop back to VS 2010; unfortunately that'll take a couple of days to manually convert all of the projects.

TCMD v16 (now in development) will definitely drop XP support. It's not feasible to develop new products for a platform that the manufacturer is doing everything it can to kill.
 
#3
This is new behavior from Microsoft. Apparently they're ramping up their "XP must die" activities -- they've now killed XP compatibility in three different places in VS 2012. I think the only workable solution is to drop back to VS 2010; unfortunately that'll take a couple of days to manually convert all of the projects.

TCMD v16 (now in development) will definitely drop XP support. It's not feasible to develop new products for a platform that the manufacturer is doing everything it can to kill.
From http://www.microsoft.com/visualstudio/eng/products/compatibility

"Visual Studio 2012 will also target earlier platforms such as Windows XP and Windows Server 2003 so you can create new apps or modernize existing apps that execute on earlier versions of Windows while leveraging the enhanced development tools, quality enablement and team collaboration capabilities in Visual Studio 2012"

Joe
 
#4
This is new behavior from Microsoft. Apparently they're ramping up their "XP must die" activities -- they've now killed XP compatibility in three different places in VS 2012. I think the only workable solution is to drop back to VS 2010; unfortunately that'll take a couple of days to manually convert all of the projects.

TCMD v16 (now in development) will definitely drop XP support. It's not feasible to develop new products for a platform that the manufacturer is doing everything it can to kill.
From http://msdn.microsoft.com/en-us/library/vstudio/jj851139.aspx

"The Visual Studio 2012 - Windows XP (v110_xp) platform toolset that's included in Visual Studio 2012 Update 1 is a version of the Windows 7 SDK that was included in Visual Studio 2010, but it uses the Visual Studio 2012 C++ compiler. It also configures project properties to appropriate default values—for example, the specification of a compatible linker for down-level targeting. Only apps that are created by using the vs110_xp toolset support Windows XP and Windows Server 2003, but those apps can also support Windows Vista, Windows 7, Windows Server 2008, Windows 8, and Windows Server 2012."

Joe
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,482
44
Albuquerque, NM
prospero.unm.edu
#5
This is new behavior from Microsoft. Apparently they're ramping up their "XP must die" activities -- they've now killed XP compatibility in three different places in VS 2012. I think the only workable solution is to drop back to VS 2010; unfortunately that'll take a couple of days to manually convert all of the projects.
I have to wonder why you ever update VS!
 
#6

rconn

Administrator
Staff member
May 14, 2008
10,291
90
#7
From http://blogs.msdn.com/b/vcblog/arch...g-with-atl-and-or-statically-linking-mfc.aspx

"Fix: Visual Studio 2012 Update 2 breaks Windows XP targeting with ATL and/or statically linking MFC"

"This issue has been fixed in Visual Studio 2012 Update 3 RC1. If you encounter this issue, please download and install this update."
I already am running Update 3 RC1.

But that's not this (new) problem -- Microsoft just changed the VS2012 redistributables installer to only run on Vista+. (I had to switch to the redistributables because Microsoft broke static linking with Update 2. Now they've broken dynamic linking as well.)
 
#8
I already am running Update 3 RC1.

But that's not this (new) problem -- Microsoft just changed the VS2012 redistributables installer to only run on Vista+. (I had to switch to the redistributables because Microsoft broke static linking with Update 2. Now they've broken dynamic linking as well.)
Maybe it's time to use a development suite from a less greedy vendor, one who does not try to force users to change operating systems by hindering application software upgrades.
 
#9
This is new behavior from Microsoft. Apparently they're ramping up their "XP must die" activities -- they've now killed XP compatibility in three different places in VS 2012. I think the only workable solution is to drop back to VS 2010; unfortunately that'll take a couple of days to manually convert all of the projects.
Thank you for the reply but I am confused! :confused: While I deplore Microsoft's shennanigans with respect to XP support as much as anybody, my problem and question relate to tpipe as an "internal command" (sic) of TCC 15.01.44 x64 running under Windows 7 Build 7601 Service Pack 1!
 

rconn

Administrator
Staff member
May 14, 2008
10,291
90
#10
Maybe it's time to use a development suite from a less greedy vendor, one who does not try to force users to change operating systems by hindering application software upgrades.
There aren't any others; they've all gone out of business. If you want to develop on Windows, it's VS or (maybe if you don't need a professional compiler & environment, or support) gcc.

And all of the add-on tools, third party libraries, etc. are only for Visual Studio.
 
May 20, 2009
218
0
53
ITALY
#11
There aren't any others; they've all gone out of business. If you want to develop on Windows, it's VS or (maybe if you don't need a professional compiler & environment, or support) gcc.

And all of the add-on tools, third party libraries, etc. are only for Visual Studio.
I am just curious. What about Embarcadero? Since the old versions of 4dos were in turbo pascal, You might want to switch to delphi? ;)

Regards

Rodolfo Giovanninetti
 

rconn

Administrator
Staff member
May 14, 2008
10,291
90
#12
I am just curious. What about Embarcadero? Since the old versions of 4dos were in turbo pascal, You might want to switch to delphi? ;)
4DOS was written in C and assembly. The only turbo pascal involved was for the help program.

Take Command is written in C++, and I'm not really enamored of the idea of converting 1,000,000+ lines of C++ to Delphi ... :wtf:
 
#14
Try it with 15.01.45 (already uploaded) and let me know if that works for you.
Sorry was away most of day. When I tried to install 15.01.45 I got the following error:
Code:
  The application ran into a problem that it couldn't handle
  Sorry for the inconvenience
Details were (I didn't try to transcribe the stack trace)
Code:
  [SEH_AV_DEP_BADPTR] ACCESS_VIOLATION (0xc0000005) at address [0x00fd14e9]
It's interesting that the installer seems to be hung at this point. Both <Back and Next> produce the error popup as do attempts to terminate the installation with X. Lacking sufficient smarts and inspiration, I resorted to brute force and used Task Manager to terminate tcmdx64.exe *32 and misexec.exe.
[I'm gonna reboot as soon as I post this reply ;) ]
 
#16
That's a Windows Installer error. 99% of the time when you run it again everything works the second time.
You were right of course!! Your knowledge of Windows is truly astounding!! ;)

tpipe no longer causes the error popup but I do not [and maybe never will] have the smarts to tell if it is working! After reading the first paragraph of the help, I naively thought that something useless like the following code would work
Code:
[]echo Hello | tpipe
TPIPE: The parameter is incorrect.
""
As shown, I didn't get the result I expected! Undaunted, I tried the following
Code:
[]echo Hello | tpipe /input
Hello
And got the result I expected from the first example. Guess I've got a ways to go before I can expect to do anything useful with tpipe. ;)
 
#18
If you just want to see it work, here's a very simple one.
Code:
v:\> echo foo | tpipe /simple=5
FOO
Thanks for the reply Vince! Your example is clear enough and illuminated my problem to date in trying to comprehend tpipe i.e. trying to devour the whole thing at once instead of using the method for eating an elephant - one bite at a time! ;)
 
#19
Thanks for the reply Vince! Your example is clear enough and illuminated my problem to date in trying to comprehend tpipe i.e. trying to devour the whole thing at once instead of using the method for eating an elephant - one bite at a time! ;)
I always hated "magic numbers"! To become efficient with TPIPE you need to learn hundreds of sets... The scarcity of examples makes it even more difficult. An outline of the option hierarchy would also be useful. I suspect those users not previously familiar with TPIPE but familiar with other tool sets, such as the ones from the POSIX world, will take long to start using TPIPE. It's like coming to TCC directly from COMMAND.COM.