Justin Rogers : Longhorn

Commenting on ChrisAn's reliability posting because he BlogX'ed himself into a no comment corner

Justin Rogers — Sun, 13 Jun 2004 14:51:00 GMT

This'll be an interesting post because I can talk about more than one thing. First, ChrisAn added some new features to his blogging engine and either turned off comments using the handy config option, or his security word feature simply isn't working. http://www.simplegeek.com/permalink.aspx/f085404d-00e3-47b4-be83-c73a682bc1f3. Now he also posted something I'm even more interested in, the picture of the CLR reliability story. Been talking about this a lot lately and I had the following comments that I wanted to post on Chris's blog, but I'll do it here and he can follow the link. Here is his original posting http://www.simplegeek.com/permalink.aspx/1cdd3f95-bc89-4bfb-8a80-8ff66b6b1c7e, and here are the comments I was trying to make. The comment starts off weird, because I'm redirecting his question of, “What should the component do“.

No, what is the platform to do. If you need a 5 nines reliability platform, then you allow for that type of platform to exist. Mark enough pages to gracefully shut-down an appication when in a particular mode or use the extra pages to gracefully exit a soft OOM (by soft, I mean not entirely real because we actually have pages we are sparing). As the platform you have the power to allocate a special region just for this type of usage.

I think as the developer, I should also get an opportunity to mark pages for this reason. I might mark a single page, so that I can open a new file handle and write out some save data while I'm gracefully crashing.

I guess large platform changes are out of the question though, even though CER regions were created. Wiping your butt with tree leaves is going out of style though, so maybe we'll get some toilet paper soon enough ;-)

I think what I hit on above is actually pretty interesting. Within the realms of the CLR, all memory allocations controlled by the CLR itself. They have a managed heap, their own private place to store information. They normally control this region, but others can walk over it using API calls. Barring users munging the managed heap, I think the ability to mark pages for use in special circumstances would be a great idea. Mark say 4k of memory that can be used to allocate enough objects to walk out of an OOM. I pose this in two parts really.

Part 1 - The CLR Tear-down mode: The CLR tear-down mode is when a really solid OOM is on the table and the CLR has to gracefully shut-down or recover. In a normal OOM, the CLR can't allocate any more memory. With the new concept of a reserved region, the CLR can now allocate memory as it steps out of the OOM, possibly granting more abilities to the GC because the GC can allocate special trees for storing compaction data, or whatever it might need.

Part 2 - The Developer Tear-down mode: If theygive the ability to the CLR, I want it as well. Word currently has a feature where they save off your file every now and then in the case your computer tanks on you somehow. This could be a Word crash, or the power going out, or you forgetting to save before walking away from your laptop while on battery. The developer tear-down mode is similar to this, but it says the following, You are being torn-down and the process is being exited, use the 4K of memory you specially allocated so you can save your settings and come back up fighting.

I'd assume the types of things you can do in this mode would be highly restrictive so that you don't just throw the machine into another OOM by calling say some property to get state that in turn allocates a huge representation tree. I'd be happy if the entire process was just a service of the CLR, maybe with me marking some special objects that are guaranteed to be serialized in the case of such an event. In later events, as the CLR invades the OS more and more it could start to take advantage of the various reliability hardware that exists. Taking events and signals from power devices in order to ensure state gets saved, or maybe even storing state into a persistent memory device if it exists on the machine. Starts to give you more options.

Rob Rylea on autocompilation of XAML containing code within IE

Justin Rogers — Fri, 09 Apr 2004 05:46:00 GMT

Today you can't compile xaml on the fly. No xaml on the fly? Well that really sucks. Of course the points Rob makes are all basic points that apply under any code running circumstance. He points out how HTML + script creates possible badness, and how the running of HTML + script would be equivalent to auto-compiling XAML within IE. Okay great, so the problem set is now well-known and well-discovered. In other words this is an issue with a known security and threat model, and a series of well known and well exercised (partial) solutions. The options here are allow an alternate extension with different default privs (such as HTA does for HTML applications, I misspoke on Rob's blog and called these HTC's which are completely different) or to simply ask the user if they'd like to compile, making them aware of the possible results.

So I tend to be an advocate of asking the user. I think any security system that attempts to deny resources to a given program, should allow some way for the program to request those resources anyway. Java has the concept of asking the user if they want to allow file access for a given program. They have some other prompts that pop up as well. Are prompts a PITA? Not as much of a PITA as having some XAML not run in my IE because I have to go compile it now. That just sucks.

Give the user a basic decision, such as Yes compile and run this app, or No don't bother I'll go do something else. (I'm quite aware at this juncture of the number of users that click the Yes button after opening an attachment and seeing a window telling them that attachments of the said type might contain viruses and would they like to continue. However, you can't solve the issue of the idiot user can you?)

[Partial Rant] - A sick cyclic redundancy when providing answers to questions, versus questions asked...

Justin Rogers — Mon, 05 Apr 2004 16:08:00 GMT

Being a couple of years now after the public release of .NET, I have to say there is a great deal of literature out there on the operation of almost every section of the namespace tree. If you can find it in the docs, someone has written about it now using more detail than the docs would ever dare to encompass. That would lead me to believe that a large amount of information is readily available to answer, say 90% of all questions, or at least 90% of all basic questions.

Something like “How do I turn a string into an enum value?”, becomes what I would call a question of the day. Has it been well answered? Yes it has, and in excruciating detail. However, people still tend to use switch statements to convert between strings and enums. They also tend to lose a grasp of where to find the answer to the original question. You see, the more information thrown out there, the deeper the search hierarchy becomes. Also, the older items get in search engines, the less likely they are to be returned at the top of result sets. The less people search for given data, the same trend applies. So let's look at how a natural progression of Q&A might happen for converting string values to an enum might go!

PDC, Q: How do I quickly convert strings to enums?
PDC, A: The QuickStarts have a sample of that. Go look it up.
Betas, Q&A: The QuickStarts still have a sample of that. Go look it up.
V1 Release, Q&A: Many newsgroup postings have this answer now. As do several code sample sites. Go look it up.
Today, Q&A: Blog - Hey, I just discovered this awesome feature of an enums that everyone should know about.

I'm not trying to fight the natural progression of things, however, almost every question you can come up with has been answered at some point and is documented out there in the wild. People continue to blindly post questions, that have relavent answers available, and people continue to quickly answer those questions with a quickly typed response, completely ignoring all of the various in-depth study and resources available to answer the same question. Eventually, the waters get so muddied again, that the research has to be refactored by a new individual and reposted to yet again demonstrate the power and feature set of available methods. The cyclic redundancy in this help system is amazingly sick to me. While I groan every time someone posts a repeated answer (the groan having direct proportion in size to the last time I actually saw the answer given) I have to admit to myself that maybe this will be the answer that staves off the next 50 questions because it now gains time precedence and becomes easy to search for again.

It occurs to me that modern day help systems don't account for refinements made after a product has shipped. They don't take into account the immense processing power of the aftermarket to help improve the central help system and instead rely on various community support features and community linking. Since I'm not a help system guy, but I know someone who is I'll just point you to their blog. Go check out Hari Sekhar's blog and comment on every post he makes with meaningful responses to ensure future help systems try to incorporate community samples/articles/information in an attempt to stop me from groaning (my doctor says that it is bad for me).

On the new Longhorn SDK, a designer asks, "Does size matter"...

Justin Rogers — Thu, 12 Feb 2004 01:38:00 GMT

So the debate rages on Hari Sekhar's blog http://weblogs.asp.net/harisekhar/archive/2004/02/10/70864.aspx about the related trade-offs between downloading 3GB of help content in one big lump sum, allowing select pieces to be downloaded, and have nice auto-update features that get the latest help updates right off of the web.

Up to now the debate has been if they should package the help system into small parts so you could specialize the SDK help viewer and only get information on say XAML or Avalon, and not have to worry about WinFS or other platform features you don't give a can of beans about. The trade-off is to probably still have these packages (I'm guessing they are going to need some packaging routine that emphasizes performance), but just download the content all at the same time and allow filters, rather than availability to govern what you see and what sets get loaded.

Now, for the life of me, I want my cake, and I want to eat it to. Ideally, I'd love to be able to have all of the content on disk and have it be as performant as possible. Barring this possibility, then I think it will be imperative to have the partial download options. Furthering this concept, I want to be able to install multiple versions of the SDK veiwer each syncing different portions of the content (again, so I can have all my stuff and still get the full on speed of having only a partial help set loaded in each viewer).

In addition, indexes and content should be held differently, I may want the results of a search operation to return content that I don't have downloaded yet. When I try to access the content, I should get the option to automagically download it for use in my viewer. A kind of placeholder in the content tree should be held waiting for me to go look at something that doesn't exist yet, but could if I so desired. In general this type of fragmentation can lead to some really nice container formats (are they going to use WinFS and get a lot of free services?) that emphasizes grabbing any and all content on the fly if necessary. If I only want C# samples then it only gets that information, if I want another language it'll have to download that information. If I wanted the results of my content to be displayed in Arabic, it should download the arabic version if available, but I should be able to freely switch between English and Arabic. On demand content is extremely powerful, especially when you have a decent web connection.

To wrap-up:
1. Size matters, but people want it both ways. Some people have more space, others have less.
2. No matter what option you pick, I want the maximum performance.
3. If you go to the container formats, can we maybe get the full on-demand system? The loaded index, but non-existent content until it is requested seems very pleasing to me.