09.16.05

PDC Day 3

Posted in General at 1:01 am by jw

Today was definitely an interesting day at PDC.  We got our copies of the Release Candidate for DevStudio 2005, picked up the DVD for Longhorn Server and got to listen to Bob Muglia tell us about Microsoft’s plans to seriously put a dent into Linux’s pet Beowulf space.  I’ll keep the best until last though, so first things first and here’s the keynote summary:

  • The “share the pain” video was almost as good as the “Napolean Dynamite” video.  Another excellent production and one that developers can definitely relate to.
  • Later this year (I assume with the .NET 2.0 release), MS will release “Windows Server 2003 R2” which will have a bunch of new stuff:
    • Password synchronization with Unix
    • Active Directory can have an NIS master
    • Services for Unix bundled.
    • .NET 2.0 (obviously)
    • WS-Management support.
    • MMC 3.0, which supports managed plugins (no mention of Monad though)
    • Remoting of single apps
  • A guy from Macromedia gave a demo about the new IT infrastructure, but it seemed to me to assume a lot of tight coupling between developers and the field.  Maybe I didn’t fully understand it, but sounded like a lot of hype about nothing particularly useful.
  • In 2006, they will be releasing the “Compute Cluster Solution” (CCS)
    • Obviously targetting Beowulf – takes computing jobs and farms them out to a loose cluster.
    • Beta 1 is available.
    • Excel 12 will be able to use it to farm out big spreadsheet work.
    • It would be nice if you could do a distributed compile on it, but that’s just pipe dreams I think.
  • Full committment to have all administration interfaces available via Monad.
  • A bunch of work is going on with AD.
  • A bunch of work is going on with “Rights Management” too, but I still have to wonder if they really do get it.
  • In 2007, Longhorn Server is due out:
    • Terminal Services can be remoted through firewalls (so what’s the point of a firewall again if everyone can pump their protocols through them?)
    • Transactional File System
    • IIS 7 (more on this later)
    • Event log is enhanced with a bunch of metadata about events
    • Modular architecture – can remove all sorts of stuff including the GUI, it seems.
    • Hot add/swap CPUs, Disks and RAM (assuming hardware support)
  • IIS 7:
    • Very modular, like Apache.  Can add/remove modules at a directory level.
    • Even tighter ASP.NET integration (when the module is running)
    • Better diagnostics and tracing.
    • Killing the metabase for XML config everywhere.
    • All MS provided modules use the same API that we can write to.
    • Gave kudos to Apache – good sportsmanship there really.
  • Longhorn Server will support virtualization – VMWare stock gonna crash.
  • Everything 64 bit.

The first breakout of the day (after I’d collected my Longhorn Server DVD) was “5 things every Win32 dev should know”.  I just had to turn up to this one for the title:

  • Performance isn’t what you think:
    • Latency is the killer, that means DISK I/O.
    • Pointers lead to page faults.  Avoid them!
    • Arrays are awesome – lots of data locality so less faulting.  Trees are bad even though they are O(log n).
    • Doing nothing is really fast!
  • Play well with others:
    • Always ask “what if 2 programs did this?”
    • Polling is bad – uses CPU power and keeps memory pages present.
    • Be careful in thread pools to clean up when releasing the threads.
    • Be aware of remote desktops – animation on them sucks.
    • Scale up and down based on machine hardware.
  • Large Fonts and DPI changes:
    • “Large Fonts” only affect a few things around the window edges.  They will go away in Vista.
    • High DPI settings affect everything!
    • Scale bitmaps to cope with high DPI.
    • Expect 96, 120, 144 and 192 DPI and TEST with those DPIs.
  • Parent/Child and Owner/Owned is kinda complex:
    • Parent/Child is containment
    • Owner/Owned is encapsulation
    • Reparenting is hard. Avoid it.
  • Async input queues and syncing them:
    • AttachThreadInput mimics Win3.1 behavior on queues.
    • Owner/owned and Parent/Child attach input queues.
    • Journal hooks screw up your entire system.

Definitely an interesting talk.  Now to see if I can remember it all!  The next session was a tough choice.  Really wasn’t much going on so I went to a Vista UI guidelines session.  Didn’t say much other than go here, and gave a pretty good demo on how to code up the new dialogs for Vista to make stuff look good.  There’s a bunch of caveats when dealing with drawing on glass because GDI is so damn old and just doesn’t understand alpha blending.  The best deal seemed to just use WPF wherever you can.

The lunchtime session I went to was on memory tuning in .NET.  Lots of interesting tips, but nothing too fantastic if you’ve delved around a profiler before.  Basically, the tricks are to use vadump, CLR Profiler and sos to poke around and figure out all sorts of cool info.

Next was a Java/.NET integration discussion which I really don’t have too much to write about.  The general feeling of the talk was that they could demo a lot of stuff that will work well in a year or so when the final products are out and settled, but we’re still in the mess we currently find ourselves and nothing was mentioned about the small differences in interpretation of WSDL that can cause so many problems.

I’ll leave the Vista Internals talk for last, because the Vista Power Management discussion wasn’t that engaging.  They’ve come up with a new event model for Power Management now so you don’t have to poll for power state, and Vista will have all desktops defaulting to sleep on a timeout, which will force a LOT of application developers to actually do something intelligent.  You also no longer get the chance to prevent sleeping when the user initiates it – it just happens and you have to cope.  As expected though, you can still disable any automatic power events while performing a long task (watching a movie, burning a CD etc.)

Now, for Vista Internals:

  • New boot loader which is platform independant (can run 32 or 64 bit code)
  • As mentioned before, kernel supports hot swapping or adding of CPUs, RAM, etc.  No mention of removing anything though.
  • Memory manager was refined:
    • Deals with kernel memory more effectively.
    • Handles NUMA and large pages.
    • Handles the paging of video/GPU memory.
  • Drivers can now run in user mode, and system can recover from one of these crashing (maybe).
  • Better multimedia support in memory manager, IO manager and process scheduler.
  • Lots of changes for windows services:
    • Services stay in desktop session 0, but user windows move to session 1 so can’t message each other.
    • Services can delay their start to help bring the system up faster.
    • Serivces can declare their privilege sets and have their process tokens stripped of unneeded privileges on startup.
    • You can get notifications about local or remote service state changes.
    • Can programmatically recycle a service process without upsetting the SCM too much (if you do it right).
  • Registry is now transactional (always was atomic though, just not across calls)
  • Registry and File System can be virtualized (access denied can point the user somewhere else under the hood, to allow low privilege modes).
  • Registry filter drivers can now be written, just like File System Filter Drivers.
  • WoW64 (the 32 bit emulation layer):
    • Supports VM spaces of up to a full 4G for user apps.
    • 16 bit support has gone from 64 bit Windows (hooray!!!)
    • 32 bit and 64 bit apps can talk to each other via COM (across different processes obviously)

And the real killer:

  • All kernel mode code (and some critical user mode code) must be signed by Microsoft in Windows Vista 64 bit (and possibly 32 bit in the future).
  • The only proposed way around this is by attaching an external kernel debugger.

Now, while this is being touted as a fantastic way to stop kernel rootkits and other nastiness, it really has a whole raft of other effects which are going to make life annoying, or just plain impossible for power users or administrators.  For example, consider the following:

  • None of the utilities at sysinternals.com will continue to work unless every revision of the driver code is digitally signed by Microsoft.  That severely limits the creativity of people like Russinovich and Cogswell.
  • Developers won’t be able to mess around with driver code for experimenting..
  • Universities will have to get special builds of Windows to allow their students to write driver code (which is part of many courses these days).
  • Driver fixes will be delayed by having to pass through Microsoft’s WHQL whenever a video card company wants to release something new.
  • We can’t test any of our drivers on Vista without attaching a debugger – hardly a production test..

And that’s just the tip of the iceberg.  The annoying fact is, rootkits can still get in.  Sure, it raises the bar for them but the simple fact is, unless Microsoft can get hooks into the hardware itself and prevent it from loading a modified kernel image, malware can simply turn off the checking in the kernel.  At some point a decision is made to load or not load a driver.  Change that flag and you own the computer.  People without computer knowledge will “trust” in Microsoft’s wonderful new security and they’re STILL vulnerable.

I hate stupidity like this.  I actually don’t mind it being on, but for goodness sake, give me a method of self-signing stuff, allowing self-signing to happen, or some other switch to opt-out of this stupid restriction.  Personally I think it’s got more to do with Digital Rights “Management” than it does preventing rootkits though.  One more step for Microsoft refusing to understand core security principles – if you don’t control the entire boot sequence from the first instruction executed by the CPU then you don’t control anything.  End of story.  Thanks for playing.

I was really excited about Vista too, until I heard this..

(sigh)

Leave a Comment