1. include abc.dll - any volunteers?

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

new topic     » topic index » view message » categorize

2. Re: include abc.dll - any volunteers?

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: include abc.dll - any volunteers?

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

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

new topic     » goto parent     » topic index » view message » categorize

9. 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:
> <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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu