JdeBP

Chicken and egg problem.

On the UFS and suchlike filesystems, at the point that fsck is rescuing orphaned i-nodes, it still has not fully gone through the process of checking and correcting free list information, or indeed fully eliminating errors from the i-node table. Creating a directory involves allocating a new i-node from an unused slot, and free blocks off the free block list.

Ironically, because they are slightly or grossly different to Unix filesystem formats, on HPFS and FAT this is less of an issue. (FAT usually has unused slots in the root directory that it is sane to use at that point, for example.) CHKDSK on OS/2 did create its \FOUND.nnn files on the fly.

It did.

Foxley gives the manual procedure for sizing the lost+found directory on the aforementioned page 52.

I have the 1986 edition of Fielder's and Hunter's UNIX System Administration and it does not mention any such command in its discussion of lost+found in chapter 3. It references AT&T Unix System 5 Release 2 (or 'UNIX 5.2' as the book puts it).

But Google Books tells me that their later 1991 update, referencing Release 4 and with an updated title to match, does indeed mention mklost+found. So that looks like something that appeared in Release 3 or 4.

I recommend starting with ECMA-35. The actual structure of escape sequences is explained there. Otherwise it gets lost that it's the ESC [ that is the entire escape sequence, an alternative form of CSI, and that this actually is one part of an entire mechanism of escape sequences with intermediate and final bytes. It's a control sequence that CSI then introduces.

I have a book on my bookshelf, Eric Foxley's Unix for Super-Users. It was published in 1985, and it answers this question on page 52, the first page listed for the entry 'lost+found' in its index.

This is surely not the earliest book mention, is it? (It'll be in earlier man pages, of course.) Google Books does not give me an earlier one, although it does yield another 1985 book.

Fun fact: Foxley cautioned that lost+found must be pre-sized ahead of time, because the fsck of the time did not grow the directory to fit found files.

It is StackExchange. So in theory someone could modernize it at any time.

That's what the answers are missing, of course. In some filesystem formats, it's possible either to recover completely from a journal/intent log, or at least to recover everything to the point that recovered files can be placed into the correct directory.

Yes, outwith the idea of Family API programs (which couldn't use Presentation Manager and whatnot anyway) OS/2 1.x did target the 286 as a minimum. But that doesn't mean that DOS+Windows didn't use the features.

It did. It was bi-modal. There were at one point switches to the WIN command to tell it whether to come up in real mode or 286 protected mode. In the latter it definitely did use the features of protected mode.

It was the bi-modal nature that was the problem. Essentially, they had to design a whole layer that simulated when in real mode all of the load-on-demand stuff that the processor architecture supplied for free in 286 protected mode, and make it so that the thing would all work either way with no changes to applications.

It wasn't really the processor architecture. Segmented addressing was actually fairly easy if the processor was used only in the way that protected mode was envisioned as working. As the headlined article observes, a lot of this stuff simply wasn't necessary in OS/2 1.x, even though that too had DLLs, callback window procedures, and the multiple tiny/small/medium/large/compact/huge memory models.

The differences were (a) that DOS+Windows was designed so that the same programs could run in both real mode, with overlaying, and 286 protected mode, with segmented virtual memory; and (b) that to really save on RAM DOS+Windows had ideas such as the data segments for DLLs being globally shared across all processes. These added all of the complications mentioned in the headlined article and more besides. It was the operating system, not the processor architecture.

It wasn't really the 'Undocumented' and 'Internals' books. Pretty much everything in the headlined article was to be found in the SDK, Microsoft Press publications, and in many third party books about DOS+Windows programming.

Petzold's Programming Windows book, for example, devoted an entire chapter (chapter 7) to memory management, with diagrams and examples. In the 2nd edition (which I just pulled off the shelf to check) that chapter runs to some 40 pages.

Check the ID numbers (48410844 < 48424862) and bear in mind that Hacker News has this thing where sometimes submissions get re-cycled for attention. Yes, annoyingly it does seem to make the presented datestamps wrong.

Psst! Let's blow their minds and tell them about the MC68008. (-:

It's a fairly widespread idea for architectures that try to move things out of kernel mode. The Hurd does program image file loading in userspace, too, in its exec server(s).

The tricky part is setting up the initial process. The way out for that is static linking and re-use of the fact that the operating system kernel loader has to understand and be able to load (at least a small subset of) program image file formats too.

If you look closely, you'll see that some faint dots are already outlining an order 7 triangular tiling.

You're not getting the full experience of analogue telly artifacts until you emulate colour subcarrier phase shift and colour burst detection failure. (-:

And of course PAL and Hanover bars.

That's actually less accurate, not more. It's a post-hoc revision that conflates Unix with Linux.

The Unix model was invented over a decade before the idea of multithreading percolated into mainstream operating systems at all.

The reason that Windows NT started as it did, was that OS/2 had come out in 1987, with kernel threads, and the idea of multithreading had taken root. SunOS 5 gained threading, too.

Windows NT applications development began with threading available as a mechanism from the start, and with a lot of people in the IBM/Microsoft world already knowing about its use in applications development from OS/2.

Whereas with the Unices it came in more gradually, as the applications had often already been designed. The whole libthread versus libpthread thing made things interesting on SunOS for a few years, too. As did the first attempt (LinuxThreads) at providing threads on Linux.

Not really. They didn't get anywhere near as far as noticing the prior art of NetBSD, not even on the mailing list discussion behind that article.

You haven't read the doco. I did point to some. The image file is supplied (or not) via the section object.

Think it through. Windows NT supported fork from the start in its POSIX subsystem, that subsystem was layered on top of the Native API, and this is the Native API mechanism that the POSIX subsystem employed. Although it took until Gary Nebbett for someone to publicly show how, even though people knew informally back in 1993.

This is an oft-overlooked point. An obvious place to look for improving fork+execve is to see whether posix_spawn can be given more efficient kernel mechanisms to be based upon.

And of course that has already been done. On NetBSD, posix_spawn() is a fully-fledged system call and much of the work is done in kernel mode.

* https://blog.netbsd.org/tnf/entry/posix_spawn_syscall_added

These discussions were definitely had back in the 20th century too. The spawn model versus the fork+execve model has been an on-going debate since the time of MS/PC/DR-DOS.

As mentioned elsewhere on this page, Windows NT had fork from the start. Vide NtCreateProcess and what happens if an image file is not explicitly supplied.

* https://computernewb.com/~lily/files/Documents/NTDesignWorkb...

Actually, there is a native fork. There had to be, as POSIX personality support was a part of the Windows NT 3.1 design. What there wasn't was a Win32 form of fork. The Native API for Windows NT allowed it quite straightforwardly.

Heh! The Unix didn't embrace the idea of file descriptor 3 meaning something specific. (-:

* https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html

Interestingly, on MS/PC/DR-DOS file descriptor 3 was stdaux. and file descriptor 4 was stdprn.

You may be mixing up fork and exec. Library data state isn't retained over execve(), and O_CLOEXEC does not take effect at fork().

Windows NT was never designed with pre-386 machines in mind. That was the territory of the old DOS+Windows. Windows NT from the get-go was for machines with page-based virtual memory.

* https://computernewb.com/~lily/files/Documents/NTDesignWorkb...

Sort of. It's also footway when denoting the no-carriages part of a road that also has a carriageway.

There's a whole complex terminology of footway, cycleway, bridleway, bridle path, footpath, cycle path, and carriageway. Even more fun: It's ever so slightly different in Scotland to England, Wales, and Northern Ireland.

* https://legislation.gov.uk/ukpga/1984/54/section/151

Not having a written constitution is not the same as not having rights in everyday practice.

That response looks like it is generated from boilerplate, so the 'reported to the authorities' part is as likely true as when sudo says the same thing.

* https://postimg.cc/3kVXKzhk

Interesting. My first thought is wondering whether the keyboard HID is adding report IDs to its input reports, because it isn't in boot mode or something. That would have that effect.

I'm not from GL. I write my own USB HID handlers and I'm being nosy about bad protocol that exists in the wild. Was the 0 byte in some input report? In a descriptor? Somewhere else?

This really isn't factually based. MFT entries are conceptually equivalent to i-node table entries. And the execute bit is what traversal checking bypass is all about.