Experimental Physics and
Industrial Control System

"Mark S. Engbretson" <[email protected]> · Mon, 2 Feb 2015 19:06:12 -0600

It's only a problem because someone made it so.

Even Microsoft says - 

If you have functions in a DLL written in C++ that you want to access from a
C-language module, you should declare these functions with C linkage instead
of C++ linkage. Unless otherwise specified, the C++ compiler uses C++
type-safe naming (also known as name decoration) and C++ calling
conventions, which can be difficult to call from C.

Problem solved. You can access DLL function entries by ordinal value if you
had to, and so long as the parameters, types, and calling conventions are
agreed upon everything still works.  The fact that every compiler name
mangles their c++ classes differently shows that actually exporting  a c++
class in a dll  is probably not the correct thing to do at the end of the
day if you don't want to hand out sources, or start building libraries for
major compiler players.  

Just wrapper or shim or cdecl the minimal functions that you need and move
on . People using Easy Channel Access do it all the time  . . . . If people
had coded this right, a single DLL , 1 header file, and the produced 'glue'
lib exported from the DLL is all that anyone would need. You don't have to
export EVERYTHING.

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Johnson, Andrew N.
Sent: Monday, February 02, 2015 5:43 PM
To: Engbretson, Mark S.
Cc: EPICS Tech-Talk
Subject: Re: epicsRingPointer.h error C2664: 'delete' : cannot convert
parameter

Hi Mark,

A DLL that only exports a C++ class can only be called by a program that is
built using a compatible ABI, which for Microsoft means the compilers must
have the same major version number. The Gnu policy on their C++ ABI has long
stressed compatibility between versions, in contrast to Microsoft's
policies. A class exports mangled versions of its symbol names (name
mangling has changed in the past) and the class interfaces have also changed
between major versions of Visual Studio, thus the compiler must know how to
mangle the names from the header file correctly to find the right methods in
the DLL, and must also use the correct class interface (RTTI, vtable entries
etc.) to be able to use the class properly.

Several of the libCom APIs are written in C++, so the above rules do matter
for some EPICS code. The Channel Access API is completely specified in C
though, which makes it immune from such issues since Microsoft's C ABI has
not changed for a long time.

Microsoft has been proposing enhancements for the C++ standard to define a
portable C++ ABI which should allow interoperability in the future, although
this will take some work to implement. Search for Herb Sutter's document
number N4028 for details.

- Andrew

--
Sent from my iPad

> On Feb 2, 2015, at 2:28 PM, Mark S. Engbretson <[email protected]> wrote:
> 
> DLL's are standalone entities which have resolved all their library 
> reverences at build time. The windows EPICS libs are already DLL's. 
> ANYTHING with the correct header files can talk to it - Pascal, 
> Fortran, past versions or future versions. All you have to do is find 
> out if whatever code that your building apps for can understand the DLL
and link lib formats.
> Grab a recent version for an APS Jenkin build and see what happens.
> Microsoft is rather compatible with itself.
> 
> https://jenkins.aps.anl.gov/job/epics-base-3.14/
> https://jenkins.aps.anl.gov/job/epics-base-3.15/
> 
> That being said - nothing keeps you from building those apps against a 
> 15 year version of epics. You just don't get later features such as 
> large arrays.  Do you need anything that only exists in current versions?
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]
> On Behalf Of Johnson, Andrew N.
> Sent: Monday, February 02, 2015 2:17 PM
> To: J. Lewis Muir
> Cc: EPICS Tech-Talk
> Subject: Re: epicsRingPointer.h error C2664: 'delete' : cannot convert 
> parameter
> 
> Hi Lewis,
> 
> Microsoft's attitude to compatibility for C++ code is that you have to 
> use the same major compiler version to be able to link programs with 
> separately compiled libraries. C code does not have the same 
> restrictions though, which is why we can use gcc to build programs 
> that link with the OS libraries, and why Windows' APIs haven't been
switched to C++ classes.
> 
> It sounds like you are building the vendor's code, which must be done 
> with VC6, but can add your own code to their program. I can suggest a 
> few ways to interface that with EPICS code built with a newer 
> compiler: Use a socket or COM API to to communicate between the two 
> sides, or make the interface a DLL with a C-only API as this should 
> allow you to link with and call code from the other compiler. A DLL 
> would give you a closer and faster interface, but might be more trouble to
get working.
> 
> If all you need is to call the CA library it does provide the C-only 
> API and DLL that you need, so in this case you might be able to just 
> copy the ca.dll and com.dll files from another machine along with a few
header files.
> 
> Hope this helps,
> 
> - Andrew
> 
> --
> Sent from my iPad
> 
>>> On Feb 2, 2015, at 1:21 PM, J. Lewis Muir <[email protected]> wrote:
>>> 
>>> On 1/30/15 5:48 PM, Andrew Johnson wrote:
>>> I don't think you'll be able to, MS Visual C++ 6 was released in 
>>> 1998
>>> (17 years ago, long before MS implemented standard C++) and it 
>>> doesn't support all of the C++ constructs that we make use of in 
>>> Base. In 2008 Jeff Hill explained that VC7 was too old to build
> Base-3.14.9:
>>>   http://www.aps.anl.gov/epics/tech-talk/2008/msg00078.php
>>> 
>>> Can't you upgrade the compiler?
>> 
>> Hi, Andrew.
>> 
>> Thanks for your reply.  I'm writing a library (that uses EPICS CA) 
>> that I need to work with a vendor-supplied program.  Unfortunately, 
>> I've been told by the vendor that the program will only build with 
>> VC6, hence, in order to have the best chance of things working right, 
>> I was planning to use the same compiler to build my library (and 
>> EPICS
> Base).
>> 
>> So, to answer your question, upgrading the compiler is perhaps 
>> possible, but I fear it might result in significant pain.
>> 
>> I'm not a Windows expert.  Is it possible to install, say, Visual 
>> Studio
>> 2010 *alongside* VC6 on Windows 7?  And if so, is it possible to 
>> compile EPICS Base and my library as DLLs that the VC6 
>> vendor-supplied program can link against?
>> 
>> Thank you!
>> 
>> Lewis
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System