101–110 of 124 posts
The fact that you can even do this without setting off a ton of alarmbells about failed checksums is what really scares me.
I should be able to change the software on my own machine, stored on and running on hardware I own, in whatever way I desire and have it do what I want. (And in practice I have - opening a binary in a hex editor and changing a few bytes is not at all beyond me.)
Earlier quoted context omitted.
How is that any different than a central maintainer of Linux accepting patches and reviewing them before they go in? The only difference is that you can see the source and test on your own machine first. MS employees don't have to commit to any codebase they like, but they should be able to obtain the actual source, so that "with enough eyes, all bugs are shallow".
Actually anyone can obtain the source, it's publicly available.
Earlier quoted context omitted.
> 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 c…
I'm not. The process is well described, it tells you exactly prerequisites, in which order to build them, and how to configure the directory structure for building gcc itself.
It worked for me the very first time I tried it.
Though I needed only a freestanding implementation, so I didn't bother with compiling libc. I believe that cross-compiling libc can be painful.
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".
1. Submit bug report. 2. Get response like "we're looking into it" 3. Wait 2 to 5 months
4a. MS tech (or sometimes event Stephan T. Lavavej himself) posts a comment, "this will be fixed in the next release" 5. Bug report closed as fixed 6. Wait x time where x mainly depends on the point in time of the release cycle where 1 occurred. The later 1, the smaller x. You've gotta time those bugs to get them fixed quickly :P
4b: "won'tfix" / "by design" i.e. I got an explanation of what I did wrong, or otherwise why it happens
4c: "deferred" i.e. posted something that can be worked around and considered too minor of an issue to fix soon
Sidebar: I haven't done deep C# in several years, since moving to F#. This code is getting to look butt-ugly. It is not a good thing if it continues like this. We already have C++. Don't need another one.
Don't worry, each new version of C# gets more features from F# and Scala, this year we will get more syntax sugar and an extensible compiler (with proper IDE support - unlike F#): https://roslyn.codeplex.com/wikipage?title=Language%20Featur... . They will add pattern matching and maybe something more interesting in the version after that. There aren't too many practical reasons to pick F# over C# today and soon there…
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…
I haven't really kept up with the latest stuff, but I've seen mentions of crosstool-ng, which may be a newer take on it:
https://github.com/diorcety/crosstool-ng
So, no, it's not next-to-impossible. It's a little complicated, and that's why these projects exist, but my memory of crosstool was that it made it trivially easy: run the script, let it compile for a bit, and voila, you now have a brand-new cross-compiler toolchain.
I would personally be very careful with the recompiling dance, at least in other languages, as alignments and such might come out of place. A patch feels much less dangerous if this is something that is to be deployed.
(I always also try to rig such builds so that the build bombs if the dependencies change. That way it doesn't survive version changes without forcing someone to take a long hard look at it.)
Earlier quoted context omitted.
Yup. Its funny as a dot net dev you learn to really love a few ms things and really hate the others. C# is a brilliant language. Entity framework is an awesome ORM. But anything to do with deployment? IIS? So very much rage. I'm in charge of the build process on my team and I'm quickly becoming "that guy in the corner who swears all the time".
Your still not cursing as much as the guy building msi installers though...
I deal with VSTO, WiX, ClickOnce, IIS, COM, MSMQ and the usual bits. Pays well but it made my hair fall out and has taken a couple of years off my life at least.
I long for the gong to ring so I can go home to my MacBook and OpenBSD (where I truly belong).
Earlier quoted context omitted.
This. One bug in IE9 clickOnce launching thanks to them changing how download prompting works. 1. Reported to connect whilst in preview release status. Closed. Reported again. Closed. FULL test cases provided. 2. We're a gold partner with a £500k spend a year on licenses. Partner support. 19 hours on the phone over 6 months, blame shifting between the IE and .net teams and a daily call to get the case closed without…
Yup. Its funny as a dot net dev you learn to really love a few ms things and really hate the others. C# is a brilliant language. Entity framework is an awesome ORM. But anything to do with deployment? IIS? So very much rage. I'm in charge of the build process on my team and I'm quickly becoming "that guy in the corner who swears all the time".
Yes deployment is a broken pile of crap. We inevitably did an NIH and wrote a massive push deployment framework for that. Cost a fortune. And I look after our integration environment as well (TeamCity). TC is nice but the .Net toolchain is horrific. Requires so much maintenance it's unbelievable. Also everything is stateful meaning repeatability is a PITA.
I'm the sweary guy too. Usually "we should have used Java - we don't have to invent new wheels every two mins".
The only bit of our infrastructure that is reliable is some memcache boxes on CentOS which have been online without a reboot for over two years!!!
Give me a C compiler, preferably LLVM and let me leave all this behind.
I know a lot of people here balk at the idea of paying for tooling, but Red Gate's Reflector[1] is absolutely amazing for situations like this. Not only is it a decompiler, but it allows you to decompile at debug-time and step into third party libraries. Assuming they haven't been obfuscated, this is an extremely useful tool. I've used it to track down a number of issues within Visual Studio itself and within some of…
You are justifying closed-source tools by using a closed-source tool to debug your closed-source tools?
By the time we've got the PO's signed if it was open source then I'd have solved the problem at hand.
To get around this, defensive purchasing is required: at least one VS ultimate license, at least one MSDN sub, ANTS profiler, IDA Pro, Azure VM allocation ready to roll for test machines and two guys who actually know something about all this.
This is the safety belt cost: about $30000 + $120k a person