Printable View
hello frnds ,
i m in difficulty i have to read some information from msinfo32.exe or i copy msinfo32.exe containing information into some other file by c program , can any one sugget me how i proceed by an example
i tried to open it by fopen for reading but it is in binary so of no use
Of course it's in binary. All executables are binary. What were you hoping to see?
fopen has a binary modealso, use fread for binary reads.Code:fp = fopen(filename, "rb");
fopen is always binary mode (using 'b' is usually just a notational convention).
do you know if it ever has an effect?Quote:
Originally Posted by @nthony
I believe we had posts here just recently that say this is wrong.Quote:
Originally Posted by @nthony
http://cboard.cprogramming.com/showt...ht=binary+file
http://cboard.cprogramming.com/showt...ht=binary+file
I can't find the one I saw recently, where it was mentioned that some O/S's get touchy about how you open a file, whether in text or binary mode.
Edit: Found it. ;)
Post by brewbuck: http://cboard.cprogramming.com/showp...3&postcount=10
thanks MacGyver, :) but does anybody know what those differences are?
MSDN: fopen might be helpful.
Also, to clear things up, C Standards:
fopen
I/O Streams
clearly define that "b" shall have "no effect". So whatever effect an OS wants to put on it outside of the standards is not C's or fopen's fault (as brewbuck said). But, it is not exactly the OS's fault either as they usually should provide a function from their own API that supercedes the standard function they have altered, in which case you should be using this function instead if you want to avoid problems (as is the case with winAPI's CreateFile).
Well, the man page on my Linux box says this:
And I can't find anywhere in the C99 standards documentation that says the 'b' will have no effect. You have to be careful that you're not reading things that are written specifically for one environment and treating it as a global truth.Quote:
The mode string can also include the letter ``b'' either
as a last character or as a character between the charac-
ters in any of the two-character strings described above.
This is strictly for compatibility with ANSI X3.159-1989
(``ANSI C'') and has no effect; the ``b'' is ignored on
all POSIX conforming systems, including Linux. (Other
systems may treat text files and binary files differently,
and adding the ``b'' may be a good idea if you do I/O to a
binary file and expect that your program may be ported to
non-Unix environments.)
Ironically, thats exactly what you've done. You've used the Linux man page for a defintion of fopen. Like Windows, Linux is one of the OS's that have changed the standard implementation of the Unix fopen to suit their needs. The link I posted for fopen is the IEEE Unix standard, so I think thats pretty much as "global" as you're going to get.Quote:
Originally Posted by itsme86
Read what you just wrote. The IEEE Unix standard. Unix != Global.
The link that I provided is the actual ISO C99 standard, in which I could find no reference to the b flag not doing anything.
The Linux man page I quoted was just to contradict what you had said. The paragraph following the quote is where I linked to the real standard.
That's 2 strikes. Do you want to try for a 3rd?
Never mind, you are correct. Yes, I was citing the Unix standard for fopen, which incidentally is C99 compliant, so I mistook it as being synonymous with the C99 standard; however I neglected to realize that the Unix implementation of C can still be C99 compliant while still ignoring the 'b' character that C99 states "shall open a file as binary". The quip is that since Unix does not distinguish between "binary" and "text" mode it technically still fulfills the C99 requirements by accepting the premise that any occurence of "text file" can be replaced by "binary file" and vice versa in the following documentation:
Quote:
Originally Posted by ISO 9899:7.19.5.3