How to: export function from VB DLL? 
Author Message
 How to: export function from VB DLL?

Hello,

Does anyone know, is it possible and how to export from
ActiveX DLL written in VB the function conforming to the
following C++ prototype:

extern "C"
{
  IUnknown * TheFunction(void);

Quote:
}

Any ideas, suggestions are thankfully appreciated.

Regards,
Andrei Suvorov.



Sat, 01 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
I think SpyWorks allows you to export functions.  They call it their Dynamic
Export Technology.  See http://www.desaware.com.

Earl Damron, MCSD, MVP

Quote:

>Hello,

>Does anyone know, is it possible and how to export from
>ActiveX DLL written in VB the function conforming to the
>following C++ prototype:

>extern "C"
>{
>  IUnknown * TheFunction(void);
>}

>Any ideas, suggestions are thankfully appreciated.

>Regards,
>Andrei Suvorov.



Sat, 01 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?

Quote:

>Does anyone know, is it possible and how to export from
>ActiveX DLL written in VB the function conforming to the
>following C++ prototype:

You can't. You can only create ActiveX DLLs (aka in-process automation
servers) with VB.

There are 3rd party alternatives you might want to investigate. Desaware's
SpyWorks Professional allows you to export functions from a VB created DLL.
http://www.desaware.com   powerbasic offers PB/DLL which allows you to
create DLLs using BASIC syntax. http://www.powerbasic.com

Also note that you can often use ActiveX DLLs with other applications only
that the method of doing so is often different. Perhaps if you provided more
information on what you're trying to do, someone could suggest more
alternatives for you.

Frank Carr



Sat, 01 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Thank you for help,

I have looked at it, that technology doesn't actually
export functions from VB DLL. It seems to create
other DLL which redirects calls to VB DLL using
callback mechanism.

Any other ideas?

Thanks in advance,
Andrei Suvorov.

Quote:

>I think SpyWorks allows you to export functions.  They call it their
Dynamic
>Export Technology.  See http://www.desaware.com.

>Earl Damron, MCSD, MVP


>>Hello,

>>Does anyone know, is it possible and how to export from
>>ActiveX DLL written in VB the function conforming to the
>>following C++ prototype:

>>extern "C"
>>{
>>  IUnknown * TheFunction(void);
>>}

>>Any ideas, suggestions are thankfully appreciated.

>>Regards,
>>Andrei Suvorov.



Sat, 01 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Andrei..

Quote:
>I have looked at it, that technology doesn't actually
>export functions from VB DLL. It seems to create
>other DLL which redirects calls to VB DLL using
>callback mechanism.

>Any other ideas?

That's the best you can do. VB doesn't support exported functions. There
*is* a complicated way to do it by intercepting Linker calls as the DLL is
being compiled, but even when such attempts have been successful, I don't
think anyone has managed to actually call the exported functions because of
stack corruption or some such trouble.

SpyWorks is really the only way to go, unless you can write the DLL in C++
instead.

--
Ben Baird, MVP
Visual Basic Thunder
http://www.vbthunder.com
Common Controls Replacement Project
http://www.mvps.org/ccrp/
Please direct your programming questions to the newsgroups.



Sat, 01 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Although it is theoretically possible to do this, through the following
technique (which could even be theoretically automated):

1) Use AddressOf to get all function pointers and then subtract the start of
the DLL in memory to get the function pointer that would go in the export
table
2) Modify the count of functions in the export table of the DLL to add in
the new functions
3) Add the name, pointer, etc., for each function to the pointer table

You would not be able to call the function in VB6 for the same reason that
CreateThread does not work... you cannot run most VB code unless the TLS has
been initialized. The workarounds for this are a huge perf hit and would
happen for every single call. It is simply not something that can possibly
done in any practical way.

Michael



Quote:
> Andrei..

> >I have looked at it, that technology doesn't actually
> >export functions from VB DLL. It seems to create
> >other DLL which redirects calls to VB DLL using
> >callback mechanism.

> >Any other ideas?

> That's the best you can do. VB doesn't support exported functions. There
> *is* a complicated way to do it by intercepting Linker calls as the DLL is
> being compiled, but even when such attempts have been successful, I don't
> think anyone has managed to actually call the exported functions because
of
> stack corruption or some such trouble.

> SpyWorks is really the only way to go, unless you can write the DLL in C++
> instead.

> --
> Ben Baird, MVP
> Visual Basic Thunder
> http://www.vbthunder.com
> Common Controls Replacement Project
> http://www.mvps.org/ccrp/
> Please direct your programming questions to the newsgroups.



Sat, 01 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?


Fri, 19 Jun 1992 00:00:00 GMT  
 How to: export function from VB DLL?
Gary's wishlist for VB7..

Be able to create Standard (not ActiveX) DLLs  (C'mon Microsoft, this can't
be too hard!)

Bet able to mark a function or sub in a module to be exported when
generating either an ActiveX or Standard DLL!!

Have a complete AddressOf operator that allows us to get the address of
anything (Classes, Variables, Methods, anything)

One word..  Inheritance!!

The ability to turn off bounds checking and Integer overrun checking
dynamically and then turn it back on.  Not just on the project scope.

Add an App.RunningInIDE property Get!!!
Add an App.ActivatePrevInst method  that actually restored the PrevInstance
if it is minimized!!

Allow Interfaces to be defined separate of the class.  No more creating
class shells just to create an interface.    Require ALL interfaces to be
defined with "Implements"  Add a second parm to Implements that defines if
it is outbound instead of inbound.  This would allow multiple outbound
Interfaces.  An event is nothing more than a method on an outbound
interface.  VB doesn't allow multiple outbound interfaces even though COM
does!.  All Events are added to one outbound interface. Add a third parm to
Implements that states if it is the Default interface.  Only one would be
allowed, of course, for the inbound interfaces and outbound interfaces
respectively.

C'mon, is this too much to ask for?   People have been asking for this stuff
forever.  You would thing that Microsoft would at least add some of it.  If
you agree with any of this or have any other ideas, goto Microsoft.com and
do a search on "Wish"  You will find the WishWizard and will be able to ask
for anything you want.

Gary    ( http://DesignerControls.com )


Quote:
>Hello,

>Does anyone know, is it possible and how to export from
>ActiveX DLL written in VB the function conforming to the
>following C++ prototype:

>extern "C"
>{
>  IUnknown * TheFunction(void);
>}

>Any ideas, suggestions are thankfully appreciated.

>Regards,
>Andrei Suvorov.



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Don't be too disappointed if you see almost none of this.



Quote:
> Gary's wishlist for VB7..



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Gary,

Sorry if it seems a stupid question, but can you clarify what exactly a
"default" interface does?

--
Kathleen



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Gary...

Quote:
>Gary's wishlist for VB7..

You might make a bit more progress if you sent your wish list to

Quote:
>Be able to create Standard (not ActiveX) DLLs  (C'mon Microsoft, this can't
>be too hard!)

It isn't but it's not worth it anyway. All DLLs are moving the way of
ActiveX -- what's the benefit of creating the "old" kind?

Quote:
>Have a complete AddressOf operator that allows us to get the address of
>anything (Classes, Variables, Methods, anything)

You can get the address of a variable using the VarPtr() function.
As for AddressOf in classes, well... it can't really work without some major
hacks -- classes just aren't set up to accept it. You can't do this in C++
either, unless the class's method is defined as "static", which pretty much
makes the method like a standard module routine anyway.

Quote:
>One word..  Inheritance!!

Why?

Quote:
>The ability to turn off bounds checking and Integer overrun checking
>dynamically and then turn it back on.  Not just on the project scope.

This is an option given to the *compiler* -- not your code. Your EXE would
have to be able to recompile itself on the fly, unless Microsoft completely
changed the core of these options, which would slow down the runtime and
make it even bigger.

Quote:
>C'mon, is this too much to ask for?   People have been asking for this
stuff
>forever.

And most of what VB programmers are asking for are things that we don't
need -- like inheritance. What we *need* is a better IDE, a smaller runtime,
and more stability.

Be careful. You may actually get what you wish for.

--
Ben Baird, MVP
Visual Basic Thunder
http://www.vbthunder.com
Common Controls Replacement Project
http://www.mvps.org/ccrp/
Please direct your programming questions to the newsgroups.



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?

How about debugging of actual DLLs and EXEs? Sometimes they do act different
than the "in environment" mode and for performance reasons, sometimes
testing in the environment is barely if even possible. Using the C++
de{*filter*} you can do this, but it can't see a lot of the variables and
doesn't step into class method calls correctly.

Following up on that, how about allowing linking to LIB or OBJ files when
creating an EXE or DLL? Some third party DLLs have mangled names that don't
match the names in the documentation and import library. This would also
allow you to write snippets of C++ when needed that don't have to be
packaged as DLLs (with the resultant installation and versioning headaches).
Inline C++ or Assembler would be really cool, but I can understand why that
might be problematic.

How about allowing CDECL in Declare statements? Many DLLs use this calling
convention.

How about supporting all COM data types, not just the automation ones?

I have mixed feelings about inheritance. I have been using C++ for several
years, and have some limited experience in Java and Object Pascal.
Inheritance can and does cause as many headaches as it cures. If inheritance
is added, it should be completely optional and not the "standard" way of
doing things. To explain, let me compare VB to MFC in C++. Lets say I want
to respond to a click on a window. In VB, I go to the form's click event and
code. It is my event and I don't have to worry about what anybody further up
the chain does with it. In MFC, I add the event in the Class Wizard and a
code stub is generated for me. A call to the parent class' implementation is
included in that implementation. Now, do I want to do my processing before
or after the call to the parent class? Or maybe some before and some after.
Maybe I should not call the parent at all. The only way to know for sure is
to break the "black box" and see what the parent class does.

VB is object based, but not truly object oriented because of the lack of
inheritance. I don't have a problem with this. In fact, I would rather see
an easy way to delegate implementation added rather than inheritance. In
other words, I would like to able to say I implement an interface using a
specified member variable of the class that supports that interface and have
VB automatically generate all the stubs to handle calls to that interface by
delegation. then I could go in and tweak the few (if any) I need to. In a
similar vein, I would like to be able to create a wrapper control and
everytime I dropped a control on it be asked if I want to automatically
surface all of its custom methods and properties to user of my control.
Again, I would want the stubs created with the proper code to make most of
it magically work.

It does seem that MS is using VB to ram COM down everyone's throat. In order
to interface to VB, you must use COM. VB can call out to DLLs, but cannot be
called into as a plain DLL. I don't think this decision was made by ther
development folks. I would like to create the DLLs also. I have a few
products that I could create add ins for much quicker in VB than C++, but
they require specific named exports with a specific calling convention and
parameter list.

-Andy


Quote:
>Gary's wishlist for VB7..



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?

Quote:

>Be able to create Standard (not ActiveX) DLLs  (C'mon Microsoft, this can't
>be too hard!)

>Bet able to mark a function or sub in a module to be exported when
>generating either an ActiveX or Standard DLL!!

Don't hold your breath...<g>

The impression I get is that Microsoft is trying to slowly push exported
function DLLs the same direction they pushed .COM executable files, out of
the picture almost entirely.

Quote:
>Have a complete AddressOf operator that allows us to get the address of
>anything (Classes, Variables, Methods, anything)

Well, you do have the infamous hidden functions (VarPtr, ObjPtr, etc.) that
you can use for some operations, if you like to live dangerously. The big
thing to add here would be to allow AddressOf to work from any module, not
just standard code modules.

Quote:
>One word..  Inheritance!!

Whoa...wait for the majority of VB programmers to learn encapsulation
first....<g>

It would be a useful addition, but there is a lot you can do with
aggregation in the mean time.

Quote:
>The ability to turn off bounds checking and Integer overrun checking
>dynamically and then turn it back on.  Not just on the project scope.

So you do like to live dangerously. Why would you want to do this?

Quote:
>Add an App.RunningInIDE property Get!!!
>Add an App.ActivatePrevInst method  that actually restored the PrevInstance
>if it is minimized!!

Both of these would be handy and have been requested for some time. I
remember seeing them on a feature request list like yours on the old MSBASIC
CompuServe forum prior to the release of VB3. However, both are easy enough
to implement in code.

Quote:
>Allow Interfaces to be defined separate of the class.  No more creating
>class shells just to create an interface.
> Require ALL interfaces to be defined with "Implements"

I would prefer this as an option, not as a requirement. Something along the
same lines I would like would be a VB way of designing a TypeLib.

Quote:
> VB doesn't allow multiple outbound interfaces even though COM
>does!.

I would like to see them better implement/mirror the COM interface within VB
as long as its done rather transparently and cleanly.

Frank Carr



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?


Quote:
>Gary...

>>Gary's wishlist for VB7..

>You might make a bit more progress if you sent your wish list to


Agreed, although sometimes you wonder if that e-mail address is a black hole
to nowhere :(.

Quote:
>>Be able to create Standard (not ActiveX) DLLs  (C'mon Microsoft, this
can't
>>be too hard!)

>It isn't but it's not worth it anyway. All DLLs are moving the way of
>ActiveX -- what's the benefit of creating the "old" kind?

Sorry, Ben, but I have to disagree with you.  True, COM DLLs are showing up
all over the place, but they STILL have to export function s.t. that COM
library can use the DLLs.  Furthermore, COM's library is based in DLLs that
you can call via exported functions (like CoCreateInstance,
CoGetClassObjects, etc.).  So while COM interfaces are great, exported DLLs
do have their value as shown by Microsoft.

Quote:
>>Have a complete AddressOf operator that allows us to get the address of
>>anything (Classes, Variables, Methods, anything)

>You can get the address of a variable using the VarPtr() function.
>As for AddressOf in classes, well... it can't really work without some
major
>hacks -- classes just aren't set up to accept it. You can't do this in C++
>either, unless the class's method is defined as "static", which pretty much
>makes the method like a standard module routine anyway.

William Storage has an article on his web site (Nerve-Net) that talks about
vtable modification in VB.  It's worth looking at.

Quote:
>>One word..  Inheritance!!

>Why?

This issue has been bashed around so much I won't touch it!!

Quote:
>>C'mon, is this too much to ask for?   People have been asking for this
>stuff
>>forever.

>And most of what VB programmers are asking for are things that we don't
>need -- like inheritance. What we *need* is a better IDE, a smaller
runtime,
>and more stability.

True.  The general cry in the industry for stable systems and programs
relates to programming languages and tools as well.  Although I would
disagree that we don't need inheritence, I think that it is more important
to get the things you asked for in VB in the next release.  I don't need 15
different ways to design databases and access them anymore, thank you :(.

Regards,

Jason



Mon, 03 Sep 2001 03:00:00 GMT  
 How to: export function from VB DLL?
Jason...

Quote:
>>You might make a bit more progress if you sent your wish list to

>Agreed, although sometimes you wonder if that e-mail address is a black
hole
>to nowhere :(.

Believe me, Microsoft reads it. The important thing is to send sincere and
*polite* requests to the vbwish alias -- rude requests and multiple messages
(spam) will only get the alias taken down.

Quote:
>>It isn't but it's not worth it anyway. All DLLs are moving the way of
>>ActiveX -- what's the benefit of creating the "old" kind?

>Sorry, Ben, but I have to disagree with you.  True, COM DLLs are showing up
>all over the place, but they STILL have to export function s.t. that COM
>library can use the DLLs.  Furthermore, COM's library is based in DLLs that
>you can call via exported functions (like CoCreateInstance,
>CoGetClassObjects, etc.).  So while COM interfaces are great, exported DLLs
>do have their value as shown by Microsoft.

You make a good point, but I suppose my rationale is that VB is doing just
fine with the DLLs it can make. AFAIK, there are only a few things (such as
CPL applets and system-wide hooks) that require the old kind of DLL -- I've
done a few of those things, and I think that programmers are a lot better
off learning to do them in C++ than using a RAD tool like Visual Basic to do
the job. RAD and system-wide hooks just don't go together :-)

Quote:
>William Storage has an article on his web site (Nerve-Net) that talks about
>vtable modification in VB.  It's worth looking at.

Yeah, it's pretty ugly isn't it? It's a terrific hack, but I'm not so sure
I'd want to mess with that in a "real" application :-)

--
Ben Baird, MVP
Visual Basic Thunder
http://www.vbthunder.com
Common Controls Replacement Project
http://www.mvps.org/ccrp/
Please direct your programming questions to the newsgroups.



Mon, 03 Sep 2001 03:00:00 GMT  
 
 [ 94 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7]

 Relevant Pages 

1. How to: export function from VB DLL?

2. How to export function in a VB DLL

3. export a function when creating a DLL in VB

4. Declaring VB DLL Function for Export

5. export a function when creating a DLL in VB

6. Problem of VB calling DLL function exported with __declspec(dllexport) in VC++

7. DLL C Function Export for VB

8. Exporting Visual Basic functions & DLL's

9. Exporting Visual Basic functions & DLL's

10. Exporting functions from DLLs

11. Exporting dll functions

12. Passing a String to an exported dll function

 

 
Powered by phpBB® Forum Software