Parasolid Release Area

Contents

• 4.1 Contents of the release area
  • 4.1.1 Privileges
  • 4.1.2 The ‘base’ directory
• 4.2 Explanation of files
  • 4.2.1 Files in ‘base’
  • 4.2.2 The Kernel Interface Driver (KID)
  • 4.2.3 Schema files
  • 4.2.4 Finding shared libraries

[back to top]

4.1 Contents of the release area

The top level of the Parasolid DVD contains a parasolid folder. Inside this folder, there is a sub-folder for each platform available on the DVD. For example, the Parasolid folder contains sub-folders such as intel_nt , intel_linux , x64_win , and intel_macos .

Inside each directory is a base directory that contains all the files necessary to install and use Parasolid for that platform.

This chapter describes the contents of these directories in some more detail. Apart from some platform-dependent filenames (noted below), the contents are essentially the same for each platform.

base_vc17

base_vc17

[back to top]

4.1.1 Privileges

You must make sure that all Parasolid users are able to read these files once they have been copied from the DVD.

[back to top]

4.1.2 The ‘base’ directory

The base directory contains all the files needed to install and use the full Parasolid kernel.

Sample code for foreign geometry, frustrum and testing:

fg.c

frustrum.c

frustrum_delta.c

frustrum_test.c

parasolid_test.c

Build scripts, pre-built libraries and LISP test (not supplied for iOS), all of which are sample code:

fg.lib

fg_library.bat, fg_library.com

frustrum.lib

frustrum_library.bat, frustrum_library.com

frustrum_link.bat, frustrum_link.com

kid_test.lsp

parasolid_link.bat, parasolid_link.com

The ‘lispdata’ sub-directory

This directory contains just one file, not supplied for iOS. This is for use with KID (see below) and is not for redistribution.

bbcini.lsp

The ‘schema’ sub-directory

This directory contains a number of schema files whose names have the form sch_XXX.sch_txt .

The ‘dll’ sub-directory (Windows)

This directory contains a Parasolid DLL, its corresponding import libraries, and a KID executable linked against the Parasolid DLL. The following DLLs are available:

• pskernel.dll - DLL for Parasolid kernel
• pskernel_net.dll - .NET binding DLL for Parasolid (relevant Windows platforms only). See Chapter 12, “Calling Parasolid From .NET Code” in the Parasolid Functional Description manual for more details.

The ‘shared_object’ sub-directory (UNIX & Android)

This contains the Parasolid shared library, a KID linked against it, and some supporting files:

• libpskernel.so - Parasolid shared library.
• libkid_support.so - shared library of support functions for KID.

On MacOS platforms, the filename extension for shared libraries is .dylib rather than .so

iOS

No form of shared or dynamic library, nor a KID executable, are supplied for iOS.

[back to top]

4.2 Explanation of files

[back to top]

4.2.1 Files in ‘base’

Parasolid archive library

For most purposes, it will be more convenient to use the Parasolid “shared library”, found in the ‘dll’ subdirectory on Windows platforms, or the ‘shared_object’ subdirectory on UNIX and Android. The archive library is supplied for use on iOS platforms, and for customers who need to link their own shared library,

PK and KI interface header files

Interface functions and type declarations for C/C++ applications.

Ifails and tokens header files

These are necessary for an application program to avoid using numeric values for PK arguments.

Parasolid test code

This is included so that you can make a simple test that the library is set up correctly before integrating it with the application program. Parasolid requires a Frustrum - thus a dummy frustrum library is also included. This should only be used for experimentation and learning, any customer Frustrum should be written to suit the application. Parasolid can also use Foreign Geometry functions, and example functions are included, although you should contact Parasolid Support before using them.

Frustrum test code

This tests the dummy frustrum library in isolation from the Parasolid library. It uses the Frustrum tester function (TESTFR), see the Parasolid Downward Interface manual for a full explanation of this. This program can also be used to test your own Frustrum.

Frustrum source code and library

Supplied for building and running the frustrum test code.

Frustrum library command file

Supplied to build a Frustrum library from the source code.

Frustrum link and Parasolid link command files

These are supplied to link the test programs with the libraries.

[back to top]

4.2.2 The Kernel Interface Driver (KID)

The KID program provides a LISP front-end to the Parasolid library, which can be used to learn the Kernel, and prototype applications. For a full description see the Parasolid Kernel Interface Driver (KID) Manual. KID loads the LISP initialization file at start-up. The KID test file is supplied as an acceptance test for the KID program.

[back to top]

4.2.3 Schema files

The content and format of Parasolid part files (either transmit or partition files) is referred to generically as the schema. The schema needs to be present so that a Parasolid-powered application can

• read part files created using other versions of Parasolid
• write part files that can be read in other versions of Parasolid

New schemas are released from time to time with new releases of Parasolid. You can find out what the current schema version is using PK_SESSION_ask_schema_version.

By default, since Parasolid V14.0, the relevant schema is embedded inside every Parasolid part file. This ensures that Parasolid parts can be received not only by later versions of Parasolid (e.g. you can read a V14.0 part file into Parasolid V15.0), but by earlier versions as well (e.g. you can read a V15.0 part file into Parasolid V14.0).

However, part files saved by versions of Parasolid before V14.0, and part files saved in any version of Parasolid using an explicit transmit version, do not have the relevant schema embedded. In these cases, an external schema file must be present in order to receive and transmit Parasolid data.

Schema files are platform independent, text based files with a name of the form sch_ XXX .sch_txt (or sch_ XXX .s_t for DOS FAT file systems).

The appropriate schema file must be present when receiving a part file created in an older version of Parasolid, or when transmitting a part file using an explicit transmit version. For instance if you are trying to read a V11.0 or V11.1 part file into Parasolid V15.0, the relevant schema file ( sch_11004 , in this case) must be present.

• Parasolid guarantees upward compatibility of part files between major versions of Parasolid. To support this, schema files corresponding to all previous versions of Parasolid are provided with each new release.
• In Parasolid V14.0 and later, Parasolid guarantees downward compatibility of part files with an embedded schema to at least the previous major version. Thus, a V15.0 part file can be received by Parasolid V14.0.
• Parasolid also guarantees two-way compatibility within a major version of Parasolid (e.g. a V14.0 file can be read into V14.1 and vice-versa).
• Caveat: parts and partitions containing facet geometry can be received into Parasolid V28.0, but the facet geometry will not be present. They work normally in Parasolid V28.1 onwards.

[back to top]

4.2.4 Finding shared libraries

You can link your application(s) against the Parasolid shared library, and then upgrade them with a newer version of Parasolid by simply providing the new shared library file. You must make sure that the new library is a Parasolid version that is compatible with the old one.

If an application needs to check the Parasolid version at run-time, it can use run-time library functions to open the shared library (e.g. dlopen() on some UNIX machines, or LoadLibrary() and GetProcAddress() on Windows platforms) and call PK_SESSION_ask_kernel_version to extract the version information.

The KID linked against the Parasolid shared library contains embedded information about where to look for the Parasolid library. This information may need to be overridden, so that the run-time loader will search the directory where the customer has put the libraries:

UNIX

The KID executable in base/shared_object/kid.exe is built consistently on all UNIX platforms and expects to use a PATH-like environment variable to locate the Parasolid shared library. You need to ensure that the directory containing the Parasolid library is included in the value of this environment variable. The name of the environment variable used varies depending on the platform, as shown below:

LD_LIBRARY_PATH

DYLD_FALLBACK_LIBRARY_PATH

Further details should be available in the linker and loader documentation for your platform. The ld man page is usually a good starting point.

Windows

The PATH environment variable is also used as the DLL search path. The search path for a DLL is:

• The directory where the executable module for the current process is located.
• The current directory.
• The Windows system directory.
• The Windows directory.
• The directories listed in the PATH environment variable.

See Section 6.6.1, “Windows run-time libraries”.

See also Section 6.9, “Linking Windows run-time libraries”

iOS

No form of dynamic or shared library is supplied for these platforms, nor is a KID executable. This section is not applicable to these platforms.

Android

The KID executable in base/shared_object/kid.exe is built to run in the ADB shell environment, not on a standalone device. It expects to use the LD_LIBRARY_PATH variable to locate the Parasolid shared library, very much like Linux. You need to ensure that this environment variable is set up, and the directory containing the Parasolid library is included in its value. Parasolid also requires the C++ run-time library from the Android NDK, libc++shared.so , which you must copy to the device, and place in a directory that is included in LD_LIBRARY_PATH. See Section 6.3.8, “ARM Android” for more details.

[back to top]