On the Visual C++ team we really value customer feedback and strive to make every interaction between ourselves and our customers as rewarding as possible. Recently we were reading a post on one of our Forums and were concerned to see a customer commenting about not receiving feedback on Visual C++ bugs they had reported on the Microsoft Connect site. In the post, the customer questioned if we are at all interested in their feedback since it appeared the bugs had been closed without any indication of what action (if any) had been taken.
We took a look into the situation and the short answer is that we messed up. Without going into too much detail, we were moving bug reports from one internal system to another and in the process lost the links to the customers who reported them. This resulted in the customer seeing all their bugs recorded as “closed” whether they had been or not. Luckily for us one of our customers cared enough to let us know that our performance was not good enough and so we got a second chance to get it right.
So this should now be fixed and the bugs should now show their correct status. If you have reported a bug on the Connect website previously and it was mysteriously closed a few months ago, then please return and see if there is a different resolution now. Also if there are no comments about why your bug has been closed then please reactivate it and comments will be added.
We really do value our customers and apologize for any inconvenience this has caused.
I used to visit the Connect site almost daily to report and vote on bugs and suggestions that were important to me. However, not anymore. Nearly all of the bugs, one after another, were marked "Closed (Won't Fix)" with comments along the lines of "does not meet Orcas product bar" and talk of red / green bits. I understand the need to prioritize. However, when you recognize a bug, then mark it "Postponed", not "Close (Won't Fix)". Honestly, my expectations of Orcas are particularly low.
(Also, while not directly related, the Connect interface is seriously lacking and difficult to use compared to the original Ladybug).
I'd say that the current Connect is better than the old Product Feedback Center in some ways (comments on vote), and is improving in others, but the search is still poorer, and it's quite a bit slower. Also, there isn't an explicit category for submitting bugs on the Connect site itself, like there was on PFC.
There are also a couple of little other weirdnesses in Connect, like not having people vote on their own bugs to state how important they want a fix, and being able to validate your own bug.
Consistent feedback to bugs on the Connect site is a problem, and can be a turn-off to newcomers. In addition to seeing bugs closed with no comment, there are confusing resolutions (closed as External or Other with no comment?), comments that appear to be meant for internal use only ("we already have this"), and finally, inconsistency in close messages. Some of them are way too long, almost a page long, and look more patronizing than helpful. I'd think that a simple "afraid we can't fix this now, see this link for more details on our triage process" would be better.
The delay to first response is sometimes way too long. The bug volume is indeed very high and tough to keep up with, but if it takes three months to close a bug as No Repro, it's very unlikely that the original poster will still have a repro case himself.
Finally, I agree that (Won't Fix) is a very bad way to label a bug that won't be fixed in the current cycle. When I see Won't Fix, I think that a bug is going to be left because it can't be fixed due to some dependency, not due to time.
I'm writing this post from the 3rd floor of a condo building in Bangkok Thailand. I am on vacation but
I think that there is a bug or mistake or changing between the 2 functions (fopen) and (fopen_s) in VC++8,
What I understand that Microsoft found a new function (fopen_s) instead of (fopen) to increase security.
The old fopen takes 2 parameters (the file name, and the mode).
The new fopen_s takes 3parameters (FILE ** , the file name, and the mode).
This what is in the help:
==== VC++ 8 help quote ===========
const char *filename,
const char *mode
And for fopen_s -----
==== end quote =================
When put this in practice:
fopen( needs the new 3 parameters)
fopen_s(take 2 parameters)
For converting programs that used to work in .NET version the fopen give a compilation error:
Error C2660: 'fopen' : function does not take 2 arguments
If we change it to fopen_s it will work in the compilation but errors occur in the run time:
Debug assertion failed!
I tried to use the old .net <stdio.h>, it works in the compilation but fail in the run time. Exactly like the fopen_s.