Re: Future platforms for DXLab

Norman Heyen

I too throw my hat into the ring of having the application and database local. Various reasons but I can do backups to the cloud (although having a 'button' to do that in DXLabs Suite would be appreciated).

The idea of a complete settings backup where it would be a matter of loading the app on a new computer, then just restoring the settings backup would be great. I have to update the shack PC soon. And like all MS apps, I dread doing this because of the hassles and uncertainty of getting everything back to like it was.

Having DXLabs platform independent would be nice but I'm probably going to be a Windows user for a long time.

Just my two cents worth (probably inflated), your support and work is greatly appreciated.

Thanks for letting us share and vent,

On October 11, 2018 at 12:17 PM Dave AA6YQ <aa6yq@...> wrote:

  • more AA6YQ comments below

+ As part of the transition to a "next platform", it would make sense to start by updating the existing DXLab applications to employ the "settings management mechanism" that will be employed in that "next platform".

And there is the crux of the problem, and one I'll maintain has no good, long-term, answer. During the DOS days, no one could have envisioned the Windows ecostructure as it is today. However, as we've all learned one does not bet against Microsoft. It may take them 3 or more versions to get something "right", but eventually they do turn out good, solid software. Whether any of us agrees with their direction makes no difference. Microsoft has its own reasons for doing things and they are only somewhat affected by the marketplace.

I think the important thing to remember is that no matter what decision is made, over time it will turn out to be "wrong". Remember when client-server was the thing? Now look at the directions of the industry, and client-server is rarely even mentioned.

My advice would be to look at when you think you need to start development for the next-gen DXLab and make your best decision then and push ahead with all deliberate speed. Just don't change horses, either in development environment or goals, in mid-stream. I was once involved in a project that did both on multiple occasions during the time between conception and delivery, a period of nearly 4 years. It ended very badly. Thankfully I was long gone and therefore well outside the blast radius.
  • Good advice.

  • To Microsoft's credit, they did not disable the Registry-based settings storage mechanism that was not just recommended, but built into the language runtimes. Thus I was never forced to divert developer cycles away from DXLab's primary objective in order to annually reposition the furniture to be consistent with that year's security posturing.

  • I still have high-level contacts at Microsoft, and will seek their views of where things are headed before making final decisions. Even though DXLab is small potatoes for Microsoft, they intrinsically hate the prospect of losing *anything*, and if made aware will exert themselves to prevent it.


Dave, AA6YQ

Join to automatically receive all group messages.