1. include abc.dll - any volunteers?
- Posted by Mike <vulcan at win.co??z>
Jan 08, 2008
-
Last edited Jan 09, 2008
Would there be much use for a tool that could read a dll file and produce a
listing of variables and routines? I know I'd like to have such a capability
added to Orac enabling a user to include such libraries seamlessly.
Thoughts?
regards,
Mike
2. Re: include abc.dll - any volunteers?
- Posted by Pete Lomax <petelomax at bl?eyonder?co.uk>
Jan 08, 2008
-
Last edited Jan 09, 2008
Mike wrote:
>
> Would there be much use for a tool that could read a dll file and produce a
> listing of variables and routines? I know I'd like to have such a capability
> added to Orac enabling a user to include such libraries seamlessly.
>
> Thoughts?
>
Sorry, I meant to email you about this ages ago, but never got round to it.
I don't think there's enough info. I actually have some code that will extract
the names, but couldn't find any info about the number of parameters or their
types, etc. Running Dependency Walker on say kernel32.dll also gives very limited
info, so I'm pretty certain it simply ain't there.
Instead I think you should aim to make say abc.dlx that contains such, whether a
bunch of define_c_func constants or a csv-style text file.
I wonder if there is any way to blag such things from std c header files?
Does say Watcom automatically know about AllocConsole or does it load details
from a file? (Or am I wrong and does it learn from kernel32.dll?)
For that matter does Watcom give a proper compilation error if you pass
AllocConsole the wrong number of parameters, or does it just let it bomb at
run-time?
I am of course worried about how useful it would really be to know there is a
LoadResource routine, but no idea what parameters it takes or what result it
returns, if any.
I take it you know that I still chip away at dll_links.e, slowly making all
entries into something like this:
xShellExecute = link_c_func(shell32, "ShellExecuteA",
{C_LONG, -- HWND hwnd, // handle to parent window
C_PTR, -- LPCTSTR lpOperation, // operation to perform
C_PTR, -- LPCTSTR lpFile, // filename string
C_PTR, -- LPTSTR lpParameters, // executable-file parameters
C_PTR, -- LPCTSTR lpDirectory, // default directory
C_LONG}, -- INT nShowCmd // whether file is shown when opened
C_PTR), -- HINSTANCE
though admittedly that has slowed down now I have F1 help on [x]ShellExecute
Regards,
Pete
3. Re: include abc.dll - any volunteers?
- Posted by Matt Lewis <matthewwalkerlewis at gmail??om>
Jan 08, 2008
-
Last edited Jan 09, 2008
Pete Lomax wrote:
>
> I wonder if there is any way to blag such things from std c header files?
> Does say Watcom automatically know about AllocConsole or does it load details
> from a file? (Or am I wrong and does it learn from kernel32.dll?)
It depends upon the header file. Some are pretty straightforward. Others
are filled with macros, or are just formatted strangely, and are a lot more
difficult to figure out. Chris Bensler wrote somthing along these lines:
http://www.rapideuphoria.com/dawg.zip
I haven't tried it, but it's probably worth checking out before anyone
goes about designing new wheels.
> For that matter does Watcom give a proper compilation error if you pass
> AllocConsole
> the wrong number of parameters, or does it just let it bomb at run-time?
A C compiler will require you to include the proper header. This gives
it information regarding the prototype (name, var types, etc) for the
function. When it comes time to link, it will search through all of the
objects included in the linking stage to find unresolved symbols. So
you have to tell the linker that you're linking against kernel32.dll,
or you'll get an unresolved symbol error when you go to link.
Matt
4. Re: include abc.dll - any volunteers?
Pete, Matt, Thanks for the replies. I think the way to do this would be to
create a tool to analyse the relevant header files and then produce a Euphoria
file that can be included as per normal. I guess it'd have to be able to parse
C so my feeling is that it won't be done any time soon...unless a similar tool
exists for another language and could be modified for our purposes.
regards,
Mike
5. Re: include abc.dll - any volunteers?
Matt Lewis wrote:
>
> Chris Bensler wrote somthing along these lines:
>
> <a
> href="http://www.rapideuphoria.com/dawg.zip">http://www.rapideuphoria.com/dawg.zip</a>
>
> I haven't tried it, but it's probably worth checking out before anyone
> goes about designing new wheels.
I had a quick look. Basic usage is something like this:
constant DLL_link_list={
{"user32.dll",
{
{"LoadIconA", {C_POINTER, C_INT}, C_INT}
}
}
}
build_wrapper("win32_wrapper.e",DLL_link_list,1)
include win32_wrapper.e
So you have to hand-craft a table of routine names, param & return types.
Also of course for it to be useful you need a bunch of eg:
constant WM_CREATE = #01,
WM_PAINT = #0F
So while it could save time, it is far from "automatic".
BTW, I spotted a bug in dawg.e:
global procedure build_wrapper(sequence wrapper_name,sequence
linkage_list,integer overwrite)
if atom(dir(wrapper_name)) and not overwrite then -- check if file exists
puts(1,"build_wrapper(): "& wrapper_name & " already exists\n")
should be if sequence(dir ...
Regards,
Pete
>
> > For that matter does Watcom give a proper compilation error if you pass
> > AllocConsole
> > the wrong number of parameters, or does it just let it bomb at run-time?
>
> A C compiler will require you to include the proper header. This gives
> it information regarding the prototype (name, var types, etc) for the
> function. When it comes time to link, it will search through all of the
> objects included in the linking stage to find unresolved symbols. So
> you have to tell the linker that you're linking against kernel32.dll,
> or you'll get an unresolved symbol error when you go to link.
>
> Matt
6. Re: include abc.dll - any volunteers?
Matt Lewis wrote:
>
> It depends upon the header file. Some are pretty straightforward. Others
> are filled with macros, or are just formatted strangely, and are a lot more
> difficult to figure out.
Do you think it might be easier to look for VB stuff, eg:
http://www.hpcc.ecs.soton.ac.uk/software/Win32API.Txt
Mike wrote:
>
> Pete, Matt, Thanks for the replies. I think the way to do this would be to
> create a tool to analyse the relevant header files and then produce a Euphoria
> file that can be included as per normal. I guess it'd have to be able to parse
> C so my feeling is that it won't be done any time soon...unless a similar tool
> exists for another language and could be modified for our purposes.
>
While I'm not about to download and install Borland/Watcom/etc myself, if you
select one of the less complicated styles, and email me a smallish example, I'll
have a go. Actually, belay that, I just found the link above and would prefer you
investigate that first.
One thing I would be keen to see is a way to integrate the help with Edita: if
you have abc.dll and abc.hlp (or abc.chm) and you create abc.inc which defines
abcfunc(), then I'd like Edita to be able to scan abc.inc and add "abcfunc" to
it's F1 help system. Maybe just something simple like:
-- xx.inc: wrapper for xx.dll
...
--F1HELP:xx.hlp
-- <or> xx.chm
-- <or> http://www.xx.org/search?term=
...
--F1:abcfunc
global function abcfunc(...)
Regards,
Pete
7. Re: include abc.dll - any volunteers?
Pete Lomax wrote:
>
> Matt Lewis wrote:
> >
> > Chris Bensler wrote somthing along these lines:
> >
> > <a
> > href="http://www.rapideuphoria.com/dawg.zip">http://www.rapideuphoria.com/dawg.zip</a>
> >
> > I haven't tried it, but it's probably worth checking out before anyone
> > goes about designing new wheels.
> I had a quick look. Basic usage is something like this:
<snip>
> So you have to hand-craft a table of routine names, param & return types.
Ugh. Yeah, I just recalled it from forum posts, and I don't think I ever
looked closely.
I know that as part of my redesign of wxEuphoria, I started looking at SWIG.
The wxPython folks use this tool. But it seemed like more work than was
necessary, especially since I controlled the specs for the code, and could
keep within certain well defined boundaries, so it was easier to write my
own code to wrap stuff from libwxeu.dll.
Looking at the archive, David Cuny did some work with SWIG:
http://www.rapideuphoria.com/swig_eu.zip
It might be a viable method, although I think that it requires you to build
your own dll. I haven't really used SWIG, though, and I'm sure that there
are much newer versions, so the utility of this code is questionable for
this sort of effort.
Matt
8. Re: include abc.dll - any volunteers?
Pete Lomax wrote:
>
> Matt Lewis wrote:
> >
> > It depends upon the header file. Some are pretty straightforward. Others
> > are filled with macros, or are just formatted strangely, and are a lot more
> > difficult to figure out.
> Do you think it might be easier to look for VB stuff, eg:
> http://www.hpcc.ecs.soton.ac.uk/software/Win32API.Txt
That does look easier to parse. I found another one in the archives (I
knew there was something else). This one by Daniel Kluss seems to do the
trick (at least on the examples provided):
http://www.rapideuphoria.com/h_to_e.zip
But then, I expect that the results of any automated tool will require
checking for correctness.
Matt
9. Re: include abc.dll - any volunteers?
- Posted by Mike <vulcan at win?co?nz>
Jan 09, 2008
-
Last edited Jan 10, 2008
Pete Lomax wrote:
>
> Matt Lewis wrote:
> >
> > It depends upon the header file. Some are pretty straightforward. Others
> > are filled with macros, or are just formatted strangely, and are a lot more
> > difficult to figure out.
> Do you think it might be easier to look for VB stuff, eg:
> <a
> href="http://www.hpcc.ecs.soton.ac.uk/software/Win32API.Txt">http://www.hpcc.ecs.soton.ac.uk/software/Win32API.Txt</a>
>
> Mike wrote:
> >
> > Pete, Matt, Thanks for the replies. I think the way to do this would be to
> > create a tool to analyse the relevant header files and then produce a
> > Euphoria
> > file that can be included as per normal. I guess it'd have to be able to
> > parse
> > C so my feeling is that it won't be done any time soon...unless a similar
> > tool
> > exists for another language and could be modified for our purposes.
> >
>
> While I'm not about to download and install Borland/Watcom/etc myself, if you
> select one of the less complicated styles, and email me a smallish example,
> I'll have a go. Actually, belay that, I just found the link above and would
> prefer you investigate that first.
I think a Q 'n D program would easily convert most of that correctly and the
rest
just flagged as too hard and so the user would need to make the final
adjustments
by hand. However, for non-std dlls we might have trouble getting the relevant VB
file. The other problem is this: who would write such a converter?
> One thing I would be keen to see is a way to integrate the help with Edita:
> if you have abc.dll and abc.hlp (or abc.chm) and you create abc.inc which
> defines
> abcfunc(), then I'd like Edita to be able to scan abc.inc and add "abcfunc"
> to it's F1 help system. Maybe just something simple like:
>
> }}}
<eucode>
> -- xx.inc: wrapper for xx.dll
> ...
> --F1HELP:xx.hlp
> -- <or> xx.chm
> -- <or> http://www.xx.org/search?term=
> ...
> --F1:abcfunc
> global function abcfunc(...)
> </eucode>
{{{
>
> Regards,
> Pete
I think it is exactly that simple but the converter tool would need help
to correctly construct any help targets.
regards,
Mike