Software Testers' Page

This page contains updated versions of current Wolverine products and trial versions of new products.  Updates to existing products are placed on this page only when substantial changes have been made, and notwithstanding rigorous testing by Wolverine, there's a small, but non-zero probability of failure, due to the extensive nature of the changes.  New products are placed on this page to allow you to get an advanced look at them and to provide us feedback.  The testing programs for some new products may be by invitation only.  We do this in the early stages of new product testing, when we prefer to work with a small number of existing customers.  Of course, if you'd like to become a participant in a limited program, you can always ask us.

Software Download Security Issues

You should be concerned with the security of files you download. Important information about the security of Wolverine-provided downloads is available here.

License Agreements

All updates are subject to the license agreements you agreed to when the software was originally installed.

Test Versions of SLX

The AR087 version of SLX includes improvements and fixes described below.  This release has been superseded by the AR137 version, published on the SLX Updates page.

1.  This is the final major upgrade of code generation for string operations.  In this release, single-character operations have been speeded up considerably.  Many applications that do a lot of parsing of textual data and piecewise construction of strings will run faster.

2.  A new item has been added to the File menu and the toolbar for opening recently used SLX files.  Clicking on this menu item / toolbar icon displays a standard Explorer-style file opening menu; however, only the 25 most recently accessed SLX files and the folders containing them are shown.  All other files and folders are removed from the lists that Windows would otherwise display.  This prevents fruitless searching of folders that do not contain recently accessed files.  Switching back and forth among multiple projects will now be easier.  The most recently accessed SLX files are still shown at the bottom of the File menu, but the history shown there is limited to 9 files.

3.  The underlying support for SLX's formatted output now uses Windows RichEdit 3.0, rather than RichEdit 1.0.  RichEdit 3.0 supports right-justified and centered tab stops.  Previous releases of SLX approximated right-justification and centering by measuring text widths to calculate offsets of left-justified tab stops, which were the only kind of tab stops available under RichEdit 1.0.  Windows' text measurement is notoriously quirky, so this approach was problematical.  As a result of the upgrade, alignment of SLX output is greatly improved.

4.  A problem that lead to multiple invocations of "Disconnect" functions in DLLs has been corrected.

=== End of AR087 Update ===

The EB167 version of SLX includes changes described below.  Click here to download updates for 32-bit systems, and click here for 64-bit systems.

1.  The efficiency of set membership interrogation operators ("is_in", "contains", and "is_not_in") has been improved.  This was accomplished by tweaking hash algorithm properties and providing an alternative algorithm that is used when a queried set has a small number of members.  For small sets, a short, but fast "brute force" search outperforms SLX's hash algorithm. 

Set membership interrogation can be a large component (up to 20%?) of execution time.  For programs where this is the case, improved performance will be quite evident.  There's a new option that allows you to monitor the effectiveness of SLX's set membership interrogation algorithm.  Click on Options, "Show is_in / is_not_in Statistics".  Collected statistics include the total number of interrogations and the average number of iterations per interrogation.  The iteration count should be between 3 and 4.  If you see values greatly exceeding 4, let us know, because this is an indication of less than desirable performance.

2.  There's also a new option for displaying the efficiency of "wait until" operations.  "Wait until" efficiency reflects how well a program is written, rather than how well SLX itself is performing.  To display "wait until" statistics, click Options, "Show Wait Until Statistics".  Collected statistics include the total number of "wait until's" executed, and the average number of attempts per success.  Low ratios of attempts to successes indicate that a program is using "wait until" effectively.  For example, consider a ratio of 2.  This indicates that a typical "wait until" consists of one FALSE (blocking) condition followed by success when the control variable(s) in the "wait until" change.  High ratios are indicative of "control variable abuse."  Consider a "wait until" statement that causes 1,000 pucks to wait.  If the "wait until" is used to enforce one-at-a-time logic, when the condition becomes TRUE, all 1,000 pucks will re-execute the "wait until".  It is very likely that one will succeed, and the remaining 999 will have to wait again.  Obviously, this sort of operation is very costly.  In such cases, you should use managed queues, in which reevaluation of blocking conditions is done less frequently.

3.  The overhead of procedure invocation has been reduced.  Programs that make large numbers of calls of small procedures will run faster.

4.  SLX's callback functions for performing set manipulations from within user-supplied DLLs have been revised to correct some deficiencies.

5.  The 5-second periodic update of SLX's IDE during program execution has been expanded to update any debugger windows that are active.  The "Calls & Expansions" window, which is always open is now included in the 5-second update.

This update should be the last major revision of SLX for some time.  Please let us know if you experience any difficulties.  In a week or two, a new update will be posted on the normal SLX Updates page.

=== End of EB167 Update ===

The AN047 version of SLX includes changes described below.  Before updating your copy of SLX, be sure to read the warning at the conclusion of the description of this update.  Click here to download updates for 32-bit systems, and click here for 64-bit systems.

1.  Consider the following code fragment:

        ...

        print (ACTIVE, ME, ww) "_ _ _\n";

In the above example, "WhoAmI" is a method of class widget, and it is invoked with explicit qualification ("w -> WhoAmI(w)").  SLX also allows unqualified invocation of methods from within a class.  An unqualified invocation applies a method to the currently active instance of the class.  Unqualified method invocations date back to the earliest versions of SLX, in which a method was simply a procedure defined within a class, and qualified invocations did not exist.

When processing method invocations, the SLX compiler must distinguish among a number of cases, e.g., whether an invocation is qualified or unqualified, whether an invocation is inside or outside a class, and whether an invocation is within another method of the same class.  (Some combinations are illegal.)  In the example above, SLX's algorithm for determining the type of invocation was wrong.  Although it processed the pointer qualification, the compiler generated code that passed the address of the currently active instance of class widget rather than the value supplied in pointer "w".  This problem has been fixed.

2.  Consider the following example:

The example above contains an unmatched quotation mark within a comment.  In attempting to skip over the comment, the SLX compiler was confused by the quotation mark, which it should have simply ignored.  As a result of this confusion, the compiler "swallowed" the "*/" that should have terminated the comment, and even worse, the following #endif.  This problem has been fixed.

3.  The 64-bit version of SLX now uses SSE floating point instructions for almost all floating point operations.  (In the 64-bit world, traditional X87 floating point instructions are considered to be a "legacy" feature.  Microsoft's 64-bit compilers generate SSE floating point instructions.)  Prior to this release, SLX-64 used legacy floating point instructions for almost all floating point operations, and invocations of Microsoft-compiled run-time support functions required that values stored in legacy registers be stored in memory and reloaded into SSE registers.

Conversion to the preferred form of 64-bit floating point arithmetic required a major overhaul of SLX's 64-bit floating point code generation.  Although effects on SLX-32 were minimal, in a few places, changes required for SLX-64 also required changes to SLX-32.  For this reason, the AN047 update has been placed on this Testers' page, rather than being placed on the SLX Updates page.  Be sure you have backed up your current version of SLX before trying this release.

=== End of AN047 Update ===

Differences between SLX-32 and SLX Classic

Effective September 1, 2006, Wolverine began shipping SLX-32, a new version of SLX developed using Microsoft tools and ceased shipping SLX Classic, which had been developed using Watcom tools.

For an overview of SLX-32, please see our News page.  Most users should notice few differences between SLX-32 and "old" SLX.  The following is a brief summary of differences:

1.  Performance is somewhat faster.  This has been accomplished by exhaustive review of source code and cleanup, where appropriate.   For a number of SLX constructs, SLX is able to exploit instructions found on "newer" hardware, including SSE2 and SSE3 instructions.  Additional performance improvements are obtained by enforcing hardware-friendly data alignment.  For example, double values are now aligned on 8-byte boundaries, whereas "old" SLX used 4-byte alignment.

2.  Memory requirements are somewhat greater, largely due to data alignment.  The impact of increased memory requirements can be reduced by grouping double values together, e.g., not intermixing declarations for 4-byte ints and 8-byte doubles.

3.  If you're using DLLs, you may have to recompile them if you're directly accessing attributes of SLX objects.  This, too, is a consequence of data alignment changes.  As with "old" SLX, you can have the SLX compiler generate a ".h" file describing the data layout of any SLX objects your DLLs reference.

4.  Memory allocation has been improved.  SLX now uses a lower-level interface for acquiring memory from Windows, and it does more memory management on its own.  SLX-32 is the beneficiary of extensive work we did to build a mixed 32- and 64-bit memory manager for SLX-64.

5.  Lengths of character strings are now handled using unsigned arithmetic, so the maximum string length in SLX-32 is 65535, rather than 32767.

Note 1: SLX-32 recognizes only Sentinel SuperPro security keys.  It will not recognize old, dark green keys that Wolverine used to distribute.

Note 2: If SLX-32 fails to recognize your Sentinel SuperPro key, you should download the latest Security Key Updates.