[vorbis-dev] new DLL additions in core libs

[Monty]

> I agree, those win32-specific modules should be moved to the win32 directory.

OK.  Apologies for the strong wording as we're in agreement.

> I did not proceed until there was some discussions here first.  The conclusion
> was that this technique was the only way to alleviate the problems with
> the shared library mechanism of win32, i.e. the inability of one DLL to access
> another DLL's data segment.
> 
> In registry.c, there are a number of statically initialized structure arrays.  This code
> ends up in a library called "vorbis". Then, there is code in vorbisenc.c which makes
> references to those structure arrays defined in registry.c, which is in "vorbis".
> 
> The problem is that the object code for vorbisenc.c goes into it's own library, called "vorbisenc".
> So now we have a scenario where code in "vorbisenc" is trying to access the
> data segment of "vorbis", which believe it or not, is not allowed by default in windows.

[...]

Ahhh... the things I missed on vacation. OK.  I understand the nature
of the problem now.

> I tried all the other less drastic tricks first:
> 
> 1.) Declaring the array names in the module definition file.
> 2.) Bracketing the definition of those arrays in a named data segment, then adding a segment
>      modifier in the module definition file and declaring the segment as type "SHARED".
> 
> Apparently the above two steps used to work, back in  Windows 3.x days.
> 
> The bottom line is that for one DLL to access another's data segment, you must
> put those refer-to items in a shared memory segment.  I know it's a ridiculous
> architecture, but I think this is the best we can do for the windows version.
> 
> How about this:  I move the win32-specific code, i.e. dllamin.c, shmmap.h, shmmap_c.h
> into a place under the "win32" subdirectory.  But keep the single conditional include
> at the bottom of registry.c, and the conditional redefinitions at the top of vorbisenc.c?

That's acceptible if necessary...  My main concern now is not for the
cleanliness of your workaround, but rather that maintaining the
current code structure given this limitation of win32 is causing an
inordinate amount of trouble.  I'd rather find some way to restructure
how vorbis/vorbisenc are manipulating the static data in order to save
you all this trouble to begin with.  That seems like the correct,
cleanest solution.

Monty

--- >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.