Hello,

we have developed a 32 bit application that must run under Windows XP (thousands of independent customers worldwide).

It works perfectly if compliled with Delphi 2010 Professional.
Recompiling it with Delphi XE5 (target platform Win 32) it starts but after some instants it shows a message like this:

The procedure entry point InitializeConditionVariable could not located in the dynamic library Kernel32.dll.

Of course this is due to such procedure only being available with Windows Vista and later.
Running a "dependency walk" software on the executable, we indeed see the dependency is there.

My question is: how do we find which application component depends on that call?

The application is not using packages, it's a lone executable.
We have full source code of all our components and searched for "ConditionVariable" (case insensitively) and found exactly zero matches at all.
Delphi's own Windows.pas and ShlObj.pas DO contain ConditionVariable code, but apparently it just detects whether it is implemented or not. In case it isn't, it looks like just implementing some "null code". So it should not cause issues.

We are using:
JVCL
ZeosLib, connecting to a MySQL server through recent libmysql.dll. The dll is part of an Oracle "connector" that installs the appropriate dll for the destination operating system (Windows XP in this case).
Midaslib (that is we are using the "embedded" version).

The official JVCL maintainer told us the library does not use condition variables at all. Searching for "ConditionVariable" through both JCL and JVCL code indeed yelded to no match found.

The program is structured to:

- Start
- Perform "assorted" SQL queries with no DataSnap / MIDAS usage.
- Open client datasets.

If I remove the libmysql dll, the program starts with no Kernel32 related message at all but of course it shows a missing Libmysql error and quits.
If I leave the libmysql.dll in, the program starts with no Kernel32 related message, then seems to perform something and only then I see the Kernel32 missing dependency message.

Anyone could please tell me if the embedded MIDAS creates those Kernel32 dependencies?

I'd be happy just knowing how to find out which code is triggering the dependencies at all.

Thanks in advance.

Edited by: Dario Fumagalli on Feb 19, 2014 7:19 AM

Edited by: Dario Fumagalli on Feb 19, 2014 7:22 AM

Dario wrote:

> we have developed a 32 bit application that must run under Windows XP
> (thousands of independent customers worldwide).
> 
> It works perfectly if compliled with Delphi 2010 Professional.
> 
> Recompiling it with Delphi XE5 (target platform Win 32) it starts but
> after some instants it shows a message like this:
> 
> The procedure entry point InitializeConditionVariable could not
> located in the dynamic library Kernel32.dll.

This is not the the first time the VCL has linked to a newer API that as 
not available on older OS versions (TThread using GetThreadTimes() comes 
to mind).  And kernel32 cannot be delay-loaded, so functions like GetThreadTimes() 
and InitializeConditionalVariable() cannot be declared as 'delayed', they 
would have to be explicitly loaded using GetModuleHandle() and GetProcAddress() 
at runtime.

And technically speaking, XP is no longer a supported platform as a development 
OS, and maybe now as a deployment OS, either.

> My question is: how do we find which application component depends on
> that call?

You would have to grep the VCL's source code directly.

> The application is not using packages, it's a lone executable.

It is still using packages, they are simply statically compiled into the 
executable.

> Delphi's own Windows.pas and ShlObj.pas DO contain ConditionVariable
> code, but apparently it just detects whether it is implemented or not.
> In case it isn't, it looks like just implementing some "null code". So
> it should not cause issues.

So Embarcadero had the forsight to implement InitializeConditionVariable() 
dynamically, so the VCL is not at fault.  Something else outside of Embarcadero's 
code is using InitializeConditionVariable().

> If I remove the libmysql dll, the program starts with no Kernel32
> related message at all but of course it shows a missing Libmysql error
> and quits.

There you go then.  libmysql.dll must be using it.  If you statically link 
to a DLL, and it statically links to a missing API function, then your app 
will fail to load at all.

> If I leave the libmysql.dll in, the program starts with no Kernel32
> related message, then seems to perform something and only then I see
> the Kernel32 missing dependency message.

That does not make sense.  The dependancy message only appears when an EXE 
is first loaded into memory before it starts running.  If your app loads 
fine, and then fails only when the DLL is accessed at a later time, then 
the DLL must be getting loaded dynamically instead of statically and the 
OS is displaying the message when the DLL is loaded into memory, but it should 
not be doing that.  Unless the DLL is being loaded by another process that 
your EXE is spawning (directly or indirectly).

If your EXE is able to load and run before the failure occurs, then try is 
calling SetErrorMode(SEM_FAILCRITICALERRORS) before the DLL is loaded.  That 
should hopefully disable the popup message, and just make the DLL fail to 
load with an error code that the calling code can then handle as needed. 
 Then find (or recompile) a version of libmysql.dll that does not use unsupported 
APIs on older OS versions.

--
Remy Lebeau (TeamB)

> {quote:title=Remy Lebeau (TeamB) wrote:}{quote}
> Dario wrote:
> 
> > we have developed a 32 bit application that must run under Windows XP
> > (thousands of independent customers worldwide).
> > 
> > It works perfectly if compliled with Delphi 2010 Professional.
> > 
> > Recompiling it with Delphi XE5 (target platform Win 32) it starts but
> > after some instants it shows a message like this:
> > 
> > The procedure entry point InitializeConditionVariable could not
> > located in the dynamic library Kernel32.dll.
> 
> This is not the the first time the VCL has linked to a newer API that as 
> not available on older OS versions (TThread using GetThreadTimes() comes 
> to mind).  And kernel32 cannot be delay-loaded, so functions like GetThreadTimes() 
> and InitializeConditionalVariable() cannot be declared as 'delayed', they 
> would have to be explicitly loaded using GetModuleHandle() and GetProcAddress() 
> at runtime.
> 
> And technically speaking, XP is no longer a supported platform as a development 
> OS, and maybe now as a deployment OS, either.
> 
> > My question is: how do we find which application component depends on
> > that call?
> 
> You would have to grep the VCL's source code directly.
> 
> > The application is not using packages, it's a lone executable.
> 
> It is still using packages, they are simply statically compiled into the 
> executable.
> 
> > Delphi's own Windows.pas and ShlObj.pas DO contain ConditionVariable
> > code, but apparently it just detects whether it is implemented or not.
> > In case it isn't, it looks like just implementing some "null code". So
> > it should not cause issues.
> 
> So Embarcadero had the forsight to implement InitializeConditionVariable() 
> dynamically, so the VCL is not at fault.  Something else outside of Embarcadero's 
> code is using InitializeConditionVariable().
> 
> > If I remove the libmysql dll, the program starts with no Kernel32
> > related message at all but of course it shows a missing Libmysql error
> > and quits.
> 
> There you go then.  libmysql.dll must be using it.  If you statically link 
> to a DLL, and it statically links to a missing API function, then your app 
> will fail to load at all.
> 
> > If I leave the libmysql.dll in, the program starts with no Kernel32
> > related message, then seems to perform something and only then I see
> > the Kernel32 missing dependency message.
> 
> That does not make sense.  The dependancy message only appears when an EXE 
> is first loaded into memory before it starts running.  If your app loads 
> fine, and then fails only when the DLL is accessed at a later time, then 
> the DLL must be getting loaded dynamically instead of statically and the 
> OS is displaying the message when the DLL is loaded into memory, but it should 
> not be doing that.  Unless the DLL is being loaded by another process that 
> your EXE is spawning (directly or indirectly).
> 
> If your EXE is able to load and run before the failure occurs, then try is 
> calling SetErrorMode(SEM_FAILCRITICALERRORS) before the DLL is loaded.  That 
> should hopefully disable the popup message, and just make the DLL fail to 
> load with an error code that the calling code can then handle as needed. 
>  Then find (or recompile) a version of libmysql.dll that does not use unsupported 
> APIs on older OS versions.
> 
> --
> Remy Lebeau (TeamB)

Hello,

first of all, thank you for taking your time and replying me!

By reading your reply, I think I have not described the situation well enough.

I have searched the  [official Embarcadero Delphi XE5 FAQ|http://www.embarcadero.com/es/products/delphi/frequently-asked-questions] and it states Windows XP is supported as deployment platform. It's very important it does, because otherwise we'd have wasted a lot of money on upgrading to RAD Studio XE5 Ultimate - we'd have to return back to Delphi 2010 if it was not compatible. But the FAQ says it does. Hopefully somebody at Embarcadero has checked the FAQ statement is saying the truth.


Another point: the application uses ZeosLib for database connectivity (I know Delphi XE5 comes with all sorts of nice solutions but the application is not trivial to refactor to use them. So we have to deal with that library.
Zeos has a drivers driven architecture so it loads any of its supported data sources (including MySQL through libmysql.dll) "just in time", that is well past the application has started.
This is why it's possible to see the application starting and only then, getting the unresolved dependencies.

Midas gets loaded even later.

My biggest doubt is whether it's the libmysql.dll or MIDAS.

Libmysql.dll:

- seems to load before the application shows the message.
- has been installed with an Oracle installer that determines which operating system it's going to install stuff for. It'd seem odd it'd install an incompatible version. Had it been some freeware stuff, ok. But for Oracle to fail installing their connectivity software on a most common platform... that sounds very odd.

- Midas instead, the Delphi 2010 DLL works like a charm, the XE5 one has given me many an headache. Crashes, access violations etc. etc. until I "merged" it in the application by adding the Midaslib in the Uses clause. Could it be the determining factor that makes the application not compatible?

I thank you for the "SetErrorMode(SEM_FAILCRITICALERRORS)" tip, I'll see what I can do with it the next time I recompile the software.

But I ask you, do you know any way to understand what piece of the application triggers the error? I mean, I'd like to find out the offending calling function and I think all I'll get by using the debugger is some unuseful assembly code address.

Dario wrote:

> My biggest doubt is whether it's the libmysql.dll or MIDAS.

Seems pretty easy to test.  Load libmysql.dll.  Does it load on XP?  Load 
MIDAS on XP.  Does it load?

> Libmysql.dll:
> 
> - seems to load before the application shows the message.

OK then.  Most likely not the culprit.

> - Midas instead, the Delphi 2010 DLL works like a charm, the XE5 one
> has given me many an headache. Crashes, access violations etc. etc.
> until I "merged" it in the application by adding the Midaslib in the
> Uses clause. Could it be the determining factor that makes the
> application not compatible?

I cannot answer that.  I do not know anything about MIDAS.  But I would expect 
that if it has a static dependancy on InitializeConditionVariable, and then 
you compile MIDAS statically into your app, then your app would fail to load 
at all on XP.

> But I ask you, do you know any way to understand what piece of
> the application triggers the error? I mean, I'd like to find out the
> offending calling function and I think all I'll get by using the
> debugger is some unuseful assembly code address.

You would have to use Dependancy Walker, or similar tool, on every EXE/DLL 
your app uses, whether loaded statically or dynamically, and find out which 
one is linking to InitializeConditionVariable().  Or maybe use SysInternals 
File Monitor to watch file accesses in real time and see which DLL was last 
accessed when the error occurs.  But either way, that is not going to tell 
you which function of which DLL is calling InitializeConditionVariable(), 
though.  In fact, it is possible that the offending module may be linking 
to InitializeConditionVariable() without actually calling it at all.  Just 
the mere presence of the function in the module's IMPORTS table is enough 
to trigger the error.

--
Remy Lebeau (TeamB)

> {quote:title=Dario Fumagalli wrote:}{quote}
> Hello,
> 
> we have developed a 32 bit application that must run under Windows XP (thousands of independent customers worldwide).
> 
> It works perfectly if compliled with Delphi 2010 Professional.
> Recompiling it with Delphi XE5 (target platform Win 32) it starts but after some instants it shows a message like this:
> 
> The procedure entry point InitializeConditionVariable could not located in the dynamic library Kernel32.dll.
> 
> Of course this is due to such procedure only being available with Windows Vista and later.
> Running a "dependency walk" software on the executable, we indeed see the dependency is there.
> 
> My question is: how do we find which application component depends on that call?
> 


I have found a solution to this issue.
It's not exactly a reply to my question: "how do we find which application component depends on that call?" but it solved the originating problem.

The culprit was the libmysql.dll indeed.

As also documented by me on the [official MySQL forums|http://forums.mysql.com/read.php?168,607366,607366#msg-607366], I have laboriously found an old DLL version (5.5) and found out that the application works perfectly well with it, even on Windows XP.

Lesson learned: even Oracle makes mistakes, apparently they did not check that *multithreaded* database applications would still work on Windows XP so their own installer puts such potentially incompatible DLL in Windows XP anyway.