A non-text attachment was scrubbed... Name: not available Type: text Size: 680 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19981125/487b5a7b/at…

A non-text attachment was scrubbed... Name: not available Type: text Size: 1180 bytes Desc: not available Url : http://www.classiccmp.org/pipermail/cctalk/attachments/19981126/6609b352/at…

John writes: IIRC, Wirth's original compiler was not p-code oriented, but emitted machine code for whatever machine it was on. I recall the problems that caused for Burroughs B6700 (MCP) machines, circa 1970-1972. They relied 100% on compiler checking for security. Outside of array bounds checking, there was literally no hardware security. However, since no supported languages had pointers that were user manipulatable, and there was no assembler (#1), this actually worked (#2). (ALGOL's pointers weren't freely manipulatable). When Pascal came along, I recall Jim Madden of UCSD Computer Center adapting a very early version of Wirth's compiler it to emit Burroughs machine code ... and then struggling with how to prevent security problems because of the @#$% tagless variant design. I.e., because the Pascal standard failed to say something robust like "compilers MUST have a secret tag to check the value of tagless variants", people were able to implement peek/poke with a tagless variant like: type foo_type = record case integer of 0: (ip : ^ integer); 1: (i32 : integer); {assumes pointers and integers are same size} end; var foo : foo_type; foo.i32 := some magic number foo.ip^ := ... {poke!} Note that if the type had been a tagged variant: ... case foo_kind : integer of then the compiler could (and should!) emit code to properly secure the "ip" field of foo, based on the tag value. In short, Pascal's refusal to implement type casting coupled with a weak design for the case variant caused problems both for code clarity and code security (on some machines). In the UCSD case, I can't recall if Jim ever released the Pascal compiler. (This is not the UCSD P system compiler, although Jim worked for Dr. Bowles) #1: At least two assemblers for B6500/B7700 MPE machines started circulating "under the table" in the mid 1970s. One was from UC Davis, and I can't recall the origin of the other one. #2: If a user attempted to modify the code in a program file by patching it, that changed the program file to a non-executable data file.

On Mon, 30 Nov 1998, Sam Ismail wrote: I also once wrote a p-code disassembler on my Apple. I used it to a disassemble the code of a game written in Apple Pascal so I could locate the copy protection (it used a code wheel...I just changed a Branch if Not Equal to a Branch if Equal and it worked). Anyway, if I can find where I saved that program I'll send that to whoever wants it too. Its very primitive though. It reads sectors off the Pascal disk in question and just dumps a disassembly to the screen. If I wrote it in Pascal it could have opened the p-code file and then done the disassembly in a more convenient manner, but I'm not about to go back to programming Apple Pascal, which blows. Sellam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------ Always being hassled by the man. Coming in 1999: Vintage Computer Festival 3.0 See http://www.vintage.org/vcf for details! [Last web site update: 11/02/98]