Hi,
I’ve created an updated pre-compiled version of the OpenSSL libraries to be used with Delphi. They are – as always – available at the Fulgan Mirror. Be sure to update your installation!
Regards,
Arvid
Hi,
I’ve created an updated pre-compiled version of the OpenSSL libraries to be used with Delphi. They are – as always – available at the Fulgan Mirror. Be sure to update your installation!
Regards,
Arvid
Hi,
of course you’ve already read about the recent problems with the Logitech Webcam Drivers (if not see Nick Hodges’ blog). Well, I think this is the right moment to report about another issue, this time regarding Brother Printer Drivers and my long-term investigations about closing a handle leak.
Let’s start with the problem: While doing some quality tests on one of our own applications I’ve discovered that after each print job the handle count increases by 1.
First of all I thought of the component being used as the source of the problem. In this case it’s THtmlView. As I am also one of it’s developers since the very early D2009 days I rewrote the whole printer implementation to see if this fixes anything. This already took some time…
Result: Nope.
So, I thought of – let it sound diplomatic – a small problem in the VCL printing solution. I rechecked each and every QC entry for Printers.pas.
Result: No corresponding entry.
We wouldn’t be developers if we don’t know about other ways to find the real source.
I came up with a small example code in a plain D2009 project:
procedure TestPrinter; var i: Integer; begin for i := 0 to 100 do begin Printer.BeginDoc; Printer.EndDoc; // or .Abort end; end;
To save paper I always switch to offline mode before doing such tests. Be sure to do the same
The example: Calling this procedure in an empty project leads to +100 handles leaking after each call. In other words, after using it 10 times the application would suffer from 1000 more handles being used.
Can this be true? Having done a quick compare between D7, D2006 and D2009 I must state that the D2009 Printers.pas is far superior against the older releases. Most (if not all) QCs are resolved for it. Correct titles, handling of device properties and so one. Just as a side note.
I thought of it being related to some kind of RTL/VCL changes. Retested for D7, D2006.
Result: Always failing.
So I’ve gone ahead: Test other operating system. Having real test machines and VMs has always been useful.
Result: Also failing.
Last step to check: Is the problem really related to the Delphi application?
Result: … drum roll … No!
I started a plain Notepad, printed a page. Nothing useful as handles increases with the first job being printed on every application due to the printer driver being attached, right?
But the Notepad suffers from the same problems. Manually printed one page after another, about 20 times. Each print job increases Notepad’s handle count by 1.
That’s the right direction, isn’t it. Ok, let’s shorten up the technical part of it:
Result: The brother printer driver dll attached to the process leaks. Using several SysInternals’ tools I am able to prove this.
Using handle.exe from the suite I saw
being attached to the process in proportional relation to the print jobs (the numbers of course change for every new application process). The latest drivers (localized and unlocalized) from Brother did not solve the problem.
So I used some of the shipped default drivers from Vista, e.g. HP DeskJet 450. Of course, no problem with increasing handles. For none of the systems and none of the applications tested.
I checked the version of the brother drivers. It’s 0.3.0.0 (release 3.23) for MFC laser printers. They are used for a wide series of printers, like the 7010, 7020, 7025, 7220, 7225N, 7420 and 7820N. Probably also in other series.
The file which has this leak is called: BROMF04B.DLL
So the drivers have a problem with an unreleased handle or better a not reused kernel object (event, semaphore, mutex).
I’ve mailed this to the european customer support of Brother International. No reply after a week.
Yesterday, I had a ~70 minutes call to Brother USA in Tennessee. I wanted to let them know of the problem. Here my real odyssey after months of debugging began: I was told that my printer is not manufactured for the United States but for European market. I was calling from Europe, as I told the support tech before (!) so I was not wondering about this information.
She said the drivers are localized and therefore different. I checked this before, of course. They were the same. Recently as I am working on english systems I am solely using unlocalized drivers. Imho, they are just a wast of space…
I tried to tell about the problems, had been forwarded three times. Waited for minutes to let her check back for other technicians to talk to. No one was understanding or even interested in this issue. Just speaking of: Is the device printing or not. I told about the leak and the tests and the file. The dialogue: Is the file missing. – Me: No. – So you have a problem with printing. – Me: Well, yes, indirectly. – So your device is not printing. – Me: No, it also happens without the printer being attached when using the offline mode (and so on).
Finally I was told to send my report to Brother International Corp. in Bridgewater, New Jersey. By mail. No, not the fast one. Nobody was able to give me the email address of a technician.
What should I do now? I wanted to help them fix their products and already invested my time and my money.
This has been an issue I’ve been investigation since a few months now. Since last week I know of the brother printer driver being the source of it. I can only open a support case in Europe – receiving meaningless default answers. Kudos!
Imagine the following: Our application is designed for 24/7 usage. The handles increases day by day. Reaching 50.000 to 400.000 after a few months and boom, your application or OS crashes. This can result in problems from unpredictable behaviour of the application up to a total crash with potential data loss.
Shouldn’t Brother care about?
Just my 2c.
Best regards,
Arvid
P.S.: If anybody has better possibilities to reach the Software Development Team @ Brother International Corp. please drop a mail or leave a comment
Hi,
yesterday a new version of the OpenSSL libraries has been published. I have just created precompiled DLLs for use with Indy again which are now available.
You can download the libraries from Fulgan’s Mirror.
Hi,
I’ve recently released an updated version of the Delphi Encryption Compendium (DEC) compatible with Delphi versions up to 2009. A code example of using it with Unicode strings is included in the library.
This libary was updated and released with permisson of the original author Hagen Reddman who developed the versions DEC 3 and DEC 5.1.
The Delphi Encryption Compendium supports several hashes, ciphers and text encodings and is imho one of the best libraries for strong cryptography in Delphi. And the best: It is free of charge!
It is available at Torry: http://www.torry.net
Thanks to Michael Puff (a.k.a. Luckie) for hosting the library on his server!
Due to the request here are the hashes for the file DEC_v5.2.zip linked at Torry / Michael’s Server:
<dec_v5.2.zip>
MD5: af599125809e4258597138a7c4496b80
RipeMD128: 9e2717abecbcd20623ebb05a04a70143
RipeMD160: fe25c2d89c2487412c4c7b9d04a2f4a9eaf792df
SHA1: cda26284cd4099a30bd7c32e2076bac0cd1b9f32
SHA256: cdec0862005a6da637d3f7d9277d2cb65f0c3eb58f5a02866989e9b56879f999
Hi,
if you have been using Gustavo Daud’s PNGImage before and consider migrating existing projects to D2009 you must keep in mind that you will loose all previously assigned PNGs in your TImages.
As you all know Delphi 2009 ships with native PNG support but there are some differences. In PngImage.pas CodeGear declared
type TPNGObject = TPngImage deprecated 'Use TPngImage.';
So the classname for PNGs changed and the old one is marked as deprecated.
The problem: All TImage pictures are stored within the form’s .DFM file. Before inserting the binary data the IDE stores the classname (and it’s length) as a prefix to the data.
When using Gustavo’s component in D2006 it will store 0A54504E474F626A656374 which is in ASCII TPNGObject (the 1st 0A is the length of the following classname). In Delphi 2009 it stores 0954506E67496D616765 which is in ASCII TPngImage (again 09 is the length).
So when opening an existing form in D2009 the IDE searches for TPNGObject classname and as it cannot find it anymore the images are emptied.
With the help of Andreas Hausladen I came up with a solution for this:
PngClassWrapper.pas
{$IFDEF VER200}
uses
Classes, Graphics, PngImage;
type
TPngObject = class(TPngImage);
{$ENDIF}
implementation
{$IFDEF VER200}
initialization
TPicture.RegisterFileFormat('PNG', 'Portable Network Graphics (Compatibility Wrapper)', TPngObject);
finalization
TPicture.UnregisterGraphicClass(TPngObject);
{$ENDIF}
After discussing the issue Uwe Raabe yesterday published a fix inside of the PngComponents for Delphi 2009.
He used:
type
TPNGObject = class(TPngImage);
begin
TPicture.RegisterFileFormat('', '', TPNGObject);
end.
The empty strings will help to hide the wrapper from the FileOpen Dialog within the filter selection in the IDE.
An updated version if his port of the PngComponents for D2009 is available at CG:
PngComponents for Delphi 2009
Btw: The PngComponents Uwe published is still compatible with older Delphi Versions (tested with Delphi 2006). Only the PngImage Gustavo previously released on SourceForge is not available anymore as the license has been revoked as D2009 now ships with an enhanced version of it.