SoylentNews

• Re:Cores and Java (Score: 3, Interesting) by DannyB on Thursday May 25, @08:51PM

  by DannyB (5839) on Thursday May 25, @08:51PM (#1308205) Journal

  In the 1980s we had used UCSD p-System Pascal. The Pascal is compiled down to p-code. Then a 2K byte PME (p-Machine Emulator) runs the bytecode. Sort of like Java. :-)

  You could take your compiled code to other systems that had the p-System PME.

  Aside...

  *SPOILER* (click to show) *SPOILER* (click to hide)

  
  To solve the endianness problem, the p-System called it "byte sex" whether the least significant byte was first in a word or the most significant byte in a word came first. Binary files, such as compiled code, would begin with a "byte sex" indicator. Two bytes where one of the bytes has the single low bit set. If you read it as 1 you had the same sex as whatever machine this binary came from. If you read that word as 256 you know you have the opposite byte sex and 16 bit words must be byte swapped.

  It was only years later I ever began hearing the term "endian" like big endian or little endian. It seemed confusing. I wondered why they had not just used the "byte sex" terminology. :-)

  So in early 1993, we are looking at rewriting things. One thing that I have my company buy is Turbo Pascal 7. Now this only ran on the PC and not other platforms. But at this point, our only other platform was Macintosh. The Apple II and Apple /// had disappeared. Just Mac and PC.

  So I really loved TP7.

  Now, in the meantime, a Canadian company Datalex had developed this thing called the Datalex Bubble. What it did was package up the p-System into a DOS EXE. So you could have DOS files that were entire p-System volumes. But the tools it provided for moving things in and out between p-System and DOS were cumbersome and ran inside the p-System.

  So my first TP7 programs were called the p-Tools. It was a set of DOS EXEs that allowed you to do a lot of manipulations of files and volumes within the p-System from the DOS command line. The p-System filesystem was rather simplistic. So this was easy, and I knew the p-System inside and out.

  My TP7 p-Tools could do massive krunches (compacting) of p-System volumes at lighting speed compares to doing it in the p-System itself with its OS utilities. I could allocate massive buffers in TP7. I could do wildcard copies of files in and out, and automatically convert TEXT files in p-System to and from DOS format.

  This made working with p-System in DOS vastly more pleasant. And our commercial software looked like an ordinary DOS program, even though it was really the p-System OS inside.

  On Macintosh we moved to MPW Pascal and wrote our own "terminal emulator" but without a "terminal". Just a 24x80 text front end for the UI, but in a Mac window. Now we maintained two Pascal source code bases for Mac and PC and simply carefully made changes to both code bases in sync.

  I considered advocating rewriting out of p-System to TP7, as we had done on Mac with MPW. But it was very clear we needed to embrace GUI. So we ended up eventually going another direction to get to a GUI interface, on both Windows and Mac.

  At one point, I considered whether we should force our Mac customer base to simply switch to Windows. So I did a survey of our customer records, and it turned out 56% of our customers were Mac. So that idea fell flat. Whatever we did had to be cross platform and GUI.

  --
  If a minstrel has musical instruments attached to his bicycle, can it be called a minstrel cycle?

  Reply to This Parent

  Starting Score:	1		point
  Moderation		+1
  Interesting=1, Total=1
  Extra 'Interesting' Modifier		0
  Karma-Bonus Modifier		+1
  Total Score:		3