Live data from Hacker News

I found a bug in the .NET framework and fixed it by hand-altering the DLL

blog.nullspace.io

31–40 of 124 posts

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#31
post #15

Earlier quoted context omitted.

Aren't you allowed to send a git (err tfs) pull request there at least within the company?

I've read several places that even Microsoft is not standardized on a source control management, some use tfs, some svn, some git, etc.

Different VCS is suited to different things. Perforce is great for gargantuan codebases with strong oversight requirements. Git is a poor choice if you check in lots of binaries. SVN is pretty widespread and supported natively by a lot of tools.

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#32
post #7

The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…

1) You can file bug reports against .NET and they get fixed. (Typically very slowly, but that's enterprise vendors for you...)

2) The tools they used to find & fix the bug are all based on fully-specified, documented, and supported mechanisms: ildasm and ilasm are stock .NET tools, and ilspy is using Mono's IL decompiler/compiler library.

3) You can compile an app against your own builds of any of the standard libraries if you want (including mscorlib, with caveats) and run it, so a fix like this can be deployed and maintained as much as you like, even if it's not Great Engineering.

4) This hand-patched DLL wouldn't corrupt any other app on your system, and you can ship and version it yourself, so it wouldn't break as a result of a system-wide .NET hotfix or anything like that. .NET's fully-specified ABI also means that it will work across all supported platforms.

5) Mono is open source, so you could always ship against mono and mono's mscorlib (both open source, naturally) if you absolutely can't wait for a .NET bugfix to ship AND you're unwilling to patch the dll yourself.

People love to bitch about .NET, but it actually provides a really good ecosystem here. Very little of it is truly a black box, the spec is extremely readable and precise about the things it covers, IL disassembly is extremely readable, IL disassembly fed through a decompiler like ILspy/dotPeek is doubly readable, debugging is straightforward even without symbols, and recompilation/patching is trivial because everything is well-specified and there's a robust open source library for it. (Even if there wasn't a library, you could just use the standard ildasm/ilasm pair.)

Oh, and you can compile native no-kidding C/C++ to .NET targeting the same instruction set and get all the benefits of the above. If you want to.

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#33
In situations like this, you can report the bug to Microsoft Connect:

1. Submit bug report. 2. Wait six months. 3. MS tech will post a comment, "this will be fixed in the next release". 4. Wait two more years. 5. Bug report will be closed as "won't fix".

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#34
post #11

Earlier quoted context omitted.

> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.

i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices oh wait

Apply some common sense, you think they let MS employees just commit to any codebase they like? And this is leaving aside all the annoying steps of locating their repository, figuring out how to build it, testing, finding out the right person to send the patch to, going through code review.

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#35

Earlier quoted context omitted.

Out of curiosity, would you have been able to read the actual source if you wanted?

Microsoft already publishes the source code for the .net framework (and I think other projects like asp.net and mvc) at referencesource.microsoft.com

They do, but interestingly that particular assembly is not included. Or at least I couldn't find it there.

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#36
post #11

Earlier quoted context omitted.

> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.

i'm glad someone who works at the company like you was able to enlighten us as to microsoft's internal practices oh wait

It's one of the things Nadella has talked about, and plans to address over time (the extreme compartmentalism of and fierce "not made here" attitude a lot of departments/groups within Microsoft have developed over the past few decades.

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#37
post #11
post #9

Earlier quoted context omitted.

---Author here--- I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!

> and still chose the hard way Chose? Unless you work on the team that made that DLL, it's likely you'd be jumping through hoops even internally.

From good source here:

You don't actually jump through hoops. All you get to do is submit the bug, which gets logged in the bucket of thousands of other bugs.

Then the PMs will gather for bug triage for the next release, which have to compete with the next shiny project features. Nobody wants to fix bugs that only one developer has. It's just not worth it. This bug has existed for years, and it is likely you could modify your code to generate different byte code.

So the bug likely won't be fixed for a while.

I love .NET. I am just describing the reality of the process of bug fixing. Also, if you fix it, who knows what else will regress. That also imposes a bias towards not fixing these kinds of bugs.

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#38
post #9
post #7

The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…

---Author here--- I should disclose that I actually work for Microsoft, and still chose the hard way. Fuck the police!

You sure like saying "Fuck the police!".

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#39
post #7

The real news here is that this is considered special. In most other languages, they'd have forked the source, fixed it, recompiled it for their own uses and submitted a pull request or patch. I'm a big .NET fan, but the fact that we have to jump through such hoops to find and fix a bug, and then still have near certainty that we're going to have to reapply the patch for many updates to come, well, that's just a bit…

1) You can file bug reports against .NET and they get fixed. (Typically very slowly, but that's enterprise vendors for you...) 2) The tools they used to find & fix the bug are all based on fully-specified, documented, and supported mechanisms: ildasm and ilasm are stock .NET tools, and ilspy is using Mono's IL decompiler/compiler library. 3) You can compile an app against your own builds of any of the standard librar…

>(Typically very slowly, but that's enterprise vendors for you...)

Ah yes, that's why you pay $$$ for software :).

Re: I found a bug in the .NET framework and fixed it by hand-altering the DLL

#40
post #17

I did this once with GCC. "But GCC's open source!" you say. Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM; and GCC maintainers insist on precise test cases to vet a bug, even if the issue is immediately obvious from reading the source code and the bug only occurs in certain very complex situations. (/me looks forward to the day Clang/LLVM become…

> Well, GCC is next-to-impossible to compile for a target other than the host, especially if the target isn't x86 or ARM; You're exaggerating. I had no problems compiling gcc 3.something targeting MIPS-I on an x86 Linux host.

I can't tell if you're being sarcastic. Generally, compiling GCC to target another architecture involves not only recreating most of the root directory structure (notably include files) of the target on the host, but also compiling libc, bintools, and a few other more obscure libraries. And this all needs to be done in the correct order (which involves something like compiling half of libc before compiling GCC, and compiling the rest of libc afterward).

Maybe in 3.x and MIPS it "just worked". My experience is 4.x and Tilera. Myself and another engineer dumped a week into that sinkhole before giving up.

Clang/LLVM on the other hand… ./configure && make && make install. No other wacky dependencies or build steps. And it generates better code in many cases (particularly when dealing with structures).

Post reply on HN