Red Hat's "obfuscated" kernel source [LWN.net]

Red Hat's "obfuscated" kernel source

Posted Aug 8, 2012 19:22 UTC (Wed) by hummassa (guest, #307)
In reply to: Red Hat's "obfuscated" kernel source by jengelh
Parent article: Red Hat's "obfuscated" kernel source

> Remember the day when an operating system was just the 100-or-so files in C:\DOS

Twenty. There were roughly twenty files. DIR C:\DOS did not scroll, nor paused, nor "more"'d or "less"'ed. It just showed less then twenty files, and a little bit less than 120K bytes free space (in a 160k disk).

*sigh* the follies of youth...

to post comments

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 11:03 UTC (Sat) by Jonno (subscriber, #49613) [Link] (2 responses)

FOUR (4) files (io.sys, msdos.sys, config.sys, command.com), the rest was not the OS, just utilities distributed together with the OS.

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 17:24 UTC (Sat) by hummassa (guest, #307) [Link] (1 responses)

not all computers had config.sys or autoexec.bat... :-D Technically, MS-DOS was msdos.sys. io.sys was the "device driver pack" and command.com was a (changeable) shell.

Red Hat's "obfuscated" kernel source

Posted Aug 11, 2012 21:50 UTC (Sat) by Jonno (subscriber, #49613) [Link]

io.sys was not a driver pack loaded by msdos.sys, it was in fact the "core" kernel image that also included some io drivers needed to load msdos.sys (e.g. for disk drives and filesystem). In Linux terms it would be equivalent to /boot/vmlinuz.

msdos.sys, on the other hand, was auxiliary kernel functionality loaded by io.sys. The closest things in the Linux world would be loadable kernel modules in /lib/modules. In MS-DOS 7 (only sold bundled with the Windows 9x Desktop Environment) all code from msdos.sys has been merged into io.sys, and in FreeDOS the combination has been renamed kernel.sys.

config.sys was a text file parsed by msdos.sys (or io.sys in MS-DOS 7). Essentially it was the DOS equivalent of the Linux cmdline (on modern x86 systems usually specified in the Grub configuration file). It also allowed loading additional kernel modules and specifying parameters to them (eg replacing the modprobe utility). While not strictly required, still definitely part of the OS.

command.com was the entry point for userspace code. Not part of the kernel, but still part of the OS. In GNU/Linux terms it would be a merge of /sbin/init and /bin/sh as well as most of coreutils. While replaceable, replacing it would pretty much make a different OS with the same kernel (think Android vs GNU/Linux).

I didn't mention autoexec.bat, it was not part of the OS, but a way to autostart non-os stuff on your computer, essentially the DOS equivalent of /etc/rc.local.