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 > >