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!
Loading user information from Channel 9
Something went wrong getting user information from Channel 9
Loading user information from MSDN
Something went wrong getting user information from MSDN
Loading Visual Studio Achievements
Something went wrong getting the Visual Studio Achievements
@VironPapadopoulos: No, Anders is using a Samsung Series 7 slate like those handed out at //BUILD last September or available from MicrosoftStore.com:
@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
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.
Isn't it amazing how how much easier it is to comprehend a complex subjecct when presented by someone with so much enthusiasm?
Great work Anders & Team. Can't wait to see what you attack next
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.
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:
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.
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.