Your reputation is not enhanced by sniping at what others are contributing to the hobby.

What you should be asking yourself is WHY does Dave have to be so repetitive in his constant advertising in the forums? If DxLabs is so superior why does Dave not like my approach of "Try all the Loggers - figure out what works for you". This is a sensible approach of finding a good logger.

Dave, you and other DxLabers find my approach offensive. Why??

My reputation is not the topic here and I could care less what you or anyone else thinks about K9IUQ. I tell truths and nothing will change that.

Your reputation is not enhanced by sniping at what others are contributing to the hobby.

What you should be asking yourself is WHY does Dave have to be so repetitive in his constant advertising in the forums? If DxLabs is so superior why does Dave not like my approach of "Try all the Loggers - figure out what works for you". This is a sensible approach of finding a good logger.

Dave, you and other DxLabers find my approach offensive. Why??

My reputation is not the topic here and I could care less what you or anyone else thinks about K9IUQ. I tell truths and nothing will change that.

Stan K9IUQ

Stan, You are punching at a straw man here. Nobody has argued against competitive evaluation of logging software.

I used the word reputation because that's the word you used in connection with Dave. Read my first posting in this topic. 73,Chuck NI0C

As an unbiased observer, it really looks like IUQ has an axe to grind or some sort of personal issue with YQ.

Of course the author of a program is going to want people to use it. Of course he's going to think it's great. He might even denigrate the competition (although I haven't seen it, either way, it's not unreasonable).

I think we're all smart enough to realize that YQ is biased towards his own creation, and to realize that there are many logging options and that we can try most of them for free. Telling us that over and over -- as if YQ's description of his software (in an appropriate setting) somehow captivates us and renders us incapable of independent thought and evaluation -- isn't adding anything to the conversation. It's just turning the thread ugly and negative, in my opinion.

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.

I'm thinking to myself. If the website is this bad, what is the software like???

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. I should know since I have been re-writing VB6 code into Visual Studio code for the last dozen years.

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. It does not directly support XML which has become the standard for modern software development.

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. This is the reason for the detailed instructions on how to get around security issues on the install pages. Many VB6 applications saved their environment variables directly into the registry. This is a big no-no now days.

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.

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.

I'm thinking to myself. If the website is this bad, what is the software like???

Sheesh. It's been a few years since I looked at the download site, so I brought it up. Took me maybe fifteen seconds to find the download button. Moreover, the reason I haven't needed to refer to the DXLab download page is that the DXLab Launcher program handles all of the upgrade downloads of revised program modules and databases for me.

The software works just fine on my old XP machine with limited resources. I'm a serious DX'er and I trust it with my entire logbook, with QSO's dating back to 1959, and I use it every day.

I came across this program via eHam.net and I must say it is a great program with easy to read instructions and simple to use with some great features. I will recommend this to anyone looking for a new amateur radio logging program. A huge well done guys. John G0NYD / EA7JRI

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'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.

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.

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.

Copyright 2000-2018 eHam.net, LLC
eHam.net is a community web site for amateur (ham) radio operators around the world.
Contact the site with comments or questions.
WEBMASTER@EHAM.NETSite Privacy Statement