Pipecom conversion to BAS only (MAJOR UPDATE!)

[SpriggsySpriggs]

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]

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!

I think I did, your last edit was 12++ PM, my post when checking it 3+PM

I cant follow(understand) your code, do you tell it to use a 1 or 2 char delimiter between (dir) lines for returned string from pipecom function?

[SpriggsySpriggs]

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

[bplus]

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

@SpriggsySpriggs

It looks good now, tried different switches on Dir, thanks for this!

Is pipecome your own name for this method? I could not find anything strongly related to that name on Internet.

This is nice as alternate to Shell for some Windows OS reports, I think.

[SpriggsySpriggs]

@bplus
Yes, pipecom is my own name for it. I came up with it because the action of reading in commands like that is called opening a pipe. And, since it's running a command, I decided to put the two together. Pipecom. Opening a pipe to a command.

[Pete]

I tried to submit a text server to Linux Red Hat, once; but the CEO had a problem with the name Linux ASCII-Hat. Oh well.

Pete

[NOVARSEG]

Trying to understand what the complier directives do. It looks like 4 bytes are added  Does data get stored in padding and padding2   ?

  $If 64BIT Then
                padding As Long
            $End If

$If 64BIT Then
                padding2 As Long
            $End If

example

cb As Long
            $If 64BIT Then
             padding As Long   
            $End If

is cb now the  LSB dword and is "padding"  the MSB dword?

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

[SpriggsySpriggs]

@NOVARSEG
The $IF64 BIT is just so I can check if it is 64 bit and then add an extra 4 bytes to make the struct aligned properly. Like you mentioned with your 16 vs 32 bit.

As for LSB and MSB, yes (I think)

[NOVARSEG]

OK

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

[SpriggsySpriggs]

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

[SMcNeill]

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

It won’t work.  The 2 integers are merged into a single long, giving one a massive value while the other remains 0.

[SpriggsySpriggs]

@SMcNeill
I was only referring to cb. I didn't even bother to read the rest haha

[NOVARSEG]

This should work for 64 bit compiler but will it work for 32 bit

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

For 32 bit the total is 68 bytes but with pad1 and pad2  it's 72 bytes. It looks like these TYPES are very strict on number of bytes. 

[SpriggsySpriggs]

No

[NOVARSEG]

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?
***

Found a pointer to STARTUPINFO

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
);

windows calls them pointers.  a pointer is an memory address.