Quantcast
Channel: New Fun Blog - Scott Bilas » windows8
Viewing all articles
Browse latest Browse all 2

Build Conference 2011: Wednesday

$
0
0

[This is my notes from Wednesday. See Tuesday's Notes.]

Important: some of these are out of date and superceded by later notes I took after talking with Microsofties. I’ve tried to mark them as such where I remember with a [*].

Visual Studio 11

No release date of course, same as Win8. Feels like “definitely not this year”. Did you all download the preview yet? It’s available for everybody. Win8 and the dev tools (VS11, Blend 5, etc.) are online.

Anyway, what’s new…

  • After 10 years they finally updated the image editor. Now it supports transparency and DDS’s.
  • VS has an FBX viewer w/ property editor. Right in the IDE you can open a 3D model, select meshes, set properties like color and transform.
  • They put a lot of work into a new thing called DGSL that is your typical shader graph.
    • Preview rendering at different stages of the pipeline, things like pins and wires connecting them to output a final render.
    • Good for the XNA crowd I guess? Seems like a distraction for the VS team.
  • Pix is integrated into VS.
    • You can debug a 3D app, take a frame grab, then in VS walk the drawprim calls backwards from a pixel. Get call stack per graphic event and all that.
    • Being integrated into VS means that this this will have a nice, consistent UI, yay.
  • There is this great DOM Explorer (JS/HTML only)
    • Reminds me a lot of the tools built into Firebug or Chrome’s dev mode, except it runs through VS.
    • Even on a server web app you can hover over a rendered web page and it will point you at the aspx line that generated it.
  • Productivity Power Tools are part of VS now. You probably already know this. Well, perhaps they’ll fix some of its many bugs if it’s an in-box addon.
  • Nice random improvements to the VS UI like categories for Intellisense (“commonly used by you” vs. “all”) and minor new features in snippets.
    • Maybe now R# will pick up this much-needed feature that VisualAssist has had for a while..
  • Await/async is deeply supported in the debugger.
    • Step through async code (like WinRT’s ShowDialogAsync) procedurally without needing to get confused by all the underlying thread context switches. I like.
  • Tons of new unit testing support. Now is the time when I remind myself to look into unit testing again..
  • The Kernel Debugger can now run from inside of VS. Sure to come in handy next time you’re developing a device driver (har).
  • Static code analysis is now a plug-in architecture.
    • He talked about, for example, the kernel mode driver validation static analysis tools that just show up as part of the compile.
    • Works on C++ or C# or whatever.
    • I expect we’ll see the same type of integration for FxCop/StyleCop
  • Javascript in VS now has a REPL command pane, just like the browsers have had.
  • Full support for ECMAScript 5. I’m only familiar with 4, which added (I think) static typing. Well, fake static typing. Anyway, now we have 5! That’s 1.0 better than 4!
  • No word of improving E&C like supporting altering a function containing a lambda..I’m going to ask them about this. [* answer: no]
  • Ooh a nice new color picker for CSS. Probably for Xaml as well.
  • VS11 projects are going to be the same format as VS2010.
    • No upgrade required, forward/backward compatible. That will make testing the beta on our stuff easier.

WinRT (Windows Runtime – the Metro API)

  • “Language Projection” is what they’re calling the layer between the language and the kernel services. It maps a language onto the underlying API’s, reflection and type system (the metadata).
    • They are dropping the least-common-denomenator “CLI” system and instead are mapping things as close as possible to the language you’re using.
    • Example: on an array returned by the core, C# uses “.Add()” to add an item, whereas Javascript uses “.append()”. I like this. Least common denominator probably wasn’t working out for them anyway because nobody really cared about making things VB-compatible when writing libraries in C#.
    • WinRT types are automatically adapted to the language. For example getting an array back from WinRT will come back to C# as an IList<T>, done through adaptors but not by making a new list (no copying). In C++ they have adaptors to get it into STL iterator form, etc.
  • Async is embedded very deeply.
    • Martyn said that in .NET when they provided a sync and an async version of the same function, people would just use the sync version and then get crap behavior and experience.
    • New stuff heavily encourages use of async, though not sure if that means the sync functions are unavailable [* they are].
  • New Windows Metadata format that is used sort of like the Reference Assemblies, sounds like, except this metadata IS the OS. Not libraries on top, but the actual Windows API’s.
    • Format is based on .NET type system but extended to meet the new needs.
    • Metadata catalog is extensible (again, Metro apps only, for custom WinRT objects) but only privately. No publishing of shared assemblies. Not that they are using the word “assembly” any more…
    • Sharing across apps is done exclusively through “contracts”, which are part of the OS. If you want to communicate across apps it must be done through a preexisting contract, looks like.
  • YAY! A new string type!!! This one is called HSTRING and is probably the 15th string type I’ll have used.
    • It gets mapped onto whatever the local language thinks of as a string but sounds just like a .NET string – immutable, and so does not copied.
  • WinRT is heavily interface driven, as is now common in the rest of the programming world
    • IUnknown is now IInspectable. They said IUnknown confused people or something. Anyway, IInspectable -> ISpecificInterface -> ConcreteClass (runtime, private).
    • C++ binds statically as usual.
    • C#/VB binding is mostly static but also uses some runtime metadata (very cheap though)
    • JS/HTML binding is dynamic dispatch at runtime, works completely through metadata as you expect a dynamic language to operate
  • Some MC++ changes, like “gcnew” is now “ref new”. [* turns out this is not true. See later notes.]

Other

  • Lots and lots of stuff about Azure, which is pretty neat but I’ve heard is very expensive for large-scale use.
  • Pithy statement I just made up: “swipe is the new right click”.
  • TFS marches forward.
    • The new stuff looks really cool, and I’d consider using their hosted TFS if I had a small studio. They even support scrum directly.

Expo Floor Queries

WPF

  • What’s New in WPF Version 4.5 Developer Preview: http://msdn.microsoft.com/library/bb613588(v=VS.110).aspx
  • WinRT is definitely Metro only.
    • We cannot embed Metro in WPF, and vice versa (well we can, but they said it would be awful, dirty, and please run away).
    • Metro really is a completely independent sandbox that has little to do with Windows.
    • [* Some of the above is a lie, as I found out on Friday. WinRT is definitely useable outside of Metro. See later notes I’ll post.]
  • Very little work has been done in WPF. It still exists! Visual Studio and the Expression suite are all WPF apps and will remain that way. But for 4.5 they focused exclusively on perf and stability. I suppose that’s ok.
  • I lost track of how many times I’d ask someone about desktop apps (WPF) and would get asked why we didn’t just “rewrite it all” for Metro. Ah, Microsoft, never change!

Blend/VS

  • The reason Silverlight has data-binding breakpoints is because the Silverlight team put the hooks in there independently and VS was able to use them.
    • Until someone does that for non-SL Xaml (whether Metro or WPF) we will not have this functionality in VS.
  • The reason JS/HTML has such freaking awesome debugging support (like interactive mode) is completely provided by the hooks already developed independently in IE over many years.
    • Again, work that Blend/VS did not have to do.
    • So they’re waiting for debug hooks in Xaml frameworks, which may never appear. Complicated problem to solve and limited resources/initiative to do it.
  • We should use DynamicResource and not StaticResource as a general rule.
  • They know that debugging resources sucks.
    • They want to work on the problem. They aren’t working on the problem. They have no plans to do so.
    • They recommended using DynamicResource (again) and binary-search style commenting out stuff to narrow down problems. Yeah, so, nothing new here.

Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles



Latest Images