I was trying to remember any interesting event associated with a new year and the best I could come up with this morning is many years after what I've been tweeting about, in 2010. In 2010 we were working on Dev11 (VS 2012) and iterating closely with Windows on Windows 8.
I was leading a team to create a tooling experience for JavaScript Windows Store apps. Windows 8 was the introduction of the Windows Store and the new WinRT APIs, ABI format, etc. that allowed languages like JS, C#, VB .NET, C++, etc. to directly call the Windows API.
It was still early in Dev11 development, and my team was writing a new JavaScript language service (as well as a new project system). There was already an existing JS language service.
However, it was built on top of JScript 5.8, which was the JS runtime that supported ES3 and shipped with IE8. To support ES5, ABIs, larger apps and better performance we decided to implement a new LS on top of Chakra (which was the JS runtime that shipped in IE 9 in early 2011).
Chakra was a highly optimized JS runtime implemented in C++ within a module named jscript9.dll. The JS LS was very different from the C# LS, because to get completion, we actually executed the JS up to where the caret was located within the file.
We then examined the runtime state and used that to generate completion lists, etc. This introduces all kinds of fun problems that I'll talk about at some point, like guaranteeing that program execution actually *gets* to where your caret is, that you don't get stuck in infinite
loops, that execution doesn't take too long, etc. That's another post though. For this thread, we all received a mail on Nov. 23rd, 2010 kicking off the creation of a 'Holiday Build' of Windows and developer tools that folks could play with during the last few weeks of December
(if they chose to). In many ways, the intent was to create a forcing function for integration across many teams and divisions. The goal was to have a installable VS that supported JavaScript Windows Store development within ~3 weeks (so by Dec. 15th)
It's important to know that this was months ahead of our plan for a dogfoodable version of JS. So, we had a problem. We weren't even close to ready. In particular, the JS LS had this annoying behavior of AVing, which since it ran within the devenv process, would crash VS.
It was sufficiently frequent that folks surely would have lost all of their work on a regular basis and there simply wasn't time to address the known issues, much less uncover what we would certainly find afterwards as our validation was nascent.
So we were in a pickle, we couldn't rely on the old JS LS because it didn't understand the WinRT API at all (or ES5), and we really did want to start dogfooding on the new LS if we could. We couldn't have folks trying this and crashing every few minutes though, so…
time for everyone to close their eyes and hold their noses, we decided to *catch* AVs. Please don't do this, it's not good practice. However, it is possible by making use of this attribute docs.microsoft.com/en-us/dotnet/a….
In this case, the part of the LS that interacted with VS was written in managed code and called into JScript9ls.dll in order to provide language analysis. So, in that relatively short time, we implemented a proxy layer that insulated all of our calls into jscript9.dll such that
if an exception, like an AV, happened we would 'zombie' the proxy layer and prevent all further calls into jscript9. This would disable all LS functionality, your code wouldn't colorize, there would be no completions, etc.
We did display a message indicating that the LS had crashed and suggested saving your work and restarting. This prevented data loss, but obviously the process was in an unknown state. Our intent was that the proxy would limit the damage that would cause. Long story short, it did.
We successfully delivered the Holiday build, opened up dogfooding for Windows Store JavaScript apps, and were able to start getting dogfooding on the new JS LS and Project System. Of course, we now had another problem.
We didn't get 'Watson' (Windows Error Reporting) dumps whenever the LS crashed because we intercepted the AVs. Our new year's goal was to then remove that support, fix the underlying issues, and get a new build out as quickly as possible.
Although we didn't want to catch AVs any longer, we still wanted to prevent the LS from crashing if we had a managed exception.
We didn't want to lose reporting though, so early in 2011 we added the following dialog that would also zombie the language service, but allowed us to easily get reports with enough context to fix the issue: Image
When we shipped externally we changed this kind of reporting into what we call a non-fatal Watson, which would capture process state at the point where the error happened and upload anonymous telemetry about the issue (if the user opted in) so we could diagnose and fix.
Anyway, that year was very hectic right before the holidays and we just barely managed to deliver. Since then, whenever starting on a new project, I make sure have a sane and immediate way to collect, collate, and diagnose errors on day 1.
You never know when you might need to deliver months ahead of your original schedule :) Happy New Year everyone - this was a morale item given out in 2000 for folks on the VB team to ring in Y2k! Image

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Anson Horton

Anson Horton Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @AnsonHorton

3 Jan
Incremental rebuild was a feature of the C# compiler which was meant to increase the throughput after an initial build. It worked on the principle that changes in between builds are localized, and that the information gathered by the compiler from previous builds wouldn't be
entirely invalidated; specifically, some of the information and, indeed, the assembly itself could be updated in an incremental fashion resulting in faster builds.
Both the VS 2002 and VS 2003 compilers exposed this option through the /incr switch on the command line, and the ‘Incremental Rebuild’ option in the Advanced tab of Project Properties. In 2002 incremental rebuild was enabled by default for all project types.
Read 22 tweets
2 Jan
In 2001 I had only recently joined Microsoft full time, so I was really just getting my feet underneath me in the org. There were many internal teams using C#, so one of the things I owned was an internal DL called CSharp User Community which had thousands of folks on it.
The point of the DL was for C# users to ask questions of each other to get help as they needed it, but I did participate a lot as often folks would ask for definitive answers. The downside to this is that I often received a large number of mails throughout the day directly.
If I'd had some more experience, I would have added the user community back to the threads much more often than I did. Regardless, this ownership led to some funny and uncomfortable situations.
Read 10 tweets
31 Dec 20
1/ In early 2004 we were heads down executing on Edit and Continue across a large contingent of teams. There had been several iterations of scoping, redesigns, and customer feedback.
2/ We had a weekly meeting every Thursday morning when representatives from each of the teams would get together and review progress. It was fairly heavy weight, but there were so many teams involved that it was necessary to have a regular sync.
3/ Regardless, E&C was coalescing, but teams were stretched thin working diligently to enable scenarios, improve performance, fix bugs, etc. It had been a month or so since we decided to add support for C# to the matrix as well, so folks were a bit stressed.
Read 19 tweets
30 Dec 20
1/ Edit and continue was a beloved feature of VB6 and was a priority for making migration onto .NET easy for RAD developers. EnC is magical when it works correctly. For web developers that are used to hot reloading, it enables that type of rapid development, but maintains state.
2/ Unfortunately, it is an extremely difficult feature to implement in a JIT'ed world as we discovered that with .NET 1.0. We actually had a version of EnC in the early releases of VS 2002.
3/ I'm fairly sure it persisted all the way up to Beta 1, though the history of when we removed it is a little hazy. The initial implementation wasn't coalescing. There were a huge number of bugs, it performed poorly, and it often corrupted the debuggee.
Read 18 tweets
29 Dec 20
1/ @werat asked about whether the debugger was using the C# compiler or language service in VS 2002. It was not. The debugger has a component called an ‘expression evaluator’ that is provided per language and is responsible for parsing and evaluating expressions when stopped at a
2/ breakpoint. For example, if you type into the immediate window, hover over a variable, type into the watch window, etc. the expression evaluator is involved. The debugger and the language service are actually deeply integrated in a number of scenarios in VS, which may
3/ initially seem surprising. I may talk about more of these scenarios in the future, but to give a flavor, when you set a breakpoint at design time the language service is involved, when you are using Edit and Continue the LS is involved, the range of what is being evaluated
Read 14 tweets
28 Dec 20
1/ I haven't mentioned much about C# integration into Visual Studio yet, but at the same time we were working on creating a new language, a new runtime, and a new framework we also decided to take disparate shells (MSDEV, devenv, VB6) and combine them. This was… a lot.
2/ As you might expect, taking on so much at the same time meant a very long development cycle. For those folks using VS6 it was a long wait for VS7 (‘98 to ’02). Regardless, we wanted to continue to provide a compelling LOB (line of business) client app framework while also
3/ enabling web apps (via ASP.NET, web forms/services, etc.). The client app framework manifested as Windows Forms and was the next iteration of a RAD app creation environment. The Windows Forms designer is extremely rich and intended to make developing UI-rich
Read 15 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!