473,379 Members | 1,216 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,379 software developers and data experts.

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

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

Nov 17 '05 #1
7 1172
ndessai wrote:
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
Nov 17 '05 #2
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] wrote:
ndessai wrote:
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


Nov 17 '05 #3
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] wrote:
ndessai wrote:
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


Nov 17 '05 #4
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] wrote:
ndessai wrote:
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


Nov 17 '05 #5
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] wrote:
ndessai wrote:
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


Nov 17 '05 #6
ndessai wrote:
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
Nov 17 '05 #7
Hi Daniel,

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

Regards,
Navanath

Carl Daniel [VC++ MVP] wrote:
ndessai wrote:
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


Nov 17 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

77
by: Charles Law | last post by:
Hi guys I have a time critical process, running on a worker thread. By "time critical", I mean that certain parts of the process must be completed in a specific time frame. The time when the...
14
by: tshad | last post by:
I am trying to set up a reusable library (business component) that I can use in a bunch of my pages. I built the file and it almost compiles, but I am not sure what I am missing. The vbc...
80
by: Charles Law | last post by:
Hi guys I have a time critical process, running on a worker thread. By "time critical", I mean that certain parts of the process must be completed in a specific time frame. The time when the...
83
by: Charles Law | last post by:
Hi guys I have a time critical process, running on a worker thread. By "time critical", I mean that certain parts of the process must be completed in a specific time frame. The time when the...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.