[vorbis-dev] new DLL additions in core libs

[Chris Wolf]

On 9/13/2001 at 12:28 PM Brian Havard wrote:

>On Wed, 12 Sep 2001 19:16:38 -0700, Chris Wolf wrote:
>
>>On 9/13/2001 at 11:55 AM Brian Havard wrote:
>>
>>>>
>>>>OK.  So the basic problem is that static externs are unsharable?  
>>>
>>>That doesn't sound right. It should work if (and only if) the variables
>are
>>>declared to the dll's user using __declspec(dllimport).
>>
>>I'm afraid that's not really true.  That is just an optimization.
>>To quote Microsoft's documentation:
>>
>>>You do not need to use _declspec(dllimport) for your code to compile
>>>correctly, but doing so allows the compiler to generate better code. The
>>>compiler is able to generate better code because it knows for sure
>whether
>>>a function exists in a DLL or not, so the compiler can produce codes that
>>>skip a level of indirection that would normally be present in a function
>>>call that crossed a DLL boundary. 
>
>That's not my experience. When porting a DLL of mine to Win32 I found that
>I was getting total garbage when accessing an array exported from it until
>I added the _declspec(dllimport). However, this was using Watcom C++, not
>VC. I'd still give it a try if I were you.

That's definitely not the case here, because I also tried compiling vorbisenc.c 
into the main vorbis.dll, (one single DLL, no vorbisenc.dll) and the application ran fine.

The problem is intra-DLL access, not DLL-application access, and yes, I tried
it anyway before I made the claim that it didn't work.  The problem is not garbage
upon dereferencing, the problem is an access violation upon an attempt to dereference.

If you check further back in the archive of this thread, there was a lot of discussion on this
issue, and other techiques were discussed to overcome this win32 shared library architecture
limitation.  The conclusion drawn was that the only way for one DLL to access another 
DLL's data segement, was if the first DLL's data was copied to shared memory.

I still was able to workaround the problem by copying the pointer arrays into dynamically
allocated memory, in which case, they go into memory allocated off the heap of the client, 
not statically declared globals, so actually we don't need the shared memory after all.

However, in this configuration, each application instance which is a client of the DLL, 
will have it's own copies of the function pointers, using the shared memory scheme,
there is only one copy.  Another potential difficulty is if those pointers were ever to be 
altered at runtime, then we would have a problem.  Right now, it works.

--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.