Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / July 2004

Tip: Looking for answers? Try searching our database.

CRITICAL:: DLLs from previous version of the compiler falis to redirect stderr:issue with CRT??

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
ndessai - 30 Jun 2004 15:09 GMT
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] - 30 Jun 2004 16:30 GMT
> Hi All,
>
[quoted text clipped - 29 lines]
> 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 - 01 Jul 2004 04:30 GMT
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

>>Hi All,
>>
[quoted text clipped - 42 lines]
>
> -cd
Carl Daniel [VC++ MVP] - 01 Jul 2004 06:42 GMT
> Thanks for the mail.
> Is there any work around by which I can meet my requirements.
[quoted text clipped - 6 lines]
> 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 - 02 Jul 2004 04:42 GMT
Hi Daniel,

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

Regards,
Navanath

>>Thanks for the mail.
>>Is there any work around by which I can meet my requirements.
[quoted text clipped - 14 lines]
>
> -cd
ndessai - 01 Jul 2004 04:30 GMT
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

>>Hi All,
>>
[quoted text clipped - 42 lines]
>
> -cd
ndessai - 01 Jul 2004 04:34 GMT
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

>>Hi All,
>>
[quoted text clipped - 42 lines]
>
> -cd
ndessai - 01 Jul 2004 04:44 GMT
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

>>Hi All,
>>
[quoted text clipped - 42 lines]
>
> -cd

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.