Why when I convert my solution from Debug to Release version, the program doesn't work anymore?

I finally was able to get the C++ program to compile without any errors and was able to produce the output without any issues.  When I compiled it into executable and tried to run on an XP machine, I received a message indicating that it was not a WIN32 application.  I then created a new project and selected "Visual Studio 2013 - Windows XP (v120_xp)" as the new platform.  I also specified that this executable be compiled as a Release version.

Now when I try to run the program, I get errors for fscanf, strcat, strcopy, where I didn't before.  I changed the fscanf, strcat, and strcopy to the secure functions (i.e., functions ending with _s).  My program still does not work.  

I'm not a c++ programmer nor am I experienced in Visual Studio 2013.

Can someone tell me what I am doing wrong?  Why changing the program from debug to release would result in errors?  And how can I get the program to run in an XP platform?
Carmen TorresData AnalystAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
sarabandeConnect With a Mentor Commented:
the problems often were due to different properties of release and debug configuration.

unfortunately, visual studio allows you to do major changes to properties of the debug configuration while the properties of the release configuration remain unchanged.

the errors you encountered may be caused by a different 'warning level' and the option 'treat warnings as errors' which both could be found in the properties of the c/c++-general page for the debug and release configuration.

if the new calls to the 'secure' functions do not work, you may post the code here together with an error description. there is often a problem with the additional size argument which may not be available if only a pointer was passed as argument.

Sara
0
 
n2fcCommented:
I am presuming it ran OK in debug mode...

Typical cause for this type of behavior is an uninitialized variable, which exhibits changed behavior due to stack changes when removing debug.
0
 
Carmen TorresData AnalystAuthor Commented:
Yes, it ran perfectly in debug mode.  Is there a way in debug, to catch the culprit that is causing the problem?
0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
ZoppoCommented:
Hi CarmenMTorres,

probably your RELEASE build is a 64-Bit application or is built for higher Windows version (i.e. take a loot at http://blogs.msdn.com/b/dsvc/archive/2009/06/19/troubleshooting-not-a-valid-win32-application-error-at-the-startup.aspx).

ZOPPO
0
 
jkrCommented:
>> Is there a way in debug, to catch the culprit that is causing the problem?

Check out https://msdn.microsoft.com/en-us/library/fsk896zz%28v=vs.110%29.aspx ("How to: Debug a Release Build")

>>  I get errors for fscanf, strcat, strcopy

Wait a minute, do you get these errors when building the release version or when running it? If that is during the run, what exactly are the messages?
0
 
n2fcCommented:
Try running "lint" on the source to check for uninitialized variables...
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.