[Date Index] [Thread Index] [Author Index]

Re: From C/C++ to Mathematica?--> MathLink programs in C for Windows

• To: mathgroup at smc.vnet.net
• Subject: [mg48247] Re: From C/C++ to Mathematica?--> MathLink programs in C for Windows
• From: "Roger L. Bagula" <rlbtftn at netscape.net>
• Date: Wed, 19 May 2004 02:42:33 -0400 (EDT)
• References: <c8cgso$el9$1@smc.vnet.net>
• Sender: owner-wri-mathgroup at wolfram.com

http://documents.wolfram.com/v5/Add-onsLinks/MathLink/System-SpecificInformation/Windows/Introduction.html
Wolfram ResearchProductsPurchasingServices & ResourcesNews & 
EventsCompanyOther Wolfram Sites
Search within



MathLink for Windows

Developer Guide

Version 4, Revision 11

June 4, 2003

This document is organized so that you will be most successful if you 
read the sections in order.

This document describes how to compile and run MathLink programs written 
in the C language on computers running a Microsoft Windows operating 
system. (The Mathematica Book describes how to write MathLink programs 
in both the Mathematica language and the C language.) This document also 
describes how MathLink is implemented for Windows.

This document does not teach you, in general, how to use your compiler 
and other development tools, nor does it teach you how to program in C 
or generally how to use a Windows-based computer. It is assumed that you 
have at least worked through the tutorial introduction that came with 
your set of tools. If you have any trouble building or running your 
MathLink programs, see the troubleshooting section at the end of this 
document.

Most of what is described in this document is Windows specific. To learn 
how to compile and run MathLink programs for another platform, see the 
Developer Guide for that platform.

Revision History

Changes in Revision 11

     * Revision 11 includes one new communication protocol, the TCPIP 
protocol. TCPIP replaces the older protocol TCP. TCPIP runs 
significantly faster than its predecessor and has some other useful 
features such as the ability to specify the urgent message port number 
at link creation time. The TCP protocol will remain in the library to 
enable communication with older versions of the MathLink library. 
Programmers who plan to use a TCP/IP based protocol in a new program 
should use the TCPIP protocol.

     * The MathLink library now uses the SharedMemory protocol as the 
default protocol on Windows. In addition the SharedMemory device has had 
numerous bugfixes.

     * Added new experimental API functions MLSetEnvIDString0 and 
MLGetEnvIDString0. These functions allow the programmer to assign a 
string name to their MathLink environment(perhaps serving as an 
identifier)prior to opening and connecting any link. The remote side of 
the connection can then get the local program's string after 
establishing the link. The programmer may find these functions useful if 
he/she needs to identify a program prior to exchanging MathLink packets. 
The names, functionality, and existence of these functions may change in 
a future release.

     * Added new experimental function MLVersionNumber0. This function 
exists to allow the programmer to return the interface number and 
revision number of the MathLink library used at runtime. The name, 
functionality and existence of this function may change in a future release.

     * MLName now correctly returns the complete path in the linknames. 
Previous versions of the MathLink library incorrectly truncated 
linknames if the name contained a path with a space character. For 
example "C:\Program Files\Wolfram 
Research\Mathematica\5.0\AddOns\MathLink\DeveloperKit\Windows\PrebuiltExamples\addtwo.exe" 
truncated to "C:\Program". The linkname will now contain the full path. 
However due to limitations in the Windows filesystem interface, users 
may still experience problems in the odd case where they have a path and 
an executabe file with the same name. For example if a user has a file 
"C:\Program.exe" as well as a directory "C:\Program Files", then 
linknames that contain "C:\Program Files" will not display correctly, 
however the link will still function correctly. If you need to have the 
full path included in the linkname in this case, you can always enclose 
your linkname in quotes to retain the full path.

     * MLPutMessage will only accept messages whose value will fit 
inside a 32 bit unsigned integer. A future version of MathLink will 
remove this limitation.

Changes in Revision 10

     * Added a Shared Memory device for Windows.

     * Added a Mac OS X version in revision 9.

     * Internal bug fixes (many).

Changes since Revision 6

Shared Library changes

All Platforms

     * The function MLGetString() could fail in some circumstances when 
a binary number was on the link. This bug was fixed.

Changes to "mathlink.h"

     * The value of MLREVISION in "mathlink.h" was changed from 6 to 7.

Changes since Revision 5

Shared Library changes

All Platforms

     * Getting and putting symbols and strings is now, on average, faster.

     * Getting and putting arrays of numbers is now faster.

     * The library was built with an improved optimizing compiler.

     * The function MLCreateMark() is now more efficient.

     * There are now functions for putting and getting numbers in 
Mathematica's *^ and ` notations.

     * The array functions in MathLink have been generalized to handle 
arrays with leaves other than machine numbers and with leaves that are 
not all the same type.

     * The function MLToLinkID() was added as a synonym for MLNumber(). 
This function returns a unique identifier for each link object that has 
been opened within the given MathLink environment. The function 
MLFromLinkID() was added. It returns the link object for a given 
identifier if that link is still open. Otherwise it returns NULL. This 
function returns the open link object with the minimum identifier if 0 
is passed in.

     * MathLink is more compatible with threaded programs.

     * A debug version of the MathLink shared library is now released 
with the standard MathLink distribution.

     * The debug shared library now detects more programming errors.

     * The function MLReady() now detects more cases when the link has 
died because the other process terminated without calling MLClose().

     * When MLTransferExpression() failed, it would sometimes clear the 
error reported by MLError(). This has been fixed.

     * When MLDuplicateLink() was called on a loopback link that had not 
had its input buffer filled (e.g. by calling MLFlush()), it could cause 
a crash. This has been fixed.

     * Creating marks when compact arrays were on the link sometimes 
caused a crash. This has been fixed.

     * The function MLErrorString() has a more complete list of error 
strings.

     * The semantics of MLNewParameters() and how MathLink does 
versioning was changed. See the section in the Macintosh or Windows 
Developer Guides entitled "Versioning with MathLink".

     * A bug was fixed that had caused MLLoopbackOpen() to crash when 
passed zero as its first argument.

     * The function MLGetByteString() now always returns a null 
terminated string. (A Mac compiler bug sometimes prevented this.) Of 
course there may be other null characters in the string and one should 
use the output length parameter to determine the string length.

     * The function MLTransferExpression() now properly handles raw 
data, uses less stack space and doesn't convert strings unless required.

     * Calls to MLInitialize() and MLDeinitialize() can now be nested. 
Only the outer MLInitialize/MLDeinitialize pair actually has any effect, 
and every call to MLInitialize will return the same value. This has the 
potential to break incorrect programs that call MLInitialize multiple 
times but only call MLDeinitialize once. Such programs will no longer be 
deinitializing the MathLink environment when they call MLDeinitialize.

     * MLTransferToEndOfLoopbackLink() now allows NULL as the 
destination link.

     * A bug caused MLNewPacket() to fail after an overflow error 
(MLEOVFL) was cleared by MLClearError().

Macintosh

     * Classic 680x0 Macintosh programs no longer need the " CFM Runtime 
Enabler" installed in the "Extensions" folder in order to use the 
MathLink shared library. However, they can take advantage of it if it is 
installed.

     * Two new stub files were added in the "Compiler Additions" folder. 
See the section in the Macintosh Developer Guide entitled "Versioning 
with MathLink".

Windows

     * On Windows platforms, the message handling and yielding 
facilities within MathLink now work more effectively with threaded 
programs and programs that have no user interface (i.e., programs that 
don't dispatch user events).

     * The function MLName() now properly deals with filenames 
containing spaces on Microsoft Windows.

     * The function MLConfirm() now works properly on Windows.

MathLink device changes

All Platforms

     * Server programs that need to open several links using the same 
link name are now supported by some link protocols.

Macintosh

     * The mechanism for finding and loading low-level MathLink devices 
was generalized for MacOS platforms.

     * When the user canceled the browser dialog box of the "PPC" link 
protocol, the Macintosh FrontEnd would give a misleading message. This 
has been fixed.

     * Some missing numeric conversions were added that may be needed by 
classic 68K applications running on a PowerPC computer.

     * Specifying an internet host using a domain name rather than an IP 
address on PowerPC-based computers did not work. This has been fixed.

     * A bug was discovered in JavaSoft's Java Runner v1.0.2 for 
Macintosh when MathLink was used in multiple threads of a Java 
application. MathLink now works around this bug.

Windows

     * The FileMap link protocol on Windows is now faster.

     * The algorithm used by the Windows FileMap protocol for generating 
a link name when none is provided has changed. The old algorithm was 
based on the system clock. The new algorithm uses random numbers.

     * The Windows FileMap protocol could only open one link object per 
second. This has been fixed.

     * The Windows FileMap protocol now supports link names of up to 31 
characters.

     * Specifying an internet host using an IP address on Intel-based 
computers (Windows and Unix) required that the 4 octets of the address 
be given in reverse order. This has been fixed.

     * The 16-bit Windows "Local" protocol now detects a request to use 
a link name that is already in use.

     * The Windows FileMap protocol had a bug that could cause MathLink 
communication to be slower if a program called MLEnd() while a second 
link was still open. This has been fixed.

Unix

     * The mechanism for finding and loading low-level MathLink devices 
was generalized for Unix platforms.

     * Specifying an internet host using an IP address on Intel-based 
computers (Windows and Unix) required that the 4 octets of the address 
be given in reverse order. This has been fixed.

     * The "TCP" protocol is now compatible with versions of Linux using 
libc.6 and libc.5.

Changes to "mathlink.h"

     * The value of MLREVISION in "mathlink.h" was changed from 5 to 6.

     * All functions in "mathlink.h" are now properly declared for use 
from C++.

     * To enable Windows MathLink to communicate more efficiently with 
MathLink on other platforms, some internal changes were made that 
required some constants to change in "mathlink.h".

     * The macros MLTK_MLSHORT, MLTK_MLINT, MLTK_MLLONG, MLTK_MLFLOAT, 
MLTK_MLDOUBLE, and MLTK_MLLONGDOUBLE were added as an indication of what 
representation the MathLink library assumes for these C arithmetic 
types. The macros MLTK_CSHORT, etc., are defined using heuristics that 
attempt to determine the representation that your compiler uses for 
these C arithmetic types when compiling code that includes "mathlink.h".

     * All declarations using the long double type are now protected by 
the CC_SUPPORTS_LONG_DOUBLE macro.

     * The file "mathlink.h" was cleaned up a little.

"Mprep" changes

All Platforms

     * "Mprep" now generates the following macro for the benefit of code 
that may rely on a particular revision of "mprep".

           #define MPREP_REVISION 6

     * The argument to the :Evaluate: keyword is now put on stdlink 
using MLPutByteString() rather than MLPutString() as this is more 
convenient in this context. So, for example

       :Evaluate: x="a\nb"

       will cause MLPutByteString() to be called with a string of 8 
characters (represented by 8 bytes) to be sent to Mathematica for 
parsing and evaluation. Whereas, with MLPutString(), the 8 bytes would 
represent 7 characters because "\n" is interpreted as a single newline 
character by MLPutString() . This is likely not what you want as the 
Mathematica parser interprets actual newline characters within strings 
as space characters.

       (Compare ToExpression["\"a\nb\""] to ToExpression["\"a\\nb\""].)

     * "Mprep" can now generate #line directives so that compilers and 
debuggers can refer to the original source files. This feature is 
controlled by the -line and -noline command-line options. The default is 
-noline for the MacOS versions of "mprep" and -line for all other platforms.

     * The mprep-generated functions MLMainString() and MLMainArgv() are 
now correctly defined when MLPROTOTYPES == 0.

     * "Mprep" no longer generates very long string literals.

     * :ReturnType: String functions can now return 0 to indicate failure.

Windows

     * "Mprep" for Windows generates programs that use a custom icon in 
the task bar.

Macintosh

     * "Mprep" for Macintosh generates modern names for system calls.

     * "Mprep" for Macintosh generates apps with a bigger default heap.

     * The applications generated by the MacOS versions of "mprep" now 
display the correct copyright notice.

     * Recording "SAmprep" AppleScripts now results in correct scripts.

     * "SAmprep" had a bug that could cause it to crash if it was run 
twice without quitting. This was fixed.

Miscellaneous

All Platforms

     * Various edits were made to this document.

     * Some sample code in the section below entitled "The Biggest 
Compatibility Issue" had a bug that could prevent it from working. This 
was fixed.

Macintosh

     * The installation instructions for CodeWarrior users have changed.

     * The AppleScripts used to create project files were modified for 
the latest Metrowerks tools. The utility source file "mlmactty.c" was 
modified to be compatible with Apple's latest SIOW library.

     * The files "mlimport.rsrc" and "mlimport.c" used by classic 68K 
applications were modified to conform to the new semantics for 
MLNewParameters().

     * The file "mlimport.c" used by classic 68K applications works 
around a code generation bug in some versions of Metrowerks' C compiler.

     * The file "mlimport.c" used by classic 68K applications now use 
modern names for MacOS system calls.

     * The file "mlimport.c" used by classic 68K applications was fixed 
so that #define LAZY 1 now works.

     * Java programmers can now easily use MathLink.

Windows

     * MathLink once again supports 16-bit Windows programs.

     * MathLink programs linked with MathLink for Windows Version 3 can 
now interoperate with MathLink programs built with MathLink for Windows 
Version 2.2. (Only the Windows platform had this temporary gap in 
interoperability.)

     * MathLink can now work around a bug in Mathematica 2.2 that 
prevented compatibility with Windows 95 and Windows NT.

     * CodeWarrior support for Windows was added.

     * Microsoft Visual C++ V5.0 and V6.0 support for Windows was added.

     * Java programmers can now easily use MathLink.

Unix

     * There was a bug in Version 3.0.0 of the Unix kernels that caused 
it to unnecessarily sleep when using MathLink. This was fixed in Version 
3.0.1 kernels. This bug caused very poor MathLink performance.

     * Mathematica kernels Version 4.0 and later have several 
optimizations that make LinkRead significantly faster.

     * A resource leak in Version 3.0 of the kernel when it was reading 
from MathLink was fixed.

     * Several other bugs, resource leaks and performance problems were 
fixed.

     * MathLink now is available on the UltraSPARC platform.

Changes since Revision 1 (also known as Beta 4)

All Platforms

     * The value of MLREVISION in "mathlink.h" was changed from 1 to 5.

     * This document was renamed again.

     * Some floating point rounding problems were fixed.

     * The output of "mprep" was modified to suppress some compiler 
warnings and to more flexibly handle :ByteString: and :ByteSymbol: 
argument types.

     * Some example files were changed to be consistent with other 
platforms.

     * A bug was fixed that caused MathLink to hang in some circumstances.

     * Some internal limits on the parameters passed to MLOpenArgv were 
removed.

     * The functions MLNextCharacter and MLCharacterOffset were 
generalized to allow a NULL value for the end parameter.

     * A bug was fixed that was encountered when putting zero-length 
strings with the obsolete functions MLPutSize and MLPutData.

     * Another bug was fixed that was encountered when MLGetString was 
called when a function was next on the link.

Macintosh

     * Some exceptions caught by the QC programmer's debugging utility 
were fixed.

Changes since Beta 3

All Platforms

     * This document was renamed.

     * A discussion of the long double type was added to the Known 
Problems section.

     * "SAmprep" and "mprep" now properly handle :ArgumentTypes: 
{ByteString}.

     * The header file "mathlink.h" was cleaned up a little.

     * More functions have arguments declared using the const type 
qualifier.

     * The argument to MLInitialize() was made opaque.

     * MLPutIntegerList() and MLPutRealList() now work.

     * Calling MLGetString() when a function is next on the link now 
correctly fails with error MLEGSEQ.

     * Various other bugs were fixed.

     * Various edits were made to this document.

     * Some unsupported goodies were added.

All Platforms

     * All callback functions are now declared 'pascal'. See the Porting 
Version 2.2 MathLink Programs section.

     * The file "mlimport.c" used by classic-68k applications now does 
version checking.

Changes since Beta 2

All Platforms

     * The function pointers passed to the undocumented functions 
MLSetDialogFunction() and MLSetUserData() were changed to 
UniversalProcPtrs wrapping pascal functions. Moreover, the prototypes 
for the functions registered with MLSetDialogFunction() have changed. 
The "Old Definition" version number of the "MathLinkLibraries" file was 
not incremented for Beta 3, however, so that the Mathematica front end 
and kernel would still bind to this new library. Neither the front end 
nor the kernel call these MathLink functions and are thus unaffected by 
the change. If you call these functions in your MathLink program, your 
program cannot be simultaneously compatible with the Beta 3 and Beta 2 
or Beta 1 MathLink libraries. Be careful that your application is using 
the shared library that matches your use of these functions. When the 
next Mathematica Beta becomes available, the "Old Definition" version 
number of the "MathLinkLibraries" file will be changed so that 
applications linked with the Beta 1 or Beta 2 library will no longer 
bind with any newer MathLink shared library.

     * Minor edits were made to this document.

     * Minor edits were made to some typedef declarations in "mathlink.h".

Macintosh

     * The file "mlimport.c" now works for classic 68K projects that use 
two bytes to represent variable of type int.

     * Minor edits were made to the AppleScripts that create project 
documents.

     * Minor changes were made to the code generated by "mprep" and 
"SAmprep" to make projects that use precompiled headers build faster and 
to fix some incorrect declarations.



Do you have questions about this topic? Click here to ask our support 
staff Buy NowFree TrialMore Information


  © 2004 Wolfram Research, Inc. | [ja] |
Sign up for our newsletter:



Tamagochee wrote:
> Hello,
> 
> I am interested in porting a short program in C++ to Mathematica.
> 
> Main part of the program are various operations on bits such as shifting,
> etc. Program performs decryption of a string that is encoded with public
> key. Since I am not certain I am permitted to post the full source code
> here, please contact me to my e-mail.
> 
> Kind regards,
> Tamagochi
> 
>