[vorbis-dev] new DLL additions in core libs

[Kenneth Arnold]

On Wed, Sep 12, 2001 at 12:42:39PM -0700, Segher Boessenkool wrote:
> I think the cleanest (and most "correct") solution would be to separate
> libvorbis (and libogg) into separate encoding and decoding parts, and
> then to put the current libvorbisenc into the encoding part split off
> the current libvorbis.
> 
> Oops, that's quite a bit of work...

... and duplication of code. Many of the operations use similar
structures and share functionality; you'll see a few functions like
_vds_shared_init that just get a flag indicating whether it is encode
or decode, and do mostly the same thing in either case. I'm not sure
exactly how much code actually works like that.

You're sure that you can't have a function that returns a pointer to
the shared area? I guess that would accomplish the same thing as
adding the array to the symbol table, which apparently doesn't work. I
missed the earlier discussion about this but I gather that it has
something to do with the codebooks and modes; couldn't both of these
simply go in libvorbisenc? Failing that, whatever structures are
shared that are the issue could have an associated function to copy
the data into a shared memory area -- but I don't really get why Win32
imposes this limitation in the first place. Libraries should be able
to access a static variable from an application if it is passed as a
pointer; why not another library? Or am I mistaken and pointers would
work? Or am I just too clueless about win32 to be talking at all?


-- 
Kenneth Arnold <ken at arnoldnet.net> / kcarnold / Linux user #180115
http://arnoldnet.net/~kcarnold/



<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010912/4480cb55/part.obj