1) кого "скомпелировал"
2) правильно писать скомпилировал
3) приведи коды "скопированного" строки с 10-й по 20-ю

Galkov я не исправим русский в школе ПРОХОДИЛ а не ИЗУЧАЛ , ну да ладно.
Скомпилировал тот же пример который выкладывал с поправкой от Alexbootch...

Я тоже (с поправкой на имя консоли)

Вопрос остается:

andrestudio, попробуй удалить файл hiWinExec.dcu. Может поможет.

коды скопированого hiWinExec строки с 10-й по 20-ю

hProcess: THandle;
hPipeInputWrite: THandle;
hPipeOutputRead: THandle;
hPipeErrorsRead: THandle;
hPipeInputRead: THandle;
hPipeOutputWrite: THandle;
hPipeErrorsWrite: THandle;

dwReadThreadID: dword;
hReadThread: THandle;
FRead: boolean;

Эдик hiWinExec.dcu - у меня поиск не нашёл

Э, я после замены кода обычно перегружаю хиасм, на всякий случай..

Ты вот прикинь, что было бы, если бы я после каждой правки кода на лету, перегружал HiAsm

Ну ты сравнил - ты наверное и в откомпилированной проге можешь её исходник править, чтобы сразу результат был виден
Спасибо, буду знать (не помню кто мне насоветовал перегрузы, а может я сам придумал)..

Андрей., перегруз нужен, когда правишь *.ini -- добавляешь точки, меняешь их названия и тп

tsdima, посмотрел я немного теорию, и вот что вижу (не смотря на то, что у меня все работает):

собственно, из bError=true еще не следует (чисто логически) что не вычитан весь буфер именно из hPipeOutputRead

как бы не увидел в MSDN проверки закрытия каналов со стороны клиента методом проверки PeekNamedPipe. Там рассказывают про возврат 0-ка через ReadFile

MSDN писал(а):

To read from the pipe, use the pipe's read handle in a call to the ReadFile function. The ReadFile call returns when another process has written to the pipe. The ReadFile call can also return if all write handles to the pipe have been closed or if an error occurs before the read operation has been completed.

но для этого, хэндлы каналов со стороны сервера hPipeErrorsRead, hPipeOutputRead, hPipeInputWrite не должны наследоваться дочерним процессом. Про Read-End цитата выше, а про Write-End вот:

MSDN писал(а):

In this case, the parent process must ensure that the child process does not inherit the pipe's write handle. If this is not done, the ReadFile operation performed by the child process cannot return zero because the child process has an open handle to the write end of the pipe

Поскольку мы не должны полагаться на конкретный код клиента, то должны следовать общим правилам, и не передавать в наследование серверные хэндлы каналов hPipeErrorsRead, hPipeOutputRead, hPipeInputWrite А клиентские хэндлы каналов hPipeErrorsWrite, hPipeOutputWrite, hPipeInputRead должны закрывать сразу же после создания процесса

в принципе, закрытие каналов hPipeErrorsWrite ИЛИ hPipeErrorsWrite - еще не означает закрытия консоли. Это вообще-то - сигнальное состояние для hProcess

вообще-то, при создании процесса, мы лочим не только pi.hProcess, но и pi.hThread Ему тоже надо бы говорить CloseHandle

Кабы была только одна труба, откуда читать надо, я бы выкинул PeekNamedPipe и проблем меньше было бы. Можно два потока замутить, хотя надобность этого под вопросом.
Выход из цикла по bError=true будет только когда мы хендлы закроем. Вместо пустого event-а для задержки можно hProcess ожидать, чтобы поймать момент, когда процесс сам собой завершится. Надо только потом из трубы дочитать.
pi.hThread надо бы конечно сразу отпускать, хотя, после того как мы убьём процесс (или он сам помрёт) pi.hThread уже никого не интересует.

Утечка памяти, это тоже такая память, которая никого не интересует

Собственно, такой код: code_8670.txt
- просто показывает систематический перерасход всяких там хэндлов (в т.ч. и Thread)
Ну и памяти, соответственно...
------------ Дoбавленo:

блин... и события выходные не синхронизированы

Установил HiAsm v3.65 build168 (предыдущий build167 удалил)

заменил hiWinExec.pas исправленный - tsdima, но результата не достиг (4998 стр) и стоп.
Вобщем если консольную прогу скомпилировать в FPC то из неё удаётся получить 5000 строк, но это мою проблему не решает так как я рачитывал использовать стороннию консольную программу

Galkov, tsdima, то что у Вас работает сомнений нет (может у Вас коды лучше причёсаны) а мне малость чего то не хватает, может мне ещё с SVN что нибудь заменить?

Написал тут утилитку, которая передает консольному (.cmd) скрипту кодирования видео параметры и запускает выполнение этого скрипта (doConsoleExec) далее результат работы скрипта выводится в BlockFind, чтобы найти там процент выполнения задачи. Ну и соостветственно этот процент передается на прогрессбар утилитки. Через случайное время работы скрипта вылетает Runtime error 216. Консольный скрипт использую уже года три. Он рабочий. Помогите избавиться от ошибки.

code_23143.txt

Попробуй между WinExec и BlockFind вставить Charset.