Bruce Eitman

Simple Little Registry Editor - New Release

Bruce Eitman — Mon, 19 Nov 2012 17:40:49 GMT

Originally posted on: http://geekswithblogs.net/BruceEitman/archive/2012/11/19/simple-little-registry-editor---new-release.aspx

I have posted a new release of the Simple Little Registry Editor found in Windows CE: Simple Little Registry Editor.

This release fixes a problem with writing DWORD values when the most significant bit is set. The application uses RegistryKey.SetValue. There seems to be a problem with how the .NET CompactFramework (and the full framework) handle the second argument during the call which causes an exception.

So the following does not work:

RegistryKey.SetValue( "TestValue", 0xFFFFFFFF, RegistryValueKind.DWord );

But, this does:

RegistryKey.SetValue( "TestValue",unchecked((int) 0xFFFFFFFF), RegistryValueKind.DWord );

C#: My World Clock

Bruce Eitman — Thu, 25 Oct 2012 18:14:33 GMT

Originally posted on: http://geekswithblogs.net/BruceEitman/archive/2012/10/25/c-my-world-clock.aspx

Download World Clock Source

I have been working on cleaning my office of 8 years of stuff from several engineers working on many projects. It turns out that we have a few extra single board computers with displays, so at the end of the day last Friday I though why not create a little application to display the time, you know, a clock.

How difficult could that be? It turns out that it is quite simple – until I decided to gold plate the project by adding time displays for our offices around the world.

I decided to use C#, which actually made creating the main clock quite easy. The application was simply a text box and a timer. I set the timer to fire a couple of times a second, and when it does use a DateTime object to get the current time and retrieve a string to display.

And I could have been done, but of course that gold plating came up. Seems simple enough, simply offset the time from the local time to the location that I want the time for and display it. Sure enough, I had the time displayed for UK, Italy, Kansas City, Japan and China in no time at all.

But it is October, and for those of us still stuck with Daylight Savings Time, we know that the clocks are about to change. My first attempt was to simply check to see if the local time was DST or Standard time, then change the offset for China. China doesn’t have Daylight Savings Time.

If you know anything about the time changes around the world, you already know that my plan is flawed – in a big way. It turns out that the transitions in and out of DST take place at different times around the world. If you didn’t know that, do a quick search for “Daylight Savings” and you will find many WEB sites dedicated to tracking the time changes dates, and times.

Now the real challenge of this application; how do I programmatically find out when the time changes occur and handle them correctly? After a considerable amount of research it turns out that the solution is to read the data from the registry and parse it to figure out when the time changes occur.

Reading Time Change Information from the Registry

Reading the data from the registry is simple, using the data is a little more complicated. First, reading from the registry can be done like:

byte[] binarydata = (byte[])Registry.GetValue("HKEY_LOCAL_MACHINE\\Time Zones\\Eastern Standard Time", "TZI", null);

Where I have hardcoded the registry key for example purposes, but in the end I will use some variables.

We now have a binary blob with the data, but it needs to be converted to use the real data. To start we will need a couple of structs to hold the data and make it usable. We will need a SYSTEMTIME and REG_TZI_FORMAT. You may have expected that we would need a TIME_ZONE_INFORMATION struct, but we don’t. The data is stored in the registry as a REG_TZI_FORMAT, which excludes some of the values found in TIME_ZONE_INFORMATION.

struct SYSTEMTIME

{

internal short wYear;

internal short wMonth;

internal short wDayOfWeek;

internal short wDay;

internal short wHour;

internal short wMinute;

internal short wSecond;

internal short wMilliseconds;

}

struct REG_TZI_FORMAT

{

internal long Bias;

internal long StdBias;

internal long DSTBias;

internal SYSTEMTIME StandardStart;

internal SYSTEMTIME DSTStart;

}

Now we need to convert the binary blob to a REG_TZI_FORMAT. To do that I created the following helper functions:

private void BinaryToSystemTime(ref SYSTEMTIME ST, byte[] binary, int offset)

{

ST.wYear = (short)(binary[offset + 0] + (binary[offset + 1] << 8));

ST.wMonth = (short)(binary[offset + 2] + (binary[offset + 3] << 8));

ST.wDayOfWeek = (short)(binary[offset + 4] + (binary[offset + 5] << 8));

ST.wDay = (short)(binary[offset + 6] + (binary[offset + 7] << 8));

ST.wHour = (short)(binary[offset + 8] + (binary[offset + 9] << 8));

ST.wMinute = (short)(binary[offset + 10] + (binary[offset + 11] << 8));

ST.wSecond = (short)(binary[offset + 12] + (binary[offset + 13] << 8));

ST.wMilliseconds = (short)(binary[offset + 14] + (binary[offset + 15] << 8));

}

private REG_TZI_FORMAT ConvertFromBinary(byte[] binarydata)

{

REG_TZI_FORMAT RTZ = new REG_TZI_FORMAT();

RTZ.Bias = binarydata[0] + (binarydata[1] << 8) + (binarydata[2] << 16) + (binarydata[3] << 24);

RTZ.StdBias = binarydata[4] + (binarydata[5] << 8) + (binarydata[6] << 16) + (binarydata[7] << 24);

RTZ.DSTBias = binarydata[8] + (binarydata[9] << 8) + (binarydata[10] << 16) + (binarydata[11] << 24);

BinaryToSystemTime(ref RTZ.StandardStart, binarydata, 4 + 4 + 4);

BinaryToSystemTime(ref RTZ.DSTStart, binarydata, 4 + 16 + 4 + 4);

return RTZ;

}

I am the first to admit that there may be a better way to get the settings from the registry and into the REG_TXI_FORMAT, but I am not a great C# programmer which I have said before on this blog. So sometimes I chose brute force over elegant.

Now that we have the Bias information and the start date information, we can start to make sense of it. The bias is an offset, in minutes, from local time (if already in local time for the time zone in question) to get to UTC – or as Microsoft defines it: UTC = local time + bias. Standard bias is an offset to adjust for standard time, which I think is usually zero. And DST bias is and offset to adjust for daylight savings time.

Since we don’t have the local time for a time zone other than the one that the computer is set to, what we first need to do is convert local time to UTC, which is simple enough using:

DateTime.Now.ToUniversalTime();

Then, since we have UTC we need to do a little math to alter the formula to: local time = UTC – bias. In other words, we need to subtract the bias minutes.

I am ahead of myself though, the standard and DST start dates really aren’t dates. Instead they indicate the month, day of week and week number of the time change. The dDay member of SYSTEM time will be set to the week number of the date change indicating that the change happens on the first, second… day of week of the month. So we need to convert them to dates so that we can determine which bias to use, and when to change to a different bias. To do that, I wrote the following function:

private DateTime SystemTimeToDateTimeStart(SYSTEMTIME Time, int Year)

{

DayOfWeek[] Days = { DayOfWeek.Sunday,

DayOfWeek.Monday,

DayOfWeek.Tuesday,

DayOfWeek.Wednesday,

DayOfWeek.Thursday,

DayOfWeek.Friday,

DayOfWeek.Saturday };

DateTime InfoTime = new DateTime(Year,

Time.wMonth,

Time.wDay == 1 ? 1 : ((Time.wDay - 1) * 7) + 1,

Time.wHour,

Time.wMinute,

Time.wSecond,

DateTimeKind.Utc);

DateTime BestGuess = InfoTime;

while (BestGuess.DayOfWeek != Days[Time.wDayOfWeek])

{

BestGuess = BestGuess.AddDays(1);

}

return BestGuess;

}

SystemTimeToDateTimeStart gets two parameters; a SYSTEMTIME and a year. The reason is that we will try this year and next year because we are interested in start dates that are in the future, not the past. The function starts by getting a new Datetime with the first possible date and then looking for the correct date.

Using the start dates, we can then determine the correct bias to use, and the next date that time will change:

NextTimeChange = StandardChange;

CurrentBias = TimezoneSettings.Bias + TimezoneSettings.DSTBias;

if (DSTChange.Year != 1 && StandardChange.Year != 1)

{

if (DSTChange.CompareTo(StandardChange) < 0)

{

NextTimeChange = DSTChange;

CurrentBias = TimezoneSettings.StdBias + TimezoneSettings.Bias;

}

else

{

// I don't like this, but it turns out that China Standard Time

// has a DSTBias of -60 on every Windows system that I tested.

// So, if no DST transitions, then just use the Bias without

// any offset

CurrentBias = TimezoneSettings.Bias;

}

Note that some time zones do not change time, in which case the years will remain set to 1. Further, I found that the registry settings are actually wrong in that the DST Bias is set to -60 for China even though there is not DST in China, so I ignore the standard and DST bias for those time zones.

There is one thing that I have not solved, and don’t plan to solve. If the time zone for this computer changes, this application will not update the clock using the new time zone. I tell you this because you may need to deal with it – I do not because I won’t let the user get to the control panel applet to change the timezone.

Windows CE: Changing Static IP Address

Bruce Eitman — Thu, 25 Oct 2012 01:00:19 GMT

Originally posted on: http://geekswithblogs.net/BruceEitman/archive/2012/10/24/windows-ce-changing-static-ip-address.aspx

A customer contacted me recently and asked me how to change a static IP address at runtime. Of course this is not something that I know how to do, but with a little bit of research I figure out how to do it.

It turns out that the challenge is to request that the adapter update itself with the new IP Address. Otherwise, the change in IP address is a matter of changing the address in the registry for the adapter. The registry entry is something like:

[HKEY_LOCAL_MACHINE\Comm\LAN90001\Parms\TcpIp]
    "EnableDHCP"=dword:0
    "IpAddress"="192.168.0.100"
    "DefaultGateway"="192.168.0.1"
    "Subnetmask"="255.255.255.0"

Where LAN90001 would be replace with your adapter name. I have written quite a few articles about how to modify the registry, including a registry editor that you could use.

Requesting that the adapter update itself is a matter of getting a handle to the NDIS driver, and then asking it to refresh the adapter. The code is:

#include <windows.h>

#include "winioctl.h"

#include "ntddndis.h"

void RebindAdapter( TCHAR *adaptername )

{

HANDLE hNdis;

BOOL fResult = FALSE;

int count;

// Make this function easier to use - hide the need to have two null characters.

int length = wcslen(adaptername);

int AdapterSize = (length + 2) * sizeof( TCHAR );

TCHAR *Adapter = malloc(AdapterSize);

wcscpy( Adapter, adaptername );

Adapter[ length ] = '\0';

Adapter[ length +1 ] = '\0';

hNdis = CreateFile(DD_NDIS_DEVICE_NAME,

GENERIC_READ | GENERIC_WRITE,

FILE_SHARE_READ | FILE_SHARE_WRITE,

NULL,

OPEN_ALWAYS,

NULL);

if (INVALID_HANDLE_VALUE != hNdis)

{

fResult = DeviceIoControl(hNdis,

IOCTL_NDIS_REBIND_ADAPTER,

Adapter,

AdapterSize,

NULL,

&count,

NULL);

if( !fResult )

{

RETAILMSG( 1, (TEXT("DeviceIoControl failed %d\n"), GetLastError() ));

}

CloseHandle(hNdis);

}

else

{

RETAILMSG( 1, (TEXT("Failed to open NDIS Handle\n")));

}

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow)

{

RebindAdapter( TEXT("LAN90001") );

return 0;

}

If you don’t want to write any code, but instead plan to use a registry editor to change the IP Address, then there is a command line utility to do the same thing. NDISConfig.exe can be used:

Ndisconfig adapter rebind LAN90001

Windows CE: C# Application to Format TFAT

Bruce Eitman — Tue, 31 Aug 2010 02:34:37 GMT

Originally posted on: http://geekswithblogs.net/BruceEitman/archive/2010/08/30/windows-ce-c-application-to-format-tfat.aspx

Windows CE: C# Application to Format TFAT

In Windows CE: Formatting TFAT I show how to format a disk with TFAT using C/C++ code. The customer that I wrote that for develops using C#, so I wrote a C# application to test the formatting code. To me, most formatting tools are just too difficult for the average user. In this case, the user will be someone working in the factory or field service. They just need to select a disk and request that it be formatted.

The application dialog look like:

It has a drop down list which I populated with a list of disks, a format button and an exit button. It is simple, and easy to use.

The hard part of this application is populating the drop down list. I did some searching and found suggestion of using System.IO.DirectoryInfo to find the root folders and check the attributes for temporary folders. The following code demonstrates this approach, were DiskSelect is the drop down list:

System.IO.DirectoryInfo DI = new System.IO.DirectoryInfo(@"\");

System.IO.DirectoryInfo[] Folders = DI.GetDirectories();

foreach (System.IO.DirectoryInfo FDI in Folders)

{

if (FDI.Attributes.CompareTo(System.IO.FileAttributes.Temporary) == 1)

DiskSelect.Items.Add(FDI.Name);

}

if( DiskSelect.Items.Count > 0 )

DiskSelect.SelectedIndex = 0;

This code works and can be effective on some systems. But it has a flaw which is that not all temprary folders are disks. If your OS includes the network redirector component, there will be a Network folder which is temporary but is not a disk. The Release folder which is used in debugging the OS using Platform Builder is also temporary, but not a disk.

The only alternative that I could find is to use FindFirstStore()/FindNextStore() and FindFirstPartition()/FindNextPartition() which are included in StoreAPI. The downside of this approach is that StoreAPI is not generaly included in the SDK and worse, it is not a DLL in the system so it cannot be P/Invoked. So if you don’t have access to the StoreAPI, you might as well stop reading now – the rest of this assumes that you do have access to StoreAPI. If you don’t have it, you might want to ask your OEM for it because it has some valuable functions for accessing disk information.

I could have simply wrapped the StoreAPI with a DLL, which would have been as simple as just linking StoreAPI.lib with a DllEntry() function. But I am not a good enough C# programmer to define the structures needed for C# and I felt that for a C# program the functions are just too clunky. Instead I made some assumptions before writing the code. The assumptions are:

1. The functions that I will be writing will be used for populating a drop down list and nothing more sophisticated

2. The disks have only one partition, if you are working with systems that have multiple partitions you can extend the code to handle that but I didn’t need it

I realized that I needed to have some data that I could let the application track and pass into function calls. So I started by defining the structure that I needed:

typedef struct __FindDiskInfo__

{

STOREINFO StoreInfo;

PARTINFO PartInfo;

} FindDiskInfoT;

STOREINFO and PARTINFO are defined in storemgr.h which is included in the SDK. I plan to create functions that populate the structure and then some functions to get the strings that I need. This should make the C# fairly easy to write. The first step is to initalize the structure and get a pointer/reference from the C/C++ code to the C# code. NewStoreInfo() will allocate the storage and initialize it and DeleteStoreInfo() will release the structure:

__declspec(dllexport) FindDiskInfoT * APIENTRY NewStoreInfo()

{

FindDiskInfoT *FindDiskInfo;

RETAILMSG( 1, (TEXT("NewStoreInfo\n")));

FindDiskInfo = (FindDiskInfoT *)malloc( sizeof(FindDiskInfoT) );

if( FindDiskInfo == NULL )

{

RETAILMSG( 1, (TEXT("StartFindStore: malloc failed\n")));

return NULL;

}

memset(FindDiskInfo, 0, sizeof(FindDiskInfoT));

FindDiskInfo->StoreInfo.cbSize = sizeof(STOREINFO);

FindDiskInfo->PartInfo.cbSize = sizeof(PARTINFO);

wcscpy(FindDiskInfo->PartInfo.szVolumeName, TEXT("TEST VolName"));

RETAILMSG( 1, (TEXT("NewStoreInfo return %X\n"), FindDiskInfo));

return FindDiskInfo;

}

__declspec(dllexport) BOOL APIENTRY DeleteStoreInfo(HANDLE hFind, FindDiskInfoT *FindDiskInfo)

{

if( FindDiskInfo != NULL )

{

free( FindDiskInfo );

}

if( hFind )

{

FindCloseStore( hFind );

}

return TRUE;

}

And the C# call to these function is:

IntPtr StoreInfo;

StoreInfo = NewStoreInfo();

…

DeleteStoreInfo(hStore, StoreInfo);

Note that DeleteStoreInfo() has an hStore passed into into it. hStore is HANDLE used for finding the disks. hStore is returned from StartFindDisk() which is called to start finding available disks. StartFindDisk() receives a pointer to the previously allocated FindDiskInfoT:

__declspec(dllexport) HANDLE APIENTRY StartFindDisk( FindDiskInfoT *FindDiskInfo )

{

HANDLE hFind = INVALID_HANDLE_VALUE;

hFind = FindFirstStore(&(FindDiskInfo->StoreInfo));

if( hFind != INVALID_HANDLE_VALUE )

{

HANDLE hStore;

hStore = OpenStore( FindDiskInfo->StoreInfo.szDeviceName );

if( hStore )

{

HANDLE hFind = INVALID_HANDLE_VALUE;

hFind = FindFirstPartition(hStore, &(FindDiskInfo->PartInfo));

if(INVALID_HANDLE_VALUE != hFind)

{

FindClose(hFind);

}

else

RETAILMSG( 1, (TEXT("No Partitions Found\n")));

CloseHandle(hStore);

}

else

RETAILMSG(1, (TEXT("OpenSelectedStore failed\n")));

}

else

{

RETAILMSG( 1, (TEXT("StartFindStore: FindFirstStore failed %d\n"), GetLastError()));

}

return hFind;

}

And the C# call is:

hStore = StartFindDisk(StoreInfo);

StartFindDisk() finds the first available disk and the first partition on the disk and populates the FindDiskInfoT structure with the available information for use later. After calling this, to get the name of the folder, the device name and the partition name, the following functions can be used:

__declspec(dllexport) TCHAR * APIENTRY GetStoreDeviceName( FindDiskInfoT *FindDiskInfo )

{

TCHAR * RetVal = NULL;

if( FindDiskInfo )

{

RetVal = FindDiskInfo->StoreInfo.szDeviceName;

}

return RetVal;

}

__declspec(dllexport) TCHAR * APIENTRY GetStoreFolderName( FindDiskInfoT *FindDiskInfo )

{

TCHAR * RetVal = NULL;

if( FindDiskInfo )

{

RetVal = FindDiskInfo->PartInfo.szVolumeName;

}

return RetVal;

}

__declspec(dllexport) TCHAR * APIENTRY GetStorePartitionName( FindDiskInfoT *FindDiskInfo )

{

TCHAR * RetVal = NULL;

if( FindDiskInfo )

{

RetVal = FindDiskInfo->PartInfo.szPartitionName;

}

return RetVal;

}

Then to get the rest of the disks, FindNextDisk() is used:

__declspec(dllexport) BOOL APIENTRY FindNextDisk( HANDLE hFind, FindDiskInfoT *FindDiskInfo )

{

BOOL FindResult = FALSE;

if( FindDiskInfo == NULL || hFind == INVALID_HANDLE_VALUE )

{

RETAILMSG( 1, (TEXT("FindNextDisk: invalid parameters\n")));

return FALSE;

}

FindResult = FindNextStore(hFind, &(FindDiskInfo->StoreInfo));

if( FindResult != FALSE )

{

HANDLE hStore;

hStore = OpenStore( FindDiskInfo->StoreInfo.szDeviceName );

if( hStore )

{

HANDLE hFind = INVALID_HANDLE_VALUE;

memset( &(FindDiskInfo->PartInfo), 0, sizeof(PARTINFO));

FindDiskInfo->PartInfo.cbSize = sizeof(PARTINFO);

hFind = FindFirstPartition(hStore, &(FindDiskInfo->PartInfo));

if(INVALID_HANDLE_VALUE != hFind)

{

FindClose(hFind);

}

else

{

RETAILMSG( 1, (TEXT("FindNextDisk: No Partitions Found %d\n"), GetLastError()));

FindResult = FALSE;

}

CloseHandle(hStore);

}

else

{

RETAILMSG(1, (TEXT("FindNextDisk: OpenSelectedStore failed\n")));

FindResult = FALSE;

}

else

{

RETAILMSG( 1, (TEXT("FindNextDisk: FindNextStore failed %d\n"), GetLastError()));

FindResult = FALSE;

}

return FindResult;

}

Similar to StartFindDisk() this finds the next disk and its first partition and populates the FindDiskInfoT with the available data, so that the strings can be retreived later.

The code for setting up the C# dialog looks like: