Board index » Visual Studio » MSVC7 to MSVC 7.1

Visual Studio307
Hello,



How can I upgrade from MSVC 7 to MSVC7.1? I searched Microsoft web site but

there was no service pack or upgrade for MSVC 7. If I need to download

anything, please give me the URL.







Best regards


-

Hallo!



There is not Upgrade MSVC 7 and MSVC 7.1 will coexist. Uninstall 7.0

and install 7.1



--

Martin Richter [MVP] WWJD

"In C we had to code our own bugs. In C++ we can inherit them."

FAQ : www.mpdvc.de">www.mpdvc.de

Samples: www.codeguru.com">www.codeguru.com www.codeproject.com">www.codeproject.com

-

Do you mean that MSVC 7.1 is a new product and not related to MSVC7?



I am gettimg a heap coruption error in MSVC7 and it seems that others that

using MSVC7.1 doesn't get it. I want to test if the problem is MSVC version

or the problem is my code. How can i test this?



Best regards





"Martin Richter [MVP]" <martin.richter@mvps.org>wrote in message



-

ma wrote:

Yes.



VC7 ==>Visual Studio .NET 2002

VC7.1 ==>Visual Studio .NET 2003



Download the Visual C++ 2003 toolkit from



msdn.microsoft.com/visualc/vctoolkit2003/">msdn.microsoft.com/visualc/vctoolkit2003/



build your application and see what happens.



Caveats:



1. If you're using MFC or ATL, the toolkit may not work for you - it doesn't

include those libraries. You can try pointing the toolkit compiler at the

VC7 include/lib directories, but there's no guarantee that it'll work.



2. The toolkit is a command-line only compiler. With some effort you can

probably hack it into the VC7 IDE (people have done similar things with the

VC6 IDE). Of course, such a configuration would be unsupported.



3. If you have strong reason to believe there's a bug in VC7 that's causing

your heap corruption, you might want to contact Microsoft Product Support to

see if there's a patch. Such calls are free if it's a bug in the product,

but incur normal support charges if it turns out to be your bug.



-cd





-

"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>

wrote in message news:OfEmd2kJFHA.3788@tk2msftngp13.phx.gbl...

Whatever the result of that experiment, it can

provide only weak evidence that the OP's

heap corruption problem is due to the toolset

rather than his/her code. The "try it and see"

approach has a good chance of helping the

OP mask an error of his/her own making.



The heap corruption problem most likely is

due to a coding or design error in the OP's

code. That way to discover that error is to

use a debugger and one of the tools available

for checking heap integrity.



I doubt that "changing toolset made problem

go away for tests I ran" is going to count as

a "strong reason".



--

--Larry Brasfield

email: donotspam_larry_brasfield@hotmail.com

Above views may belong only to me.





-

For your group information:

The prohram compiled with MSVC 7.1 and the problem solved. It seems it is a

tools mismatch problem or a problem that would go away whith MSVC 7.1!





Best regards





"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>

wrote in message news:OfEmd2kJFHA.3788@tk2msftngp13.phx.gbl...



-

"MA" <Not@Known.com>wrote in message



I wish you good luck then, because that is

what you are relying on. I would bet good

money that the problem is/was not a fault of

the toolset and arises from a coding error.

The luck you rely upon is whether this error

will remain hidden for all the inputs that your

program will be asked to handle.



--

--Larry Brasfield

email: donotspam_larry_brasfield@hotmail.com

Above views may belong only to me.





-

Unfortunately I can't do anything in this matter.

I have a library and a template source code. When I use the template source

code and put the following line in it it is crashing:



void TemplateClass::open(inData data)

{

std::string MyFile=data.getFilename();

}



but if remove the line, it is working well.



One other source that I think may generate this problem is the fact that I

don't know how the library is compiled. Probably it is compiled with a

different version of threading than the one that I am using.



Best regards





"Larry Brasfield" <donotspam_larry_brasfield@hotmail.com>wrote in message



-

"ma" <ma@nowhere.com>wrote in message

If that is true, then I urge you to see to it that the program,

in its final form as your customer(s) will use it, (meaning

bitwise identical), is tested very thoroughly. What you

have shown below makes it more likely that the problem

is a coding error that induces undefined behavior. This

sort of problem can easily change, hide, or reappear

with the slightest change in anything that affects the

loaded part of the executable image.



One thing you ought to do for sure is ensure that

if you are using more than one thread, your library

is able to cope with that, correctly. Threading

problems are notoriously sensitive to slight code

changes, other processes affecting scheduling,

and platform. All the more reason to find the

bug or test the Hell out of your maybe shippable

program.



[Quotes only follow.]



--Larry Brasfield

email: donotspam_larry_brasfield@hotmail.com

Above views may belong only to me.





-

ma wrote:

Sounds like the problem to me. To use a DLL with a function that returns

std::string, you must compile with the same compiler version that the

DLL was built with.



Tom

-