|
PureBytes Links
Trading Reference Links
|
Hello Tomasz,
>handles cdecl
A quick search at Microsoft (for VB) found this (watch word wrap):
<http://search.support.microsoft.com/kb/psssearch.asp?SPR=vbb&T=B&KT=ALL&T1=
7d&LQ=cdecl+&PQ=PastQuery&S=F&A=T&DU=C&FR=0&D=kbVBsearch&LPR=&LNG=ENG&VR=htt
p%3A%2F%2Fsupport.microsoft.com%2Fsupport%3Bhttp%3A%2F%2Fsupport.microsoft.c
om%2Fservicedesks%2Fwebcasts%3Bhttp%3A%2F%2Fsupport.microsoft.com%2Fhighligh
ts&CAT=Support&VRL=ENG&SA=GN&Go.x=32&Go.y=18>
I don't know if this is what you are talking about or not. I hope it is
doable in VB. Does this make sense?
Peter Gialames
-----Original Message-----
From: Tomasz Janeczko [mailto:amibroker@x...]
Sent: Sunday, September 23, 2001 7:33 AM
To: amibroker@xxxxxxxxxxxxxxx
Subject: Re: [amibroker] DLL interface
Hello,
A quick check on the Internet proved that PowerBasic apparently
handles cdecl calling convention and unions so I guess it should
be perfectly capable of creating AmiBroker-compliant DLLs.
Best regards,
Tomasz Janeczko
===============
AmiBroker - the comprehensive share manager.
http://www.amibroker.com
----- Original Message -----
From: "Tomasz Janeczko" <amibroker@xxxx>
To: <amibroker@xxxxxxxxxxxxxxx>
Sent: Sunday, September 23, 2001 9:50 AM
Subject: Re: [amibroker] DLL interface
> Hello,
>
> In fact there are 3 issues that decide if particular language is
> capable of creating plugins for AmiBroker:
> - ability to use cdecl calling convention (altrough I am considering
switching
> to stdcall being more-API like, but this would require significant
changes)
> - ability to call functions via function pointers (the function pointer is
what
> WINAPI GetProcAddress returns)
> - ability to handle C-like string pointers (char *), floating point array
pointers (float *)
> and structs (records) of those variable types.
>
> All flavours of C/C++ support these and Delphi supports these also.
> Visual Basic in the current version is not able to create "normal" (not
COM) DLLs
> and there is no control over calling convention used.
>
> These requirements are enforced because plugins will support two-way
function calls
> AmiBroker->ExternalDLL and ExternalDLL->AmiBroker and AFL will make
> no distinction between these calls. (NOTE: yes I know this could be also
done
> using COM but some of you probably know that writing COM in C/C++ requires
much more
> work and I would like to provide an easy way to write the plugin DLLs for
you)
>
> I don't know if PowerBasic supports the features I mentioned,
> but for VisualBasic and other COM-based languages I will provide the
ability
> to call functions in COM (ActiveX) objects. However this will be handled
> by separate function Call( object, "functionname", params,...) (or
Invoke).
> In this second approach features listed in point 3 will not be available.
>
> Best regards,
> Tomasz Janeczko
> ===============
> AmiBroker - the comprehensive share manager.
> http://www.amibroker.com
>
>
> ----- Original Message -----
> From: "Buzz M Ross" <buzzmr@xxxx>
> To: <amibroker@xxxxxxxxxxxxxxx>
> Sent: Saturday, September 22, 2001 10:07 PM
> Subject: Re: [amibroker] DLL interface
>
>
> > Hi, Tomasz,
> >
> > For a number of reasons, I do not program in C, nor any flavor of it,
and
> > avoid it like the plague. [Many years ago, I DID write a program in C,
> > and was 'cured' forever from it. My hat's off to you for your patience
> > to do YOUR work in C!!! (:->) ]
> >
> > I've chosen to do my projects in various flavors of Basic. In
> > particular, I use Visual Basic and PowerBASIC. PowerBASIC is my
language
> > of choice, and soon I'll be obtaining the PB/DLL v6.0 compiler. This
> > compiler generates code to interface with Visual Basic's 'dll' calling
> > conventions, which to my understanding use standard Windows API
interface
> > conventions. As long as the AmiBroker calling convention adhere's to
> > this standard, I see no reason why ANY language, including the PB/DLL
> > compiler, that generates such calling-interface code could not be used.
> > Please verify that this is a correct assumption for purposes of writing
> > DLL's for AmiBroker.
> >
> > If this assumtion is NOT correct, then you may want consider what to do
> > about the AmiBroker specs before casting them in concrete. Thanks in
> > advance for your consideration.
> >
> > Providing the ability for the user to write their own DLL's is a VERY
> > POWERFUL policy decision that I highly commend you for!! Thank you for
> > your SANE approach to EFFECTIVE software development for users!!!
> >
> > Buzz
> > -------------------------
> > Buzz M. Ross, President
> > Creative Consulting Co.
> > Boulder, CO 80301
> >
> > -------------------------------------
> > On Sat, 22 Sep 2001 09:36:26 +0200 "Tomasz Janeczko" <amibroker@xxxx>
> > writes:
> > >Hello,
> > >
> > >In this e-mail I want to present you some features of a DLL plugin
> > >interface
> > >being developed for version 3.8. I would like to know your thoughts
> > >about
> > >it before I close the specification.
> > >
> > >The purpose of AmiBroker's plugin interface is to allow to extend AFL
> > >built-in function set
> > >by any user or third party software vendor.
> > >
> > >Main goals are:
> > >1. speed - there will be virtually no performance differences between
> > >internal and external
> > > functions
> > >2. simplicity -
> > > a) the interface is very simple, flat API-like (no COM for now).
> > > b) writing plugins will be as easy as adding a new function(s) to a
> > >sample C project
> > > c) Installation of a plug-in will be as easy as just copying the
> > >DLL into "Plugins" directory
> > >3. tight integration with AFL engine -
> > > a) external functions will be available directly from
> > > AFL without the need to call any additional function like ExtFml.
> > > b) all external functions will be highlighted properly in a new
> > >syntax coloring editor
> > > c) AFL engine will check types of parameters passed to the external
> > >function
> > > d) ability to call-back any built-in AFL function from within
> > >external DLL (this includes
> > > also calling functions from one external DLL to another)
> > > e) ability to overwrite built-in functions
> > >
> > >For technical reasons (mainly point 3.) plugin DLLs will have to be
> > >written in some flavour
> > >of C/C++ language. Visual C++ 6 is preferred, however free compilers
> > >like PGPP (GNU) and
> > >free Borland C/C++ 5 compliers will be supported also. It is yet to be
> > >tested if it is possible
> > >to write compatible DLLs using Delphi.
> > >
> > >Visual Basic and other COM-only languages will not be supported at
> > >this stage.
> > >COM-based interface is planned later (next year).
> > >
> > >Best regards,
> > >Tomasz Janeczko
> > >===============
> > >AmiBroker - the comprehensive share manager.
> > >http://www.amibroker.com
> >
> > ________________________________________________________________
> > GET INTERNET ACCESS FROM JUNO!
> > Juno offers FREE or PREMIUM Internet access for less!
> > Join Juno today! For your FREE software, visit:
> > http://dl.www.juno.com/get/tagj.
> >
> >
> >
> >
> > Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
> >
> >
> >
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
|