ezprint library crashes tcl84.dll when wrapped as starpack?

Hi All,

I have an application developed for WinXP that makes use of the ezprint
library (http://lbayuk.home.mindspring.com/ezprint/).

When run as pure tcl code, the application works correctly, but when wrapped
as a starpack, some of the commands associated with the ezprint library
cause a crash, with the following message:

Error Signature ---------------------
Appname: test.exe
AppVer: 8.4.2.9
ModName: tcl84.dll
ModVer: 8.4.2.6
Offset: 000399df

The above was generated using a pre-built Tclkit that returns "8.4.9" for
[set tcl_patchLevel].

Interestingly, the same commands that work during a particular run, will
cause a crash during a different run - it's not entirely consistent. The
test app is *very* simple.  Basically, it just requires the ezprint dll,
period.  Then I am entering ezprint commands in the console to cause the
crash, so I definitely think it's related to interaction between the wrapped
code and the ezprint lib.

Anyway, I've got some more testing to do, but does anyone have any immediate
ideas?

Thanks,


Jeff

Last time I faced a similar error, was due to a direct dependency of
an extension with the tcl dll. It was not using stubs.
Any extension that is not stubs enabled will crash
when loaded in a starkit, as the tcl/tk dll won't be found.

George

"Jeff Godfrey" <jeff_godfrey@pobox.com> wrote in message
news:10sm4m66n7uuhf1@corp.supernews.com...
> Hi All,
>
> I have an application developed for WinXP that makes use of the ezprint
> library (http://lbayuk.home.mindspring.com/ezprint/).
>
> When run as pure tcl code, the application works correctly, but when
> wrapped as a starpack, some of the commands associated with the ezprint
> library cause a crash, with the following message:
>
> Error Signature ---------------------
> Appname: test.exe
> AppVer: 8.4.2.9
> ModName: tcl84.dll
> ModVer: 8.4.2.6
> Offset: 000399df
>
> The above was generated using a pre-built Tclkit that returns "8.4.9" for
> [set tcl_patchLevel].
>
> Interestingly, the same commands that work during a particular run, will
> cause a crash during a different run - it's not entirely consistent. The
> test app is *very* simple.  Basically, it just requires the ezprint dll,
> period.  Then I am entering ezprint commands in the console to cause the
> crash, so I definitely think it's related to interaction between the
> wrapped code and the ezprint lib.
>
> Anyway, I've got some more testing to do, but does anyone have any
> immediate ideas?
>
> Thanks,
>
>
> Jeff
>

----- Original Message -----
From: "Georgios Petasis" <petasis@iit.demokritos.gr>
Newsgroups: comp.lang.tcl
Sent: Thursday, December 23, 2004 12:53 PM
Subject: Re: ezprint library crashes tcl84.dll when wrapped as starpack?


> Last time I faced a similar error, was due to a direct dependency of
> an extension with the tcl dll. It was not using stubs.
> Any extension that is not stubs enabled will crash
> when loaded in a starkit, as the tcl/tk dll won't be found.
>
> George

George,

Thanks for the response.

Though my C is very rusty, the extension ships with the C source code (just
a single file).  What can I look for in the source to verify whether it uses
stubs or not?  Assuming it doesn't, are you saying that it will never work
within a starpack?  If that's true, is there some kind of roadmap for
converting the code to stubs?

Thanks for any additional info.

Jeff

"Jeff Godfrey" <jeff_godfrey@pobox.com> wrote in message
news:10sm5df8a9t6ec3@corp.supernews.com...
> ----- Original Message -----
> From: "Georgios Petasis" <petasis@iit.demokritos.gr>
> Newsgroups: comp.lang.tcl
> Sent: Thursday, December 23, 2004 12:53 PM
> Subject: Re: ezprint library crashes tcl84.dll when wrapped as starpack?
>
> 
>
> George,
>
> Thanks for the response.
>
> Though my C is very rusty, the extension ships with the C source code
> (just a single file).  What can I look for in the source to verify whether
> it uses stubs or not?  Assuming it doesn't, are you saying that it will
> never work within a starpack?  If that's true, is there some kind of
> roadmap for converting the code to stubs?
>
> Thanks for any additional info.
>
> Jeff

Well, it seems that George's hunch was correct.  The lib was crashing
because it was not "stubs enabled".  After much Googling, I was able to
figure out what to change in the source (the easy part), and how to rebuild
the dll (the hard part).  Anyway, I now have a stubs enabled version of
ezprint that appears to no longer crash unexpectedly.

Thanks,

Jeff

jeff_godfrey@pobox.com wrote:
>...
>
> Well, it seems that George's hunch was correct.  The lib was crashing
> because it was not "stubs enabled".  After much Googling, I was able to
> figure out what to change in the source (the easy part), and how to rebuil
d
> the dll (the hard part).  Anyway, I now have a stubs enabled version of
> ezprint that appears to no longer crash unexpectedly.

I only have access to the Borland compiler, and I'm pretty sure it is
impossible to build a stubs-enabled application with this compiler using
the MSC-built Tcl from ActiveState. That's why it isn't stubs enabled. If
the patches you sent me (thanks!) don't break Borland building, I can patch
the source code at least, to make it easier for someone else to build it
with stubs.

I am glad that you solved the problem. Perhaps you already know it,
but is a very nice tool, named Dependency Walker
(http://www.dependencywalker.com/), that will reveal
*all* dependences of any exe/dll file.

The tool is so great that it gets even included in the Visual C++
releases. I find it extremely handly for similar cases
(i.e. why this extension fails when loaded through "load" :-))

Best wishes,

George


"Jeff Godfrey" <jeff_godfrey@pobox.com> wrote in message
news:10smfsbolpeane9@corp.supernews.com...
> "Jeff Godfrey" <jeff_godfrey@pobox.com> wrote in message
> news:10sm5df8a9t6ec3@corp.supernews.com... 
>
> Well, it seems that George's hunch was correct.  The lib was crashing
> because it was not "stubs enabled".  After much Googling, I was able to
> figure out what to change in the source (the easy part), and how to
> rebuild the dll (the hard part).  Anyway, I now have a stubs enabled
> version of ezprint that appears to no longer crash unexpectedly.
>
> Thanks,
>
> Jeff
>
>