Open Menu

Synergex Blog


Synergy .NET Platform Targeting Options

By Steve Ives, Posted on May 21, 2015 at 10:25 am

One of the many options that is available to developers each time they create a new project in Visual Studio is how to configure the platform targeting options in the project properties dialogs Build panel. In the latest versions of Synergy there’s probably not much to worry about because the default values probably do exactly what you want most of the time, but the default values were not the same in some older versions of Synergy .NET, so it’s a good idea to have a good understanding of what your options are, and what the implication of choosing each option is.

In Synergy 10.3.1a we’re talking about two options; the Platform target drop-down and the Prefer 32-bit checkbox.

Project Build Options

The Platform target drop-down allows you to select from three different ways that the assembly that is created by your project (the .DLL or .EXE file) can be created; essentially you are choosing which .NET CLR (and Framework) will be used to execute your code. The options are:

Any CPU (default) Assembly can be executed by either the 64-bit or 32-bit CLR, with 64-bit preferred.
x86 Assembly can ONLY be executed by the 32-bit CLR on an Intel x86 CPU.
x64 Assembly can ONLY be executed by the 64-bit CLR on an Intel x64 CPU.

It is important to understand that we’re not talking about which Synergy runtime components will be used, we’re talking about which .NET CLR will be used, and the matching Synergy runtime components must be present on the system in order for the assemblies to be used.

The Prefer 32-bit checkbox (which was added in Synergy 10.3.1a and is only available when the platform target is set to Any CPU) provides the ability for you to determine that even though your assembly will support both 32-bit and 64-bit environments, you would prefer that it executes as 32-bit if a 32-bit environment is available.

The chart below summarizes which environment (32-bit or 64-bit) will be selected for all possible combinations of platform targeting settings and deployment platform.

Framework Selection Grid

A red n/a entry in the table indicates that an assembly would not be available for use in that particular environment.

So what’s the take-away from all of this? Well it’s pretty simple; Stick to the defaults unless you have a good reason to do so. The current default is Any CPU, Prefer 32-bit which means that on Intel x86 and x64 systems your apps will run as 32-bit. This in turn means that you only need to install the 32-bit version of Synergy on runtime only systems unless you also need to run services such as license sever, xfServer, xfServerPlus or SQL OpenNET on the same system. Development systems should ALWAYS have 32-bit and 64-bit Synergy installed.


What’s in my library?

By William Hawkins, Posted on February 4, 2010 at 4:22 pm

The obvious answer that springs to mind is "books", but some may respond "what sort of library?".  Of course, in this context, I'm really referring to a library containing Synergy object code. 

When referring to Synergy subroutines and functions, on both Windows & Unix, you can perform a "listdbo" or "dblibr -t" on the object file/object library and peruse the output to see the names of your routines.  However, when referring to methods (in classes/namespaces), the name used is mangled.  This mangling process takes the fully qualified name of the method, the return type, and all the parameter types, and reduces it down to a mangled name.  In a lot of cases, you can look at the mangled name and stand a chance of actually recognizing the name of the routine, but decoding the parameters in your head may require the use of illegal drugs.

For example, if you see a mangled name of '7SYNPSG5CORE11UTILITIES3CC6SYNCC11GETCCNAME_O7SYSTEM7STRINGI', you could intuitively see that it's probably this routine: 'SYNPSG.CORE.UTILITIES.CC.SYNCC.GETCCNAME(I)@SYSTEM.STRING'. 

But what about this one: '7SYNPSG5CORE11UTILITIES3CC6SYNCC11GETCCNAME_O7SYSTEM7STRINGSP0P1P2P39CARDTYPE'?  It’s the "same" overloaded routine, but it has a SYNPSG.CORE.UTILITIES.CC.CARDTYPE parameter instead of an integer parameter.  Similarly, if you saw '7SYNPSG5CORE11UTILITIES8WORKING9SHOWFORM_XO7SYSTEM7STRING', you could probably see that it's 'SYNPSG.CORE.UTILITIES.WORKING.SHOWFORM(@SYSTEM.STRING)'.  Now, what if you saw this '7SYNPSGCR1UTLTESWRKNGSHW9HTGB13'?   Well, it's surprisingly the same SHOWFORM method, but it's been mangled beyond recognition.  The term used here at Synergex is "crushed".  In fact, if you have a crushed name, it's basically impossible to determine the original method name. If the mangled name of the method is too long for the environment, the mangled name is crushed down to the maximum size permissible.  OpenVMS has a limit of 31 characters, 64-bit systems have a 188 character limit, and 32-bit systems have a 200 character limit. Actually, the limit is one character less, because we use the rule that if the name is exactly the maximum size, it must be a crushed name.  As the last 7 characters of a crushed name is a checksum, on OpenVMS you’re only left with 24 characters for a human “readable” name.

So how, exactly, does a mangled name become a crushed name? Well, characters are removed, one by one, until the name is exactly the correct length. First non-alphanumeric characters are removed, then vowels, then letters from the name of your first born child, then random letters based on the cycle of the moon, until you eventually get a name that fits. So, with only 31 characters for method ames, the OpenVMS users out there will have to become accustomed to seeing crushed (i.e. indecipherable) method names inside Shared Image Libraries.  If you need to create an OpenVMS Shared image library, I would recommend creating an object library, and using the make_share.com file to convert to a shared image library.  However, you may need to review the use of the MATCH qualifier on your shared image libraries, as method names can change with the modification of a parameter (or return) type. So changing a method to (for example) have an additional optional parameter will cause a new method name to be created.  Unless you rebuild your application to see (and use) the new name, you could find that the application starts giving “routine not found” errors.

You might think that not knowing the name of the routine would be a problem – it's not really, because the compiler has a consistent supply of the same high quality drugs, and given a constant method signature, will always generate the same crushed name.  So it really doesn't care that that your code said  "object.showform(1)", because it'll know that you really want to call the method '7SYNPSGCR1UTLTESWRKNGSHW9HTGB13' from your library.

For most developers out there, the actual name of the method inside a library is unimportant, but I though the more curious of you out there would be interested in this.


RSS

Subscribe to the RSS Feed!

Recent Posts Categories Tag Cloud Archives