[sitkack]

I never used it, are you saying you could Run the current program and it might accidentally bring your entire system down without having saved the program?

Seems like at least a two file circular buffer with autosave wouldn't take up too much space, or maybe streaming diffs into a compressed buffer (even on a 286, this shouldn't be too much trouble).

[mbessey]

Yes, that exactly. Part of what made Turbo Pascal so fast was that it kept your entire program, and the compiler, in memory.

You had an option from the main menu to "compile" or "run", which included compiling, but NOT saving your edits first. You could save first, but on a floppy-based system, that could take a while.

I want to say that behavior changed in Turbo Pascal version 2, or 3?

[dumdedum123]

At least until 3 which is what I used.

[cardiffspaceman]

But control-Kdsr saves your work to the device it came from and runs the program. Approximately the WordStar command set with additions for the task at hand.

[kragen]

I think that is what he is saying, though I can't remember the TP command set well enough.

Turbo Pascal wasn't written on a 286; it was written for CP/M, where I think it required 48KiB of RAM. A "fairly early version of Turbo Pascal for DOS" might have required 64KiB?

You can't really stream things onto a floppy disk (remember that early home computers and the IBM PC didn't have hard disks; they didn't become standard equipment until the late 80s). You have to write a whole sector at a time, which can take a second or two to seek the disk to the appropriate track; rotating the disk to the right sector takes a significant fraction of a second. Journaling your edits to a journal file was a feature that EDT on VAX/VMS had around that time, but there wasn't really a practical way to do that on a home computer.

[sitkack]

Yeah, I see that. I had an Amiga and mostly used the HD, so I don't really remember how slow the floppy drives were. Maybe for systems with tape drives we could live code and stream a journal to audio tape? A log of all the edit commands should be doable, maybe even as DTMF tones.

That would be funny if early OSes had an 8track (endless loop) as the circular journal. I think that is how the Voyager probes work. The 8 track DTR on the Voyager probes did not have an endless loop. https://hackaday.com/2018/11/29/interstellar-8-track-the-low...

Did you see this

Show HN: Torque – A lightweight meta-assembler for any processor (benbridle.com)

https://news.ycombinator.com/item?id=43698801

It is a Forth inspired programmable assembler.

based off of https://wiki.xxiivv.com/site/uxn.html

[kragen]

It's definitely an entertaining idea! And you probably could have made it work.

RAM would have been a cheaper and probably more reliable edit journaling device than an 8-track tape. It would survive warm boots unscathed where you had to reboot the computer after hanging it, failing only if your edits were lost to a power outage, and you would test it all the time, not just when the computer crashed. A battery-backed CMOS shift register memory chip, maybe about 2048 bits in size, would have solved the power loss problem, but keep in mind that a lot of these early microcomputers were so bare-bones they didn't even include a real-time clock, which is the other thing you want the battery for.

In 01996, Chen et al. at UMich proposed just such a (non-battery-backed) RAM journal to avoid losing written data in kernel crashes in https://web.eecs.umich.edu/virtual/papers/chen96.pdf, "The Rio File Cache: Surviving Operating System Crashes". They reported that it worked surprisingly well, and it enabled them to increase the durable transaction rate of their spinning rust filesystem by about three orders of magnitude, if I recall. And of course NetApp have been shipping FAServers using that approach (with battery-backed RAM) since day one, also about 01996.

Tim Paterson's blog I linked elsewhere in the thread has some comments about quantitatively exactly how fast different floppy systems used on 8-bit computers were.

[kragen]

I didn't, thanks!

[prosaic-hacker]

Early 80's VMS had a Keep/Purge system for history of files. Everytime you edited a file a version number was bumped up by 1. There was a command, "purge", I think that set the Keep count which was default to 3.

This would have been within the contemporary Dos and disk capabilities and size of 160-360kBytes, although slow (5-15 seconds).

When Dave Cutler moved from DEC to MS I expected the Dos console under windows to get that same feature. Disappointed. A gajillion lost hours could have be saved.

[sitkack]

We had a VMS machine in school and regret not spending more time learning from it.

It would be awesome to have application level granularity for a time traveling file system, the undo/redo mechanism could be built into the OS.

Reading up on https://en.wikipedia.org/wiki/Fossil_(file_system)

[kragen]

Incidentally, I was just reading https://cseweb.ucsd.edu/classes/wi19/cse221-a/papers/bobrow7... about TENEX, which offered roughly the same version numbering facility as VMS, though without the hierarchical filesystem directories VMS and Unix got from Multics. I don't know if TENEX got the idea from an earlier system. They don't mention one.

It's kind of amazing that this one paper introduced command-line completion, copy-on-write pages, load averages, and CAM TLBs.

[kragen]

The way I remember it, there was a SET command to set how many versions of a file should be kept, and PURGE would delete all but the most recent version. You could see the date of each version in DIR (they were listed on separate lines) but there wasn't a convenient way to open "FOO.FOR as of yesterday morning". You would have to figure out what version number to ask for and open "FOO.FOR;53" or whatever.

I agree that implementing this functionality in MS-DOS would have been relatively straightforward and acceptably efficient.

It'd be great to have long-lived transactions in a filesystem, permitting higher-level undo and redo.