How to access a DLL in Tcl/Win32 ?
Exchange CAPITALS for correct address
confusion, the more i read about DLL access.
Until now, i have made my GUI based programming with Delphi and
Autohotkey, and accessing DLLs was no more than call LoadLibrary() and
GetProcedureByName(). But i would like to switch to Tcl, because it
supports Linux too.
So i digged through my two books about Tcl, where i found nothing and
then i looked around on internet, where i consulted the wiki and i got
lots of information, which talks about packages and starkits and ....
and i understand nothing.
Is it really so much more complicated to access DLLs in Tcl than in
other programming languages or am i just mentally blocked by a lot of
unknown buzzwords ???
Any help appreciated.
Best regards
Klaus
P.S. My programming experience with AHK and Delphi is just as small as
my knowledge of Tcl, because i try to avoid Windows wherever i can,
but as a moderately skilled C- and assembler programmer acces to DLLs
was just a piece of cake in these languages.
nedbrek
"Exchange CAPITALS for correct address" <Slaus.Ke...@gmx.de> wrote in
message news:4if6m513idrq3sbrq...@4ax.com...
>
> Is it really so much more complicated to access DLLs in Tcl than in
> other programming languages or am i just mentally blocked by a lot of
> unknown buzzwords ???
>
Tcl is very flexible, there are a number of different ways to go about
things, depending on what you are looking for.
Fundamentally, Tcl is just going to execute commands. If you have
functionality in C, it must be connected to a Tcl command. You might use a
wrapper which can load the DLL, and export the needed functionality to Tcl.
See Tcl_CreateNewCommand.
Is the DLL built from code you have? If so, you can include the Tcl adapter
code in it. If it is called mydll.dll, then create a function:
extern "C" // for C++ or Pascal/Delphi
int Mydll_Init(Tcl_Interp *interp); // may need declspec(dllexport)
In Tcl:
% load mydll.dll
Then that init function is called. Whatever else you do, make sure to
create a new command ("mycmd"), and attach whatever state you need with it.
Then in Tcl:
% mycmd args
Will transfer back to your code.
----
It may be worthwhile to simply export the dlopen functionality to Tcl...
there may be an existing project for that. A quick googling didn't turn
anything up...
Hope that helps,
Ned
Jan Kandziora
> But i would like to switch to Tcl, because it
> supports Linux too.
>
> Is it really so much more complicated to access DLLs in Tcl than in
> other programming languages or am i just mentally blocked by a lot of
> unknown buzzwords ???
>
libraries is a no-go when doing cross-platform development. So the obvious
advice is to throw away anything you know about software development for
MS-Windows and do the whole thing entirely in Tcl.
Kind regards
Jan
Alexandre Ferrieux
While 100% seconding Jan's wise words, let me just mention "ffidl" for
the case where you really have your dynamic library in both
environments (a .dll and a .so):
Ffidl lets Tcl call into an arbitrary dynalic library, not one
instrumented for Tcl specifically. The price to pay is getting the
arguments' types right of course.
-Alex
Roger O
used it to great effect. It parses the C functions and data structures
in your C header files and makes a Tcl interface to the defined
functions and structures.
I will have to explore ffidl. It, too, looks promising.
-
Roger Oberholtzer
Exchange CAPITALS for correct address
<alexandre...@gmail.com> wrote:
>While 100% seconding Jan's wise words...
please see my reply to Jan :-)
> let me just mention "ffidl" for
>the case where you really have your dynamic library in both
>environments (a .dll and a .so):
Thanks for Your hint. Unfortunately ffidl is just one of these things,
i find unuseable at the moment, because they are too complicated
for me. Maybe within one or two years i can manage this, but i need
to do the first step before the second, i.e. i need to learn, how to
access a DLL the simple way, then i can upgrade to ffidl.
By the way, there was a discussion about ffidl and possible
errors in it on comp.lang.forth some time ago, because Gforth also
uses ffidl as foreign library interface. So for sure i will avoid it,
until i know, that i can master it. I do not want to look for
other peoples errors, i want to do my own errors :-))
>The price to pay is getting the arguments' types right of course.
For a C and assembler programmer this is no surprise.
Thanks again
Klaus
Exchange CAPITALS for correct address
wrote:
>...
>Tcl is very flexible, there are a number of different ways to go about
>things, depending on what you are looking for.
I just want to start with the simplest way available :-)
>
>Fundamentally, Tcl is just going to execute commands. If you have
>functionality in C, it must be connected to a Tcl command. You might use a
>wrapper which can load the DLL, and export the needed functionality to Tcl.
>See Tcl_CreateNewCommand.
This seems to be the first step, i was missing so far, assigning a
start address to a command name.
>Is the DLL built from code you have? If so, you can include the Tcl adapter
>code in it. If it is called mydll.dll, then create a function:
>extern "C" // for C++ or Pascal/Delphi
>int Mydll_Init(Tcl_Interp *interp); // may need declspec(dllexport)
The most important DLL is made from my own code. If it is necessary, i
can reach each and every foreign DLL from here, because it is written
in C and i can extend it. But introducing new names in this DLL
requires to relink all my C-programs, because they use static loading
at start time. And i really do not like to put Tcl-specific code into
a library for general use (it is used by C-, Forth, Delphi- and
AutoHotKey-programs). If it is unavoidable, i can live with it, but i
count it as a big minus for Tcl. I loose overview, if things are
spread across too much places. The basic design idea behind this DLL
is the construction of a message passing system, which allows to
spread the necessary functionality across a bunch of separate tasks,
each maintained by a single programmer, who is free to choose his
favourite programming language to do the job. And the responsible for
the whole program does not need to know _any_ programming language, he
just knows, which messages have to go in and out and he can identify
an erroneous program by comparing input and output messages.
>In Tcl:
>% load mydll.dll
Are You sure, that this is really called "load" ? A search for "load"
in Tcls wiki turns up a lot of different items.
>Then that init function is called. Whatever else you do, make sure to
>create a new command ("mycmd"), and attach whatever state you need with it.
What does "state" mean ?
>Then in Tcl:
>% mycmd args
>Will transfer back to your code.
Isn't it possible to make the initialization code inside Tcl? Why do i
need to do it inside the DLL?
>
>It may be worthwhile to simply export the dlopen functionality to Tcl...
>there may be an existing project for that. A quick googling didn't turn
>anything up...
>
>Hope that helps,
>Ned
Thank You, Ned. At least i am one step ahead, although i still do have
a lot more questions than answers. At the moment mastering Tcl seems
to consume more time than i can ever gain by using Tcl.
But in a Tcl newsgroup i probably should not ask for better
alternatives ;-))
Best regards
Klaus
Exchange CAPITALS for correct address
>You wont have MS-Windows DLLs at hand on Linux anyway. Using external
>libraries is a no-go when doing cross-platform development.
You should add a smiley for Your nice joke :-)
There are kids out there, which have never heard about the
magic word "abstraction layer" and may keep You serious ;-)
>So the obvious
>advice is to throw away anything you know about software development for
>MS-Windows and do the whole thing entirely in Tcl.
And after this is done, we only have the problem, that my application
needs data as input. And guess, how this done!
Bingo, congratulations! You have solved the riddle in the first try,
it is a shareable library in Win32-DLL-format or Unix-so-format.
Now we only need to know.... oh holy shit, wasn't this
the original question :-D ???
Good morning Jan.
Thank You very much, You made me smile.
Best regards
Klaus
Alexandre Ferrieux
<Slaus.Keegeba...@gmx.de> wrote:
>
>
> > let me just mention "ffidl" for
> >the case where you really have your dynamic library in both
> >environments (a .dll and a .so):
>
> Thanks for Your hint. Unfortunately ffidl is just one of these things,
> i find unuseable at the moment, because they are too complicated
> for me. Maybe within one or two years i can manage this, but i need
> to do the first step before the second, i.e. i need to learn, how to
> access a DLL the simple way, then i can upgrade to ffidl.
Sorry, I don't get it. In a nearby post you say that you don't want to
"spoil" your beautifully generic code with Tcl-specific glue. I
understand this argument perfectly. Then you say that you are used to
calling it from other scripting languages directly. Hence, these
languages have a generic dlopen() gateway. Very good.
Then I give you the name of the generic dlopen() gateway for Tcl,
which is ffidl. And you say it is too complicated ?
This I don't understand: sheer logic indicates that in _any_ language,
calling a foreign dynamic library implies wrapping one's head around
the types in the prototype, and bridging whatever gap exists between
the C types and the host language's ones.
That is exactly what the main call in the ffidl API does:
::ffidl::callout name {?arg_type1 ...?} return_type $address
(where $address is obtained through ::ffidl::symbol).
Now please explain: what, in these other scripting languages, makes
calling arbitrary functions enromously simpler than the above line ?
> By the way, there was a discussion about ffidl and possible
> errors in it on comp.lang.forth some time ago, because Gforth also
> uses ffidl as foreign library interface. So for sure i will avoid it,
> until i know, that i can master it. I do not want to look for
> other peoples errors, i want to do my own errors :-))
Beware of hasty decisions. Ffidl is really a Tcl-specific wrapper
above libffi, which is the real worker for cross-platform dynamic
calling.
What you have in Gforth is a similar wrapper specific to Forth, which
may have its own personal bugs. Unimpressed ;-)
> For a C and assembler programmer this is no surprise.
Then maybe you can also comment on the suggestion of SWIG which was
made in this thread.
Of course this means building a (eeeeek!) Tcl-specific wrapper, though
automatically.
You then will have to decide between
(a) mastering the straightforward syntax of ffidl and directly
calling your pristine dll/so
(b) using the automated SWIG tool and building a Tcl wrapper, which
you'll then [load].
-Alex
nedbrek
"Exchange CAPITALS for correct address" <Slaus.Ke...@gmx.de> wrote in
message news:jg6dm5hgthuhcoar8...@4ax.com...
> On Fri, 29 Jan 2010 18:44:02 -0500, "nedbrek" <ned...@yahoo.com>
> wrote:
>>...
>>Tcl is very flexible, there are a number of different ways to go about
>>things, depending on what you are looking for.
>
> I just want to start with the simplest way available :-)
>
Understandable :)
>>Is the DLL built from code you have? If so, you can include the Tcl
>>adapter
>>code in it. If it is called mydll.dll, then create a function:
>>extern "C" // for C++ or Pascal/Delphi
>>int Mydll_Init(Tcl_Interp *interp); // may need declspec(dllexport)
>
> The most important DLL is made from my own code. If it is necessary, i
> can reach each and every foreign DLL from here, because it is written
> in C and i can extend it. But introducing new names in this DLL
> requires to relink all my C-programs, because they use static loading
> at start time. And i really do not like to put Tcl-specific code into
> a library for general use (it is used by C-, Forth, Delphi- and
> AutoHotKey-programs). If it is unavoidable, i can live with it, but i
> count it as a big minus for Tcl. I loose overview, if things are
> spread across too much places.
Ok, if you are loading DLL's from a DLL, then you should be able to create a
new DLL which will be loaded by Tcl. Then it can load all the others, as
needed.
>>In Tcl:
>>% load mydll.dll
>
> Are You sure, that this is really called "load" ? A search for "load"
> in Tcls wiki turns up a lot of different items.
Yes, make sure to check the man pages or .hlp file first. I downloaed the
HTML version of the man pages, and keep a bookmark in Firefox. I often have
a whole window filled up with tabs (one for Tcl, one for Tk, one for the C
API, and some wiki tabs).
"load - Load machine code and initialize new commands"
The alternative is to use a package (package require), but that is more
complicated...
>>Then that init function is called. Whatever else you do, make sure to
>>create a new command ("mycmd"), and attach whatever state you need with
>>it.
>
> What does "state" mean ?
I have a Tcl program that interfaces to some C++ code. Here is my init
function (for nstclgui.so):
extern "C"
int Nstclgui_Init(Tcl_Interp *interp)
{
initNameArrays(); // initialize global variables
NewStarsTcl *nstp = new NewStarsTcl; // class to interface to C++
nstp->setEnums(interp); // class method to populate some Tcl variables
using Tcl_SetVar
// create the Tcl command
Tcl_CreateObjCommand(interp, "newStars", generate, nstp, destructor);
return TCL_OK;
}
The NewStarsTcl object "nstp" is my "state". It is passed to every command
callback (the fourth argument in create command). It stores everything I
need to remember in between calls from Tcl (mostly file handles, and some
cached info extracted from the C++ data structures).
"generate" is my command handler, and "destructor" is called when Tcl
unloads the dll.
>>Then in Tcl:
>>% mycmd args
>>Will transfer back to your code.
>
> Isn't it possible to make the initialization code inside Tcl? Why do i
> need to do it inside the DLL?
You can do whatever you like in Tcl or the _Init function. "mycmd" will
call your version of "generate". So it is responsive to user input (say a
script attached to a dialog).
> Thank You, Ned. At least i am one step ahead, although i still do have
> a lot more questions than answers. At the moment mastering Tcl seems
> to consume more time than i can ever gain by using Tcl.
> But in a Tcl newsgroup i probably should not ask for better
> alternatives ;-))
It takes a while to get used to doing things "the Tcl way" :) Once you do,
you'll find you are a lot more productive.
Ned
Exchange CAPITALS for correct address
wrote:
snip....snip
>"load - Load machine code and initialize new commands"
>
>The alternative is to use a package (package require), but that is more
>complicated...
I do not have the smallest idea, how to use a package.
I tried load and it produced a real error message: it wants to have
Mydll_init(). I wrote Mydll_Init() { sleep( 2 seconds); return(0).}
and a tcl window popped up after 2 seconds. First problem solved.
>>>Then that init function is called. Whatever else you do, make sure to
>>>create a new command ("mycmd"), and attach whatever state you need with
>>>it.
I read about this function (i also saw,that i should include tcl.h),
but once again i do not have the smallest idea, where to get it.
>> What does "state" mean ?
>I have a Tcl program that interfaces to some C++ code. Here is my init..
Aaah, i see. My routines are all stateless, so i just enter 0.
>It takes a while to get used to doing things "the Tcl way" :) Once you do,
>you'll find you are a lot more productive.
This was the reason, why i have choosen it. In the moment, it is just
the opposite. I hope i find the solution before i loose patience :-)
I now have already spent more time to access a DLL than i have needed
to learn to write one!
Thanks again for Your help
Klaus
Exchange CAPITALS for correct address
<alexandre...@gmail.com> wrote:
>Sorry, I don't get it. In a nearby post you say that you don't want to
>"spoil" your beautifully generic code with Tcl-specific glue. I
>understand this argument perfectly. Then you say that you are used to
>calling it from other scripting languages directly. Hence, these
>languages have a generic dlopen() gateway. Very good.
>Then I give you the name of the generic dlopen() gateway for Tcl,
>which is ffidl. And you say it is too complicated ?
If You reread my posting carefully, You will see, that i said: it is
too complicated for me. In the country, where i am living, this makes
a big difference. And please reread my first sentence of my first
posting, where i wrote: As a newbie in Tcl...
Is it now better understandable?
>This I don't understand: sheer logic indicates that in _any_ language,
>calling a foreign dynamic library implies wrapping one's head around
>the types in the prototype, and bridging whatever gap exists between
>the C types and the host language's ones.
I agree wholeheartedly. But documentation differs in quality.
Unfortunately, i do not find in the moment the example i wanted to
show You. I evaluated Swiftforth two months ago and they gave a
perfect description for their DLL-interface in 50 lines of text and
examples. Within half an hour i had an UDP interface up and running an
could transfer data to a second computer. For a Tcl interface i have
at least read already 50 *pages* of text and still do not get it.
I have no problem to admit, that this is *my* stupidity. This is why i
asked for help.
>That is exactly what the main call in the ffidl API does:
>
> ::ffidl::callout name {?arg_type1 ...?} return_type $address
>
>(where $address is obtained through ::ffidl::symbol).
What do You think will happen, when i enter these phrases into
my tcl-window ? I suppose i will understand the error messages as well
as these commands.
>Now please explain: what, in these other scripting languages, makes
>calling arbitrary functions enromously simpler than the above line ?
A description of 50 lines of text, which explain the 2 lines of code.
>Beware of hasty decisions. Ffidl is really a Tcl-specific wrapper
>above libffi, which is the real worker for cross-platform dynamic
>calling.
>What you have in Gforth is a similar wrapper specific to Forth, which
>may have its own personal bugs. Unimpressed ;-)
This why i started my comment with:by the way...
It is a hint, not more. For me it gives the warning, that there could
be more pitfalls, than i can master.
As ffidl claims to be a universal tool, i am simply a bit frightened.
I am walking on unknown territory and try to avoid complexity,
wherever i can.
>> For a C and assembler programmer this is no surprise.
>
>Then maybe you can also comment on the suggestion of SWIG which was
>made in this thread.
>Of course this means building a (eeeeek!)
I like Your sarcasm, really, but it shows also, that You did *not*
perfectly understand, as You have claimed before. The problem is not
the additional code, but the additional name in the namespace of the
DLL, which leads to a rearrangement of the relation between the
routines and their ordinal number, which then leads to the fact, that
those programs, which use this DLL statically linked, will enter wrong
function until i relink them all. As i am a lazy guy, i see this as
rather unnecessary work, and i normally hate unnecessary work.
>Tcl-specific wrapper, though
>automatically.
>You then will have to decide between
>
> (a) mastering the straightforward syntax of ffidl and directly
>calling your pristine dll/so
>
> (b) using the automated SWIG tool and building a Tcl wrapper, which
>you'll then [load].
>
>-Alex
Alex, i appreciate any help, i can get. But throwing in some
impressive phrases, which demonstrate, that You are the absolute
expert will help me as much as Jans proposal to rewrite all programs
in Tcl. With my knowledge of Tcl! This is not a playground programm,
where i can only destroy some bytes, there is a real machine behind
this program which can easily make half a million of bucks damage.
My momentary solution is a TCP-link to wrapper programs, which then
transfer the messages to the mailbox system. This is neither effective
nor elegant. It is just one level of indirection more than necessary
and lead to delays, because programs are scheduled independently. If
it were a realtime OS, i would have less problems, but it is XP and
its granularity is around 10 ms, this means i am at the limit.
In the ffidl description i found the following:
>Ffidl uses Tcl's TclpDlopen() and TclpFindSymbol(), to load dynamic
> libraries and discover the locations of functions.
These could be the two functions, i am looking for. But the
documentation is just as chaotic as all documentation i have found for
this area. From my impression this is all still "chantier" (i do not
know the english word, i hope Your french is better than my english).
Best regards
Klaus
Roger O
Surely running SWIG on the header files of the DLL to access is not so
very hard. SWIG does all the grunt work. You then call the functions
in the DLL with the same names and Tcl-ized arguments as in the C/C++
code that is presumably also using this DLL. SWIG even goes one step
further and makes an interface to the data structures defined in the
header files, not just the functions.
In the simplest case, it is one command that makes a bit of C code you
compile. Then, load your untouched DLL, and then load this wrapper.
Then get to work.
I think the discussion here was more work/time than generating a Tcl
interface from SWIG...
--
Roger Oberholtzer
Alexandre Ferrieux
<Slaus.Keegeba...@gmx.de> wrote:
>
> Alex, i appreciate any help, i can get. But throwing in some
> impressive phrases, which demonstrate, that You are the absolute
> expert will help me as much as Jans proposal to rewrite all programs
> in Tcl.
Sorry, did my best to hilight the important questions. If it gets
emotional this fast, I prefer to give up. Fare well !
> With my knowledge of Tcl! This is not a playground programm,
> where i can only destroy some bytes, there is a real machine behind
> this program which can easily make half a million of bucks damage.
Ah, what kind of company is that, where a Tcl newbie is assigned the
Tcl port of such a serious thing...
Defense ? Nuclear power plant ? Chilling...
-Alex
nedbrek
"Exchange CAPITALS for correct address" <Slaus.Ke...@gmx.de> wrote in
message news:7vvem5huou17rgled...@4ax.com...
> On Mon, 1 Feb 2010 08:14:19 -0500, "nedbrek" <ned...@yahoo.com>
> wrote:
>>>>Then that init function is called. Whatever else you do, make sure to
>>>>create a new command ("mycmd"), and attach whatever state you need with
>>>>it.
>
> I read about this function (i also saw,that i should include tcl.h),
> but once again i do not have the smallest idea, where to get it.
"mycmd" is just an example. It is whatever you pass in as the second
argument to Tcl_CreateObjCommand
Tcl_CreateObjCommand(interp, "mycmd", myCallback, NULL, NULL);
Ned
Jan Kandziora
>
> needs data as input. And guess, how this done!
>
development kit. Things other people already developed and put it into the
environment.
> Now we only need to know.... oh holy shit, wasn't this
> the original question :-D ???
>
You forgot? Here it is:
>
> "Until now, i have made my GUI based programming with Delphi and
> Autohotkey, and accessing DLLs was no more than call LoadLibrary()
> and GetProcedureByName()."
>
Fine thing. Use ffidl, like Alex told you.
> "But i would like to switch to Tcl, because it supports Linux too."
>
Does not compute. You won't get any benefit from Tcl being available on both
platforms if your program relies on platform-specific libraries. You could
have said "I'd like to use C++ because it supports Linux, too.".
Kind regards (though kindness is futile here)
Jan
Exchange CAPITALS for correct address
>Sockets + pure Tcl library. Or other things that are already in the Tcl
>development kit. Things other people already developed and put it into the
>environment.
I do not know, how i can use sockets in Tcl. I use built-in TCP as an
intermediate solution. But i need UDP as well. And the acces to
my customers database is only available as a Win32-DLL or as a
Linux-so. Although this itself uses TCP, i am not allowed to do so.
This is why i made my question for help. I am using Tcl-Coach, which
is very nice environment to start with Tcl. It has a good tutorial ( i
think in german only), but i did not find any extensions until now.
Even the file tcl.h, which i would need according to Neds proposal is
not there. But it can do standalone executables, which is necessary
for me.
>Fine thing. Use ffidl, like Alex told you.
Repeating buzzwords does not help. As i told, i had already searched
the internet before, and had found things like ffidl, swig and
serveral more, where i do not remember the names.
As i stated in my first posting, these things are all looking too
complicated to be used by me. Maybe You can give me a hint, how i have
to use them. Alex already felt offended, when in my despair i asked
him to clarify the use of ffidl. Putting some punctuation and
parentheses around the buzzwords only looks arrogant to me.
Sorry if this is too rude, i do not know how to express this more
kindly, the german word is "verscheissern", but babelfish and my
dictionary both do not know this word.
But i should not complain, it is the fate of the beginners to be the
destination of bad jokes.
Nevertheless there _must_ be a way, to access dynamic libraries. ffidl
does this, so maybe i have to dig through the sources of ffidl to find
the basics. Each and every computer language i have used so far, has a
possibility to access the underlying OS. Otherwise it is seriously
crippled. If i can not get Tcl to do this, it goes to the trashcan. My
brain is already proposing this since some time. Its only my heart,
which says: give Tcl one more try.
>Does not compute. You won't get any benefit from Tcl being available on both
>platforms if your program relies on platform-specific libraries. You could
>have said "I'd like to use C++ because it supports Linux, too.".
This seems to be the basic wrong assumption, You are making FMPOV.
I rely on on platform-specific libraries, which are available on Win32
as on Linux (and DOS and Mac-OS and and... ). Look for the
IP-Interface as an example. It is made by a system-DLL on Windows,
which comes with Windows, so it is clearly a system DLL. But it
presents the same interface to the user as Linux does (and how i have
used it on DOS, where it was an external program). So for to the lower
side (to the system) they are different (platform-specific), but to
the upper side (to the user or calling program or however You call it)
they are more ore less identical. Not totally, but rather. And the
necessary call to WSAstartup() can be done by providing an empty
routine on Linux without too much effort :-)
This is, what _i_ call portability. An underlying abstraction layer,
which gives me the same functionality on all systems. My programs are
running equally on DOS and on Win32, all i had to change, is the
mechanism of calling. In DOS, i had to link a static library, in Win32
i can choose, if i link statically or load dynamic. The names of the
routines and the arguments are all identical, even the errorcodes.
Maybe ffidl can give me, what i need. But ffidl has to use some
underlying mechanism to acess the system. And this is what i need to
learn first. Then i can use ffidl as an upgrade. I do not want
"muddling through" ( "Hey, my work is so secret that i myself do not
know, what i am doing here!"). I know that a lot of people like this
approach. I do not.
Thanks for Your efforts and kind regards
Klaus
P.S. kindness is _never_ futile, it always makes the world better.
Exchange CAPITALS for correct address
wrote:
>"mycmd" is just an example. It is whatever you pass in as the second
>argument to Tcl_CreateObjCommand
>Tcl_CreateObjCommand(interp, "mycmd", myCallback, NULL, NULL);
Sorry, this was badly expressed. I meant Tcl_CreateObjCommand().
It should be in a library, but i seem not to have any libraries, nor
do i have the necessary tcl.h.
I am using Tcl-Coach 2.5, whis has a nice tutorial (in german, good
for me) and the capability to produce standalone executables. Just
what a beginner like me needs.
Best regards
Klaus
APN
already rejected ffidl for whatever reason. It is simple enough to
use. The example below is condensed from http://wiki.tcl.tk/4016 and
may need some tweaking -
load ffidl05.dll ;# load the ffidl package
set DLL AutoItDLL.dll ;# save instead of retypeing this name in for
each function
# This dll needs to be in the path or system directory (so it is found
by ffidl)
# Define the function you want to call
ffidl::callout AUTOIT_WinMinimizeAll {} int [ffidl::symbol $DLL
AUTOIT_WinMinimizeAll]
# Now call it
AUTOIT_WinMinimizeAll
http://wiki.tcl.tk/16697 also contains another more complete example
of calling an "arbitrary" DLL from Tcl
/Ashok
Exchange CAPITALS for correct address
I suppose that You are absolutely right :-))
But unfortunately SWIG claims to miss Win98 support.
Did You ever here the sentence:
The software is getting slow faster than the hardware is getting fast?
This is why i stay with Win98 as long as i can.Whenever computers are
fast enough for me to run Win2000 i will have a second look to SWIG.
Thanks and best regards
Klaus
Uwe Klein
> On Wed, 03 Feb 2010 19:46:28 +0100, Jan Kandziora <j...@gmx.de> wrote:
>
>
>>Sockets + pure Tcl library. Or other things that are already in the Tcl
>>development kit. Things other people already developed and put it into the
>>environment.
>
>
> I do not know, how i can use sockets in Tcl. I use built-in TCP as an
> intermediate solution. But i need UDP as well.
I may have got this wrong but:
There is tcludp
http://wiki.tcl.tk/8493
and the
udp command from scotty ( though dated )
http://wiki.tcl.tk/220
uwe
Exchange CAPITALS for correct address
<alexandre...@gmail.com> wrote:
>Sorry, did my best to hilight the important questions. If it gets
>emotional this fast, I prefer to give up. Fare well !
Sorry for offending You, this was not my intention.
I just thought, that decorating a buzzword with more punctuation and
parentheses to make the things even more ununderstandable is a very
bad joke. I am still asking myself if You did this, because You
yourself do not know ffidl good enough to give more advice, or because
You like bad jokes.
>Ah, what kind of company is that, where a Tcl newbie is assigned the
>Tcl port of such a serious thing...
>Defense ? Nuclear power plant ? Chilling...
I like Your sarcasm :-))
I never said that i was assigned to port the whole program to Tcl.
This was the proposal of Jan, which You called "wise words" and 100%
supported him. Maybe You have changed Your mind ? Or like to give
answers before reading question (attention:sarcasm!)?
Tcl was used to make the user interface (GUI) and it was done by my
brother, who is a beginner in Tcl _and_ in programming and he made a
real nice job in short time. Tcl is now talking to the other tasks
(the program is made from around 15 different tasks) via TCP. But as
all other tasks are talking via shared memory, i would like Tcl to use
the same channel and avoid the additional task of translating from TCP
as there are already enough tasks started. The machine is a 2KW laser
with production environment and You can burn nice holes in Your brain
and it is useable to make a tattoo as well as an industrial heater
(900 Kelvin) is useable for drying hair, the smell is similar!
The customer made no rules for the programming languages, so i was
free to choose whatever is appropriate and it was me to make the
decision for Tcl. Now don't tell me that this was bad ;-)
Best regards
Klaus
Alexandre Ferrieux
<Slaus.Keegeba...@gmx.de> wrote:
>
> Sorry for offending You, this was not my intention.
> I just thought, that decorating a buzzword with more punctuation and
> parentheses to make the things even more ununderstandable is a very
> bad joke.
What are you talking about ? What buzzword ? What punctuation ? What
parentheses ?
-Alex
Exchange CAPITALS for correct address
<alexandre...@gmail.com> wrote:
>What are you talking about ? What buzzword ? What punctuation ? What
>parentheses ?
::ffidl::callout name {?arg_type1 ...?} return_type $address
(where $address is obtained through ::ffidl::symbol).
Best regards
Klaus
Exchange CAPITALS for correct address
wrote:
>I haven't gone through the entire thread so forgive me if you have
>already rejected ffidl for whatever reason...
I rejected ffidl, because i did not understand it.
Thanks for Your short explanation. I am starting to understand now.
Best regards
Klaus
Exchange CAPITALS for correct address
<uwe_klein_...@t-online.de> wrote:
>I may have got this wrong but:
>
>There is tcludp
> http://wiki.tcl.tk/8493
>and the
>udp command from scotty ( though dated )
> http://wiki.tcl.tk/220
Thank You for the hints.
Best regards
Klaus
Alexandre Ferrieux
> >What are you talking about ? What buzzword ? What punctuation ? What
> >parentheses ?
>
> ::ffidl::callout name {?arg_type1 ...?} return_type $address
> (where $address is obtained through ::ffidl::symbol).
Look again: this syntax is simply the one I copied/pasted from the URL
I already gave you !!!
You'll have to make an effort: scroll down near 25% of that page...
:: is not an insulting punctuation, it is Tcl's namespace separator
{??} is not an insulting pair of parentheses, it just indicates
optional arguments in that page
So, you felt insulted by technical syntax ? You can't be bothered to
read a manpage ? You have difficulties telling apart the messenger
from the message ?
And you're driving a 2kW laser ? Help !!!!!!!!!
-Alex
Exchange CAPITALS for correct address
<alexandre...@gmail.com> wrote:
>> �::ffidl::callout name {?arg_type1 ...?} return_type $address
>> (where $address is obtained through ::ffidl::symbol).
>
>Look again: this syntax is simply the one I copied/pasted from the URL
>I already gave you !!!
>
> http://elf.org/ffidl/
>
>You'll have to make an effort: scroll down near 25% of that page...
I said from the very beginning, that these things look too
complicaticated to me and although i did not explicitely mention
ffidl, it was obviously included. What i am looking for is the basic
mechanism to access DLLs, not fancy tools, which hide this.
> :: is not an insulting punctuation, it is Tcl's namespace separator
Thanks, this is useful information.
> {??} is not an insulting pair of parentheses, it just indicates
>optional arguments in that page
>
>So, you felt insulted by technical syntax ?
No, i feel bored by hearing the same buzzwords, which point to the
wrong direction, over and over again. And naming it a bad joke was the
most polite manner i could find to express this.
>You can't be bothered to read a manpage ?
Since the invention of unixtime man-pages have been the swapspace
of the human brain, i.e. a help only for those, who already know
everything, but can't keep everything inside their memory.
For beginners manpages have always been a PITA.
Do You think You will understand my laser when i give You its
reference manual?
>You have difficulties telling apart the messenger from the message ?
Do You really think i would talk to You if i had?
>And you're driving a 2kW laser ? Help !!!!!!!!!
Congratulations, You start to get it. My machine is complex enough
that it does not need unnecessary complexity from programming
languages. This is _one_ of several steps to security.
So either Tcl _can_ give direct access to DLLs or it is too crippled
for my needs.
Best regards
Klaus
Alexandre Ferrieux
<Slaus.Keegeba...@gmx.de> wrote:
>
> So either Tcl _can_ give direct access to DLLs or it is too crippled
> for my needs.
Programming takes certain skills, just like painting or cooking.
Either you make an effort to gain those skills, or you give up the
field. There're several really good programmers around this newsgroup
who are seeking employment. I'd frankly rather see _them_ bore holes
with a Tcl-controlled laser.
-Alex
vinilk...@gmail.com
am new to tcl scripting.
any please help me, how to access c function in tcl script.
hae
the tcl wiki is a good source. Look for dll or ffidl.