Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


BitCrazed BitCrazed

Niner since 2008

  • Developing a Windows Store app

    Holy cow! I think something went wrong with the audio encoding on these videos - sound is totally overdriven.

    Shame since this is a great session!

  • Anders Hejlsberg: Introducing TypeScript

    @VironPapadopoulos: No, Anders is using a Samsung Series 7 slate like those handed out at //BUILD last September or available from MicrosoftStore.com:


  • Checking In: Larry Osterman - 26 Years of Programming at Microsoft and Counting

    @Brice Richard: You've clearly never worked on a really big software project before. Of course Windows is documented - perhaps moreso now than ever before thanks to the Consent Decree & EU settlements Wink

    In fact, the original Windows NT design docs written by Cutler et al were actually donated to the Smithsonian!

    What you don't understand is just how big Windows is. It's approaching 100M lines of code these days. It includes the Kernel (HAL, memory manager, DMA & interrupt handling mechanisms, drivers, DRM, etc.), Win32, GDI, User, System, RPC, COM, DCOM, COM+, ActiveX, DirectX, ADO, FAT/NTFS, the Windows shell (Explorer, control panel, etc), WMI, Powershell, IE, WiFi and networking infrastructure, tools and applets, SMB (the docs for this one feature alone are 500 pages long!), Registry, Hyper-V, Active Driectory, ADFS, CLR & .NET, and so on and so on. Want a taste of how complex this all is? Go read MSDN or the Windows Server protocol specs: http://msdn.microsoft.com/en-us/library/gg258393(v=prot.13).aspx">http://msdn.microsoft.com/en-us/library/gg258393(v=prot.13).aspx

    No one human being could possibly remember all public API's (and their parameters and return types) and what they do, let alone understand the enormous complexities that exist throughout the inner workings of the entire OS.

  • Tech Talk Interview with Patrick Hevesi

    Could you not afford any lights? Devil

  • Anders Hejlsberg: Introducing Async – Simplifying Asynchronous Programming

    Isn't it amazing how how much easier it is to comprehend a complex subjecct when presented by someone with so much enthusiasm? Wink

    Great work Anders & Team. Can't wait to see what you attack next Big Smile

  • First Look: Windows Phone 7 Series Hands on Demo

    The device shown in the videos around launch is:

    1) An internal-only prototype device

    2) Running unfinished software

    3) Running untuned software


    The software is currently being driven to completion and will be tuned to handsets as their designs and implementation details are finalized.

  • First Look: Windows Phone 7 Series Hands on Demo

    DON'T - there is NO confirmation yet whether the HD2 will or will not run WinPhone7. FAR better to wait until the officially supported phones are announced and released.

  • IE 9: Surfing on the GPU with D2D

    Essentially, GDI, GDI+ and DirectX provide a layered architecture for rendering of 2D and 3D imagery, text, etc. When you print a page in a GDI-based app today, your app obtains a printer Device Context (DC) and draws on it. This DC can then be submitted to the printer for rendering which passes the DC to the printer driver in order for the DC to be converted into printer-specific commands (e.g. PostScript, etc).


    Direct2D is no different. You ask DirectX to create a rendering surface compatible with your printer and you draw on it. The surface can then be passed to the printer driver for translation into the printer-specific language.


    Review some of the WinHEC 2008 presentations on DirectX and XPS:


  • Mark Russinovich: Inside Windows 7

    IO is extremely costly. In most cases, if a thread requests an IO operation, it's going to be hanging around for quite a while for the IO to complete, so it makes sense to curtail the thread's quantum and move onto the next thread awaiting CPU time (i.e. context switch).

    When the IO operation returns (most likely a DMA operation these days), the CPU will be interrupted and the interrupt handler fires, unblocking the interrupt service thread (IST) and releases the CPU. The CPU then works out whch thread to run next. Because the IST is a high-priority thread, it'll most likely get the next quantum and complete the IO operation. Your IO requesting thread will then be reactivated and return.

    Forcing the IO requesting thread's quantum to extend (to HALF A SECOND???) will only slow down the machine as the CPU will be able to execute FEWER threads per second because of the largely dormant thread hogging the CPU's time.

    The reason that creating two Zip archives simultaneously mgiht be is slower has many factors, including the rotational, seek and data transfer capabilities of the storage device itself, how fragmented your storage device is, whether your device implements some kind of write buffering, etc. And that's not to mention whether you're running single/multiple processors and what else is running on your box.

    If it takes longer to create two zips at the same time vs. doing it serially indicates to me that you may be suffering from slow disk and.or high disk fragmentation forcing your Zip tool to create and extend its file in many small chunks, causing lots of disk seeking and therefore slowing you down.

  • Windows Vista - 64 bit in the Mainstream

    Tarpido - In my Windows environment, I have run XP and Vista x64 exclusively (except one older box) for over 5 years now. Vista x64 is (in my humble opinion) the best 64-bit OS I've yet run.

    Chances are that your machine is slower after several months because you've installed a ton of apps and software on it. Much of that software will often load a start-bar "utility" or a background service at boot-up time. I've seen some machines with startup apps numbering into the 40's and 50's. Several tens of apps all trying to load at the same time as the OS is loading and initializing will often add several seconds each to your boot time.

    To get an idea of what's slowing down your machine, run MSCONFIG and loot at the Startup tab to see what loads when Windows starts up. I strongly encourage you to un-check the apps that you DON'T want to load when you boot your machine. Note - this doesn't remove the item from the list - it just stops it loading automatically at boot.

    You should also review the Services tab to check what services are starting up when you boot - note that most of the Microsoft services will be required by some part of the OS so turn off auto-starting service with caution, but you may well find a bunch of stuff starting up automatically that you don't need.

    You ask "How can I expect 3rd party apps compatible with 64 bit when some of Microsoft's own apps are not ready for 64 bit." I understand your concerns, but note that the stars have only just aligned to make 64-bit a reality in the retail market (to which utilities like SteadyState are targeted). Rest assured, most teams at MS are now planning to or are already building apps that are compatible with Windows 64-bit.

    Note, however, that many apps don't necessarily need to be converted to 64-bit! Many apps that will never consume significant amounts of RAM will be unlikely to benefit from being converted to 64-bit. Apps that WILL need to be converted include those that are likely to consume significant amounts of RAM and anything that runs in the kernel including all drivers (this may be where SteadyState currently falls short). Apps that consume significant amounts of RAM include apps that works on graphics / video / audio (e.g. Photoshop, Expression), software development tools (e.g. Visual Studio), databases (e.g. SQL Server, Oracle) and other servers (e.g. Exchange), etc.

    For many other apps though, recompiling them to 64-bit will only increase their disk, IO and memory footprint, so many smaller apps will remain 32-bit for some time.

    You, the user, however will benefit from running these 32-bit apps on 64-bit OS though as you'll be able to run more of these apps simultaneously in your ne PC's much larger memory space.