I just noticed this post; mycomments are interspersed below.
After reading the QST December article on DX Lab, I thought I'd give it a try. Well..... the website is bad, I mean really bad. I think I went around in circles for 20 minutes before I stumbled across the actual download link.
There's a Download
tab in the row of tabs running across the middle of the web page. More than 1500 users have been downloading and installing DXLab each month for the past several years; you are the first to report being unable to find the Download tab.
Next to the install... Ohhh my... it is apparent that DX Lab is written in Visual Basic V 6.0 or C++ 32bit which has been obsolete for a dozen years.
There is nothing remotely obsolete about VB 6.0; applications written in VB6 run on all versions of Microsoft Windows, including 8.1, and have access to all new OS capabilities via the Windows API. It's true that Microsoft no longer provides updates to VB6; as a result, it enjoys a level of stability unusual for a Microsoft product.
I should know since I have been re-writing VB6 code into Visual Studio code for the last dozen years.
My sincere condolences.
I'm not being a software snob here, there are some significant drawbacks to the old 32 bit code. It does not support threading. In a multi-task environment this can lead to slow and stalled applications.
Perhaps you can explain how DXLab manages to accept DX spots from up to 6 sources (including the high-speed Reverse Beacon Network) while decoding up to 50 separate PSK transmissions, using all of this incoming information to update a database of active DX stations and provide the user with up-to-date tabular, bandspread, world map, propagation, and "heat-map" views of this database -- all in real time with no "stalling" whatsoever. Checkout what users have to say
It does not directly support XML which has become the standard for modern software development.
DXLab has supported XML for years; for example, it uses XML when interacting with QRZ's "XML Data" callbook lookup service. XML is a straightforward representation for which a recursive parser can easily be written. I'd be happy to recommend an introductory text if you'd like to learn how to do this. You might employ this knowledge to automate some of your application "translation" work.
The biggest drawback is that old 32bit apps are not directly compatible with W7 or W8 OS. When VB6 was written, Windows OS had not yet evolved into a secure OS and there were no protected folders.
Neither Windows 7 nor Windows 8 is remotely secure, as the worldwide network of script kiddies demonstrates every day. And as any member of the Windows Vista development team will admit, "Protected Folders" were introduced to provide the illusion of security, and nothing more. Anyone with a basic understanding of operating system security should understand this.
This is the reason for the detailed instructions on how to get around security issues on the install pages.
Translation: by default, the DXLab Launcher installs itself and the rest of DXLab in C:\DXLab rather than C:\Program Files.
Many VB6 applications saved their environment variables directly into the registry. This is a big no-no now days.
DXLab has no "environment variables".
A re-write into Visual Studio VB or C# would add multithreading, direct integration to XML, and the ability to interface to SQL and Web Services directly.
As has already been pointed out, DXLab achieves significant parallelism, and employs XML. DXLab provides users with the optional ability to employ SQL in filtering one's Log or in filtering the database of active DX stations. DXLab includes a web server that provides remote access to the database of active DX stations. It provides full synchronization with LotW, eQSL.cc, and ClubLog by employing the web services they provide.
All these efforts would time, be well worth the effort.
Each of your alleged limitations has been refuted by citing capabilities long provided by DXLab. I have no need to keep developers entertained by allowing them to "port" DXLab to Microsoft's latest and greatest bugfest. When it's appropriate to move DXLab to another platform, I'll exploit its loosely-coupled modular architecture to do so in an incremental manner, continuing to support the DXLab user community with new functionality on a weekly basis and keeping the backlog of reported but uncorrected defects at zero, as I do today.
Dave, AA6YQ (author, DXLab)