Suggestion/Note Regarding Flexlib Internal Sockets Code

Peter K1PGV

(This is really a note to the FlexLib devs... I apologize in advance for the length of the post)

I've been long anticipating a project that involves building a network attached device that does "band following" for a given slice, allowing automatic control of devices like amps and ATUs.

My plan for this project was to use Win10 IoT Core (this OS version will be free for any use) running on the Raspberry PI 2 (RPI2).  Because Win10 IoT Core supports C#, the development should be easy.  Use FlexLib, write a little C# code to interface to a 5 button switch (left, right, up, down, select) and a single line LCD display... and I'm in business.  This is precisely what FlexLib and Win10 IoT are supposed to be about, right?  Facilitating projects just like this.

Windows 10 IoT (in three different versions, with various levels of functionality) replaces Windows Embedded going forward.  There are some *very* cool things coming in this release, from AllJoyn support to support for easy, encrypted, connection to "the cloud" for advanced off-box processing (think voice recognition, heavy computation, cloud storage, etc).

Well, it turns out there's a fly in the ointment.  Win10 IoT Core (including Windows Phone and Windows RT) does not support the System.Net class. In its place, it supports the Windows.Networking class.  Bad job Microsoft, but I'm sure they have their reasons.  Windows.Networking still supports sockets, just in a bit of a different form.  There's no TCPClient or UDPClient class, for example.  Who cares, its JAMOC (Just A Matter Of Code).

And that brings me to the topic of my post.  I accept that I have to re-write the FlexLib networking code.  But, ****... the networking code is spread around multiple places in FlexLib.  IF the FlexLib devs had put all the network interfacing into a single custom class developed by them, and uniformly used this class instead of directly invoking things from the System.Net namespace throughout FlexLib, life would be a whole lot easier.  And, more importantly, this would allow me to write a replacement for that class -- and make that replacement available to the community. In that case, voila!  FlexLib would work on Win10 IoT, Windows Phone, and the like with just the inclusion of the substitute network class.

As it is, I'll have to create a parallel version of FlexLib with different networking code... which will then need to be updated with every new version of FlexLib that's released.

Given the very purpose of FlexLib is to interact on the network and parse commands, I understand why the FlexLib devs didn't think to encapsulate the System.Net namespace when they did their development.  I know I wouldn't have.  But,thinking about it NOW, it sure would be nice to isolate the message parsing and event processing work in FlexLib from the mechanism for transmitting and receiving messages... don't you think?

So, why am I writing this?  Given the potential upside, and the relative ease of slicing out the FlexLib networking code and encapsulating it in a separate class, I'm hoping the FlexLib devs at least consider doing this in a future release.

I accept that, for now, I have to get out the chainsaw and make a private version of the FlexLib code.  But, perhaps, some bright day in the future, the dev team might modularize things a bit more and allow for easier migration of the existing code base.

Walt - KZ1F

Yep, I had to do the same thing in my version of Flexlib, which, by the way, will run under Windows anything. My advice, scrap the proprietary code in favor of a portable SSDR.

Steve - KD8QWT

I too was thinking about trying Win10 on the pi 2 so I can use the Flex api.  So much for that.  It seems that there are a few people rolling their own classes for non-Windows platforms.  It's unfortunate that there isn't something that's more cross platform available.

Walt - KZ1F

Mine will very much be cross platform. Linux, Mac, Android, iPad, Raspberry Pi, even Windows, etc. The only 'issue' is there are things I can do on Android I can't do on Linux or Windows or Mac and there are neat things I can do on LInux, Mac, Windows that I can't do on Android, iPad, or Raspberry Pi. But, they will all share the same core  and, perhaps I'll have a single UI that will simply behave slightly differently on platforms supporting that specialized functionality.

I don't want to steal Peter's thunder here, it is, after all, his thread. I merely made the comment I agreed with his assessment and had to deal with it in the portable core.

Peter K1PGV

my version of Flexlib, which, by the way, will run under Windows anything

Just to verify: You know that your version of Flexlib will run on Windows IoT Core?

Peter
K1PGV

Walt - KZ1F

It will run on my Windows 7 laptop..so to answer the specific version of Windows, I have not tried it, nor will I, on Windows IoT Core. The strategy Microsoft has is their products require an absolute loyalty to Microsoft products, it's an incredibly homogenous working environment, much like Apple but the difference is Apple never got the adage "you never buy a dot zero release of a Microsoft product". A Mac environment will not run, or run well, on a Dell, it requires their hardware, software, devices etc. But by doing that it doesn't require them testing with every conceivable device for compatibility or outsourcing that to the device vendor which may or may not do a good job of compatibility testing. It costs more but it works.

Peter, you have a strong affinity for Microsoft, that's why they made chocolate because not everyone likes vanilla. I think your skill set would allow you to do an incredibly good job on an alternative control surface for the Flex. I was agreeing with you and suggested rather than a solution bound to Microsoft, perhaps you could appeal to more consumers with an equally good control surface. There are way too many people on here iching for a fight.

However, while I do not know and, frankly, do not care. There are multiple ISVs (Independent Software Vendors) that also write portable code and if Microsoft locked them out, there would be marketplace 'issues'.

Peter K1PGV

I only asked because you claimed that your version of Flexlib will run "under Windows anything."  So, not so much, I guess.

(Aside: Sigh... the Microsoft bashing *does* get tiring.)

was agreeing with you and suggested rather than a solution bound to Microsoft, perhaps you could appeal to more consumers with an equally good control surface. 

Yeah... I'm not interested in creating an alternative control surface, nor am I interested in appealing to more consumers.

Whatever code I write in my spare time (which is all the code related to amateur radio) I write to appeal to and to please only myself.  If I release such software to the community (as I've done occasionally in the past through my web site), I do it in the hopes that whatever I find useful somebody else in the community might also coincidentally find useful.  Nothing more, nothing less.

I write application code in C# on Windows because it's easy for me, and I find C# to immensely enjoyable. Programming on/for Linux holds less than no appeal to me as a spare time activity.

Peter
K1PGV

Walt - KZ1F

Pete, I don't know that it won't work... Do you? Actually the reverse of your last sentence applies to me. I deliberately left the uSoft centric world decades ago. Sorry, for some reason I thought you had a consulting company. Whatever.

N7AIG

everything new is old... take us back to 1980 and the seeds of CLOS

I highly recommend reading and understanding the writings of Sonya Keene.

Eric-KE5DTO

Peter,

Thanks for the input.  I was unaware of Microsoft's plans not to support the System.Net namespace on Win10 IoT Core.  I did some googling but couldn't find any discussion about this.  Can you provide any links?

Eric-KE5DTO

It is worthy of noting that the SmartSDR Ethernet API is accessible to any platform supporting TCP/UDP.  It is string based and easy to use/debug.  FlexLib (C# library used in SmartSDR-Win) is built on top of this API.

Peter K1PGV

Thanks for your consideration, Eric.

Comprehensive documentation for Win10 IoT isn't public yet (though there IS a public release of IoT Core... it's quite cute).  For IoT Core you need to write a "Windows Universal Application" and, like Windows Phone, this at least currently does NOT include the System.Net namespace.  This was a big issue for Windows Phone -- people were not amused that they were "politely requested" to move to the Windows.Networking namespace.

The docs are scheduled to be release in a couple of weeks.  In addition, I'll make some inquiries in the IoT Client team (the people who own the code) to see if I can get a definitive statement regarding this.  When I do, I'll post back here.

Peter
K1PGV

rfoust

Oh, ya know I did hear something about this not too long ago.  Not sure if I ever saw any official links or if it was in a facebook group.  If I come across anything, I'll post it here.

Walt - KZ1F

It has a reported release date of July 29. So Pete's question to me was a trick one. How could I test my app on a version of Windows that, publicly, doesn't exist yet. I assume I passed. I'm still not interested whether my app works on a windows watch or phone or whatever. Right now, it works on WIndows. Whether that will be true in Aug, don't know, don't care.

Peter K1PGV

It has a reported release date of July 29. So Pete's question to me was a trick one.

I'll call you "Walt" if that's OK with you, and if you don't mind I'd appreciate you calling me "Peter", not "Pete", thank you.  Much appreciated.

And, hardly a trick.  A pre-release of Windows 10 IoT Core has been publicly available since April 29th see here.  Before posting here, I made it a point to do my testing on the publicly available version (of both IoT Core *and* Visual Studio 2015, which is also currently in pre-release status).

I'm still not interested whether my app works on a windows watch or phone or whatever. Right now, it works on WIndows. Whether that will be true in Aug, don't know, don't care.

For someone who doesn't care, you sure post a lot about it.  Personally, I tend to ignore threads with topics I don't care about. But, you know, some people like vanilla and others like chocolate.

Peter
K1PGV

Walt - KZ1F

Actually Peter, I'd prefer you did refer to me as Walt, not that I suspect you are interested in developing a professional relationship. Apologies where referring to Pete grated on you, it was unintentional.

I believe it was you that posed a counter-point when I suggested people comfortable with a Windows solution likely wouldn't be swayed  by a non Windows specific application that happened to run on Windows. And I've never talked about running SSDR on a watch or tv or whatever else IoT is supposed to do. I believe we've covered my interest in a Microsoft world. I certainly don't begrudge you being 'into' the Microsoft mindspace. I used to be there myself, multiple trips to Redmond, multiple trips to Belllevue, Windows Internals, Windows Networking, Writing Windows Device Drivers etc. The last time was '98 I think, Seattle, 'Window Wizards' conference, during the internals rollout of XP as I recall. I've got more Microsoft University coffee mugs than Carter has pills.

But, as Jim Whitehurst of Redhat likes to point out that represents vendor lock in. And they, and I, don't believe in vendor lock in. But whatever pays your mortgage, ya know?  And we can dispense with the large quotie things. Merely highlighting the thing you want to quote and then hit the double down quotes symbol seems to work fine. While I  am sure you are an excellent developer, I doubt I will have have the occasion to or interest in using any of yours, equally I am sure you have neither the interest in nor occasion to use any of mine, so we can acknowledge that and go our separate ways. How does that sound? I believe my post was merely acknowledging you comment about the networking. It was not a challenge or anything other than a comment. If IoT supports Oracle Java, then I suspect mine will run fine there. If it doesn't that is between the 3rd party vendors and Microsoft. I have no dog in that hunt.

So you aren't left with the wrong idea Peter, I have, on multiple occasions, referred people to you when it looked like the root of their question hinged on how Windows does things or expects things.

Peter K1PGV

Just a note: I haven't forgotten about this.  In fact, I've been working the issue consistently.

I've been getting either no answer at all or conflicting answers as to whether UDPClient and TCPClient will be supported in Windows 10 IoT Core.

The answer I received today, which purports to be the definitive answer, is that YES... both UDPClient and TCPClient will be supported by for use in Windows Universal Platform (UWP) applications and that they will hence be supported on Windows 10 IoT Core.

There is still not any public documentation on this. I would therefore hesitate to make any decisions based on the information I've been given to date, especially given that if UDPClient and TCPClient *are* supported in UWP apps this will mean ADDING support to Phone and Windows Store Apps where it did not exist previously. This isn't impossible, and the addition of these classes would be welcomed by phone developers.

If FlexLib would work as supplied, this would be GREAT for Windows IoT Core... which will be free.  That would make building "little devices" that interact with or consume data from Flex radios very close to trivial.  Note that IoT Core is *not* restricted to headless displays... so having a device with a high res touch panel display is VERY possible with this free version of Windows.  The RPI2 is certainly capable enough to handle it.

Bottom line: I'll believe it when I see it.  And I've yet to see a build where I've been able to successfully use either of these classes.

Peter
K1PGV

Eric-KE5DTO

Thanks for the update.  Sounds like good news.