Back in the late 1970's, the company I worked for hired a software programmer from Data General. He brought with him a tape that had the source code to Adventure on it. We got local company to extract the code and put in on an 8" floppy. We had just purchased Microsoft's Fortran compiler were able get Adventure up and running on our own version of a PC. Productivity took a nose dive for the next month or so. Byte magazine published the complete source code in a mouse point font. To win you had to fight the dragon with your bare hands If you tried any weapon you were killed. You had to answer yes to the question "Do you really want to kill the dragon with your bare hands?" Another game I remember spending hours making maps of 20 levels of 10x10 grids was OrbQuest.

I am also working in an old C++ MFC project that was developed in the late 90's. I am using Reshaper from JetBrains. It gives a lot of suggestions when looking at old C++ code. Adding a 'const' shows up a lot. It includes a lot of suggestions to use the newer memory/string functions that require providing the buffer size. I don't take all of it's suggestions since the code is very reliable.

Loose Lost In ? (? = room where it might be found) Unorganized Storage

I have been using Visio for software architecture drawings. Not really a flowchart drawing tool per se, but Think & Do was a PC-based industrial control package that used flowcharts to document a machine's control logic. A medium sized project would contain 100+ flowchart. The flowcharts were compiled into a byte code stream that the run-time component would evaluate in real time. Scan times for a medium sized project was 2-3 msec. I worked for Think & Do Software in the early 00's and am working to port the Visual 6.0 C++ solution to VS2019 C# so it will run on 64-bit Win-10. Visio and Excel have been helpful in documenting how the old C++ code worked

If you find yourself in a hole, stop digging. Will Rogers www.TND10.com

1969, FORTRAN via punch cards on an IBM 370. The procedure was: 1. Punch cards 2. Submit deck 3. Wait somewhere between 5 minutes and several hours 4. Pickup output listing 5. Find typo or logic error 6. Repeat I think the program had something to do with using Simpson's Rule. Later on I did a lot of programming on a HP 2100 mini-computer via paper tape on a teletype machine. I remember trying to get something working late on day and out of frustration I randomly typed 'why' at the prompt. The computer responded with 'Why not'. HP published all the details on the machine, include the assembly language source code for the OS. I decided to figure out where the 'Why not' was coming from. It was extremely well disguised so it took a couple of hours to find it. It's pretty easy to disguise stuff in assembly language.

They were manipulating a cat's knee joint with a swept sine wave and measuring the activity on a nerve in the upper leg. They found that there were sensors in the knee that were sensitive to both position and velocity, with a hint that there was some sensitivity to acceleration. The data processing was all done in HP's Fortran and took a long time. After they upgraded the computer to a HP 2100, which gave you access to the micro-code, I created a couple of new machine instructions that sped the FFT up by 15%. The 2100 systems also came with a disk drive that has both a fixed and removable cartridge. I am guessing that the platter was 14" in diameter and held maybe 2MB. How was the HP being used in your situation?

I designed and built a ADC card. We were recording nerve signals on a high quality multi-channel analog tape recorder, playing it back into the computer at 1/16 speed and doing FFTs and correlations to see how the nerves encoded information.

I learned to program on a HP 2115 minicomputer whose primary IO methods were paper tape and a teletype. One evening while trying to get something to work, I typed "why" at the command prompt. The computer replied "Why not". Since HP published the source code for the basic OS (HP Assembly Language), I dove in to see if I could find where "why" was being parsed as a legal command. As I remember, it was very well obfuscated using octal constants for both data and executable code. I guess I'll have to go with the HP2115's answer to the question Why? Why not!

I have a table defined in a xsd that has an autoincrementing field that is used as the key to the table. The application uses ReadXML and WriteXML function to persists the dataset to an XML file. I am curious as to where the next value to use for the autoincrement field is persisted. I would have expected that when creating a new row in the table, the value for the ID field would be one greater than the highest value found in the table after the dataset is read in. It seems however to persist the highest value used in the past, even if those records have been deleted. In my application, when I create a new row, the ID field contains a 6071 when the highest value used before creating a new row was 5995. It does not appear that the autoincrement seed value is stored in the XML file itself, but where else would it be.