“Eclecticism, (from Greek eklektikos, “selective”), in philosophy and theology, the practice of selecting doctrines from different systems of thought without adopting the whole parent system for each doctrine.” – Encyclopaedia Britannica.
Windows 10 20H2
DesktopInfo 2.10.2, also tested and observed on 2.10.1
I observed a weird bug with the CMD item. When the stdout output has exactly 200 characters, DesktopInfo can’t display it or assign it to a variable. Also subsequent CMD items and other items with refresh interval don’t work anymore, and changes to the INI file aren’t noticed anymore. Basically DesktopInfo is broken for any dynamic items then (I think). I’m not sure whether 200 is the only problematic character number, but 199 and 201 seem to work fine.
Here is a simple example to reproduce the issue:
CMD=active:1,file:powershell.exe,parameters:'This line has 199 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | Write-Host -NoNewline
CMD=active:1,file:powershell.exe,parameters:'This line has 201 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | Write-Host -NoNewline
CMD=active:1,file:powershell.exe,parameters:'This line has 200 characters aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' | Write-Host -NoNewline
CMD=active:1,file:powershell.exe,parameters:'This is another line but after the 200 character line CMD items dont work anymore in DesktopInfo' | Write-Host -NoNewline
This topic was modified 4 days, 8 hours ago by Bender. Reason: code block formatting
200 is the magic number. I set the read buffer to 200 bytes. If the stdout pipe contains exactly 200 bytes, it reads it in then stalls on the next read when the pipe contains zero bytes. It’s supposed to return with a result of zero bytes read. That’s a bug in the ReadFile win32 api function. I’ve added a check for the pipe contents before attempting to read it.