Neil,

.NET wrappers are totally acceptable. In fact, .NET does some of them for
you. There are three  ways of interoperating with native code. They use the
term native rather than win32 because you can also call 64 bit code and
potentially any other code (linux) on the platform you are running.  There
are performance issues in each of these mechanisms and Microsoft is
changing them as we speak.

The simplest is called PInvoke. It allows .NET code to call an entry point
in a .DLL This is essentially what VB programmers have been doing for years
and conceptually similar to what we do in MapBasic calling a DLL. Using a
.NET concept called attributes, you can control a few things better such as
calling conventions and how data is converted or "marshalled" from .NET to
the native DLL.  The .NET framework uses this facility itself to call
Windows APIs.  The calling is one way (.NET to DLL)

COM objects can be called from .NET by the building of wrappers. The RCWs
(Runtime Callable Wrappers) are built automatically by Visual Studio when
you tell it that you want to use a COM object. The dialog in Visual Studio
where you select the objects that you want to reference has a TAB for .NET
assemblies as well as COM objects. The wrapper handles the calling of the
COM objects and marshalling of data.  MapInfo distributed a wrapper like
this for those who wanted to get started on .NET work over year ago. The
wrapper handled the older MapX/MapXtreme.

Connected with that technology is the ability to call a .NET Code from COM.
These wrappers are called CCW (COM Callable Wrappers).

Check out MSDN for some good papers or
http://www.codeproject.com/dotnet/COM_DOTNET_INTEROP.asp.

The third technology is the C++ compiler. The .NET version C++ compiler
supports what is called Unmanaged (native) and managed (MSIL) code
generation. You can build totally MSIL code in C++ if you wish. The
interoperability to native code is built into the compiler with a few rules
that you have to follow. It is so easy to do that they called the
technology IJW (It just works!). Well, we found a few problems with that
technology. However, it is improving and some of the things they are doing
in the next version are pretty amazing if they work. We are looking at that
now. Note from my earlier memo that just because code is MSIL and compiled
to native code by the run time (Just in time) compiler, does not mean that
the code is "safe".

MapInfo uses this C++ technology to interoperate between it's public
interface code (MSIL) and the native code.

Hope this helps.

Eric Blasenheim
Software Architect
MapInfo Corporation




Mail List:
       [EMAIL PROTECTED]
                                                                           
 From:      on 09/14/2004 09:47 PM CST                                     
                                                                           
 To:       SCISOFT <[EMAIL PROTECTED]>, "'MapInfo-L'"                
           <[EMAIL PROTECTED]>                             
                                                                           
 cc:                                                                       
                                                                           
 Subject:  RE: MI-L MapBasic vs VisualStudio .NET ... MapXtreme 2004       
                                                                           



Up the learning curve... without cramps?  I have a follow-on question.
From
our software engineers I have been told that there may be some sort of
intermediate step that essentially puts a .NET-wrapper around WIN32 code
permitting such legacy code to be used in the NET environments?  Is this a
safe and reliable "first move" for legacy code or is this more like buying
re-treaded tires?  They look great on the rack, have a low cost, but tend
to
fly apart under stress and fast speeds.

MidNight Mapper
Aka neil

-----Original Message-----
From: SCISOFT [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 15, 2004 1:26 PM
To: 'MapInfo-L'
Subject: RE: MI-L MapBasic vs VisualStudio .NET ... MapXtreme 2004

It's gratifying to see some accurate info about .NET being presented by
Eric
Blasenheim, and I'm sure his comments about MapInfo's conversion to the
platform / framework will be well received.

Something that has been discussed (well, more along the lines of conjecture
really) is how the MapBasic language and the MBX package will fit into the
.NET versions of MapInfo Professional and MapXtreme 2004.

Personally, I find .NET amazingly rich and powerful compared with Win32
programming, and (while I appreciate that MI will continue to use existing
"Win32" components) it's my guess and hope that the "new" geometry language
for MapInfo products will be light years ahead in its ease of use, compared
with the arcane MB.

I guess it's the transition from the weirdness of MB to the facility of the
"new" geometry language that worries people.

Ian Thomas
GeoSciSoft - Perth, Australia


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, 15 September 2004 11:00 AM
> To: Ian Tidy
> Cc: MapInfo-L; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: MI-L MapBasic vs VisualStudio .NET ... MapXtreme 2004
>
> Interesting thread. Let me try and squash a few misconceptions.
>
(BIG SNIP)
>
> Keep the information coming.
>
> Eric Blasenheim
> Software Architect
> MapInfo Corporation

(EVEN BIGGER SNIP)



---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 13333

---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 13334






---------------------------------------------------------------------
List hosting provided by Directions Magazine | www.directionsmag.com |
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Message number: 13340

Reply via email to