Search results matching tag 'Longhorn'

Where is the transparency, and no, Avalon this doesn't concern you

rdawson — Tue, 17 May 2005 10:28:00 GMT

Interesting discussion going on in the comments, although Brian Shapiro ends with: "i was also hoping for discussion in the posts i made but nobody has really touched them." Alas, I don't have an answer. I was also hoping for more of a discussion by people in positions to make things happen, but that doesn't seem to be happening. There are people obviously interested in the UI of Longhorn, and some who have done previous work on similar concepts, but this doesn't seem to be enough to draw attention. On a similar note, there is a guy in the Channel 9 forums posting 'posters' to get Microsoft employees more active.

More transparency would help by leaps and bounds. Hiding UI concepts is a joke--I'll tell you how much of a joke it is: there is a creative director who does not work at Microsoft anymore, but when he did, he worked on Aero for 5 years. 5 years. I'll tell you, if they would have been open about designs, they would probably have a *revolutionary* UI when longhorn ships. Sure, maybe Apple would have snatched some bits and pieces. But, that is the beauty about transparency. Since Apple would go ahead on those pieces, it would allow Microsoft and others to design the next new paradigm on top of those said pieces. At least this is what I think. Maybe I am totally wrong. Let me know.

And, in 5 years, do you know how many concept designs I could come up with, not to mention a team of designers...But, even bigger, a community of people...

Many say that retraining is the biggest obstacle in keeping Microsoft from implementing a totally unique and futuristic UI. I think that is a load of crap. Who ever said you would have to scrap the Windows 2000 look? No one. You could have the futuristic one as an option you explicitly choose. Sure, Apple has a niche market, but I don't see why this wouldn't work.

Multiple UXs are not only the future, they are the only way to go. The bridge between an advaced power user and my grandma is way too big for a one-size-fits-all. I will embrace this trend, have you? Seriously...

I'm just an idiot throwing around ideas here, and I don't know anything--but, think about the people who do know things, lots of them. I'm sure they have lots of advice for making a great product. Ask some people over at frog design or IDEO--they know how to build great products.

Let's get some real thought going. Start in the comments, or on your own blogs, or on the Channel9 forums, or Neowin...I don't care, let's just start it. The waiting has gone on long enough.

P.S. Have you seen the news that IE is going to have tabs. Did I miss the keynote speech by BillG on this news? Anyway, it is kind of corny to hype this feature--since I have already explored ideas for better tab implementations in response to their nonsense. I relate this to Rory's new Notepad. I don't understand why IE gets the hype they do. Yes, in linking to them and talking about this, I am giving them hype, too.

Better Service

rdawson — Wed, 11 May 2005 19:23:00 GMT

Why are there 10 million instant messaging applications? MSN, Yahoo, AIM, Skype...

Let me tell you, an instant message at its most basic form is a commodity. Trust me. There are special services layered on top, but at the base (the text) it's a commodity. So, if all of these operating system vendors are in the business of APIs, which they are, because the operating system is a commodity, why don't they support entities like instant messages. Sending, receiving, presence, multi-casting, etc. That is their business, right?

On top of that, build in extensibility, so that IM clients can broadcast their capabilities on top of the commodity type. MSN can add everything they want right on type of the base. They can add their blogging and avatar features. Anything, really.

Why stop there? How about adding the same type of thing for mail messages, appointments, tasks, and text documents. These are almost like APIs. There has to be some way to standardize formats to a reasonable degree. No one is saying throwing your competitive edge out the window. Just make everything a lot nicer to deal with, for everyone. Because, to be honest, whether you do this or not, Word Perfect and AIM are still going to ship. Just what are you really accomplishing by the lock-out. You build it, they build it, it's all the same.

So, if I have to build instant messaging into my application, I *am* going to do it. Just because MSN is out there doesn't stop me. Let's just get a little bit smarter about it and put these things into the operating system. Now, you may be thinking, there are APIs. But, it's not enought to provide the ability, without the service. I shouldn't have to re-subscribe to every buddy in every program or IM client, right. By all means, tell me if I am wrong at any point.

Since, Longhorn hasn't shipped, let's start there...Sound like a plan?

For the sake of innovation...Please...

The Smallest MSBuild Project

rdawson — Sat, 09 Oct 2004 06:32:00 GMT

The smallest MSBuild project, considering of course, the included assembly could be excluded:

</Target>

</Project>

There are variations of a simple project (.proj) definition floating around, although I believe simplicity should be maintained at all costs. For example, I don’t like the ability to be able to create the same thing two different ways. I would say it follows the law of squares, in that it is x^2 times harder to learn something in programming when variations exist that do the exact same thing.

Please Reconsider

rdawson — Tue, 31 Aug 2004 18:52:00 GMT

I am sorry for the post to follow because I try to keep a very high signal to noise ratio on this blog, although I thought that some words were needed, that I had not yet seen in the blogosphere.

Why must we taint Avalon by back porting it to XP? Obviously, the technical problems are going to be far and wide, not to mention that it is going to cut functionality across the board. Why must we do it? There already exists a perfectly viable (and probably equivalent) match to Avalon on XP today – Xamlon. So, my solution, instead of ruining Avalon, how about those developers interested use Xamlon and then we wait for a clean Avalon solution in Longhorn.

Secondly, how in the hell is someone going to get a 100-200MB distributable onto a client PC. Everyone knows that the .NET 21MB distributable is pushing it as is.

I can’t speak for anyone else, and I doubt you will see any criticism from within Microsoft because it is a career limiting move, but I will say that I am very disappointed.

WinFS is the backbone to the next generation of computing. Relationships are *key*. I just received an email today from a VP at one of the largest design firms and he was telling me how all his customers were really interested in WinFS, more than any other pillar. Let me say that again – A design firm’s customers preferred the advances in WinFS to Avalon. That speaks volume.

Not to mention, WinFS was also my favorite slice of the pie.

I have not done enough research in the lengthening upgrade cycle for PCs, but I imagine that people are not at all ready to upgrade. I would give until 2007, which should give more than enough time to get all of the pillars ready.

In my opinion, I think this is an “all of nothing thing.” I hear over and over that this is what the customer wants. But, according to my experience, this is the exact opposite. The customer wants a way to get rid of pop ups/spyware, share documents over the web, and download music. Walk into most corporations and you will find that they run the Win95 graphics scheme on XP. So, don’t tell me it is about Avalon. Most web sites and server farms roll their own pipelines for the utmost speed (The ones who do use Web services are on step 1 of the 5 step WSE ladder). So, don’t tell me about Indigo. And, the fundamentals don’t mean as much if they are not coupled with everything else (Most of the fundamentals are stand alone libraries that can be downloaded today, either open source or other).

Create New Folder in Longhorn 4074

akinney — Mon, 02 Aug 2004 15:11:00 GMT

This is a very simple solution to the odd bug where "New Folder" is not available in the context menu of Explorer.

Click on Start, then Run.
Type regedit, click on OK.
Go to HKEY_CLASSES_ROOT/.Folder (not Folder but .Folder with a dot) Double-click on (Default)
Type "Folder" (without the quotes) in the value data zone, then click on OK.
Close regedit.

[via PROneTworks]

Read or write comments on this entry

Missing Indigo library in PDC Longhorn

akinney — Fri, 30 Apr 2004 12:03:00 GMT

Currently, if you attempt to use Indigo, you may quickly run into an error, warning that a library is missing, usually once you get into the System.Net.PeerToPeer namespace.

Well, yesterday in a “Developing Mobile Applications in Longhorn” webcast, Derek Ferguson mentioned the cause of the error. In the PDC Build of Longhorn, there is a Windows Component called Peer to Peer that is not installed by default.

I did install it, but I have not attempted to use it yet. I brought this up, because I have been asked about this very error, and was happy to share the answer.

Derek Ferguson is puttting on another webcast called Architecting Mobile Soultions in Longhorn on May 5th. The unfortunate problem with webcasts is once they're over, they're gone; so be sure not to miss this one if you are interested in seeing the new support for mobile devices in Longhorn.

System.Help

rdawson — Fri, 02 Apr 2004 03:51:00 GMT

System.Help

So, they have been hard at work creating a task-oriented help system that is extensible and easy to understand. I guess it now time that we stop using our own system and partake in the fruits provided.

Some clarifications from above should probably be in order:

Task-oriented – The new help system has a new intermediate data format that maintains the intent of the help file. By placing the content within task-oriented XML tags the Help runtime can determine the display using its own XSLT. So, let me say that again. The help file writer does not concern him/herself with the presentation. Among the many benefits of a system like this are that it is easy to author and it maintains a consistent look across programs.

It is extensible. Each help file is contained within an XML file. That means that a typical project would contain n XML files, where n represents the number of help topics provided by the author. Also, some book-keeping files: a .helpmd (which is a list of all the topics, .taskdef (a CLR mapping file), .taskimp (extension to .taskdef), and a .packinglist (which is analogous to the MSBUILD file, it contains all the files which are going to be compiled). These are all compiled into a .help file. Lastly, the help topics use XLink to link between each other. XLink is not a totally revolutionary idea, but I would say this is the first application in which I have seen it used –which is revolutionary.

It is easy. Take it at face value that I was able to get a help system up and running in 20 minutes.

Lastly, as implied by the title of this article, the help system is supported by a programmatic interface in .NET. Among other things, this allows me to control the help pane by switching between different help topics with different UI interactions.

In case you are wondering what the help pane looks like, here goes:

For the image above, here is the content for the topic:

<?xml version="1.0" encoding="UTF-8"?>

<conceptual xmlns="http://schemas.microsoft.com/maml/2003/5" xmlns:doc="http://schemas.microsoft.com/maml/internal" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.microsoft.com/maml/2003/5

C:\Program Files\Microsoft Longhorn SDK\misc\MAML_Schema\Maml.xsd" xmlns:xlink="http://www.w3.org/1999/xlink">

<title> Longhorn Help Demo: Topic 1</title>

<para> This is the introductory topic of the "Longhorn" Help authoring demo.</para>

</content>

<title>Link demonstration</title>

<para>Here is a link to <link xlink:href="help://microsoft.windows/default.aspx?language=en-us&version=6.0.0.1&bundleid=LonghornHelpDemo&topic=/Topic2.xml">Topic 2</link>.</para>

</content>

</section>

</sections>

</conceptual>

I would like to note that the above code is straight from an easy to follow sample on getting the help system running. The overview can be found here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/htmlhelp/html/hwmscintroducingwindowslonghornhelp.asp, while the actual download is here: http://download.microsoft.com/download/6/c/5/6c58007f-d204-4281-a14d-8c53d9bbc198/Longhorn_Help_Authoring_Walkthrough.EXE. The download contains the helpcompiler.exe and the sample: Longhorn_Help_Authoring_PDC.mht

When you get the help file built and installed, you can begin to reference it in code:

string uri = @"help://microsoft.windows/default.aspx?language=en-us&version=6.0.0.1&bundleid=LonghornHelpDemo&topic=/Topic1.xml";

System.Help.Pane pane = new System.Help.Pane();

pane.DisplayTopicFromUri(uri);

Note that there are 3 assemblies to choose from; for this specific example, you are going to want the System.Help.Pane assembly. This code will start up the help pane and give you the image at the top of this article.

ObjectSpaces

rdawson — Tue, 23 Mar 2004 05:33:00 GMT

ObjectSpaces

The ObjectSpace technology, coupled with basic XML querying will eradicate current methods for database manipulation as we know them. At least, that is how I feel. In both statements, the back-end database remains essentially the same. It is a column and row relational storage device. But, in the former statement, you talk to the back-end through CLR objects, and the latter statement, you talk to the back-end through XML-ish procedures, including XQuery (In short, you only communicate in XML standards).

So, the interesting thing is that nothing has really changed except productivity and portability. The reason that I think the ObjectSpace will take hold is because no one works with the SqlDataReader for fun. They work with it because they must read data, when the fact stands that the query is the only valuable piece of data that needs to be passed to the server. Secondly, object orientation was decided a good thing for a good reason. Now, my original premise will be broken in the fact that people will use a DataSet, but the abstraction for persistence will be the same as with ObjectSpaces. The only reason that I think people will still use the DataSet is because it is easier for the short term. We have a whole infrastructure built around tables –DataGrid for one. I think the DataGrid is an uninteresting control (Although, not the concept of a table). If anyone has tried to customize the DataGrid, you know that you have run into problems, or it is the fact that getting data in and out of the DataGrid is tedious. Why is this? The answer is because we don’t work in tables, we work in objects. I would much rather have a DataGrid built on objects than rows and columns. So, as you will see, the infrastructure was built around tables for simplicity, and not for API penetrability.

When working with any of the new technologies in v2.0, you must notice that there are many facilities that translate relational content into objectified content, and this applies to things other than ObjectSpaces. In order for you to understand ObjectSpaces, it should be worthwhile to have a look at how these technologies are glued togther. There are three pieces to the puzzle: A Relational part, an Object part, and a part that ties the object and the relational parts together.

Relational Schema

The relational schema is the cardboard on the database side. In essence, its purpose is to enumerate the columns that we want to use. In this sense, we now have a vocabulary to talk about when we want to use the database. We have therefore limited the database to only the fields that we care about, and have abstracted a layer over the database.

What does this file look like? You can obviously imagine that it is an XML file, but here is a sample:

<rsd:Database Name="Northwind" Owner="sa" xmlns:rsd="http://schemas.microsoft.com/data/2002/09/28/rsd">

<r:Schema Name="dbo" xmlns:r="http://schemas.microsoft.com/data/2002/09/28/rsd">

<rsd:Tables>

<rsd:Table Name="Customers">

<rsd:Columns>

<rsd:Column Name="CustomerID" SqlType="nchar" Precision="5" />

<rsd:Column Name="CompanyName" SqlType="nvarchar" Precision="40" />

<rsd:Column AllowDbNull="true" Name="ContactName" SqlType="nvarchar" Precision="30" />

</rsd:Columns>

<rsd:Constraints>

<rsd:PrimaryKey Name="PK_Customers">

<rsd:ColumnRef Name="CustomerID" />

</rsd:PrimaryKey>

</rsd:Constraints>

</rsd:Table>

</rsd:Tables>

</r:Schema>

</rsd:Database>

I will take the fact that this XML file is self explanatory. If you are familiar with the traditional relational storage system, you will not have any problems; otherwise, I recommend you review some of the essentials.

One thing to note is that this table is provided in the default SQL Server installation as the Northwind database.

Object Schema

The object schema is the cardboard on the object side. It represents the CLR object. I will also take the fact that the representation is self explanatory, and the simple fact is that I cannot point you in the correct direction if you were to inquire more about the structure.

<osd:ExtendedObjectSchema Name="DataTypesOSD" xmlns:osd="http://schemas.microsoft.com/data/2002/09/20/persistenceschema">

<osd:Classes>

<osd:Class Name="Customer">

<osd:Member Name="ID" Key="true" />

<osd:Member Name="Company" />

<osd:Member Name="Name" />

</osd:Class>

</osd:Classes>

</osd:ExtendedObjectSchema>

Along with this, we should also probably define the object in our code file. As the database was provided for us, this requires minimal work.

public class Customer

{

public string ID;

public string Name;

public string Company;

}

Mapping Schema

Obviously, the last piece in the puzzle is the glue for the two cardboard pieces. This is the most interesting part, in my opinion.

<m:MappingSchema xmlns:m="http://schemas.microsoft.com/data/2002/09/28/mapping">

<m:DataSources>

<m:DataSource Name="NorthwindRSD" Type="SQL Server" Direction="Source">

<m:Schema Location="RSD.XML" />

<m:Variable Name="Customers" Select="Customers" />

</m:DataSource>

<m:DataSource Name="DataTypesOSD" Type="Object" Direction="Target">

<m:Schema Location="OSD.XML" />

</m:DataSource>

</m:DataSources>

<m:Mappings>

<m:Map SourceVariable="Customers" TargetSelect="Customer">

<m:FieldMap SourceField="CustomerID" TargetField="ID" />

<m:FieldMap SourceField="CompanyName" TargetField="Company" />

<m:FieldMap SourceField="ContactName" TargetField="Name" />

</m:Map>

</m:Mappings>

</m:MappingSchema>

In the DataSources section, we square away the details of the stores we will be referencing as the source and destination (target). As to how the name for our relational schema became NorthwindRSD, I have no idea; my only assumption is that you must append RSD on the end of the table name. As for DataTypesOSD, we clearly defined that as the name of our object schema. Considering that I have named the relational schema to RSD.XML and the object schema to OSD.XML, all is well.

The mappings section is where things start to get a little more interesting. As you will notice, we can simply state the SourceField and TargetField and the mapping will happen automatically. It is as simple as referencing the names and we get an object to work with.

Using the ObjectSpace

Some notes before we continue.

ObjectSpaces is currently only supported on a SqlConnection, so you must therefore have SQL Server running. This is not to say that ODBC will not be supported before it ships.

It is interesting that persistence of an object to a database is so easy, but we must remember that database updates are still expensive.

You must reference the System.Data.ObjectSpaces and System.Data.SqlXml assemblies and namespaces.

First order of business is to create a connection to the database:

SqlConnection connection = new SqlConnection("Data Source=localhost; Integrated Security=SSPI; Database=northwind");

I will not go over the details of a connection string, but suffice it to say that on a default installation of SQL Server Yukon, this connection string works.

Next, we create the ObjectSpace:

ObjectSpace os = new ObjectSpace(@"..\..\map.xml", connection);

Considering that I named the mapping schema above as map.xml, and it is located in the root of my VS project, all is well. That would also mean that the relational and object schemas were also in the same root folder.

ObjectReader reader = os.GetObjectReader(new ObjectQuery(typeof(Customer), "Company = 'Microsoft'", ""));

foreach (Customer c in reader)

{

// Handle customer

// ...

}

reader.Close();

We get an ObjectReader by calling GetObjectReader on the ObjectQuery. We pass in an ObjectQuery. The ObjectQuery is composed of the return type as an instance of System.Type, an OPath, and a span. The OPath is the new object language that is also used by WinFS. Details may be found here http://longhorn.msdn.microsoft.com/lhsdk/ndp/daconcreatingobjectqueries.aspx. The span, as far as I know, is a way to specify related tables that are in the OPath. Otherwise, the OPath query will not return the expected results since it will treat the table in the OPath as empty. Otherwise, if specified in the span, it will retrieve that table data, too.
You can iterate through the results with the respectable type, in this case, Customer.
You must close the reader

On the other hand, to create a new object, we would use the following code:

Customer customer = new Customer();

// Modify customer ...

os.StartTracking(customer, InitialState.Inserted);

// Modify customer ...

os.PersistChanges(customer);

In order to set the object up for persistence, we call StartTracking. The first parameter is the object, and the second is the state of the object. There are two choices: Inserted or Unchanged. Inserted means that the object is totally new and will equivocate into an INSERT SQL statement. On the other hand, Unchanged actually means that you can change the object, however, an UPDATE SQL statement will be used at persistence time instead of an INSERT statement. PersistChanges is the actual call to make things happen.

One more thing. Although this may seems obvious, all technologies like this (including XQuery and the like) actually translate their instructions into SQL statements before they are passed to the database provider.

Where Are We?

An ObjectSpace is the facility that allows a programmer to circumvent type mapping from a database to an object. This significantly increases productivity and programmability. There are three schema files required to make this happen: an object schema, a relational schema, and the mapping schema that interoperates the two. The main query mechanism in ObjectSpaces is an OPath statement.

ContactPickerDialog

rdawson — Fri, 12 Mar 2004 04:57:00 GMT

A semi interesting UI control is the ContactPickerDialog:

Longhorn is slated to have many standard UI controls like this that represent social aspects, like Contacts.

Anyway, programming against the ContactPickerDialog is straight forward.

ContactPickerDialog picker = new ContactPickerDialog();

picker.Title = "Invite These People";

picker.DefaultFolder = ContactPickerDialog.PersonalContacts;

picker.Layout = ContactPickerDialogLayout.DisplayPropertiesAtBottom;

picker.OkButtonLabel = "Invite";

picker.MultiSelect = true;

ContactPropertyRequest contact = new ContactPropertyRequest(ContactPropertyType.Contact);

picker.PropertyRequests.Add(contact);

ContactPropertyRequest email = new ContactPropertyRequest(ContactPropertyType.EmailAddress);

picker.PropertyRequests.Add(email);

if (picker.ShowDialog(this) == DialogResult.OK)

{

foreach (ContactSelection item in picker.SelectedContacts)

{

// ...

}

There are a couple of things to note:

You can customize the Contacts that are shown by default (PersonalContacts, CorporateDirectory) and some of the small things like the Title.
You can define the columns, per se, as in the ContactPropertyRequest objects. This will also add a button to the bottom in case you only want to add that specific property, such as EmailAddress. On the other hand, ContactPropertyType.Contact will give all of the contact details (not that they are all shown as columns, though).

Browse Together Article

rdawson — Wed, 10 Mar 2004 06:37:00 GMT

This article will focus on the Real Time Communication stack that is present in Longhorn. We will implement an instant messaging application that allows two users to browse the internet and chat together. Further, an introduction to the managed web browser; and, hosting WinForms controls inside Avalon.

The article can be found here