Thanks,
let's do as you wrote. I just need to ask you for some patience, as this is a bit bigger task than a usual tech support. So, I need to reserve some extra time. With this, I think it is safe to assume that my first results will be available in a week or less.

Hello,
thank you for clarification - I now understand better what you are trying to achieve.
We do not really have sufficient experience here with gcc or other tools you are using. I think that what we can do is that we will together develop a standards-based code that will on our side run under Microsoft C++, and at the same time you will help with making it compile and run under the tool that you choose. To give you an idea, below is an example that comes installed with QuickOPC-COM. The example demonstrates the basic use of QuickOPC-COM, but calls it using all kinds of Microsoft-specific stuff (such as the use of #import for creation of the C++ type wrappers from the type library, and the use of ATL classes CComVariant and CSafeArray to simplify the handling of OLE Automation variants and safe arrays).

// ReadMultipleItems.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include
#include

#import "libid:FAB7A1E3-3B79-4292-9C3A-DF39A6F65EC1" version(5.1) // EasyOpcLib
using namespace EasyOpcLib;

int _tmain(int argc, _TCHAR* argv[])
{
// Initialize the COM library
CoInitialize(NULL);

// Instatiate the EasyOPC-DA client object
IEasyDAClientPtr EasyDAClientPtr(__uuidof(EasyDAClient));

CComSafeArray ItemIdArray(4);
ItemIdArray[0] = _T("Simulation.Random");
ItemIdArray[1] = _T("Trends.Ramp (1 min)");
ItemIdArray[2] = _T("Trends.Sine (1 min)");
ItemIdArray[3] = _T("Simulation.Register_I4");

CComVariant vMissing;
vMissing.vt = VT_ERROR;

CComVariant vResults(EasyDAClientPtr->ReadMultipleItems(_T(""), _T("OPCLabs.KitServer.2"),
CComVariant(ItemIdArray.Detach()), vMissing));

CComSafeArray ResultArray(vResults.parray);
for (int i = ResultArray.GetLowerBound(0); i < ResultArray.GetUpperBound(0); i++)
{
IDAVtqResultPtr DAVtqResultPtr(ResultArray);
IDAVtqPtr DAVtqPtr(DAVtqResultPtr->Vtq);
_tprintf(_T("results(%d).Vtq.ToString(): %s\n"), i, DAVtqPtr->ToString().bstrVal);
}

// Release all interface pointers BEFORE calling CoUninitialize()
ResultArray.Destroy();
vResults.Clear();
EasyDAClientPtr = NULL;

CoUninitialize();

TCHAR line[80];
_putts(_T("Press Enter to continue..."));
_fgetts(line, sizeof(line), stdin);
return 0;
}



What I suggest is that we rewrite this code (or similar) so that it uses only "standard" C++ and works both under Microsoft C++ and your tool. I have looked around to see if there is a library that can make it easier, and have found just one, called VOLE:

vole.sourceforge.net/
sourceforge.net/projects/vole/
forum.dlang.org/thread/ep0jl7$...
<a href="www.artima.com/forums/flat.jsp?forum=269&thread=192386" target="_blank" rel="nofollow">www.artima.com/forums/flat.jsp...

with some examples:

www.codeproject.com/Articles/1...
www.codeproject.com/Articles/1...

Essentialy we would be doing the same as the examples do, except that we will call QuickOPC methods instead of methods of the MS Word or XML validator.
I cannot tell upfront if this is the viable way to go, but it is the (only) one that occurred to me. Please let me know how all this sounds to you.

Hello.
QuickOPC-COM is a Microsoft COM component itself, and therefore it should be consumable from any language and tool that supports using COM components. Since COM, however complex, is just a Windows API, and about the only thing that is truly required to use it is the ability to call Win32 functions and work with function pointers (vtables), it should work with any C or C++ compiler (on Windows only).
This said, the code that needs to be written may be somewhat ugly, but that's mainly for plain C. In C++, consuming COM objects is usually translated to calling methods on "normal" C++ objects. This is done by frameworks or libraries (such as ATL for MFC in Microsoft compilers). I believe that similar frameworks/libraries exist for gcc or Borland as well. Currently, we have no examples or more information about how to do this. If you want to pursue this scenario, let me know and I will be willing to work with you on figuring out the right way to do it.
OPC-UA is, from our point of view, a different story. For your needs, there is an ANSI C stack built by OPC Foundation itself (available in source to members). Using that one would be the most appropriate, "native" way to write a portable software that supports OPC-UA. Compared to QuickOPC, the API of the stack (or SDK) itself is quite complex. We, as a company, currently only focus on Windows, and therefore our QuickOPC-UA product does not use this stack, but instead it is based on .NET stack.
The bottom line is that I think that QuickOPC-COM can be a solution for you for connecting to OPC "classic" (COM-based) servers under Windows, even with non-Microsoft compilers. But we do not have such solution for OPC-UA, or any solution portable outside of Windows platform.
Best regards