Question

im creating a dll in MS Visual Studio 2010 Express which loads a binary data file (*.mgr extension -> used exclusively in my company’s applications) using fstream library in C++. The file is created with an app developed by someone else in my company who is using Delphi. He says the first 15 bytes should be some characters which indicate the date the file was created and some other stuff like version of the app:

“XXXX 2012”.

The result after loading with fstream (in binary mode) and writing another file with fstream (string mode) is as follows:

“[] X X X X 2 0 1 2”

The first char is an unknown char (rectangle) then there are spaces between each char. Finally it is 31 bytes wide. 15 for actual chars + 15 for white spaces + 1 for the rect char = 31.

Some other information:
I’m using C++, the app developer is using Delphi.
Im using fstream. he is using BW.Write() function. (BW == Binary Writer?)
He uses Windows 7 whilst i use Windows XP Professional.

Can you make a diagnosis of the problem?

Thanks in advance

First Edit: I’m adding c++ code that loads those first bytes.

Firstly he is using Delphi XE2 from embarcadero Rad Studio XE2.

From what i know PChar is a null-terminated string consisting of widechars (since delphi 2009) which are 2 bytes wide as opposed to normal chars (one byte). So basically he’s saving words instead of bytes.

here is the code loading the mgr:

wchar_t header[15];
DXFLIBRARY_API void loadMGR(const char* szFileName, const char* szOutput)
{
fstream file;
file.open( szFileName, ios::binary | ios::in );
if(file.is_open()) 
{
    file.read(reinterpret_cast<char*>(header),sizeof(header));
}
file.close();

//zapis

fstream saveFile;
saveFile.open( szOutput, ios::out );
if(saveFile.is_open())
{
    saveFile.write(reinterpret_cast<const char*>(header),sizeof(header));
}
saveFile.close(); 
}

Header contains 15 wchar_t’s so we get 30 bytes. Still after investigating i have no idea how to convert.

Answer 1

It seems pretty clear that somewhere along the way the data is being mangled between an 8 bit text encoding and a 16 bit encoding. The spurious first character is almost certainly the UTF-16 BOM.

One possible explanation is that the Delphi developer is writing UTF-16 encoding text to the file. And presumably you are expecting an 8 bit encoding.

Another explanation is that the Delphi code is correctly writing out 8 bit text, but that your code is mangling it. Perhaps your read/write code is doing that.

Use a hex editor on the file output from the Delphi program to narrow down exactly where the mangling occurs.

In the absence of any code in the question, it’s hard to be more specific than this.