dllexport for vc 6.0 c++

  • Thread starter Thread starter Henri.Chinasque
  • Start date Start date
H

Henri.Chinasque

Hi all,

I needed a way to provide vc 6.0 c++ code a way to call managed dlls
compiled in vs 2003. In order to do this I created a wrapper (in vs
2003) for the managed code and made the functions accessible with dll
export.

I then wrote a test application in vc 6.0 which included the .lib file
created from dllexport and called the managed code through it.
Everything works just fine. However, somehow it just seems a little
too good to be true. I'm wondering if I am going to pay for this
approach somewhere down the line.

Does anybody have experience with interoperability between vs6 and vs7
code? Your comments are most welcome.

Thanks,

Henri
 
I needed a way to provide vc 6.0 c++ code a way to call managed dlls
compiled in vs 2003. In order to do this I created a wrapper (in vs
2003) for the managed code and made the functions accessible with dll
export.

I then wrote a test application in vc 6.0 which included the .lib file
created from dllexport and called the managed code through it.
Everything works just fine. However, somehow it just seems a little
too good to be true. I'm wondering if I am going to pay for this
approach somewhere down the line.

Does anybody have experience with interoperability between vs6 and vs7
code? Your comments are most welcome.
Click to expand...

Hi,

Yes, Life can really be that good. As long as you live by the following
rules, everything is hunky-dory:
- do not deallocate memory that was allocated in another module.
- do not use classes in your public interface. Only plain C functions and
plain old data arguments.
- do not let exceptions escape beyond module boundaries. Use simple return
values.

All praise the power of Visual C++ :-)

--

Kind regards,
Bruno van Dooren
(e-mail address removed)
Remove only "_nos_pam"
 
Bruno van Dooren said:
Hi,

Yes, Life can really be that good. As long as you live by the following
rules, everything is hunky-dory:
- do not deallocate memory that was allocated in another module.
- do not use classes in your public interface. Only plain C functions and
plain old data arguments.
- do not let exceptions escape beyond module boundaries. Use simple return
values.
Click to expand...

That advice will work great with VS2005 (vc8). vc7 though may cause random
failures due to things like bugs in the managed c++ runtime library relating
to loader lock, and syntax that lets you pass unpinned managed objects to
native functions.
 
Back
Top