CreateProceess() i przekierowanie do pliku ">"

Witam.
ostatnio zauważyłem dziwne zachowanie funkcji CreateProcess(). W moim programie wykorzystuję ją do uruchomienia kompilatora asemblera.
Podaję kod:

	STARTUPINFO si;
	PROCESS_INFORMATION pi;

	ZeroMemory( &si, sizeof(si) );

	si.cb = sizeof(si);
	si.dwFlags = STARTF_USESHOWWINDOW;
	si.wShowWindow = SW_SHOWDEFAULT;
 
	AnsiString Command_A = "tasm.exe plik.asm plik.obj";				// dziala
	AnsiString Command_AA = "tasm.exe plik.asm plik.obj>log.txt";		// dziala
	AnsiString Command_B = "tasm32.exe /ml plik32.asm plik32.obj";		// dziala


	//a to NIE DZIALA (proces przebiega ale brak rezultatu (nie otrzymuje wyniku: plik.obj i log.txt)
	AnsiString Command_BB = "tasm32.exe /ml plik32.asm plik32.obj>log.txt"; 

	if(!CreateProcess( NULL, Command.c_str(), NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi ))   
		{/* obsluga i komunikat o bledzie */}
   
	WaitForSingleObject( pi.hProcess, INFINITE);
	CloseHandle( pi.hProcess );
	CloseHandle( pi.hThread );

W podanym kodzie w miejsce zmiennej Command podstawiam jeden z czterech przedstawionych wariantów.
Wykorzystuję kompilator firmy Borland (tasm - do kompilacji programów 16 bitowch i tasm32 do kompilacji programów 32-bitowych).
Przechwytuję wynik kompilacji do pliku tekstowego w celu wyświetlenia go i odczytania ewentualnych błędów w kodzie .asm.
Co ciekawe testowałem wszystkie 4 warianty ręcznie z poziomu konsoli i działają bez zarzutu.

Nie wiem dlaczego w przypadku użycia Command_BB = "tasm32.exe /ml plik32.asm plik32.obj>log.txt"; proces się wykonuje ale nie dostaję plików .obj i .txt.

Kto wie, w czym tkwi problem i jak go rozwiązać ?

Creating a Child Process with Redirected Input and Output

Generalnie chodzi o ustawienie uchwytu standardowego wyjścia programu odpalanego przez CreateProcess. Uchwyt ten podajemy przez lpStartupInfo->hStdOut. W przykładzie użyto potoku, ale możesz równie dobrze użyć uchwyt standardowego wyjścia twojego programu (GetStdHandle(STD_OUTPUT_HANDLE) ) i chyba też uchwytu do pliku (CreateFile(...) ).

Kiedyś miałem problem z podobną nakładką .
Okazało się że problemem były ścieżki dostępu do tasm i najważniejsze do
pliku kod.asm .

Pomogło dodanie ścieżki do PATH systemowego (lokalizacja tasm po instalacji )
i chyba ustawienie przed wywoływaniem [tasm + wiersz polecenia] za pomocą nakładki
katalogu roboczego fun SetCurrentDirectory na katalog gdzie znajduje się '*.asm' .
Albo podawać ścieżki bezwz. do pliku *.asm .
Po kompilacji ponownie przełączyć się na stary katalog .

W każdym razie bez kontroli przez nakładkę (i system) gdzie jaki plik się znajduje i dodania
ścieżek w wywołaniach to program raz działał a raz nie ... zależnie od np. ostatnio
otwieranego katalogu (część kodu poszła na montowanie ścieżek i ustawianu gdzie co się znajduje, plik source , plik log i td.).
Polecam przyjrzeć się temu zagadnieniu czy aby na pewno
tasm znajduje plik do kompilacji .

proces się wykonuje

Być może , ale czy dostaje wszystkie dane aby sie wykonać poprawnie ?
Nie pamiętam dokładnie wszystkiego
ale właśnie tu był problem..

czyli coś takiego :

 AnsiString Command_A = "tasm.exe    C:\\SCIEZKA_do_PLIKU\\plik.asm plik.obj";

Może byc i tak że pliki log.txt powstają ale w przypadkowym katalogu
tu też trzeba rozwiązać jak je zlokalizować i zapisywać w określonym katalogu .

Właściwie gdybym dzisiaj to pisał zamiast plikow .log.txt zastosował np :
http://cpw.net.pl/c++builder/artykuł/283/
i propozycje adf88 .

Problem ścieżek dostępu jednak i tak pozostaje bez względu na metodę .
Acha jeszcze parametr CreateProcess (.... PCTSTR pszCurDir... ) może chyba trochę pomóc
przy ustawianiu katalogów roboczych.

Ps .
Ja używałem prostego wywołania 'system("tasm scieżki parametry") '
Może spróbuj zastąpić CreateProcess fun system lub funkcje shella. ( ostatecznie WinExec )
CreateProcess zachowuje się czasami dziwnie przy interpretacji wiersza poleceń,
nadpisuje też bufor wiersza poleceń w tym przypadku AnsiString .
Jeśli wszystko zadziała dopiero spróbuj z fun CreateProcess .

Udało mi się rozwiązać sytuacje za pomocą FrontEndów
http://cpw.net.pl/c++builder/artyku%C5%82/283/

Działają ładnie na aplikacjach 32-bit (tasm32) ale nie rozwiązują problemu aplikacji 16-bitowych, (tu: użycie tasm.exe) ponieważ Windows posługuje się wirtualną maszyną 16-bitową, używając własnego procesu "ntvdm.exe" do którego nie mam dojścia.

Czyli jeśli kompiluję aplikacje 16-bit to muszę jednak uruchamiać jak wcześniej:
AnsiString Command_A = "tasm.exe plik.asm plik.obj>log.txt";</url>