Re: Visual C++ 6 support issue
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 05/18/04
- Next message: Joseph M. Newcomer: "Re: Visual C++ 6 support issue"
- Previous message: Vivek: "Re: Debug and Release build"
- In reply to: Ian Semmel: "Re: Visual C++ 6 support issue"
- Next in thread: Yasoo: "Re: Visual C++ 6 support issue"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 18 May 2004 01:45:52 -0400
See below...
On Sun, 16 May 2004 20:35:25 GMT, Ian Semmel <isemmel@removejunkmailrocketcomp.com.au>
wrote:
>Ditto to what you say, but it has never been fully explained (for me) just WHY
>they had to do a U-turn and upset everything.
****
As far as I can tell, because Somebody Had A Vision. And no one had the sense to squash
him at the beginning, By the time this got into beta, the decision to build such a crappy
interface was unrecoverable. I gave up being a beta tester years ago, because all MS wants
us to do is debug the software. No feedback about the design was ever considered valid,
and nothing ever made it into the product release or the next release because a beta
tester said "This design sucks". So I found little point to continuing. (Not to mention
the fact that they would send us a beta for a product called GLORP or some other cute
internal name, and never once explain what GLORP was, or why I would care to beta test
it!)
****
>
>A common IDE is a good idea, but usually in programming, you have to write code
>that fits into the user's environment, not tell the user "I've written this
>really good program. All you have to do is change the way you do everything". I
>can imagine the reaction from my customers if I tried this.
*****
The designer of VS7 probably got a stock bonus for this abomination. There Ain't No
Justice. The rest of us would be told to get our resumes in order, as our careers with
whatever company employs us would be in jeopardy, and deservedly so.
*****
>
>I think it would have been easier for MS to develop VS6 into something better
>than the path they chose. I think I remember something about some guru they got
>from Borland who decided that the VS7 approach was they way to go.
****
Borland's final revenge on Microsoft? Perhaps the reason Borland went downhill so fast was
their products looked like VS7?
****
>
>As far as changes, I would have liked something to be done with resources. The
>present way (been around forever) using #defines has always been a bit of a
>kludge in my opinion.
*****
How so? It is no more a kludge than the use of #define to define any other constant.
*****
>
>I would like resources to have names, which would allow for better code sharing.
>MFC could convert these "under the hood" to global values if that's what's needed.
*****
Resources have always had names. They're just hard to use. Any resource whose name is not
preprocessed into an integer by having a suitable #define is named with the literal string
that is its name. This has been true since Windows 1.0.
But it doesn't allow better code-sharing. What WOULD allow better code-sharing is if you
could separately compile .rc files and link .res files together, using link-time
resolution for the names instead of compile-time resolution for the names. Then you could,
as many people have asked for, put resources into .lib files (after all, .res files are
just in COFF format, so all the mechanisms are already in place!)
Like most really useful features needed for large-scale development, this seems to have
escaped the Microsoft developers' attention for nearly 20 years. Instead, we are given
ActiveX, a gratuitously complex solution to a simple problem. Note that C# gets rid of the
resource problem by not having any resources (yep! They create thousands of lines of code
that create the forms on the fly!)
*****
>
>How in VS7 do you get a convenient list of member variables you have defined as
>you can in VS6 in the 'Variables' tab of class wizard.
*****
WHAT? YOU WANT A USEFUL FEATURE LIKE THIS! SHAME ON YOU! (I agree; the VS7 model is a
seriously defective way of handling this. I can't look and say "What controls don't have
variables attached", or add the variables quickly with one incarnation of the add-variable
wizard. A wizard that takes 2 seconds to invoke on a 2GHz dual processor is beneath
contempt. Another of the massive steps-backward that VS7 took, and again one of the many
reasons I am convinced the designer never actually wrote an MFC program in his life, or he
would know that this is an important feature!)
*****
>
>Why does the hourglass cursor come up when I hit F3 to search for the next
>occurrence of a string ? Something must be seriously wrong.
*****
It's VS7. ANYTHING can be construed as "seriously wrong" and you would be correct! It is
SO SLOW. After years of making the compilers and environments faster and faster, I get one
that is SLOWER on my 2GHz dual processor than VS6 was on my 500MHz uniprocessor!
*****
>
>As far as support for VS6 goes, I think that the overwhelming majority are still
>using it. I don't think that there are many commercial applications around that
>demand the use of .NET, the main reason that VS7 was developed.
*****
There is nothing in the VS7 interface that supports .NET that can explain the systematic
destruction of a useful interface.
*****
>
>Joseph M. Newcomer wrote:
>
>> Actually, the inboard help system sucks, too. I used to be able to tile the MSDN lib and
>> VS6 so I could read both at once. This does not seem possible in VS7. I have not been able
>> to figure out how to tile help and source code. I solved the problem by moving to a
>> dual-monitor system and keeping a version of VS7 on the "other" monitor just to read the
>> documentation (I don't use it for development, so what I get is an interface poorer than
>> the original infobrowser that came with MSDN #1, but we've already pointed out to MS that
>> the quality of their documentation browser has been declining for a dozen years, with each
>> release being poorer than its predecessor).
>>
>> Let's see: what would have improved VS6?
>>
>> * Longer edit controls for things like control names, so we didn't have to use horizontal
>> scrolling
>> * Getting the Z-order of dialog layout right
>> * Showing the entire string name in the STRINGTABLE, instead of having a fixed-size column
>> that chops it off.
>> * Supporting all the new methods, messages, etc. that have evolved since VS6 was delivered
>> * Allowing WM_GETMINMAXINFO to be handled for dialog-based apps that have a resizing
>> border
>> * Keeping all control member variables protected instead of public
>> * Allowing decent support so the ghastly editor could be replaced with a real editor
>> * Use the clipboard for copy-and-paste of controls so they can be copied and pasted
>> BETWEEN copies of visual studio
>> * A more reliable NCB file mechanism
>> * Multiprocess debugging
>> * Saving settings INSTANTLY so if VS6 or the OS or hardware crashes, all customizations
>> are maintained (instead of being lost), and if a customizatiion is made, it is instantly
>> available in all versions of VS that are started, even before the version of VS in which
>> the changes were made has not been closed (get rid of MS-DOS thinking, that people
>> actually EXIT programs!)
>>
>> I factor out the numerous improvements to the C compiler, MFC, etc. because these could
>> have been done as readily with a VS6 interface.
>>
>> What do I like about VS7?
>> * The tabbed dialogs at the bottom of the screen so I can quickly switch views if I need
>> to, e.g., having the call stack a single mouse click away.
>> * Z-order on dialogs is fixed
>> * I can make control variables protected (the default of 'public' is always wrong, of
>> course; there is no sane reason to make control variables public)
>> * Multiprocess debugging
>> * There is one other thing I like, but I can't remember it
>>
>> There is not room to list everything I detest about it.
>>
>> OK, that exhausts my list, at least at the moment. So why didn't we just get these
>> improvements? Because it became somebody's "toy project" to do a "new" interface that was
>> an "improvement". As far as I can tell, the designer not once, not ever, wrote an MFC
>> program or the defects would have been instantaneously visible. No usability studies were
>> done with real programmers, or the results were ignored. A competent design review would
>> have deep-sixed this design at its first meeting. And the abomination was actually allowed
>> to escape the designer's office!
>> joe
>>
>> On Fri, 14 May 2004 12:07:31 -0600, Jerry Coffin <jcoffin@taeus.us> wrote:
>>
>>
>>>In article <vp78a0lq7m2ol6e40rijbf427cf4dq7s91@4ax.com>,
>>>newcomer@flounder.com says...
>>>
>>>>It is a good question. A lot of us wonder the same thing. Bottom line: until VS6 actually
>>>>stops running, we consider VS7 only as a last-ditch solution. Since effecitively it hasn't
>>>>been supported in years (SP6 came as a surprise to most of us), it is not something we've
>>>>been overly concerned with. The real pain is fhe difficulty people have in getting VS6,
>>>>the last decent development environment Microsoft delivered. I have on client that went to
>>>>VS7 because there was no way to get VS6, then a few weeks later ranted at me for three
>>>>solid hours about how VS7 was unusable.
>>>
>>>My advice would be to get them to buy MSDN Professional (or higher)
>>>which will get them copies of VS 6.
>>>
>>>My advice to Microsoft would be to start work on VS 8 by scrapping
>>>everything in VS 7.x, and starting over from VS 6. The SOLE change
>>>in VS 7 that should be retained is having the option to keep the help
>>>system in-board. Of course, from another viewpoint, that's not
>>>really a new feature of VS 7 either -- it's just going back to the
>>>way things were in VC++ 4.x.
>>>
>>>
>>>>The worst part about the rant was that I could only agree with them on nearly
>>>>every point. Their project is one of the two VS7 projects I currently support.
>>>
>>>In this case, I should probably tone down my rhetoric in other
>>>threads -- if you have to support _any_ VS 7 projects, you deserve
>>>moral support, no matter how certain I might be that you're wrong.
>>>
>>>
>>>>Besides the obvious failure to have applied a design review process (or even the most
>>>>rudimentary of usability studies) to the VS7 interface, Microsoft's second worst mistake
>>>>in the VS domain was discontinuing the availability of VS6. This is based on the premise
>>>>that it is sound business practice to discontinue a successful product while replacing it
>>>>with something that would fail a first-semester GUI design course. (I know someone who
>>>>teaches GUI design, and I've often thought of telling him he should submit VS7 to his
>>>>students and have the entire class critique its numerous catastrophic failures, and send
>>>>the collection of student papers to Microsoft. Preferrably cced to Steve Ballmer).
>>>
>>>What have those students done to you, that you'd subject them to such
>>>a thing? Personally, I think this would be unconstitutional: if
>>>convicted criminals are protected for cruel and unusual punishment,
>>>surly poor, possibly even innocent colleges students should be as
>>>well.
>>
>>
>> Joseph M. Newcomer [MVP]
>> email: newcomer@flounder.com
>> Web: http://www.flounder.com
>> MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: Joseph M. Newcomer: "Re: Visual C++ 6 support issue"
- Previous message: Vivek: "Re: Debug and Release build"
- In reply to: Ian Semmel: "Re: Visual C++ 6 support issue"
- Next in thread: Yasoo: "Re: Visual C++ 6 support issue"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|