I have limited knowledge of C++ (so far). Done some modifications on existing software, but that's it for now. Usually I am working with other programming languages.
My task is to take a legacy app written in C++ / Win32 / MFC / Visual Studio 2003 and get it "up to date".
"Up to date" means:
it should be Windows-7 compatible
it should still run on Windows XP
probably not possible: it should still run on Windows 2000 ?
Since time is limited as usual, I am interested in solutions that achieve these goals with fewest possible modifications on the code base.
Right now, the app runs on Windows 7 only if started in compatibility mode for Windows XP.
I could imagine that VS2003 is not able to satisfy Windows-7 compatibility.
Do I need VS2010 or would VS2008 suffice (that is available already) ?
MS works very hard to be backward compatible from what I know. Try check if it doesn't just work - if code was written correctly (i.e. did not depend on quirks, undocumented functions etc.) it should work. Well - from your post I assume it doesn't so goto 2.
If it does not work. Try compile. Remove any warning and/or error that appeared. Probably with warnings set on maximum level.
Find out where it does not work (does it crashes? where? etc.). Use debugger. Checks what's wrong. This will either help you with next 2 steps or you may go straight to solving problem if you know what it is.
If it does not work check code for any undocumented functions etc. and replace them with well-documented ones. That step is good ot perform even without any problems for future compatibility.
Check code for documented functions that changed some parameters (that will be in MSDN documentation).
There is nothing about vs2003 that stops an app running on win7. VS2008 has much better C++ standard and VS2010 adds a few nice editing features
There is no obvious reason why it shouldn't work, MSFT is very good about keeping backward compatibility. You will have to look at exactly what is stopping it.
Related
I work in a factory where 80% of our equipment uses an MS-DOS interface. None of our engineers have experience in c/c++ programming, and it was requested we add some features to the machines interface. Our automation group has abandoned the MS-DOS platform in favor of Allen-Bradley controls. I'm feeling ambitious and decided to take on this project, even though I have next to no experience in c/c++.
On to the question:
All of the programming was written and compiled in Turbo C++. I would prefer to use DEV++ for various reasons (ease of use, additional headers, more developed C++ platform, ect.). The problem is the existing programming relies heavily on non-standard headers from TC++. There are 10 or so headers unavailable in DEV++ in the source code, and rewriting the code using more modern constructs is not an option; we would lose what little support we have from our AG, time, ect.
Is there a way I could add all the headers from TC++ to DEV++? For example adding the graphics.h to DEV++ and have it be fully functional? I have tried adding it to the include folder, calling it with #include"graphics.h", and if DEV++ manages to recognize it, it throws a ton of compiling errors because it doesn't recognize the internal commands in the graphics.h file.
Unfortunately I cannot include any example code from this project, due to non-disclosure and copy-write policies.
My programming experience:
DABBLE in RSLogigx500,5000 ; Arduino IDE (don't judge) ; Parker 6K ; PanelView ; ~40hrs of self-taught c and c++.
Any help would be much appreciated.
UPDATE
Very helpful information. It seems like this isn't going to be possible given how outdated the hardware is and the restrictions I have on this project, but thank you all for your input.
Most of the headers from old Turbo C are really just the MSDOS API, in a way. So it doesn't make any sense to attempt to use those headers in any other environment and you can't port them to a Windows compiler. Similarly, graphics.h is for a Borland-specific DOS graphics library called BGI and will not work on any other compiler.
It should be noted that old Turbo C++ (I'm assuming version 3.1?) didn't follow the C or C++ standards much. The C++ version it used is completely antique.
Also note that the Dev C++ IDE is outdated and doesn't update the GCC compiler any longer. The CodeBlocks IDE is a better alternative.
This is more of a "long comment" than a direct answer to your question, trying to guide you to a better understanding of what MAY be your challenge in your project.
I personally would choose a more "professional" level development tool. Either Eclipse (positives is that this is portable and looks/feels the same whether you use Windows or Linux), XCode (works only on Mac) or Visual Studio (which works only on Windows). These are full featured integrated development environments, and they are all very slick. All of them are free or nearly free.
Compiling OLD code, that is written for DOS into a modern compiler with on a modern OS may be quite a challenge, depending on what the application does and how much in the way of assumptions about it's environment the code is written with:
does it assume int is 16 bits
does it call direct to DOS to get file info, opening/reading/writing/closing files
does it do raw keyboard input
does it poke characters and/or pixels directly at the screen
does it use far and near pointers, are there driver-like components that interface directly to hardware interrupts
One thing that stands out in your question is the mention of graphics.h, which I believe is very Borland specific. Which means you'll have to write your own replacement functions - either a replacement graphics.h set of functions (I expect most functionality is available in any modern OS, it's more a case of "what is it called and what do I need in order to call that function"). This can be quite a task in itself.
The tricky part here is not only to identify what the code does, but to replace it with similar logic, that does the same thing in your new environment.
And of course, it all depends on what you want to do with the code, how well written it is - is it nicely modular, does each function do one thing and one thing only, or are there functions that "This calculates the value of , and then reads some data from disk, then does some I/O to the screen, and then talks to some external hardware, and because it gets calls frequently, also updates the time on the screen if it has changed".
According to MSDN, Microsoft still ships nothrownew.obj with the Visual C++ 10 (Visual Studio 2010) runtime library, so that users can link against it and have sub-standard behavior of "ordinary" (not nothrow flavor) new returning null on allocation failure. This sub-standard behavior dates back to Visual C++ 6 which is now considered extremely old.
Why would it do so? I mean they make each new version of the compiler more and more Standard-compliant. For example, Visual C++ 7 would support "default int", but Visual C++ 9 would not. And the old sub-standard behavior of new can be easily achieved by slightly changing code to use nothrow flavor of new - this is straightforward and very easy.
Why is this option so important that Microsoft still supports it?
Well, this is sort of an open question, since nobody except someone responsible from Microsoft can say for sure - if at all. So, I'll take a bite:
I'll guess it is for convenience:
Microsoft itself may need it in some of their products and it is just easier having it together with the compiler tools.
Microsoft may know that someone (say a big vendor/app) still needs it and it is just easier (or even necessary if compiler specific) to still provide it.
Microsoft may know/anticipate that it is generally still "widely" used in legacy apps. Big or small.
"It doesn't hurt", well arguably. For example, Microsoft has a long record of maintaining backward compatibility in Windows (see Raymond Chens blog), again, arguably not always for the better.
Documentation, Tests, etc. would need to be altered (or removed, but still).
That is, removing it may be more trouble yet then just keeping it.
At least they need / should provide a deprecated notice a version prior to removing it. I don't know if they did that for VS2010 or any prior version.
Because I am now (2012) porting a product from Visual C++ 6.0 to Visual Studio 2010 and that helps greatly to bring the development up to speed. We also will not make the Unicode transition for a few years to come. If Microsoft would not provide the compatibility feature I would build it myself.
As a side note we are a major ISV in a specialized field. If we decide to change OS, an entire Industry would probably change to. (Before Windows we used to also build a specialised OS.)
I was asking my team to port our vc6 application to vc2005, they are ready to allot sometime to do the same.Now they need to know what is the advantage of porting.
I don't thing they really understand what does it mean to adhere to standard compliance.
Help me list out the advantage to do the porting.
Problem I am facing are
1)No debugging support for standard containers
2)Not able to use boost libraries
3)We use lot of query generation but use CString format function that is not type safe
4)Much time is spent on trouble shooting vc6 problems like having >>
vector<vector<int>>
with out space between >>
Advantages:
More standards compliant compiler. This is a good thing because it will make it easier to port to another platform (if you ever want to do that). It also means you can look things up in the standard rather than in microsoft's documentation. In the end you will have to upgrade your compiler at some point in the feature. The sooner you do it, the less work it will be.
Not supported by MS. The new SDK doesn't work. 64-bit doesn't work. And I don't think they're still fixing bugs either.
Nicer IDE. Personally, I really prefer tabs to MDI. I also think that it's much easier to configure Visual Studio (create custom shortcuts, menu bars, etc.). Of course that's subjective. Check out an express edition and see if you agree.
Better plugin support. Some plugins aren't available for VC6.
Disadvantages:
Time it takes to port. This very much depends on what kind of code you have. If your code heavily uses non-standards compliant VC6 features, it might take some time. As Andrew said, if you're maintaining an old legacy project, it might not be worth it.
Worse Performance. If you're developing on really old computers, Visual Studio may be too slow.
Cost I just had a quick look and Visual Studio licenses seem to be a bit more expensive than VC6's.
Why VC2005? If you are going to invest the time (and testing!) to upgrade from VC6, why not target VC2008?
If you're maintaining a legacy project then there may be no advantage in porting. Simply converting projects and fixing up compiler problems could take weeks of time and introduce instability.
If you're actively developing a product then the main advantage is that you'll no longer be using a product that's over eight years old - which is clearly a good thing.
More recent versions of the Windows SDK don't work with VC6 - if you want to use the latest Windows features, you'll need a more recent compiler.
The later compilers are said to be more standards conforming. I'm sorry I can't be more specific. I do know that VC6 generates lots of compiler warnings just for using standard template classes.
If you use any external libraries that are compiled with a later compiler, you'll need to use something compatible.
Prepare for something of a harsh transition - the IDE's are more different than they should be.
To ensure complete compatibility of the application with different versions of the base platform. And to rectify any errors found thereby so as to give enough freedom to end user to use his own version of the base platform.
I'm not saying you shouldn't convert, but to take your specific points:
1)No debugging support for standard
containers
I debug code using standard containers with VC++ 6 all the time. What's your problem here?
2)Not able to use boost libraries
True. You may find you can use some of the simpler stuff.
3)Much time is spent on trouble
shooting vc6 problems like having >>
[can't get SO to stop mangling this, nb]
with out space between >>
Um, that is a syntax error (at least in the version of C++ understood by VC++6) and will be flagged as such. If your team is spending "much time" on this sort of thing, you need another team.
Edit:
3)We use lot of query generation but
use CString format function that is
not type safe
It will be equally type-unsafe under VS2005. I don't see why this is a reason for porting. If you want type safety use the standard C++ I/O mechanisms.
If your team can't see any advantage and you are unable to explain any advantage, why are you asking them to do this?
Sounds like you are porting just for the sake of it.
I have a client who is still using Visual Studio 6 for building production systems. They write multi-threaded systems that use STL and run on mutli-processor machines.
Occasionally when they change the spec of or increase the load on one of their server machines they get 'weird' difficult to reproduce errors...
I know that there are several issues with Visual Studio 6 development and I'd like to convince them to move to Visual Stuio 2005 or 2008 (they have Visual Studio 2005 and use it for some projects).
The purpose of this question is to put together a list of known issues or reasons to upgrade along with links to where these issues are discussed or reported. It would also be useful to have real life 'horror stories' of how these issues have bitten you.
Not supported on 64-bit systems, compatibility issues with Vista, and it was moved out of extended support by Microsoft on April 8, 2008
http://msdn.microsoft.com/en-us/vbrun/ms788708.aspx
Unpatched VC6 STL is not thread safe. See here http://www.amanjit-gill.de/articles/vc6_stl.html, the patches aren't included in the service packs and you have to get them from Dinkumware directly (from here http://www.dinkumware.com/vc_fixes.html) and then apply them to each installation...
The biggest problem that we've seen at my workplace is it's inability to handle even marginally complex templated classes or functions. This fact alone has force some of the most devoted VS6 fans in the company to upgrade and start using VS2005. In addition to the template problem, intellisense is much better, debugging is easier and more accurate, and many people find the IDE easier to navigate. The only downside that we have seen thus far is that builds take a bit longer in 2005 than they did in 6 (but that's probably a side effect of the compiler being more robust)
You can also check out these sites for a sampling of known issues in VS6:
http://louisville.edu/~ecrouc01/CECS302/VisualCPP.htm
http://www.acceleratedcpp.com/details/msbugs.html
I'm sure you could find more if you poked around a bit.
VS6 does not compile code according to the current C/C++ standard. For example,
it has incorrect (outdated) scoping rules for loops. At least one MSFT SDK have been updated now with code that expects the correct semantics, so the SDK won't even compile with VS6 any more.
It has trouble being able to compile all but the most trivial template constructs.
It will compile some template constructs that have been declared illegal in recent standards updates (because the constructs don't actually do what normal users expect).
operator new doesn't conform to the C++ spec and doesn't throw exceptions on allocation failure, fixing this is non trivial.
see: http://msdn.microsoft.com/en-us/magazine/cc164087.aspx
One of the biggest reasons for me to upgrade was the standard compliant C++ compiler ( although still not 100% ), so I could leverage more C++ features in my projects and not worry about strange hacks and workarounds that can lead to hard to find bugs.
Not compatible with Vista. Heck, there's a long list of issues VS 2005 has with Vista.
That being said, most of the improvements in VS seem to apply to everything other than C++ native code. What I'm seeing is more standards compliance, which is important but hardly dramatic.
Visual Studio 6 is not compatible with the lasted Windows SDKs, so it cannot utilize (at least easily) the latest OS features.
Though I no longer have concrete details, I'll just throw in that when we upgraded at work, the new compiler found quite a few errors that VC 6 let slip through quietly. Improved product robustness just from the upgrade.
If they use the STL, they may be interested in the recently-released feature pack, which includes an implementation of TR1.
I have upgraded my stuff but it's relatively uncomplicated. A con to upgrade is VS 2005 DLL Hell
The VS 2008 version of the STL compiles with /clr, so if they're interested in transitioning to the managed world, they don't have to lose all their old code.
By defoult newer versions have better compiler and better libraries. But it's not always easy to port existing projects to newer studio, and you can upgrade both compiler and libraries manually.
I was using VS 6.0 with Intel compiler just year ago. We just had a bunch of old code then, which was threating iterators as pointers and vice versa, and it was all real messy and scary, so this holded us from an upgrade.
But I have had to upgrade after all, because the framework I'm currently using simply doesn't run on VS 6.0. Think this is the ultimative reason :-)
Third-part libraries support only a limited number of compilers, too. Your client may not be able to accept bugfixes or feature upgrades as a result.
For instance, even a widely used library as Boost supports only VS 7.1 and later (source)
And you might have some problems with Data Execution Prevention (DEP) as well, because VC6 ships with an old ATL version. As usual, see Raymond Chen for details.
Ok, I'm developing an application that has been in pretty much continous development over the last 16 years, from C in DOS, through various flavours of C++ and now is largely based around C++ with MFC and StingRay GUIs and various other SDKs.
While I use VS 2005 for the release builds, I still use MSVC 6 for much of the GUI building, simply because ClassWizard is so much quicker in this environment than the weak equivalent tools that followed. Note that I am using ClassWizard to automatically generate code for my own user defined types (see Custom DDXs) and I like to add a lot of member variables and methods in one go. Creating them one at a time as per later versions of Visual Studio for me is a big backward step. At the same time, working with multiple IDEs is also a pain.
My question is in two parts;
Is there any way of getting ClassWizard to work is VS 2005 or VS 2008?
Is there any drop in replacement, or alternative IDE, that provides similar levels of productivty for old C++ hacks such as myself?
A follow up to those who are interested. ClassWizard may be re-introduced in VS2010, from Tarek Madkour [VC++ Team]
'We are considering adding the Class
Wizard back to VS10. We hope this will
make DDX/DDV function creation more
keyboard-centric just like it was in
VC6. There are some schedule
challenges that we will need to
overcome to get the feature done, but
I am optimistic that you will see it
when we ship VS10.'
Click here for the full discussion
Edit: The release notes for VS2010 confirm that MFC Class Wizard is back. So contrary to popular belief, the guys at MS do listen to their users.
Visual Studio 2010 provides a C++ IDE
experience that includes the return of
the MFC Class Wizard, the ability to
view large source files through Source
Outline, integrated quick searching to
find information without the confusion
of the current “Find In Files” method
and an easily extensible IDE model
through the new Managed Extensibility
Framework (MEF).
Agree with Shane, the CW alternative in vs2008 is shockingly poor; it makes you wonder if anybody at Microsoft still uses MFC. I’ve started bumping my estimates up just because of the generally poor afx/mfc integration. It’s just not finished and what is there is pretty buggy. Sure you can put the code in by hand, nobody is claiming its hard but seriously, its grunt code, its 2010, you just shouldn’t be writing this stuff by hand anymore.
I will suggest avoid code generation at all and use your favorite editor to manually create new code. If i understand correctly your are expert in this area and i sure you know that manually created code will be much cleaner and simpler then the generated one.
In additional the code generator is a nightmare for code reviews, it change zillions of places that should not be changed at all and it's really hard to concentrate to the meaningful changes.
IMHO.
I would also suggest you put the neccessary DDX/DDV (as well as message handling) macros (and member variables) manually into your classes. At first it seems a bit difficult to find out how and where exactly one is supposed to write the entries, but after a short while it's rather easy. I started doing that after porting a VC6 project over to VS2005, and for exactly the same reason you gave: there is no suitable replacement for ClassWizard. However, after two years I can say that I don't miss it at all anymore.
You can write click on controls on form and add variable or event handler. It is not as good as VC6 but still. I do not see any point in writing the DDX manually.