473,569 Members | 2,731 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

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 1187
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
functionali ty 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
functionali ty 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
functionali ty 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
functionali ty 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_HANDL E (and/or
STD_OUTPUT_HAND LE) 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_HANDL E (and/or
STD_OUTPUT_HAND LE) 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
4521
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 process starts is not especially important, but it must be complete within a small number of seconds. The operations I am performing do not take a...
14
1816
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 command and results are: ************************************************************************ C:\Inetpub\wwwroot\Development>vbc /t:library...
80
3411
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 process starts is not especially important, but it must be complete within a small number of seconds. The operations I am performing do not take a...
83
3059
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 process starts is not especially important, but it must be complete within a small number of seconds. The operations I am performing do not take a...
0
7698
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
0
8122
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7673
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
7970
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
1
5513
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
5219
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3653
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3640
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
0
937
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

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.