Author Topic: File IO  (Read 2315 times)

James Fuller

  • Newbie
  • *
  • Posts: 15
File IO
« on: May 26, 2016, 01:20:55 pm »
Mike & Patrice,
  A few questions for the experts.

  What methods do you use to for your binary file IO, CRT or WinApi and why.

  How do you handle text file IO.
    A. Do you always use ascii?
    B. Do you always use UNICODE?
    C. A mix of the above.

  Are most of the apps you write UNICODE or ascii?

  Thank you,

Patrice Terrier

  • Administrator
  • *****
  • Posts: 951
    • zapsolution
Re: File IO
« Reply #1 on: May 26, 2016, 02:12:04 pm »

In the case of ObjReader, the .MTL, the .OBJ, and the WinLIFT .SKS are always plain ASCII files.

However the C++ source code itself for ObjReader, GDImage, and WinLIFT is full UNICODE.

For example all GDIPLUS code is always using UNICODE while the deprecated GDI32 is still ANSI.

All file IO are based on the core API fscanf to read formatted data from stream.
And CreateFile to read from texture files.

However, remember that in C++ CreateFile is indeed CreateFileW when defined for UNICODE, and CreateFileA for ASCII.

And i am using MultiByteToWideChar to convert from ASCII to UNICODE (see the code below).

Code: [Select]
                hFile = CreateFile(zPath, GENERIC_READ, 0, NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
                memset(&zPath[0], 0, sizeof(WCHAR) * MAX_PATH);
                if (hFile != INVALID_HANDLE_VALUE) {
                    DWORD dwBytes = 0;
                    BYTE* buffer = new BYTE[nSize];
                    if (ReadFile(hFile, &buffer[0], nSize, &dwBytes, NULL)) {
                        MultiByteToWideChar(CP_ACP, 0, (LPCSTR) &buffer[0], nSize, zPath, MAX_PATH);
                        wcsncat_s(zMessage, zPath, _TRUNCATE);
                    delete [] buffer;
« Last Edit: May 26, 2016, 02:15:30 pm by Patrice Terrier »
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 777
Re: File IO
« Reply #2 on: May 26, 2016, 09:40:08 pm »
Hi James,

We have three parallel implementations of our Wavefront Obj viewers: in 64-bit C++ (called ObjReader64), 32-bit PowerBASIC (called ObjReader) that used to be taken historically as the C++ implementation prototype but is still maintained in working order, and 32-bit FBSL (called Objector).

Patrice has described file IO for ANSI (PB) and Unicode (C++) implementations. Please note that historically, .OBJ model files and .MTL material library files are expected to be written in ASCII as there's a lot of usable 3D software, both professional and indie, that wouldn't allow Unicode chars to be used in either those text files or texture/model/material file names. Hence the reduction of C++ Unicode capabilities to ANSI-only APIs in what concerns the model/material/texture file naming and input.

The FBSL implementation is built around the same concepts as Patrice's ObjReaders but uses a lot of different code solutions utilizing FBSL's built-in BASIC as well as its dynamic C and assembly jitters. FBSL is historically ANSI-only software though it does provide AnsiToWide() and WideToAnsi() built-in functions for handling the rare cases where Unicode would be a must as e.g. in constructing GDI+ string literals.
« Last Edit: May 26, 2016, 09:44:51 pm by Michael Lobko-Lobanovsky »
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)