BinaryWriter/BinaryReader Portability
-
Hello, Is the format used by BinaryWriter and BinaryReader portable for standard data types like string and uint? For example, suppose that one uses a BinaryWriter on a machine of type X to write to a NetworkStream, and the other end of the stream is running on a machine of type Y and uses BinaryReader to read from the NetworkStream. Suppose also that both machines are using programs written in C# and being executed by .NET. Will the reader get what was written, regardless of whether X and Y are different types of machines (possibly having different endianness)? (The BinaryWriter constructor allows one to specify an encoding. I would like to know whether the default encoding is portable in the way described above, and whether the other standard encodings are portable in this way.)
-
Hello, Is the format used by BinaryWriter and BinaryReader portable for standard data types like string and uint? For example, suppose that one uses a BinaryWriter on a machine of type X to write to a NetworkStream, and the other end of the stream is running on a machine of type Y and uses BinaryReader to read from the NetworkStream. Suppose also that both machines are using programs written in C# and being executed by .NET. Will the reader get what was written, regardless of whether X and Y are different types of machines (possibly having different endianness)? (The BinaryWriter constructor allows one to specify an encoding. I would like to know whether the default encoding is portable in the way described above, and whether the other standard encodings are portable in this way.)
In answer to your primary question, BinaryReader will read streams created by BinaryWriter correctly. Your question about endianness is meaningless at the present time because .NET only runs on Intel CPUs and hence you don't have to worry about it. Once Microsoft target .NET for other CPUs then, yes, the .NET Frameowrk team will have to worry about how the stream is created and used between different endian CPUs. Cheers, Julian Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
-
Hello, Is the format used by BinaryWriter and BinaryReader portable for standard data types like string and uint? For example, suppose that one uses a BinaryWriter on a machine of type X to write to a NetworkStream, and the other end of the stream is running on a machine of type Y and uses BinaryReader to read from the NetworkStream. Suppose also that both machines are using programs written in C# and being executed by .NET. Will the reader get what was written, regardless of whether X and Y are different types of machines (possibly having different endianness)? (The BinaryWriter constructor allows one to specify an encoding. I would like to know whether the default encoding is portable in the way described above, and whether the other standard encodings are portable in this way.)
Note also that the version of the assembly must be identical on both ends.
-
Note also that the version of the assembly must be identical on both ends.
Arun Bhalla wrote: Note also that the version of the assembly must be identical on both ends. Do you mean that the version of .NET that the assembly is using on both sides must be identical? Or do you mean that the version of the assemblies itself must be identical? If the latter this makes no sense because the assembly using BinaryWriter might be different from the assembly using the BinaryReader, e.g., there is a client/server relationship.
-
Arun Bhalla wrote: Note also that the version of the assembly must be identical on both ends. Do you mean that the version of .NET that the assembly is using on both sides must be identical? Or do you mean that the version of the assemblies itself must be identical? If the latter this makes no sense because the assembly using BinaryWriter might be different from the assembly using the BinaryReader, e.g., there is a client/server relationship.
Ooops, sorry I was thinking of BinaryFormatter & Serialization.
-
In answer to your primary question, BinaryReader will read streams created by BinaryWriter correctly. Your question about endianness is meaningless at the present time because .NET only runs on Intel CPUs and hence you don't have to worry about it. Once Microsoft target .NET for other CPUs then, yes, the .NET Frameowrk team will have to worry about how the stream is created and used between different endian CPUs. Cheers, Julian Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
Julian, Is there complete BinaryWriter/BinaryReader compatibility for all Microsoft .NET implementations and for all pairs of machines that Microsoft's .NET runs on? I tried to be explicit about this in the original post -- if the question is still not clear then I will try to make it clearer. I am looking for an explicitly-written answer that's more informative than, "Some BinaryReader objects can read what's written by some BinaryWriter objects." The endianness question is meaningful at present because there are different vendors, e.g., Microsoft and Mono, but even information only about Microsoft-to-Microsoft communication would be helpful. Also, it helps and is even necessary to have some idea of future capabilities. I do not want to release software only to find out in 3 months that a large class of users cannot connect to a server because BinaryWriter and BinaryReader are incompatible in some circumstances, e.g., .NET 2.0 (say) is using a format that is incompatible with .NET 1.0. In fact if this were to happen, then using BinaryWriter/BinaryReader would be painful for many client/server situations because there would be two different classes of users, e.g., many Windows XP users with .NET 1.0 and some other users who are using .NET 2.0. It would become necessary to somehow know in advance which version of the protocol to use, and to be able to use either version within a single assembly (the server). Andrew
-
Ooops, sorry I was thinking of BinaryFormatter & Serialization.
Ah. No problem.
-
Julian, Is there complete BinaryWriter/BinaryReader compatibility for all Microsoft .NET implementations and for all pairs of machines that Microsoft's .NET runs on? I tried to be explicit about this in the original post -- if the question is still not clear then I will try to make it clearer. I am looking for an explicitly-written answer that's more informative than, "Some BinaryReader objects can read what's written by some BinaryWriter objects." The endianness question is meaningful at present because there are different vendors, e.g., Microsoft and Mono, but even information only about Microsoft-to-Microsoft communication would be helpful. Also, it helps and is even necessary to have some idea of future capabilities. I do not want to release software only to find out in 3 months that a large class of users cannot connect to a server because BinaryWriter and BinaryReader are incompatible in some circumstances, e.g., .NET 2.0 (say) is using a format that is incompatible with .NET 1.0. In fact if this were to happen, then using BinaryWriter/BinaryReader would be painful for many client/server situations because there would be two different classes of users, e.g., many Windows XP users with .NET 1.0 and some other users who are using .NET 2.0. It would become necessary to somehow know in advance which version of the protocol to use, and to be able to use either version within a single assembly (the server). Andrew
Andrew I'm sorry, I see I wasn't being explicit enough . Any stream written with any existing BinaryWriter can be read by any existing BinaryReader. I can even confirm that fact with Whidbey's BinaryReader and Writer (that is, with .NET Framework 2.0). If it didn't then it's a bug. (So the 3D matrix of 1.0, 1.1, 2.0 frameworks, for the two layers of writers and reader combinations has ticks in every cell). That's the statement about Microsoft's .NET Framework. I know nothing about the Mono project (apart from what it is, of course). I have no idea whether their BinaryReader would always work with a stream createed with BinaryWriter. Similarly I don't know if a stream written by Mono's BinaryWriter would be readable with MS's BinaryReader. However, I would *guess* that the Mono people would have taken endianness into account when they were writing their reader and writer. Now, as to the future (beyond Whidbey): it would make sense for the .NET Framework team to make sure that BinaryReader and BinaryWriter can continue to work as before. Why? Because the ResourceManager uses BinaryReaders and Writers internally. And that would be bad if Visual Studio .NET X (for X>2) couldn't read resource files from existing projects. Also, the format used by BinaryWriter is very, very simple and easily reverse engineered. There's no wierdo enums or class names being put in there or stuff like that. An int is written out as 4 bytes, a double as 8, etc, etc. So, although neither I nor anyone else can really tell you what would happen five years down the road, I wouldn't worry about it. Cheers, Julian Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
-
Andrew I'm sorry, I see I wasn't being explicit enough . Any stream written with any existing BinaryWriter can be read by any existing BinaryReader. I can even confirm that fact with Whidbey's BinaryReader and Writer (that is, with .NET Framework 2.0). If it didn't then it's a bug. (So the 3D matrix of 1.0, 1.1, 2.0 frameworks, for the two layers of writers and reader combinations has ticks in every cell). That's the statement about Microsoft's .NET Framework. I know nothing about the Mono project (apart from what it is, of course). I have no idea whether their BinaryReader would always work with a stream createed with BinaryWriter. Similarly I don't know if a stream written by Mono's BinaryWriter would be readable with MS's BinaryReader. However, I would *guess* that the Mono people would have taken endianness into account when they were writing their reader and writer. Now, as to the future (beyond Whidbey): it would make sense for the .NET Framework team to make sure that BinaryReader and BinaryWriter can continue to work as before. Why? Because the ResourceManager uses BinaryReaders and Writers internally. And that would be bad if Visual Studio .NET X (for X>2) couldn't read resource files from existing projects. Also, the format used by BinaryWriter is very, very simple and easily reverse engineered. There's no wierdo enums or class names being put in there or stuff like that. An int is written out as 4 bytes, a double as 8, etc, etc. So, although neither I nor anyone else can really tell you what would happen five years down the road, I wouldn't worry about it. Cheers, Julian Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
Thanks Julian. That is just what I wanted to know. Andrew