Comment by mastax | Hacker News Reader

Comment by mastax | Hacker News Reader

I understand why this is the case but it’s also extremely frustrating:

> It is extremely difficult for programmer-users to report bugs against the Windows API (we're supposed to direct you to Feedback Hub, but you may as well transmit your message into deep space). I've filed OS-49268777 "SRWLOCK can deadlock after an exclusive owner has released ownership and several reader threads are attempting to acquire shared ownership together" with a slightly reduced repro.

> Thanks for doing your homework and creating a self-contained repro, plus pre-emptively exonerating the STL. I've filed this OS bug as a special favor - bug reports are usually off-topic for r/cpp. The microsoft/STL GitHub repo is the proper channel for reporting STL misbehavior; it would have been acceptable here even though the root cause is in the Windows API because this situation is so rare. If you see STL misbehavior but it's clearly due to a compiler bug, reporting compiler bugs directly to VS Developer Community is the proper thing to do.

The best way I know of to report bugs to windows is report them as documentation bugs. see for example https://github.com/MicrosoftDocs/cpp-docs/pull/3526.

Clever!

Clever until they just fix the documentation to match what the implementation is doing.

It looks like it was declared in Nov 21, and in May 23 they merged in the "fix" by adding "it's approximate" to the docs ( https://github.com/MicrosoftDocs/cpp-docs/commit/447b5d8a781... ), so not sure this is the best approach for actual bugs.

> It is extremely difficult for programmer-users to report bugs against the Windows API

I can't imagine living in this hell. When I find bugs in Linux, I E-mail the actual engineers directly and get responses in under 24 hours: https://lore.kernel.org/lkml/Zcb3_fdyJWUlZQci@gmail.com/

Thats pretty cool. No comments left in the code after the revert though. Are they relying on their minds and commit history as documentation of invariants? How do they prevent the same mistake from being made again in the future?

Microsoft engineers have emails too.

And how would you know what email to contact in a case like this one? It’s not about “having email”

You can either go down the route of finding the team that owns the code and then contacting someone on that team, or by contacting someone you know from the company to look it up for you or report the bug on your behalf.

> the route of finding the team that owns the code and then contacting someone on that team

Nice circle, now the reader will only hav to fill in the rest of the owl.

The benefit of the open open development model of Linux is that you don't have to have "someone you know" on the inside or essentially spam whatever contacts you can dig up until you find someone who has pity on you. You have actually publicly available developers (from many different companies, including hardware manufacturers) as well as real bug trackers where you can find if other users have had the same issue.

And Twitter/X accounts.

I have had a lot more things fixed in Windows or MSVC from nagging devs on there than from reporting through any official channel.

+1 if you want to reach a real engineer they are going to be spending their free time on sites like X and not on sites like some community feedback and bug reporting form

Nice to know that it's not just Apple to whom reporting bugs in hopeless. :)

I generally assume that's the case for any large company.

Sometimes I get pleasantly surprised, but generally speaking the internal incentives are skewed against, the primary focus is whatever the roadmap is followed by tickets from paying clients, public bugs generally have a very low hit ratio so they're unrewarding, unless you manage to snipe one of the company's employees (either nerd-snipe or interest / shock them enough to raise the issue internally) it's like playing the lottery.

> I generally assume that's the case for any large company.

Despite Google partly losing its marbles recently, reporting bugs to Chromium still works very well.

I wonder if the open source element of the project keeps them “honest” to some extent?

Not my experience. When I report a bug in Chromium, it’s usually quickly verified as legit, and then left for dead forever.

> I generally assume that's the case for any large company.

What works to some degree are dedicated maintenance teams providing development support. If their main task is fixing bugs and they are evaluated on this basis, support tickets reporting real bugs have a good chance to receive the required attention.

However, there is always the temptation for management to redirect resources from those teams. But at least in the B2B area costly customer escalations can remind management of the importance of good maintenance.

Depends on the team, I think. I've had no luck at all with the OS/framework and "core" apps bugs, except getting the report that it has been fixed, and I should install the new version of the OS. Only to find out the bug wasn't solved.

The Logic team, however, has been helpful, and in one or two cases (that were discussed in musician's forums) went out of their way.

The amount of attention and care a bug report or a piece of feedback receives is inversely proportional to how easy it is to file it.

Former AWS here.

My literal job for the last part of my time at AWS was "help triage bugs in the AWS SDK." This is by far the best repro I've ever seen for such an in-depth event.

Most of the tickets you get in open ticket trackers are incomplete [ https://github.com/boto/boto3/issues/4011 ] nonsensical [ https://github.com/boto/boto3/issues/4018 ] or weird [ https://github.com/boto/boto3/issues/358 ].

Like the comment says, filing an issue on GitHub would've also eventually led to a proper internal report, so the system isn't wholly reliant on one guy trawling Reddit.

I have many complaints about Win32 (having half a dozen different error code types, for one), but outright bugs are really rare.

Reply on news.ycombinator.com