You have two files involved are they both opened in Binary?
Tim S.
Printable View
EVOEx: You're not understanding at all. Of course the files aren't the same on both Linux and Windows. I've already stated that the Windows data is BROKEN and that I'm trying to find a way to fix it. After so many replies into the topic, I realized that Quzah was saying that the 0A Bytes are read as 0D 0A because of how Windows handles text. What I was saying is that the same source code was the only data that was the same. Also, the pseudo-code was given just to better illustrate the problem after people got confused when I posted the true data. It appears I just need a fix for the 0A to 0D 0A problem.
stahta01: Files are being opened in binary mode, yes. As can be seen in these code snippets:
Code:portfrom=fopen(portfromentry,"r+b");
portto=fopen(porttoentry,"r+b");
displaylist=fopen("temp1.zmuffin","w+b");
vertexdata=fopen("temp2.zmuffin","w+b");
texturedata=fopen("temp3.zmuffin","w+b");
They are opened now that way, but were they opened then that way?
Now = when you have the current data you are trying to magically fix.
Then = when the files were actually created.
Also, how did you get them from one machine to another? Did you ftp them over in text mode, or binary mode? Did you create it from scratch over again on the other computer?
What matters now is how you plan on fixing it (and what you do with it in the future). Why don't you just re-copy the data back over correctly from your *nix machine?
Quzah.
Previously, they were worked with in a Hex Editor, so they were most likely in Binary Mode at that time, too. The data that the program is reading is straight from video game files, of course.
Even though I've been using a Windows compiler under Wine, I have had an actual Windows user compile it and get the same issue. The video game files are being downloaded via a website.
My current plan for fixing it is to...
> Call eight more byte variables.
> When data is grabbed, write them to a temporary file.
> Go back eight bytes and grab the bytes written to the temporary file. Compare to the original eight bytes and delete the one that is different.
That is my concept of a workaround for the 0A to 0D 0A problem. However, when writing the contents of the temporary file to the video game file itself, this can't be done because deleting a byte would offset the rest of the data in the file.
Is there a way to simply write the contents of one file to another without having to take risks with a loop that grabs a byte from the temporary file and writes it to the final file until complete? The way Windows parses bytes keeps me from doing this part.
"The way Windows parses bytes keeps me from doing this part."
It's not so much how Windows parses bytes, as how you are telling Windows to parse bytes. If you get a "clean" copy of your data, and never touch it except in binary mode (which your hex editor may or may not do, and it wouldn't completely surprise me if it didn't, and something like Notepad would certainly not do), then you won't have a problem.
I'm re-downloading the files and doing this with perfectly clean data each time. Besides, when a file is opened in binary mode, Windows should be told to treat it as binary. Ohh well.
If this were true, we wouldn't be having this discussion. Have you checked a downloaded-but-otherwise-unmessed-with Windows file with a downloaded-but-otherwise-unmessed-with *nix file with file sizes (and maybe checksums)? (I'm assuming that all your files, even if differing from person to person or run to run, are all the same size. If you can use just one file on both systems, that would be superb.)
Once you make sure you have a clean copy, then open with "rb" and no transformations will happen.
I just had a Windows user try opening the file and copying it to and empty, fresh, new one. They still get the errors, even though the copy is 100% clean and not modified from what is found in the game.
So it's not actually you who is testing your code.What does that even mean?What does that even mean? What error? Doing what?Quzah.Code:#include<stdio.h>
int main( void )
{
FILE *fp1, *fp2;
fp1 = fopen( "mywindowsfile", "rb" );
fp2 = fopen( "myunixfile", "rb" );
if( fp1 && fp2 )
{
int c1, c2;
while( (c1 = fgetc( fp1 )) == (c2 = fgetc( fp2 )) && c1 != EOF )
;
printf( "Your files are %sdifferent.\n", c1 == c2 ? "not " : "" );
fclose( fp1 );
fclose( fp2 );
}
return 0;
}
I'm testing my code. It works flawlessly for me. For people on Windows, though, after so many bytes are read, the data starts getting screwy and eventually just becomes FF FF FF FF Bytes (NULL). I'm sensing there is a trick behind it, like how you need to use fflush(stdin); each time you use a getchar(); statement. Something similar may be needed here. I actually tested creating a file full of seemingly random bytes for the Windows user to test. When they ran the program, even though there were a few 0A Bytes in the first twenty or so bytes, they didn't transform into 0D 0A, so it has to be something related to a statement that needs used with the fgetc(); statements.
I made a program similar to your file compare program yesterday as well and had a Windows user test it. It only got one byte from each file at a time and it seemed to work for them. I can't modify the program to get just one byte at a time, though, because it checks them in an eight-byte-aligned mode, so I need to get eight at a time.
Also, opening the file and copying it would be opening the file in a hex editor, copying its data to an empty file, and saving as a new file. Having a clean, never opened file is a solution made by tabstop, who I thank for their support, but it didn't really change the output for Windows people.
Sorry if my words are confusing.
Actually, you should never use fflush(stdin). It's undefined behavior. fflush is only defined for output streams. Read about it here: Cprogramming.com FAQ > Why fflush(stdin) is wrong, and about some alternate solutions here: Cprogramming.com FAQ > Flush the input buffer.
What type is byte1 to byte8?
You need to check for end of file on input; why it works on Linux is unknown.
FF is likely the end of file indicator.
Tim S.
Go download this utility for Windows: WinMD5 Free - Windows MD5 Utility Freeware.
Get the md5sum of your "100% clean and not modified from what is found in the game" Windows file. Then on *nix, type the following at the command line: "md5sum /path/to/game/file". Make sure both files are fresh downloads. Paste the results of both into a new post on this thread for us to see. Dollars to doughnuts, your Windows and *nix files are different before you even open them.
Anduril462: Wow, thanks! I didn't know about that. I haven't used fflush(stdin); since I made simpler programs on Windows, but that is very useful to know.
Stahta01: I have them all stored in integer (int) form, even though I could use unsigned char, seeing how FF is the maximum for a byte, which is also the maximum of an unsigned char.
Anduril462:
The results follow.
Linux: 0431300f23001a4f19819a712db2608c
Windows: 0431300f23001a4f19819a712db2608c
Image Verification:
Linux.
Windows.
So can you post your latest code to try and read that file?
If you're using "rb" for your fopen() calls, it should be working the same.