The Office Open XML Formats use the same ZIP/XML conventions that Metro uses. So, you can use
System.IO.Packaging in the
WinFX SDK to open and manipulate the format. In fact, we'll be showing this at our TechEd session next week.
So a CompoundFileContainer generates basically a ZIP file?
--edit: Nevermind, in the Beta1 RC it has been renamed to ZipPackage. Question answered.
This does not seem to be the case. Doing a quicksearch with Reflector, I find (almost) no P/Invoke in it. And not a single ImportDLL user32 ... If you watched the video Chris made the connection with D3D and user32 BELOW milcore.dll so it must happen
somewhere there. Somewhere lower level where life is more unmanaged You must not forget doing P/Invoke from managed code has some performance issues.
Well, if it's not PresentationCore, then it must be milcore.dll. Interaction between User32 and Direct3D doesn't make sense to me, but I'm open to being corrected.
with DWM and GDI you mean what was called "Avalon Desktop Composition" and "Classic Window Manager" on
this slide from a WinHEC2005 presentation? If so, would that mean that the DWM is not used on the tiers "To Go" and "Classic" ? Will the DWM be somhow magically turned off when its in the mode that you described as "GDI" ?
DWM is "Desktop Window Manager", which would be desktop composition. It's basically just another instance of the Universal Compositing Engine (it's used to compose controls into a window, and windows into a desktop). The DWM needs LDDM to operate, for the stability
thanks to new features in there, like hardware reset of the graphics card. If you don't have LDDM drivers, it'll fall back to the regular window manager using GDI for drawing. The tier "To Go" won't use DWM, because it doesn't require LDDM. Classic is just
the Windows 2000/XP user interface.
Wow that's really great news ... So in case there is some old TNT2 (or even older) on the machine most of the rendering is done by GDI and the CPU (and therefore Avalon will run) ?
Well, it'll use the GPU as much as possible. However GDI will not be invoked in rendering the window backbuffer, Avalon will do this on its own in software mode if necessary. GDI will be used to slap the backbuffer onto screen (unless they do indeed invoke
D3D at some point, just like games in window-mode, which doesn't make too much sense since it's a simple surface going to screen).
1) We will have to make a differnciatioation between WGF 1.0 (wich is wich is an enhanced version of Direct3D9 Also known as “DX9.L”) and WGF 2.0 wich totally replaces direct3d.
I'd guess that Avalon will use the best one available, so that'll put them on the same line. Why use Direct3D if WGF is there, which does the same job but better.
2) Chris mentioned in his video that user32 talks directly to Direct3d. See his blockdiagram, so we can take that as granted .... Also PresentationCore.dll is a pure managed assembly where user32.dll is pure ("legacy") unmanaged ....
Direct3D is a dumb polygon painter, if you want. User32 cares about window placement and user input, it has to communicate that to the component who manages the Window element and does event routing of input, that'd be PresentationCore from what I remember.
And there are thing's like PInvoke and all that, that allow a managed component to talk to unmanaged code. I bet if you run a hex editor or ILDasm over PresentationCore, you'll find tons of MIL and User32 references.
3) we will also have to make a distinction between the 4 tiers of Aero. The first two ("Classic","To Go") are for older Hardware that do not support the LDDM and the other two ("Aero Express","Aero Glass") run only on Hardware with LDDM.
There are only two modes. DWM or GDI. The difference between Classic, To Go, Aero Express and Aero Glass is the amount of eye candy and acceleration factor.
4) I doubt that GDI is now some layer below Direct3D. When you redner soemthing on older XPDDM hardware it wont necessearily go through GDI. I always thought that Avalon will require d3d9 (at least) in any case.
Rendering on XPDDM, GDI has to be involved in some way, because GDI will be the main renderer, if only for the window frames. Remember that Avalon renders into a backbuffer, which needs to be copied to screen. And Avalon needs D3D9 only for full acceleration,
but works fine on older hardware with limited acceleration. My machine ran Avalon on a DX8.1 card just fine.
5) Direct3D -> DWM -> Direct3D doesn't really make sense to me ...
Direct3D acceleration of the window composition, all into a backbuffer. The DWM takes the backbuffer and uses it as texture for desktop composition. Makes sense.
As far as I know, WGF is going to be the successor to Direct3D, so Avalon will likely make use of it, so you can put Direct3D and WGF together. Otherwise it should look more like this, from what I remember:
I think the ideal way of implementing a managed OS would be to offer core services in native code form, that is a global memory manager and a global CLR and GC, and then try to implement as much in managed code (including drivers). Processes would be represented