Vorbis dev - Sep 2001 - Problems trying to run the examples in windows v orbis sdk

Yes, it works now. 
Thank you very much.

-----Original Message-----
From: Chris Wolf [mailto:cwolf@starclass.com]
Sent: 05 September 2001 10:12
To: vorbis-dev@xiph.org
Subject: Re: [vorbis-dev] Problems trying to run the examples in windows
vorbis sdk

On 9/4/2001 at 6:00 PM Pablos-Sanchez, Rolando wrote:
>I have just downloaded the vorbis sdk for windows, for researching
>purposes.
>
>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".
>Something about bad pointed pointers, I think.
>So I haven't been able to start testing yet. I have tried with static
link
>library and dynamic but nothing to do. 
>
>Then I have downloaded the source and I got the same problem, but now I
>know
>in which exact line the error is.
>Inside the vorbisenc.c, we have the following function:
>static void codec_setup_partialcopy(codec_setup_info *ci,
>codec_setup_info *cs){
>int i;
>memcpy(ci,cs,sizeof(codec_setup_info)); /* to get the flat numbers */
>/* codebooks */
>for(i=0;i<ci->books;i++){
>ci->book_param[i]=cs->book_param[i];
>}
>/* time backend settings */
>for(i=0;i<ci->times;i++){
>ci->time_param[i]=_time_P[ci->time_type[i]]-> // <---The error
is in this
>line
>copy_info(cs->time_param[i]);
>}
>...
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.

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

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

I have included vorbisenc.c in the vorbis DLL, and it is true that it
compiles and codes.
But now I have tried to decode and I got: "Input does not appear to be an
Ogg bitstream."
I have also vorbis for Linux, and both the encoder and decoder work. I can
even decode in windows a file encoded with the Linux encoder.
So there must be a problem in the windows encoder.  I don't know whether it
is because of moving the vorbisenc.c to vobis project or it just the coding
process in windows.

Thanks.

-----Original Message-----
From: Chris Wolf [mailto:cwolf@starclass.com]
Sent: 05 September 2001 10:12
To: vorbis-dev@xiph.org
Subject: Re: [vorbis-dev] Problems trying to run the examples in windows
vorbis sdk

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.

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

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

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

Chris

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

>	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]);
>		  */
>	  }
In Windows #pragma data_seg(".some_name") does indeed name the segment
but
it no longer makes it globally accessable as in 3.x.  In 3.x you could also
create static data segments that would achieve the same purpose, but no
longer.  In Windows there no longer is any compiler method that will let you
share memory between processes as it is now illegal for a process to access
memory outside of it's data segments.  Attempting to do so will cause an
access violation.  Obviously this is a kick in the teeth for cross platform
compatibility as the only way that memory can be shared is in a non-standard
programmatical method.

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

If DLL 'B' has an explicit call to DLL 'A', DLL 'A' will
always be loaded
first even if the application initially calls DLL 'B'.

DLL's always get loaded in a 'Bottom up' fashion, where if
'A' calls 'B'
calls 'C' they will get loaded in the order 'C' B'
'A'.

Chris

-----Original Message-----
From: Chris Wolf [mailto:cwolf@starclass.com]
Sent: Thursday, September 06, 2001 5:45 PM

Ok, I added file mapped shared memory and copied the backend mapping
function pointers from vorbis.dll into it.
I was able to successfully see vorbisenc.dll invoke a function from a
pointer in shared memory,
pointing into vorbis.dll.

The question is this.  If DLL 'A' initializes the shared memory upon
which
DLL 'B' is dependent,
what insurance is there that A gets loaded before B? (and thus A's DllMain
getting called before B's DllMain)
It just so happens, that in my case, vobis.dll gets loaded before
vorbisenc.dll.  I'd like to avoid explicit loading.
(I guess I could have B load then unload A, if I really had to...)

Oh, and BTW, we don't need inter-process access here -- the same process
loads the two DLL's.

        -Chris

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