Re:Writing a simple operating system from scratch (2010) [pdf]
by chungy on Friday March 25, 2022 @01:30PM
(#30804962)
Windows 3.1, 95, 98, Me all did exactly the thing described as "more trouble than it is worth"; they are 32-bit protected mode operating systems[0] that makes frequent context switches to 16-bit mode and utilize BIOS functions.
[0] Yes, I know, Windows 3.1 applications were almost always 16-bit unless you installed Win32S. It's somewhat complicated.
Re:Writing a simple operating system from scratch (2010) [pdf]
by smhenderson on Friday March 25, 2022 @04:42PM
(#30806845)
I guess in their case they had so much already written code to work with BIOS calls it was worth adding the shim layer. But if you were to start tomorrow with no legacy code then it would be more trouble than it's worth.
Re:Writing a simple operating system from scratch (2010) [pdf]
by chungy on Friday March 25, 2022 @05:32PM
(#30807254)
That is the story of Windows NT after all :)
Re:Writing a simple operating system from scratch (2010) [pdf]
by afr0ck on Friday March 25, 2022 @12:29PM
(#30804139)
If you are running your OS on a VM hypervisor (e.g.; Qemu, kvmtool), then you can just use virtio for disk and network I/O. No boring and complex device specification (e.g.; ATA) to implement.
Re:Writing a simple operating system from scratch (2010) [pdf]
by rmasters on Friday March 25, 2022 @01:09PM
(#30804694)
Yeah, I'm avoiding modern interfaces due to my peculiar bootstrapping requirements (e.g. must run on old HW; no SW dependencies). virtio is probably a better choice for anyone trying to build something practical. On the other hand, it looks like using virtio would need a lot more code than accessing the BIOS and I couldn't easily find examples in assembly.
"So what this means is that a 32-bit operating system must provide its own drivers for all hardware of the machine (e.g. the keybaord, screen, disk drives, mouse, etc). Actually, it is possible for a 32-bit protected mode operating system to switch temporarily back into 16-bit mode whereupon it may utilise BIOS, but this teachnique can be more trouble than it is worth, especially in terms of performance."
--
In the toy 32-bit OS I am currently writing, having easy disk access and text output was more important to me than performance, so I decided to implement this technique to access the disk and screen via the BIOS instead of writing an ATA disk driver.
Although I could not find any minimal yet complete working examples of dropping to 16 bit and later resuming 32 bit mode, I was able to piece it together and write assembly functions called enter_16bit_real and resume_32bit_mode. See https://github.com/ironmeld/builder-hex0/blob/main/builder-h.... Those routines are working well but beware the project is a volatile work in progress and is coded in hex for bootstrapping reasons.