Here's another....file I/O difficulties.

[Zack]

I can't figure this out. I'm trying to make a very simple Encryption/decryption console app.
The first error is on the OPEN Filename FOR BINARY AS #F. It says there's a type mismatch at parameter 1.
Now, I'm not sure why. I assume parameter 1 is Filename. And I've dimensioned that as a STRING already. Why the type mismatch?
Now, I replace that with hard text, like "c:\foo.txt" and that solves that error...for some reason. Then there's another. On the "IF KeyString="" THEN..." part, it lists another type mismatch. "Type mismatch, found THEN". I can't seem to work around that one.
Any ideas folks?

Code:

OPTION EXPLICIT
DIM Filename,KeyString,RealText,CipherText AS STRING
DIM F,FilePos,I,I2 AS INTEGER
DIM TempChar AS BYTE
GetFilename:
INPUT "Filename:";Filename
F=FREEFILE
OPEN Filename FOR BINARY AS #F
IF ERR=2 THEN
    PRINT "File not found!"
    GOSUB GetFileName
ELSEIF ERR=3 THEN
    PRINT "General File I/O error!"
    PRINT "Press any key..."
    SLEEP
    END
END IF
GetKeyString:
INPUT "Key string:";KeyString
IF KeyString="" THEN
    PRINT "Empty Key String!"
    GOSUB GetKeyString
END IF
PRINT "Ciphering...";
WHILE NOT EOF(F)
    GET #F,,TempChar
    RealText=RealText + CHR$(TempChar)
WEND
TempChar=ASC(RealText)
FOR I=1 TO LEN(RealText)
    FOR I2=1 TO LEN(KeyString)
        TempChar=TempChar XOR ASC(MID$(KeyString,I2,1))
        CipherText=CipherText + CHR$(TempChar)
    NEXT
NEXT
FilePos=1
PUT #F,1,CipherText
CLOSE
PRINT "done."

[stylin]

Code:

DIM Filename,KeyString,RealText,CipherText AS STRING
DIM F,FilePos,I,I2 AS INTEGER

Only CipherText is DIMed as a string. The rest are integers. Change those to,

Code:

DIM as string Filename, KeyString, RealText, CipherText
DIM as integer F, FilePos, I, I2

and you should be fine.

This is another reason why
1. You should avoid multiple declarations (DIMs) on one line.
2. Declare variables only when you immediately need them, ie., not all at once at the top of the program.

Post again if you have any more troubles.

[Zack]

Thanks, man! I didn't know that. I kneaded out a few other problems on my own.
Here's the finished code:

Code:

OPTION EXPLICIT
DIM AS STRING Filename,KeyString,RealText,CipherText
DIM AS INTEGER F,FilePos,I,I2
DIM TempChar AS BYTE
GetFilename:
INPUT "Filename: ",Filename
F=FREEFILE
OPEN Filename FOR BINARY AS #F
IF ERR THEN=2
    PRINT "File not found!"
    GOSUB GetFileName
ELSEIF ERR=3 THEN
    PRINT "General File I/O error!"
    PRINT "Press any key..."
    SLEEP
    END
END IF
GetKeyString:
INPUT "Key string: ",KeyString
IF KeyString="" THEN
    PRINT "Empty Key String!"
    GOSUB GetKeyString
END IF
PRINT "[De]ciphering...";
WHILE NOT EOF(F)
    GET #F,,TempChar
    RealText=RealText + CHR$(TempChar)
WEND
FOR I=1 TO LEN(RealText)
    TempChar=ASC(MID$(RealText,I,1))
    FOR I2=1 TO LEN(KeyString)
        TempChar=TempChar XOR ASC(MID$(KeyString,I2,1))
    NEXT
    CipherText=CipherText + CHR$(TempChar)
NEXT
FilePos=1
PUT #F,1,CipherText
CLOSE
PRINT "done."
SLEEP

It's basically simple. You input a file, and a key string. The program XORs each character in the file with each character in the key string, and saves it in that same file. To decrypt, simply enter the same file and original key.
Not a very strong encryption, but alright if you want to stop your little brother from changing your settings in photoshop. :wink:
There is one thing more. Why doesn't the ERR handling thing work? If I enter a wrong filename, it doesn't tell me so, as it should.

[stylin]

Code:

IF ERR THEN=2

I'm not sure how this even compiles. Does it? Try this:

Code:

IF ERR=2 THEN

[Zack]

Sorry, copying error, I accidentaly changed it. Your correction is right. Thanks.

[stylin]

Not a problem.

[Moneo]

.....
Not a very strong encryption, but alright if you want to stop your little brother from changing your settings in photoshop. :wink:
.....

I you want a simple but more robust encryption algorithm, try the following by Ethan Winer. It's even less code than yours.

Code:

rem X$ is the string to be encrypted.
rem Password$ is the password.

dim L as integer
dim X as integer
dim Pass as integer

L=len(Password$)
for X = 1 to len(X$)
     Pass = asc(mid$(Password$, (X mod L) - L  * ((X mod L) = 0), 1))
     mid$(X$,X,1) = chr$(asc(mid$(X$,X,1)) xor Pass)
next X

*****

[Zack]

Well, I don't know how it works but it does seem solid. Neat.

[Moneo]

Don't feel bad, Zack, I don't really understand it either. This code is right out of Ethan Winer's book available free at:
www.ethanwiner.com

Back in 1990, for an encryption utility, I used the original assembly language version which was in Winer's QuickPak Professional Library, and it has always worked fine.
*****

[stylin]

Well, I don't know how it works but it does seem solid. Neat.

Simply, it overlays Password$ end-to-end over X$, then XORs X$ based on the value of Password$ at that character:

Code:

   This is the line to be encrypted.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   passwordpasswordpasswordpasswordp

While yours XORs every character of X$ (RealText) with the entire Password$ (KeyString):

Code:

   This is the line to be encrypted.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   ppppppppppppppppppppppppppppppppp
   aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
   sssssssssssssssssssssssssssssssss
   sssssssssssssssssssssssssssssssss
   wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
   ooooooooooooooooooooooooooooooooo
   rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr
   ddddddddddddddddddddddddddddddddd

Hope that clears it up.

[Zack]

I see. And I also assume that the reason it's been made to be rather complex is so that it can inhabit a mere two lines. Is that correct? It could be done in a less concise, but clearer way. Perhaps I'll attempt that tomorrow.

[stylin]

Well, many seasoned programmers aim for terseness when writing code, usually because this leads to clearer, and sometimes more elegant, code. Terseness, however, can be a liability; it took me a few minutes to decipher (pun intended) his algorithm, and I would have appreciated a short comment. It can be digested, if chewed.

In his case, I think splitting up the loop would actually make the code less clear, since it would detract from the main things that are being accomplished: 1. calculating an encryption key, and 2. encrypting the text. Splitting it up, IMO, would require additional helper functions, so that the encryption code could be kept on the same level of abstraction (1. and 2., instead of 1a., 1b., 2.).

[na_th_an]

I just drop by to say that I strongly discourage following this direction:

2. Declare variables only when you immediately need them, ie., not all at once at the top of the program.

No-no. Spaghetti, spaghetti.

[Anonymous]

in a language like qb, na_th_an is correct. however, now that we have fb (and variable scoping) you can definitely declare vars when you need them, and safely let them go out of scope when they aren't needed anymore.

[na_th_an]

For scoped variables, yes. But I can picture people declaring *any* stuff wherever and then losing track of variable types and stuff.

I fiscourage it.