You may read on if you ever wanted to…

1. have this cool progress bar feature in the taskbar.
2. have an overlay icon onto your application’s icon in the taskbar.
3. multiple tabs for each window or control of your application in the taskbar.
4. have thumb buttons inside the preview of your form (like the Windows MediaPlayer).

You want your application to look like that?

Are you using Windows 7? What a lucky (wo)man you are.

The guys from TheUnknownOnes just released some components to use the new features introduced in Windows 7. 
Of course, these components are based on the JEDI Windows API. At the moment (until the next release of JWAPI), you’ll have to checkout the trunk of the JWAPI in order to get the code compiled.
To get these components, checkout the source out of their svn repository.

And if you want to discuss something about them in German: use this thread.

A first short demo was published here. Stay tuned for some more.

At first I thought that it was a problem with the OpenKey function of TRegistry. However, this was already confirmed and fixed as a bug in QC# 23429.

Then I wanted to check the real error value of DeleteKey. Of course, it just returns true or false, so I added a call to GetLastError. And it returned 87 (Invalid Parameter). It must be said that using GetLastError in a framework like VCL is always a problem because you don’t really know how many winapi functions are called subsequent to the actual winapi function. So you may get an error value from another random function. This is one reason I’m using exceptions in JWSCL, btw.
A quick step through debugging session (you have to enable debug dcu in project options and rebuild the project) confirmed that the invalid parameter error (87) came from RegDeleteKey. But why 87? The next step was obvious because I had a windows function and thus I would have to read its MSDN documentation.

It reads:

Tandy also mentions the competitor Borland with its famous Turbo Pascal (that I also used) and how it got Bill Gates to tremble.

At $50 for the Borland product vs. the Microsoft $400 compiler, it was a bit like comparing a VW to a Porsche. But while Turbo Pascal was lighter weight for serious development, it was almost as quick for programming and debugging as Microsoft’s BASIC interpreters

I wonder if the comment about the speed is true?

And did you know that Microsoft had been using the language Pascal for their projects until they developed C ?

Read more about The Secret Origin of Windows

WinAPI

uses
  SysUtils,
  //JwaWindows, //Use either JwaWindows or these JEDI headers:
  JwaWinBase,
  JwaWinType,
  JwaWinNT,
  JwaAclApi,
  JwaAccCtrl,
  JwaWinError,
  JwaSddl;

type
  TOwnerResult = (orNone, orName, orSID);

function GetFileOwner(const FileName: string;
  out Domain, Username: String): TOwnerResult;
var
  pSD: PSecurityDescriptor;
  dwOwnerNameSize, dwDomainNameSize: DWORD;
  pOwnerSID: PSID;
  pszOwnerName, pszDomainName: PChar;
  OwnerType: SID_NAME_USE;
  dwError : DWORD;
begin
  result := orNone;

  pSD := nil;
  dwError := GetNamedSecurityInfo(
     PChar(FileName),//__in       LPTSTR pObjectName,
     SE_FILE_OBJECT,//__in       SE_OBJECT_TYPE ObjectType,
     OWNER_SECURITY_INFORMATION,//__in       SECURITY_INFORMATION SecurityInfo,
     @pOwnerSID,//__out_opt  PSID *ppsidOwner,
     nil,//__out_opt  PSID *ppsidGroup,
     nil,//__out_opt  PACL *ppDacl,
     nil,//__out_opt  PACL *ppSacl,
     pSD//__out_opt  PSECURITY_DESCRIPTOR *ppSecurityDescriptor
   );
  if (dwError <> NOERROR) then
  begin
    SetLastError(dwError);
    RaiseLastOSError;
  end;

  //First get necessary memory size for Owner and Domain
  dwOwnerNameSize  := 0;
  dwDomainNameSize := 0;
  if not LookupAccountSID(nil, pOwnerSID, nil,
    dwOwnerNameSize, nil, dwDomainNameSize, OwnerType) then
  begin
    //Check for SIDs that are unknown on this local system
    if (GetLastError() = ERROR_NONE_MAPPED) then
    begin
      Win32Check(ConvertSidToStringSid(pOwnerSID, pszOwnerName));
      Domain := '';
      Username := pszOwnerName;
      LocalFree(HLOCAL(pszOwnerName));
      result := orSID;
      exit;
    end
    else
    //Any other error exits the function
    if (GetLastError() <> ERROR_INSUFFICIENT_BUFFER) then
      RaiseLastOsError;
  end;

  //Allocate memory for owner and domain
  //Take into account the size of a char type (like WideCHAR)
  GetMem(pszOwnerName, dwOwnerNameSize*sizeof(CHAR));
  try
    GetMem(pszDomainName, dwDomainNameSize*sizeof(CHAR));
    try
      //Retrieve name and domain
      Win32Check(LookupAccountSID(nil, pOwnerSID, pszOwnerName,
        dwOwnerNameSize, pszDomainName, dwDomainNameSize, OwnerType));

      result := orName;

      Domain   := pszDomainName;
      Username := pszOwnerName;
    finally
      FreeMem(pszDomainName);
    end;
  finally
    FreeMem(pszOwnerName);
  end;
end;

The function behaves the following:

• If an WinAPI error occurs the exception EOSError is thrown. You can retrieve the error value from its property Errorcode.
• If the user name could be retrieved the result value is orName and both parameter Domain and UserName contain a value. Otherwise the result is orSID and only UserName contains the User Security Identifier (e.g. S-1-5-21-564352346-2735467565-567745764-1001).

JWSCL

Of course, JWSCL wraps these function calls already. Thus the source size decreases rapidly. See another example here.
In JWSCL it is quite different to implement the function. However the behaviour is equal:

function JwsclGetFileOwner(const FileName: string;
  out Domain, Username: String): TOwnerResult;
var
  F : TJwSecureFileObject;
  Owner : TJwSecurityId;
begin
  F := TJwSecureFileObject.Create(FileName);
  try
    Owner := F.Owner; //Owner is cached/freed by TJwSecureFileObject
    try
      Domain := Owner.GetAccountDomainName();
      Username := Owner.GetAccountName();
      Result := orName;
    except
      on E : EJwsclWinCallFailedException do
      begin
        if E.LastError = ERROR_NONE_MAPPED then
        begin
          Domain := '';
          Username := Owner.StringSID;
          Result := orSID;
        end
        else
          raise;
      end;
    end;
  finally
    F.Free;
  end;
end;

In a next version of JWSCL (currently trunk) the exception handling will be a little bit different:

function JwsclGetFileOwner2(const FileName: string;
  out Domain, Username: String): TOwnerResult;
var
  F : TJwSecureFileObject;
  Owner : TJwSecurityId;
begin
  F := TJwSecureFileObject.Create(FileName);
  try
    Owner := F.Owner; //Owner is cached/freed by TJwSecureFileObject
    try
      Domain := Owner.GetAccountDomainName();
      Username := Owner.GetAccountName();
      Result := orName;
    except
      on E : EJwsclSidNotMappedException do //not mapped error is handled differently
      begin
        Domain := '';
        Username := Owner.StringSID;
        Result := orSID;
      end;
    end;
  finally
    F.Free;
  end;
end;

If you use JWSCL (Version >= 0.9.2a) and enable the compiler switch JWSCL_SIDCACHE in file Include\Jwscl.inc, JWSCL will add a SID cache (for all TJwSecurityID instances globally). In this way LookupAccountSid will be called only once for every unknown SID and thus SIDs that were already translated are retrieved from cache instead.

The ACTRL_ACCESS structure is used by the interface method IAccessControl::GetAllAccessRights (and others) which is rather hard to implement yourself because the structure must be created in a single block of memory that can be freed by CoTaskMemFree.

So here is how it looks like

ACTRL_ACCESS design diagram

Luckily, JWSCL will provide an implementation of IAccessControl so don’t worry.

What have we learned from the article?

1. Avoid version checks at all
2. Check for functionality
3. Use the right functions
4. Learn logic

1. It is always frustrating if an application doesn’t start because of version checking.

If you have a Win32API function that is not available on older OS, do not use a version check. If you don’t dive the internal structures of Window it is very likely that your application will work.

2. Instead: try to load the function with GetProcAddress. If it fails, well then use something else.

That is the reason why I tell people to set the DYNAMIC_LINK compiler switch when using any of the JEDI functions. In this case the JEDI API libraries loads a function using GetProcedureAddress (located in JwaWinTypes – don’t ask me why it is located there).
GetProcedureAddress can raise two types of Exception.

• EJwaLoadLibraryError : If a necessary library could not be found.
• EJwaGetProcAddressError : If the function could not be located in the library.

So now it is easy to write an exception handler:

try
  API_Call(...);
except
  on E1 : EJwaLoadLibraryError do
    //fail safe library not found
  on E2 : EJwaGetProcAddressError do
   //fail safe function not found
end;

Well, this code only works if you define DYNAMIC_LINK in your project options. Don’t forget it! If it is not defined, and you try to run your application on an older Windows, it just won’t start. Instead you get a nasty error message.

Delphi 2010 comes with a new feature that MS Visual C++ people know as Linker support for Delay-loaded DLLs.
Allen Bauer posted an article about this new feature for Delphi under the strange headline Procrastinators Unite… Eventually! You can also think of it as “Delay loaded functions for Delphi”.

function NewAPIFunction(Parameter : TParameter): BOOL; stdcall;
  external 'user32.dll' name 'NewAPIFunction' delayed;
...

begin
  NewAPIFunction(Parameter);
end;

Do you recognize the new word “delayed” ? If you try to access the function for the first time, it will be loaded automatically from the library “user32.dll”. So we don’t have to be afraid of running the application on an older Windows version. Unfortunately, we also have to add code that checks for the Windows version.

begin
  if OSVersion > 5.1 then
    NewAPIFunction(Parameter);
end;

(Don’t be confused about GreaterThan. There is a bug in the code plugin that prevents the greater sign to be shown correctly.)

Haven’t we learned that it is not good to check for the OS version? Shouldn’t we check for functionality? Apparently, delay loading in Delphi 2010 wasn’t created with this idea in mind.
If we change the library name or the function name to something incorrect, like:

function NewAPIFunction(Parameter : TParameter): BOOL; stdcall;
  external 'user32Bla.dll' name 'NewAPIFunction' delayed;
...

begin
  NewAPIFunction(Parameter);
end;

…and call this function, at least, I get a nasty EExternalException with the message “External Exception C0FB007E“.
Even using the correct library but an incorrect function name doesn’t change the exception type, but the message :
“External Exception C0FB007F“.

Well, It could have been so nice! And in Update 2 we’re going to see how…

function NewAPIFunction(Parameter : TParameter): BOOL; stdcall;
  external 'user32.dll' name 'NewAPIFunction' delayed;
...

begin
  try
    NewAPIFunction(Parameter);
  on E1 : ELoadLibraryError do
    //fail safe library not found
  on E2 : EGetProcAddressError do
   //fail safe function not found
end;

Instead we need to check:

function NewAPIFunction(Parameter : TParameter): BOOL; stdcall;
  external 'user32.dll' name 'NewAPIFunction' delayed;
...

begin
  try
    NewAPIFunction(Parameter);
  on E : EExternalException do
    //failsafe
end;

However, I wouldn’t even be sure that this exception type is always the same. EExternalException is always suspect to me, isn’t it? So in the end it is all about Exception.

UPDATE

I was so short sighted! To the COM people C0FB007E should look quite familiar. Yeah, it is a HRESULT code. It maps to

Severity (ERROR_SEVERITY_ERROR = $C) + Facility Code ($FB) + Code (7E and 7F)

Well $7E is 126 in decimal and can be found in JwaWinError.pas as ERROR_MOD_NOT_FOUND. Same goes for $7F =127 which is ERROR_PROC_NOT_FOUND.

Knowing this we can use:

begin
  try
    NewAPIFunction(Parameter);
  on E : EExternalException do
     RaiseLastOSError(Windows.HResultCode(E.ExceptionRecord.ExceptionCode));
  end;
end;

This exception should be known to Delphi programmers. And you can add another try except block around to catch the Win32 exception.

The exception EExternalException comes from an internal call to RaiseException.

UPDATE2:

If you read the system.pas file from Delphi 2010 you’ll find the function SetDliFailureHook. It allows us to get notified when an delayed loading error occured. So how does it look?

uses
  Windows,
  SysUtils;

type
  ELoadLibraryError = class(EWin32Error);
  EGetProcAddressError = class(EWin32Error);

function DelayedFailureHook(dliNotify: dliNotification; pdli: PDelayLoadInfo): Pointer; stdcall;
begin
  case dliNotify of
    dliNoteStartProcessing: ;
    dliNotePreLoadLibrary: ;
    dliNotePreGetProcAddress: ;
    dliFailLoadLibrary   :
      raise ELoadLibraryError.CreateFmt(
        'Failed to load library "%0:s".'#13#10' Error (%1:d) %2:s',[AnsiString(pdli.szDll),
          pdli.dwLastError, SysErrorMessage(pdli.dwLastError)]);
    dliFailGetProcAddress:
      if pdli.dlp.fImportByName then
        raise EGetProcAddressError.CreateFmt(
            'Failed to load function "%0:s" from "%1:s"'#13#10' Error (%2:d) %3:s',[
           AnsiString(pdli.dlp.szProcName), AnsiString(pdli.szDll),
          pdli.dwLastError, SysErrorMessage(pdli.dwLastError)])
      else
        raise EGetProcAddressError.CreateFmt(
            'Failed to load function #%0:d from "%1:s"'#13#10' Error (%2:d) %3:s',[
           pdli.dlp.dwOrdinal, AnsiString(pdli.szDll),
          pdli.dwLastError, SysErrorMessage(pdli.dwLastError)]);

    dliNoteEndProcessing: ;
  end;
end;

...
begin
  SetDliFailureHook(DelayedFailureHook);

  try
    NewAPIFunction(Parameter);
  on E1 : ELoadLibraryError do
    //fail safe library not found
  on E2 : EGetProcAddressError do
   //fail safe function not found
  end;
end.

All the other errors we don’t process are converted to an EExternalException error automatically. You can try it out by removing the case dliFailLoadLibrary or dliFailGetProcAddress.

By the way:

1. The function pointer of NewAPIFunction is not nil. It points to an address that does the magic behind the curtain.
2. If you wonder why the JEDI Windows API hasn’t implemented this feature: We are still in pre alpha stage.
   You could help by telling us your experience with this feature.

3. Using the right functions can be a bit problematic. There are a lot of possible functions you can use:

1. JwaWinBase/Windows contains GetVersion and GetVersionEx
2. There is also a more complex function called VerifyVersionInfo(Ex)
3. And Delphi comes with a function of its own in SysUtils : CheckWin32Version

CheckWin32Version is little known to Delphi programmers. Instead they create their own complicated classes and tool functions. But if you just want to check for the major and minor version of the OS, try this:

if CheckWin32Version(5, 1) then

It checks for Windows XP regardless of a service pack. It is the easiest and safest way to check the OS version. But sometimes you need also to know the service pack or even more.

GetVersion and GetVersionEx can be hard to be used. So Microsoft added support for a more flexible and safe way to check the OS version. VerifyVersionInfo was born.

I have translated Yochay Kiriaty’s example of VerifyVersionInfo for you.

uses
  JwaWinNT,
  JwaNative,
  JwaWinBase;

function IsWindowsXPorLater : Boolean;
const
  Condition = VER_GREATER_EQUAL;
var
  OSInfo : TOSVersionInfoEx;
  ConditionMask : Int64;
begin
  ZeroMemory(@OsInfo, sizeof(OSInfo));
  OSInfo.dwOSVersionInfoSize := SizeOf(OSInfo);
  OSInfo.dwMajorVersion := 5;
  OSInfo.dwMinorVersion := 1;
  OSInfo.wServicePackMajor := 1;
  OSInfo.wServicePackMinor := 0;

  ConditionMask := 0;
  ConditionMask := VerSetConditionMask(ConditionMask, VER_MAJORVERSION, Condition);
  ConditionMask := VerSetConditionMask(ConditionMask, VER_MINORVERSION, Condition);
  ConditionMask := VerSetConditionMask(ConditionMask, VER_SERVICEPACKMAJOR, Condition);
  ConditionMask := VerSetConditionMask(ConditionMask, VER_SERVICEPACKMINOR, Condition);

  result := VerifyVersionInfo(OSInfo, VER_MAJORVERSION or VER_MINORVERSION or
     VER_SERVICEPACKMAJOR or VER_SERVICEPACKMINOR,
     ConditionMask);
end;

I hope more people are going to use this function.

4. In the end I also want to write something about logic.

If you wonder why so many applications ceased to work when Windows Vista came out. Well, if you look at this code you should know why (Windows XP: 5.1 -> Vista: 6.0)

 if (MajorVersion >= 5) and (MinorVersion >= 1) then
 begin 'OK'
 end
 else
 begin
 'Sorry. Old Windows version detected'
 end;

Well, such a (similar) code is (still) used a lot of times. And it seems to work for Windows 2000 and XP. But in Vista MajorVersion was changed to 6 and, because it was the very first release of version 6, MinorVersion was set to zero. So the if condition stopped working on the second condition check. (BTW: This is a reason why Windows 7 is using version 6.1 instead of version 7.0 .)
Sometimes we need to apply the basic rules of logic (read a good book from Amazon) or check (nearly) all possible values in a table:

Not all Windows versions in this table really exists. But how could you know that at that time? So make the table as complete as possible. Then you can change the variables Win32MajorVersion and Win32MinorVersion to the test your if condition and run your application. Software engineers also use unit tests to check the correctness efficiency of their functions.

All in all, if the people of the bad applications had used a function like CheckWin32Version, we hadn’t this article now:

function CheckWin32Version(AMajor: Integer; AMinor: Integer = 0): Boolean;
 begin
 Result := (Win32MajorVersion >AMajor) or
 ((Win32MajorVersion = AMajor) and
 (Win32MinorVersion >= AMinor));
 end;

But then we couldn’t blame Microsoft for their bad compatibility. *g*

You can get your personal properties by using the Windows Address Book Editor. It can be opened using “wab” in command line.

At first you see your personal “Contacts” folder. This folder contains your personal contact file. Its extension is “.contact”. A double click on it opens the Address editor as seen below:

“Web.exe” can also receive any personal contact file to import it to your personal contacts.

The contact file contains a formatted text in xml syntax. Data is arranged in a tree that is used to retrieve values. When I am writing of a path, I iterate through the tree. Some of the elements contains a collection of the same element type. The reason comes from the fact, that several other contacts can be added to the personal contact. The WC API uses the array brackets to access different contact values.

The following sample path shows you how to obtain the first user’s name.(Notice that the array starts with one not zero.)

NameCollection/Name[1]/GivenName

XML (manually formatted):

This parts can be cut into three parts:

1. NameCollection defines a container for the array
2. /Name defines an array which contains all contacts
3. GivenName defines a name property of exact one contact.

There are also Value tags:

ContactIDCollection/ContactID[1]/Value

XML (manually formatted):

This path returns the GUID of contact number one.

Many parts of a path are already defined as constants. Have a look at them in MSDN.

So how can we read from the personal contact file? Since new API uses COM, we will use the following interfaces

• IContact
• IContactCollection
• IContactManager
• IContactProperties
• IContactPropertyCollection

Actually there is no implementation of these interfaces for Delphi. To create your own type library (TLB) do the following steps (in Vista of course):

1. Get Visual Studio 200x
2. Download and install the latest version Windows SDK for Vista for MIDL and IContact.IDL.
3. Open the Visual Studio Command Prompt (in VS open menu Tools). We need the predefined include path settings.
4. Add path of midl.exe from the Windows SDK to your path environment. Use this command:
   set path=%path%;<your path here>\Microsoft SDKs\Windows\v6.0\Bin
5. Change folder to ;<your path here>\Microsoft SDKs\Windows\v6.0\Include
6. Backup and open IContact.idl in your favorite text editor.
   Find these lines…
   interface IContactPropertyCollection;
   interface IContactCollection;

   …and add :

   interface IContactProperties;
   interface IContactPropertyCollection;

   Additionally find this method…

   HRESULT CommitChanges([in] DWORD dwCommitFlags);

   …and also add :

   HRESULT _DO_NOT_USE1([in] IContactProperties* pC);
   HRESULT _DO_NOT_USE2([in] IContactPropertyCollection* pC);

   In this way midl.exe will also create interfaces in the typelibrary for IContactProperties and IContactPropertyCollection.
   I could not figure out how to do it in another way. Comments are apreciated.

7. You should also find all appearances of…
   procedure Next; safecall;

   …and replace them by:

   function Next : HRESULT; stdcall;

   It is necessary because we need to check for a positive return value (S_FALSE). Delphi does not raise an EOleSysError exception for positive values.

8. Save your work and start the conversion:
   midl icontact.idl /tlb icontact.tlb
9. The new tlb file can now be imported using Delphi. To do so, start Delphi as Administrator, open menu “Components” and select “Install components” and hit the next button until all the components are listed. Click button “add” and choose the newly created IContact.tlb. Delphi imports the library and also generates the Delphi type library source code.

Did you know?

You can also (un)register a TLB file using regtlib.exe from C:\Windows\System32\URTTEMP
Type “regtlib Icontact.tlb” to register the library and “regtlib /u IContact.tlb” to unregister it.

You can find an already generated type library and and Delphi source code at the end of this article.

Using the Windows Contact API is really easy as soon as the Delphi type library unit exists. It implements class factories for IContact and IContactManager. Use the IContact class factory if you want to add your own contacts to the user’s personal database. If you just want to read data you have to use IContactManager.
Retrieving the current user’s profile is simple:

These lines creates an empty contact manager. Notice that the method Initialize is necessary for further calls.
Now we have to actually open the current user’s contact database.

The new interface Contact contains all the user’s personal data. We can obtain it through a path value as shown in the beginning of this article.
Let us obtain the user’s name. This task is done by retrieving the property interface IContactProperties using the Contact instance.

The new instance ContactProp allows us to access a property through a path.

The variable Name will contain the user’s name. In this way we make sure that the right amount of memory is allocated. Notice that the GetString actually returns the count of chars and not the count of bytes, so we have to double the size. We always get an exception in GetString because Delphi wraps (safecall convetion) the method and automatically raises an exception if the function returns a negative value (E_XXX code). We don’t distinguish between a memory error which we need to check for the correct size and a real error. So let us implement it in the right way:

In this way all “real” errors are catched and reraised.

All the other properties can be obtained in similar ways. However what properties are available at all? The interface IContactPropertyCollection allows us to obtain all available property names and types. IContactProperties implements a method GetPropertyCollection which returns a pointer to a IContactPropertyCollection that contains the requested properties. It is also possible to filter some of them.

The new property collection contains an enumeration method to iterating all available properties. Be aware that you must call Next before you start getting data.

In this way we can obtain name, type , version, modification time and ID of a property. Just use the available methods of IContactPropertyCollection.

• GetPropertyName
• GetPropertyType
• GetPropertyVersion
• GetPropertyModificationDate
• GetPropertyArrayElementID

We already coded how to get a string using COM methods. So this code isn’t new to you. It retrieves the name of the property.

To make life easier I created a unit that implements the shown code. You can download ContactMisc.pas in the download section of this article. The unit implements the following functions:

Some hints in the end

• The Windows Contacts API does not allow to open foreign contact profiles. Although IContactManager implements the method Load, it is useless. Every contact file may contain several contacts. However only one contact belongs to the user. The method Loads expects a contact file name and the user’s ID (GUID) . /GUID:”xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx” /PATH:”……..\xy.contact”
  You cannot retrieve the GUID of a foreign user with the WC API. To do so, you had to parse the contact file manually.
• So how does
  ContactManager.GetMeContact(Contact);

  retrieve the user’s ID?
  The ID is stored in the registry. Look at …
  HKEY_CURRENT_USER\Software\Microsoft\WAB\Me
  …and you’ll find the a string that is necessary for the Load method of IContactManager.

• The WC API is sensible to the current token. A service may use an impersonated thread to get a foreign user contact.

Download:

Download the package here. It contains:

• IContact.tlb – type library
• Contact_tlb.pas – delphi type library header
• ContactMisc.pas – IContact tools
• Contacts.dpr – small demonstration

Because nobody reads the remarks section of TerminateProcess, I cite it here.

The TerminateProcess function is used to unconditionally cause a process to exit. The state of global data maintained by dynamic-link libraries (DLLs) may be compromised if TerminateProcess is used rather than ExitProcess.

TerminateProcess initiates termination and returns immediately. This stops execution of all threads within the process and requests cancellation of all pending I/O. The terminated process cannot exit until all pending I/O has been completed or canceled.

And remind this little sentence.

A process cannot prevent itself from being terminated.

However there are some reasons not to make your application undestroyable.

1. The users don’t want it.
2. The work does not pay off. The user is going to close the app anyway.
3. Some people complain about apps that do not close when Windows is shutting down.
4. It’s also said that there were laptops which didn’t shutdown. The users put them into their bags and didn’t realize that the machine overheated eventually.
5. Vista closes your application in the end you have no veto.

Tell me how you liked this blog entry by adding a comment.

These are the subjects:

1. Part I: The Primer
2. Windows API calls are just calls to dynamic link libraries
3. Loading a dynamic link library
4. Dynamic loading at runtime
5. Resource only dynamic link libraries
6. Stack usage and dynamic link libraries
7. Callback functions
8. The Hook functions
9. Data storage in dynamic link libraries
10. Instanced addresses and thunking
11. Part II: Getting our hands dirty