I'd like to be able to compile a C/C++ library so that it runs within a safe managed runtime in the Silverlight CLR.
There are several tools for doing this with the JVM that allows C++ code to run within a CRT emulation layer (see NestedVM, LLJVM, etc), which effectively allows C++ code to be run within a Java Applet. There's even a tool for this for the Adobe Flash VM (see Alchemy).
However, I can't seem to find any tools like this for the CLR. fyi, the MSVC tools don't seem to allow for this: The /clr:pure flag will create C++ code that runs in the CLR, but it isn't safe (because the CRT isn't safe) and /clr:safe requires massive code changes (no native types, etc).
Then I think you are plain out of luck. If your code can't use the /clr:safe flag then it won't be compilable into something that can run in Silverlight. If the C++ is doing something that the CLR does not allow or support, then there is no way around this directly.
Depending what your code does, you could possibly execute it on the server and call that from Silverlight via a web service?
What you're looking for is not inherently possible. The problem is that native C++ types allow direct access to pointers. With pointer access, you can circumvent the .NET security model and compromise the execution environment. It's not just because the CRT is unsafe, it's because pointers are unsafe.
What the original poster wants to do sounds fine to me... but perhaps not possible.
I take it you basically want to be able to run your C++ code in silverlight, without porting it to /clr:safe
A fine and noble pursuit. i'd like to do the same. But as far as I can tell you can't do it :(
The closest method I've seen mentions perhaps targetting the mono clr... and then using that in the clr? That's your nested CRT.
I don't particularly care about if the code runs natively, or not. What I don't want to do is port a muli-million line C/C++ code base to /clr:safe, just so it can run in silverlight.
I think that's what the OP wants :)
I wish him luck :(
Related
One of our products is a C++ application - using MFC (MDI). (And we skin the application with Codejock.)
I've been asked if we could "port the application to .NET" - so it would be possible to use, e.g., C# libraries and other .NET features. I know there is something called "C++.NET" - or maybe (if I understand it right) it should be called "managed C++" now. But I don't know much about it.
My question: Is this at all possible? Could we run an MFC-application as "managed C++"? (And can an application using Codejock be run as a "managed C++" application?) There is some other threads about this, but I haven't been able to find "a definitive answer"...
I'd be very grateful for some good advice! :-)
As far as I understand, you want to keep your MFC/Codejock GUI and allow the use of .NET libraries from you application's C++ code.
This is indeed possible, but for a complete application that is currently compiled as "native" C++ it is probably not such a good idea to convert all of it to being compiled with C++/CLI. "It Just Works (IJW)" is a nice meme, but it doesn't work always :-)
We have the same situation, namely a C++/MFC/Codejock application that needs to call into .NET assemblies. This works mostly without problems:
We have C++/CLI modules that offer a native C++ DLL interface for the native C++ code to call into and that then route these call on to an assembly written in C#.
We also have C++/CLI assemblies that offer a .NET interface for the C# code and then call back into pure native modules.
It should also be possible to have a single (say, exe) project that is compiled natively and you only enable the /clr switch for selected cpp files that need managed interop. And at the end you link everything together. Since we've never mixed it that way, I can't really say anything about this approach however. What I can say for sure though is that it is possible to compile parts on a module as /clr and parts as native.
I faced a similar problem some years ago, and found that unless for trivial cases converting from un-managed to managed or reverse side was really painfull. I ended leaving the two worlds each in its side, and simply use interop to have the COM - .NET compatibility.
It was not very nice, but a lot cheaper. The conclusion that we should wait a major evolution to consider a full rewriting.
Can I have managed code within native code?
There are quite a few ways to do this.
You can code in C++/CLI, the managed C++ compiler provided by Microsoft. You can mix managed and native code as you wish (security restrictions may apply).
You can go the COM route, and it's natively supported on the .NET side. Harder to program on the native side though, especially all the interop. You can start here: http://msdn.microsoft.com/en-us/magazine/cc163494.aspx.
The 3rd way is to "host" the .net runtime engine directly into your app and use it to load managed assemblies and then execute parts from them. This may be overkill for you, but it generates a 100% native image and doesn't rely on COM interop. You can start here: http://msdn.microsoft.com/en-us/library/dd380850.aspx.
I'm just starting my first C++ project. I'm using Visual Studio 2008. It's a single-form Windows application that accesses a couple of databases and initiates a WebSphere MQ transaction. I basically understand the differences among ATL, MFC, Win32 (I'm a little hazy on that one actually) and CLR, but I'm at a loss as to how I should choose.
Is one or more of these just there for backward-compatibility?
Is CLR a bad idea?
Any suggestions appreciated.
Edit:
I've chosen C++ for this project for reasons I didn't go into in the post, which are not entirely technical. So, assuming C++ is the only/best option, which should I choose?
It depends on your needs.
Using the CLR will provide you with the most expressive set of libraries (the entire .NET framework), at the cost of restricting your executable to requiring the .NET framework to be installed at runtime, as well as limiting you to the Windows platform (however, all 4 listed technologies are windows only, so the platform limitation is probably the least troublesome).
However, CLR requires you to use the C++/CLI extensions to the C++ language, so you'll, in essense, need to learn some extra language features in order to use this. Doing so gives you many "extras," such as access to the .net libraries, full garbage collection, etc.
ATL & MFC are somewhat trickier to decide between. I'd refer you to MSDN's page for choosing in order to decide between them. The nice thing about ATL/MFC is that you don't need the .NET framework, only the VC/MFC runtimes to be installed for deployment.
Using Win32 directly provides the smallest executables, with the fewest dependencies, but is more work to write. You have the least amount of helper libraries, so you're writing more of the code.
Win32 is the raw, bare-metal way of doing it. It's tedious, difficult to use, and has a lot of small details you need to remember otherwise things will fail in relatively mysterious ways.
MFC builds upon Win32 to provide you an object-oriented way of building your application. It's not a replacement for Win32, but rather an enhancement - it does a lot of the hard work for you.
System.Windows.Forms (which is what I assume you meant by CLR) is completely different but has large similarities to MFC from its basic structure. It's by far the easiest to use but requires the .NET framework, which may or may not be a hindrance in your case.
My recommendation: If you need to avoid .NET, then use MFC, otherwise use .NET (in fact, in that case, I'd use C# as it's much easier to work with).
As far as C++ goes, I would use WTL. It's lightweght and you will have few (if any) dependencies, making it easy to ship and install. I find it very satisfying when my app consists of a single EXE that will run on most versions of Windows, but this may not be a concern to you.
If you choose to go .NET instead, then C# is almost certainly the way to go.
More in WTL here:
http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx
I would be very curious as to why you would do this in C++ at all. Based on your brief description, C# sounds like a much more appropriate choice.
Just to elaborate a bit, look at the link you gave describing the C++ CLR. The top rated answer notes (accurately, in my opinion) that C++ is appropriate for "kernel, games, high-performance and server apps" - none of which seems to describe what you're doing.
MFC, ATL, etc are going to be supported in the sense that, yes you'll be able to compile your app on future versions of Visual Studio and run them on future versions of Windows. But they're not supported in the sense that there's not a lot of new development going on in the API or the language the same way there is in the CLR and C#.
There is nothing wrong with CLR. Like others here I'd suggest C# but as you have reasons for sticking with C++ then using the .NET framework is several thousand times easier than messing with ATL/MFC if you're not already familiar with them (IMO).
It may be worth mentioning that if you're using C++/CLR then you're not really using C++ at all. C++/CLR compiles to CIL just like C#. I've never used it myself but I believe its purpose is to allow you to compile legacy code and make it easily available to new .NET code rather than allow new code work with old C++ executables. There are other methods of calling native code from .NET which, perhaps, you should explore.
The modern (2021) answer to this question would appear to be to use C++/WinRT instead of C++/CLR (or C++/CLI or C++/CX... jeez Microsoft):
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt
C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler.
...
C++/WinRT is Microsoft's recommended replacement for the C++/CX language projection
It's basically standard C++ but the UI is defined with XAML.
Still though, as with the other answers, it would appear that using C# is really microsoft's favorite approach. C++/WinRT really looks like it's almost C# anyways.
I have an application written in Delphi that compiles in Delphi 2007. I think it was originally written in Delphi 7.
Anyway, I need to convert all the core non-GUI code into C++ because I want to release a Mac version of the software.
What is the best way to do this? Any shortcuts I can take to speed up the process?
EDIT: The code compiles to native code, not .NET.
Simple answer: You simply can't port non-trivial Delphi code to C++ without a complete rewrite. C++'s object model is very different from Delphi's. It doesn't have a base class like TObject from which all other objects are derived, and it lacks support for a lot of the RTTI stuff that Delphi code often takes for granted. And there's no simple way to reimplement Delphi RTTI in C++, since a lot of it's done at the compiler level, and a lot of it's based on the fact that all Delphi classes descend from TObject.
C++ also lacks support for the concept of unit initialization and finalization sections that are so common in Delphi, and what it has instead is badly broken. (Look up the "static order initialization fiasco" for all the gory details.)
Delphi's exception handling is also much more advanced than C++'s. Part of this is the object model and part of it's compiler magic. Plus, C++ has no support for the try-finally construct.
If you want to port a Delphi project to the Mac, Free Pascal is your best solution. It's not 100% compatible with Delphi, but it's good enough for a lot of things, and you specifically mentioned that you don't need to port the Delphi GUI stuff. AFAIK the GUI area is the source of most of FPC's compatibility weaknesses, so if that's not necessary, FPC is probably pretty close to ideal for your needs, at least until CodeGear gets an OSX compiler out. (Which hasn't been officially announced, but based on various things that have been said it's not unreasonable to suppose that one will be available sometime next year.)
For converting your code from Delphi to Cpp, have a look at
http://ivan.vecerina.com/code/delphi2cpp/.
I used this to convert some of the classes and functions in SysUtils, DateUtils and StrUtils using wxWidgets functions. If you are planning to use wxWidgets for C++ have a look at http://twinforms.com/products/wxwidgets/wxvcl.php which has all the converted source.
If you want directly develop Mac OSX applications using then have a look at wxForms for Delphi - http://twinforms.com/products/wxformsdelphi/index.php
I think this would be difficult to do mechanically, so you are probably looking at a complete re-write. One thing to bear in mind is that typically Delphi uses try...finally structures for resource management, whereas C++ uses a technique known as RAII (resource acquisition is initialisation). You should read up on this and other C++ idioms before you attempt the conversion.
If your code compiles in Delphi 2007 into .NET assemblies, you may have a much easier option than trying to port from Delphi's object pascal to C++.
You could potentially compile your logic into .NET assemblies (and maybe even portions of the UI), and use Mono to run it on Mac. You could write a custom GUI around Mono, or even potentially make a single, platform independent application.
You can use also Delphi Prism. It's for .NET, but it's the last expression in Delphi language spec. It supports also Mac OSX (see the link). Also the guys from CodeGear/EMBT are in the works for a new compiler as well as for a new version of Delphi which is expected to enter in beta in April and narrow the gap between Prism and RAD studio. See their 'Beta Programs' page.
The "correct" way to do this is to rewrite it in Objective C. I find Objective C a little weird, but there are a lot of similarities with Delphi in the way objects connect and delegate.
You may be able to use Free Pascal to do it more quickly, but you should seriously consider a rewrite.
I would be in love with Embarcadero if they could release a Mac OS X version of Delphi that didn't, you know, suck like Kylix did. One can dream.
Edit: There is a great benefit to staying in Delphi, and having a separate version for the Mac in Objective C. First, it means you don't need to rewrite the version on Windows, losing the (presumably) years of investment in Delphi code. Second, Mac software operates differently than Windows, from a UI perspective. A simple port of the product is inappropriate, and hobbles the developer from using the great native features of Windows and Mac. See: older versions of MS Word for Mac, or iTunes for Windows. They look and feel wrong.
Microsoft appears to be moving a lot of configuration and query capabilities to PowerShell (accessible from C# or managed C++), while deprecating and even removing older APIs (accessible for C or unmanaged C++). Those of us who have extensive unmanaged C++ programs that can't switch to managed C++ may have a need to call PowerShell cmdlets (at least, I have one now) -- how can we do so?
There are suggestions that a reverse-PInvoke (managed/unmanaged thunking) might be able to do something, but I'm hoping for a better way than either thunking or parsing text output from a PowerShell script.
[Note: This is a reworked and generalized query I made yesterday that may have been too specialized.]
The MS suggestion would probably be to compile specific classes/modules in your generally unmanaged C++ app as managed code (compiling individual files with /clr), and letting the IJW transition code manage the calls to/from it (and calling PowerShell API's from the managed bits). I've been told (from MS VC++ people) that's the expected methodology for adding bits of managed calls to large unmanaged applications.
Hope that helps.