Due to the never ending plandemic lockdowns it's now been well over a year since I've done any sorta substantial coding effort at work. It's been mostly just endless talk about maybe getting into the lab and doing something when things finally open up. But now I don't even do that because I got myself "resigned" for resisting the jab.
So I thought maybe I should try and code something in my now copious free time to see if I still got what it takes. And this is where it took me. Ziptuner on Windows 10. Why not?
I think the play button works, but I have no speakers yet to be sure.
It still needs a whole lotta of tender lovin care, but all the essentials are there. I had to build an updated
dialog.exe for Windows based on this old
cdialog for windows recipe to get all the extra button options required for the ziptuner. So I'll probably publish that procedure and put out a binary, real soon now.
And eventually a ziptuner "package" for Windows will follow.
Update Feb 11, 2022
Problems, problems, problems. The Windows 10 PC is really throwing up some roadblocks. Apparently the Windows Terminal app has quite not come along as far as I'd hoped. The internet and linux have rallied around the versatile variable length utf-8 Unicode encoding, but MS support is spotty, even in the spiffy new tabbed terminal app. I can't seem to stabilize it on one set of glyphs that works well in the ziptuner. I'm sure this is partly due to ignorance on my part, but the OS still gets some of the blame in my mind.
To test it I saved the dialog command from a sample ziptuner query to a simple batch file called dlg.bat and ran it through several paths to the display to try and sort out what's going on. First I just typed it out in the command prompt.
D:> Type dlg.bat
It's all Greek to me, but I think it looks right. So I typed it out again, but this time I piped the output through the
more utility.
D:> Type dlg.bat | more
That looks like it dropped the
utf-8 support and went with a representation using the ibm pc code page 437 setting. I get the same thing if I simply type it out in the older CMD prompt window instead of the terminal app. Disappointing, but no surprise there.
Next I ran the batch file to see what the dialog program itself would do with it.
D:> dlg.bat
It looks like it interpreted it as utf-8, but forgot it had all the glyphs in the font. Weird.
Finally I ran ziptuner, resumed the previous search, and had the ziptuner run the dialog program in a sub-shell.
D:> ziptuner
That looks like it maybe tried to go back to an 8 bit code page interpretation again. But which code page?
I could live this for a while, but it also confuses the dialog and
garbage gets left behind when you scroll through the list. Oh well, I
got some work to do to sort all this out...
And meanwhile, to add to my woes the sound card in the Windows PC is busted and produces no sound, so I've gotta fix that as well.
Update May 2, 2022
Wow, almost 3 months and no update. What's up with that? Well, I gotta admit I almost gave up right then, but sometime after discovering the dead sound card I remembered a dirt cheap USB Music Fairy sound stick that I bought back in the dark ages to provide some sound in desperate times.
Unfortunately, the alternate "Engrish" name on the purple
Music Faily disk proved more apt, and it performed as promised. It
failed. Or more precisely, it failed for me on Windows 10. I suspect the ancient drivers delivered on the purple mini CD made extensive proprietary use of the CPU for extra signal processing horsepower to assist the stick. Sadly, those drivers only work on expired Windows from the distant past, and while Windows 10 has some generic drivers that claim to support the sound stick, the audio output is a cacophonous discordant disaster. Very discouraging.
Again I almost gave up, but I can be a glutton for punishment so I pushed on with the UTF-8 issues. However despite some interesting investigations like
Bush hid the facts and a run in with the 8K Windows command line length limit, I was ultimately unsuccessful making UTF-8 work with the dialog program running in a separate subprocess. Oh well.
Now, I know I promised to deliver an updated dialog program for Windows, but it turns out I actually found one already available on Github that behaves pretty much the same as my build. So I'll simply link to that instead.
At this point I think the right way to go on Windows would be to pull the libdialog.a static library right into the ziptuner executable itself and run the dialogs directly as local procedure calls so everything can be done in a single process. That'd be a whole lot easier to debug, would also avoid the command line length limit, and actually seems like a more Windowsy approach. If I ever get some working sound hardware running on the Windows box, I still may do just that. We'll see...
