I haven't been able to find a solution answer on this for the past 2 days:
Can C# Mono, or a supported third party framework, be used to create and manage layer 2 tunnel over a virtual interface across the 3 major platforms (OSX, Windows, Linux)?
At a high-level an application like Hamachi or Tunngle would be a real world example for what I'd like to achieve at a basic level.
The intention behind this question is whether it would be possible to write effective cross-platform code or whether I would have to resort to platform-specific code to implement the virtual interfaces.
That depends. Since L2TP is actually accomplished using UDP datagrams, there's no reason why you can't implement it in C#. However, integrating it with the operating system (as a virtual interface driver etc.) is more or less impossible - I'd expect the only real way would be to have a small native wrapper that calls the managed code that does most of the work.
In other words - you can write Hamachi in .NET just fine. Writing the Hamachi Network Adapter is the tricky part. Also, if you just want to add L2TP capabilities to your applications, there's no problem (instead of TcpClient/UdpClient etc., you'd just use your own class that communicates with your L2TP class). However, integrating it to the IP infrastructure does require you to write a driver, which is usually a native-only territory.
It might be that there are some ready-to-use solutions that have the virtual network adapter which can call DLLs, but I'm not aware of any. A very unsafe way would also be to create hooks on Socket calls, but I'm not going to elaborate since that's extremely tricky and a bad idea overall :D
In other words, you have the option to use a hybrid approach - have the minimal native drivers for all the platforms you want to support, and let them call your managed library to do all the real work - the managed library can then be platform independent (as long as Mono is supported there :)).
Now, each OS probably has its own VPN client, which you could concievably use from .NET. However, that also means that your application will have to be able to support each of these OSes and their different VPN clients separately - and that will be tricky.
If you want to go the way of writing your own network interface driver, a good way to start on Windows is the Driver Development Kit, which has some sample source code for NIC drivers. Windows uses NDI (http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification), which has some support even on *nix family of OSes, so it might be possible to do this relatively easily - but don't forget, you're still writing a driver. Unless you have significant experience with C/C++/ASM and OS kernels and driver models, you're probably out of your league here. This is the stuff that leads to BSODs :)
There's also some related technologies like TDI (Transport Driver Interface) or WFP (Windows Filtering Platform) which could be used to do all this in user-space, rather than kernel/driver-space. However, those are Windows technologies. You'll have to find the equivalents on the other OSes you want to support, and you'll have to do some magic to make it all work in one cross-platform application. And while doing all this, you want to maintain performance - which requires very careful programming in .NET (it's easy to write reliable code in .NET, but it's harder to get cutting-edge performance. C/C++/ASM is quite the opposite - it's relatively easy to do things fast, but reliability suffers).
Related
I am going to write Windows application (for commercial use) which will send/receive and trace CANopen messages.
The problem is I don't know what devices will be used by users of this app.
Currently I have one requirement to support only USB-CAN devices.
However there is many vendors of such devices and everyone has other api/library/dll to use theirs devices.
(By the way, the problem is because I have to use Windows.
As I know on Linux is SocketCAN and everything is more standardized :-()
I don't know which library should I use. Could you recomend me something.
Of course this library should support as many vendors (and drivers) as possible.
Second requirement is this library shall compile to IL or somehow I can use this library in my C# application.
I have done small research:
The most popular is CAN Festival but it is abandoned project, however there is a few forks.
There is CANopen for .NET
But support only PEAK devices and state is prealpha
CANopen for Python
Support more devices but state is also alpha and I don't know if I can use this library in my c# application. Maybe when I use IronPython.
I also found this library: http://www.emtas.de/en/allgemein/csharpapi. It is commercial, but If support many devices I can buy It. Anyone has used it before??
We are using and have licensed the Swedish datalink.se CANopen library and it works very well for us. But honestly we are only using the CAN interface driver layer on Windows, for accessing a range of devices like Lawicel, Kvaser, IXXAT a.s.o. I haven't looked at the CANopen parts so much.
I looked at other CANopen SW stacks, too, back then, but like you I wasn't happy about CAN Festival. So what we do in our Kickdrive software is that we implemented just the amount of CANopen that we really need. See my answer in the post How to program a simple CANopen layer.
Depending on what are your actual requirements, this might be good enough already, or even the best approach.
I want to make my C# program in parallel on two host over lan, I know I should use the mpi language, but really I don't know which packet should I install that can connect to another computer, and run a C# program parallel, I just want to run it on two computer,my Os is window7,32 bit operating system,and I am programming with vs2010.
You should install something like MPI.NET - it provides .NET class wrappers around the MPI API and allows easy use from C#. Be aware though that the C# API is not part of the MPI standard and therefore might (and probably will) differ between different vendors. Unfortunately MPI.NET has been dead for years, probably due to lack of interest in using MPI with C# on behalf of the .NET developers community.
Another option would be to utilise P/Invoke to call the MPI functions from the MS-MPI DLLs directly. This won't work very well due to the differences in the memory models of MPI (especially when it comes to non-blocking operations) and .NET.
I need to make a desktop app which is pretty complex and handles a particular
domain. The domain has entities at the back end. I want the UI of this desktop app to be portable
to different frameworks such as Java(Eclipse RCP Plugin) and .NET(Visual Studio Plugin). So
1.)can I write the domain layer using C++ and interface with Java using JNI for Java
2.)use same C++ layer as point 1.) for interfacing with .NET (C++/CLI) as plugin for VStudio
What are the architectural considerations, pitfalls, future issues one will face if one
relies on a portable C++ layer interfaced with higher level APIs like Java and C# for a rich
client desktop application
For example one of the issue I will face is that I cannot debug and step into Native code from Java.
Are there many such items?
Should I just rewrite my domain layer using .NET and Java for each type of environment rather than keeping it portable as C++ layer?
Why isn't such an approach adopted by the industry?
What are the practical issues one faces when one has a JNI layer in between the View and Domain Layer?
Interfacing with domain models in another language / on another platform is really painful and my main architectural advice would be to avoid going there.
If you want a portable desktop app, I think you are better off writing it end-to-end in Java (or perhaps another JVM language like Scala or Clojure if you are one of the people who thinks that Java itself is a bit old-fashioned).
Rationale:
You'll only need to write the GUI layer once as Java will give you access to all the environments you need. You can run Java desktop apps pretty much everywhere that has a JVM, without recompiling. You just need to take a little care to avoid hard-coding platform specific features (e.g obvious stuff like don't assume "\" as a file separator, you need to use the portable File/pathSeparator instead).
This avoids the complexities of having to do a lot of cross-language interfacing. This is inherently a hard problem, since the languages have different object format and method calling semantics.
Java has a great open source library ecosystem with respect to portable code.
You can make pretty decent portable UIs in Java for most purposes (using Swing or SWT), and this is probably better in the long run than developing a custom UI layer for each target platform.
If you are smart, you can architect the app so that the GUI interacts with the back end domain objects through a clean and simple API. If you do this, then it will be easier to add new GUI options in the future (for example a web-based front end).
Writing the app end-to-end in .Net is also clearly feasible and might even be a bit easier on the GUI side given how good Microsoft's GUI-building tools are, but has the big disadvantage that you're now effectively locked into Windows, so your portability and platform flexibility goes out of the window. In addition (though this will depend on your domain) I think the Java ecosystem has the overall edge in terms of library ecosystem and tool support (with things like Maven).
When you want a cross language data model, a common pattern is to use a DSL to describe the domain model and generate the code from that. e.g. proto buffers. That way you can have native C++, Java, C# etc code for a common domain model.
One of the pitfalls of using a C++ library from Java is it doesn't feel like a Java library. You have to do all sorts of unnatural things to use it and you end up adding a layer to make it more Java friendly. I imagine its the same for C#
For example one of the issue I will face is that I cannot debug and step into Native code from Java. Are there many such items?
Netbeans supports Java + Native code debugging and you can step into native code from Java and debug both.
Should I just rewrite my domain layer using .NET and Java for each type of environment rather than keeping it portable as C++ layer?
I would have said yes, but that is me. For you it could make sense to leave in C++. There are pluses and minuses both ways.
Why isn't such an approach adopted by the industry?
Developing in Java and C# (and other virtual machine languages) is often seen as more productive and easier to find people who can support it.
What are the practical issues one faces when one has a JNI layer in between the View and Domain Layer?
You have to mirror the domain model, as you cannot just import it. i.e. all the data model you expose needs to be translated. This requires creating Java versions of the exposed model and well as translation code. (Another good reason to have all of it generated)
I will be developing some applications using mobile barcode scanners and need to choose between C++ and C# for coding on the scanners.
I am considering Intermec's CK31 or similar for the combination of wifi, scanning choices, programmability and user interface options. It runs Windows CE .NET 4.2 according to their spec sheet.
Intermec's Developer Library comes with .Net and C++ SDKs. My previous Win CE 2003 experience is in C++ (MFC GUI, sockets and serial comms). I'm comfortable in C# with WPF and can learn other GUI frameworks if I have to. That gives me freedom to choose a language - any recommendations one way or another?
I am NOT looking for answers advocating C++ over C# as languages in general - my productivity in either is similar and I have enough experience to be able to create complex, robust C++ solutions.
What I would appreciate are war stories or factors to put into our platform evaluation, about programming on these devices. eg: battery life of C# apps vs C++ apps, memory consumption or other environmental impacts of the language choice. If there are specific versions of .Net CE to avoid, that would be a good tip.
I've been designing and developing software for Windows Mobile and Windows CE in C, C++ and C# for quite a few years now. Moreover, I been doing so for Honeywell (formerly Hand Held Products, purchased by Honeywell in 2007) where I've worked on nearly all aspects of the devices, from drivers and services to Line of Business GUIs and utilities.
First of all, I won't tell you one language is better than the other... I probably spend a 50/50 split of my time with each, and each platform definitely has their own place in the mobile development.
I will however, give a suggestion that you likely stay away from any device that runs an OS as old as WinCE 4.2, especially if you are even considering .NET development. The reasoning for this is that 4.2 only has, at most, .NET CF 1.0 embedded in ROM (part of the OS ROM image), meaning that you would require a ~5MB CAB file to install at least .NET CF 2.0 Yes, you could develop with CF 1.0 but, truly, it's not worth the pain of using such an old framework. Most WinCE 5.0 devices these days come with CF (Compact Framework) 2.0 installed in the ROM so I would at least look for that.
On that same vain, you may even want to consider using a device with Windows Mobile 6.0 or 6.1 as they are easy to program with and will always have CF 2.0 pre-installed. In case you're wondering why I have not mentioned CF 3.0 or CF 3.5, it's just because the first Mobile platform to be release with those versions will be Windows Mobile 6.5, which is not out yet. Though you can always install the framework if you want (~8MB CAB).
Granted, WinCE definitely gives you a more "Windows" look and feel to its GUI over its Windows Mobile cousin, so that is all a matter of your programming preference and what your end users want and need.
Regarding kgiannakakis's comments on SDKs being only a thing layer, this is just not true. If you have a proper SDK you should have all of the same access to any devices or drivers that you would in C++ but with the ease of C#. For example, Honeywell provides an extensive SDK for all of our devices in C++, VB and C# and the C# portion of the SDK actually has more functionality than the C++ portion. You will never have to do a P/Invoke with our code from C#.
If you want to take a look at the SDK I'm talking about, it's freely available to download here and has some great examples.
IMHO I would actually consider the provided SDK as more important than the hardware in many cases since, most of the time, the hardware for the devices is pretty much the same. They all have ARM CPUs, WiFi, Bluetooth, Laser or Image based scanners, etc.
Though, I looked at the Intermec link you posted and it doesn't look like that unit actually has a built in scanner...are you using an external scanner hooked to the device?
Take a look at the Honeywell offering if you want here. We've got devices with probably the best imager based bar code scanner in the business, built into all of our units. And we have a rock solid SDK (I should know, I wrote a lot of it). And the SDK provides .NET extremely access to all of the hardware on the device. Ok...I'll stop my sales pitch now.
As for one language over the other...it really all depends on what exactly you want to do.
Drivers and services cannot be written in anything but Native (Win32) C or C++. So .NET is out for anything like that.
C and C++ can absolutely be your friend on mobile devices in terms of keeping things lightweight, since you don't need the whole .NET framework to run the add. Remember, you have a maximum of 32MB of memory for any process (not including DLLs..that's another lecture) so if your application is going to be processing a ton of data, C++ may be the way to go.
One of the major disadvantages I've found to C and C++ on mobile systems, however, is that making a GUI is way harder than it is with .NET Actually, most of the C++ apps I write are completely headless and have no GUI at all... .NET CF does not have WPF (yet), and is stuck with WinForms, but it's really easy to pick up. Pretty much drag and drop in the designer. And also remember, like I mentioned before, that WinCE has a completely different GUI paradigm than Windows Mobile. However, sometimes the Windows Mobile way is kind of nice, since it forces you to keep your GUIs simple and to the point.
Memory consumption can be higher when using .NET, but not always. For one, having a device with the version of the CF you are going to use stored in ROM will mean that you will generally have no more memory used on a .NET application vs the equivalent C++ app. In some cases, .NET will even use less memory. For example, a .NET app vs a C++ app that uses MFC can often use less memory because the C++ app has to load up the MFC framework (since it isn't already loaded by the OS...).
Also, since C# is managed, you will often end up with less memory usage because the garbage collector is freeing up memory that you may have forgotten to do in a C++ app.
Execution speed on more modern devices is generally no different between the two. Granted, you will always have little parts of each language where one will be faster than the other, but .NET is mature enough at this point that the speed is not really a concern. I have programmed extremely fast applications with highly interactive, animated GUIs that ran just fine on a device with 128MB RAM and a 420MHz ARM CPU. I even wrote one app that I had to slow down because it was calling into a native DLL via P/Invoke and the .NET portion was essentially getting "Impatient."
I have never seen any issues with battery life in one language vs the other. But I've never specifically tested for it either.
I really think that, in the end, it still comes down to the SDK that comes with your device of choice. If it has poor .NET support then you will find your self doing a lot of extra work getting everything to work, in which case I would go with C++. But if it has great .NET support (like the one I work on) you will find yourself with a lot less work and probably get the job done significantly faster.
Also, remember that it's not just the SDK of the hardware vendor you have to take into account. While you need that specific SDK as each device is different (i.e. the SDK I linked to earlier will not work on that Intermec device) all of the non-hardware related OS stuff is pretty much standard across the board, which is where the Windows Mobile or Windows CE SDK from Microsoft comes in. Their C++ support is pretty good, but they are really pushing all things .NET these days, so as updates are made to the OS, less updates are made to the C++ SDK and much more functionality now relies on using .NET Not that you couldn't do it in C++, it's just that they haven't done a lot of the work for you that they did do in the .NET SDK.
Ok...that was long, but I was trying to dump the finer parts of my years of experience into one thing. I hope it made sense.
The answer to your question has to do with the type of your application. If your application is mainly around communicating with the hardware and only a thin layer of business logic and User Interface is needed, then C++ would be a better choice. To interact with the scanners you need to talk to a driver. This is better and faster achieved with C++. The .NET SDK will actually be a wrapper of C++ code using a ton of P/Invoke, which makes the code performing less faster.
If on the other side your application requires a significant business layer and/or a User Interface, then .NET (and specifically C#) is a better option. In that case the productivity gains far out weight the performance gains of C++.
Another important factor is the type of the devices the application is going to be deployed to. Are you targeting Windows Mobile devices only? Then .NET is a safe option. For Windows CE devices you need to investigate whether the compact framework is pre-installed or not. Also, some Windows CE devices may not support all .NET namespaces.
Finally, I recommend reading Mobile Architecture Pocket Guide, which is a recent document about architectural decisions for mobile applications.
First I'll strongly echo Adam's recommendation against running anything based on CE .NET 4.2 at this point for essentially the same reason. At this point it's an ancient version of the OS and unless you are getting the terminal for free it's not worth it and if you choose to do C# development the download of the CAB to run .NET 2 is just painful.
We've developed a lot of applications for both Motorola(Symbol) and Intermec devices. The current set of APIs for both of them work reliably so I'd worry more about the suitability of the device than the specific APIs. They also both provide reasonable sample programs that make it easy to cut and paste a solution.
I have noticed one other big difference between Motorola and Intermec. On the Intermec devices I've worked with (in C#), it takes about a second for the decoder for each symbology to be loaded. This typically isn't a big deal if you use a limited number of symbologies and setup the scanner at the start of the application, but can cause significant delays if you change the decoders(symbologies) within the application.
I've been developing for about 15 years. Approx 5 years in C++ and 3 years in C# (which currently is my language of choice). In C++ I always used stdlib, and sometimes boost.
I have cut my development time with a third since I switched from c++ to c#. That was done because of a couple of things (nothing scientific, just my opinons):
.Net is a more complete framework and easier to use than stdlib and boost combined.
C# has a better structure which make easier to read others code and to code.
Unit testing in .Net is light years from unit testing in C++, especially with Resharper and xUnit (xUnit got clean syntax, resharper let's you test specific test methods directly inside dev studio).
I mostly code servers, GUI programming should be even faster.
Before I jump headlong into C#...
I've always felt that C, or maybe C++, was best for developing drivers on Windows. I'm not keen on the idea of developing a driver on a .NET machine.
But .NET seems to be the way MS is heading for applications development, and so I'm now wondering:
Are people are using C# to develop drivers?
Do you have to do a lot of API hooks, or does C# have the facilities to interface with the kernel without a lot of hackery?
Can anyone speak to the reliability and safety of running a C# program closer to Ring 0 than would normally be the case?
I want my devices to be usable in C#, and if driver dev in C# is mature that's obviously the way to go, but I don't want to spend a lot of effort there if it's not recommended.
What are some good resources to get started, say, developing a simple virtual serial port driver?
-Adam
You can not make kernel-mode device drivers in C# as the runtime can't be safely loaded into ring0 and operate as expected.
Additionally, C# doesn't create binaries suitable for loading as device drivers, particularly regarding entry points that drivers need to expose. The dependency on the runtime to jump in and analyze and JIT the binary during loading prohibits the direct access the driver subsystem needs to load the binary.
There is work underway, however, to lift some device drivers into user mode, you can see an interview here with Peter Wieland of the UDMF (User Mode Driver Framework) team.
User-mode drivers would be much more suited for managed work, but you'll have to google a bit to find out if C# and .NET will be directly supported. All I know is that kernel level drivers are not doable in only C#.
You can, however, probably make a C/C++ driver, and a C# service (or similar) and have the driver talk to the managed code, if you absolutely have to write a lot of code in C#.
This shall help you in a way: Windows Driver Kit
It's not direct answer to your question but if you're interested you might look at Singularity project.
Can anyone speak to the reliability and safety of running a C# program closer to Ring 0 than would normally be the case?
C# runs in the .NET Virtual Machine, you can't move it any closer to Ring 0 than the VM is, and the VM runs in userspace.
If you're willing to have a go at a proprietary framework, Jungo's WinDriver toolkit supports user-mode driver development (even in managed code) for USB, PCI, and PCI-E devices.
Microsoft has a number of research projects in the area of having a managed-code OS, in other words kill with Win32 API.
See Mary Jo Foley's article: Rebuilding a Legacy
Writing device drivers in .net makes no sense for current versions of windows.
<speculation>
Rumors are that MS is investing a lot of money in bringing Singularity to the next level. Just look for Midori. But that's 2015+
</speculation>
If I remember it correctly, the Dokan Project is a user-mode file system driver, which also allows .NET code to be executed by a system driver: https://github.com/dokan-dev/dokan-dotnet.
So, you could develop a C# "driver" (user-mode application really), which is then called/invoked by a C++ kernel-mode driver. The kernel-driver could simply pass everything along without manipulating the data and act as a simple wrapper.
Needless to mention, that it is very unsafe and you would most likely end with a BSOD (I tried it).
Mildly related:
The Cosmos Project is an open-source Operating system, which is developed in C# and runs
"(kernel) drivers" and user-level applications written completely in C#/F#/VB.NET/...
Though these are technically kernel-level drivers, the OS is no longer Windows but your own, so I guess that this is not a correct answer ......