OpenEuphoria

RE: Invaid argument type in dll.e

• Posted by Elliott Sales de Andrade <quantum_analyst at hotmail.com> Oct 07, 2003
• 379 views

>From: Andy Serpa <ac at onehorseshy.com>
>Subject: RE: Invaid argument type in dll.e
>
>
>Just a note:
>
>There are a number of wrappers for external .dll libraries (zlib,

  ZLib does. It's only required for one function, gzprintf, because it takes 
a variable number of arguments.

>sqlite, etc.) in the archives that should (now) be using cdecl
>declarations instead of stdcall (add "+" before the function name in the
>declaration).  They happen to work with the interpreter because of a
>quirk in Watcom, but will crash if translated to C.
>
>So when making a wrapper, check to see what the proper calling
>convention is...
>
>
>Brian Broker wrote:
> >
> >
> > Hi Chris,
> >
> > The bottom line is, the C routine definitions should never have been
> > declared with NULL's or 0's.  The definition's need to be fixed... This
> > shouldn't be too difficult but perhaps a bit time consuming.  Or you
> > could wrap define_c_func/proc to check for NULL parameters but then you
> > still need to replace occurrences of define_c_func/proc to whatever your
> >
> > wrapper name is.
> >
> > Personally, I'd just fix the definitions and maybe re-release the fixed
> > code to the archives.
> >
> > -- Brian
> >
> > Chris Burch wrote:
> > > Hi
> > >
> > > I have a headache.
> > >
> > > After purchasing eu2.4, I find that a lot of the downloaded programs 
>are
> > >
> > >
> > > broken, particularly directe and exotica.
> > >
> > > The problem lies in dll.e, particularly :-
> > >
> > > global function define_c_func(object lib, object routine_name, 
>sequence
> > > arg_sizes, atom return_type)
> > > -- define a C function (or machine code routine)
> > >
> > >     return machine_func(M_DEFINE_C, {lib, routine_name, arg_sizes,
> > > return_type})
> > > end function
> > >
> > > returns invalid argument type. (usually line 53) This didn't happen in
> > > eu2.3.
> > >
> > > The reason (gathered from previous postings) - and correct me if I'm
> > > wrong,
> > > is that some programs pass NULL, and not {}, which is now interpreted 
>in
> > >
> > > eu2.4
> > > differently.
> > >
> > > Having traced thru (in exotica) various files, eg emain.ew,
> > > ewin32_api.ew,
> > > and replace various NULLs with {} the errors are changing places, so
> > > it's
> > > beginning to work.
> > >
> > > However, other solutions could be
> > >
> > > 1. Rewrite the eu sorce code to accomodate these different types 
>passed
> > > to
> > > the interpreter - so that the error is not returned.
> > >
> > > 2. Check the type passed to the define_c_func, and change it to the
> > > correct
> > > type in situ so that the error is not returned.
> > >
> > > 2 is where my headache started. I've tried various things, checking to
> > > see if
> > > what's passed is an object or a sequence, but I am floundering a 
>little,
> > >
> > > and
> > > any pointers would be greatly appreciated. Also, due to floundering, 
>I'm
> > >
> > > a
> > > little sparse on detail - sorry.
> > >
> > > At the moment, in order to experiment with with direct x, I'm having 
>to
> > > use
> > > eu2.3, which is inconvenient more than anything.
> > >
> > > Chris
> > >
> >