Добрый день коллеги!

Возник вопрос в части реализации одной задачки.

Начнем с того, что у нас есть.
В свое время наша фирма разработала по ТЗ заказчика вспомогательную программу, одна из функций которой была работа с аппаратными средствами).
Программа написана на С++. Программу внедрили и сдали клиенту в 1998г. По мере поступления запросов от клиента, функционал проги дописывался.
Теперь о главном. Во время внедрения программы у клиента, часто возникала проблема с данными передаваемыми аппаратным средствам.
Для контроля за передаваемыми данными с нашей стороны была написана DD.DLL, которая записывала лог передаваемых данных(в dd.dll только одна функция csr_DbgWriteData(char*).
В функцию передается строка с данными). При запуске программы, программа ищет DD.DLL, динамически ее загружает и записывает данные в файл.

Теперь о проблеме
Часть ошибок нашли и исправили. Но осталась группа ошибок которые периодически "вылазят" еще, и которые можно выявить только анализируя принимаемые и передаваемые данные аппаратуре.

Что хочется сделать
Хочется написать отдельную программу, которая в реальном времени получает внутренние данные из нашей DD.DLL(т.е. из нашей основной программы). Проводит анализ полученных данных и визуализирует полученную информацию.


Что у нас есть, что можем, как хочется сделать
Мы можем передать указатель на класс, который содержит внутренние данные программы в нашу функцию (перепишем функцию csr_DbgWriteData(char*, CCSR*) )
Закидываем нашу DD.DLL в каталог программы.
Запускаем приложение клиента. В момент передачи и приема данных находим DD.DLL динамически ее загружаем. По необходимости вызываем DbgWriteData. После завершения процесса обмена данными выгружаем нашу DLL.
Класс CCSR содержит данные, многие из которых являются указателями на классы или структуры данных(собственная реализация LIST).

Вопрос
Как наилучшим образом организовать передачу данных между процессами(между основной программой(а точнее сказать DD.DLL) и новым приложением) с учетом что это указатели на данные?
Причем разработка дополнительной новой программы будет вестись на Visual Studio 6.

Здравствуйте, wbear, Вы писали:

W>Вопрос
W>Как наилучшим образом организовать передачу данных между процессами(между основной программой(а точнее сказать DD.DLL) и новым приложением) с учетом что это указатели на данные?
W>Причем разработка дополнительной новой программы будет вестись на Visual Studio 6.

А почему бы не сделать так, что ваша программа самостоятельно пишет структурированные логи, и она же устраивает ротацию логов, чтобы не заполнить ими весь диск, а отдельная программа-визуализатор эти логи визуализирует.

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

Здравствуйте, wbear, Вы писали:

В другой процесс загрузится другой инстанс вашей dd.dll, и указатель на данные будет указывать в никуда. Для взаимодействия между процессами, данные должны так или иначе пройти маршалинг. Для этого, ещё во времена VS6 и ранее, были придуманы COM (COM exe сервер, как раз межпроцессорный).

В вашем конкреном случае (когда не хочется революций в архитектуре), самое простое, наверное, будет передавать данные через Shared Memory. Можно реализовать эти интерфейсы в dd.dll.

D> Для этого, ещё во времена VS6 и ранее, были придуманы COM (COM exe сервер, как раз межпроцессорный).

Или MS RPC.

D>В вашем конкреном случае (когда не хочется революций в архитектуре), самое простое, наверное, будет передавать данные через Shared Memory. Можно реализовать эти интерфейсы в dd.dll.

Это который через CreateFileMapping, MapViewOfFile, CopyMemory ?

Здравствуйте, m2user, Вы писали:

M>Или MS RPC.

Спасибо, упускал из вида. Иногда именно это и надо было сделать в старых динозаврах.

Здравствуйте, m2user, Вы писали:

D>> Для этого, ещё во времена VS6 и ранее, были придуманы COM (COM exe сервер, как раз межпроцессорный).

M>Или MS RPC.

D>>В вашем конкреном случае (когда не хочется революций в архитектуре), самое простое, наверное, будет передавать данные через Shared Memory. Можно реализовать эти интерфейсы в dd.dll.

M>Это который через CreateFileMapping, MapViewOfFile, CopyMemory ?

Да.
CopyMemory я не использовал, просто писал и читал по указателю из MapViewOfFile.

    DWORD dwSizeHigh = SizeToAlloc >> 32;
    DWORD dwSizeLow = static_cast<DWORD>(SizeToAlloc);
    m_hHandle = CreateFileMapping(INVALID_HANDLE_VALUE, 0, PAGE_READWRITE, dwSizeHigh, dwSizeLow, "<most unique name>");
    if (m_hHandle == INVALID_HANDLE_VALUE)
    {
        char T[512];
        sprintf(T, "Failed to alloc %I64u bytes for Image", SizeToAlloc);
        MessageBox(0, T, "Fatal Error", MB_OK | MB_ICONEXCLAMATION | MB_APPLMODAL);
        logFatalError(_MSGINFO_, T);
        return FALSE;
    }

    BYTE* p = (BYTE*)MapViewOfFile(m_hHandle, FILE_MAP_ALL_ACCESS, 0, 0, SizeToAlloc);
    if (!p)
    {
        char T[512];
        sprintf(T, "Failed to alloc %I64u bytes for Image", SizeToAlloc);
        MessageBox(0, T, "Fatal Error", MB_OK | MB_ICONEXCLAMATION | MB_APPLMODAL);
        logFatalError(_MSGINFO_, T);
        return FALSE;
    }
    m_pBmi = (BITMAPINFO*)GlobalAlloc(GMEM_FIXED, HeaderSize());

    m_pAllocData = p; //

m_pAllocData в разделяемой памяти. Другой процесс Другой процесс получает доступ точно так-же по имени "<most unique name>". Можно GUID сгенерировать и сделать константой с префиксом для читателей-людей.

Здесь был bmp и указатель кастуется к BYTE*. Но никто не запрещает использовать структуры с полями:

    HANDLE hHandle = CreateFileMapping(INVALID_HANDLE_VALUE, 0, PAGE_READWRITE, 0, sizeof(DiagnosticCounters::DIAG_COUNTERS), "<{GUID}>_Counters");
    g_pCounters = (DiagnosticCounters::DIAG_COUNTERS*) MapViewOfFile(hHandle, FILE_MAP_ALL_ACCESS, 0, 0, sizeof(DiagnosticCounters::DIAG_COUNTERS));
    memset(g_pCounters, 0, sizeof(DiagnosticCounters::DIAG_COUNTERS));

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, wbear, Вы писали:

W>>Вопрос
W>>Как наилучшим образом организовать передачу данных между процессами(между основной программой(а точнее сказать DD.DLL) и новым приложением) с учетом что это указатели на данные?
W>>Причем разработка дополнительной новой программы будет вестись на Visual Studio 6.

Pzz>А почему бы не сделать так, что ваша программа самостоятельно пишет структурированные логи, и она же устраивает ротацию логов, чтобы не заполнить ими весь диск, а отдельная программа-визуализатор эти логи визуализирует.

Pzz>Одно из приятных дополнительных достоинств такого подхода заключается в том, что пользователь может послать вам свои логи вместо того, чтобы вам к нему переться.

Программа залогирована по самые уши. В программе можно установить уровень логирования и объем сохраняемой информации. На основании залогированной информации проблем в своей части кода мы не видим.В связи с этим есть желание залезть на чужую территорию и подсмотреть что там происходит. А там все хранение данных реализовано на динамической памяти.

Здравствуйте, wbear, Вы писали:

W>Вопрос
Это тупиковый путь. Увеличивая сложность будет расти вероятность ошибок.
W>Причем разработка дополнительной новой программы будет вестись на Visual Studio 6.
А как вы будете контролировать правильность работы программы для логирования данных и, например, ситуаций в которых обе программы будут конкурировать за данные? Там же тоже будут ошибки, а чтобы их отловить, надо будет написать ещё одну программу.