*********** REPLY SEPARATOR ***********
On 9/11/2001 at 2:05 AM xiphmont@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@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.