RichTurner RichTurner

Niner since 2004

Hi! I am the Product Manager for Microsoft Identity Platform which includes Windows CardSpace, ADFS, ADAM, AzMan, etc. Prior to moving into this role, I was a Program Manager on Windows Communication Foundation (formerly "Indigo") and a Solution Architect within Microsoft Consulting Services. To find out more, please visit my blog at ! :)



  • Singularity III: Revenge of the SIP

    littleguru wrote:
    Is Singularity a lot slower then traditional operating systems once hardware protection is activated?

    Obviously, Singularity is very new, implemented in a radically different fashion from traditional OS' using languages and dev tools that are wayyy out there on the bleeding edge! However, despite this, comparing, for example a system the access a bunch of data on disk, processes it and exchanges it between worker processes, Singularity actually turns in perf numbers that are typically *very* close to the perf of XP or Linux! There are several scenarios, in fact, where Singularity wipes the floor with ANY other OS!

    Don't forget, a typical user-mode <--> kernel transition is not cheap! This is why GDI, for example, batches up calls to the graphics driver rather than crossing the boundary every time something on the screen needs to be updated. Singularity gets to replace the CPU ticks lost during transitions with CPU ticks that actually do work like making sure that the software is running correctly.

    littleguru wrote:
    How do you make sure that a pointer does not point to any address space of another process? Are there no classes in your C# dialect that allows that? Is there no IntPtr class and therefore no way to initialize a pointer with an int?

    Spec# (derived from C#) is, like most managed languages, doesn't have a notion of pointers (as traditional C programmers would recognize them). SIP's (Software Isolated Processes) can't reach beyond their own boundaries, just like one Win32 process can't reach into the address space of another Win32 process.

    Some days when I get down, I go and browse the Singularity source. The sheer beauty of this thing just cannot be overstated. Once you've seen a graphics driver or filesystem written in pure C# that exposes a hard contract which defines how callers MUST call it (whch cannot even be compiled unless they conform to the graphics driver SIP's contract). I've often been reduced close to tears looking at this thing - it's just jaw-droppingly beautiful!
  • Diving into the Vista Heap

    Almost, but not quite. malloc/free or new/delete are C/C++ language specific memory allocation/de-allocation routines. They allow you to create chunks of memory for your own use - untyped blocks in the case of C's malloc or untyped/typed in C++'s new.

    Windows itself provides a range of memory allocation routines which are called by various dev platforms etc. to allocate memory on device. This is necessary because in the world of modern OS', running apps do not get complete control over the whole machine and the OS must arbitrate between demands for blocks of memory and the availability of free RAM. When memory is demanded and it's not available, the OS will try to swap read-only data out of memory into a disk-based swap file and allocate some/all of the freed-up RAM to the requesting app.

    Why do dev languages implement their own memory management infrastructure? Because asking the OS for memory is not a free operation - it costs time. It's often faster for a dev platform to ask the OS for a chunk of RAM (which can take some time) and then divide this chunk up much more quickly and easily (since it doesn't need to check ACL's, etc) using app-specific algorithms.

    This is why memory-management tools like SmartHeap and later versions of VC++ could deliver magnificent perf improvements over the standard C RTL malloc.

    In more modern languages and environments such as Java or CLR, memory is Garbage Collected and the app is generally not in control of its memory - that's left up to the execution engine (e.g. JVM/CLR). The execution engine can deliver massive performance benefits for memory allocation compared to simply call the OS' equivalent of Windows' GlobalAlloc() API.

    What the CoreOS team at Microsoft have added is some insanely clever technology which will help deliver massive stability improvements by preventing code from executing in areas in which it's not permitted to - regardless of the toolset used to build the code. That's not to say that Vista's MM (Mmemory Manager) is flawless, but the bar for hackers has now been raised significantly.

  • InfoCard Explained

    In "InfoCard" v1.0, you'll be able to export/import cards to/from your hard-drive/USBkey etc.

    We're currently working on a mechanism to allow you to safely store your cards on secure portable storage devices whilst still maintaining InfoCard's open extensible architecture. Cool
  • Richard Turner - What is your advice to developers who are thinking about Indigo and ​interoperab​ilit

    Thought I'd replied to this forever ago! Sorry it didn't seem to make it to the site! Sad

    In answer to your questions:

    Q1: "Will Indigo Services require configuration of IIS?"
    A1: Yes ... if you want to host your Indigo services in IIS. No ... if you don't! You can host Indigo services in any CLR application - regardless of which transports, encodings etc. that your services require.

    Q2: (Paraphrased) "What platforms will Indigo support?"
    A2: Windows XP (SP2+), Windows Server 2003 (SP1+) and Windows Vista.

    Q3: (Paraphrased) "Will Indigo interop with Remoting endpoints?"
    A3: No. Remoting is not compatible with Indigo on the wire. There are several technical reasons for this including the fact that Remoting uses RPC-encoded SOAP whereas Indigo, ASMX and pretty much everything else that talks SOAP these days uses document-literal-encoding. Also, if you're using Remoting with the SOAP/HTTP channel, you should read my paper on ASMX/ES/Remoting perf - you might be compromizing your systems performance! Wink

    Hope this helps.

    Rich Turner