[Discuss-gnuradio] MSVC porting

[Geof Nieboer]

All,

 

After doing some ‘proof of concept’ with the VOR receiver (the phase comparator still isn’t perfect, but bad weather has given me a marginal signal recently, so it’s on hold for a tad), I’ve been really impressed with gnuradio.  It’s only flaw it seems to me is that it’s difficult for joe average to install/use on their PC.  So here’s how I’d like to contribute:

 

1-       Tweak the C++ libraries so that they’ll compile under windows natively (MSVC++ 2005 specifically)

2-       Add ‘shims’ to allow access to the C++ classes through .NET managed code on windows

3-       Convert select python applications to C#

4-       Build a standalone install package (easy once 1/2/3 are done)

 

I believe I’ve got a concept that will extend the functionality to a native windows environment without complicating the linux build process.  On my dev machine, I’ve set up a gnuradio source tree (3.1.2), and added a directory ‘gnuradio.net’.  The .vsproj files etc go there, as well as any managed code (both Managed C++ and C# depending).  The .vsproj files link to the primary source code which remains in it’s original directory.  This way those that are uninterested in windows code (probably the majority) can ignore the ‘.net’ directory completely and be undisturbed.   Of course I’m adding some #ifdef _MSC_VER to some of the code, but so far it’s not bad at all IMHO.  Most annoying thing seems to be UNIX open() vs Win32 fopen() and fil_des integers vs FILE pointers.  Otherwise the fixes seem reasonably straightforward so far.  (Quick caveat, I’m not a native C++ developer (pardon the pun), so there may be better techniques than what I am using)

 

From what I’ve gathered, the makefile format is different between GCC and MSVC, so it seemed trying to keep the build method consistent between the two would probably cause more drama than what it’s worth, so I just stuck with the .vsproj method

 

I’ve already converted usrp, omnithread, and most of gnuradio-core (general, gengen, filter, runtime), so it certainly seems do-able.  The USRP code I was able to build completely and run some basic code, validating that I could talk to the USRP successfully via C# using the usrp_standard_rx class.

 

The reason I’m preferring C# to porting/reusing the Python is that most of the Python code I’ve looked at so far is pretty straightforward object-oriented high-level code, and porting it to C# (or VB.NET etc etc) will be pretty trivial, giving us 2 advantages, 1- the power of the .NET winforms interface, and 2- it’s easier to build a stand-alone binary install that doesn’t require any additional install work by the end user.

 

So, please let me know if this effort is something the community is interested in.  If so, I guess I need the copyright/permissions electronic form to start the formal part off? 

 

Geof

 

P.S.  Thanks to Andrew Rose for his posts to the wiki on this concept, it saved me a couple steps!