using win32 api for handling files vs. fstream

They have two different philosophy with a certain area of overlap.

fstream implements the "concept" of C++ stream when the data flow are directed to files.
It does so by cooperating with a number of other classes like strembuff and locales, whose defaults do almost nothing, but you can replace in modular way.

Win32 API are the surface of the "iron" that the operating system drives.
They provide their own a number of "features", many of them are used internally by the fstream implementation, some are almost transparently (apart some name changes) re-exposed at the C++ level, some other are left unused.

Consider also that many of the API are not even "windows" but "file system" related and can have limited functionality on certain file system respect to other (FAT has less attributes than NTFS, for example)

So, if you have to manage file system related attributes probably the native API are more suitable (C++ models are not interested in that), if you have to control the way data are written/read fstream is probably much suitable.

Consider also that -even if fstreams can be binary- they are naturally text oriented converters, while native API are binary oriented bulk movers.

thanks a lot, so there isn't much diffrence when developing for windows.
or are there any limitations using any method? such as security options available on one but not on the other, or limitations on file size? are ther opertions that are very easy to implement using one way, but are much more difficult in the other? is the best practice for developing on windows to use the win32 api?

I can find the same terms (for example: HANDLE) by reading of
- a WIN32 API documentation
- a Task Manager report

:)