When Windows Vista first came out nearly 3 months ago, I had a difficult time getting my XV-6700 PDA Phone from Verizon to connect to my laptop as a CDMA Modem. After much searching and reading of Microsoft KB articles I realized this driver had been floating around the Smartphone world since 2002. However Microsoft had changed the way they wanted winmodem drivers written around the time of Windows XP SP1, however Windows XP was still backwards compatible. However when Windows Vista was released they made the new driver format the rule, and thus the reason the 7 year old driver will not work.

So after I understood the problem I set out to change the driver based on this KB837637 article from Microsoft. And the follow picture shows how easy in the changes were to make the driver fully Windows Vista complaint.

So after the work I have done, which you can imagine it was mostly reading and understanding of the problem, I am giving this driver way free to my readers and anybody else who would like it. I provide no warranty or support for the above driver.
Download Smartphone USB Modem Driver

If you need help getting this driver to work with your Cell Phone, please check out the great articles from Engadget. They are Verizon and Sprint (CDMA) specific but should easily translate to Cingular and other GSM providers.

• How To: Use your EV-DO Pocket PC Phone for Internet Access
• How To: Use your CDMA cellphone as a USB Modem

Update: This driver was originally made by HTC, however there should be nothing preventing your from using it with other PDA devices that use the Pocket PC winmodem program.

I just found this today out on the net, it seems to have many forms so the author is Anonymous.

High School/Jr.High

  10 PRINT "HELLO WORLD"
  20 END

First year in College

  program Hello(input, output)
    begin
      writeln('Hello World')
    end.

Senior year in College

  (defun hello
    (print
      (cons 'Hello (list 'World))))

Read more

The System.IDisposable interface is a very useful interface to understand if you are concerned about performance in your application. Microsoft says the following about the IDisposable interface:

The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used, however, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.

Most System.Data, System.IO and System.Windows.Controls objects use the IDisposable interface, as well as many others, to free up unmanaged resources that may have been created when the object was initialized. Unmanaged resources are any calls that are made outside of the .NET environment, this can be GDI+ calls, SQL Driver calls, Disk IO calls, or basically anything that cannot be accounted for by the Garbage Collector.

Often times you will see database connection code that looks like this:

SqlConnection conn = new SqlConnection("{connection string}");
SqlCommand command = new SqlCommand(conn);

command.CommandText = "select * from SomeTable";

// ... some more code to use the command

conn.Close();

However there are a problem with this code, the unmanaged resources for the SQL connection have not yet been destroyed in memory. The correct way this code should have been written is the following:

using (SqlConnection conn = new SqlConnection("{connection string}")) {
	using (SqlCommand command = conn.CreateCommands()) {

	command.CommandText = "select * from SomeTable";

	// ... some more code to use the command

	conn.Close();
	}
}

And if you were to look at this code under a microscope the following code is actually what is happening:

SqlConnection conn;
SqlCommand command

try {
	conn = new SqlConnection("{connection string}");
	command = new SqlCommand(conn);

	command.CommandText = "select * from SomeTable";

	// ... some more code to use the command
} finally {
	conn.Close();
	command.Dispose();
	conn.Dispose();
}

So essentially even if an exception is thrown from your code, the unmanaged code is still cleaned up and you don’t have memory leaks from unmanaged code sitting around in memory waiting to be reclaimed. It is reclaimed instantly after you are done working with it.

If you would like to learn more about the code used above please see these links

• using Statement
• try-finally Block