@SpriggsySpriggs — what you’re running into is Data Alignment/Packing
I *still* haven’t sat down and sorted out where the BLEEP we’re required to have those 8-byte breakpoints in data types. All I can do is sit down in front of a keyboard, and furiously attempt to change first one and then the other, until I finally find a combo that works.
The "di" is intentional. I wanted to show getting the error of supplying it with a wrong command. As for any extra characters, did you grab my latest code? Also, feel free to diagnose any bugs!
@bplus @STxAxTIC
Just pasted in my latest code (in the best answer post) that seems to behave the way the old one did. Please redownload and run at your convenience. Let me know your results. Fellippe and I tested it ourselves and have compared it to the original header version.
bplus, as for understanding the code:
Windows uses a carriage-return & line-feed combination. This causes an extra line to be displayed in the window if you leave it like that. So, in order to avoid that, I'm removing all instances of CHR$(13). It's the same way I did it in the header file I had. CHR$(10) is the way that matches how Linux would display line endings and is the absolute best way.
cb As Long
$If 64BIT Then
padding As Long
$End If
Type STARTUPINFO
cb As Long
$If 64BIT Then
padding As Long
$End If
lpReserved As _Offset
lpDesktop As _Offset
lpTitle As _Offset
dwX As Long
dwY As Long
dwXSize As Long
dwYSize As Long
dwXCountChars As Long
dwYCountChars As Long
dwFillAttribute As Long
dwFlags As Long
wShowWindow As Integer
cbReserved2 As Integer
$If 64BIT Then
padding2 As Long
$End If
lpReserved2 As _Offset
hStdInput As _Offset
hStdOutput As _Offset
hStdError As _Offset
End Type
TYPE STARTUPINFO
cb AS _INTEGER64
lpReserved AS _OFFSET
lpDesktop AS _OFFSET
lpTitle AS _OFFSET
dwX AS LONG
dwY AS LONG
dwXSize AS LONG
dwYSize AS LONG
dwXCountChars AS LONG
dwYCountChars AS LONG
dwFillAttribute AS LONG
dwFlags AS LONG
wShowWindow AS LONG
cbReserved2 AS LONG
lpReserved2 AS _OFFSET
hStdInput AS _OFFSET
hStdOutput AS _OFFSET
hStdError AS _OFFSET
END TYPE
@NOVARSEG
It might work but it is incorrect. You don't want to make cb into an 8 byte variable just to
fill the space. You would want to leave it as is.
TYPE STARTUPINFO
cb AS LONG
pad1 AS LONG
lpReserved AS _OFFSET
lpDesktop AS _OFFSET
lpTitle AS _OFFSET
dwX AS LONG
dwY AS LONG
dwXSize AS LONG
dwYSize AS LONG
dwXCountChars AS LONG
dwYCountChars AS LONG
dwFillAttribute AS LONG
dwFlags AS LONG
wShowWindow AS INTEGER
cbReserved2 AS INTEGER
pad2 AS LONG
lpReserved2 AS _OFFSET
hStdInput AS _OFFSET
hStdOutput AS _OFFSET
hStdError AS _OFFSET
END TYPE
BOOL CreateProcessA(
LPCSTR lpApplicationName,
LPSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCSTR lpCurrentDirectory,
LPSTARTUPINFOA lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
So it works for 64 bit and not for 32 bit. I'm trying to figure out a way without the compiler directives.
Even with the compiler directives will 64 bit EXE work on 32 bit computer?
Try using _CLIPBOARD$ to capture the second call and paste it in your terminal
Thanks for this great utility. Wanted to let you know about an issue I found on Linux. If the command I send to pipecom is too long, it causes errors indicating that the command text is being truncated. If I use an arbitrarily large fixed length string instead it seems to work properly.
Just changed the following line:Code: QB64: [Select]
stream = popen(cmd + " 2>pipestderr", "r")
to this:Code: QB64: [Select]