CO-LaN recommends that COBIA based applications are shipped with the latest COBIA Runtime. Release 1.2.0.10 contains several fixes to the COBIA Runtime.
The distribution is made of three elements:
- a zipped file that contains merge modules that are used in 3rd-party installation packages to install COBIA Runtime (also known as COBIA Core),
- an installation package of these merge modules for 64-bit machines (to be used to repair an installation of the merge modules made by other means),
- an installation package of COBIA Software Development Kit (SDK).
COBIA Runtime can be freely used and redistributed. COBIA Runtime consists of middleware components that will be installed on the end-user’s computer during installation of COBIA-based Process Modelling Environments (PMEs) and Process Modelling Components (PMCs) developed by a software provider. The COBIA Runtime is intended to be distributed with and utilized by third-party software.
The COBIA Software Development Kit (SDK) is provided for free as a stand-alone installation package which distributes a set of components and tools that are used by a software developer to create software that utilizes COBIA as the middleware for CAPE-OPEN interoperability. The SDK includes code generators to help create the source code of interfaces developed from the CAPE-OPEN Interface Definition Language (IDL) specifically adapted to COBIA. The SDK installer installs COBIA Runtime as well.
Development and maintenance of COBIA is conducted by AmsterCHEM for CO-LaN.
Please refer to the list of tickets fixed by version 1.2.0.10. Find hereafter explanations for the most relevant support tickets that are resolved by this release:
- Ticket 125: COBIA does not nicely pick up all COM CAPE-OPEN objects. Components that are not registered with {678c09a1-7d66-11d2-a67d-00105a42887f}, which is the CapeOpenComponent_CATID, so the CATID for any CAPE-OPEN component, were found by COBIA using Primary PMC CATIDs (CAPE-OPEN Property Package Manager CATID, CAPE-OPEN Property Package CATID, etc…). Fix consists of removing, from any list of components built by COBIA parsing through the registry, the components for which only the CapeOpenComponent_CATID is found.
- Ticket 126: C++ code generator misspells putVersionIndependentProgId. Code is generated that contains putVersionIndependentProgID instead of putVersionIndependentProgId (capital D). This issue is internal to COBIA generation.
- Ticket 127: For example if the ICapeUnit::Calculate method implemented on a Unit Operation fails because of an exception raised by a CalcEquilibrium call, the Unit Operation wants its Calculate method to raise an exception stating it failed because of the failure on the CalcEquilibrium call. However, the cape_open_error object lacks a constructor to raise an exception from a description with a contained error. This makes it impossible (from c++ code using wrapper objects) to raise a nested CAPE-OPEN error with a custom description. To resolve this issue, two constructors are added that take an error that was previously raised by another component. Advice: if your COBIA-based PMC wants to re-raise an error as a nested error, the fix of support ticket 127 may come handy. Re-building your COBIA-based application with the new version of COBIA SDK is then necessary.
- Ticket 128: corrects an, in principle, harmless issue. There is no need to re-build your COBIA-based application for this sole defect/fix.
- Ticket 129: Improper reporting of line and column number in C++ leads to a parser error in code generator. Lines were not properly detected, so all errors were reported at line 1, character #####. This issue is internal to COBIA generation.
- Ticket 130: Improper bracket matching resulting in C++ parsing errors. Brackets after division, e.g “1/(1+2)” were skipped due to improper reading of division. Leading to C++ parsing errors and inability to perform code generation. This issue is internal to COBIA generation.
- Ticket 131: when a COM object was registered in the Windows Registry by COMBIA, as the counterpart of a COBIA object, it was registered with a CapeVersion which is 1.2. As COBIA is itself based on CAPE-OPEN 1.2, this value for CapeVersion is nothing else than the CAPE-OPEN version on the COBIA side. However, CAPE-OPEN version 1.2 does not exist for COM. The COM-based implementations of CAPE-OPEN know about CAPE-OPEN 1.0 and CAPE-OPEN 1.1. Some COM-based PMEs have been known to rely on the value of the CapeVersion key when displaying CAPE-OPEN PMCs available for use and a CapeVersion as 1.2 was not making sense to them. Therefore, as per the fix made, when COMBIA is now registering a Property Package, a Physical Property Calculator or an Equilibrium Server in the Windows registry, it is storing 1.1 as the CapeVersion, and, for Unit Operations, COMBIA is storing 1.0 in the Windows registry for the CapeVersion of that type of PMCs.
- Ticket 132: in the Errata & Clarifications for Parameter Common interface specification 1.0, as published in February 2016 by CO-LaN (version 1.0.1.022) and part of the distributed documentation set of CAPE-OPEN Specifications, there is a detailed description of how CAPE-OPEN homogeneous array parameters should be implemented in COM. Their structure is defined as:
ICapeParameter.value is a COM VARIANT, with variant type (VARTYPE) set to VT_ARRAY|VT_VARIANT,
the VARIANT will contain a a SAFEARRAY(VARIANT) with one dimension stored at the VARIANT’s pArray member,
the lower bound shall be zero (0), and the number of elements of the array shall be the first(and only) element of the array obtained from the ICapeArrayParameterSpec.Size method…
This structure imposed itself to COMBIA. So the lower bound for homogeneous one-dimensional array parameters should be zero in COMBIA. Until version 1.2.0.10 it was one, and this was evidently causing problems. Resolution of ticket 132 brings the lower bound to zero. - Ticket 133: Synchronize access to COBIA objects from COM. COMBIA registers DEFAULT threaded COBIA objects as “Both”, which implies the COM side may be instantiated as supporting the MultiThreaded Apartment (MTA) model, which in turn implies that multiple concurrent incoming calls are in theory possible. COMBIA should shield against this. One synchronization object (e.g. std::mutex) has been implemented per PMC objects – including all its primary PMC objects to agree with DEFAULT threading model. Only partial testing of these modifications has been carried out, so far successfully, with the valued help from SINTEF that has a strong interest in having this synchronization working.
- Ticket 134: COMBIA incorrectly re-allocated Integer Array value as double array. Upon re-sizing COMBIA re-allocated the VARIANT as VT_R8 type, should be VT_I4. Fixed.
- Ticket 136: CapePMCEnumerator leaked contained object. COBIA PMEs that enumerate PMCs using the capeGetPMCEnumerator should be recompiled to avoid this leak.
CO-LaN encourages all software developers to use version 1.2.0.10.
Previous release was version 1.2.0.9 released on March 31, 2022. Version 1.2.0.9 was downloaded 131 times for the SDK installer, 122 times for the archive of runtime merge modules, and 261 times for the runtime installer since it was made available.
Questions on COBIA 1.2 can be posted on the CAPE-OPEN forum dedicated to COBIA.