Такая ситуация, надо перенаправить поток stdout, так что бы при использовании функций printf, puts и т.д. все выводимые данные выводились в мое окно (а конкретно в RichEdit на нем).
При этом это должно происходить не только в моем модуле, но и во всех загружаемых моим модулях dll-ках.

Т.е есть все printf -ы в моей программе со всеми вызываемыми ею примочками должны итди в мое окно.
О как!!!!
Кто поможет?

Самое простое решение - перенаправить вывод в пайп.

Код

int outPipe[2]; pipe(outPipe); dup2(outPipe[1], STDOUT_FILENO); close(outPipe[1]); FILE *out = fdopen(outPipe[0], "r");

Дальше используя файловый дескриптор out читать из него данные.

Sun, все хорошо но есть два но
1. Это то что приложение у меня НЕ консольное.
2. При таком расскладе как написал ты (или почти таком) в нутри приложение все работает, а вот функции, вызываемой dll выводят в некуда а ради них все и затевалась.
Объясняю ситуацию.
Для упрощения работаю не с pipe, а с дисковым фалом (приблизительно так)

Код

FILE* stream; stream = freopen( "freopen.out", "w",stdout ); HMODULE hmod = LoadLibrary(DllName); F f = (F)GetProcAddress(hmod,fName); printf("This is from Maindlg\r\n"); f(m_SerialPort); fclose(stream);

Так вот фраза "This is from Maindlg\r\n" в файл благополучно записалась, а вот тот printf, который был в функции ушел в некуда.

Дальше инетересние. Значенеи переменой stdout (это 1-ый элемент массива _iob, описанный в stdlib.h) имеет разные значения внутри основго модуля и внутри dll.
Далю "финт ушами", вместно LoadLibrary вызываю
LoadLibraryEx(DllName,NULL,DONT_RESOLVE_DLL_REFERENCES)
- в смысле грузись моя дллька, токль DllMain просьба не выполнять.
При этом обращение к функциям типа printf и GetStdHandle - вызывает ошибку времени выполнения (очень где-то глубоко)

ребята, бьюсь над этим уже много времени.
ПЛИЗ, помогайте

Вобще, судя по всему весь вопрос грубо говоря сводится к выяснению следующих деталей
1. Где/когда/кем ведется заполненение массиво _iob ( т.е. определения значений переменных stdin,stdout,stderr)
2. И что же такое деллает загрузчик при условии, что фуекция DllMain У меня пустая (ведь делает что-то стервец )

Нашел подходящую функцию

Цитата

SetStdHandle The SetStdHandle function sets the handle for the standard input, standard output, or standard error device. BOOL SetStdHandle(   DWORD nStdHandle,   HANDLE hHandle ); Parameters nStdHandle [in] Standard device for which the handle to be set. This parameter can be one of the following values. Value Meaning STD_INPUT_HANDLE Handle to the standard input device. STD_OUTPUT_HANDLE Handle to the standard output device. STD_ERROR_HANDLE Handle to the standard error device. hHandle [in] Handle to set to the specified device.

Sun. солнышко, я нашла это давно, но пока никакой пользе мне это не принисло.
Ели я правльно думаю то, смотри:
Все потоки можно рассматиривать как файлы:
- у файла есть файловы дискриптор int
- может быть определена структура FILE*
- есть HANDLE (виндузовский)
Тк вот все эти функции переопределения потоков, что _dup2, что SetStdHandle, работают с теми же файлами, но каждый своим путем.
Причем для получения HANDLA из файлового дискриптора или наоборот (вобщем любого из трех вышеописанных описателей из любого) есть специальные функци.
Так что твое предложение из тупика нас пока не вывело.

Жду еще

Хм..Странно однако. Видимо где-то в другом месте идет переопределение вывода. Тогда можно попробовать сделать перехват для CreateFile и если будет идти создание "CONOUT$" файла - делать подмену файловго дескриптора. Или сделать перехват для SetStdHandle, так как похоже его кто-то вызывает.

Цитата

Хм..Странно однако. Видимо где-то в другом месте идет переопределение вывода. Тогда можно попробовать сделать перехват для CreateFile и если будет идти создание "CONOUT$" файла - делать подмену файловго дескриптора. Или сделать перехват для SetStdHandle, так как похоже его кто-то вызывает.

Как ты себе это представляешь?

Вся проблема в том, что желательно dll не трогать. Т.е. все делается в основном модуле.
dll и знать не должна куда она выводит

Цитата(Nastya @ 4.4.2005, 10:19)

Как ты себе это представляешь? Вся проблема в том, что желательно dll не трогать. Т.е. все делается в основном модуле. dll и знать не должна куда она выводит

Если предположение что в Dll идет перенаправление вывода верно, то нужно перехватить это перенаправление, установив ловушки для вызова функций SetStdHandle и CreateFile. Тогда если в Dll будет идти попытка перенаправления вывода, мы будем это перехватывать и подменять файловый дескриптор на тот который нам нужен. Что-то вроде такого

Код

BOOL Hook_SetStdHandle(   DWORD nStdHandle,   HANDLE hHandle ) {   if (nStdHandle == STD_OUTPUT_HANDLE) {     // ничего не делаем   } else {      Real_SetStdHandle(nStdHandle, hHandle); .// вызываем настоящую функцию   } } HANDLE Hook_CreateFile(   LPCTSTR lpFileName,   DWORD dwDesiredAccess,   DWORD dwShareMode,   LPSECURITY_ATTRIBUTES lpSecurityAttributes,   DWORD dwCreationDisposition,   DWORD dwFlagsAndAttributes,   HANDLE hTemplateFile ) {   if (strcmp(lpFileName, "CONOUT$")) {       return OurStdOutHandle; // подменяем результат на наш файловый дескриптор   }   return Real_CreateFile(... ); // во всех других случаях передаем управление оргинальной CreateFile функции }

Ой, по моему это слишком
Кроме того, я не уверена ,что CreateFile в принцепе будет. Может просто инициализироваться массив _iob.
Можно попробывать, но как-то такой вариант ТЯЖЕЛОВАТ (в смысле ресурсов)

Вот код, уже с pipe, не обошлось без помощи ребят с форума rsdn.ru

Код

HANDLE StdHandle,hPipe; hPipe = CreateNamedPipe(PIPE_STDOUT_NAME,                                 PIPE_ACCESS_DUPLEX,                                  PIPE_TYPE_BYTE | PIPE_READMODE_BYTE,                                  PIPE_UNLIMITED_INSTANCES,                                  512, 512, 0,                                 NULL);                  StdHandle = CreateFile(PIPE_STDOUT_NAME,                             GENERIC_WRITE |GENERIC_READ,                             FILE_SHARE_WRITE |FILE_SHARE_READ,                             NULL,                             CREATE_ALWAYS,                             FILE_ATTRIBUTE_NORMAL,                             NULL);          ConnectNamedPipe(PIPE_STDOUT_NAME,NULL);     SetStdHandle(STD_OUTPUT_HANDLE,StdHandle);     SetStdHandle(STD_ERROR_HANDLE ,StdHandle);     stdout->_file= _open_osfhandle((long) StdHandle,_O_TEXT);     stderr->_file= _open_osfhandle((long) StdHandle,_O_TEXT);

Из hPipe потом читаем

Цитата(Nastya @ 4.4.2005, 13:29)

Вот код, уже с pipe, не обошлось без помощи ребят с форума rsdn.ru

Но проблема и дальше не решена? Вывод в Dll дальше не перехватывается?

Почему, все запускаемы мной dll-ки пишут в мой pipe.
Причем не имеет значение как организован вывод в sttdout при помощи printf, puts или cout<<

Привет!
вынежден поднять эту тему   
У меня та же задача, что надо все из dll перенаправлять в мой файл и обрабатывать...
Но не могу подключить код, который Nastya реализовала 



вот сюда



dll получает из командной строки опции и работая выдает результаты на консоль...
хочется из консоли перенаправить в exe через пайп...помогите!!!
Как вставить вышеназванное решение?
весь интернет перерыл, нашел только здесь и здесь http://www.rsdn.ru/forum/Message.aspx?mid=13172
да и то, не полные коды...
Есть много примеров с пайпами, но для варианта старта сторонней программы, а не dll
Пример: http://www.codenet.ru/progr/bcb/pipes.php

(исходники dll-ки есть, но все исправить нереально, слишком много кода) 

Привет!
вставил я код, компилируется без ошибок, в файл все stdout из dll записываются, но не получается читать из пайпа (или файла).
Проверял, все сообщения из этого кода идут в никуда, в файл записываются только stdout из dll
Как можно работать в этом случае?