Introduction

D-Cubed Components are used in a wide range of end-user application running on a variety of hardware options: From mobile apps on smartphones, high end CAE on desktop workstations to Cloud-based engineering solutions.

This article discusses how the deliverables for the D-Cubed Components are provided to meet the needs of all these types of user.

Component Design

D-Cubed Components are coded in C++ and are designed to be used with C++, C or any other high level language which supports a C calling structure. For each C++ function there is a corresponding C function that can be used by an application. Each component is essentially a C++ class, of which the application can have multiple instances.

In the case of static libraries, code is typically integrated in the executable, or one of its shared object libraries, during linking/compiling. Static archives reduce run-time loading costs and decrease the size of binaries, but require that the C++ run-times of the libraries and the binaries match.

Code in shared libraries is called at run-time. Shared libraries save memory and reduce swapping at the expense of function execution and run-time loading costs. Our shared libraries are digitally signed using a Siemens PLM certificate to verify authenticity and code-integrity.

Other than C++ run-times and math libraries, D-Cubed Components have no other external dependencies and so are very portable.

Platform Versions and Updates

We typically keep up to date with the compilers of the latest major versions of the single-track operating systems such as Windows, Mac OS and iOS. D-Cubed Components may be updated to the latest minor versions depending on compatibility and demand.

For the Android and Linux platforms which come in many flavours, we select versions and options that we expect to be widely compatible and to remain stable for long periods. Different versions and options may be considered on request.

Supported Operating Systems

The following tables describe operating systems that are currently supported by D-Cubed Components. Support that is planned around our next release cycle is also listed. However, this is an area that is evolving rapidly and questions about any specific platform can be sent to D-Cubed support.

Microsoft Windows Desktop

Compiler

Processor

OS

Current Release

Next Release

Visual Studio 2015

x86_64

i386

Windows 7 SP1 or later

Windows Server 2008 R2 SP1 or later

✔

Visual Studio 2017

x86_64

i386

Windows 7 SP1 or later

Windows Server 2012 R2 or later

✔

planned

Mac

Compiler

Processor

OS

Current Release

Next Release

Clang 8.0.0

x86_64

i386

OS X 10.11 or later

✔

planned

Clang 9.0.0

x86_64

i386

macOS 10.12 or later

planned

Clang 10.0.0

x86_64

i386

macOS 10.13 or later

planned

Linux

Compiler

Processor

OS

LSB compliant

Current Release

Next Release

GCC 4.8.5

x86_64

i386

RHEL 7 or later

SLES 11 or later

Other similar

✘

✔

planned

iOS

Compiler

Processor

OS

Bitcode

Simulator

Current Release

Next Release

Clang 7.3.0

ARM64

ARMv7

A6

iOS 8 or later

✔

x86_64

i386

✔

planned

Clang 9.0.0

ARM64

iOS 10 or later

✔

x86_64

✔

planned

Clang 10.0.0

ARM64

iOS 11 or later

✔

x86_64

planned

Android

Compiler

Processor

OS

NDK

STL

Current Release

Next Release

GCC 4.9

ARMv7a

ARM64

Android 5.0 or later

r13b

stlport_shared

✔

planned

Microsoft Windows Universal Platform

Compiler

Processor

OS

Current Release

Next Release

Visual C++ 14.14

x86_64

i386

Windows 7 SP1 or later

Windows Server 2012 R2 or later

✔

planned

.NET interface

We support .NET applications with an alternative interface for the D-Cubed 2D DCM and 3D DCM components that uses the.NET Framework 4.0.

The .NET interface is a separate bridge library supplied as a DLL which provides a C# class that mimics the C++ interface. An associated XML file provides the metadata for interface description. The .NET interface is fully managed, so it requires no application marshalling of data. Note that the .NET bridge DLL depends upon the native DCM library i.e a specific build for the underlying CPU; Pure CLR version of D-Cubed Components are not supported.

Parasolid Wrapper

For the CDM and HLM components, D-Cubed can provide a C++ wrapper that communicates directly with the Parasolid modeller. By using the wrapper, applications are not required to write functions for the calls that are made by the Frustum of the CDM or HLM. All the necessary geometric support for the CDM or HLM is provided by the Parasolid modeller.

Version Strategy

With each major D-Cubed release, the version numbers in the libraries are updated. By maintaining a wrapper around the component interface, applications can maintain multiple libraries in parallel and choose the desired function version without needing to re-compile.

The component interface requires that applications only need register mandatory call-back functions. We make sure to minimise the amount of work required to update component versions, so customers can make significant jumps in version without needing to modify their code.

Conclusion

This article has described the principles for how D-Cubed supports its products on different hardware and operating systems, and lists what is currently available. However, as mentioned above, this is an area that is evolving. If you have any questions please leave a comment or contact D-Cubed Support.