Login
Templates, Tools and Utilities
for Clarion Developers
Templates, Tools and Utilities
|
||
|
|
|
Add a comment to an Icetips ArticlePlease add your comments to this article.
Please note that you must provide both a name and a valid email address in order
for us to publish your comment. Comments are moderated and are not visible until they have been approved. Spam is never approved!
Back to article list Search Articles Add Comment Printer friendly Direct link Windows API: WinInet callback linked local vs standlone mode 2003-05-31 -- Alexey Solovjev Hello,
> Another standalone vs local link problem....
> ...
> When linked local in c6ea4-1, the callback seems to be called ok until i
> open a status window...event:openwindow is posted then the program just
> goes away with no further event.or explanation of itself at all...
> just gone.
>
> If anyone is doing a wininet callback, I would greatly appreciate it if
> you could try it linked local.
Well, let me explain that happening.
EXEs and DLLs are about identical. There are only few differences, most of
them are not significant. But one is principal. Every EXE and DLL has the
entry point. The manner how Windows calls to this entry point is very
different for EXE and DLL:
- the entry point of the EXE is called once only on the start of process.
- the entry point of the DLL is called on the loading and unloading this
DLL to and from the process virtual space AND on start and finish of
every thread (except one that is active at loading and unloading time).
This means that Windows does not "inform" the EXE when thread is started
or closed. The Clarion RTL knows about this Windows behavior and handles
it. Threaded data declared in the EXE is initialized on the start of new
thread and it is cleaned up on the thread closing. The RTL also detects
threads started, for example, by dialogs started from the program and
initializes all required internal data.
The case in your program is the most difficult case: the new thread is
started out of the program by Internet stuff and calls to passed callback
function within this new thread. If the program is linked in the standalone
mode, there are no problems: the RTL is a DLL and Windows calls to its
entry point that allows to initialize all threaded data. If the program
is linked in local mode, Windows does not inform it about new thread. So,
the callback is the first code in the program that is executed by the
external thread. Hence, first attempt to access threaded data declared
within the program or within RTL causes the fault.
This is not a defect of Clarion, this is consequence of Windows behavior.
We can handle case of such callbacks in one-piece EXEs too but do not
consider that this is reasonable - because of the cost of solution: every
program regardless the mode it has been linked would be need to perform
extra code on every call to the most frequently used operation in the RTL.
This is too high cost for handling very rare situation that is not handled
by Windows. On the other hand, there are several alternative solutions:
- to make the program in the standalone mode
- if you don't want to ship multiple DLLs with your program (RTL, drivers),
it can be made it not one-piece but as two pieces: the locally linked DLL
and the small EXE that does the only thing - calls to specific function
from the DLL.
Follow next simple steps for the latter variant:
- In the program's project set Target Type to DLL and Run-Time Library to
Local
- Move code from the program's CODE section to a procedure, e.g.
From:
CODE
Today is November 21, 2024, 7:12 am This article has been viewed 35237 times. Google search has resulted in 82 hits on this article since January 25, 2004.
|
|