Problem with a for() loop.

Printable View

06-04-2011
Flotonic

Problem with a for() loop.

Currently, in Linux, the for() loop I've written gives me no problems. However, when Windows users try working with it, the data get offset after so many times going around and they get thrown into an infinite loop. I'll show the for() loop, the data that a Windows user gets, and the data that I get from it.

The for() loop:

Code:

for( ; ; ) { byte1=fgetc(portfrom); byte2=fgetc(portfrom); byte3=fgetc(portfrom); byte4=fgetc(portfrom); byte5=fgetc(portfrom); byte6=fgetc(portfrom); byte7=fgetc(portfrom); byte8=fgetc(portfrom); fputc(byte1,displaylist); fputc(byte2,displaylist); fputc(byte3,displaylist); fputc(byte4,displaylist); fputc(byte5,displaylist); fputc(byte6,displaylist); fputc(byte7,displaylist); fputc(byte8,displaylist); if(byte1==0xDF && byte2==0x00 && byte3==0x00 && byte4==0x00 && byte5==0x00 && byte6==0x00 && byte7==0x00 && byte8==0x00) { break; } }

Windows User Data (this is cut off; the FFs keep being generated for infinity):

Code:

D7 00 00 02 03 E8 01 F4 E7 00 00 00 00 00 00 00 FC 12 16 04 5F FD FF F8 FA 00 00 FF 80 80 80 FF FB 00 00 00 00 14 50 FF E2 00 00 1C C8 11 20 78 E3 00 10 01 00 00 00 00 FD 90 00 00 06 00 0B 00 F5 90 00 00 07 05 01 41 E6 00 00 00 00 00 00 00 F3 00 00 00 07 07 F4 00 E7 00 00 00 00 00 00 00 F5 88 04 00 00 05 01 41 F2 00 00 00 00 03 C0 3C D9 00 00 00 00 2F 00 05 01 02 00 40 06 00 7D 28 06 00 02 04 00 04 02 06 06 04 08 0D 0A 00 06 08 04 06 0C 0E 10 00 0E 12 10 06 0E 14 12 00 0E 16 14 06 0E 18 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Linux Data (actual data):

Code:

D7 00 00 02 03 E8 01 F4 E7 00 00 00 00 00 00 00 FC 12 16 04 5F FD FF F8 FA 00 00 FF 80 80 80 FF FB 00 00 00 00 14 50 FF E2 00 00 1C C8 11 20 78 E3 00 10 01 00 00 00 00 FD 90 00 00 06 00 0B 00 F5 90 00 00 07 05 01 41 E6 00 00 00 00 00 00 00 F3 00 00 00 07 07 F4 00 E7 00 00 00 00 00 00 00 F5 88 04 00 00 05 01 41 F2 00 00 00 00 03 C0 3C D9 00 00 00 00 2F 00 05 01 02 00 40 06 00 7D 28 06 00 02 04 00 04 02 06 06 04 08 0A 00 06 08 04 06 0C 0E 10 00 0E 12 10 06 0E 14 12 00 0E 16 14 06 0E 18 1A 00 1C 0E 1A 06 0E 1E 18 00 0E 0C 1E 06 1E 20 18 00 1E 22 20 06 22 24 20 00 22 26 24 06 26 28 24 00 28 2A 24 06 2C 2E 26 00 2C 30 2E 06 2A 32 24 00 34 14 36 06 14 16 36 00 10 36 0C 06 10 34 36 00 2C 32 30 06 38 2C 22 00 2C 26 22 06 3A 38 1E 00 38 22 1E 06 3C 3A 36 00 3C 36 3E 06 3A 1E 36 00 1E 0C 36 D9 00 00 00 00 2F 04 05 06 10 12 14 00 10 14 34 E7 00 00 00 00 00 00 00 FB 00 00 00 8A 14 5A FF FD 90 00 00 06 00 0B 00 F5 90 00 00 07 05 01 40 E6 00 00 00 00 00 00 00 F3 00 00 00 07 07 F4 00 E7 00 00 00 00 00 00 00 F5 88 04 00 00 05 01 40 F2 00 00 00 00 03 C0 3C D9 00 00 00 00 2F 00 05 01 01 40 28 06 00 7B E8 06 00 02 04 00 00 06 02 06 08 06 00 00 0A 08 00 06 0C 0E 10 00 0E 12 10 06 0E 14 12 00 14 16 12 06 14 18 16 00 18 1A 16 06 12 1C 1E 00 12 16 1C 06 16 20 1C 00 16 1A 20 06 10 12 1E 00 10 1E 0C 06 18 22 1A 00 18 24 22 06 1A 26 20 00 26 24 20 DF 00 00 00 00 00 00 00

Is there a way to "free" variables each time during the loop that I don't know of? Thanks in advance!
06-04-2011
stahta01

Do you open the file in Binary Mode?
This is not needed under Linux; but, required under Windows.

Tim S.
06-04-2011
Flotonic

Code:

displaylist=fopen("temp1.zmuffin", "r+");

So I don't think I did. Mind elaborating about this "binary mode?"

EDIT:

Now binary mode is used. Example:

Code:

portfrom=fopen(portfromentry,"r+b");

However, the problem for Windows people still persists, but it's now closer than before. Any ideas now?

Code:

D7 00 00 02 03 E8 01 F4 E7 00 00 00 00 00 00 00 FC 12 16 04 5F FD FF F8 FA 00 00 FF 80 80 80 FF FB 00 00 00 00 14 50 FF E2 00 00 1C C8 11 20 78 E3 00 10 01 00 00 00 00 FD 90 00 00 06 00 0B 00 F5 90 00 00 07 05 01 41 E6 00 00 00 00 00 00 00 F3 00 00 00 07 07 F4 00 E7 00 00 00 00 00 00 00 F5 88 04 00 00 05 01 41 F2 00 00 00 00 03 C0 3C D9 00 00 00 00 2F 00 05 01 02 00 40 06 00 7D 28 06 00 02 04 00 04 02 06 06 04 08 0D 0A 00 06 08 04 06 0C 0E 10 00 0E 12 10 06 0E 14 12 00 0E 16 14 06 0E 18 1A 00 1C 0E 1A 06 0E 1E 18 00 0E 0C 1E 06 1E 20 18 00 1E 22 20 06 22 24 20 00 22 26 24 06 26 28 24 00 28 2A 24 06 2C 2E 26 00 2C 30 2E 06 2A 32 24 00 34 14 36 06 14 16 36 00 10 36 0C 06 10 34 36 00 2C 32 30 06 38 2C 22 00 2C 26 22 06 3A 38 1E 00 38 22 1E 06 3C 3A 36 00 3C 36 3E 06 3A 1E 36 00 1E 0C 36 D9 00 00 00 00 2F 04 05 06 10 12 14 00 10 14 34 E7 00 00 00 00 00 00 00 FB 00 00 00 8A 14 5A FF FD 90 00 00 06 00 0B 00 F5 90 00 00 07 05 01 40 E6 00 00 00 00 00 00 00 F3 00 00 00 07 07 F4 00 E7 00 00 00 00 00 00 00 F5 88 04 00 00 05 01 40 F2 00 00 00 00 03 C0 3C D9 00 00 00 00 2F 00 05 01 01 40 28 06 00 7B E8 06 00 02 04 00 00 06 02 06 08 06 00 00 0D 0A 08 00 06 0C 0E 10 00 0E 12 10 06 0E 14 12 00 14 16 12 06 14 18 16 00 18 1A 16 06 12 1C 1E 00 12 16 1C 06 16 20 1C 00 16 1A 20 06 10 12 1E 00 10 1E 0C 06 18 22 1A 00 18 24 22 06 1A 26 20 00 26 24 20 DF 00 00 00 00 00 00 00

Now the data is closer to what it should be, but there are some unreasonable shifts and other things. Thanks for you time. Any other ideas?
06-04-2011
quzah

If I were to guess, since I don't feel like reading hundreds of data points to see where it's different, I'd say it's this: Newline - Wikipedia, the free encyclopedia

Quzah.
06-04-2011
Salem

> However, the problem for Windows people still persists, but it's now closer than before. Any ideas now?
So how did you get your Linux data onto your windows box?

> 06 00 02 04 00 04 02 06 06 04 08 0D 0A 00 06 08
Because it seems to me that 0A got converted into 0D 0A by whatever you used to transfer it.
If you used FTP, you need to make sure that was in binary mode as well.

Begin by checking the actual file sizes down to the number of bytes.

Then perhaps use things like md5sum to make sure the file still has the same contents on both machines (the checksum is identical).
06-05-2011
Flotonic

I'm referring to when executing the program itself. It copies a certain block of data from a file to a new file. (The program was put on Windows by compiling under Windows. Very simple.)

After reading so many bytes, the data being written to the new file becomes offset, as seen in the previous code examples. I'll write some pseudo-data just to further define what's going on.

Line_________Original_Data________Ripped_Data_____ ___Comparison
Line_1_______57_87_97_67________57_87_97_67_______ _Successful!
Line_2_______89_97_48_49_________99_97_48_49______ _Less accurate
Line_3_______15_30_45_00_________89_40_45_00______ _Even less accurate.
Line_4_______13_78_95_15_________45_61_17_15______ _Even less accurate.
Line_5_______89_03_4A_19_________30_76_22_57______ _Zero accuracy.
Line_6_______78_5A_7B_8B_________FF_FF_FF_FF______ __Writing NULL.

After every so many time bytes are read by the program, they become less accurate. After reading so many bytes, NULL results are written to the file.
06-05-2011
tabstop

Quote:

Originally Posted by Flotonic

(The program was put on Windows by compiling under Windows. Very simple.)

That tells us less than nothing about how the data file got there.
06-05-2011
EVOEx

Quote:

Originally Posted by Flotonic

I'm referring to when executing the program itself. It copies a certain block of data from a file to a new file. (The program was put on Windows by compiling under Windows. Very simple.)

After reading so many bytes, the data being written to the new file becomes offset, as seen in the previous code examples. I'll write some pseudo-data just to further define what's going on.

Line_________Original_Data________Ripped_Data_____ ___Comparison
Line_1_______57_87_97_67________57_87_97_67_______ _Successful!
Line_2_______89_97_48_49_________99_97_48_49______ _Less accurate
Line_3_______15_30_45_00_________89_40_45_00______ _Even less accurate.
Line_4_______13_78_95_15_________45_61_17_15______ _Even less accurate.
Line_5_______89_03_4A_19_________30_76_22_57______ _Zero accuracy.
Line_6_______78_5A_7B_8B_________FF_FF_FF_FF______ __Writing NULL.

After every so many time bytes are read by the program, they become less accurate. After reading so many bytes, NULL results are written to the file.

Where did you get that "pseudo-data" from? I can't find it anywhere in the data you provided. Also, comparing the two program's output; it seems that everyone is right, the first difference (according to Linux's diff program) is in the following line:

Code:

< 06 00 02 04 00 04 02 06 06 04 08 0A 00 06 08 04 > 06 00 02 04 00 04 02 06 06 04 08 0D 0A 00 06 08

And as several people stated before, the only change is that Windows uses '\r\n' as a newline and Linux '\n'. So with the information you provided us so far, there's nothing anybody here can do for you, if there is an error still at all.
06-05-2011
Flotonic

"Pseudo" means fake. That was just fake bytes that I threw together in order to better illustrate the problem and in a smaller amount of space.

The data file gets there when the program is ran. It asks for a file to grab data from and the offset to begin grabbing data. For example:

File to grab data from: [USER INPUT.]
Offset to begin grabbing data: [USER INPUT.]

It goes to the offset relative to the start of the file and grabs bytes, writing them to a new file as it goes, until it runs into a certain byte. The problem is that when this program is ran as a Windows user, the data becomes offset after so many loops. I'm looking for something cross platform, and the code currently only executes the way it is supposed to when running on Linux.
06-05-2011
quzah

I've already told you what your problem is.

Ascii Table - ASCII character codes and html, octal, hex and decimal chart conversion

Go there and be surprised and amazed at what 0D and 0A are, and then run along.

Quzah.
06-05-2011
Salem

You've yet to prove to us that the data file you copied from Linux to Windows is undamaged by your attempt to copy it.

If your Linux file contains an 0A, which is transformed to 0D 0A on Windows, then you need to look at the copying process, not your code.
There is nothing you can do in your code to fix this.
06-05-2011
Flotonic

Ohh! Now I see it. :P Thank ya! The problem now is modifying the code or doing something so Windows doesn't do said conversions. Because I'm still relatively new and still, in fact, have the right-out-of-the-box smell, have any ideas for how to fix this?

Proof that the data reads correctly on Linux is because it doesn't enter a permanent loop, the data stops cleanly at a DF Command, and all data is grabbed successfully. A sword wouldn't have been successfully ported from one file to another (game-wise) had the code had a flaw in it. Link.

A custom .ini file or anything to get Windows to go into a different mode when reading code?
06-05-2011
Salem

OK, last time of asking - is your data file the SAME on both systems?

If the answer is NO, then you are screwed. There is no fix you can apply in your program code where you can automatically patch 0D 0A pairs, because there is always the random chance that 0D 0A might appear in a normal data file anyway.
06-06-2011
Flotonic

Both the source code and the files being read/written to are the same on both systems. Yes. There shouldn't be a reason there can't be some sort of repair, though.
06-06-2011
EVOEx

Quote:

Originally Posted by Flotonic

Both the source code and the files being read/written to are the same on both systems. Yes. There shouldn't be a reason there can't be some sort of repair, though.

And here we go again. No, the files are not the same on both Windows and Linux, I'm quite sure. You haven't even answered half of the questions that will lead to an answer, and you even throw in random "fake" data that only puts anyone reading it off - because it definitely does NOT show what is wrong here.
06-06-2011
stahta01

Quote:

Originally Posted by stahta01

Do you open the file in Binary Mode?
This is not needed under Linux; but, required under Windows.

Tim S.

You have two files involved are they both opened in Binary?

Tim S.
06-06-2011
Flotonic

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");
06-06-2011
quzah

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.
06-06-2011
Flotonic

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.
06-06-2011
tabstop

"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.
06-06-2011
Flotonic

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.
06-06-2011
tabstop

Quote:

Originally Posted by Flotonic

I'm re-downloading the files and doing this with perfectly clean data each time.

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.
06-06-2011
Flotonic

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.
06-06-2011
quzah

Quote:

Originally Posted by Flotonic

I just had a Windows user try

So it's not actually you who is testing your code.

Quote:

Originally Posted by Flotonic

opening the file and copying it to and empty, fresh, new one.

What does that even mean?

Quote:

Originally Posted by Flotonic

They still get the errors, even though the copy is 100% clean and not modified from what is found in the game.

What does that even mean? What error? Doing what?

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; }

Quzah.
06-07-2011
Flotonic

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.
06-07-2011
anduril462

Quote:

Originally Posted by Flotonic

like how you need to use fflush(stdin); each time you use a getchar(); statement.

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.
06-07-2011
stahta01

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.
06-07-2011
anduril462

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.
06-07-2011
Flotonic

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.
06-07-2011
Salem

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.
06-07-2011
stahta01

Code:

if(byte1==0xDF && byte2==0x00 && byte3==0x00 && byte4==0x00 && byte5==0x00 && byte6==0x00 && byte7==0x00 && byte8==0x00) { break; }

A poor way to handle EOF with only minor changes to your code.

Code:

if(byte1==EOF || byte2==EOF || byte3==EOF || byte4==EOF || byte5==EOF || byte6==EOF || byte7==EOF || byte8==EOF) { byte1=0xDF; byte2=0x00; byte3=0x00; byte4=0x00; byte5=0x00; byte6=0x00; byte7=0x00; byte8=0x00; } if(byte1==0xDF && byte2==0x00 && byte3==0x00 && byte4==0x00 && byte5==0x00 && byte6==0x00 && byte7==0x00 && byte8==0x00) { break; }

Not tested or syntax checked.

Tim S.
06-07-2011
Flotonic

Salem:
I'll post the general bits for file reading here for you. If you want the whole source code, I can create a PasteBin entry for you.

Code:

char portfromentry[145],porttoentry[145]; int dltoport,dltoreplace,extradl,ofstoput,ofstoputstatic,trianglestoget,conversiontheorem,currentcommandoffset,getvertex,writevertex,currentround=0,twentyfour,area,texturelength,grabbed,extradlcheck; FILE *portfrom, *portto, *vertexdata, *texturedata, *displaylist; printf("\nZOBJ to port from: "); scanf("%s",portfromentry); printf("\nZOBJ to port to: "); scanf("%s",porttoentry); printf("\nDisplay List to port: 0x"); scanf("%X",&dltoport); printf("\nDisplay List to replace: 0x"); scanf("%X",&dltoreplace); 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"); for( ; ; ) { byte1=fgetc(portfrom); byte2=fgetc(portfrom); byte3=fgetc(portfrom); byte4=fgetc(portfrom); byte5=fgetc(portfrom); byte6=fgetc(portfrom); byte7=fgetc(portfrom); byte8=fgetc(portfrom); fputc(byte1,displaylist); fputc(byte2,displaylist); fputc(byte3,displaylist); fputc(byte4,displaylist); fputc(byte5,displaylist); fputc(byte6,displaylist); fputc(byte7,displaylist); fputc(byte8,displaylist); if(byte1==0xDF) { break; } }

Even though it all works so flawlessly for me, Windows gets stuck in a permanent loop when dealing with the loop unless it's working with extremely small Display Lists (that have a DF Command 0x50 or less bytes from the start). After reading and putting so many times, it beings to fail to read bytes the way it's supposed to, so by the time it gets to a DF Command about 0x200 bytes later, it doesn't notice that byte1==0xDF, so it never breaks out of the loop. I again repeat that it works flawlessly for me, but Windows struggles with it.

With the actual problem better explained now, hopefully a solution would be easier to come across.

Stahta01:
Actually, the DF Command isn't always at the end of the file that we're porting from. For example, if the user inputs 0x6A48 as the Display List to port, which is, say, 0x528 Bytes long (in this example only), and the total file-size is 0x7FF8, it would be separating the Display List only, which would start at 0x6A48 and end at the end of the DF Command that is up next. It's kind of difficult to explain, despite how simple it really is.
06-07-2011
quzah

Quote:

Originally Posted by Flotonic

I again repeat that it works flawlessly for me, but Windows struggles with it.

Translation: "Some guy says it doesn't work, but I can't repeat his effort to break it."

Good job wasting everyone's time with something you aren't actually experiencing.

Code:

while( fread( buf, 1, 8, fp ) == 8 ) { if( buf[ 0 ] == stopbyte ) break; else /* optionally remove the else statements and just have it do this anyway */ if( buf[ 1 ] == stopbyte || buf[ 2 ] == stopbyte || buf[ 3 ] == stopbyte || buf[ 4 ] == stopbyte || buf[ 5 ] == stopbyte || buf[ 6 ] == stopbyte || buf[ 7 ] == stopbyte ) printf( "stopbyte found out of position\n" ); else ...do whatever it is you are doing... }

But like I said, troubleshooting some random guy's "problem" without actually duplicating it yourself, or actually having his broken files is well... sort of like this thread.

Quzah.
06-09-2011
Flotonic

I optimized the code earlier today and am now getting the same permanent loop problem on Linux, same for Windows. The good part is that the data ripped from the file on each system is one hundred percent identical. Pretty much, my only remaining problem is getting it to break out of the loop once a DF Command is found. The code is as follows.

Code:

for( ; ; ) { for(fill=0;fill<9;fill+=1) { bytegrabber=fgetc(portfrom); bytestoring[fill]=bytegrabber; } for(fill=0;fill<9;fill+=1) { bytegrabber=bytestoring[fill]; fputc(bytegrabber,displaylist); } if(bytestoring[1]==0xDF && bytestoring[2]==0x00 && bytestoring[3]==0x00 && bytestoring[4]==0x00 && bytestoring[5]==0x00 && bytestoring[6]==0x00 && bytestoring[7]==0x00 && bytestoring[8]==0x00) { break; } }

The solution here must be obvious, even though I'm not seeing it. I've tried shifting all of the variables down (starting at bytestoring[0] instead of bytestoring[1]) as well as checking bytestoring[0] or bytestoring[1] by itself and not alongside its family. Does anyone mind enlightening me and telling me what I'm doing wrong while trying to break out of this? Thanks in advance!
06-09-2011
quzah

Why are you reading nine bytes instead of eight now? Why aren't you just using fread?

Quzah.
06-09-2011
Flotonic

Ohh. Right. The problem is now fixed. I didn't try both changes in conjunction. Again, a simple answer. Thanks a lot!

How might I lock a topic?
06-10-2011
mike65535

Quote:

Originally Posted by Flotonic

How might I lock a topic?

That's not for you to decide. ;-)
06-10-2011
Salem

There is no "close" or "solved" tag on this forum, treads are simply abandoned when the OP is happy with the result (or quietly leaves never to be heard from).

It is rare that someone will bump it several years later with some "me too" refrain, and rarer still that they might have something useful to contribute.
06-10-2011
Salem

However, this one has gone on long enough, and is wandering into forum meta discussion. If it really interests you, try asking in the GD forum.