[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

I haven't looked at the specific issue, but Windows can export data from a DLL into another DLL.

The data to be exported should be declared __declspec(dllexport), and when it is required to be imported declared as __declspec(dllimport).

The attached zip includes a DLL (dllexport) that exports a value (myData) along with a function (initData) to initialise the data, a second DLL (dllimport) that imports the value and exports a function to return the value, and a main that initialises the data with a call into the first DLL and then retrieves the value with a call to the 2nd DLL.

Compile with:

cl /LD dllexport.c

cl /LD dllimport.c dllexport.lib

cl main.c dllimport.lib dllexport.lib

running main.exe gives the expected out value.

Normally macros would be used such that the same header file is used for both export and import changing the __declspec() mode depending on what is to be done via a compilation definition.  Doing this though, does preclude doing both import and export from the same DLL.

 

On 20 May 2017 at 22:03, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:

On 19-05-17 19:44, Guy Harris wrote:
> For example, if libwireshark exports a value_string table, I'm not sure all the platforms we support would allow a plugin dissector to point to that value_string from one of its header fields.

I think we're seeing that with TFS (true/false strings). We have a collection of
them ready for use in tfs.[ch], but these appear to be unusable in (dissector)
plugins on Windows.

Thanks,
Jaap

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@wireshark.org?subject=unsubscribe

--

Graham Bloice

Software Developer

Trihedral UK Limited

Attachment: dlltest.zip
Description: Zip archive