C++ shift from Unix to Visual Studio in Windows

Question

Hi Everybody,

I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present. Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.

If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.

But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO. Is it very difficult for a C++ programmer to shift from Unix to Windows. Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?

given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)

Answer 1

Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.

Answer 2

I understand your pain; I took the same path a few months ago.

You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.

Usually, you have two compilation "modes", debug and release. (you can add your own)

When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...

Just start it using the F5 key.

More notes on the additional files:

In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).

A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.

Answer 3

First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.

If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.

If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.

Good luck.

Answer 4

The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.

If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).

More details: A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.

A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.

Extensions used:

• *.vcproj : Project file for C/C++ sources

• *.vcproj..user : contains which windows are open in the GUI. Can safely be deleted.

• *.sln : Solution file

• *.ncb : Intellisense database for a solution. Can safely be deleted.

• *.suo : contains which windows are open in the GUI. Can safely be deleted.

• *.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)

• ./Debug/* : folder with all intermediate files for a Debug build (can be changed)

• ./Release/* : folder with all intermediate files for a Release build (can be changed)

That's all I can think of at the moment.

Answer 5

VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.

http://msdn.microsoft.com/en-us/library/sc65sadd.aspx Please select hyperlink "Debugging Native Code" for C++ specific.

Answer 6

If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.

That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.

Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?

I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.