Cook Computing

Omar Shahine emailed me a couple of days ago to say that the Panther release of OS X has QuickTime support for the GSM 6.10 codec. The particular significance of this: it means that you will be able to listen to voicemail messages created on Avaya's Unified Messenger and Modular Messaging unified messaging systems.

Herb Sutter has announced that the C++/CLI candidate base document has been posted and is available for download.

Regarding my recent point about managed arrays. the document says:

An array type is declared using a pseudo-template ref class with the following declaration:

namespace stdcli::language { 
    template<typename T, int rank = 1>
    ref class array : Array {
    };
}

The class is a pseudo-template because aspects of an array type cannot be implemented in a library using the facilities of the language. An array-type is any specialization of the stdcli::language::array pseudotemplate class. For example:

array<int>^ arr1D = gcnew array<int>(10);
array<int, 3>^ arr3D = gcnew array<int, 3>(10, 20, 30);

Larry O'Brien has heard from Brandon Bray that the new VC++ syntax for managed types is definitely not supported in the PDC Whidbey release. So we weren't missing a command line switch.

Virtual PC 2004 now available from MSDN subscriber downloads (via Matt Berther).

Sam points to several blogs from members of the VC++ team (I've added Andy Rich):

• Herb Sutter
• Martyn Lovell
• Brandon Bray
• Jonathan Caves
• Andy Rich

Plenty of C++ info here, particularly about the new C++ features to handle managed types.

I installed the Whidbey preview on a VPC virtual machine at the weekend, hoping to check out the new features, but they don't seem to be implemented in this build. One particular point of interest was if managed arrays were any easier to code because these are one of more ugly parts of current Managed C++.

The project I'm currently working on uses ASP.NET. We don't like having to ship the ASPX pages in source form, not because of IP issues but because of the possibility that customers might tinker with the files and break things unintentionally, leading to support problems. We're planning to add some form of checksum approach which will detect modified pages but when Whidbey arrives we will be able to precompile our ASP.NET application.

MSDN has an article New Code Compilation Features in ASP.NET Whidbey which describes the two types of precompilation that will be available.

In-place precompilation is the simpler of the two. It allows you to manually trigger a batch compile of all the pages in the application instead of waiting until the first user accesses the application. To do this you point your browser at a special precompilation handler in your application, for example: http://localhost/mywebsitename/precompile.axd.

The second mode - precompilation for deployment - enables you to precompile the whole web application off-site and then deploy the compiled application without any source code (including HTML). Precompilation is done using a new command-line utility called aspnet_compiler.exe.

So, maybe there is more to be revealed about the Future of IE. Robert Scoble writes

But, we also are looking for ways to make the Web better too. Now, we haven't talked about what we're doing with the browser. I hear that'll come later. Astute Longhorn testers have already seen that we snuck a pop-up ad blocker into the browser without telling anyone about it. Whoa. That means we're gonna turn off MSN's capabilities of selling popup ads.

Andy Rich has some interesting posts on how Microsoft are integrating Managed C++ extensions into the language. Out go modifiers such as __gc and __value, in come ref and value. There is even a new handle reference operator ^ for ref types, with corresponding gcnew operator, which is used instead of the * reference operator. These and other new keywords will not clash with existing use of the same words as identifiers because their usage will be identified by their context.

The System.MessageBus.Transports page in the Longhorn SDK lists the various transports available in Indigo:

• CrossProcessTransport
• HttpTransport
• InProcessTransport
• ISAPIHttpTransport
• Pop3Transport
• SmtpTransport
• SoapTransport
• TcpTransport

SoapTransport is a virtual transport which heuristically determines the actual transport to be used by attempting connections on the host using various protocols.

CrossProcessTransport is apparently implemented using Named Pipes. My experience with using Named Pipes with Remoting is that it is nowhere near as fast as cross-process COM so maybe CrossProcessTransport implementation will change if it is to become "extremely fast".

Peter Golde raises a question about the future of IE which had already occurred to me: why wasn't there any mention of this at the PDC when a few months ago we were hearing that IE development was effectively frozen and it was hinted that we would find out what was happening at the PDC. I asked a colleague who attended the PDC to look out for this but he said that nothing was mentioned.

If the long-term strategy is to move to a purely managed environment then maybe a managed browser is being developed to take advantage of the improved UI features of Avalon and to provide better security. If this is the case then perhaps development had not yet reached the point where it could be demonstrated. Microsoft do need to implement a substantial end-user application in managed code to convince people that it is effective for this type of application. A managed browser would be sufficient evidence I think.

WebDAV: Next-Generation Collaborative Web Authoring by Lisa Dusseault has been published by Prentice Hall. This should be the book to read on WebDAV - Lisa has been involved with the WebDAV specification process for several years. I've just ordered a copy.

Yosi Taguri has some notes on the Joe Long's PDC session WSV203 "Indigo": Connected Application Technology Roadmap. I was pleased to read the following:

crossprocess communication will be extremly fast in indigo.

because crossprocess remoting calls are slow right now compared to what you can achieve using COM and the project I am working on now makes heavy use of Remoting to connect code running in ASP.NET with the main application server. I guess LRPC/LPC will be used. LRPC (Lightweight Remote Procedure Call) is based the undocumented LPC (Local Procedure Call) protocol is used by COM for cross-process calls. Clemens Vasters describes how it achieves such high performance:

LRPC/LPC maps all marshaled data into a shared memory area and then tunnels the caller's active kernel thread into the callee's process space (!). There it picks up the marshaled data and dispatches it on the called object and takes the same way back. With that, LRPC can indeed complete a cross-process call within a single OS time slice (in practice, not only in theory), if the action is compact and doesn't involve anything that gives up the time slice directly (Overlapped I/O, WaitForSingle/MultipleObject, Sleep).

According to the slides for WSV203 there should be only a small cost for us to migrate to Indigo from Remoting. For example, server object code will look like this:

// using System.Runtime.Remoting;
using System.ServiceModel;

[RemoteObject] 	// new attribute
public class MyService : MarshalByRefObject
{
  public void Foo()
  {
  }
}

Hosting code will look like this (old code commented out):

// using System.Runtime.Remoting;
using System.ServiceModel;

public class Host
{
  public static void Main()
  {
    // RemotingConfiguration.Configure("Server.Config");
    ServiceManager manager = new ServiceManager("http://indigo-svr");
    manager.Services.Add("/MyService", typeof(MyService));

    Console.WriteLine("Host ready to process remote messages.");
    Console.ReadLine();
  }
}

And client code will look like this (old code commented out):

// using System.Runtime.Remoting;
using System.ServiceModel;

public class Client
{
  public static void Main()
  {
    // RemotingConfiguration.Configure("Client.Config");
    // MyService svc = new MyService();
    MyService svc = ServiceManager.CreateProxy<MyService>();

    Svc.Foo();
  }
}

Omer van Kloeten's blog has a post in which Jim Hogg, CLR PM at Microsoft, mentions in the comments a forthcoming feature, Friend Assemblies (via Brad Abrams):

So, we intend to introduce a new feature in next release of .NET -- "Friend Assemblies", that does precisely what you're suggesting. It will use an assembly-level custom attribute called "InternalsVisibleTo", that grants access to a named "friend" assembly (Omer.B in this example) -- for all "internal" types.

This sounds useful for cases where you don't want to package code in a single assembly yet still want to use "internal" visibility for your types and their members. The blog post and comments discuss some of the issues around this.

Update: John Lam describes how friend assemblies will be very useful for implementing unit tests.

Miguel de Icaza's blog has an interesting entry on the need to maintain API stability in Linux:

In particular my friend complained about the a.out to ELF migration; Then the ELF libc5 to libc6 migration, and apparently the new version of libc6 breaks their application again. They still update their software, but older binaries distributed to the public stop working on new releases of the product. Internally I know that all those changes were needed for Linux, and also that it is possible for the Linux community to provide the backwards compatible packages. Although this is possible in theory, in practice these compatibility libraries are not shipped with the main distributions

He is right to emphasize the importance of this. If you work on the Windows platform you feel pretty confident that your software will work on future versions of Windows whereas it seems that with Linux that you will lucky if it works on all the current distributions and very lucky if it will still work with any distribution two years from now. I'm not saying this is necessarily the reality, only the perception amongst people who don't do a lot of work with Linux. I agree with Miguel that Mono offers a lot here. A small example was a .NET program using XML-RPC.NET I wrote a few days ago. I built it on Windows using the Microsoft C# compiler, and copied the program and the XML-RPC.NET assembly to a Linux machine. I then ran it on the Linux machine. No recompilation necessary. It just worked. This is a big step forwards. Of course Java enthusiasts may disagree with the last statement but I am looking at this from a Windows developer's perspective where Java is probably not the chosen development environment.

Miguel de Icaza has announced the publication of the Mono project roadmap and a roadmap for contributors.

The one issue that surprised me was the lack of support for CAS (Code Access Security). I see this as being a very important part of the .NET environment in the long term. People will always find ways of loading malicious code onto machines and so we need to reach a situation where even local code will not be run unless it is trusted. For example, if we take away from end-users the ability to give trust to code, say via a global policy, it doesn't matter if an email contains an executable attachment which the user downloads and attempts to run: the code won't be trusted and the OS won't run it [1].

Miguel also commented in another post to the Mono list that "Mono has plenty of non-Microsoft components" and pointed to a diagram. Interesting to note XML-RPC.NET is included. I do intend the next release of the library to work with Mono on both Windows and Linux - its looking good so far - I just need some time to complete all the work and testing.

[1] This does presume the ability to prevent untrusted unmanaged local applications from running so we still have some way to go to the scenario I describe.

I ordered the Longhorn and Whidbey PDC release DVD(s) from MSDN a couple of days ago. Delivery is scheduled for 14th November. Reports suggest a fast machine with loads of memory will be advantageous.