Archived

This topic is now archived and is closed to further replies.

File I/O with the API

This topic is 5752 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How do I do file I/O with Win32 API functions? I Googled and all I could find was DOS tutorials. Now correct me if I''m wrong, but DOS I/O function won''t work in the Windows environment right? Thanks. -AJ C:\DOS C:\DOS\RUN RUN\DOS\RUN -Comic Book Store Guy''s t-shirt that I saw on the Simpsons, although it didn''t actually come from the Simpsons. http://vdsoft.netfirms.com/home.html

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
why would you WANT to use the win32 api file functions?

Share this post


Link to post
Share on other sites
If by "DOS" you mean fopen and the such, they will work in Win32 since they most likely are implemented as Win32 calls anyway. But Win32 has so much more cool stuff you can do to the files! You need CreateFile, ReadFile, WriteFile and CloseHandle. Also check out the Ex versions of those functions, and CreateFileMapping, MapViewOfFile, and UnmapViewOfFile.

Share this post


Link to post
Share on other sites
Hey, I don't have a clue when it comes to file i/o in windows. Wanna try suggessting an alternative approach instead? I really would appreciate posts that would actually help me solve my problem. If you're not gonna help, why post? The least you could've done was criticize my choice of i/o method constructively. Anyone else care to give it a shot? Thanks.

-AJ

Edit: This was directed at Anonymous, not IndirectX

C:\DOS
C:\DOS\RUN
RUN\DOS\RUN

-Comic Book Store Guy's t-shirt that I saw on the Simpsons, although it didn't actually come from the Simpsons.

http://vdsoft.netfirms.com/home.html

[edited by - redneckCoder on April 17, 2002 12:41:06 AM]

Share this post


Link to post
Share on other sites
fopen, fread, fwrite, fputs, <fstream>, fprintf all should work in Win32. I thought you were looking for Win32 fun.

edit: HTML.

[edited by - IndirectX on April 17, 2002 12:44:20 AM]

Share this post


Link to post
Share on other sites
Never use any platform-specific API unless you have to. In other words, use fopen, fprintf, fwrite, and the rest, (include stdio.h in C or cstdio in C++) unless you have some good reason otherwise.

Share this post


Link to post
Share on other sites
quote:
Original post by merlin9x9
Never use any platform-specific API unless you have to.

Yeah, right. Try implementing file mapping objects or async io or completion ports in straight C++.

Share this post


Link to post
Share on other sites
quote:
Original post by IndirectX
Yeah, right. Try implementing file mapping objects or async io or completion ports in straight C++.

Did he say that the standard library could do everything? No. He said use the standard library for what it could do.

Share this post


Link to post
Share on other sites
quote:
Original post by IndirectX
Didn''t I list a bunch of standard library functions as well?

I fail to see what this has to do with what Merlin or I said.

Share this post


Link to post
Share on other sites
MSDN online - Here is the link:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/files_intro_4hwl.asp

If you are concerned about portability outside of Windows you should use something in the standard library. The other option, would be to create a platform layer or interface and hide the implementation accordingly. As a warning though, IndirectX is right - memory mapped files, async, etc - using stdio is not trivial. So if you do create an interface and decied to support that functionality outside of windows you are in for some work.

Hope that helps..
#dth-0

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:

Never use any platform-specific API unless you have to. In other words, use fopen, fprintf, fwrite, and the rest, (include stdio.h in C or cstdio in C++) unless you have some good reason otherwise.



Wrong. If he knows he is going to be developing for the Win32 Api and the Win32 Api alone, then there is no reason not to use those functions which are provided with that API.

Not everyone wants to be a cross-platform developer so if you know you''re going to be developing for a specific API why not use the functions provided by that API? Why re-invent the wheel?

In any case, back to the original question.

You''re going to want to look into the API functions CreateFile(), ReadFile(), and WriteFile() .



Share this post


Link to post
Share on other sites
quote:

If he knows he is going to be developing for the Win32 Api and the Win32 Api alone, then there is no reason not to use those functions which are provided with that API.



Wrong. Or, rather, this is a matter of opinion. I think it''s stupid to lock yourself into a particular API when a standard API does what you need it to do. For instance, let''s say that you need to concatenate and compare strings. You could use CString or std::string, and both would work equally well. Why needlessly bind yourself to MFC with CString? It''s the same case—most likely—with the Win32 API file functions and those of the C (or C++, for that matter) standard library. If, say, he just needs to open a file, write some text to it, why use the Win32 API (and this ignores that the Win32 API functions are usually pure overkill for such things).

Let''s say, for the sake of argument, that you agree with this logic. You can make yourself feel even better about it when you consider that although you "know" that you''re targetting x, you may someday change your mind. What about code reuse? You might decide that a particular routine is great and want to reuse it. That would be less than trivial if you hadn''t used the standard library or similarly platform-neutral library. Think about it.

Share this post


Link to post
Share on other sites