|
Don Clugston wrote:
I was really surprised to see the number of people using .NET 2002.
IMHO, VC6 has the more-C++ friendly IDE, especially for resource editing (they should drop the 'Visual' from VC7, there's nothing at all visual about it that I can see).
.NET 2003 has a standard compliant compiler, which is why I switched. I miss the wizard bar, and the 'properties' page really sux.
But .NET 2002 has a non-standard compiler and an annoying IDE -- why does anyone use it? Or are all those users non-C++ programmers?
We got .NET 2002 through an MSDN profesional subscription, which we were forced to drop when business slowed down. We never got around to getting the upgrade CD before MS discontinued it.
Also I've heard storys that many of the spectacular IDE failures in .NET 2002 never got fixed in .NET 2003. These include menu command IDs being replaced with numbers, and IDE getting confused by files with the same names and classes in different projects. It also bothers me that the big bool bug was never fixed. That's the bug in which returning a bool from unmanaged code to managed code would always be converted to true.
With these bugs, which are not only big issues, but look really easy to fix still in .NET 2003, I have to wonder how worth while upgrading would be. New compiler features would be nice, but it's the IDE bug fixes that I really want. Does anyone know if they were fixed in the next .NET?
Nathan
|
|
|
|
|
MacTruck wrote:
Microsoft doesn't even use the tools they sell to the consumer. Internally, they use different tools. As a result, nothing ever gets fixed except to their own internal tools.
That doesn't suprise me a bit...
MacTruck wrote:
In order for software to become stable, you actually have to use it...at home and as far away from a debugger as possible.
I agree 100 percent!
Happy Programming!
WWW::CodeProject::BNEACETP
|
|
|
|
|
First off,
1) Microsoft does use thier own tools internally. (who ever told you this was probably on a developement team that was not).
2) The XP manifest information does not even get saved in Visual studio 2002 and is still there in 2003!!! (importing it as an external resource fixes this problem).
3) The resource editor still changes your ID tags, without you knowing!
other than those two problems (2,3), I have not had any other complaints about 2003. But yes 2002 is very very buggy.
|
|
|
|
|
It is true that some VC++ 6.0 code cannot be upgraded to VC++ .NET. Visual Studio .NET 2002 had problems (many bugs), but 2003 is perfectly fine for me.
I personally cannot go back to VC++ 6.0 anymore.
The only problems I found with VS .NET 2003 is the resource editor. Some times it erases my ID tags and inputs a number (even when there were no duplicate names). Other than that error, it seems fine.
I also have done some Visual Basic .NET work and that is a huge improvment.
So over all, i think visual studio .net 2003, is far better than Visual Studio 6.0.
|
|
|
|
|
This looks pretty bad. I can understand the 20% or so VB6 users since they have a questionable upgrade path. But more than 50% of the responders are using VC++ 6, which can easily be upgraded to VC++ .NET 2002 or 2003 (versions 7 and 7.1, if you would rather).
The improved MFC and ATL support in version 7 alone should make the upgrade mandatory.
Visual C++ 6 is 5 and a half years old. Its last service pack was three years ago.
It's time to upgrade to at least get product support!
Dale Thompson
|
|
|
|
|
Dale Thompson wrote:
But more than 50% of the responders are using VC++ 6, which can easily be upgraded to VC++ .NET 2002 or 2003
The problem is VC.NET is not fully backward compatible with VC6 and it will break your code in many cases mostly because VC6 let / forced you do things that were not standard (mostly with templates) and VC.NET fixes this but if you have code written for VC6 it may require a lot of modifications to compile under .NET. I have 200K+ lines of code in 6 dlls that I use with most of my applications. Most of this code was written by me (probably like 70%) and some of it was taken from code project and other sites. I spent two weeks and fixed 200+ error messages in this code and then gave up and returned to the old code and old compiler. Good thing with CVS you can go backwards without too much pain.. It was too much a pain to fix other peoples' code because I was not familiar with it enough to make the changes and they did not have updates yet.
John
|
|
|
|
|
VC++ 6 is not such a resource drain as the Visual Studio .NET versions of the product. I can develop a VC++ 6 project just fine on my AMD k6-2 running at 333 MHz, not so for the Visual Studio .NET product...
|
|
|
|
|
Also the .NET IDE is a pain to use for C++ programmers at first. It's too much like the Visual Basic IDE...
John
|
|
|
|
|
There's Visual Studio .NET 2002 on my platform. After I customised the IDE to make it similar to VC++6, I think .NET IDE is OK...
Maxwell Chen
|
|
|
|
|
Plus theres companies like mine who are to cheap to buy the new stuff. And to stupid to upgrade.
|
|
|
|
|
I agree with u completely
Love is the law, love under will.
|
|
|
|
|
In my case, it's me personally. I wouldn't mind paying for VC7.1Pro, but I have no reason to buy the whole Visual Studio suite. If Microsoft were to release a standalone version of VC7.1Pro, I'd buy it and have te company upgrade, too. As it is, they only have the standard edition (which won't do), so I use VC6Pro at home and therefore at work.
|
|
|
|
|
We need something really unmanaged (.NETless) and better MSDN.
VS.NET offers bad explanation on Win32 API, MFC and other older technologies in the attached MSDN.
I just so hope MS will release a Visual C++ 7 and not Visual C++.NET.
Not everyone interested on .NET.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
There are no improvements to MFC in VS.NET. In fact MS announced that it has discontinued MFC development (only bug fixes).
If you are only doing c++ and/or MFC development, the few extra improvements (mainly the compilor) may not make it worth the effort. If you convert your project, you will have to retest everything. At least I have found many subtle bugs introduced into my code by the new libraries.
VC6 was a mature and stable product. If it works why fix it?
|
|
|
|
|
If the rumours I hear are true you may have no option but to upgrade for the new vesion of windows (as usual). If anyone knows if this lot is true, please post back
1. All subclassing(VB) and hooking code will not run due to the API being deprecated.
2. The GUI will be (stolen from the) XML forms specification. Who MS?
3. The GUI is script/markup based so web-form will finally be seamless.
4. To use un-managed code you will need to go through an virtual application?
If any of this is true and you know why, please tell me
Bulletin boards are the root of all evil and myths.
|
|
|
|
|
One may find that a big proportion of the people who ticked VC++ 6 also ticked one of the VS.NET options.
regards,
Paul Watson
Bluegrass
South Africa
Brian Welsch wrote:
"blah blah blah, maybe a potato?" while translating my Afrikaans.
Crikey! ain't life grand?
Einstein says...
|
|
|
|
|
I would say that not everyone is having the same problems when it comes right down to it because not everyone uses a product in the same fashion so some will see bugs that others might never see...
I for one have had Visual Studio .NET 2002 crash on me several times and have seen quite a few strange things while Visual C++ 6.0 has NEVER crashed on me a single time (as far as I can remember), and I can also admit that the VS.NET 2002 and 2003 products are more sluggish that the VS 6.0 products.
For me at least, VS.NET 2003 (which I use VC++.NET, VC#.NET, and VB.NET) seems to be a bit more stable than 2002, but hopefully I haven't spoke too soon.
BNEACETP
|
|
|
|
|
We have older versions of our products, developed on VC6, that we still need to support. We still need to use VC6 to recompile changes for these older products. We use VS.net 2003 for new development.
I'm sure there are lots of other companies in the same boat.
Ian J Prest
|
|
|
|
|
Ian Prest wrote:
I'm sure there are lots of other companies in the same boat.
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
When a new compiler comes out, as a developer or development manager you have to ask yourself two questions.
1. Do I have the time and manpower to make sure that the product still works after we've compiled it in the new compiler.
2. Do the new features in the compiler, justify the risk of upgrading.
When you have a codebase that has been developed over several years and is the main source of company income - you have to make sure that the upgrade is worth it.
You'd be surprised about the number of little things that have changed that can break legacy apps - I know, I've been there.
Michael
But you know when the truth is told,
That you can get what you want or you can just get old,
Your're going to kick off before you even get halfway through.
When will you realise... Vienna waits for you? - "The Stranger," Billy Joel
|
|
|
|
|
And don't forget number 3:
3. Am I in the middle or near the end of the development cycle for a product?
If the answer to that is yes, then you probably want to wait a while before upgrading...
"I'd be up a piece if I hadn't swallowed my bishop." Mr. Ed, playing chess
|
|
|
|
|
Dale Thompson wrote:
Visual C++ 6 is 5 and a half years old. Its last service pack was three years ago.
Isn't there supposed to be a new service pack for VC++6 released this year?
"Insanity runs in my family... It practically gallops." - Mortimer Brewster, in Arsenic and Old Lace
My 20 favorite films: http://www.ymdb.com/user_top20_view.asp?usersid=8912
|
|
|
|
|
Don't know, but there was a service pack last year
|
|
|
|
|
|
Dale Thompson wrote:
This looks pretty bad
I take it you are a Microsoft salesperson then? I mean, the only one it's "bad" for is Microsoft, that don't get to peddle more wares that are once again unsupported and artificially obsoleted in a year or three.
But more than 50% of the responders are using VC++ 6, which can easily be upgraded to VC++ .NET 2002 or 2003 (versions 7 and 7.1, if you would rather).
Easily? Well, as a sales person I think you might not see the difficulties involved in such a change.
Let's paint a not too fantastic scenario:
2002:
- Upgrade to 7.0. ~50 licenses. A nice sum of Redmond Tax.
- Requires ~4-6 times as much memory, ~5 times as much disk, and 4-6 times the CPU, why obviously new developer machines would be required [1]. Another $70-$100K (current exchange rate).
- Standstills due to OS and software installations, say just one lost workday/developer (too low to be realistic). At $100 each that's another $40K.
- Oh, it's incompatible with all our other tools (profilers and such)? OK, another $10K-$20K.
- Incompatible with VC6, and incompatible with the standard. Requires code rewrites incompatible with both. This is wasted time, and money, that "nicely" spills over to the next upgrade (2003). Estimate impossible.
- Hope (and pray) all developers becomes reasonably comfortable with it, to let them be at least as productive as with VC6. Fat chance.
That would set us back a quite noticable amount, with no immediate benefits in sight.
[1] Due to these machines, they might like Microsoft start writing sloppy code, consuming way more resources (e.g. memory and CPU) without even noticing the slowdowns - only the customers running older machines will experience this (I think that might be a reason VC7 even was released - if you compare its speed on a top-of-the-line machine at the time it was release, it actually might run the same speed as VC6 on a top-of-the-line machine at its time - but I wouldn't bet on it).
Now fast forward just one year to 2003.
2003:
- Yet *another* version, even that it's internal numbering clearly displays it as a just revision (7.1). More Microsoft Tax.
- This time perhaps the machines are "fat" enough to handle it. "Only" 4 hrs/dev. $20K.
- Oh, it broke 50% of the developers OSes? Tough luck. Complete reinstallation of OS and tools takes care of that. 25 developers * 1 day. Another $20K.
- More conforming compiler. Great, finally we may change the code to be C++, but it costs money. Money we wasted on the interim 7.0 code. Estimate impossible.
For both versions, the API documentation has only become worse and worse. If this continues, there will no longer be a Win32 API - just a 10GB of "soup" called "MS Runtime Slosh", or something like that.
<sarcasm>Yeah, I can see how this could have been of benefit...</sarcasm>
The improved MFC and ATL support in version 7 alone should make the upgrade mandatory.
Improved?! They have for crissake put it on death row! OK, that might be an "improvment" for something as MFC from a C++ POV, but for the ones using it it's a knife in the back!
Visual C++ 6 is 5 and a half years old.
So you judge software by age? The older the worse? Then, surely, you must think antiquities as vi, ls, more, grep and uncountable other tools or built-in commands to be so useless they should be banned?
I'd love to see you even try getting on the net if that ever happened...
But if this is your view, that you actually think customers are happy being put in an endless-upgrade treadmill, perhaps you should start trying to sell your software with a big red best-before date on the box, making it clear that "after this date, we won't care about neither this software nor you"?
Another viewpoint is that the older the software the more it displays it's utility. If it's used after half a decade, that's good in MS-terms. If it's used after a decade, it's good. Many use software that's over 20 years old. Not because they are "cheap", but because it still does the job! Sometimes, it's even the best there still is!
It's time to upgrade to at least get product support!
Like we have ever gotten any "support". VC6 was released the same year the C++ standard was ratified. Did they do anything to increase the level of standards conformance to the compiler? Anything at all? No. You call that support? I call it "pissing customers in the face".
Forcing a sh*tty VB-ish IDE down developers throats when MS instead/also could have upgraded the compiler for MSVC6, and charged for it as 6.1, 6.2... I don't like it, and apart from the few here that are forced to use 7.x, I've got a feeling VC6 was the last full MS C++ development product we rolled out.
|
|
|
|
|