Hello all,

Does unit initialization in libraries (.dll files) work in arm/WinCE? Somehow it seems that even code placed in the library initialization begin end block isn't executed either. I found some bug reports (e.g.
0019404) suggesting that this didn't work for arm/Linux but it has been added to the trunk. But not for arm/WinCE?

If this is the case, is there a feasible workaround to call unit initialization sections manually? I am not statically linking the libraries by means of "external" clauses but I am using LoadLibrary() and GetProcAddress() to communicate with the dll from the exe, so I could create an exported function in the dll and call it manually from the exe after loading if I could somehow iterate in it the unit initialization sections and call them.

Thank you in advance.

Constantine.

kyan wrote

Does unit initialization in libraries (.dll files) work in arm/WinCE?

From the startup code of arm-wince I don't see why it should not work...

Somehow it seems that even code placed in the library initialization begin end block isn't executed either.

How did you test this?

I found some bug reports (e.g. 0019404) suggesting that this didn't work for arm/Linux but it has been added to the trunk. But not for arm/WinCE?

Linux and Windows have different schemes for library initialization, so even if it was the case that arm-wince did not work it would not help to apply the fix for arm-linux there as well.

Regards,
Sven

OK, I apologize. It seems that the problem lies elsewhere. The fact that library initialization seems to be deferred until you do a GetProcAddress() confused me. The problem is that function GetModuleName() is stubbed out in WinCE (and Linux):

unit SysUtils.inc;
function GetModuleName(Module: HMODULE): string;
begin
{$ifdef MSWINDOWS}
  SetLength(Result,MAX_PATH);
  SetLength(Result,GetModuleFileName(Module, Pchar(Result),Length(Result)));
{$ELSE}
  Result:='';
{$ENDIF}
end;

The function GetModuleFileName() exists (although it is unicode) in WinCE: http://msdn.microsoft.com/en-us/library/ms908441.aspx

And from what I've found in the web a Linux implementation is possible using dladdr().

"kyan" wrote

OK, I apologize. It seems that the problem lies elsewhere. The fact that library initialization seems to be deferred until you do a GetProcAddress() confused me.

It might't be that Windows (or CE only) initalizes a library only if you use GetProcAddress at least once... I have not tested that, but it might be an idea. If that is the case we can not influence that.

Pchar(Result),Length(Result)));

If you want you can create a bug report. WinCE might likely be solved then, but I can't comment on Linux or other *nix systems.

Regards,
Sven

Thank you for your reply Sven.

It might't be that Windows (or CE only) initalizes a library only if you use GetProcAddress at least once... I have not tested that, but it might be an idea. If that is the case we can not influence that.

No need to, it really doesn't matter since one has to do a GetProcAddress() in order to be able to call anything inside a dll. Maybe it is an optimisation that has to do with resource dlls.

If you want you can create a bug report. WinCE might likely be solved then, but I can't comment on Linux or other *nix systems.

It's OK, I've wrapped GetModuleName() in a function of my own that works as expected in Delphi, Win32, Win64 and WinCE and will stick to that. Will report when I find some time.

Sven Barth wrote

Am 12.06.2012 15:20 schrieb "kyan" :

.
.

In any case, it's wrong that the implementation is placed in the platform independent include file instead of the respective sysutils.pp files. :-(

Tomas

That can be corrected as well when support for Windows CE is added :D

Regards,
Sven