OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 7:59 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 7:21 am 
Offline
Member
Member
User avatar

Joined: Tue Mar 06, 2007 11:17 am
Posts: 1225
I have been thinking about the possibility to extend the original DOS and BIOS specifications without real modifications to the structure of the service calls.

Except that:

- Services could be called via reimplemented INT BIOS services or via individual direct functions with proper numbered names for the services.

- MORE IMPORTANT: For registers, we would extend all parameters to 32 or 64 bits depending on the register width for the corresponding CPU mode, and we would use a data structure to hold all registers, including FLAGS, instead of the registers themselves. For example, we would have WIDEAL, WIDEAH, WIDEAX..., and so on for all registers. and they all would be 32-bit or 64-bit wide, so that we could access the whole range of addresses of modern hardware devices with the same fundamental structure mostly used by the original BIOS.

- It would have its own Bios Data Area (BDA) also with all fields extended to full CPU register width, and would also have functions to get the current base address of all such system areas. It would contain all known BDA and EBDA fields.


The extent to which BIOS calls have been used indicates that such an extension for native 32 and 64 bits would be successful. It would be a simple yet valid and powerful low level platform API to be added as a system API library.

Register usage was simple enough using the BIOS so as to allow this reimplementation extension without fearing a bad design.

It would provide BIOS-like services in an uniform way to BIOS and xEFI-based systems.

It could be written purely in x86 Portable Assembly language so that the same code can really be reassembled to 32 or 64 bits without modifications to the code.

_________________
Live PC 1: Image Live PC 2: Image

YouTube:
http://youtube.com/@AltComp126/streams
http://youtube.com/@proyectos/streams

http://master.dl.sourceforge.net/projec ... 7z?viasf=1


Last edited by ~ on Mon Jul 03, 2017 1:44 pm, edited 3 times in total.

Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 7:36 am 
Offline
Member
Member
User avatar

Joined: Sat Dec 27, 2014 9:11 am
Posts: 901
Location: Maadi, Cairo, Egypt
DOS is ancient technology. So is BIOS really, but at least BIOS is still somewhat used today because it's still the only firmware on the PCs that don't support EFI.

EFI is what I would call a clean, 64-bit BIOS (and I recall reading somewhere that there is 32-bit EFI, too, but I don't know enough about it.) Even if EFI supports all the modern features an OS would use, in the end, it's just part of the firmware and shouldn't be used for anything other than booting. IMHO, the fun of OS development is controlling the hardware yourself, not hiding everything behind a BIOS/EFI function. Contrary to what others here may think, I don't get bored of writing many drivers for similar devices (like EHCI, UHCI, and OHCI for instance, which all have the same principles and purposes.)

Basically, instead of trying to make a new firmware, you can have two solutions instead: boot your OS from GRUB and let it do the dirty work for you, and you don't need to care if the system is BIOS or EFI or whatever. Or, write a BIOS boot loader as well as an EFI boot loader, and both boot loaders would hide the differences between the firmware interfaces, and pass a defined structure to your kernel, which would allow you to get information about the system (i.e. video mode, boot partition, ACPI tables, etc) without knowing what kind of firmware it is.

Unless your goal is to make a new firmware, there's no reason to make a new firmware or remake the BIOS.

_________________
You know your OS is advanced when you stop using the Intel programming guide as a reference.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 7:38 am 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
Why? What's the benefit? None?

If you're going to do it for fun for yourself, go for it. But don't think there's going to be anyone else using it, nobody uses BIOS/UEFI and nobody wants to. (Just in case it's not blatantly obvious, yes, during boot BIOS/UEFI is used, it's called bootstrapping).

Instead of doing BIOS stuff, why not create an OS which provides not the crappy BIOS services but real services applications actually want to use? Or if you are suggesting providing real OS services, then how is it "BIOS" and not kernel/OS?

And how exactly are you going to code it in assembly so that it can be assembled into both 32-bit and 64-bit binary? So one is protected mode and the other is long mode? How about paging, both do it? What interface will you use, interrupts?

Btw, if you want to make it easily portable between 32-bit and 64-bit, why not use a language more closely designed for that, ie. C or C++ or some other HLL?

And finally, you may want to look into coreboot/linuxbios/libreboot, somewhat overlapping area.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 7:43 am 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
The entire design of DOS is 16-bit real mode from the bottom to the top. The first problem you'll run into is that 32-bit memory addressing is entirely different to 16-bit memory addressing on the x86. And since all the 32-bit opcodes are different, you'll never be able to run existing DOS applications on a "32-bit DOS" unless you also write a compatibility layer (at which point you're either giving up the advantages of a 32-bit system or you might as well use an existing "compatibility layer" such as DOSBox.

There is an existing DOS "remake" though called FreeDOS. I don't know for sure but I'd guess that there's no aim to make it 32-bit.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 2:17 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

~ wrote:
I have been thinking about the possibility to extend the original DOS and BIOS specifications without real modifications to the structure of the service calls.


a) There's a large number of problems with BIOS that have nothing to do with the fact that it's designed for real mode. Most of these same problems apply equally well to DOS. One of the biggest problems is that for BIOS functions everything is "synchronous" (the caller has to wait until the function completes), and all modern hardware (and all useful OSs) are designed so that many things can happen in parallel (e.g. CPU/s doing useful work while disk controller/s are transferring data while network card/s are sending/receiving packets while USB controller/s are handling many USB devices while sound card is....).

b) For boot loaders (which is the only case where it's sane to use BIOS) it's possible to create a wrapper that that allows software to run in protected mode or long mode (with IRQs enabled) and use BIOS functions; by temporarily switching to real mode and back.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 7:54 pm 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
@Brendan: I agree with you, but we must face it having a Basic Input Output System for protmode and longmode wouldn't be so bad. It's true that BIOS is only used for booting nowdays, but it wasn't always the case. DOS was a pretty small and usable piece of software because it could rely on a standardized way to interact with the hardware. For example there were no disk controller driver or video card driver in DOS ever. Now we stuck with EFI, a beast that it horrible, over-complicated, difficult to use and (just like real mode BIOS) completely useless for anything other than booting. You cannot rely on it's BlockIO routines or GOP routines in run time. :-(

To the op: So I like the idea, but I wouldn't use interrupts. I think passing a BIOS structure pointer (with tables and function pointers, like EFI_SYSTEM_TABLE) in memory (like RSDT PTR) and register (like dl for boot drive in BIOS) would be sufficient and very easy to implement (on both hardware manufacturer's and kernel developer's side). It would also allow to use C as primary language for boot loaders and device drivers (which was one of the goals of EFI). But it's just a dream, I don't see any chance to change to industry and drop EFI in favour of a protmode/longmode BIOS.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 03, 2017 9:14 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

bzt wrote:
@Brendan: I agree with you, but we must face it having a Basic Input Output System for protmode and longmode wouldn't be so bad. It's true that BIOS is only used for booting nowdays, but it wasn't always the case. DOS was a pretty small and usable piece of software because it could rely on a standardized way to interact with the hardware.


Yes, once upon a time there was an OS that was a crippled piece of trash that sucked and died because it used BIOS (because end users didn't know better); but that is not a valid excuse to waste time on a new/modern crippled piece of trash that will suck and die (now that everyone has known better for over 2 decades).

bzt wrote:
For example there were no disk controller driver or video card driver in DOS ever.


DOS did (eventually) have drivers for CD-ROM (and "mscdex.com" to support file systems like ISO9660, etc), and did have drivers for SCSI controllers (and drivers for some network cards, and some sound cards, and...).

Of course (with or without drivers) the disk IO performance was extremely bad (no file caches, no prefetching in the background, no "buffered writes" in the background, etc); and (because of the lack of video drivers) lots of games had to have support for many video cards built into them (which wasn't as bad back when there weren't as many devices to support, but is incredibly silly now that there's so many).

bzt wrote:
Now we stuck with EFI, a beast that it horrible, over-complicated, difficult to use and (just like real mode BIOS) completely useless for anything other than booting. You cannot rely on it's BlockIO routines or GOP routines in run time. :-(

To the op: So I like the idea, but I wouldn't use interrupts. I think passing a BIOS structure pointer (with tables and function pointers, like EFI_SYSTEM_TABLE) in memory (like RSDT PTR) and register (like dl for boot drive in BIOS) would be sufficient and very easy to implement (on both hardware manufacturer's and kernel developer's side). It would also allow to use C as primary language for boot loaders and device drivers (which was one of the goals of EFI). But it's just a dream, I don't see any chance to change to industry and drop EFI in favour of a protmode/longmode BIOS.


Ironically; UEFI is mostly just a 64-bit DOS clone (single-tasking, simple/bad synchronous APIs, no protection, simple/bad FAT file system, etc), which is what OP wants to create.

Also note that (as far as I'm concerned) the OP is trying to invent an excuse to continue 20 years of failing to learn anything useful.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Tue Jul 04, 2017 2:28 am 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 280
Location: Private, UK
Brendan wrote:
Of course (with or without drivers) the disk IO performance was extremely bad (no file caches, no prefetching in the background, no "buffered writes" in the background, etc)


Actually, MS-DOS did have cached file I/O from the very start see the "BUFFERS" CONFIG.SYS setting. Additionally, later versions MS-DOS included "SmartDrive" that provided much better I/O caching, including buffered writes and prefetching. There were even DMA-enabled IDE drivers available for DOS. The main reason that I/O sometimes felt slow on DOS is because it was a single-tasking, single-threading OS with no async I/O API. While writes could be buffered by the likes of SmartDrive (or any of the similar third-party products), reads would always "block" the application. If they missed the cache, that would cause a noticeable "pause".

As for 32-bit DOS, it's not actually a new idea. For a while there was a project called "FreeDOS32" that aimed to create a 32-bit DOS-like OS (not actually related in any significant way to FreeDOS) with DPMI support. The DPMI (0.9) specification is basically a specification for a 32-bit DOS (1.0 was a cut-down version aimed solely at interfacing with 16-bit DOS) and when implemented by a 32-bit "host", like Windows 9x or NT, a DPMI application may well be executing exclusively 32-bit code from the application all the way to the hardware.

Even before DPMI, there was GEMDOS, a DOS-like OS implemented by Digital Research for the Motorola 68000 CPU architecture (which is 32-bit internally) back in the mid-1980s. It was used as the basis for the Atari ST series' "TOS". I've toyed with the idea of porting "MiNT", the evolution of TOS, with a lot of UNIX influence, to x86. Adding MS-DOS/DPMI compatibility wouldn't be all that difficult.

_________________
Image


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Tue Jul 04, 2017 4:21 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 1584
Brendan wrote:
Yes, once upon a time there was an OS that was a crippled piece of trash that sucked and died because it used BIOS (because end users didn't know better); but that is not a valid excuse to waste time on a new/modern crippled piece of trash that will suck and die (now that everyone has known better for over 2 decades).

It seems we don't agree on that. I think it wasn't crippled at all, I think the philosophy behind DOS/BIOS was brilliant (provide code for every device and use an uniform interface (ints) to use that, so that the OS does not need to have drivers). The only reason BIOS failed because it was realmode, and couldn't keep up with protmode. I'd like to point out that the Amiga used a similar architecture (drivers in ROM with unified interface) but there wasn't any processor mode upgrade or new device types and therefore it wasn't obsoleted.

Brendan wrote:
DOS did (eventually) have drivers for CD-ROM (and "mscdex.com" to support file systems like ISO9660, etc), and did have drivers for SCSI controllers (and drivers for some network cards, and some sound cards, and...).

As I said, BIOS failed to keep up with hardware improvements. Btw imho CDROM was really badly designed, it should have used the standard disk int interface as USB Floppies and disks do in the first place. Hardware manufacturers seems to have learned from CDROM's mistake.

Brendan wrote:
Of course (with or without drivers) the disk IO performance was extremely bad (no file caches, no prefetching in the background, no "buffered writes" in the background, etc); and (because of the lack of video drivers) lots of games had to have support for many video cards built into them (which wasn't as bad back when there weren't as many devices to support, but is incredibly silly now that there's so many).

Well, you can always have a specialized driver in your OS for full performance, but still it would be nice to have a Basic Input Output System in firmware. And please don't forget that games stopped shipping video card drivers by the introduction of VESA. Now VESA was a good way to extend BIOS imho. It followed the concept IBM engineers originally had at least.

Brendan wrote:
Ironically; UEFI is mostly just a 64-bit DOS clone (single-tasking, simple/bad synchronous APIs, no protection, simple/bad FAT file system, etc), which is what OP wants to create.

Agreed. The biggest problem with that is it's unusable after ExitBootServices. BIOS provided run time services, which is an undeniably better design imho. You can technically forget everything EFI related once your kernel is started, which simply renders the complexity of EFI ridiculous.

Brendan wrote:
Also note that (as far as I'm concerned) the OP is trying to invent an excuse to continue 20 years of failing to learn anything useful.

Well, partially agree. Yes, developing such a BIOS is pointless and there's not much to learn from it. But I think failing was caused by misusing the original BIOS concept, and not because the concept was bad. They should have introduced new int services for sound cards and another one for network cards for example, following the original structure (one int for every device, one for console, one for video, one for disks, one for keyboard etc.). The idea the OP has is great, it's just outdated by decades as the industry took a different path.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Tue Jul 04, 2017 5:00 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 923
Location: Finland
It is easy to see a few recurrent themes every time (MS-)DOS is mentioned. First of all, the implementation details are very bound with the actual operating system API although it should not have to be. If there is a sequence of system calls, "Open file", "Write file", and "Close file", nothing necessitates the use of real mode, BIOS, or some other firmware-provided service. The abstraction is good enough in this case. For other than file services, especially video and sound, there is no good abstraction and that is a problem.

The second theme is exaggeration. A DOS-like operating system is not a good reference for studying how modern operating systems work and this fact often gives a some kind of permission and acceptance to cut corners and claim that it did nothing right. Its disadvantages are clear enough so there should not be any need for beat it with partial-truths, e.g. no caches or buffered writes.

The intention of warning new developers is good, absolutely. A DOS gives enough attack surface to do it fairly.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Tue Jul 04, 2017 5:55 am 
Offline
Member
Member

Joined: Thu Aug 13, 2015 4:57 pm
Posts: 384
The bottom line is, if you create something as "crippled" as BIOS or DOS then you're not going to be able to do anything useful.

A) You do something as crappy as BIOS/DOS and it's only good for booting an actual OS
B) You do it "right" at which point your BIOS/DOS isn't "Basic" or DOS, it's a real OS

Option B is pointless as that's the purpose of the real OS, bolting it to the hardware/firmware doesn't make much sense. The only purpose of BIOS/UEFI is to provide bootstrap.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Tue Jul 04, 2017 5:57 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

bzt wrote:
Brendan wrote:
Yes, once upon a time there was an OS that was a crippled piece of trash that sucked and died because it used BIOS (because end users didn't know better); but that is not a valid excuse to waste time on a new/modern crippled piece of trash that will suck and die (now that everyone has known better for over 2 decades).

It seems we don't agree on that. I think it wasn't crippled at all, I think the philosophy behind DOS/BIOS was brilliant (provide code for every device and use an uniform interface (ints) to use that, so that the OS does not need to have drivers).


Every OS provides a uniform interface of some kind; the problem is that the uniform interface for DOS was extremely poor (even for a single-user, single-tasking, real mode OS on the hardware that existed back then). The OS *did* need drivers (including using BIOS and device ROMs as "pseudo-drivers", and including actual drivers designed for DOS), except that often it failed to provide any drivers and application developers were forced to be do it themselves (and ruin future proofing because you can't install new devices and expect old applications to support them).

The concept behind DOS was "let's recycle a piece of trash for the sake of getting something to market, without caring about how poorly designed it is" because everyone at the time (including IBM) expected PC to be dead within a few years anyway. It was never intended to be good.

bzt wrote:
The only reason BIOS failed because it was realmode, and couldn't keep up with protmode. I'd like to point out that the Amiga used a similar architecture (drivers in ROM with unified interface) but there wasn't any processor mode upgrade or new device types and therefore it wasn't obsoleted.


No; BIOS failed because it's a crippled joke (and "real mode" had nothing to do with that at all). Don't forget that protected mode came with virtual8086 mode specifically to allow old real mode code to be executed without much problem.

PC succeeded because hardware manufacturers were able to create new CPUs, new motherboards, new devices and new device types. Every other home computer (TRS-80, BBC Micro, Commodore 64, Amiga, ...) become obsolete because there wasn't competition among hardware manufacturers and there wasn't the flexibility to handle new devices or new device types.

bzt wrote:
Brendan wrote:
DOS did (eventually) have drivers for CD-ROM (and "mscdex.com" to support file systems like ISO9660, etc), and did have drivers for SCSI controllers (and drivers for some network cards, and some sound cards, and...).

As I said, BIOS failed to keep up with hardware improvements. Btw imho CDROM was really badly designed, it should have used the standard disk int interface as USB Floppies and disks do in the first place. Hardware manufacturers seems to have learned from CDROM's mistake.


Hardware manufacturers have nothing to do with software interfaces provided by firmware or OS. Firmware manufacturers learned that firmware is too inflexible to do much more than start an OS.

bzt wrote:
Brendan wrote:
Of course (with or without drivers) the disk IO performance was extremely bad (no file caches, no prefetching in the background, no "buffered writes" in the background, etc); and (because of the lack of video drivers) lots of games had to have support for many video cards built into them (which wasn't as bad back when there weren't as many devices to support, but is incredibly silly now that there's so many).

Well, you can always have a specialized driver in your OS for full performance, but still it would be nice to have a Basic Input Output System in firmware. And please don't forget that games stopped shipping video card drivers by the introduction of VESA. Now VESA was a good way to extend BIOS imho. It followed the concept IBM engineers originally had at least.


It went in waves. First games just used "int 0x10", then games came with built-in drivers to support better video modes, then VBE came along, then games came with built-in drivers for 3D acceleration (then DOS died).

bzt wrote:
Brendan wrote:
Ironically; UEFI is mostly just a 64-bit DOS clone (single-tasking, simple/bad synchronous APIs, no protection, simple/bad FAT file system, etc), which is what OP wants to create.

Agreed. The biggest problem with that is it's unusable after ExitBootServices. BIOS provided run time services, which is an undeniably better design imho. You can technically forget everything EFI related once your kernel is started, which simply renders the complexity of EFI ridiculous.


ExitBootServices is the thing I like most about UEFI. It gives a clear transfer of ownership (from "firmware owns all hardware" before ExitBootServices to "OS owns all hardware" after ExitBootServices); and signifies the point during boot where an OS's boot code no longer has to tip-toe around in fear of upsetting someone else's code and can actually start behaving like an OS.

bzt wrote:
Brendan wrote:
Also note that (as far as I'm concerned) the OP is trying to invent an excuse to continue 20 years of failing to learn anything useful.

Well, partially agree. Yes, developing such a BIOS is pointless and there's not much to learn from it. But I think failing was caused by misusing the original BIOS concept, and not because the concept was bad. They should have introduced new int services for sound cards and another one for network cards for example, following the original structure (one int for every device, one for console, one for video, one for disks, one for keyboard etc.). The idea the OP has is great, it's just outdated by decades as the industry took a different path.


They should've added new interfaces for sound and network, and replaced all the old "synchronous" APIs with APIs that aren't pure trash, and deprecated "A20 gate" and fixed the PIC chip configuration and forced "RTC date/time is UTC", and provided protected mode entry points capable of handling paging, and added support for multi-CPU and 3D accelerated video and scanners and full "print quality" printers and CD burners, and added support for "hot-plug everything" (starting with USB), and provided fault tolerance throughout all of that; and even if they did all of that I'd still say it's too inflexible for a competent OS developer to bother with.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 10, 2017 9:13 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1925
Location: Athens, GA, USA
Keep in mind also that (according to some) Gates originally proposed using a stripped-down version of Unix (which they had already been mooting as a platform for internal development use, and which would eventually become Xenix - Microsoft would go on to use it for over a decade, and didn't develop on their own OSes until Windows NT 4.0). IBM refused, not because of the technical limitations (which admittedly would have been significant) but because they didn't want to license Unix from Ma Bell. Also, the initial assumption was that CP/M-86 would be the dominant OS anyway; they only discussed the topic with MS because they needed something that was ready at launch, and a lower-priced alternative to CP/M ($200) and UCSD Pascal ($500) which could be shipped as the intro package.

MS-DOS was never meant to be in widespread use. The whole point of the IBM PC was to kill the home computer market off; things didn't go quite as planned. You have to understand that most people at IBM didn't just see it as a threat to their market share; they thought home computing (and before that, timesharing) was a bad idea, something dangerous that needed to be stopped for everyone's benefit. I had talks with ex-IBMers who still thought that way in 1993.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
Ordo OS Project
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Mon Jul 10, 2017 12:21 pm 
Offline
Member
Member
User avatar

Joined: Fri Feb 17, 2017 4:01 pm
Posts: 641
Location: Ukraine, Bachmut
Schol-R-LEA wrote:
and didn't develop on their own OSes until Windows NT 4.0

Funny, NT 3.1, 3.5 and 3.51 was made by Gods then? Until MS took over. :mrgreen:
and OS/2? despite IBM and their fanboys moaning, and pretending it was their only OS, according to Gordon Letwin, OS/2 completely had begun in MS. It wasn't called OS/2 then, but was started in MS by Xenix and MS-DOS folks.

bzt wrote:
Now we stuck with EFI, a beast that it horrible, over-complicated, difficult to use and (just like real mode BIOS) completely useless for anything other than booting. You cannot rely on it's BlockIO routines or GOP routines in run time. :-(

Seriously? Firmware for booting OS is "bad" because it's only for booting OS? Block I/O routines and GOP are made for OSLoaders and internal stuff like the Boot Manager to let you draw a cute boot selection menu and load those files. The decision to drop everything "Boot Services" related when passing control to an OS, is intentionally made to simplify the life for the OS, it is taking over and has its own fancy I/O and graphical stuff. And because of this it easily may throw away everything the FW had in memory, using it for its purpose. It is so easy for the specification to make all that stuff persistent, just claiming they should be Runtime Services. But why?
If a "modern" OS is going to use GOP for its graphical stuff and Block I/O for its I/O, then well, that OS is better off to not show up publicly. :D

UEFI is not "horrible", it's an unfair and not motivated statement. It's a nice constructor. I love its modularity and extensibilty. This is something all those unix clones makers should have learnt at least a bit.

PS. Really, for the OP, maybe you should take a look at UEFI? It in many ways looks similar to BIOS/DOS, it's very low level, but its modern. Maybe you will want to take a competition with (mostly) Intel guys writing Tianocore implementation and make your own UEFI for x86 and x64?
I, for example, clearly didn't go that way, because I wanted to make my work useful at least for a few others and thought it's way not smart to "compete" with corporations. So I decided to write UEFI on mips. xD But reasons vary for different people. Still, I think you would have a bigger user-base with your UEFI implementation than with the DOS one.

_________________
ANT - NT-like OS for x64 and arm64.
efify - UEFI for a couple of boards (mips and arm). suspended due to lost of all the target park boards (russians destroyed our town).


Top
 Profile  
 
 Post subject: Re: Planning Pure 32/64-bit Implementations of DOS/BIOS
PostPosted: Tue Jul 11, 2017 3:21 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 923
Location: Finland
zaval wrote:
If a "modern" OS is going to use GOP for its graphical stuff and Block I/O for its I/O, then well, that OS is better off to not show up publicly.


In this case there is a really small margin between a bad idea and an excellent idea. If using GOP as a "runtime" service (which is not possible unless firmware is in control, e.g. a UEFI application), it is a bad idea. If using a graphics mode set by GOP (and there is no native display drivers), it is an excellent idea.

In general, public opinion on firmware-assisted graphics mode setting is a little bit unthankful. It is always the criticism of what it is not than listing advantages of what it is. It is a good compromise. Everyone can get something on the screen without having a native display driver. By not having runtime services, we are leaving out a very problematic dependency. Passive (i.e. framebuffer) is very different to active (i.e. runtime code).

_________________
Undefined behavior since 2012


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page 1, 2  Next

All times are UTC - 6 hours


Who is online

Users browsing this forum: DotBot [Bot] and 274 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group