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:

Impact of workaround.Disabling icons from being displayed for shortcuts prevents the issue from being exploited on affected systems. When this workaround is implemented, shortcut files and Internet Explorer shortcuts will no longer have an icon displayed.

Let me show you, why I can’t work anymore efficiently.

Windows 7 Taskbar with plain Icons

As you can see, some of the applications are already started and they don’t have their icon but some of them have. I don’t see the reason though. Do you?

BTW: This goes on in the start menu, on the desktop, and the favorite list in Windows Explorer.

Happy working….

EDIT:

A possible fix was supplied by external programmers. Maybe this will be the only option for the last few people who are using Windows 2000 still.

Feel free to use it since it is public domain.

Download C++ Environment Scripts

By default the scripts setup the environment to the newest compiler found on your system. In this way you can just call msbuild and build your projects.

Please adapt your news reader accordingly. However, it is a pity that the old messages cannot be restored and maybe never will without an backup.

Furthermore, the server itself may still be changed but the address will stay the same.

UPDATE:

It looks to me as if only the unsecured access is not accepted. Instead only SSL is available regardless of the address (so both works).
I got some mails from people who couldn’t answer the threads I participate. So they sent me mails directly.

A shame that Kaster’s thread wasn’t replicated by e.g. Nick. His blog is far more often read by people than this Announce forum (which was afterwards effectively unavailable to me and others).
Furthermore some forums look to me a little bit more abandoned than usual. So the activity seems to be lower.

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

To understand the concept of Window Sessions, Stations and Desktop it is not necessary to read all articles to the end. I think the beginning is just fine.

• Pushing the Limits of Windows: USER and GDI Objects
  Mark Russinovich writes about USER and GDI objects but he also gives a basic introduction how sessions, windowstations and desktops are related.
  • Part 1
  • Part 2  (still writing)
• Desktop Heap Overview
  The guys from Advanced Windows Debugging and Troubleshooting explain how it is possible that a desktop can run out of heap. It is a quite technical article but it gives a nice insight into some of the Windows internals.
  • Part1
  • Part2

I often prefer such blog articles to MSDN articles because blog articles are much more fun to read.

Valid for all open source projects, also the JEDI API&WSCL projects heavily depend on their users. This is not a company where people work all day to make a  great project. I and other members of JEDI use our spare time after real work to bring forward projects such as JEDI.

Unfortunately, time has changed and less and less people want to provide their skills and manpower in projects like JEDI…and I am not talking about JEDI API exclusively. That is a pity because we will not provide you with source code forever. Instead the process will come to a halt and we will see more and more questions in newsgroup asking why the project doesn’t work anymore in Delphi 2020 (or similar).

I don’t get it. There are many new API functions in Vista and Windows 7. And I see a lot of people writing conversions from C to Delphi so they can use the new functionality. But instead of donating these sources to JEDI API they post it to their local forum or use it in their project as an internal unit. Usually, I come along and ask these people if they want to donate their source to JEDI API. And the chat goes like this:

Christian: “Hey, I am from JEDI API. Maybe you heard from us. It would be great if your conversion could be integrated into JEDI. Do you agree?”

X: “Yeah, I’m using your projects a lot. And of course, I would like to see my source integrated into JEDI.”

C: “Well, I need your source code to be converted to some standards we use. I will send you more information about this easy process. If you have further question just ask.”

X: “Eh? Sorry, but I don’t have time to put more effort into this. Can’t you just do it yourself?”

Let me answer: Well, If we could do it ourselves we would already have done it. But that means that we would need to give up our jobs and private life to convert over 20.000 functions, interfaces and types only for this project.

Did you know that there is a template that shows you how to create a JEDI API file?

Also it often happens that I don’t hear anything from them. Therefore these conversions never get integrated because I need an explicit agreement.

On the other hand there are many people who like just to use the source code in their own project because it makes it easier to write good programs.
May I ask what you did to keep alive the project that you gained from?  I have to say from experience that the donations in source and money (in relation to current software prices) are that rare that zero (0) would describe it best. Luckily, this is not entirely true but it is very close to the truth.

Fortunately, there are a lot of companies which are generous and allow us to use their products for free. You can find the list  in the sponsors section of this blog. With a monetary donation of nearly zero we could never use their products. I cannot stop saying: “Thank you!“

Also let me use this article to thank all the people who helped or are still helping in these projects. I want to thank them again and again and again! And let me thank the donators again (I wrote them a mail).

–

Christian

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.

I always add “RaiseLastOsError” to every Windows API call.

if not ImpersonateLoggedOnUser(token) then
  RaiseLastOsError;

In this way you don’t miss any failed call and wonder what is happening (I can recall a lot of forum threads that ask about this).
RaiseLastOsError generates an EOSError exception that contains the error number and text in its message. It also stores the GetLastError value in its property ErrorCode.

One more good thing is that a caller of the function, where this code is implemented, cannot ignore an error value. The API function ImpersonateLoggedOnUser is very problematic because if it fails all subsequent calls are made on the security token of the process instead of the thread. So a client could access more things than usual. So if we had a function that implements the example

function MyImpersonateUserToken(UserName : String; out UserData : PUserData) : Boolean;
begin
  //get user token here
  //get user information from token here and store it into UserData

  result := ImpersonateLoggedOnUser(token);

As you can see a caller can just do the following

MyImpersonateUserToken(UserName, UserData);
If UserData.Groups.IsMemberOf('Administrators') then

Be aware that the example is only fictional. However I have seen many production codes that call WinAPI without error checking. The WinAPI usually (and the code above definitely) does not touch any of the output parameters if they fail. So you probably get an Access Violation (best case) or it works randomly (worst case). See that UserData is not initialized here. But what about this one:

procedure MyImpersonateUserToken(UserName : String; out UserData : PUserData);
begin
  //get user token here
  if not GetUserToken then
    raiseLastOsError;
  //get user information from token here and store it into UserData
  if not GetTokenInformation then
    raiseLastOsError; 

  if not ImpersonateLoggedOnUser(token) then
    raiseLastOsError;

You see that the function is really a procedure now that throws exceptions in case of failure. In this way the code following the function call MyImpersonateUserToken isn’t executed at all. Instead, we need to wrap an exception trap around the function call to let the code continue.

try
  MyImpersonateUserToken(UserName, UserData);
except
end;

if UserData.Groups.IsMemberOf('Administrators') then

Okay, everbody should see that this is a really ******* code and should not be left in this way.

If you make an habit from this you won’t miss the old way. Instead it takes less time to implement and I don’t mention the time searching for memory leaks.

Furthermore, I think it looks much better and besides of that it is really easy to read and understand.
However, the most important reason (for me) is that any user who calls this function incorrectly (e.g. user not found) gets a nasty exception thrown into the face.

These are the reasons why JWSCL throws exceptions in 99,99% of its methods instead of returning error values.

I always use try/finally for memory allocations

Programmers have a hard to find memory leaks. There are libraries (like JWSCL) that support smart pointers but Delphi comes also with “smart pointers” (besides interfaces). Although it needs some more work. If you have translated code from C to Delphi you have seen it maybe. I’m talking about “goto” statements in C code.

{
  ...
  if (!GetTokenInformation(...))
    goto exit_1;

goto exit_0;
:exit_1
  CloseHandle(hToken);

:exit_0
return (result);
}

In Delphi we don’t use goto because we were told that it is  bad habit. So we directly put the exit after each failed function called.

begin
  ...
  if not GetToken(hToken) then
  begin
    result := true;
    exit;
  end;
  if (not GetTokenInformation(...)) then
  begin
    CloseHandle(hToken);
    result := FALSE;
    exit;
  end;

  CloseHandle(hToken);
  result := TRUE;
end;

In more complex code you can easily miss a failure code path or miss to close a handle or free an object. So why don’t do it this way?

  ...
  if not GetToken(hToken) then
    raiseLastError;

  try
    if (not GetTokenInformation(...)) then
      raiseLastError;

    if GetMeOutOfHere() then
      exit;
  finally
    CloseHandle(hToken);
  end;
end;

The try/finally statement ensures that the code within finally is executed. It does not matter that an exception is raised (we know that already). Even if we call “exit” the finally part is also executed.

However, you need to make sure that the variables within finally are valid.

1. CloseHandle throws an exception if the handle is not valid. This only happens if it detects an attached debugger.

2. Free, FreeAndNil, FreeMem, Dispose will throw an exception depending on the content of the given pointer. In worst case nothing happens and you get garbage results anywhere else in your application.

So the correct way is to trap every allocated variable (pointer, class) in a separate try/finally statement.

New(Ptr);
try
  MyClass := TMyClass.Create;
  try
    ...
  finally
    FreeAndNil(MyClass);
  end;
finally
  Dispose(Ptr);
  Ptr := nil;
end;

Make it an habit to implement the finally part immediately. Delphi helps you by adding the finally part automatically.

New(Ptr);
try
  (1)
finally
  Dispose(Ptr);
  Ptr := nil;
end;

Now continue at position (1).

One more tip: If you have a lot of source lines between try/finally you can also put a comment behind finally to show the initial call.

New(Ptr);
try
  ... many lines ...
finally //New(Ptr);
  Dispose(Ptr);
  Ptr := nil;
end;

In this way you don’t mix up the variable names allocated and freed. And we also don’t mix up the allocation types (e.g. GetMem <> Dispose)

Your programming habits

If you want to share your habits you can do this by leaving a comment. Or better you can write your own article and link it here so a conection is made.

Looking forward to hearing from you!

Christian