WinFBE Editor and FreeBASIC Compiler (All-in-One Package) (V3.1.0 June 4, 2023)

[marcov]

- use CreateProcessW, but read the docs carefully (my highlighting):

The TL;DR:

- expand paths (make them absolute and resolve all "..\", since NT paths can't handle that)
- prepend \\?\
- calll the -W function

The Unicode version of this function, CreateProcessW, can modify the contents of this string.

New for me, will have to check that in our code. Unfortunately, your source seems to be encoded in some way, won't open with notepad. (despite having an .asc extension)

[jj2007]

source seems to be encoded in some way, won't open with notepad. (despite having an .asc extension)

Wordpad will do, but that won't help you because the fun stuff is under the hood. Fact is you don't have to prepend the \\?\ stuff, CreateProcessW works fine with a plain UTF-16 path.

[marcov]

source seems to be encoded in some way, won't open with notepad. (despite having an .asc extension)

Wordpad will do, but that won't help you because the fun stuff is under the hood. Fact is you don't have to prepend the \\?\ stuff, CreateProcessW works fine with a plain UTF-16 path.

Wordpad doesn't solve much it seems, and indeed createprocessw doesn't come with the usual LFN warning most W apis have. (like deletefilew).

It does say however:

The maximum length of this string is 32,768 characters, including the Unicode terminating null character. If lpApplicationName is NULL, the module name portion of lpCommandLine is limited to MAX_PATH characters.

So only if lpapplicationname!=null it seems.

I'll have to review our own createprocessw wrapper soon, and keep this, and the "written to" warning in mind. Thanks.

[jj2007]

I have no problems with command lines longer than 260 chars. But saving or renaming a file with a path longer than 260 chars fails with Explorer (manually) and using CreateFileW programmatically. Below 260, the prepending is not required. Above that, it doesn't help. Pretty confusing.

[PaulSquires]

Thanks guys for the info. Here is the code that I am using to do the compile and to capture the console output. Maybe you can see where I might be going wrong.

Code: Select all

''
''
private function RedirConsoleToFile( byref wszExe AS wstring, _
                                     byref wszCmdLine AS wstring, _
                                     byref sConsoleText AS string _
                                     ) as long

   dim SecurityAttribute AS SECURITY_ATTRIBUTES
   dim hChildStdOutRead  AS PHANDLE
   dim hChildStdOutWrite AS PHANDLE
   dim dwReadBytes       AS long
   dim sBuffer AS STRING * 4096
  
   ' Set the bInheritHandle flag so pipe handles are inherited.
   SecurityAttribute.nLength              = SIZEOF(SECURITY_ATTRIBUTES)
   SecurityAttribute.bInheritHandle       = TRUE
   SecurityAttribute.lpSecurityDescriptor = NULL

   ' It appears that CreateProcess will fail if szExe is wrapped in quotes. This
   ' means that the WinFBE installation and the location of the gcc tools should not
   ' have any embedded spaces in their folder paths. 

   ' Create a pipe for the child process's STDOUT.
   IF CreatePipe(@hChildStdOutRead, @hChildStdOutWrite, @SecurityAttribute, BYVAL 0) = FALSE THEN
      ? "error creating pipe"
   ELSE
      ' Ensure the read handle to the pipe for STDOUT is not inherited.
      IF SetHandleInformation(hChildStdOutRead, HANDLE_FLAG_INHERIT, BYVAL 0) = FALSE THEN
         ? "error SetHandleInformation"
      ELSE
         ' Create the child process and read from its standard output
         dim ProcessInfo AS PROCESS_INFORMATION
         dim StartupInf  AS STARTUPINFO

         StartupInf.cb         = SIZEOF(STARTUPINFO)
         StartupInf.hStdError  = hChildStdOutWrite   
         StartupInf.hStdOutput = hChildStdOutWrite  
         StartupInf.dwFlags    = STARTF_USESTDHANDLES

         dim wszFullCommandLine as wstring * 32767
         dim wszFullExe as wstring * 32767
         
         if instr(wszExe, " ") then
            wszFullExe = wchr(34) & wszExe & wchr(34, 32)
         else
            wszFullExe = wszExe 
         end if
         
         wszFullCommandLine = wszFullExe & " " & wszCmdLine
         
' This call to CreateProcessW will succeed in all cases except for the one
' where there is spaces in wszFullExe because once I wrap the string in double
' quotes then the call to CreateProcessW fails.
         IF CreateProcessW( wszFullExe,  _    ' Create the child process.
                     wszCmdLine, _       ' Command line
                     BYVAL 0,     _  ' Process security attributes
                     BYVAL 0,     _  ' Primary thread security attributes
                     TRUE,        _  ' Handles are inherited
                     CREATE_NO_WINDOW, _  ' Creation flags  
                     BYVAL 0,     _  ' Use parent's environment
                     BYVAL 0,     _  ' Use parent's current directory
                     @StartupInf,  _  ' STARTUPINFO pointer
                     @ProcessInfo) THEN

' If I use NULL for the first parameter and instead include the exe name as the
' first parameter of the second parameter then the compile will fail with a "linker
' error not finding WinMain@16".
'         IF CreateProcessW( NULL,  _    ' Create the child process.
'                     wszFullCommandLine, _       ' Command line
'                     BYVAL 0,     _  ' Process security attributes
'                     BYVAL 0,     _  ' Primary thread security attributes
'                     TRUE,        _  ' Handles are inherited
'                     CREATE_NO_WINDOW, _  ' Creation flags  
'                     BYVAL 0,     _  ' Use parent's environment
'                     BYVAL 0,     _  ' Use parent's current directory
'                     @StartupInf,  _  ' STARTUPINFO pointer
'                     @ProcessInfo) THEN

            CloseHandle(hChildStdOutWrite) ' To avoid ReadFile hanging at the end.
            DO
               IF ReadFile(hChildStdOutRead, BYVAL VARPTR(sBuffer), 4096, @dwReadBytes, BYVAL 0) = FALSE THEN 
                  '? "ERROR ReadFile. hChildStdOutRead=";hChildStdOutRead
                  '? "GetLastError: "; GetLastError
                  EXIT DO
               end if  
               sConsoleText = sConsoleText & LEFT(sBuffer, dwReadBytes)
               '(at this stage we could SAVE the buffer that we've read from the child to a file, but 
               ' thats an extra ReadFile+WriteFile compared to the direct-to-hFile method)
            LOOP
            
         else
            ? "CreateChildProcess failed"      
            ' Close handles to the child process and its primary thread.
            ' Some applications might keep these handles to monitor the status 
            ' of the child process, for example.
            CloseHandle( ProcessInfo.hProcess )
            CloseHandle( ProcessInfo.hThread )
         END IF
         
      END IF
   END IF

   function = 0
END function

[marcov]

I have no problems with command lines longer than 260 chars. But saving or renaming a file with a path longer than 260 chars fails with Explorer (manually) and using CreateFileW programmatically. Below 260, the prepending is not required. Above that, it doesn't help. Pretty confusing.

And if you don't sanitize your paths (and have e.g. ..\ in them) that gets even more confusing :-)

Note that some win10 update (may 18 ?) has an longlfn option, and also applications can manifest themselves as being longlfn compatible and then the 260 limit goes away.

[fxm]

Indeed, under Windows, only the folder and file paths can not exceed 260 characters (basic setting).
As for the command line itself, it can have several thousands of characters depending on the version of Windows.

[macko17]

Maybe you can see where I might be going wrong.

It won't fix any problems you may have but you're leaking the handle to the read end of the pipe. The write end is closed, but not the read. The MSDN example the code is based off has the same error so you translated it too perfectly :-)

[jj2007]

It won't fix any problems you may have but you're leaking the handle to the read end of the pipe. The write end is closed, but not the read. The MSDN example the code is based off has the same error so you translated it too perfectly :-)

Good find! Is there any correct example around? I have similar code, and it does indeed leak one handle per call, but GetLastError reports zero for the six CloseHandle calls involved.

[PaulSquires]

Version 1.9.8 (November 7, 2019)
- Added: ListView ItemSelectionChanged event.
- Added: ListView ColumnClick event.
- Added: ListView.BeginUpdate and ListView.EndUpdate for situations when adding many items during a bulk add.
- Added: ListViewRow, ListViewColumn to the e EventArgs passed to certain ListView event handlers.
- Added: Code to manipulate ListView Columns Text, Width, Alignment, Add, Insert, Remove, Clear for situations outside of the Form's Initialize event.
- Fixed: Much faster deallocation of memory for large collections of items for controls like ListView and ListBox.
- Fixed: ListView Click event now only fires once rather then three times when fired.
- Fixed: freebasic_keywords.txt to remove duplicate entries (thanks cbruce).
- Fixed: Regression fixed whereby compile would fail for source code files that have spaces in their full path filename. However, the problem still persists if your WinFBE installation folder contains spaces. Install WinFBE to locations with folder paths containing no spaces until a permanent fix can be found for this problem.

https://github.com/PaulSquires/WinFBE/releases

[marcov]

I can remember two problems with our implementation. One is summoned up by this comment:

{ The handles that are to be passed to the child process must be
inheritable. On the other hand, only non-inheritable handles
allow the sending of EOF when the write-end is closed. This
function is used to duplicate the child process's ends of the
handles into inheritable ones, leaving the parent-side handles
non-inheritable.
}

See TProcess source code for some context. The sourcecode is portable (OSX/Unix,Windows), and therefore can be hard to read.

The other one is something that is logical, but easily overlooked: If you connect both stdin and stderr pipes, but don't drain stderr AND data is written to stderr, stdin pipe will stall. (e.g. you don't drain stderr because you are blocked on a huge drain of stdin, or you try to read stderr and block on it, but the stderr will only come if stdin is drained more). This was fixed by always using peeknamedpipe, and never reading more bytes than peeknamedpipe specifies, alternating both pipes. This also helps with running the process (and continuously process output) in the same thread as the gui.

[fxm]

- Fixed: Regression fixed whereby compile would fail for source code files that have spaces in their full path filename. However, the problem still persists if your WinFBE installation folder contains spaces.

Indeed, it does not work until the end.
For now, I stay with version 1.9.1.

[PaulSquires]

- Fixed: Regression fixed whereby compile would fail for source code files that have spaces in their full path filename. However, the problem still persists if your WinFBE installation folder contains spaces.

Indeed, it does not work until the end.
For now, I stay with version 1.9.1.

Thanks fxm, I will continue to try to find an acceptable solution to this problem.

[ur_naz]

it seems like 1.9.8 cannot dysplay cyrillic symbols properly. while 1.7.4 can

[PaulSquires]

- Fixed: Regression fixed whereby compile would fail for source code files that have spaces in their full path filename. However, the problem still persists if your WinFBE installation folder contains spaces.

Indeed, it does not work until the end.
For now, I stay with version 1.9.1.

Hi fxm,

I have doing many, many, tests trying to figure out why this fails. It doesn't appear to be related to CreateProcess at all but rather (maybe) to MingGW and spaces in file paths. Using folder with spaces, I tried doing compiles directly from a batch file and got error from AS.EXE indicating that it can't find the necessary files.

I then decided to re-download WinFBE 1.9.1 (directly from my Releases repository on GitHub) and set up a folder structure similar to yours and the compile also failed. Here are the details:

Code: Select all

Command Line: 
C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\fbc32.exe -m "C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\test.bas" "" -v -s console -i ".\FreeBASIC-1.06.0\inc\Afx" 

FreeBASIC Compiler - Version 1.06.0 (02-17-2019), built for win32 (32bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
standalone
target:       win32, 486, 32bit
compiling:    C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\test.bas -o C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\test.asm (main module)
assembling:   C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\bin\win32\as.exe --32 --strip-local-absolute "C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\test.asm" -o "C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\test.o"
Assembler messages:
Error: can't open Outils for reading: No such file or directory
Outils: Error: can't open Personnels\WinFBE_Suite\FreeBASIC-1.06.0\bin\win32\as.exe for reading: No such file or directory
assembling failed: 'C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\bin\win32\as.exe' terminated with exit code 1

Can you confirm that your WinFBE 1.9.1 compiles? It would be weird that yours compiles but mine does not?

The source file I used is extremely simple.

Code: Select all

? "spaces test"
sleep

Here is the batch file I am using to test:

Code: Select all

"C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\fbc32.exe" test.bas -v -s console   

And here is the console output:

Code: Select all

C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite>"C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\fbc32.exe" test.bas -v -s console
FreeBASIC Compiler - Version 1.06.0 (02-17-2019), built for win32 (32bit)
Copyright (C) 2004-2019 The FreeBASIC development team.
standalone
target:       win32, 486, 32bit
compiling:    test.bas -o test.asm (main module)
assembling:   C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\bin\win32\as.exe --32 -
-strip-local-absolute "test.asm" -o "test.o"
Assembler messages:
Error: can't open Outils for reading: No such file or directory
Outils: Error: can't open Personnels\WinFBE_Suite\FreeBASIC-1.06.0\bin\win32\as.exe for reading: No such file or directory
assembling failed: 'C:\Users\rambotheman\Documents\Mes Outils Personnels\WinFBE_Suite\FreeBASIC-1.06.0\bin\win32\as.exe'
 terminated with exit code 1