You are not logged in. Please login or register.
AudioGames.net Forum → Developers room → Is possible to read and edit files on bit level in bgt?
Hi all,
I have one unstandard question. Is possible to read and edit files on 1/0 level? I projecting some cypher algorithms, and I need this. I think that bgt do not support this, but I am asking before I vill change programming language for this project.
Thanks too much for answers.
I think that you can open a file for write and read with the "b" keyword.
To open for read in bite mode you would use.
file.open("test.txt", "rb");
And write:
file.open("test.txt", "wb");
If you need more answers look in the bgt help file under "object re... in the foundation".
Hello,
ofcourse, but this vill read bytes, no bites. One byte have 8 bites. For example, if I want to read text file with text "a". I need get to the string no "a", but "01000001", what is "a" on the deepest part of computer thinks.
Next I can by the index edit the bites, for example 0 to 1, 1 to 0 and save file encrypted with this method.
To prewent computer ram I can do this by reloading byte after byte, but I need a function to read this.
Thanks too much for help.
Hi,
An uncapitalized a in decimal is the number 65, or the hexidecimal number 0x41. So the binary equivalent is 01000001. Why you need to write bytes directly is a mystery to me. Writing bytes directly to a file in such a way is known as direct IO, and is extremely difficult to handle. I have never heard of a cipher that needs such low-level IO.
Just be warned that if you do continue on with this extremely difficult (and possibly dangerous) mission, there are several things you must know:
You must understand that each character (which is 1 byte) is 8 bits. Do not try and simply right, say, 1111000 (which is "x" in binary). You must make the string your writing exactly 8 bits, no less, no more. X in binary is, including the leading zeros, 01111000. If it is more than 8 bits, add more bits until you have the entire string written, but mentally separate it with a separator. For instance, if you wish to write "Hello, world!", you would write to the file the following bits: 01001000011001010110110001101100011011110010110000100000011101110110111101110010011011000110010000100001. Mentally, though, you might separate it with commas, e.g.: you would mentally think, "01001000, 01100101, 01101100, 01101100, 01101111, 00101100, 00100000, 01110111, 01101111, 01110010, 01101100, 01100100, 00100001."
You must realize that binary is an extremely difficult language to write things in. "Hello, world!" is 13 characters. Binary increased the length of the string by 91 characters (which is approximately an 800 percent increase). You would be better off writing in hex. "Hello, world!" in hexidecimal is 0x48656c6c6f2c20776f726c6421. Hex increased the string "Hello, World!", which was only 13 characters, to 26 characters (which is approximately a 200 percent increase).
You must also consider another problem with binary, hex, and writing a string using ints: If you make one mistake (even a very tiny one), you need to write the entire string over again, which isn't fun. Computer programmers used to do that. That's why Assembly language was invented: to rid computer programmers of the hassle of not knowing what they were entering into the machine.
You need to know binary... entirely. You cannot know it a little; you need to know it completely. And you need to know how your processor operates. In this case, you need to master binary and the cipher down to the letter. There can be no mistakes in your code, otherwise your entire calculation is a waste of computer resources.
So, I would kindly advise you to stop right here before you destroy yourself trying to figure out how binary works and just use normal UTF-8 strings. You don't need a cipher so complicated that it requires you to write bits directly. If you need that kind of cipher, then your attempting a project that is impossible. And I mean that, literally. You'll never manage to complete such a project if you use bit-level strings. Your basically accessing hardware directly. The only thing that isn't stopping you from directly calling disk drives directly is BGT's incapability to do it and the kernel of windows preventing you from doing so.
You want to look up bitwise operators, and use hexadecimal. These aren't covered in the BGT manual.
Each hex digit represents 4 bits, and since there are only 16 (0-f), it's fairly easy to remember (or calculate) what binary sequence they represent.
The bitwise operators are hard to explain in a forum post. I'll try to summarize as best I can:
& (and): for single bits x and y, x&y==1 only when x==1 and y==1. This is the most useful way to find the value of any particular bit. For example:
if((x&1)==0) alert("Even number", x + " is even!");
(OK, you can do the same as the example with x%2==0, but that's beside the point. If you need to check for the 4, 8, or 32 bits, or a collection of bits, this is how you'd do it.)
| (or): x|y==1 if x==1 or y==1. This is most useful for setting desired bits to 1, even if you don't know their original state. For example,
x=y|5;
Means that, no matter what the value of x, the 4 and 1 bits will be set.
^ (exclusive or, xor): x^y==1 if only one of x or y is 1, but not both. This is most useful if you want to toggle a bit. For example:
x^=1;
Will set the 1 bit if x is even, or set it to 0 if x is odd.
(FYI: you can use the (logical) xor keyword in conditionals. I didn't know that until very recently... what a typing-saver that would have been, even though it doesn't come up often.)
~ (not): this is a unary operator that flips all the bits in a byte/bytes. Try it on a bunch of random numbers, and see the twos-complement algorithm in action. (Which is to say, for a signed integer, ~0==-1. For an unsigned integer, ~0=the maximum value for the bytesize.) This is mostly useful because you're manipulating individual bits on the byte level, and this is how you'd set specific bits to 0 without changing the others. For example:
x=x&~4;
Sets the 4 bit to 0, without changing the other bits.
<< and >> (left and right shift) move all the bits to the left/right (where lower-value bits are to the right, and higher-value bits to the left). This is equivalent to integer-multiplication (<<) or division (>>) by powers of 2, but is useful when you want to store multiple values in a single int, which you need to work with as lower-order values later.
For example, say you have 4 integer values (a, b, c, d) that you want to save in the smallest space possible. If you can expect them to only have a maximum of 16 distinct states, you could store them like so:
int16 bytes=a|(b<<4)|(c<<8)|(d<<12);
And to retrieve them:
a=bytes&0xf;
b=(bytes>>4)&0xf;
c=(bytes>>8)&0xf;
d=(bytes>>12)&0xf;
For all of these, you can use combined read/write operations, for example x|=y, x<<=y, x&=~y, x^=y.
Usually, I use bitwise stuff when I need to use an arbitrary number of boolean properties, because it turned out to be much easier and more efficient (for me, anyway) than using tons of bools. Especially since I almost never need more than 32, usually need more than 8, and can usually predict based on the program whether or not 16 will be enough. It makes it possible to leave room for new flags without having to change much.
+1
Hello,
thank you all for help. My goal is to create a file version of vernam cypher, to protecting my secret files by creating a key file to the external flash drive.
I know other languages like java, c++ or delphi, so I vill try to use this powerfull possibilities to realize my thinks easyer.
Very thank one more time.
AudioGames.net Forum → Developers room → Is possible to read and edit files on bit level in bgt?
Generated in 0.022 seconds (58% PHP - 42% DB) with 10 queries