BIOS Feature

I have mandatory BIOS password on my work computer. Some Catbert character thought of it as good security feature. Now, whenever I need to reboot my computer, I need to sit next to it.

I used to grab cap of coffee while it was rebooting and all I needed to do was to log into Windows once that is done. Now I need to sit next to it through whole shutdown process waiting for BIOS password and only then I can get a coffee. If there is some update in progress, that waiting period usually puts me in “I will kill this guy” state. I really hate waiting…

During that useless time my mind often wonders to my first Pentium-class computer. There you could set “stealth” BIOS password (I forgot official name of that feature). If such password was set, system would boot up without asking for anything. Everything seemed normal until you tried to use keyboard or mouse - they were locked. Only once you entered your password BIOS would release control of PS/2 ports and Windows would take over. Since Windows worked normally even without password, you could rely on this feature even across reboots.

I have pretty good idea why that feature is gone - USB. BIOS can intercept and handle PS/2 keyboards quite easily even once Windows are up and running. Since Windows talk with keyboard over BIOS, it can choose whether to pass characters or not. With USB things get complicated.

Once Windows take over USB control (and that is fairly early in boot process) there is no simple way BIOS can restrict it. Only approach that would work in that case would be some hardware virtualization. BIOS would have control over physical USB and Windows would get virtualized version controlled by BIOS.

I am quite sure that someone would do it if there weren’t three big problems - compatibility, performance and cost. Compatibility would be easiest to solve. Performance (latency) could be lowered by employing ASICs. However cost to do that would be high. And all that because of feature that is not that necessary to begin with.

Sometimes I long for simpler times… :)

Full Width Toolbar

As I ventured into WPF world, some things annoyed me more than others. One of those things was inability of toolbar to have no grip and to be full width.

After some time I found solution for grip problem. Just put toolbar in toolbar tray and set IsLocked attribute to true.

<ToolBarTray IsLocked="True">
    <ToolBar>
        ...
    </ToolBar>
</ToolBarTray>

Extending it’s width proved to be little bit more engaging. It took me a while to notice ActualWidth property of ToolbarTray control. As name says, it will return you actual width of ToolbarTray.

Since we want toolbar to span whole window, it should be inside DockPanel (and docked to top). Synchronizing ActualWidth of ToolbarTray and our Toolbar is then solved by simple data binding:

<DockPanel?
    <ToolBarTray IsLocked="True" DockPanel.Dock="Top">
        <ToolBar MinWidth="{Binding RelativeSource={RelativeSource AncestorType={x:Type ToolBarTray}}, Path=ActualWidth}">
            ...
        </ToolBar>
    </ToolBarTray>

    <Grid>
    </Grid>
</DockPanel>

Sample with everything done (and few things more) is here.

Got a Key?

Starcraft II has it’s release date confirmed. It will be available for general public on 27th July. Of course that probably means that I (a resident of Croatia) will not get it until some time later.

Detecting 64-Bit in .NET 4.0

In previous versions of .NET we could check whether process is 64-bit or not. It is not obvious solution - we check length of pointers.

With .NET 4.0 there are two new properties in Environment class. Is64BitProcess returns true if we are currently running in 32-bit mode. It is equivalent to our old-style check of IntPtr.Size == 4.

Is64BitOperatingSystem is something completely new. It will return true if operating system is capable of running 64-bit programs. This opens possibility of detecting 64-bit environment even if we run in 32-bits ourself. It will not be used often but it is good thing to have when e.g. running other processes.

Windows Phone Developer Tools

Some time ago Microsoft gave us CTP version (you might call it alpha) of Windows Phone development environment. Unfortunately, that version of Visual Studio 2010 Express for Windows Phone was not compatible with Visual Studio 2010 RTM.

Last days of April finally brought refreshed CTP with that particular problem solved.

Happy development.