New types of Collections Guess what theres some new collection types we can look forward to in Win8, confusing thing is that one of them is called an IVector, and it's got nothing to do with 3D.. I'm still trying to work out what the hell they mean, even how they're used doesn't reveal much about there purpose. Can anyone infer what these new types do?! IVector IVectorView IMap IObservableMap IItterator IItterable IObservableItterator etc... High res image : http ://xs.to/media/6951 Update: seems like these types are known to the native (C/C++) devs. These are new ideas to us C# devs. Very interesting and i definetely will ask why these are in the foundation libs at build.
A little more about Vector, Map and Iterator: These are all concepts/classes from the C++ STL (Standard Template Library). Vector in C++ is like an Array in C#. Map in C++ is like Hashtable or Dictionary in C#. Vic
I was looking inside Windows.UI.dll and found reference to DPAPI.dll, which contains CryptProtectDataNoUI function (msdn haven't description for that). Is it usefull in any matter? I'm a noob in debugging/programming, so can say a stupid things sometimes
I don't think you need to wait until then. These types are there because WinRT is a native framework, it's not built in .NET so it cannot use .NET types. It's like IEnum used by COM but much nicer due to the use of generics. Small correction, IVector<T> is like IList<T>, not like an array.
it makes sense that they are Native collection types for use in a Native Frameowork, but when you start using these WinMD libraries in your managed app then confusion hits you. ObservableCollection, List im sure will always be available to us BUT this IVector, IMap etc. they just look and sound more performant than the .NET collections, I need to research more into these types to work out there advantages/disadvantages over the .Net collections. Question is even thou these WinMD libs can be referenced in your managed project, will we ?! Does MS expect us to use these WinMD api's in our managed Jupiter Immersive apps? Or are these really just targeted to WinC++ and JS?! Maybe all this WinMD api's will be exposed in a yet to be announced API that is more friendly to current .NET devs?! Thou I personally highly doubt that there will be a .NET friendlier api, that these WinWD libs will probably be what we reference in our Managed Jupiter Immersive apps.
the advantages of Windows.Foundation.Collections is dead simple: they are 'WinRT friendly', it means they can be exposed or consumed by WinRT components. since those builtin WinRT libraries are all native code, they can not instantiate nor access a managed collection type directly, they have to use their own type/interface if they want to return or receive a collection data structure right ? did you noticed that they are just interfaces ? it means you are not supposed to use these types for your own code. and you can expose a managed list type as IVector with some helper extension method in System.Runtime.WindowsRuntime. what's more, the name of these types are chosed to avoid name collisions with managed collections in BCL, I'll call that '.NET friendly'. you'll want to reference those WinMD files if you NEED them. and since Jupiter itself is one of these native code WinRT library exposed by WinMD, so yes you do NEED them in your managed Jupiter apps, immersive or not.
can you guys show any more screen shots of the windows.ui.directui namespace pretty please more the happier, thanx
Since the Windows.Foundation.Collections namespace only contatins interfaces (no implementations) perhaps they are only for interop with unmanaged code? The STL classes could implement these interfaces so they could be used from managed code. Have you guys seen any implementations of these interfaces elsewhere in the framework? it looks more and more like pinvoke is finally beeing laid to rest in favor of calls though WinRT *fingers crossed*
Well, there are some .NET implementations of these interfaces somewhere in System.Runtime.WindowsRuntime. Of course, they're just intended to wrap WinRT collection interfaces in BCL collection interfaces (and the other way around) to simplify interop. People seem to look into these collections more than it is needed, it's just interop stuff.
7955 'Administrator' password anyone?? I've just been fiddling around with the 7955 M3 leak and noticed the 'Administrator' account is password protected! To be expected I suppose if the image was originally made from a VHD or something similar ... I wonder if any kind soul here-abouts might know what the pass is .. or indeed how to change it??
Yeah I know it's interop stuff, and it makes sense that these API's are directed more for the native devs. All I'm sugesting is that these libraries if used in C# managed code is a different experience to what we're currently use to in the WPF/Silverlight world unless ofcourse the devdiv team extend our collections to use these new primitives. For instance anywhere that takes a collection in the WinMD libraries, like a Listbox/ItemsControl etc will take the IObservableVector<IPropertyValue> as its Items. And these controls are concrete implementations not interfaces. The class hierarchy & the associated inheritence tree for controls in WinMD is looking very different fundamentally between WinMD and WPF/SL which isn't a bad thing as WinDiv have definetely removed alot of complexity .. I'm going to continue to analyze the WinMD api's and classes with regards to how much they differ to WPF/SL. It may not mean much to native devs BUT for us WPF/SL peeps that may be using this for building Jupiter apps along side WPF/SL/WP7 apps makes a world of difference! And so as not to polute this thread I'll create a new one devoted to Findings in Win8 M3 Beta of relevance to Managed .net & WPF/SL developers. ok all future .NET/WPF/SL related comments by me are in here (remove the space after "http", im under 20 posts) : http ://forums.mydigitallife.net/threads/27437-Win8-M3-(7955)-findings-relevant-to-Managed-.net-amp-WPF-SL-developers
He he, it's about time. There have been complaints that the BCL implementation does not achive very good compression factors. This should resolve the problem.
Good, there are some definite improvements here over the .NET collection interfaces. Some are redundant with .NET types, e.g. IIterable<T>/IIterator<T> vs. IEnumerable<T>/IEnumerator<T>. Others are similar, but without some cruft. IMap<K,V> is analogous to IDictionary<K,V>, as IVector<T> is to IList<T>. But we don't really have anything equivalent to IVectorView<T>. You can think of this as an IEnumerable<T> with support for random access (retrieving an element by index/ordinal). It has the read-only components of IVector<T>, but no write support. The closest thing we have is ReadOnlyCollection<T>, which is a concrete type rather than an interface, and the purpose isn't as open-ended. IVectorView<T> could represent a subsequence, e.g. a range of elements within a larger IVector<T>. ReadOnlyCollection<T> is really only intended as a read-only wrapper around an existing IList<T>. The "Observable" collection variations simply add change notification. There really isn't much "new" stuff here for .NET developers--it's mostly differences in naming/semantics. The cool stuff is the addition of the read-only "view" interfaces.
Found something, if you open cmd and enable Administrator acc, it has a pw on it. Go into an alt acc, remove password, and you're in. Probably to keep people out?
Hrm, people are reading this thread and are drawing dubious conclusions. Maybe I should try to correct some of them: DirectUI is not a superset of WPF, it's really a subset, quite a small one. WPF is not going away, it even has improvements. For example collection change notifications can be raised from a background thread now. WinRT doesn't have anything to do with .NET, the WinMD assmeblies do not contain any code, they only contain metadata. You don't need .NET to run WinRT applications but you can make .NET applications that interop with WinRT. There's no relation between WinRT collections and STL, appart from name similarity (map, vector etc.). The API is quite different. As is now, slr100.dll has no part in this. It doesn't replace CLR, nor it appears to have any sort of connection with WinRT. In theory the slr compiler (which we haven't seen) could generate code to interop with WinRT but there's no trace of such a thing in the leaked builds.
Hmm, none of the appx applications seem to start properly. Even an C# exe compiled with /target:appcontainerexe doesn't start. It seems to me that something is missing or not running and I don't think it's twinui. In particular AppXDeploymentServer.dll should probably run in a service but I haven't seen any such service. /target:appcontainerexe sets a flag in the PE header, a new flag. That means that the kernel probably checks this flag and for some reason refuses to start the process. The kernel exports a function named RtlGetAppContainerNamedObjectPath so even the kernel knows about app containers.