>Integrating the basic runtimes and mappable data types sounds better than the need for Ironpython and Jython sources to be changed for each new Python version. Having Node.Js accessible sounds also better than Rhino and Nashorn and always having to check what is supported. You were able to host Java runtimes as well (probably still possible), but going through JNI was/is a PITA


What I meant is that there's a pretty standard way to host .NET in other Windows applications or you can just use direct COM interop (with many limitations but it works).

It's always been surprising to me that other platforms didn't take advantage of the COM hosting features that Windows essentially provided to integrate with other tools - the APIs have always been public but Microsoft seems to be the only company that was using it. Interop is always a benefit to the vendors IMHO who get uptake, so it's baffling that this wasn't taken advantage of more (especially back in the day when desktop still really mattered).

+++ Rick ---

>
>regards
>
>thomas
>>Another good reason to look at .NET possibly more so than other languages is that you can at least interop with it from FoxPro. You can create a library in .NET and then call that from FoxPro either via COM Interop or via wwDotnetBridge to give you a big chunk of functionality that would otherwise not be available in FoxPro.
>>
>>And for your Visual FreePro - you can also host .NET directly in your own application - which is pretty much what I do with wwDotnetBridge, so you can extend it that way as well.
>>
>>+++ Rick ---
>>
>>>I've looked at C# and .NET over the years, and have tried various things and had a general idea of how it worked, etc.
>>>
>>>I've had an occasion recently to learn more about it and I have to say I'm very impressed with how well integrated it is.
>>>
>>>For my Visual FreePro, Jr. database engine, I've had to create an external DllImport and use some marshaled unmanaged pointers for obtaining information back from the remote VJr DLL. It's been very straight-forward to integrate and is working well.
>>>
>>>

[DllImport("vjrdbf.dll")]
>>>public static extern UInt32 dbf_get_field_type_extended(Int32 handle, UInt32 fieldNumber, [MarshalAs(UnmanagedType.LPStr)] ref string dest, UInt32 destLength);
>>>

>>>
>>>It's really been quite nice. If any of you have been putting off learning C#, I would suggest you give it a try. It's very robust, and if you have any C/C++ knowledge, it's very straight-forward.