200 character CMD output bug

Tagged: cmd

This topic has 1 reply, 2 voices, and was last updated 4 days, 4 hours ago by Glenn.

Viewing 1 reply thread

Author

Posts
- 8 April, 2021 at 7:09 am #3874
  Bender
  Participant
  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
  0
- 8 April, 2021 at 11:45 am #3877
  
  Glenn
  Keymaster
  
  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.
  
  +1
Author

Posts

Viewing 1 reply thread

You must be logged in to reply to this topic.