• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

I develop on Windows but my question is may my C code be ported and EOF work on both

Onceler

Golden Member
I am writing a program that generates a file, will the EOF marker for Linux be readable on a Windows system and vise versa?
 
The EOF is a code that both file systems should recognize.

Now a *nx file may not be directly readable on a windows platform.
We used to have to send the files across TCP/IP between platforms back in the 90's. Unsure if that issue still exists
 
If your file is a text file, you may run into the CRLF/LF issue. This can be manually solved with the "unix2dos"/"dos2unix" programs. Otherwise you may want to check for an extra CR (Carriage Return) character in case you need to discard it.
 
it will be a binary file the object is to have it readable on both systems without the ctrl-z ctrl-d being a problem.
 
The EOF is a code that both file systems should recognize.

Now a *nx file may not be directly readable on a windows platform.
We used to have to send the files across TCP/IP between platforms back in the 90's. Unsure if that issue still exists

Sounds like you were curing an endian-ness problem by calling hton* on one side and ntoh* on the other. You were probably using a version of Unix that is big-endian. Windows and most versions of Linux on x86 architectures are all little-endian, so it shouldn't be an issue for most cases now.
 
Sounds like you were curing an endian-ness problem by calling hton* on one side and ntoh* on the other. You were probably using a version of Unix that is big-endian. Windows and most versions of Linux on x86 architectures are all little-endian, so it shouldn't be an issue for most cases now.

One reason why I specified the date - demonstrates aging 😳
Very few version of *nx existed at the time on a x86. we had SCO at the timeon a x86.
The files though were on some mainframe that were being used.

Would the Mac line have the same issue?
 
One reason why I specified the date - demonstrates aging 😳
Very few version of *nx existed at the time on a x86. we had SCO at the timeon a x86.
The files though were on some mainframe that were being used.

Would the Mac line have the same issue?

OS X on Intel is also little endian. OS X and earlier systems on power pc and Motorola architectures were big endian.
 
Last edited:
Back
Top