OSDev.org

From BIOS detecting the hard drive's MBR, and the MBR putting IO.SYS and MSDOS.sys into memory and initialing the IO.SYS. Would the command.com be user-mode application? I'll look at the command.com through a hex editor to see if I see an MZ. I only have seen the MZ in the first type bytes of Windows 3.11 win.exe and I believe setup.exe of Windows 3.11.

If I'm right about command.com being user-mode, IO.SYS and MSDOS.SYS would be in kernel mode. Correct? Kernel Mode and User Mode is somewhat blurry to me. I get that kernel mode is 0 ring and user mode is ring 3. Ring 0 would indicate most privledge and have access to everything on the hardware. Whereas, user-mode does not and has to ask permission from the kernel to get access or manipulate hardware such as reading from disk.

Currently, I'm following a tutorial that does UEFI in C++. So far, I really do like it. However, he hasn't uploaded a newer video. I just want to start off small like a command line interpreter.

The below workflow or so far what I have in my head:

Computer Boots -> UEFI -> My Kernel -> My Kernel Finds System.Bin (or something) -> Reads Config (System.Conf) -> Finished with all initialization -> Launch Terminal.exe (Command line Interpreter).

Am I going in the right direction with this idea?

MS-DOS runs in real mode and real mode has no kernel / user mode concept. Rather, everything runs in kernel mode. OTOH, if you run MS-DOS under another OS, then the applications can run in user mode (in V86 mode) and the MS-DOS API can be virtualized by the host operating system so the system services actually run in kernel mode.

Still, if you plan to do something with UEFI, the operation of MS-DOS is not relevant.

rdos wrote:MS-DOS runs in real mode and real mode has no kernel / user mode concept. Rather, everything runs in kernel mode. OTOH, if you run MS-DOS under another OS, then the applications can run in user mode (in V86 mode) and the MS-DOS API can be virtualized by the host operating system so the system services actually run in kernel mode.

Still, if you plan to do something with UEFI, the operation of MS-DOS is not relevant.

Ah. Okay. Can I still go from kernel mode and make a C++ program with my own API to gain access or ask permission to my kernel's mechanics? If my kernel has a disk read function, and my custom API used by my future applications to ask permission for the kernel to read disk.

if kernel function is: _kReadDisk.
My Api function is: ReadDisk.
My future applications in user mode would include my API and use the ReadDisk function.
That's what I believe what I'm aiming for.

That's what system calls are for - to allow a user application to call a kernel routine.

iansjack wrote:That's what system calls are for - to allow a user application to call a kernel routine.

Thank you.

To answer your direct question, the kernel is still software. It just has higher privileges. Now in the MS-DOS case, all software has the same privileges, as @rdos pointed out. But, however, MS-DOS wise, IO.SYS and MSDOS.SYS (and to a lesser extent, the BIOS) are considered the "kernel" per se.

SIC88 wrote:I'll look at the command.com through a hex editor to see if I see an MZ

That won't do you much good, as the MZ header is used for EXE files, not for COM files.


JAL