dxg@cai.com (05/15/91)
First some info: I am using MS-C 6.0a and MS-C 3.0a.
I am calling a function from a .exe that is in a DLL. This
function does an fopen() and then returns a FILE *. Within the DLL
I am able to fprintf() to the file, but when I try to call
fprintf() from my .exe it fails, with the following pop up box
in CodeView: Trap 13 (0DH) - General Protection Fault
Am I doing something wrong or is impossible to call fopen() from within
a DLL and return the FILE * to the exe?
basic function in DLL:
FILE *my_fopen( char *psFileName, char *psMode )
{
FILE *pFile;
pFile = fopen( psFileName, psMode );
if( pFile != NULL )
fprintf( pFile, "\n This works in the DLL" );
return( pFile );
}
basic function in .exe called from WinMain():
int my_func()
{
FILE *pFile;
pFile = my_fopen( "file.tmp", "w" );
if( pFile != NULL )
{
fprintf( pFile, "\n This does not work!, get CVW pop up box!" );
fclose( pFile );
}
}
The examples above may have syntax errors, but they should help
your understanding of my problem.
I do not get the chance to read news that often, so please mail me
your responses.
Many many thanks in advance.
--
Dean Grammas..............................................dxg@cai.com
"All I ask is a chance to prove that money can't make me happy."
.....................................................................bonneau@hyper.hyper.com (Paul Bonneau) (05/17/91)
In article <394.28314261@cai.com> dxg@cai.com writes: > >First some info: I am using MS-C 6.0a and MS-C 3.0a. > >I am calling a function from a .exe that is in a DLL. This >function does an fopen() and then returns a FILE *. Within the DLL >I am able to fprintf() to the file, but when I try to call >fprintf() from my .exe it fails, with the following pop up box >in CodeView: Trap 13 (0DH) - General Protection Fault > The problem is that the FILE * is based on the data segment of the DLL. When you pass it to the app, it does not correspond to any stdio buffer of the app. If you pass it back from the DLL as a FILE FAR *, you will have to use the large model versions of the stdio routines. This can mean some mucking around with the lib utility (to extract the stdio routines into .obj files) if your app's model is not large. cheers - Paul Bonneau.
dxg@cai.com (05/17/91)
In article <394.28314261@cai.com>, dxg@cai.com writes: > > First some info: I am using MS-C 6.0a and MS-C 3.0a. and we are doing our Windows development using the Large Memory Model. I am new to the DOS world, (UNIX is my original home) so this near/far pointer stuff is new to me. Nevertheless, my understanding is that with the Large Memory Model, everything is a far pointer. > > I am calling a function from a .exe that is in a DLL. This > function does an fopen() and then returns a FILE *. Within the DLL > I am able to fprintf() to the file, but when I try to call > fprintf() from my .exe it fails, with the following pop up box > in CodeView: Trap 13 (0DH) - General Protection Fault > > Am I doing something wrong or is impossible to call fopen() from within > a DLL and return the FILE * to the exe? > Or, should I call _lopen() and then the MS-C routine fdopen() to get my FILE *, or is there something else that I should do? Again, please mail me your responses, as I do not get to read news that often. Thanks again, -- Dean Grammas..............................................dxg@cai.com "All I ask is a chance to prove that money can't make me happy." .....................................................................
Christian_Kaiser@f7220.n241.z2.fidonet.org (Christian Kaiser) (05/19/91)
> First some info: I am using MS-C 6.0a and MS-C 3.0a. No: I assume you use MS-Win 3.0a. MSC 3.0 would be too old... > I am calling a function from a .exe that is in a DLL. This > function does an fopen() and then returns a FILE *. OOOOOOOOOps. As far as I see, you made a lot of questionable things... First of all, the FILE * in the my_fopen() is on the stack, so it will be overwritten when you use the stack next time (calling fprintf), and that will cause BIG trouble. So make the FILE * a static variable. Second, you should declare all pointer parameters in combination with DLLs as FAR. So it should be FILE FAR *my_fopen(LPSTR psFileName, LPSTR psMode) that'll avoid the rest of your problems... > Am I doing something wrong or is impossible to call fopen() from within > a DLL and return the FILE * to the exe? Of course you can. Just remember: - declare pointers as far (remember 'CS != SS') and - variables as static if they are used outside the function where they are declared (the FILE * in this case) Ok? Bye! Christian
Thomas_Neumann@p4.f5800.n241.z2.fidonet.org (Thomas Neumann) (05/23/91)
> so this > near/far pointer stuff is new to me. Nevertheless, my > understanding > is that with the Large Memory Model, everything is a > far pointer. Yes, in large model every pointer is a far pointer, but be aware that this is not sufficent for pointer arithmetic like it is done on linear addressed machines ! The (far) pointers in large memory model do *not* behave correct on segment wraparounds. Just in case you didn't already know... bye, Thomas
Thomas.Neumann@sunbrk.FidoNet.Org (Thomas Neumann) (05/24/91)
Reply-To: Thomas_Neumann%p4.f5800.n241.z2@hippo.dfv.rwth-aachen.de (Thomas Neumann) > so this > near/far pointer stuff is new to me. Nevertheless, my > understanding > is that with the Large Memory Model, everything is a > far pointer. Yes, in large model every pointer is a far pointer, but be aware that this is not sufficent for pointer arithmetic like it is done on linear addressed machines ! The (far) pointers in large memory model do *not* behave correct on segment wraparounds. Just in case you didn't already know... bye, Thomas * Origin: Seaeast - Fidonet<->Usenet Gateway - sunbrk (1:343/15.0)