Windows Specific File I/O

I'm trying to make a small application that will read in a file, split it up and output each part to a different file. I'm trying to do this using Windows specific file I/O, and basically i'm completely lost. This is what i have so far:

Code:

#include <windows.h>
#include <iostream>

int main(int argc, char* argv[])
{
        const CHAR *file = "soeasy.mp3"; //This is hardcoded for now, ill change that when the rest works.

        HANDLE hfile = CreateFile(file, 
						GENERIC_READ, 
						0, 
						NULL, 
						OPEN_EXISTING, 
						FILE_ATTRIBUTE_NORMAL, 
						NULL);

	unsigned long file_length = GetFileSize(hfile, NULL);
	
	std::cout << file_length << std::endl;
	return 0;
}

In explorer the file "soeasy.mp3" is 3,66 MB. But the output i am getting is 3841925, is there something wrong with the code? And why doesn't the sizes match up?

After i've gotten the file size, i've got to allocate enough memory to read the filesize divided by the number of output files into memory, i'm guessing i have to use ReadFile() for this? Is there a difference between binary I/O and text file I/O with theese functions, like with fstream?

When should i call GetLastError()? After each of the function calls or? Anything else that i am forgetting?

3841925 bytes / 1024 = 3751.8798828125 KB
3751.8798828125 KB / 1024 = 3.66394519805908203125 MB

That seems about right. What are you expecting?

According to "calc":
3841925 / (1024 * 1024) becomes 3.66394519805908203125

So I guess Explorer is just rounding, and not very far off.

--
Mats

Originally Posted by Neo1

In explorer the file "soeasy.mp3" is 3,66 MB. But the output i am getting is 3841925, is there something wrong with the code? And why doesn't the sizes match up?

3.66 x 1024 x 1024 = 3837788.16, so I wouldn't say you're completely off track.
Plus I don't know if it returns the actual size on disk or the actual file size.

Originally Posted by Neo1

I'm trying to make a small application that will read in a file, split it up and output each part to a different file. I'm trying to do this using Windows specific file I/O, and basically i'm completely lost. This is what i have so far:

Code:

#include <windows.h>
#include <iostream>

int main(int argc, char* argv[])
{
        const CHAR *file = "soeasy.mp3"; //This is hardcoded for now, ill change that when the rest works.

        HANDLE hfile = CreateFile(file, 
						GENERIC_READ, 
						0, 
						NULL, 
						OPEN_EXISTING, 
						FILE_ATTRIBUTE_NORMAL, 
						NULL);

	unsigned long file_length = GetFileSize(hfile, NULL);
	
	std::cout << file_length << std::endl;
	return 0;
}

In explorer the file "soeasy.mp3" is 3,66 MB. But the output i am getting is 3841925, is there something wrong with the code? And why doesn't the sizes match up?

After i've gotten the file size, i've got to allocate enough memory to read the filesize divided by the number of output files into memory, i'm guessing i have to use ReadFile() for this? Is there a difference between binary I/O and text file I/O with theese functions, like with fstream?

When should i call GetLastError()? After each of the function calls or? Anything else that i am forgetting?

To read data, you use ReadFile(). AFAIK there is no difference between binary/text with ReadFile(). You are just reading bytes.

MSDN recommends that you use GetFileSizeEx() instead of GetFileSize().
I have used GetFileSizeEx() and it correctly reports the number of bytes in the file.

EDIT:

Heh see above too.

Originally Posted by sethjackson

To read data, you use ReadFile(). AFAIK there is no difference between binary/text with ReadFile(). You are just reading bytes.

No, that's not true. In text mode, newlines are translated into '\n', and bytes that represent the value of "end of file" are also picked up, thus prematurely setting EOF for a file. To read text files, use text mode; other files, use binary. This only applies to C/C++, however.
OpenFile/ReadFile does not have text/binary mode AFAIK.

Originally Posted by Elysia

No, that's not true. In text mode, newlines are translated into '\n', and bytes that represent the value of "end of file" are also picked up, thus prematurely setting EOF for a file. To read text files, use text mode; other files, use binary. This only applies to C/C++, however.
OpenFile/ReadFile does not have text/binary mode AFAIK.

Isn't that what he said?

Originally Posted by MacGyver

3841925 bytes / 1024 = 3751.8798828125 KB
3751.8798828125 KB / 1024 = 3.66394519805908203125 MB

That seems about right. What are you expecting?

Silly me, i was dividing by 1000 not 1024, so i guess the first part is fine. This is how it looks right now:

Code:

#include <windows.h>
#include <iostream>

int main(int argc, char* argv[])
{
	const unsigned int NumberOfOutputFiles = 3;
	unsigned long OutputFileSize = 0;
	const CHAR *File = "soeasy.mp3";
	char *pBuffer = NULL;
	HANDLE hFile = CreateFile(File, GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
	
	unsigned long TotalFileSize = GetFileSize(hFile, NULL);
	
	std::cout << "File size is: " << TotalFileSize << " bytes." << std::endl;
	
	OutputFileSize = TotalFileSize / NumberOfOutputFiles;
	pBuffer = new char[OutputFileSize];
	
	ReadFile(hFile, pBuffer, OutputFileSize, NULL, NULL);
	
	delete[] pBuffer;
	
	return 0;
}

This is giving me segfaults, how come? I can't locate any obvious memory leaks or anything in there?

Originally Posted by Elysia

No, that's not true. In text mode, newlines are translated into '\n', and bytes that represent the value of "end of file" are also picked up, thus prematurely setting EOF for a file. To read text files, use text mode; other files, use binary. This only applies to C/C++, however.
OpenFile/ReadFile does not have text/binary mode AFAIK.

Which is what I said no?

Originally Posted by MacGyver

Isn't that what he said?

Depends on how you see, I guess.
For Win32 there is no text/binary, so it makes no sense.
Then one could apply it to C/C++ where it does matter.
Just clearing it up I guess. Valuable information.

From MSDN:

http://msdn2.microsoft.com/en-us/lib...67(VS.85).aspx

"If lpOverlapped is NULL, lpNumberOfBytesRead cannot be NULL."

Code:

DWORD dwBytesRead;
    
ReadFile(hFile, pBuffer, OutputFileSize, &dwBytesRead, NULL);

Originally Posted by Elysia

Depends on how you see, I guess.
For Win32 there is no text/binary, so it makes no sense.
Then one could apply it to C/C++ where it does matter.
Just clearing it up I guess. Valuable information.

True. Sorry for the confusion....

Originally Posted by sethjackson

From MSDN:

http://msdn2.microsoft.com/en-us/lib...67(VS.85).aspx

"If lpOverlapped is NULL, lpNumberOfBytesRead cannot be NULL."

Code:

DWORD dwBytesRead;
    
ReadFile(hFile, pBuffer, OutputFileSize, &dwBytesRead, NULL);

This fixed the segfaults

True. Sorry for the confusion....

Why do you apologize, Elysia was the one that brought up standard C++, which has got nothing to do with anything in this thread really.

Originally Posted by Neo1

Why do you apologize, Elysia was the one that brought up standard C++, which has got nothing to do with anything in this thread really.

You are using C++, are you not? Then how does it have nothing to do with this thread?
I think you are the one who was confused at first, thinking about using binary or text.

One word of warning when dealing with HANDLEs. Apparently some functions that return a HANDLE return NULL to signify an invalid HANDLE, while some return INVALID_HANDLE_VALUE to signify the same thing. It's always important to always be sure to read the API documentation specifically and check to make sure you have a valid HANDLE returned from whatever specific function you use.

And on a side note, I don't think there was any any confusion in what Seth said, hence no need for an apology from him.

Originally Posted by Elysia

You are using C++, are you not? Then how does it have nothing to do with this thread?
I think you are the one who was confused at first, thinking about using binary or text.

He's using the Windows API for I/O, not C++'s standard I/O. He simply wanted to know if the Windows API was the same as C++'s fstream. I think that indicates he has an idea how that works.