Note!

You must have JavaScript enabled for these web pages to function properly.

--------------General Information (32-bit & 16-bit)-------------------

In general, the DLL is no different that directly embedding the CLIPS engine into your source. However, in the 16-bit Windows environment this is a very large overhead burden to place on any application, (remember we only have the one 64k automatic data segment and CLIPS uses most of this on its own), thus having the CLIPS engine implemented as a dynalink was critical to larger 16 bit applications. While this problem no longer exists in the 32-bit Windows arena, there are still advantages to using the DLL vs. direct embedding. First, it is a standalone object and needs not be built; all of the functions may still be directly called from your application. Additionally, multiple processes can now share the DLL thus requiring less overhead than each one would if embedded separately. Note that all functions exported from the DLL are exported as cdecl. For interfacing to languages other than C, the VB./HLL interface DLL is provided, (of course some languages will allow for calling of C functions - you may wish to experiment with this on your own). There is some condensing of the interface done in the VB./HLL interface as well to make dealing with certain types of data easier. (If you are using the CLIPS wrapper class please see the notes on the C++ page).

---------------DLL FAQ---------------------

• Where can I obtain the source for the DLL? Contact Athena Information Svcs. While the DLL binary is free for redistribution, they retain rights to the DLL itself (and the source).
• How can I implement a USER function with the DLL? Look at the page here User Functions in the DLL.
• How can I get user input into CLIPS (have the CLIPS code prompt for information and then continue)? You need to structure your Rules and CLIPS workspace to accommodate embedding. The DLL will not provide any user interface capability this is delegated to the host program (which is the correct place to do this anyway). When a condition is met that requires user input, the rules should cease processing (nothing on the agenda). You then either have the host program examine the workspace conditions to see what (if any) information is needed (by examining the state of the facts, globals, etc. in the current workspace) and then gather it from the user and assert as new facts or globals (or new values). This would then cause more rules to be placed on the agenda, and Run() would be called again (continue the loop as needed). An alternative to having the host program examine the state of the workspace would be to have the host program capture specific routers and then have a rule (or rules) that will send messages to the route(s). The host program can then parse these messages to determine the required information, gather it from the user, push it back into the workspace and continue as above. See the VB 6 example using the OCX (VB6_OCX.ZIP). This uses a modifed version of the WINE.CLP program to demo a wine selection expert. A C++ version of this sample is included as well with the OCX installation from version 1.6.2 of the OCX upwards. An alternative method would be to use the callback functions (periodic and others) to make changes to the CLIPS environment, but this method limits you to NOT making any changes to the RETE network as it will still be processing.
• Why can't I register the DLL? Regsvr32 fails with an error. The DLL version of CLIPS is not an InProc server. It is simply a dynamic library version of the CLIPS engine. The only version available here that is COM enabled is the CLIPS OCX. A version of the InProc server (i.e. a COM DLL) will be available shortly.

---------------32-bit DLL version specific Notes---------------------

• All of the DLL versions include enhanced memory management, (a Windows specific implementation). [For the Technoids: this was actually implemented in C++.] Please note: The DLL version is NOT COM enabled. If you attempt to run REGSVR32 on it, it will fail (as it should). There is nothing that needs to be done to install the DLL other than placing on your system.
• One thing to remember, the Exit command in CLIPS ends up calling the CRTL _exit() command which when called in a DLL, with cause the loading process to exit as well. This is the way Windows works...
• The releases after 6.04.24 support a feature called BlackBoard Memory, (see the HTML page on this site specific to that topic for further information).
• The versions after 6.04.27 support building your own UserFunctions, without the need to rebuild the Main DLL...this is done by use of another external DLL that is built by the end user called CLPUSRFN.DLL, which is in turn called by CLIPS.DLL, (the name is NOT negotiable - it must be named this). It must export the int UserFunctions(void) as well as any functions you define...the setup for the UserFunctions() call is demonstrated in the std CLIPS docs, (I will not cover this here), other than the above there is nothing different, simply build your own DLL with the user functions in it, register them with CLIPS in the entry point and it will automatically load and use this DLL, (it would need to be in the search path or current working directory naturally). If it can't be found then it is presumed that no User Functions are needed. There is always the ability to hook any CDECL function by simply calling the appropriate DefineFunction calls so you could still have ANY function be a UserFunction by calling the appropriate APIs at runtime.
• The versions after 6.04.33 include support for Long FileNames
• The versions 6.04.30 and later added 4 new functions (see below)
• Version 6.05.x Adds the CLIPS 6.05 CORE code build Version x.xx.40 is basically pure maintenance, rolls in the latest DR fixes
• Version 6.10.45 Rolls in the new 6.1 functionality. When they released 6.0 they deprecated certain functions in favor of newly named versions. With 6.1 these were completely removed. The 6.1.x DLL exposes BOTH interfaces in these cases for compatability. The OLD deprecated names simply call their new counterparts. Here is a quick list of the functions affected:
  • SetMemoryStatusFunction() = SetAfterPromptFunction()
  • CLIPSFunctionCall() = FunctionCall()
  • CLIPSSystemError() = SystemError()
  • ExitCLIPS() = ExitRouter()
  • PrintCLIPS() = PrintRouter()
  • GetcCLIPS() = GetcRouter()
  • UngetcCLIPS() = UngetcRouter()
  • InitializeCLIPS() = InitializeEnvironment()
• Version 6.10.46 ... 47. Rebuilt with Visual C++ 6.x runtimes. Now requires version 6.x of MSVCRT.DLL
• Version 6.10.48 modifed prototype for Matches() function. (see below)
• Version 6.10.49 (Internal release only, not regression tested) Fixed a leak in the BlackBoard memory space.
• Version 6.10.50 fixed a bug with the LFN code in inscom.c breaking some of the Instance StringRouter functions, (LFN support was added way back in 6.05.33). Specifically LoadOrRestoreInstances() was broken if using a string router source.
• Version 6.10.51 Added a new export (see below) for facilitating Batch processing
• Version 6.10.52 Cleaned up some of the CLIPS code to be more friendly for tools such as Purify and BoundChecker. It now generates many less irrelevant warnings when run in such environments.
• Version 6.10.53 Added the sleep function. Takes a single parameter (time in milliseconds to sleep the current thread). Usage: (sleep 100)
• Version 6.10.54 Again modifed the RouteCommand function arguments (see the notes following this). The wrapper classes have been modifed to account for this. If you are using the wrappers with the DLL you will need to update them with the DLL. The BINARY save file format was also changed. If you are using BSaved files from an earlier version, they must be regenerated (i.e. BSave them again) using the newer version of the DLL before attempting to BLoad them.
• 6.10.55 ... 6.10.61 DRs through DR836 verified completed. More extensive testing with Windows 2000 and added support for side-by-side versioning.

---------------------------Additional Functions--------------------------

The following was added to allow you to set a MessagePump

void SetYieldTimeFunction(void (*func)(void));

This would be important only in a single threaded application, so that the application does not appear to 'hang' during CLIPS processing.

The Fact Manipulation callbacks added were:

• BOOLEAN AddAssertFunction(char *,VOID (*)(void *),int);
• BOOLEAN AddRetractFunction(char *,VOID (*)(void *),int);
• BOOLEAN RemoveAssertFunction(char *);
• BOOLEAN RemoveRetractFunction(char *);

The callback they will use is prototyped as:

VOID (*functionPtr)(void *)

Where the VOID * it receives as a parameter is the fact pointer currently being asserted or retracted. It is very important to NOT modify the state of the RETE network inside these callback functions, you have been warned.

6.1.51 added :

void BatchLoop(void) (commline.c). This will execute a loop on the open batch sources and terminate when batch processing is complete (or when HaltExecution is set).

Misc.........................

int CLIPSVERSION(int) takes an INT param returns an INT, if the parameter is non zero it will additionally pop-up a message box to display the DLL version, returns the VERSION of CLIPS as an integer, (604 = 6.04). This is the ONLY function exported from the DLL with a __stdcall stack frame char *WinAlloc(long Size) void WinFree(char *) These functions handle the memory allocation and freeing for CLIPS at the Windows interface. You need not call them directly, you can call the genalloc and genfree CLIPS calls if you rather. The DLL is running with Block memory allocations enabled. This means that CLIPS is using its own memory manager to handle sub-allocations and is only requesting memory in fixed block sizes. The block size is set to 128k. These are the system functions that enable the blackboard memory area. See the notes on this feature for more specifics. These are not intended to be called directly, there are CLIPS functions that allow these to be used in your CLP files -- see the related document on this. There shouldn't be a real problem with calling them directly from C/C++, but this was not the intention and was not tested.

• int CLIPSSetGlobalStringObject(void);
• int CLIPSSetGlobalIntObject(void);
• int CLIPSSetGlobalFloatObject(void);
• void *CLIPSGetGlobalStringObject(void);
• int CLIPSGetGlobalIntObject(void);
• float CLIPSGetGlobalFloatObject(void);
• int CLIPSFreeGlobalObject(void);
• long CLIPSQuerySlackSpace(void);
• int CLIPSDefragmentSharedPool(void);
• VOID BlackBoardFunctionDefinitions(void);

----------------------------Modified Functions--------------------------

RouteCommand(char *command, int printResult, char *routeName) : RouteCommand() now has an extra parameter that specifies which route/logical name the output should be sent to.

globle BOOLEAN Matches( void *theRule, char *theRoute ) : Matches() now has an extra parameter that specifies the route the output should be sent to. If this is NULL then WDISPLAY is used.

<CLICK HERE TO LIST ALL DLL EXPORTED FUNCTIONS>