Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Visual C++/MFC/WTL > Совместимость dll


Автор: ICEMAN3141592 12.9.2011, 18:25
Здравствуйте. Есть сервер, использует динамические библиотеки от MS Studio 2003, перехожу на MS Studio 2010, есть исходники. Если пересобрать проект, "новые" dll- ки схиляют для сервера. Какие могут быть варианты вообще ? Я честно говорю, что во внутренней структуре dll не разбираюсь. Надеюсь на Вашу помощь и профессионализм.

Автор: borisbn 13.9.2011, 06:14
Если из сервера в длл (или наоборот) передаются stl-ные классы (или даже указатели на них), то с огромной долей вероятности работать не будет

Автор: ICEMAN3141592 13.9.2011, 08:55
Во общем, есть сервер, не я его писал, даже не знаю устройство внутреннее его, НО он принимает dll, скомпилированную от VS 2003, если я исправлю исходники, из которых составляется эта dll в VS 2010, то примет "новую" dll сервер ? Читал на разных постах, что есть вар, что нет, но в большинстве случаев нормально, но я же не могу полагаться на то, что прокатит до поры до времени.

Автор: borisbn 13.9.2011, 09:17
ICEMAN3141592, я тебя понял с первого раза. Перечитай моё сообщение выше:

Цитата(borisbn @  13.9.2011,  06:14 Найти цитируемый пост)
Если из сервера в длл (или наоборот) передаются stl-ные классы (или даже указатели на них), то с огромной долей вероятности работать не будет


Автор: ICEMAN3141592 13.9.2011, 09:44
1. Тут высказывают надежду на stlport (ни разу о таком не слышал), если он используется, то переносимость будет соблюдаться ?
2. Скажите, как лучше поступить, если лицензий на 2003 нету, а поддерживать проект нужно...
3. 
Цитата(borisbn @  13.9.2011,  09:17 Найти цитируемый пост)
ICEMAN3141592, я тебя понял с первого раза. Перечитай моё сообщение выше:

Извините, модераторы с другого форума не поняли сразу проблемы, и я подумал, что пишу о "сложных" вещах smile

Добавлено через 8 минут и 48 секунд
Посмотрел в *.vcproj о stlport, в файле слова такого нету

Добавлено через 13 минут и 3 секунды
Решили посмотреть, передаются ли stl-контейнеры или нет, с помощью midl компиллятор, преобразует интерфейсы из IDL 
в интерфейсы на C, после этого преобразованая проанализировать все вызовы будет нетрудно. Он нагенерит огромный файл
Исходников сервера нету. 

Автор: Earnest 13.9.2011, 12:53
Наличие\отсутствие stl-вызовов и версия компилятора, под которым это все собиралось, никак не связаны. stl либо используется либо нет. Причем, если используется локально (для собственных нужд и нигде не светится в интерфейсах импортируемых функций), то и бог с ней.
Ты бы уже давно скомпилировал библиотеку да проверил. Кстати, совершенно не факт, что код под 2003 так уже безболезненно скомпилируется под 2010. И даже если скомпилируется, то будет ожидаемым образом работать - есть ряд  критичных изменений в поведении компилятора, при переходе с 2003 на более старшие. Но это с совместимостью библиотек не очень связано. Однако, если нужно переходить на новый компилятор и обеспечивать дальнейшее развитие \ поддержку, то вариантов особых нет. Кроме как остаться на 2003.
Что касается совместимости, то проблемы могут быть в других используемых библиотеках, скажем, если используются динамические версии CRT и MFC.
Опять же, эти проблемы возникнут, только если соответствующие объекты "пересекают" границы своих модулей. Скажем, память динамически выделяется в сервере (одна версия CRT), а освобождается в клиенте (другая версия CRT). Или наоборот. Вот тогда проблемы точно будут.
Но грамотно спроектированные (для раздельной жизни) модули таких зависимостей содержать не должны.
Нужно посмотреть на интерфейс (импортируемые функции).

Добавлено через 3 минуты и 36 секунд
Цитата(ICEMAN3141592 @  13.9.2011,  10:44 Найти цитируемый пост)
 с помощью midl компиллятор, преобразует интерфейсы из IDL 

Так у тебя COM-сервер? Тогда проблем быть не должно, разве что авторы сервера совсем уж м..ки. Никаких параметров типа stl-контейнеров в IDL быть не может. И чего на с-файл-то смотреть, гораздо проще смотреть сразу на IDL. Он как минимум компактнее.

Автор: borisbn 13.9.2011, 12:57
Цитата(Earnest @  13.9.2011,  12:53 Найти цитируемый пост)
Нужно посмотреть на интерфейс (импортируемые функции).

Поддерживаю. Без этого сказать точно "всё будет работать" или "точно работать не будет" сказать сложно.
Показывай интерфейс.

Автор: ICEMAN3141592 13.9.2011, 15:33
Цитата(Earnest @  13.9.2011,  12:53 Найти цитируемый пост)

Ты бы уже давно скомпилировал библиотеку да проверил. Кстати, совершенно не факт, что код под 2003 так уже безболезненно скомпилируется под 2010. И даже если скомпилируется, то будет ожидаемым образом работать - есть ряд  критичных изменений в поведении компилятора, при переходе с 2003 на более старшие.

Да когда я писал проект на VS 6.00, а потом пришлось переписывать на VS 2005, проблем было куча smile Так что если переписывать с VS 2003 на VS 2010, то я бы быстро не переписал, т.к. знаю что это означает. Решил почву, так сказать, подготовить.

Цитата(Earnest @  13.9.2011,  12:53 Найти цитируемый пост)
Но это с совместимостью библиотек не очень связано. Однако, если нужно переходить на новый компилятор и обеспечивать дальнейшее развитие \ поддержку, то вариантов особых нет. Кроме как остаться на 2003.

Так если с совместимостью проблем нету, почему бы не продолжить на 2010 ?

Код

//////////////////////////////////////////////
// Реализая контейнеров для COM технологий
//
//

import "oaidl.idl";
import "ocidl.idl";

    /** ISPVector - интерфейс реализации одномерного массива */
    [
        object,
        uuid(9F4ADB2D-47FC-4241-8463-C9C4CDFDF4BD),
        dual,
        helpstring("ISPVector Interface"),
        pointer_default(unique)
    ]
    interface ISPVector : IDispatch
    {
        [id(1), helpstring("method Create")] HRESULT Create([in]DWORD dwItemSize, [in]DWORD dwInitSize, [in]DWORD dwGrowSize);
        [id(2), helpstring("method AddItems")] HRESULT AddItems([in]DWORD dwCount, [in]char* pItems);
        [id(3), helpstring("method Clear")] HRESULT Clear();
        [id(4), helpstring("method GetSize")] HRESULT GetSize([out]DWORD* pdwSize);
        [id(5), helpstring("method GetItems")] HRESULT GetItems([in]DWORD dwFirst, [in]DWORD dwCount, [in, out]char* pItems, [out]DWORD* pdwResult);
        [id(6), helpstring("method GetItemSize")] HRESULT GetItemSize([out]DWORD* pdwSize);
        [id(7), helpstring("method RemoveItems")] HRESULT RemoveItems([in]DWORD dwFirst, [in]DWORD dwCount);
        [id(8), helpstring("method TrimEmpty")] HRESULT TrimEmpty();
    };

[
    uuid(D63E5C21-8D4B-4313-B027-A2080BF15A87),
    version(1.0),
    helpstring("COM Containers 1.0 Type Library")
]
library COMCONTAINERSLib
{
    importlib("stdole32.tlb");
    importlib("stdole2.tlb");

    [
        uuid(56BD6878-9B04-4B13-BD2B-F7C136790C60),
        helpstring("SPVector Class")
    ]
    coclass SPVector
    {
        [default] interface ISPVector;
    };
};



Это один из примеров, есть файлы *.idl от MS, имеются файлы проекта xercesc. Мне нужны в них всех проверить наличие шаблонов STL ?

СПАСИБО Earnest, borisbn за помощь, время которое уделяете.

Автор: ICEMAN3141592 13.9.2011, 15:49
Код

// Created by Microsoft ® C/C++ Compiler Version 13.10.3077 (8d8e4508).
//
// c:\projects_root\win32\debug unicode\tw.tlh
//
// C++ source equivalent of Win32 type library tw\tw.tlb
// compiler-generated file created 12/24/10 at 16:40:10 - DO NOT EDIT!

#pragma once
#pragma pack(push, 8)

#include <comdef.h>

//
// Forward references and typedefs
//

struct __declspec(uuid("87ded1de-f1d7-48ee-b96c-be8b3d69b9c8"))
/* LIBID */ __TWLib;
struct /* coclass */ ThreadStack;
struct __declspec(uuid("49a0fcf3-3971-4b82-9276-3d41f3e7e64d"))
/* dual interface */ IThreadStack;
struct /* coclass */ ProgramStack;
struct __declspec(uuid("53efd35a-e0a5-4c69-aadb-127429a05366"))
/* dual interface */ IProgramStack;
struct /* coclass */ ProgramStackManager;
struct __declspec(uuid("f0cdde38-1fc6-445e-b157-730fb6b822a2"))
/* dual interface */ IProgramStackManager;
struct __declspec(uuid("1ac4df32-f0a2-4782-a334-9c0659e2e0de"))
/* interface */ _IAliveEvents;
struct /* coclass */ Alive;
struct __declspec(uuid("7d3526c4-7a42-42d1-b34f-6105aa79850b"))
/* dual interface */ IAlive;
struct /* coclass */ TWControl;
struct __declspec(uuid("53fb2381-fea3-4a54-91f9-f024830df79d"))
/* dual interface */ ITWControl;

//
// Smart pointer typedef declarations
//

_COM_SMARTPTR_TYPEDEF(IThreadStack, __uuidof(IThreadStack));
_COM_SMARTPTR_TYPEDEF(IProgramStack, __uuidof(IProgramStack));
_COM_SMARTPTR_TYPEDEF(IProgramStackManager, __uuidof(IProgramStackManager));
_COM_SMARTPTR_TYPEDEF(_IAliveEvents, __uuidof(_IAliveEvents));
_COM_SMARTPTR_TYPEDEF(IAlive, __uuidof(IAlive));
_COM_SMARTPTR_TYPEDEF(ITWControl, __uuidof(ITWControl));

//
// Type library items
//

struct __declspec(uuid("f3766478-0304-428c-9c12-ba48d3874ffb"))
ThreadStack;
    // [ default ] interface IThreadStack

struct __declspec(uuid("49a0fcf3-3971-4b82-9276-3d41f3e7e64d"))
IThreadStack : IDispatch
{
    //
    // Raw methods provided by interface
    //

      virtual HRESULT __stdcall push (
        /*[in]*/ LPSTR szName,
        /*[in]*/ LPSTR szDsc ) = 0;
      virtual HRESULT __stdcall addEvent (
        /*[in]*/ LPSTR szDsc ) = 0;
      virtual HRESULT __stdcall pop (
        /*[in]*/ LPSTR szName ) = 0;
      virtual HRESULT __stdcall popLast ( ) = 0;
      virtual HRESULT __stdcall clearAll ( ) = 0;
};

struct __declspec(uuid("80accce3-5c4b-4ceb-94a5-128ac2c65cc6"))
ProgramStack;
    // [ default ] interface IProgramStack

struct __declspec(uuid("53efd35a-e0a5-4c69-aadb-127429a05366"))
IProgramStack : IDispatch
{
    //
    // Raw methods provided by interface
    //

      virtual HRESULT __stdcall createThreadStack (
        /*[in]*/ unsigned long dwThreadID,
        /*[in]*/ LPSTR szDsc,
        /*[out]*/ struct IThreadStack * * stack ) = 0;
};

struct __declspec(uuid("59748e97-1b97-4c6e-a074-dd50a4c27eeb"))
ProgramStackManager;
    // [ default ] interface IProgramStackManager

struct __declspec(uuid("f0cdde38-1fc6-445e-b157-730fb6b822a2"))
IProgramStackManager : IDispatch
{
    //
    // Raw methods provided by interface
    //

      virtual HRESULT __stdcall createProgram (
        /*[in]*/ LPSTR szProgramName,
        /*[in]*/ LPSTR szDsc,
        /*[out]*/ struct IProgramStack * * stack ) = 0;
};

struct __declspec(uuid("1ac4df32-f0a2-4782-a334-9c0659e2e0de"))
_IAliveEvents : IUnknown
{
    //
    // Raw methods provided by interface
    //

      virtual HRESULT __stdcall isAlive ( ) = 0;
};

struct __declspec(uuid("4cba53d2-c659-4295-a251-e9f640399fe4"))
Alive;
    // [ default ] interface IAlive
    // [ default, source ] interface _IAliveEvents

struct __declspec(uuid("7d3526c4-7a42-42d1-b34f-6105aa79850b"))
IAlive : IDispatch
{};

struct __declspec(uuid("2dc28a08-df08-44f9-be68-f694a9f91173"))
TWControl;
    // [ default ] interface ITWControl

struct __declspec(uuid("53fb2381-fea3-4a54-91f9-f024830df79d"))
ITWControl : IDispatch
{
    //
    // Raw methods provided by interface
    //

      virtual HRESULT __stdcall dump ( ) = 0;
      virtual HRESULT __stdcall setDumpName (
        LPSTR szFileName ) = 0;
      virtual HRESULT __stdcall hide ( ) = 0;
      virtual HRESULT __stdcall show ( ) = 0;
};

//
// Named GUID constants initializations
//

extern "C" const GUID __declspec(selectany) LIBID_TWLib =
    {0x87ded1de,0xf1d7,0x48ee,{0xb9,0x6c,0xbe,0x8b,0x3d,0x69,0xb9,0xc8}};
extern "C" const GUID __declspec(selectany) CLSID_ThreadStack =
    {0xf3766478,0x0304,0x428c,{0x9c,0x12,0xba,0x48,0xd3,0x87,0x4f,0xfb}};
extern "C" const GUID __declspec(selectany) IID_IThreadStack =
    {0x49a0fcf3,0x3971,0x4b82,{0x92,0x76,0x3d,0x41,0xf3,0xe7,0xe6,0x4d}};
extern "C" const GUID __declspec(selectany) CLSID_ProgramStack =
    {0x80accce3,0x5c4b,0x4ceb,{0x94,0xa5,0x12,0x8a,0xc2,0xc6,0x5c,0xc6}};
extern "C" const GUID __declspec(selectany) IID_IProgramStack =
    {0x53efd35a,0xe0a5,0x4c69,{0xaa,0xdb,0x12,0x74,0x29,0xa0,0x53,0x66}};
extern "C" const GUID __declspec(selectany) CLSID_ProgramStackManager =
    {0x59748e97,0x1b97,0x4c6e,{0xa0,0x74,0xdd,0x50,0xa4,0xc2,0x7e,0xeb}};
extern "C" const GUID __declspec(selectany) IID_IProgramStackManager =
    {0xf0cdde38,0x1fc6,0x445e,{0xb1,0x57,0x73,0x0f,0xb6,0xb8,0x22,0xa2}};
extern "C" const GUID __declspec(selectany) IID__IAliveEvents =
    {0x1ac4df32,0xf0a2,0x4782,{0xa3,0x34,0x9c,0x06,0x59,0xe2,0xe0,0xde}};
extern "C" const GUID __declspec(selectany) CLSID_Alive =
    {0x4cba53d2,0xc659,0x4295,{0xa2,0x51,0xe9,0xf6,0x40,0x39,0x9f,0xe4}};
extern "C" const GUID __declspec(selectany) IID_IAlive =
    {0x7d3526c4,0x7a42,0x42d1,{0xb3,0x4f,0x61,0x05,0xaa,0x79,0x85,0x0b}};
extern "C" const GUID __declspec(selectany) CLSID_TWControl =
    {0x2dc28a08,0xdf08,0x44f9,{0xbe,0x68,0xf6,0x94,0xa9,0xf9,0x11,0x73}};
extern "C" const GUID __declspec(selectany) IID_ITWControl =
    {0x53fb2381,0xfea3,0x4a54,{0x91,0xf9,0xf0,0x24,0x83,0x0d,0xf7,0x9d}};

#pragma pack(pop)


Есть еще один файл такого же типа и все. Как я понял, передаются интерфейсы (или нет ?). Т.е. если я проект перенесу на 2010, скомпилирую dll, сервер, по идеи, должен будет с ней работать ?

Автор: borisbn 13.9.2011, 16:34
Судя по всему, в интерфейсе длл присутствуют только простейшие типы (LPSTR, HRESULT, DWORD и т.п.).
Упаковка есть
Цитата(ICEMAN3141592 @  13.9.2011,  15:49 Найти цитируемый пост)
#pragma pack(push, 8)

тип вызова прописан явно
Цитата(ICEMAN3141592 @  13.9.2011,  15:49 Найти цитируемый пост)
 virtual HRESULT __stdcall push (

в общем, интерфейс связи длл и сервера проработан хорошо.
Должно всё отработать... Гарантию, конечно, не дам, но впечатление, что всё будет ОК smile

Добавлено @ 16:37
Ещё нужно убедиться, что в настройках проекта 2003 и вновь создаваемого под 2010 установлена одинаковая кодировка: Not Set, Unicode или Multi-Byte.
Т.е. нужно посмотреть, что выставлено в проекте 2003, и выставить такую же в 2010.

Автор: ICEMAN3141592 13.9.2011, 18:53
Так, "одинаковая кодировка: Not Set, Unicode или Multi-Byte."- ясно, что - нибудь еще ?

Автор: borisbn 13.9.2011, 23:08
Собственно, блюдо практически готово - др. словами - пора пробовать 

Автор: Earnest 14.9.2011, 08:40
Я же уже говорила, что если интерфейс чисто COM-овский, никаких stl и прочих классов там быть не может. Только встроенные типы, вариант, да простые структуры, причем определенные где-то там же.

Насчет совместимости, есть еще один параметр компиляции, который надо проверить. "Treat wchar as buit-in type", как-то так называется, в районе Code generation или Language. Тоже должен быть одинаковым. А COM-строки (BSTR), если не ошибаюсь, всегда UNICODE...

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)