[vorbis-dev] new DLL additions in core libs

[Chris Wolf]

*********** REPLY SEPARATOR  ***********

On 9/11/2001 at 2:05 AM xiphmont at xiph.org wrote:

>Chris, re the DLL additions:
>
>In a word, *no*. 
>
>That much Win32 specific code does not belong in a lib that's pure
>math and totally platform agnostic.  It may be appropriate, assuming
>it's necessary, to add this in the win32 specific SDKs, but it has no
>business in the core libvorbis.  Please move it out to a more
>appropriate place as soon as you possibly can.

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

>
>Secondly: I'd like to know the reasoning behind using shared memory
>segments.  It suggests there's a misunderstanding about how the
>libvorbis data is structured. Libvorbis should have nothing to do with
>the process and memory management you're setting up.

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

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