AndrewEnsley.com » Operating System

Google's Chrome OS - First Impressions

Andrew — Fri, 20 Nov 2009 18:48:43 +0000

Yesterday, Google officially announced their new Chrome OS and explained what it will be when it's released. They also published the source code to allow developers and other interested parties to take a peek. I'm one of those "other interested parties."

The Setup

I didn't build the OS from source myself, but downloaded a pre-compiled VMWare image. Then, using CloneVDI, I converted it to a VirtualBox virtual hard disk. I just created a new Virtual Machine for Linux and added the .vdi. Done!

The Tour

First, you're presented with a logon screen. My first thought was "uhhh.... now what? I didn't create an account". Then I remembered: "This is a Google product. Try your Google login." And whadayano? It worked!

I don't know why it was off-center like that. It came up like that every time for me.

The first place I went to after logging in was a button at the top left that looked like a Chrome logo. That gave me this page:

Google Short Links

I don't know what "Google Short Links" is, but it wouldn't let me login with my regular username/password here.

I wanted to see what I was working with, so I went to the "About" dialog.

About

It's using Chromium 4.0.253.0 (32535).

Next, I went to the options menu.

Options Menu

The first page provides you with some time and touchpad settings.

Options Dialog

One setting that would be nice to have? Screen resolution. I couldn't find any place to change that, and the 800x600 default resolution feels incredibly confining. I found the bottom of the Basics tab humorous:

Basics Tab

Chromium cannot determine or set the default browser.

...oops.

As for the other two settings pages, they're exactly what we all have in Google Chrome right now.

Let's see... what should I try next? Oh yeah! How about my favorite Google service? Hello Gmail

Revoked Security Certificate

Wait... what? This happened to me several times. After refreshing, it usually worked, but it took over 5 refreshes once. Very annoying.

Once I finally got gmail to show up, I tried to enable offline mode. Surely this OS has gears built-in, right? Wrong. It asked me to install Gears:

Gears

Unfortunately, it's impossible to install Gears. I learned through this process that currently, it is impossible to open any file in this OS.

Gears Install

Clicking on the downloaded file does nothing. Clicking the "Open in folder" option from the file's sub-menu... does nothing. Google will have gears integrated by the time this is released. They'd be crazy not to.

Conclusion

My thoughts? Looks like fun. For how far along it is, the integration with Google services is impressive. It's definitely very rough right now. For example: there's no way to tell it to shut down. That's a pretty glaring oversight. But obviously, this is an extremely early release which is by no means complete.

Also, speed was an issue. Windows Vista Ultimate 64-bit runs faster in VirtualBox on my machine. That is not an exaggeration. In case you're wondering: My desktop runs on an Intel Core 2 Quad @ 2.66Ghz (Q9450) with 8GB of DDR3 1600Mhz RAM and a 10,000RPM boot drive (which also hosted the .vdi file), so the bottleneck was not my machine.

All problems aside, I can't wait to see what the finished product looks like, or how Google's new programming language will fit into it all.

Possibly Related posts:

C# Detect Windows OS Version - Part 1

Andrew — Tue, 23 Jun 2009 03:29:58 +0000

feed

privacy

partner

After reading this, check out Part 2: Using WMI for even more info

Introduction

I recently needed to programmatically determine the Operating System my software is running on. I was amazed at how difficult it was to find reliable, useful information on this subject. There were bits and pieces here and there, but almost everyone assumed I had some pre-existing knowledge of the process in one manner or another. Hopefully, this little series will save somebody some time in the future.

The thing that makes this so difficult is that there are almost as many different ways to detect the operating system as there are operating systems! It's an unbelievably frustrating experience trying to reinvent this wheel, so I'll try to walk through it here.

Strategies

There are 4 basic strategies:

Read and parse information from files in the Windows directory. This is probably the most difficult and least rewarding method. The files are different for each generation of OS and the format is not guaranteed in almost any case.
Read information from the registry. This method works a little better, but you still have varying locations for the information based on which OS you're dealing with.
Use Environment variables. Nothing is more reliable. However, it doesn't give you the nitty-gritty detail you might want. For example: There's no way to detect XP Home vs. XP Professional.
Use WMI to query for information about the OS. This gives you everything you could possibly want all in one shot. Unfortunately, it's not supported in pre-NT versions of Windows (of course, this is becoming less and less of a problem).

I started with number 1. After pulling most of my hair out and wanting to punch my keyboard, I moved on to number 2. That was a dead end too. I could have made it work, but I didn't have the patience. I gave number 3 a try and was very happy... ...until I decided that the specific version of 2000, XP, Vista, and 7 mattered to me. So I finally ended up with a combination of 3 and 4.

For part 1 of this series, I'm going to focus on number 3, a.k.a. The Easy Way^tm

The Code

The key to everything is the Environment class. It has everything we need in a property called OSVersion. However, the information is a little cryptic (mostly a bunch of numbers), so it takes some work to get a "friendly" value returned.

This first method gives us the Operating system architecture as an integer. The environment variable "PROCESSOR_ARCHITECTURE" is either set to "x86" or doesn't exist on 32-bit versions of Windows. It's always set to something other than "x86" on 64-bit versions of Windows.

1
2
3
4
5

int getOSArchitecture()
{
string pa = Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE");
return ((String.IsNullOrEmpty(pa) || String.Compare(pa, 0, "x86", 0, 3, true) == 0) ? 32 : 64);
}

For something that seems so simple, this can actually be very confusing. There are two important notes about this method:

Even though the physical CPU's architecture may support 64-bit operations, this environment variable will always return the architecture of the OS. So 32-bit Windows running on a 64-bit capable processor will return 32-bit. It's a bit of a misnomer, but provides the information we really want anyway.
Even though the CPU is 64-bit capable, and the OS architecture is 64-bit, your .Net program could still be running as a 32-bit application. Sometimes, this information is more useful than knowing whether Windows is 32- or 64-bit. To see if your program is actually running in 64-bit mode, check to see if IntPtr.Size == 8. It will be 4 in 32-bit mode and 8 in 64-bit mode.

Now onto the actual Operating System version. The following code is largely based on what I found on the Microsoft Knowledge Base article: How to determine the Windows version by using Visual C#.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

string getOSInfo()
{
//Get Operating system information.
OperatingSystem os = Environment.OSVersion;
//Get version information about the os.
Version vs = os.Version;

//Variable to hold our return value
string operatingSystem = "";

if (os.Platform == PlatformID.Win32Windows)
{
//This is a pre-NT version of Windows
switch (vs.Minor)
{
case 0:
operatingSystem = "95";
break;
case 10:
if (vs.Revision.ToString() == "2222A")
operatingSystem = "98SE";
else
operatingSystem = "98";
break;
case 90:
operatingSystem = "Me";
break;
default:
break;
}
}
else if (os.Platform == PlatformID.Win32NT)
{
switch (vs.Major)
{
case 3:
operatingSystem = "NT 3.51";
break;
case 4:
operatingSystem = "NT 4.0";
break;
case 5:
if (vs.Minor == 0)
operatingSystem = "2000";
else
operatingSystem = "XP";
break;
case 6:
if (vs.Minor == 0)
operatingSystem = "Vista";
else
operatingSystem = "7";
break;
default:
break;
}
}
//Make sure we actually got something in our OS check
//We don't want to just return " Service Pack 2" or " 32-bit"
//That information is useless without the OS version.
if (operatingSystem != "")
{
//Got something. Let's prepend "Windows" and get more info.
operatingSystem = "Windows " + operatingSystem;
//See if there's a service pack installed.
if (os.ServicePack != "")
{
//Append it to the OS name. i.e. "Windows XP Service Pack 3"
operatingSystem += " " + os.ServicePack;
}
//Append the OS architecture. i.e. "Windows XP Service Pack 3 32-bit"
operatingSystem += " " + getOSArchitecture().ToString() + "-bit";
}
//Return the information we've gathered.
return operatingSystem;
}

Notice that getOSInfo() returns an empty string if it was unable to determine the OS version.

The code should be pretty self-explanatory, and the great thing is that you don't have to reference any special assemblies. Everything is right there in System.

Want even more information? Don't miss Part 2: Using WMI

Possibly Related posts:

C# Detect Windows OS Version – Part 2 (WMI)