Microsoft GW-BASIC on IBM compatibles allowed flags to the SAVE command, to indicate the manner in which a file should be written out.

As I recall, it allowed for no flag to write a standard tokenized format, ,A to write a plain-text ASCII BASIC listing, and ,P to write a "protected" file.

"Protected" files looked like gibberish on disk even compared to the tokenized files, and the interpreter would at least refuse to LIST the source code. As I recall the file size also wasn't the same. They did however run just fine when given to the interpreter.

How were such "protected" files encoded? What about them was different compared to an ordinary tokenized save (no flag)?

1 Answer 1


The files are encoded as follows:

  • the first byte is 0xFE to indicate that it’s a protected tokenized file (0xFF for a regular tokenized file);
  • the remainder of the file is encoded using exclusive-ors with two keys, embedded in the interpreter (or in the ROM, for BASICA).

The two keys are

Key1    db    9Ah, 0F7h, 19h, 83h,  24h, 63h, 43h, 83h,  75h, 0CDh, 8Dh, 84h, 0A9h
Key2    db    7Ch,  88h, 59h, 74h, 0E0h, 97h, 26h, 77h, 0C4h,  1Dh, 1Eh

When decoding, two counters are stored in CH and CL, starting respectively at 0x0D and 0x0B (the lengths of the keys); each stored byte is then replaced with (encodedCL) ^ Key1[CH – 1] ^ Key2[CL – 1] + CH, CL and CH decrementing every time a byte is processed until they hit 0 (after the calculation), when they are reset to their starting value (independently). Encoding is the opposite: with the same loop, each plain-text byte is replaced with (decodedCH) ^ Key1[CH – 1] ^ Key2[CL – 1] + CL.

So the size of the files should be identical. The LIST limitation is presumably implemented in the interpreter.

See Deciphering GW-BASIC / BASICA protected programs for details.

  • 2
    I seem to recall a POKE command to un-protect the code from within the interpreter, but I could be mistaken. It was pre-internet days, after all and I can't imagine where I would've seen it or learned about it, yet the memory seems real. Perhaps I saw something on a BBS somewhere. Commented Jul 26, 2018 at 13:13
  • 2
    @Bill that’s quite likely, the documentation in UNPBAS11.ZIP mentions other decryption schemes, and says “Still other schemes employ a POKE or BLOAD after loading the protected program into the interpreter, which may or may not be allowed, depending on the interpreter.” Commented Jul 26, 2018 at 13:30
  • 1
    @BillHileman: Early versions of MSBASIC may have allowed a poke to disable protection, but later versions severely restrict the set of actions that can be done in immediate mode--probably because MS realized that people were using poke to bypass protected mode.
    – supercat
    Commented Jul 26, 2018 at 23:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .