As I checked the bugs list, at least one bug regarding BiDi support (QC # 97965) is fixed in VCL Styles. No other BiDi related bugs are fixed in this update. Embarcadero staff mentioned in Embarcadero newsgroups that the company is planning to release monthly updates for XE2 product, so we should wait to see if any of the BiDi related bugs will be fixed in the coming updates or not.

The easiest way to enumerate Windows services is using WMI. Of course using WMI requires some basic knowledge of MS COM technology which is tricky, but thanks to the great tool. Delphi WMI Class Generator by Rodrigo Ruz, you can have a ready Delphi class for obtaining information about installed services on a Windows machine without even writing a single line of code. All you have to know is that WMI class for Windows services is Win32_Service under root\CIMV2 namespace. Delphi WMI Class Generator will generate a unit named uWin32_Service.pas which contains a class named TWin32_Service. This class returns info about a single service for you. If you need to enumerate all installed services, you need to write a couple of codes to call its GetCollectionCount to retrieve number of available services, and SetCollectionIndex to set current item index for the class. Here is a sample code to retrieve names of all installed services on the local machine using TWin32_Service class:

var
  i: Integer;
begin
  with TWin32_Service.Create do
  try
    for i := 0 to GetCollectionCount - 1 do
    begin
      Writeln(DisplayName);
      SetCollectionIndex(i);
    end;
  finally
    Free;
  end;
end;

However, WMI is slow, and it relays on WMI service. If you need a faster way to enumerate Windows services, or if for whatever reason WMI service is disabled or not working on your target machine; then you have to relay on Windows API. Using Windows API for this purpose is not as easy as using the automatically generated TWin32_Service class. I am not aware of a single Windows API function that can enumerate Windows services for you and give you all the detailed information which WMI returns for each service. You have to call roughly a dozen of API functions to enumerate Windows services and retrieve some nice information for each service.

First you need to open a handle to service manager on the target machine by calling OpenSCManager function, then you should call EnumServicesStatusEx function to enumerate available services, and retrieve their names and status. If you just need service names and status, you are done, but if you need to retrieve description and configuration for each service too, then you should open a handle for each service using OpenService function by giving it service name which you obtain through EnumServicesStatusEx call , and then call QueryServiceConfig and QueryServiceConfig2 functions to get the required configurations. At the end you should make sure you free all the allocated buffers, and close all handles. Delphi installation does not provide header translation for some of these API functions (particularly EnumServicesStatusEx and QueryServiceConfig2), but they are translated and available for Delphi by well-known Project JEDI, and their JEDI Windows API Headers which contain the majority of Windows headers. If you are a Delphi developer and have not heard about them yet (That would be weird!!), you can download the package from this link.

Anyways, in the source code below, I wrapped all of those API calls into a class named TAkServices. This class holds an internal list containing information for each Windows service installed on a given machine. I tested it on both Delphi 2010 (Win32) and Delphi XE2 (Win64):

{*******************************************************************************
/// <author> Ali Keshavarz (vcldeveloper@gmail.com) </author>
/// <date> 09/13/2011 </date>
/// <license>
///  This work is licensed under the Creative Commons Attribution 3.0 Unported
///  License. To view a copy of this license, visit
///  http://creativecommons.org/licenses/by/3.0/
///  or send a letter to Creative Commons, 171 Second Street, Suite 300,
///  San Francisco, California, 94105, USA.
/// </license>
*******************************************************************************}

unit uAkServices;

interface

uses
 Generics.Collections;

type
 /// Service status values; these items are defined in Windows SDK. For more
 /// info refer to MSDN.
 TAkServiceState = (SERVICE_STOPPED          = $۰۰۰۰۰۰۰۱,
 SERVICE_START_PENDING    = $۰۰۰۰۰۰۰۲,
 SERVICE_STOP_PENDING     = $۰۰۰۰۰۰۰۳,
 SERVICE_RUNNING          = $۰۰۰۰۰۰۰۴,
 SERVICE_CONTINUE_PENDING = $00000005,
 SERVICE_PAUSE_PENDING    = $۰۰۰۰۰۰۰۶,
 SERVICE_PAUSED           = $۰۰۰۰۰۰۰۷ );

 /// Service startup mode values; these items are defined in Windows SDK. For
 /// more info refer to MSDN.
 TAkServiceStartMode = (SERVICE_BOOT_START,
 SERVICE_SYSTEM_START,
 SERVICE_AUTO_START,
 SERVICE_DEMAND_START,
 SERVICE_DISABLED );

 /// <summary>
 /// Service information structure. This structure is used by TAkServiceList
 /// class to save info for each individual service.
 /// </summary>
 TAkServiceInfo = record
 public
 /// A path to service executable file.
 BinaryPath : string;
 /// Current service state.
 CurrentState : TAkServiceState;

 Description : string;
 /// User-friendly name of service
 DisplayName : string;
 /// Service flags. It can be either zero or SERVICE_RUNS_IN_SYSTEM_PROCESS.
 Flags : Integer;
 /// Actual name of service which is also used as service key name in Registry.
 Name : string;
 /// Process identifier for a running service. If the service is not running
 /// or it is running in System process, then ProcessID will be zero.
 ProcessID : Cardinal;
 /// Startup mode of service.
 StartMode : TAkServiceStartMode;
 /// Username by which service logged into system.
 StartName : string;
 end;

 /// Holds a list of TAkServiceInfo reccords as the list of Windows services.
 TAkServiceList = TList<TAkServiceInfo>;

 TAkServiceInfoEnumerator = TEnumerator<TAkServiceInfo>;

 /// <summary>
 /// Provides a list of installed Windows services on a given machine.
 /// </summary>
 TAkServices = class
 private
 FLastUpdateTime : TDateTime;
 FList : TAkServiceList;
 FMachineName : string;
 function GetCount: Integer;
 function GetItem(Index: Integer): TAkServiceInfo;
 procedure GetServiceConfig(hSCManager: Cardinal; var Service: TAkServiceInfo);
 procedure SetMachineName(const Value: string);
 protected
 procedure InitializeList; virtual;
 procedure InternalRefresh; virtual;
 public
 /// <summary>
 /// Constructor for TAkServices.
 /// </summary>
 /// <param name="AMachineName">
 ///  (in) Name of the machine which its services should be listed. Default = ''
 /// </param>
 /// <param name="."></param>
 constructor Create(const AMachineName: string = '');
 destructor Destroy; override;
 function GetEnumerator: TAkServiceInfoEnumerator;
 /// <summary> Updates list of services. </summary>
 procedure Refresh;
 /// <summary>
 /// Indicates number of services. If the list is not updated yet, it will be
 /// updated first.
 /// </summary>
 property Count: Integer read GetCount;
 /// <summary>
 /// Returns item at the Index position of the list of services.
 /// If the list is not updated yet, it will be updated first.
 /// </summary>
 property Item[Index: Integer]: TAkServiceInfo read GetItem; default;
 /// <summary>
 /// Indicates last update time for the list. It will be updated each time
 /// Refresh method is called.
 /// </summary>
 property LastUpdateTime: TDateTime read FLastUpdateTime;
 /// <summary>Name of the machine which its services should be listed. </summary>
 property MachineName: string read FMachineName write SetMachineName;
 end;

implementation

uses
 SysUtils,
 Windows,
 JwaWinNT,
 JwaWinType,
 JwaWinSvc,
 JwaWinError;

{ TAkServices }

constructor TAkServices.Create(const AMachineName: string);
begin
 inherited Create;
 FMachineName := AMachineName;
end;

destructor TAkServices.Destroy;
begin
 System.TMonitor.Enter(Self);
 try
 FList.Free;
 FList := nil;
 finally
 System.TMonitor.Exit(Self);
 end;

 inherited;
end;

function TAkServices.GetCount: Integer;
begin
 InitializeList;
 Result := FList.Count;
end;

function TAkServices.GetEnumerator: TAkServiceInfoEnumerator;
begin
 InitializeList;
 Result := FList.GetEnumerator;
end;

function TAkServices.GetItem(Index: Integer): TAkServiceInfo;
begin
 InitializeList;
 Result := FList[Index];
end;

procedure TAkServices.InitializeList;
begin
 if not Assigned(FList) then
 begin
 System.TMonitor.Enter(Self);
 try
 FList := TAkServiceList.Create;
 InternalRefresh;
 finally
 System.TMonitor.Exit(Self);
 end;
 end;
end;

procedure TAkServices.GetServiceConfig(hSCManager: Cardinal; var Service: TAkServiceInfo);
var
 dwBufNeeded: Cardinal;
 dwBufSize: Cardinal;
 hService : Cardinal;

 /// <summary>
 /// Retrieves service binary path, start mode, and user name.
 /// </summary>
 procedure GetRequiredConfig(var Service: TAkServiceInfo);
 var
 lpServiceConfig : LPQUERY_SERVICE_CONFIG;
 begin
 dwBufSize := 0;
 dwBufNeeded := 0;
 /// Retrieve required buffer size.
 QueryServiceConfig(hService, nil, dwBufSize, dwBufNeeded);
 if GetLastError <> ERROR_INSUFFICIENT_BUFFER then
 RaiseLastOSError;

 /// Alocate enough buffer size.
 dwBufSize := dwBufNeeded;
 lpServiceConfig := AllocMem(dwBufSize);
 try
 /// Get service configuration
 if not QueryServiceConfig(hService, lpServiceConfig, dwBufSize, dwBufNeeded) then
 RaiseLastOSError;

 /// Save configuration data in the record.
 Service.BinaryPath := lpServiceConfig.lpBinaryPathName;
 Service.StartMode := TAkServiceStartMode(lpServiceConfig.dwStartType);
 Service.StartName := lpServiceConfig.lpServiceStartName;
 finally
 FreeMem(lpServiceConfig);
 end;
 end;

 /// <summary>
 /// Retrieves service description.
 /// </summary>
 procedure GetOptionalConfig(var Service: TAkServiceInfo);
 var
 lpServiceDescBuff : LPSERVICE_DESCRIPTION;
 begin
 dwBufSize := 0;
 dwBufNeeded := 0;
 /// Retrieve required buffer size.
 QueryServiceConfig2(hService, SERVICE_CONFIG_DESCRIPTION, nil, dwBufSize, dwBufNeeded);
 if GetLastError <> ERROR_INSUFFICIENT_BUFFER then
 RaiseLastOSError;

 /// Alocate enough buffer size.
 dwBufSize := dwBufNeeded;
 lpServiceDescBuff := AllocMem(dwBufSize);
 try
 /// Retrieve service description
 if not QueryServiceConfig2(hService, SERVICE_CONFIG_DESCRIPTION,
                            PByte(lpServiceDescBuff), dwBufSize, dwBufNeeded) then
   RaiseLastOSError;
  /// Save service description in the record.
  if Assigned(lpServiceDescBuff.lpDescription) then
   SetString(Service.Description,
             lpServiceDescBuff.lpDescription,
             StrLen(lpServiceDescBuff.lpDescription));
   finally
     FreeMem(lpServiceDescBuff);
   end;
 end;

begin
  Assert(hSCManager > 0, 'Service manager is not initialized.');

  /// Open a service handle to be used by QueryServiceConfig() and QueryServiceConfig2() functions.
  hService := OpenService(hSCManager,PChar(Service.Name),SERVICE_QUERY_CONFIG);
  if hService = 0 then
    RaiseLastOSError;
  try
    GetRequiredConfig(Service);
    GetOptionalConfig(Service);
  finally
    CloseServiceHandle(hService);
  end;
end;

procedure TAkServices.InternalRefresh;
var
  dwBufNeeded: Cardinal;
  dwBufSize: Cardinal;
  dwNumOfServices: ULONG;
  hSCM: SC_HANDLE;
  lpResumeHandle: Cardinal;
  NewItem : TAkServiceInfo;
  pBuf: PBYTE;
  pInfo: LPENUM_SERVICE_STATUS_PROCESS;
  i: Integer;
begin
  Assert(Assigned(FList),'Internal list is not assigned yet!');

  System.TMonitor.Enter(FList);
  try
   dwBufSize := 0;
   dwBufNeeded := 0;
   dwNumOfServices := 0;
   lpResumeHandle := 0;
   FList.Clear;

   /// We need an open service manager handle to be able to enumerate services.
   hSCM := OpenSCManager(PChar(FMachineName), nil,
   SC_MANAGER_ENUMERATE_SERVICE or SC_MANAGER_CONNECT);
   if (hSCM = 0) then
     RaiseLastOSError;

   try
     /// First check how much buffer is needed by passing dwBufSize as zero,
     /// and pBuf as nil.
     EnumServicesStatusEx(hSCM, SC_ENUM_PROCESS_INFO, SERVICE_WIN32,
                          SERVICE_STATE_ALL, nil, dwBufSize, dwBufNeeded,
                          dwNumOfServices, lpResumeHandle, nil);
     if (dwBufNeeded < 1) then
       RaiseLastOSError;

     /// Alocate enough space for the buffer.
     dwBufSize := dwBufNeeded;
     pBuf := AllocMem(dwBufSize);
     try
       /// Retrieve services list
       if not EnumServicesStatusEx(hSCM, SC_ENUM_PROCESS_INFO, SERVICE_WIN32,
                                   SERVICE_STATE_ALL, pBuf, dwBufSize, dwBufNeeded,
                                   dwNumOfServices, lpResumeHandle, nil) then
         RaiseLastOSError;

       /// Type casting pBuf to LPENUM_SERVICE_STATUS_PROCESS record is necessary
       ///  so that we can access each service info in the buffer as a record.
       pInfo := LPENUM_SERVICE_STATUS_PROCESS(pBuf);
       /// Write services list
       for i := 0 to dwNumOfServices-1 do
       begin
         NewItem.Name := pInfo.lpServiceName;
         NewItem.DisplayName := pInfo.lpDisplayName;
         NewItem.Flags := pInfo.ServiceStatusProcess.dwServiceFlags;
         NewItem.ProcessID := pInfo.ServiceStatusProcess.dwProcessId;
         NewItem.CurrentState := TAkServiceState(pInfo.ServiceStatusProcess.dwCurrentState);
         GetServiceConfig(hSCM, NewItem);
         FList.Add(NewItem);

         /// Go to next record in the buffer. Compiler will increment pInfo pointer
         ///  according to size LPENUM_SERVICE_STATUS_PROCESS record.
         Inc(pInfo);
       end;
       FLastUpdateTime := Now;
    finally
       FreeMem(pBuf);
    end;
  finally
    CloseServiceHandle(hSCM);
  end;
  finally
     System.TMonitor.Exit(FList);
  end;
end;

procedure TAkServices.Refresh;
begin
 /// If FList is not created yet, InitializeList will create it and calls InternalRefresh
 /// automatically, but if the list is already created, just calling InternalRefresh
 /// is enough.
 if not Assigned(FList) then
 InitializeList
 else
 InternalRefresh;
end;

procedure TAkServices.SetMachineName(const Value: string);
begin
 if not SameText(FMachineName, Value) then
 begin
    FMachineName := Value;
    Refresh;
  end;
end;

end.

Here is also a demo Delphi application using TAkServices class to enumerate Windows services on the local machine, and show them in a ListView control. Download link for the source files (including uAkServices.pas and all required JEDI API header translations) is available at the end of this article:

Demo application in action; enumerating Windows services using Windows API

Download:

Source code plus the demo app

P.S. Oops, it seems my code highlighter is not keen on indentation in longer source codes. If you see the code without proper indentation, you can use this pastebin link to see the source formatted properly, or download the source file. I’m sorry for the inconvenience.

• Added support for Win64 and Delphi XE2.
• Added TProcessItem.CloseProcess method to close a process normally (not forcefully).
• Added TProcessItem.CurrentProcess property. This property always refers to the current process in the list of running processes.
• Added PrivateWorkingSetSize property to TProcessItem.MemoryInfo.
• Added global  ProcessInformation function. This function returns a global instance of TProcessInfo. The instance will be freed when the application is terminating.
• Fixed a few minor bugs.

To download ProcessInfo 1.5, please go to ProcessInfo page.

Parameter modifiers

When you call a function or procedure (I am going to refer to both of them as Functions here), you have to somehow pass the required input or output parameters to it. Parameters are passed to functions either by value, or by reference.

Passing by value means, compiler makes a new copy of the original data, and sends it to the function. This way, the function has its own copy of data, and changing value of the parameter inside the function does not affect the original data. This is the default mode when you pass a parameter to a function in Delphi:

program Test02;

procedure Foo(Param1: Integer);
begin
  Inc(Param1); //=> Has no effect on MyData.
end;

var
  MyData : Integer;
begin
  MyData := 1;
  Foo(MyData);
  Writeln(MyData); //=> MyData is still 1.
end.

Passing by reference means, compiler only sends a pointer to the function. This pointer refers to the original data, so changing value of the parameter inside the function directly changes the original data. In Delphi such parameters are marked with var keyword:

program Test02;

procedure Foo(Var Param1: Integer);
begin
  Inc(Param1);
end;

var
  MyData : Integer;
begin
  MyData := 1;
  Foo(MyData);
  Writeln(MyData); //=> MyData is 2.
end.

These are the two basic ways parameters are passed to functions, but Delphi has still two other modifier keywords for function parameters: const and out. What are these two used for?

“Const” makes the parameter read-only, so that you cannot change its value inside the function. This lets compiler to generate optimized code when there is no need to alter value of that parameter inside the function.

procedure Foo(const Param1: Integer);
begin
  Inc(Param1); // => ERROR! You cannot modify a const parameter.
end;

“Out” is similar to “var”, the difference is, when you use “Out” the initial value of the parameter is discarded inside the function, and it does not matter. What matters is the value you assign to that parameter inside your function. “Out” is basically there to support MS COM method declaration in Delphi. You can use it in any function you write, but you will see lots of COM methods having Out parameters in their declaration.

OK, the purpose of Const and Out modifiers are clear, it can be guessed even from their name which represent Constant and Output; but, to which category do they belong?

Are “Out” and “Const” passed by value or by reference?

For “out”, as I mentioned above, it acts similar to “var”, so it passes parameters by reference.

How about “Const’? Const acts somehow differently! It passes parameters usually by value, but it passes certain data types by reference too! Which data types are passed by value, and which ones are passed by reference? To clarify this, I wrote a simple program; it shows address of a parameter passed to a function using the default passing (by value), var modifier (by reference), and const modifier. It repeats this for various data types, to show how these modifiers pass different data types to a function. The source code is attached at the end of this post. Here is a screenshot of this sample program:

For each data type, “Original:” line indicates address of the original data before being passed to the function. “Value:” line indicates address of the parameter passed to the function by value. “Const:” line indicates address of the parameter passed to the function as a constant. And finally, “var:” line indicates address of the parameter passed to the function by reference.

As you can see, for all data types, address of var parameter is the same as address of the original data, and address of value parameter (passed by value) differs from the original data. Therefore, we can conclude passing a parameter by value, always makes a copy of the original data; and passing a parameter with var modifier always refers to the original data, regardless of the data type which is used.

But for constant parameters, we can see that it always passes the parameter by value, except when the parameter is of array type (static arrays and open arrays, not dynamic arrays; dynamic arrays are passed similar to objects), or record type. It means, if you do not specify a modifier for a parameter of type array (not dynamic arrays) or records, then every time your function is called, the whole data inside that array or record will be pushed into stack, and when the execution of your function is over, it is dismissed! On the other hand, when you use Const or Var modifiers, only a pointer to your record or array is passed to the function, so there is no need to copy the whole data of the array or record.

Now you might ask, if the compiler is smart enough to optimize array and record parameters when Var or Const modifiers are used, then why doesn’t it use the same optimization for objects, interfaces, strings, or dynamic arrays?! The answer is: Because those are special data types!

Objects, Interfaces, Strings, and Dynamic Arrays as parameters

Objects, interfaces, strings, and dynamic arrays are behind the scene just pointers. They do not contain the real data. They are pointers that refer to the real data. That’s why if you call SizeOf() function on a string or object type, even if your string or object contains huge data; the result is always 4 (as long as Delphi compiler is 32-bits)! SizeOf() function only returns the size of that pointer, not size of the data that pointer refers to. Also that is why we have Length() function for getting size of strings and dynamic arrays, and TObject.InstanceSize class method for getting size of an object.

Hence, for data types as objects, interfaces, strings, or dynamic arrays; we can say practically they are always passed by reference, even if no modifier is specified for them. So the code bellow directly affects StringList variable, and there is no local copy of that object inside Foo:

program Test03

uses Classes;

procedure Foo(Param1: TStrings);
begin
  Param1.Add(‘۱۲۳۴’); //=> This will directly add a new item to StringList.
end;

var
  StringList : TStringList;
begin
  StringList : TStringList.Create;
  try
    Foo(StringList);
    WriteLn(StringList.Text); //=> Writes ‘۱۲۳۴’.
  finally
    StringList.Free;
  end;
end.

Using var modifier on objects, interfaces or dynamic arrays is most of the time unnecessary, because the value itself is a reference, so using var means having a reference to another reference!

Also Const modifier has no particular meaning on objects, interfaces or dynamic arrays, because it only locks the pointer behind the scene, not the data structure to which the pointer is referring. So if we change declaration of Foo() in the code above to this:

procedure Foo(const Param1: TStrings);

We will get the same result as the above code.

However, const and var modifiers have meaning for string types! This is because strings are a special auto-managed data types in Delphi.

Strings, Dynamic Arrays, and Interfaces are referenced counted:

Strings and dynamic arrays are both reference-counted. Interfaces in Delphi also provide reference-counting support). Reference-counted types are automatically handled by Delphi runtime. When you define a string variable in Delphi and assign it a value, you will have a data structure containing your text, and a reference-counter value which is set to 1:

var
 A : string;
begin
  A := ‘Test’; // Memory is allocated for A
                  // on the heap, and reference
                  // counter is set to 1.
end;

Now if you change the above code to this:

var
  A, B : string;
begin
  A := ‘Test’; // Memory is allocated for A
                  // on the heap, and reference
                  // counter is set to 1.
  B := A;      // Reference count for the data
                 // structure referred by A is incremented to 2.
end;

Value of A is not copied to B, instead of that, B refers to the same data structure as A, and reference counter of that data structure is set to 2. As soon as any of those variables goes out of scope, reference counter of that data structure would be decremented, and when reference counter reaches down to zero, the data structure would be automatically freed. This mechanism is the same for strings and dynamic arrays. For interfaces, the class which implements the interface should implement three methods defined inside IInterface to provide reference-counting support.

Strings use Copy-On-Write technique:

The biggest reason why Const and Var modifiers are meaningful to string types is their copy-on-write feature. To explain this, I had to explain reference-counting in brief. Now please take a look at this example:

var
  A, B : string;
begin
  A := ‘Test’; // Memory is allocated for A
                  // on the heap, and reference
                  // counter is set to 1.
  B := A;      // Reference count for the data
                 // structure referred by A is incremented to 2.
  B := B + ‘er’;   // B = Tester , A = Test
end;

This is the same as the previous sample code, with one extra line. In the last line, we add ‘er’ to variable B. That will result in B referring to “Tester”, not “Test” anymore. How is it done? A and B were both referring to a data structure containing “Test”. Then we decided to modify B. Delphi runtime assigns a new data structure, and copies the string “Test” and the string “er” to it. It also decrements reference-counter of original “Test”, and changes B to refer to the new data structure. It also increments reference-counter of the new data structure. So at the end, we have A which refers to the old data structure, and B which refers to the new data structure. Reference-counters of both data structures are 1 now.

This is called copy-on-write; as long as there is no modification, there is no need to do the costly copy operation and waste the memory. Delphi waits until a modification is requested, at that time, it does the actual copy operation.

Please take note, this mechanism does not exist for dynamic arrays, so if A and B in the code above were dynamic arrays, changing B would have affected A too.

So, how does a string parameter work?

When a string parameter is defined with no modifier, it is sent to the function as a reference to the actual data, but its reference-counter would be incremented when entering the function, and decremented when exiting the function. If a modification is done on the string parameter, then a new local string variable would be created inside the function, and the original value of the parameter would be copied to it (Copy-on-write operation). The change would be reflected on the local string variable. This local string variable would be released when execution of the function is over.

When a string parameter is defined as a constant, compiler is sure that the string cannot be modified inside the function, therefore, there is no need for it to add codes for automatic incrementing and decrementing of the reference-counter.

When a string parameter is defined with var modifier, then it is sent to the function as a reference to the actual data. When value of the parameter is changed, then the original data would be copied to a new memory location, and the modification would be applied to it in the new memory location:

program Test04;

procedure Test(var Param: string);
begin
  Param := Param + Param;
end;

var
  A, B : string;
begin
  A := 'Test';
  B := A;
  Test(A);
  Writeln(A); //=> A is modifed and is now “TestTest”
  Writeln(B); //=> B still refers to “Test”
end.

Now back to the original question:

When should we use Const modifier for parameters?

1. Whenever you have a parameter of type array or record, and you do not need to modify it inside your function; define it as a constant parameter to prevent expensive copy operation of array elements every time your function is called.
2. Whenever you have a parameter of type string or dynamic array, and you do not need to modify it inside your function, define it as a constant parameter to prevent compiler from generating protecting code to keep track of the reference-counter. When you do not use const modifier in such cases, compiler would add a hidden try-finally block to your function which contains code for keeping track of reference-counter for your string or dynamic array parameter. This would affect performance of your code. To read more about the impact of this, and see how much code compiler would produce in that case, you can read Eric Grange’s post on this.

Important Note: For the second recommendation above to work, you have to set “String format checking” in your project option to False. This option adds that protective try-finally block to your functions whether you define your string or dynamic array as const or not! This is for backward compatibility with some old C++ Builder codes. If you are not a C++ Builder developer, or are a C++ Builder developer, but do not have such old codes, then you MUST set this option to False in your projects. It reduces performance of strings in Delphi.

OK, I hope this post is clarifying function parameter modifiers and their effects in Delphi programming; specially answering the question of when to use Const modifier. You can download source code and binary file of Function Parameters Type Demo from here.

Have Fun!

ProcessInfo 1.3 is released. The changes in this release are:

• CPU usage is added to TProcessItem.
• Is64Bit is added to TProcessItem.
• IsAccessible is added to TProcessItem.
• Setting thread priority is added to TThreadItem.
• Setting process base priority class is added to TProcessItem.

To download ProcessInfo 1.3, please go to ProcessInfo page.

Q1: How can we find a module which is running a specific thread, giving a thread ID:

A: First of all, Threads are not assigned to modules, they are assigned to processes. You can find a process which is running the thread, by searching in the list of threads owned by each running process. Here is a sample code:

function FindProcessByThreadID(ID: Cardinal): TProcessItem;
var
  ProcessInfo : TProcessInfo;
  AProcess : TProcessItem;
begin
  Result := nil;
  ProcessInfo := TProcessInfo.Create(nil);
  try
    for AProcess in ProcessInfo.RunningProcesses do
    begin
      if Assigned(AProcess.Threads.FindByID(ID)) then
      begin
        Result := AProcess;
        Exit;
      end;
    end;
  finally
    ProcessInfo.Free;
  end;
end;

FindProcessByThreadID iterates over all running processes, and checks which of them has a thread with the given ID. If a process owns a thread with that ID, it will return that process as a TProcessItem object.

Once you have the process object, you can get more information about the process or the specific thread, or you can kill the process, or suspend the thread. For example:

var
  Process : TProcessItem;
begin
  Process := FindProcessByThreadID(StrToInt(3444));
  if Assigned(Process) then
    ShowMessage(Process.FullPath);
end;

The above code looks for a thread with its ID = 3444, and if it is found, it provides full path of the EXE file for that process.

Q2: How can we get memory consumption for a given process?

A: You can read memory info for a given process using TProcessItem.MemoryInfo. It provides different info about the memory the process is consuming. Here is an example for reading memory info of Google Chrome process while it is running :

var
  ProcessInfo : TProcessInfo;
  AProcess : TProcessItem;
begin
  ProcessInfo := TProcessInfo.Create(nil);
  try
    AProcess := ProcessInfo.RunningProcesses.FindByName('Chrome.exe');
    if Assigned(AProcess) then
      ShowMessage(Format('WorkingSet Size = %d, Peak WorkingSet Size = %d',
                         [AProcess.MemoryInfo.WorkingSetSize,
                          AProcess.MemoryInfo.PeakWorkingSetSize]));
  finally
    ProcessInfo.Free;
  end;
end;

First we search for Chrome.exe process among running processes. Once the process is found, we read its current working set size, and pick working set size through MemoryInfo property, and show them in a message box. The values returned are in Bytes.

Q3: How can we get process base priority class or change it?

A: You can access base priority class for a given process or modify it (added in version 1.3), using TProcessItem.

PriorityClassBase. Be careful, adjusting a base priority class of a given process inappropriately might make other processes unresponsive! Here is a example code:

var
  ProcessInfo : TProcessInfo;
  AProcess : TProcessItem;
begin
  ProcessInfo := TProcessInfo.Create(nil);
  try
    AProcess := ProcessInfo.RunningProcesses.FindByName('firefox.exe');
    if Assigned(AProcess) then
      AProcess.PriorityClassBase := BELOW_NORMAL_PRIORITY_CLASS;
  finally
    ProcessInfo.Free;
  end;
end;

You can also change each priority of  each thread within a process by setting BasePriority property of that TThreadItem instace.

Q4: How can I check if a process is 64-bit?

A: You can check this by reading TProcessItem.Is64Bits property.

Q5: How can I get CPU usage for a given process?

A: You can get CPU usage by reading TProcessItem.CPUUsage property.

I hope these few answers and sample source codes can help you use Process Info. For other examples of using Process Info, please refer to this post: How to use TProcessInfo

If there is any question regarding using Process Info, or anything about Delphi that you think worth being mentioned in Tips & Tricks section of this website, please contact me, and let me know about it.

Have Fun!

ProcessInfo 1.2 is released. The changes in this release are:

• SuspendThread, ResumeThread, TerminateThread methods are added to TThreadItem class. Now you can pause/resume/terminate any running thread in a given process.
• TProcessInfo.Active and TAppInfo.Active are published properties, and can be set in design mode.
• TProcessInfo.RunningProcesses and TAppInfo.RunningApplications automatically populate the corresponding list if UpdateList method is not called yet. This means even if you don’t activate any of these two components, or call their UpdateList method, accessing RunningProcesses or RunningApplications does not cause Access Violation.

To download ProcessInfo 1.2, please go to ProcessInfo page.

Regards.

This toolbar provides a nice search box which is able to filter components in the palette based on the search phrase. This toolbar is disabled by default, and is shown when Classic Layout is selected. Here you can see a snapshot of Classic Layout in RAD Studio 2010:

A few weeks ago while I was working with Delphi 2010, I noticed a delay when switching from code view to form designer. The delay was there not only in the complex forms, but also in simple empty forms! It was not a big delay (about 1 second), but since I had to switch between code and form designer view many times, it was really annoying, so I decided to investigate it and find out what is causing this delay.

At first I got suspected to CnPack toolbars in form designer and code view, so I disabled them, but it had no effect on the delay!  Then I went for SysInternals Process Monitor to monitor RAD Studio while switching from code view to form designer. There were many Registry activities regarding to component toolbar. At that time I was thinking about standard Tool Palette in RAD Studio 2010, not the classic component toolbar, because I was not using classic layout.

I tried to hide Tool Palette to see if it fixes the delay, but it didn’t! So I decided to disable its IDE package and see if it fixes the issue. While I was looking into the list of IDE packages in Registry, I found Component Toolbar Package, and I thought this is the package corresponding to Tool Palette. So I removed it from the list of known IDE packages, and restarted RAD Studio 2010; the Tool Palette was still there, BUT the switching delay was gone!

I was wondering if Component Toolbar was not related

to Tool Palette, then what was it related to?! Suddenly I remembered the new classic component toolbar, and switched to Classic Layout. Yes, it was the new classic component toolbar which was using Component Toolbar Package!

Since I don’t use classic view, I simply disabled this IDE package to have a faster switch time from code view to form designer. But still it is weird why this toolbar is being update even when it is not being visible, and why it is making switching from code view to form designer slower. This is definitely a bug in RAD Studio 2010.

How to disable an IDE package:

Here is how you can disable Component Toolbar Package from Registry:

1- Go to HKEY_CURRENT_USER\Software\CodeGear\BDS\7.0\Known IDE Packages.

2- Make a backup by right-clicking on “Known IDE Packages” key, and selecting  Export.

3- Find “$(BDS)\bin\comptoolbar140.bpl” value in “Known IDE Packages” key, and delete it.

4- Run RAD Studio 2010.

Regards

I released a new version of ProcessInfo. In this release I added these features:

• Enumerators are added for Windows, Threads, Modules, and Processes; Now you can use for-in statements in D2007 and above for iterating on running processes list, or modules\threads\windows of a given process.
• TProcessItem.UserName is added; This property returns domain name\user name which is running the process.
• TProocessInfo.AdjustDebugPrivilage is added; This method is called automatically.
  TThreadItem.ToString & TProcessItem.ToString are added; TThreadItem.ToString returns ThreadID. TProcess.ToString returns process EXE name.
• Now supports Delphi 7,2007,2009, 2010; Some conditional compiler directives are added so that it can be used in D7, 2007, 2009, and 2010. I tested it in D7, 2009, and 2010. It should work in D2007 too.

To download ProcessInfo 1.1, please go to ProcessInfo page.

Regards.

I thought maybe it is a good idea to talk about these components and some of their usages by providing some sample source codes. So I will start with TProcessInfo.

Updating running processes list automatically

TProcessInfo has an internal timer which can update processes list automatically. This timer is controlled by Active, and UpdateInterval properties. Active activates the internal timer, and UpdateInterval specifies update interval. The default value for UpdateInterval is 1000 (1 second).

To update the list manually, and not using the internal timer, you can call UpdateList method.

OnBeforeUpdate and OnAfterUpdate

TProcessInfo has two events. They both are invoked when UpdateList is called, either automatically by internal timer or manually by the programmer.

OnBeforeUpdate is invoked just before updating the list. It has a Cancel parameter which lets you to cancel updating. OnAfterUpdate is invoked when the list is updated. So if you have a control (e.g. a list view) that should show processes list, you can write its updating code in the event-handler of OnAfterUpdate.

Finding a running process

You can iterate over all running processes to find a specific process with specific characteristics, or use FindByID, and FindByName methods to find a process by its Process ID or Process Name:

var
  Process : TProcessItem;
begin
  Process := ProcessInfo1.RunningProcesses.FindByID(1234);
  if not Assigned(Process) then
    ShowMessage('No process found');
end;

Finding a process by its Process ID.

var
  Process : TProcessItem;
begin
  Process := ProcessInfo1.RunningProcesses.FindByName('Project3.exe');
  if not Assigned(Process) then
    ShowMessage('No process found');
end;

Finding a process by its Process Name.

var
  I: Integer;
  MemSize,
  MaxMemSize : Cardinal;
  ProcessName : string;
begin
  MaxMemSize := 0;
  for I := 0 to ProcessInfo1.RunningProcesses.Count - 1 do
  begin
    MemSize := ProcessInfo1.RunningProcesses[i].MemoryInfo.WorkingSetSize;
    if MemSize > MaxMemSize then
    begin
      MaxMemSize := MemSize;
      ProcessName := ProcessInfo1.RunningProcesses[i].ExeFile;
    end;
  end;
  ShowMessage(ProcessName + ‘uses more memory than other processes.’);
end; 

Finding the process which consumes more memory than others.

Terminating a running process

To terminate a running process, you should first find it in the list of running processes, and then call its TerminateProcess method:

 var
  Process : TProcessItem;
begin
  Process := ProcessInfo1.RunningProcesses.FindByName('notepad.exe');
  if Assigned(Process) then
    Process.TerminateProcess;
end;

Retrieving full path of a process

 var
  Process : TProcessItem;
begin
  Process := ProcessInfo1.RunningProcesses.FindByName('notepad.exe');
  if Assigned(Process) then
    ShowMessage(Process.FullPath);
end;

Listing modules which a process loaded

 var
  Process : TProcessItem;
  I: Integer;
begin
  Process := ProcessInfo1.RunningProcesses.FindByName('Project1.exe');
  if  Assigned(Process) then
  begin
    for I := 0 to Process.Modules.Count - 1 do
      Memo1.Lines.Add(Format('%d  : %s',[Process.Modules[i].BaseAddress,
                                         Process.Modules[i].ModuleName]));
  end;
end;

You can access other information about a process (e.g. Threads list, threads count, memory consumption, and so on) in the same way.
TAppInfo works very similar to TProcessInfo. I will try to explain it more with some examples in another article.