Windows CE General

Windows CE: Running Batch Files

Bruce Eitman — Thu, 21 Aug 2008 23:53:28 GMT

Every once in a while I am asked about running batch files on Windows CE. My first response of course to ask why? But let’s assume that you are set on using a batch file. I know you probably think that batch files are easy to modify, but really I don’t think that they are and you may find that batch files for Windows CE aren’t that easy.

The first thing that you are going to need is a Command window, or DOS shell, to run your batch file in. It is likely that your system doesn’t have one, but if you have control over the content of your Windows CE OS ROM image, you can add one using Platform Builder or as your OS team to add one. If you don’t have one and don’t have control over the OS, then you will need to find one that you can use. I do have control over my OS, so I have never needed to look for one.

To demonstrate that batch files can run in Windows CE, and to check for some of the shortcomings, I created the following batch file:

@ECHO OFF

echo Running Batch.bat

set LOGOFILE="\Release\Logo.jpg"

set TESTFILE="\Release\Test.txt"

if EXIST %LOGOFILE% xcopy %LOGOFILE% \Windows

if EXIST %LOGOFILE% copy %LOGOFILE% \Windows

for /F %%i in (%TESTFILE%) Do (

echo %%i

)

CALL :ListDirs

Pushd \Windows

Dir /A:D

Popd

GOTO :EOF

:ListDirs

cd %1

for /F %%i in ('dir /A:D /B /S \Windows' ) Do (

Echo Dir %%i

)

GOTO :EOF

Careful, don’t think that everything in this file works. Some things do not work:

1. Xcopy isn’t available, but copy is

2. For loops aren’t suppprted, but if statements are

3. Call is supported, but not to functions in the batch file

4. Pushd and Popd aren’t supported, but cd is

I am sure that if I kept adding things to this batch file, I would have found more unsupported features that are supported in big Windows or DOS.

I think that it might be easier to write a simple application to do most of what you might want to do in a batch file. You can write an application that uses main() for Windows CE, and have for loops. But I am a C programmer so what is easy to me might not be so easy for you.

Windows CE: Automatically setting the Object Store Size

Bruce Eitman — Thu, 21 Aug 2008 01:40:32 GMT

A customer asked me an interesting question today. He wanted to know how to know how much space his system needed for the Object Store. That had me thinking that there could be a way to monitor the size and automatically adjust it, Windows Mobile does that. Of course Windows Mobile probably has a better way to manage the Object Store size than this, I am guessing that it monitors the size within FileSys and adjusts it as requests come in.

I wrote the following code just to see what could be done. I don’t necessary think that this is a good way to do it, but it is something that could be used to monitor the Object Store.

CheckObjectStoreSize() will check the current number of pages being used by the Object Store and will adjust the size to the maximum of:

- The documented minimum size of 128K

o #define DOCUMENTED_MIN_OS_PAGES( PageSize ) (( 128 * 1024 )/PageSize )

- Current number of pages being used plus MIN_FREE_PAGES, which is a random number that I picked

o #define MIN_FREE_PAGES( PageSize ) ((100 * 1024)/PageSize)

Because the number of pages being used is obtained using GetSStoreInformation() this function will both increase and decrease the size of the Object Store.

void CheckObjectStoreSize()

{

DWORD StorePages,

DWORD RamPages

DWORD PageSize;

DWORD CurrentNeededSize;

DWORD Status;

DWORD ObjectStorePages;

STORE_INFORMATION StoreInfo;

GetSystemMemoryDivision(&StorePages, &RamPages, &PageSize);

GetStoreInformation(&StoreInfo);

CurrentNeededSize = ((StoreInfo.dwStoreSize - StoreInfo.dwFreeSize)/PageSize) + 1 ;

ObjectStorePages = DOCUMENTED_MIN_OS_PAGES(PageSize);

// Check to see if the current Object Store needs to be bigger

if( ObjectStorePages < (CurrentNeededSize + MIN_FREE_PAGES( PageSize) ))

{

ObjectStorePages = (CurrentNeededSize + MIN_FREE_PAGES( PageSize));

}

// Do we have enough free space to increase the Object Store?

if (ObjectStorePages >= (StorePages + RamPages))

{

RETAILMSG(1,(TEXT("Out of memory to increase Object Store\n")));

return;

}

Status = SetSystemMemoryDivision (ObjectStorePages);

if (Status)

{

RETAILMSG(1,(TEXT("Failed to set Object Store: ")));

switch(Status)

{

case SYSMEM_MUSTREBOOT:

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

break;

case SYSMEM_REBOOTPENDING:

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

break;

case SYSMEM_FAILED:

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

break;

default:

break;

}

I then tested the CheckObjectStoreSize() by calling it in a loop from WinMain(). The loop copies a file from the storage card to the Object Store 50 times followed by deleting the files on the next 40 times through the loop.

int WINAPI WinMain(

HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow

)

{

DWORD Counter = 0;

TCHAR FileName[ MAX_PATH ];

BOOL Toggle = FALSE;

while( 1 )

{

Sleep( 5000 );

wsprintf( FileName, TEXT("\\File%d.txt"), Counter++ );

RETAILMSG( 1, (TEXT("Copy to %s\n"), FileName ));

if( Counter > 50 )

{

Toggle = !Toggle;

Counter = 0;

}

if( Toggle )

{

if( !DeleteFile( FileName ))

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

}

else

{

if( !CopyFile( TEXT("\\Storage Card\\a.txt"), FileName, FALSE ))

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

}

CheckObjectStoreSize();

}

Tags: ObjectStore

Windows CE: Number of Processes and Threads

Bruce Eitman — Thu, 07 Aug 2008 02:37:42 GMT

Once in a while I am asked how many processes can run at any time in a Windows CE system. It is also one of my interview questions when interviewing a candidate with Windows CE experience, and the follow on question is how many threads can run at one time?

Number of Processes:

Then number of processes is controlled by the kernel and was changed for Windows CE 6.0 to be 32K processes. Pretty impressive, but I suspect that the limit is much smaller because on most, if not all, Windows CE systems you will run out of physical memory long before creating even close to 32K processes (I suppose that there is another post topic in that sentence.) Each process has up to 2GB of virtual address space available to it. As a result, Microsoft lifted the artificial limits on number of processes and virtual address space, now the limit is hardware.

The number of processes that can run at simultaneously in Windows CE 5.0 and earlier versions is 32. Each process has 32MB of virtual address space available to it. The reason for these limits is that the address space for processes is divided into 33 slots each having 32MB of virtual address space available to it. The slots are numbered 0 through 32, with slot 0 being the currently running process.

There was a significant change to the slot architecture in Windows CE 4.0. Slot 1, which was where the kernel ran in prior versions, was reserved for loading DLLs that were specifically fixed up to run in slot 1. The kernel moved out of the slots altogether, so this change didn’t reduce the number of processes that could run. This change was significant because in previous versions all DLLs loaded in slot 0, which meant that the DLLs reduced the amount of available virtual address space available to the running process. That is if any process loaded a DLL, all processes suffered the loss of virtual address space. This was still true for Windows CE 4.x and 5.0, but only if the DLL was not fixed up to run in slot 1, but most of the DLLs that are loaded are included in the OS and are fixed up to run in slot 1.

Number of Threads

The number of threads is only limited by the available system resources. That is a fancy way of saying that when the system runs out of physical RAM, no more threads can be started.

	Number of Processes	Number of Threads	Virtual Address Space per Process
Windows CE 5.0 and before	32	Limited by System Resources	32 MB
Windows CE 6.0	32K	Limited By System Resources	2 GB

Tags: Kernel

Platform Builder: RETAILMSG vs. DEBUGMSG

Bruce Eitman — Thu, 24 Jul 2008 02:33:23 GMT

What is the difference between RETAILMSG and DEBUGMSG? This question comes up once in a while, so I thought it might be interesting to discuss it.

The first thing that we should think about is what are these? The first clue, assuming that we don’t read the documentation, is that they are both in all capital letters. This is usually a clue that they are macros. If they are macros, they cannot be hidden away in a binary, they must be in a header file that we can look at to figure out what they do. If I didn’t like you so much, I would just stop here and let you go off and search for them to figure them out.

HINT: A search of the Public tree would take a long time, but since sysgen puts the header files that we need in our OSDesign or PBWorkspace folder we can search there and save a lot of time. Search in the WINCE<version>\<BSP specific folder>\cesysgen sub folder.

After searching for RETAILMSG, you should find that it is defined in dbgapi.h. Now we have a way to see what they do. You will notice that it looks something like this:

#ifdef SHIP_BUILD

This is a ship build

Define DEBUGMSG and RETAILMSG so that they don’t do anything

#else

#ifdef DEBUG

This is a debug build

Define DEBUGMSG so that it outputs if the condition is met

#else

This is a retail build

Define DEBUGMSG and RETAILMSG so that they don’t do anything

#endif

For both debug and retail builds do this

Define RETAILMSG so that it outputs if the condition is met

#endif

This means that the important difference between RETAILMSG and DEBUGMSG is the conditions that allow or exclude them from outputting their messages.

When defined to output messages, both RETAILMSG and DEBUGMSG will output the message if the first parameter, the condition, is true. Where they output the message is up to you. If you are using KITL, they will output on the KITL transport once the connection is established. If you are not using KITL or if the connection has not been established they will output using the HAL OEMWriteDebugString() function. OEMWriteDebugString() can be implemented in different ways on different platforms, but usually it will output on a serial port.

The second parameter of both RETAILMSG and DEBUGMSG are the variable argument list to be passed to NKDbgPrintfW. Because this is a macro, this parameter must be wrapped in a parenthesis which are part of the argument. The arguments for NKDbgPrintfW are similar to printf, except that the format string is a wide character string. This means that the format string must be qualified by using a macro that changes the char string to a wide character string. I prefer the TEXT() macro for this, but there are other ways.

Tags: Sysgen, RETAILMSG, DEBUGMSG

Windows CE: Starting an Application when the System Boots

Bruce Eitman — Tue, 01 Jul 2008 03:35:49 GMT

You have developed or bought a Windows CE system and developed an Application for it. Now you want to start your application every time the system boots up. Not an unusual need, but the solution will have a lot to do with who you are and what you have to work with.

So, who are you?

Platform Builder User

Since you are using Platform Builder, you have access to the system registry so you can use the HKEY_LOCAL_MACHINE\Init key to start your application. FileSys uses HKEY_LOCAL_MACHINE\Init to find which applications to start when the system boots. The values are LaunchXX and DependXX, where the XX are numbers; example Launche60 and Depend60. This is the same registry key that is used to start applications like the device manager, the services manager and the Explorer shell.

LaunchXX is a string value. Pick a number, one that makes sense within the context of your system, and set the value of LaunchXX to the name of your application; Example Launch60=”MyApp.exe”. You cannot use this string to pass command line arguments to your application. If you need to pass command line arguments, you should create a small wrapper application that calls on your application and passes arguments to it.

DependXX is a hex value. The XX number must match the number that you used for LaunchXX. The value indicates which of the LaunchXX applications your application is dependent on. "Depend60"=hex:14,00, 1e,00 indicates that the application is dependent on Launch20 (0x14 == 20) and Launch30 (0x1e == 30).

If you use HKEY_LOCAL_MACHINE\Init to start your application, you should call SignalStarted() to tell the system that your application is running and ready. Failure to call SignalStarted() can cause other applications to not be started.

Visual Studio User\End User

If you are not developing the Windows CE OS for your platform, you can add your application to the \Windows\Startup folder. This option does require that the \Windows\Startup folder is persistent and that the Explorer shell runs on your system.

You do have as an option the previous discussion for Platform Builder users, if the registry is persistent.

Using a Proprietary System

If you are using a COTS system, the OEM may have a proprietary way for you to start your application.

Windows CE: Monitoring for Disk Insertion to add support for Startup folders

Bruce Eitman — Sat, 14 Jun 2008 02:56:41 GMT

Windows CE supports starting applications in the \Startup folder when Windows Explorer starts, but doesn’t automatically run applications on removable media when the media is inserted. It would be nice to have that ability for some devices, although tread lightly with this if security is an issue.

The following code example demonstrates how to use the Message Queue Point-to-Point functions and Storage Manager API to detect insertion of removable media and then launch exe files found in a Startup folder on the disk.

Header files used by this application

#include <Windows.h>

#include <msgqueue.h>

#include <pnp.h>

#include <storemgr.h>

A global variable for stopping the thread, although this code monitors for this, it does not set this or even have a way to do so. I leave that as an exercise for you. There may also be better ways to do this, like using an event.

static BOOL StopMonitoringForNewDisks = FALSE;

The first task is to monitor for disk insertions. MonitorForNewDisks() does this and when new disks are detected will call HandleNewDisk() . MonitorForNewDisks() uses a message queue and notifications to receive notifications when a new Block driver is detected. The message in the queue will contain the device name of the block driver, example DSK1:, which will be passed to HandleNewDisk().

MonitorForNewDisks() is not interested in disk removal, but that could be added by including an else with the if(pDetail->fAttached).

void MonitorForNewDisks()

{

HANDLE hNotify;

HANDLE *qStore ;

DWORD flags;

DWORD size;

BYTE DevDetail[sizeof(DEVDETAIL) + (MAX_PATH * sizeof( TCHAR ))];

DEVDETAIL * pDetail = (DEVDETAIL *)DevDetail;

MSGQUEUEOPTIONS msgopts;

msgopts.dwSize = sizeof(MSGQUEUEOPTIONS);

msgopts.dwFlags = 0;

msgopts.dwMaxMessages = 0;

msgopts.cbMaxMessage = sizeof(DevDetail);

msgopts.bReadAccess = TRUE;

qStore = CreateMsgQueue(NULL, &msgopts);

hNotify = RequestDeviceNotifications(&BLOCK_DRIVER_GUID, qStore, TRUE);

{

if(WaitForSingleObject(qStore, 5000) == WAIT_OBJECT_0)

{

while(ReadMsgQueue(qStore, pDetail, sizeof(DevDetail), &size, 1, &flags))

{

if(pDetail->fAttached)

HandleNewDisk(pDetail->szName);

}

} while( !StopMonitoringForNewDisks );

StopDeviceNotifications(hNotify);

}

Now we have a been notified that a new disk has been inserted and HandleNewDisk() is called with the device name of the block driver. That is enough information to use OpenStore() to start finding the partition and then the Startup folder.

While working on this, I discovered that we can go from notification to calling OpenStore() quicker than the Store will be available. To handle that, this code loops until the Store can be opened. When the Store cannot be opened this will Sleep for 100 milliseconds to allow the Storage Manager to do its work.

When a Store is opened, this calls on RunStartupFolders() passing the handle to the Store.

void HandleNewDisk( TCHAR *DiskName )

{

HANDLE hStore;

BOOL success = FALSE;

DWORD Count = 600;

{

hStore = OpenStore( DiskName );

if( INVALID_HANDLE_VALUE != hStore )

{

RunStartupFolders( hStore );

CloseHandle( hStore );

success = TRUE;

}

else

{

// When the disk first shows up, it may not be ready

// for us to OpenStore(), so wait a bit then retry

Sleep( 100 );

}

}while( !success && Count--);

}

RunStartupFolders() receives a handle to an open Store and then uses FindFirstPartition() and FindNextPartition() to find the partitions on the Store. When it finds a partition it calls StartExes() to run the applications in the Startup folder.

Again, we can get to this code faster than the partitions can be mounted, so this loops waiting for a valid, mounted partition. I have to be honest the first do/while loop could probably be simplified, but I found this is where I found that the Store might not have been opened (kind of wish that I had added more error handling earlier.)

void RunStartupFolders( HANDLE hStore )

{

HANDLE hFind = INVALID_HANDLE_VALUE;

HANDLE hPartition = INVALID_HANDLE_VALUE;

PARTINFO partInfo = {0};

DWORD Count = 120;

{

Sleep( 500 );

memset( &partInfo, 0, sizeof( partInfo ));

partInfo.cbSize = sizeof(PARTINFO);

hFind = FindFirstPartition(hStore, &partInfo);

if( INVALID_HANDLE_VALUE != hFind )

{

if(PARTITION_ATTRIBUTE_MOUNTED & partInfo.dwAttributes)

break;

else

FindClose(hFind);

}

} while( Count-- );

if(INVALID_HANDLE_VALUE != hFind)

{

if(PARTITION_ATTRIBUTE_MOUNTED & partInfo.dwAttributes)

{

StartExes( partInfo.szVolumeName );

}

}while(FindNextPartition(hFind, &partInfo));

FindClose(hFind);

}

Now the it is time to find the exe files in the Startup folder on the partition. StartExes() receives the name of the partition and uses it to look for exes using FindFirstFile() and FIndNextFile(). Once an exe file has been found call CreateProcess() to start the exe.

void StartExes( TCHAR *PartitionName )

{

WIN32_FIND_DATA a_file;

TCHAR search[MAX_PATH];

TCHAR path[MAX_PATH];

PROCESS_INFORMATION pi;

HANDLE FHandle;

wsprintf( search, TEXT("%s\\Startup\\*.exe"), PartitionName );

FHandle = FindFirstFile(search, &a_file);

if (FHandle != INVALID_HANDLE_VALUE)

{

wsprintf( path, TEXT("%s\\Startup\\%s"), PartitionName, a_file.cFileName );

if (CreateProcess( path, NULL, NULL, NULL, FALSE, 0,NULL, NULL, NULL, &pi))

{

CloseHandle(pi.hProcess);

CloseHandle(pi.hThread);

}

}while (FindNextFile(FHandle, &a_file));

FindClose (FHandle);

}

And of course we need to kick the whole thing off, so here is a WinMain that calls SignalStarted, so that we can use this from HKEY_LOCAL_MACHINE\Init and then calls MonitorForNewDisks().

int WINAPI WinMain( HINSTANCE hInstance,

HINSTANCE hPrevInstance,

LPTSTR lpCmdLine,

int nCmdShow)

{

SignalStarted( _wtol(lpCmdLine) );

MonitorForNewDisks();

}

Now when disks are inserted into the device, applications will automatically run. This can be handy for servicing the device, but comes with some risk. You can mitigate that risk by using a less common folder name or some other method that you determine has more benefit than risk.

The sources file for building this with Platform Builder is fairly simple but included here to document the libraries that will need to be linked to the application.

TARGETNAME=StartupFolders

TARGETTYPE=PROGRAM

EXEENTRY=WinMain

RELEASETYPE=PLATFORM

TARGETLIBS= \

$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib \

$(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\storeapi.lib

SOURCES=\

StartupFolders.c