User:ConradPino/Christian Wimmer/Task List 2010-Jan-29

Date: Fri, 29 Jan 2010 16:58:33 +0100
From: Christian Wimmer <>
To: "Conrad T. Pino" <>
Subject: JEDI API&WSCL work

Hi Conrad,

I just did some research and actually there is some work to do that I couldn't finish.

1. There is a JwaWinTrust.pas that isn't completely translated. Vista added some extra stuff and therefore some parts are missing in the Delphi version. I started a translation some time ago that needs to be finished. I can send you this unfinished unit if you like.

2. We need a replacement for the dynamic loading functions for all WinAPI functions. At the moment a function is dynamically loaded in this way:

var
  _GetWindowModuleFileNameW: Pointer;

function GetWindowModuleFileNameW;
begin
  GetProcedureAddress(_GetWindowModuleFileNameW, user32, 'GetWindowModuleFileNameW');
  asm
    MOV ESP, EBP
    POP EBP
    JMP [_GetWindowModuleFileNameW]
  end;
end;

However, if Delphi gets 64bit support this won't work anymore because in 64bit function parameters are stored in registers (and unused registers are cleared when a function is called) So we need a replacement and Delphi 2009 introduced the reserverd word "delayed" which is added behind the function declaration. (Furthermore stdcall; is deprecated) I had this solution in mind:

"Remove" the asm function and add "delayed" to the function declaration if "DYNAMIC_LINK" compiler switch is active. Usually the functions are declared twice. One is defined in the interface part and another one in the implementation part. The static loaded function looks like this:

function DefRawInputProc; external user32 name 'DefRawInputProc';

So I think adding "delayed;" here (in case of DYNAMIC_LINK" compiler switch is active) should be fine.

function DefRawInputProc; external user32 name 'DefRawInputProc' {$IFDEF DYNAMIC_LINK}delayed{$ENDIF DYNAMIC_LINK};

Of course it means that the whole DYNAMIC_LINK compiler stuff must be rethinked because "delayed" should only be used in D2009 and newer.

Old implementation still should use the asm function (thus I put "Remove" into quotes). Maybe we add DELAYED_LINK directive (or different name) that undefines DYNAMIC_LINK (so the static part is used) but activates the reserverd word "delayed" in the function declaration.

Unfortunately it is a lot of work and I don't even know whether it will work. Maybe a program could do it automatically? Furthermore D2009 is necessary.

3. I have some JEDI API translation files available to be released. However, they need some checks and makeover.

a) Application Restart and Recovery

b) Kernel Transactions Manager

c) Windows Image to Virtual Hard Disk (WIM)

d) Windows Update API

These were created by another member who has some other work to do. (It could be possible that one of them is already available in JEDI API.)

4. There is a big project on ice at the moment. The JEDI API Installer. It is an application that supports JEDI API&WSCL subversion repository.

At the moment it can show all available versions and download them through subversion commands.

The next step would be to compile the JEDI API source to JwaWindows.dcu for all available Delphi versions. Currently, only the install wizard part (that is a row of GUI pages in an installation wizard style) is implemented.

The setup application supports different ways of downloading and installing source codes. I mean it is possible to add another interface implementation that allows to download JEDI VCL source (all install packages are implemented using interfaces). So it would be possible to add another project to the installer (like JEDI VCL).

This project is officially not available and resides on a private SVN server. Its presence must not be made available to public because I am not sure when or if it will be available at all. However if you intend to take part I can give you access to the code (Needs some time though).

• I think the first important part would be to generate a plan and design that show other people what they can do and how. I cannot add ten people and guard their work that is the reason why I didn't make it public yet. (Usually people tend to stop working after some time and don't respond anymore).

5. This work is not about JEDI API but JEDI WSCL. There are some open fields like

a) JwsclAccounts.pas This unit is about managing Windows user accounts. It should wrap all the various NetUser/NetGroup (e.g. NetUserGetInfo) into classes. Because of the different kinds of structures (struc_ver1, struc_ver2 etc. ) this is a really confusing job.

b) JwsclSSPI.pas This unit should wrap the Security Support Provider Interface in classes that allows to handle the functions easier. Since SSPI is a really generic interface for different kinds of providers (everybody can write such a provider) it is hard to handle the different kinds of structures. However, only the provider supported by MS should be available through this interface and maybe only MS NTLM and Kerberos for the beginning.

c) JwsclSecurePrivateObjects.pas and JwsclSecureUserObjects.pas These are two units that actually should do the same:

Providing a class that can be attached to any private/default ressource (like classes, database fields) so it becomes a secured resource. MS provides some WinAPI (like CreatePrivateObjectSecurity) that helps doing the job. However, JWSCL has a much more sophisticated way of doing the same thing (e.g. merging security descriptors).

Furthermore I used AccessCheck that wraps the original AccessCheck function which does a process context change to kernel mode. The AuthZ API provided by MS and implemented in JwsclAuthCtx.pas , however, supports AccessCheck without a context switch (it is implemented in a dll)

This work is rather interesting for application programmers that want to use MS Windows security to grant or deny access to internal resource. In this way the user management of Windows can be used to do access checks. Because security descriptors can use a lot of space the hard part is to store only one security descriptor for different resource but with the same content of a security descriptor. Usually, a hash is set (for each resource) that points to a security descriptor stored in a central place. It gets more complicated if the resources are organized in a tree (like files and registry) because inheritance should be available too).

Hopefully, you are interested in one (or more) of these fields and can bring them to an end. Don't hesitate to ask questions or send me other fields you'd like to work on.

Best Regards

Christian Wimmer