Topics

Future platforms for DXLab

Dave AA6YQ
 

DXLab isn't a suite of native Windows applications because I don't like Linux or because I don't like OSX. It's because in the early 1990s, I was leading product development at Rational Software, and we'd just begun partnering with Microsoft to provide tools and a process for modern software engineering to companies starting to use Windows across their enterprises. Rational had initially developed an advanced programming environment for the Ada programming language that ran on an operating system and hardware of our own design; we'd just made the arduous transition to hosting this programming environment on Unix-based workstations (Sun, DEC, IBM) when the Microsoft opportunity became real.

With zero Windows experience, I was looking for a fast way up the learning curve. Having gotten my novice ticket in 1990, I'd been writing some small "DX assistants" in Modula for my trusty Amiga 1000. Microsoft was touting Visual Basic as the Windows programming tool of choice, so I began developing a "DXer's Accomplice" using their recommended programming environment. The transition from that monolithic "DXer's Accomplice" to the DXLab Suite is described in this CQ article from 2002:

<http://www.dxlabsuite.com/Presentations/Creating%20the%20DXLab%20Suite%202002-08-05.pdf>

My focus since the beginning has been on providing powerful functionality in support of DXing. So long as there has been more of that to do, I've deferred all consideration of moving DXLab to another platform that could run natively on Linux and OSX. Those would be "sideways moves" -- consuming weeks if not months, but yielding no increase in DXing functionality.

As anyone can see in

<https://www.dxlabsuite.com/download.htm#AvailableReleases>

the various enhancement lists are still full of useful new functionality to implement. However, the list of "large" projects is beginning to dwindle:

1. the Override Database, which yields new versions of DXView, DXKeeper, and SpotCollector, will soon be ready for testing (if there aren't too many more crashes without backed-up Workspaces!)

2. the low-cost Spectrum-Waterfall display - using a low-cost SDR like the RSP-2

3. the "DX Calendar" - extracting information from <https://www.ng3k.com/misc/adxo.htm> and other sources, and displaying it with "need" depicted with font color

At one time, I'd planned to focus energy on significantly improving MMTTY's RTTY decoder, but the availability of the 2Tone and GRITTY engines with WinWarbler has largely mitigated that need.

I'm expecting that interoperation between DXLab, WSJT-X and JT-Alert will continue to improve. There have been an increasing number of suggestions to extend WinWarbler to directly interoperate with WSJT-X, but I hope that won't be necessary.

So I've begun spending more "background cycles" on thinking about a "next platform".

A relatively easy step would be to port DXLab from Visual Basic version 6 (VB6) to the current Microsoft program environment, lovingly referred to as "dot net". The N1MM team made this transition a few years ago; Tom N1MM, Larry K8UT, and Rick N2AMG are all friends, and would undoubtedly share their "lessons learned. This would enable DXLab to benefit from the improvements Microsoft has been making to improve performance, reliability and usability; on the other hand, there'd be times when defects introduced in "dot net" ripple through to DXLab applications. The transition to "dot net" could be made one DXLab app at a time, minimizing risk and disruption.

At the other extreme, I could develop a simple low-cost box with a couple of serial ports, USB ports, and an RJ45 connector that would make all of your radios and antenna rotators accessible via the internet, and then move DXLab to the cloud, replacing the current user interfaces with web-based interfaces; Pathfinder and SpotCollector already provide such interfaces:

<http://www.dxlabsuite.com/pathfinder/WebClient/>

<http://www.dxlabsuite.com/spotcollector/WebAccess.jpg>

While this approach would provide significant advantages, it would also require overcoming several substantial challenges. Like security. Like "no DXing when the internet is down?". Like "how does DXLab interoperate with PC-hosted apps?" Like "how do we pay for hosting DXLab in the cloud?".

Those are likely the two extremes of a range of possibilities. Nothing is imminent, and nothing is likely to become imminent in the next year, but I am beginning to think more seriously about this topic. Critique, comments and suggestions are welcome.

73,

Dave, AA6YQ

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Stan Gammons
Sent: Tuesday, October 09, 2018 7:28 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Data-deletion bug forces Microsoft to suspend rollout of Windows 10 update

I don't see that happening. Been down that road already. I have played some with a fairly current development version WINE and was able to get DXLab to "mostly" work that way on Kubuntu 18.04 The show stopper is the WINE DDE support is lacking and none of the DXLab apps are able to communicate with one another. i.e., if you see a spot in SpotCollector and double click it; nothing happens. So, the only real option in my opinion is if you want to use Linux, and I still do, and run DXLab; a windows VM is the way to do it. On the Linux side, CQRLog is very good, but it's not DXLab. Nothing else is really. It's the best IMO. I know I've said it many times before, but thanks Dave for DXLab.

73

Stan
KM4HQE



On 10/08/2018 10:05 PM, Norman Heyen wrote:


All you have to do is convince Dave to rewrite DXLabs for a variety of Linux. And then convince the rest of us to learn that version of Linux.

But I agree, this really shouldn't have happened. I expect some 'revisions' to how future updates are handled. The current method isn't very popular in the corporate world.

Norman
KC9NVN

Peter Laws
 

On Tue, Oct 9, 2018 at 10:08 PM Dave AA6YQ <@AA6YQ> wrote:

With zero Windows experience, I was looking for a fast way up the learning curve. Having gotten my novice ticket in 1990, I'd been writing some small "DX assistants" in Modula for my trusty Amiga 1000. Microsoft was touting Visual Basic as the Windows programming tool of choice, so I began developing a "DXer's Accomplice" using their recommended programming environment.

Hey, Dave. Glad to hear you are moving the entire Suite to AmigaDOS!
Commodore rules! I'm running Workbench 1.3 - Is this going to be a
problem or should I look at getting new ROMs for my A2000HD? Also, I
have about 10 MB free on my 40 MB SCSI disk. Will this be enough or
should I look at a new disk?

--
Peter Laws | N5UWY | plaws plaws net | Travel by Train!

Stan Gammons
 

Hi Dave,

Thanks for the lengthy email.  We have talked off list several times about platforms and have agreed to disagree on platforms of choice. I hope my recent comments didn't cause you to write this email. 

I know you spoke of a web based version before and maybe that's what MS sees as the future. While I can see where it would be cross platform, so is Java but it's been so riddled with security holes that isn't even funny, I can't say as I'd like a web based version of DXLab.  While I haven't messed with computers as quite as long as you have, only 35 years or so for me; I don't trust the cloud. That's my opinion though.

I'm sure this is going to be a long thread...

Thanks for all you have done for us DXers.


73

Stan
KM4HQE


On 10/09/2018 10:08 PM, Dave AA6YQ wrote:
DXLab isn't a suite of native Windows applications because I don't like Linux or because I don't like OSX. It's because in the early 1990s, I was leading product development at Rational Software, and we'd just begun partnering with Microsoft to provide tools and a process for modern software engineering to companies starting to use Windows across their enterprises. Rational had initially developed an advanced programming environment for the Ada programming language that ran on an operating system and hardware of our own design; we'd just made the arduous transition to hosting this programming environment on Unix-based workstations (Sun, DEC, IBM) when the Microsoft opportunity became real. 

With zero Windows experience, I was looking for a fast way up the learning curve. Having gotten my novice ticket in 1990, I'd been writing some small "DX assistants" in Modula for my trusty Amiga 1000. Microsoft was touting Visual Basic as the Windows programming tool of choice, so I began developing a "DXer's Accomplice" using their recommended programming environment. The transition from that monolithic "DXer's Accomplice" to the DXLab Suite is described in this CQ article from 2002:

<http://www.dxlabsuite.com/Presentations/Creating%20the%20DXLab%20Suite%202002-08-05.pdf>

My focus since the beginning has been on providing powerful functionality in support of DXing. So long as there has been more of that to do, I've deferred all consideration of moving DXLab to another platform that could run natively on Linux and OSX. Those would be "sideways moves" -- consuming  weeks if not months, but yielding no increase in DXing functionality.

As anyone can see in

<https://www.dxlabsuite.com/download.htm#AvailableReleases>

the various enhancement lists are still full of useful new functionality to implement. However, the list of "large" projects is beginning to dwindle:

1. the Override Database, which yields new versions of DXView, DXKeeper, and SpotCollector, will soon be ready for testing (if there aren't too many more crashes without backed-up Workspaces!)

2. the low-cost Spectrum-Waterfall display - using a low-cost SDR like the RSP-2

3. the "DX Calendar" -  extracting information from <https://www.ng3k.com/misc/adxo.htm> and other sources, and displaying it with "need" depicted with font color 

At one time, I'd planned to focus energy on significantly improving MMTTY's RTTY decoder, but the availability of the 2Tone and GRITTY engines with WinWarbler has largely mitigated that need.

I'm expecting that interoperation between DXLab, WSJT-X and JT-Alert will continue to improve. There have been an increasing number of suggestions to extend WinWarbler to directly interoperate with WSJT-X, but I hope that won't be necessary.

So I've begun spending more "background cycles" on thinking about a "next platform".

A relatively easy step would be to port DXLab from Visual Basic version 6 (VB6) to the current Microsoft program environment, lovingly referred to as "dot net". The N1MM team made this transition a few years ago; Tom N1MM, Larry K8UT, and Rick N2AMG are all friends, and would undoubtedly share their "lessons learned. This would enable DXLab to benefit from the improvements Microsoft has been making to improve performance, reliability and usability; on the other hand, there'd be times when defects introduced in "dot net" ripple through to DXLab applications. The transition  to "dot net" could be made one DXLab app at a time, minimizing risk and disruption.

At the other extreme, I could develop a simple low-cost box with a couple of serial ports, USB ports, and an RJ45 connector that would make all of your radios and antenna rotators accessible via the internet, and then move DXLab to the cloud, replacing the current user interfaces with web-based interfaces; Pathfinder and SpotCollector already provide such interfaces:

<http://www.dxlabsuite.com/pathfinder/WebClient/>

<http://www.dxlabsuite.com/spotcollector/WebAccess.jpg>

While this approach would provide significant advantages, it would also require overcoming several substantial challenges. Like security. Like "no DXing when the internet is down?". Like "how does DXLab interoperate with PC-hosted apps?" Like "how do we pay for hosting DXLab in the cloud?".

Those are likely the two extremes of a range of possibilities. Nothing is imminent, and nothing is likely to become imminent in the next year, but I am beginning to think more seriously about this topic. Critique, comments and suggestions are welcome.

         73,

               Dave, AA6YQ






-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Stan Gammons
Sent: Tuesday, October 09, 2018 7:28 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Data-deletion bug forces Microsoft to suspend rollout of Windows 10 update

I don't see that happening. Been down that road already. I have played some with a fairly current development version WINE and was able to get DXLab to "mostly" work that way on Kubuntu 18.04  The show stopper is the WINE DDE support is lacking and none of the DXLab apps are able to communicate with one another. i.e., if you see a spot in SpotCollector and double click it; nothing happens. So, the only real option in my opinion is if you want to use Linux, and I still do, and run DXLab; a windows VM is the way to do it. On the Linux side, CQRLog is very good, but it's not DXLab. Nothing else is really. It's the best IMO.  I know I've said it many times before, but thanks Dave for DXLab.

73

Stan
KM4HQE



On 10/08/2018 10:05 PM, Norman Heyen wrote:


	All you have to do is convince Dave to rewrite DXLabs for a variety of Linux. And then convince the rest of us to learn that version of Linux. 

	But I agree, this really shouldn't have happened. I expect some 'revisions' to how future updates are handled. The current method isn't very popular in the corporate world. 

	Norman
	KC9NVN





neil_zampella
 

FWIW ... my wife cut her teeth on Rational's ADA machines, was a 'beltway bandit' teaching ADA to this AF MSgt which is how we met.    One of her tasks was to convert an old Fortran-based AF system to ADA using the Rational compiler for Unix on the old MAC based WWMCCS workstation of the early 90s (which died a merciful death).

As far as moving to another platform.    Laurie's been moving JT-Alert to 'Dot NET' in hopes of making it cross-platform, but its slow going.

Its not a bad idea to move to .NET, however it would definitely keep XP users from the suite in the future.


Neil, KN3ILZ


On 10/9/2018 11:08 PM, Dave AA6YQ wrote:
DXLab isn't a suite of native Windows applications because I don't like Linux or because I don't like OSX. It's because in the early 1990s, I was leading product development at Rational Software, and we'd just begun partnering with Microsoft to provide tools and a process for modern software engineering to companies starting to use Windows across their enterprises. Rational had initially developed an advanced programming environment for the Ada programming language that ran on an operating system and hardware of our own design; we'd just made the arduous transition to hosting this programming environment on Unix-based workstations (Sun, DEC, IBM) when the Microsoft opportunity became real.


---
This email has been checked for viruses by AVG.
https://www.avg.com

Dave AA6YQ
 

+ AA6YQ comments below

With zero Windows experience, I was looking for a fast way up the learning curve. Having gotten my novice ticket in 1990, I'd been writing some small "DX assistants" in Modula for my trusty Amiga 1000. Microsoft was touting Visual Basic as the Windows programming tool of choice, so I began developing a "DXer's Accomplice" using their recommended programming environment.
Hey, Dave. Glad to hear you are moving the entire Suite to AmigaDOS!
Commodore rules! I'm running Workbench 1.3 - Is this going to be a problem or should I look at getting new ROMs for my A2000HD? Also, I have about 10 MB free on my 40 MB SCSI disk. Will this be enough or should I look at a new disk?

+ I'll code it in 68K assembler, so no worries.

73,

Dave, AA6YQ

Dave AA6YQ
 

+ AA6YQ comments below

Thanks for the lengthy email. We have talked off list several times about platforms and have agreed to disagree on platforms of choice. I hope my recent comments didn't cause you to write this email.

+ They did, but that's not a problem. In past years, I'd have explained why it makes no sense to consider support for additional platforms at that time. Now, I'm interested in the ideas that arise from such a discussion.


I know you spoke of a web based version before and maybe that's what MS sees as the future. While I can see where it would be cross platform, so is Java but it's been so riddled with security holes that isn't even funny, I can't say as I'd like a web based version of DXLab. While I haven't messed with computers as quite as long as you have, only 35 years or so for me; I don't trust the cloud. That's my opinion though.

+ The security issue is certainly "make or break". How about we use LoTW Callsign Certificates for authentication?

+ There may come a time when there's enough redundancy in high-speed access to the internet that "loss of internet" is about as frequent as "loss of AC power", with your smartphone getting you through internet outages in the same way that a generator can keep you DXing through a power outage.

73,

Dave, AA6YQ

Stan Gammons
 

Hi Dave,

On 10/09/2018 10:39 PM, Dave AA6YQ wrote:
+ AA6YQ comments below

Thanks for the lengthy email.  We have talked off list several times about platforms and have agreed to disagree on platforms of choice. I hope my recent comments didn't cause you to write this email.  

+ They did, but that's not a problem.  In past years, I'd have explained why it makes no sense to consider support for additional platforms at that time. Now, I'm interested in the ideas that arise from such a discussion.

LOL!  That was NOT my intention at all and I think you know that.   I was trying to say forget about asking you to re-write DXLab to make it cross platform.  Just run DXLab in a windows VM using VirtualBox and be happy.   Having said that, if you are considering going the .net route; I "think" there is a way to make .net apps run on Linux. 


+ The security issue is certainly "make or break". How about we use LoTW Callsign Certificates for authentication?

Um, that might work.  But, a web based app causes more problems than just security.  If it's web based, who is going to host it and who is going to foot the bill for it?   More things to consider.


+ There may come a time when there's enough redundancy in high-speed access to the internet that "loss of internet" is about as frequent as "loss of AC power", with your smartphone getting you through internet outages in the same way that a generator can keep you DXing through a power outage.

Maybe.  Some times the loss of internet is a good thing :)


73

Stan
KM4HQE

Dave AA6YQ
 

+ AA6YQ comments below

On Tue, Oct 9, 2018 at 09:05 PM, Stan Gammons wrote:

Having said that, if you are considering going the .net route; I "think" there is a way to make .net apps run on Linux. 

Transitioning to .net would mean replacing all of the DDE links with UDP or TCP, so even WINE might work at that point.

        73,

                  Dave, AA6YQ

Stan Gammons
 

On 10/09/2018 11:11 PM, Dave AA6YQ wrote:

+ AA6YQ comments below

On Tue, Oct 9, 2018 at 09:05 PM, Stan Gammons wrote:

Having said that, if you are considering going the .net route; I "think" there is a way to make .net apps run on Linux. 

Transitioning to .net would mean replacing all of the DDE links with UDP or TCP, so even WINE might work at that point.


While I have not tried it, I believe a VirtualBox VM can communicate TCP with apps on the host platform.  How difficult would it be to change the DDE links to TCP/UDP with the existing code base or make such communications (DDE, TCP or UDP) an option?   Changing to TCP/UDP would also make DXLab a bit more operable with other windows apps that use TCP/UDP. 

Time for input on the topic from others...


73

Stan
KM4HQE







Salvatore Besso
 

Dave,

you know what my opinion is, I already spoke of it with you in the past:

Programs (I hate to call them "apps"):

Embarcadero Delphi (Object Pascal). With its latest version (Delphi Tokyo 10.2.3) you build and maintain only one source and compile for several platforms:

Windows (x86 and x64)
Linux (only x64 for now)
OSX

Not to mention IOS and Android, but I suppose that they are out of scope here. Who could want to run the suite on a telephone?

I can even beat the dust from my rusty Delphi Object Pascal and help in the transition somehow (and for the translation into my language, of course).

Database:

Firebird, zero maintenance fast SQL client-server database. Stop.

I could have added MySQL, but I won't. Access? No, thanks.

DOT NET??? No, thank you! You don't need it with Object Pascal, even if you could use it. Delphi, with third party components, has all you need without the overload of the net framework and the source is less complicated.

Web-based interfaces? Cloud? Naaaaaaaaaah.

This would enable DXLab to benefit from the improvements Microsoft
has been making to improve performance, reliability and usability;
like the operating system's update that wipes users' files? ;-)

73 de
Salvatore (I4FYV)

Dave AA6YQ
 

+ AA6YQ comments below

While I have not tried it, I believe a VirtualBox VM can communicate TCP with apps on the host platform. How difficult would it be to change the DDE links to TCP/UDP with the existing code base or make such communications (DDE, TCP or UDP) an option?

+ Straightforward. It would be completing a process that has already begun.

Changing to TCP/UDP would also make DXLab a bit more operable with other windows apps that use TCP/UDP.

+ DXKeeper has long accept logging directive via TCP as well as via DDE.

+ Commander accepts directives via TCP as well as via DDE; WSJT-X uses this.

+ Commander can also issue status updates using UDP messages defined by N1MM.

73,

Dave, AA6YQ

Dave AA6YQ
 

+ AA6YQ comments below


you know what my opinion is, I already spoke of it with you in the past:

Programs (I hate to call them "apps"):

Embarcadero Delphi (Object Pascal). With its latest version (Delphi Tokyo 10.2.3) you build and maintain only one source and compile
for several platforms:

Windows (x86 and x64)
Linux (only x64 for now)
OSX

+ For those who do not recognize the name, Embarcadero is the successor to Borland. I use Embarcadero's C++ development environment
when maintaining MMTTY.

+ I'm concerned about Embarcadero's longevity; I would have a serious conversation with them before committing DXLab to their
platform.

73,

Dave, AA6YQ

Jeff AC0C
 

Wow, Turbo Pascal.  Now that brings back memories.

Dave, hope you won't go full-cloud with a local option.  A lot of us countryside dwellers already have bandwidth and connectivity problems.

73/jeff/ac0c
alpha-charlie-zero-charlie
www.ac0c.com

On 10-Oct-18 12:43 AM, Dave AA6YQ wrote:
+ AA6YQ comments below


you know what my opinion is, I already spoke of it with you in the past:

Programs (I hate to call them "apps"):

Embarcadero Delphi (Object Pascal). With its latest version (Delphi Tokyo 10.2.3) you build and maintain only one source and compile
for several platforms:

Windows (x86 and x64)
Linux (only x64 for now)
OSX

+ For those who do not recognize the name, Embarcadero is the successor to Borland. I use Embarcadero's C++ development environment
when maintaining MMTTY.

+ I'm concerned about Embarcadero's longevity; I would have a serious conversation with them before committing DXLab to their
platform.

73,

Dave, AA6YQ



Dave AA6YQ
 

+ AA6YQ comments below

Wow, Turbo Pascal. Now that brings back memories.

Dave, hope you won't go full-cloud with a local option. A lot of us countryside dwellers already have bandwidth and connectivity problems.

+ I should have included "internet coverage" in the list of challenges associated with the cloud-hosted alternative; thanks.

+ Note that the two alternatives described were the extremes of a range of possible solutions.

73,

Dave, AA6YQ

Salvatore Besso
 

Dave,

I'm concerned about Embarcadero's longevity
all announces seem to go in the opposite direction. After all I'll see one or two updates per year always with new additions (the latest has been the Linux x64 compiler), and that's not so bad.

Is it possible to know what the representative told you in that conversation?

I use Embarcadero's C++ development environment
which version?

By the way, the first Turbo Pascal that I've ever used has been TP 2.0 but under CP/M. Only a few years ago... sigh!

73 de
Salvatore (I4FYV)

Salvatore Besso
 

Dave,

sorry, in the hurry I misinterpreted your message. You "would" have a conversation, but you still haven't.

So, what would you ask them in this conversation?

73 de
Salvatore (I4FYV)

Jeff Otterson
 

Hi Dave,

How about building on .Net on Mono?  Mono has runtimes for Windows, Linux, and OSX.  https://www.mono-project.com/ -- you could get the lift to .Net and also cross-platform support.

I expect that would be a non-trivial exercise.

Jeff n1kdo

Joe Subich, W4TV
 

On 2018-10-09 11:08 PM, Dave AA6YQ wrote:
While this approach would provide significant advantages, it would also require overcoming several substantial challenges. Like security. Like "no DXing when the internet is down?". Like "how does
DXLab interoperate with PC-hosted apps?" Like "how do we pay for hosting DXLab in the cloud?".
For many of us in outer suburban/rural areas a cloud based solution
is a non starter due to internet bandwidth (and availability) issues.
Add to that the incremental cost of cloud hosting/access for those
who are already retired/on fixed incomes, I strongly urge you to forget
about cloud migration as the primary platform for any "new" DXLab Suite.

*IF* a major change in development platform is necessary (as I suspect
it will be due to Microsoft's slow move away from VB), I would strongly
support a move to a multi-OS platform but remaining based on the local
hardware (potentially with club based *storage* for those who desire
it) with multi-user (e.g. ability to run from multiple computers -
desk/laptop/tablet simultaneously) capabilities.

73,

... Joe, W4TV

Roy Jackson
 

I strongly concur with this if a change becomes imminent. 73
-- 
Roy Jackson KW4G
Sebring, FL. USA

On Wed, 2018-10-10 at 08:48 -0400, Joe Subich, W4TV wrote:
On 2018-10-09 11:08 PM,  Dave AA6YQ wrote:
While this approach would provide significant advantages, it would 
also require overcoming several substantial challenges. Like 
security.  Like "no DXing when the internet is down?". Like "how does
DXLab interoperate with PC-hosted apps?" Like "how do we pay for 
hosting DXLab in the cloud?".
For many of us in outer suburban/rural areas a cloud based solution
is a non starter due to internet bandwidth (and availability) issues.
Add to that the incremental cost of cloud hosting/access for those
who are already retired/on fixed incomes, I strongly urge you to forget
about cloud migration as the primary platform for any "new" DXLab Suite.

*IF* a major change in development platform is necessary (as I suspect
it will be due to Microsoft's slow move away from VB), I would strongly
support a move to a multi-OS platform but remaining based on the local
hardware (potentially with club based *storage* for those who desire
it) with multi-user (e.g. ability to run from multiple computers -
desk/laptop/tablet simultaneously) capabilities.

73,

    ... Joe, W4TV





Charles Gallo
 

<snip>
Having said that, if you are considering going the .net route; I
"think"
there is a way to make .net apps run on Linux. 
Transitioning to .net would mean replacing all of the DDE links with UDP
or TCP, so even WINE might work at that point.
Yes, there is a way to get .NET to easily run Linux - it is called .NET
Core, and is what Microsoft is pushing, heavily! That said, it really is
meant to use web pages (read ASP, or actually it's own build in web server
called Kestrel)

A .net core app will run native on Windows OR Linux, and is open source
for those who care (Yes, the runtime, and the compilers are open source)

It also makes for another interesting option - docker containers. So far,
I've implemented 3-4 apps that have been containerized! One real beauty
of this is if you do it right (and it can be more than one container if
you want), the container is put up on something like docker hub. Anyone
running docker itself (which, gasp, is usually Unix inside) which runs on
Win10 or Server2016 can download the container, spin it up, and it just
runs - it is a lightweight VM (it doesn't do hardware virtualization)

Of course, there are LOTS of languages that can be used to develop the
code in the container.
(Remember, Azure is almost all Linux)