[vorbis-dev] Problems trying to run the examples in windows v orbis sdk

[Chris Wolf]

I merged these changes into the head revisions of the effected files.
(vorbis/lib/resistry.c, vorbis/lib/vorbisenc.c)  Dynamic linking should now
work on win32.  There are no changes to the Linux build.

   -Chris

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

On 9/5/2001 at 3:04 PM Chris Wolf wrote:

>On 9/5/2001 at 9:45 AM Chris Parsons wrote:
>
>>> On 9/4/2001 at 6:00 PM Pablos-Sanchez, Rolando wrote:
>>> 
>>> >I have compiled the example 'encoder_example.c' just to start, and it
>>> >compiles, but I got a error in the following line just at the
>>beginning: 
>>> >vorbis_encode_init(&vi,2,44100, -1, 128000, -1);
>>> >The error is more or less: The instruction at '0xaddresss' referenced
>>> >memory at '0xaddress'. The memory could not be "read".
>>> 
>>> The work around for this problem is to include vorbisenc.c in the vorbis
>>DLL and not have a
>>> separate, stand alone vorbisenc.dll.  If you do this, then this problem
>>disappears.  Obviously,
>>> since the vorbisenc code is quite large, and a lot of applications will
>>only be decoding, this
>>> is not a permenent solution.
>>> 
>>> This may have to do with how global data is treated in DLLs, which is
>>that
>>each client gets a 
>>> fresh instance of the global data.  The problem seems to be accessing
>>_time_P accross DLLs
>>> (vorbisenc.dll accessing _time_P in vorbis.dll)  I'm thinking of trying
>a
>>named data segment.
>>
>>
>>That is exactly what the case is.  There is only a couple of ways to
>savely
>>access global data across DLL's in Windows, probably the safest is to use
>>CreateFileMapping() with a named memory space.  This way if the space was
>>already created by a previous instance of the DLL it will open that space
>>and not create a new one.  It used to be possible to pass global pointers
>>across DLL's in Windows 3.x and to some extent with Win 9x, but it's more
>>or
>>less down right illegal in Win NT x.  It is legal however for a memory
>>space
>>allocated with GlobalAlloc to be passed to the calling application (or
>DLL)
>>by handle.
>
>Isn't it true that if you bracket global definitions with
>#pragma data_seg(".some_name")
>...
>#pragma data_seg()
>
>...that those globals become sharable a' la 3.x DLL's?  In any case, I
>tried it and it didn't help.
>
>>From the debugger, I can access the address of _time_P, which is a global
>inside vorbis.dll (I also have it exported in the module definition file) 
>I can even access the first element
>of this pointer array, but when a try to dereference one of the function
>pointers, it blows up. 
>
>Here's what I tried  (vorbisenc.c):
>
>  /* time backend settings */
>  for(i=0;i<ci->times;i++)
>  {
>      int vit = ci->time_type[i];
>      vorbis_func_time *data = _time_P[vit];                              
>   // this succeeds
>
> //    void *(*copy_info)(vorbis_info_time *) = _time_P[vit];             
>// access violation
> //    void *(*copy_info)(vorbis_info_time *) = data->copy_info;        //
>access violation
>//     void *(*copy_info)(vorbis_info_time *) = time0_copy_info;       //
>this succeeds
>//     void *(*copy_info)(vorbis_info_time *) =
>time0_exportbundle.copy_info; // this succeeds
>
>      ci->time_param[i] = copy_info(cs->time_param[i]);
>    /*
>    ci->time_param[i]=_time_P[ci->time_type[i]]->
>      copy_info(cs->time_param[i]);
>      */
>  }
>
>
>
>--- >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.

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