Thanks! I will try your solution. By the way, did you try DuplicateHandle
API? I am wondering that perhaps that might work as well but am not sure if
it is any different from dup.
Also, if I use fdopen to open standard file descriptors would it still work
if my application is starded by a command-line application?
Thanks!
-----Original Message-----
From: Kaptsenel, Dmitry [mailto:xxxxx@intel.com]
Sent: Thursday, October 31, 2002 2:14 AM
To: File Systems Developers
Subject: [ntfsd] RE: dup fails on windows 9x for stdout, stdin and stderr
I had the same problem. 95/98/ME performs initialization of stdout/err/in
descriptors only by demand (from inside of printf()) or if application was
started by other command-line application (so std file descriptors are
inherited). If your application was started by windows app on 95/98/ME, your
std file descriptors remains non-initialized. My solution was to open
standard file descriptors before _dup2() using _fdopen().
–
-----Original Message-----
From: Qasim Zuhair [mailto:xxxxx@Attachmate.com]
Sent: Thursday, October 31, 2002 11:12 AM
To: File Systems Developers
Subject: [ntfsd] dup fails on windows 9x for stdout, stdin and stderr
I am baffling with an issue for a while now and am hopeful that someone on
this board may be able to help me. It appears as a potential bug on Windows
98/95/Me.
The problem is that both _dup and _dup2 return -1 when I try to duplicate
stdin (0), stdout(1) and stderr(2). The errno indicates “Bad file
descriptor”.
It works just fine on Windows 2000/NT/XP.
Has anyone else seen this?
Thanks for the help!
You are currently subscribed to ntfsd as: xxxxx@attachmate.com
To unsubscribe send a blank email to %%email.unsub%%