CRITICAL:: DLLs from previous version of the compiler falis to redirect

[ndessai]

Hi All,

I discovered following issue with the VC 7.1 compiler regarding the
backword compatibility.

I created a dll (Redirect.dll) which exposes a function and simply
writes some text (say "Hello World") to stderr stream. I also created a
driver program (driver.exe) and used the exposed function from the above
dll. The driver.exe tries to redirect the stderr stream to a file
"stderr.txt" before calling the method from the dll. (used freopen here)
After calling the dll method it writes some text to stderr stream as
well (Say "Driver Hello World")

Now Please look at the observations below.

1. If I compile both exe and the dll either in VC6 or VC7 then the
messages appear either on the stderr(console) or the file depending on
whether it was redirected.

2. Now if I compile the dll in VC6 and the exe in VC7, I get the
messages successfully on the console(stderr stream) both from the dll
and the exe, when no redirection is done. The moment I redirect the
stderr stream to a file all messages from the exe get written to the
file but no message from the dll gets written to the file. No other
functionality is broken.

- One of the colution to the problem could be to recompile the dll with
the new compiler. But the limitation is many a times these dlls are a
part of SDK released by a third party.

Can anyone please tell me if there is any workaround to redirect the
messages written by the dll to a file?? Is this a know issue? Has anyone
faced this issue before?

Please let me know.

Thanks,
Navanath

 

[Carl Daniel [VC++ MVP]]

Hi All,

I discovered following issue with the VC 7.1 compiler regarding the
backword compatibility.

I created a dll (Redirect.dll) which exposes a function and simply
writes some text (say "Hello World") to stderr stream. I also created
a driver program (driver.exe) and used the exposed function from the
above dll. The driver.exe tries to redirect the stderr stream to a
file "stderr.txt" before calling the method from the dll. (used
freopen here) After calling the dll method it writes some text to
stderr stream as well (Say "Driver Hello World")

Now Please look at the observations below.

1. If I compile both exe and the dll either in VC6 or VC7 then the
messages appear either on the stderr(console) or the file depending on
whether it was redirected.

2. Now if I compile the dll in VC6 and the exe in VC7, I get the
messages successfully on the console(stderr stream) both from the dll
and the exe, when no redirection is done. The moment I redirect the
stderr stream to a file all messages from the exe get written to the
file but no message from the dll gets written to the file. No other
functionality is broken.

- One of the colution to the problem could be to recompile the dll
with the new compiler. But the limitation is many a times these dlls
are a part of SDK released by a third party.

Can anyone please tell me if there is any workaround to redirect the
messages written by the dll to a file?? Is this a know issue? Has
anyone faced this issue before?

This is a fundamental limitation - when you compile the DLL with VC6 and the
EXE with VC7{.1}, you have two different copies of the CRT each of which has
it's own table of "file handles". If you need to coordinate I/O between
modules compiled with different versions of the CRT (compiler), you'll need
to implement all of your I/O in terms of the base Win32 API (CreateFile,
WriteFile, etc).

The same situation will occur if you simply mix CRT versions with a single
compiler version (e.g. compile the DLL with /MD and compile the EXE with
/MT).

-cd

 

[ndessai]

Thanks for the mail.
Is there any work around by which I can meet my requirements.

The limitations on my side are the dll cannot be recompiled for the the
CRT since it is from third party. And I have moved my project to the new
compiler. Since the dll anyways prints all the messages to the console
screen, is there no way by which I can redirect it to a file without
changing the dll?

Please let me know.

Thanks,
Navanath

 

[ndessai]

Thanks for the mail.
Is there any work around by which I can meet my requirements.

The limitations on my side are the dll cannot be recompiled for the the
CRT since it is from third party. And I have moved my project to the new
compiler. Since the dll anyways prints all the messages to the console
screen, is there no way by which I can redirect it to a file without
changing the dll?

Please let me know.

Thanks,
Navanath

 

[ndessai]

Thanks for the mail.
Is there any work around by which I can meet my requirements.

The limitations on my side are the dll cannot be recompiled for the the
CRT since it is from third party. And I have moved my project to the new
compiler. Since the dll anyways prints all the messages to the console
screen, is there no way by which I can redirect it to a file without
changing the dll?

Please let me know.

Thanks,
Navanath

 

[ndessai]

Thanks for the mail.
Is there any work around by which I can meet my requirements.

The limitations on my side are the dll cannot be recompiled for the the
CRT since it is from third party. And I have moved my project to the new
compiler. Since the dll anyways prints all the messages to the console
screen, is there no way by which I can redirect it to a file without
changing the dll?

Please let me know.

Thanks,
Navanath

 

[Carl Daniel [VC++ MVP]]

Thanks for the mail.
Is there any work around by which I can meet my requirements.

The limitations on my side are the dll cannot be recompiled for the
the
CRT since it is from third party. And I have moved my project to the
new compiler. Since the dll anyways prints all the messages to the
console screen, is there no way by which I can redirect it to a file
without
changing the dll?

You might be able to use SetStdHandle to point STD_ERROR_HANDLE (and/or
STD_OUTPUT_HANDLE) to a file. I would think that that would catch I/O from
the DLL as well, but I don't have any way to test it in your environment.

If you try it, please post back with the results, good or bad.

-cd

 

[ndessai]

Hi Daniel,

Thanks for the suggestion. I had tried this earlier but to my dismay, it
did not work!!

Regards,
Navanath