Fix incorrect CFile.hpp declarations

[nasiratif]

In the official Fusion SDK, DWORDs are used for some return types/parameters in the CFile APIs, but DarkEdif mistakenly replaced them with declarations as unsigned ints instead, causing linking errors and some runtime issues with some CFile functions.

[LB--]

Do you have examples of this? I've used uint32_t as a replacement for DWORD in the past without issues. In theory unsigned int should be the same type as those always when targeting 32-bit Win32, but it is poor practice to use raw primitives.

[nasiratif]

Do you have examples of this? I've used uint32_t as a replacement for DWORD in the past without issues. In theory unsigned int should be the same type as those always when targeting 32-bit Win32, but it is poor practice to use raw primitives.

The linking errors were caused by these functions particularly:

FusionAPIImport unsigned int	FusionAPI	File_GetPosition(HFILE hf);
FusionAPIImport unsigned int	FusionAPI	File_SeekBegin(HFILE hf, long pos);
FusionAPIImport unsigned int	FusionAPI	File_SeekCurrent(HFILE hf, long pos);
FusionAPIImport unsigned int	FusionAPI	File_SeekEnd(HFILE hf, long pos);

DWORD (what these functions are actually defined to return, per official SDK docs) is defined to be an unsigned long rather than an unsigned int, which I believe is what was causing the linking errors because they aren't technically the same primitive types.

As for the runtime issues, I was trying to use the CInputBufFile::Read functions, but Visual Studio gave me an ESP run-time check failure after the function was called, and the function seemingly did nothing. This also had unsigned ints being declared rather than DWORDs, so changing them back to DWORDs solved this issue and the function was finally working.