FreeDOS and UEFI

DOS specific questions.
xlucas
Posts: 334
Joined: May 09, 2014 21:19
Location: Argentina

Re: FreeDOS and UEFI

Post by xlucas »

Hey, guys... I think the problem with DOS running on new computers today is not the BIOS, but the hardware. That is, if the hardware were the same, really most BIOS functions are never called by most programs. If it were worth it, I agree it'd be relatively easy to create a "BIOS" that would load first, as if it were the OS and then run the DOS "boot sector" or whatever. The thing is DOS programs would use direct access to hardware a lot. For example, joysticks. There were BIOS functions for that, but games would go to the hardware instead.

The great confusion about the idea of a "new DOS" is that DOS was mostly not DOS, but hardware access, so now, with a different hardware, we need to define what a new DOS would actually "mean". If what one's looking for is the ability to run old software then DOSBox is perfect for that. I think that people who feel that we need a new DOS somehow, are not thinking about backwards compatibility: they are thinking about a form of operating and programming a personal computer. What a new DOS should be is something that resembles old DOS and feels like old DOS when you're programming, not something that actually can run old software. My honest opinion. What do you guys think?

Oh... and I don't mean just easthetically. What I mean is to recover the good aspects of DOS, like being fast and simple, not requiring updates, not depending on the internet, allowing direct access to hardware, etc. For some projects, a system like that would be much more comfortable than a modern one.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeDOS and UEFI

Post by marcov »

I think the core problem is that modern hardware is not that simple anymore.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FreeDOS and UEFI

Post by angros47 »

DOS is a low level OS, and it offers much less abstraction than other operating systems. It can be a good thing in terms of speed and memory usage, but it also makes porting more troublesome.

A programming language like GCC, FreePascal, or FreeBasic can be ported to a different platform: one would only need to rewrite the backend, keeping the front end unchanged, and then most programs written in these languages could be compiled on the new platform.

On the other end, an Assembler (NASM, for example) can't be easily ported to a different platform: the instruction set would be different, so to deal with it the front end would need to be changed, too, and if you rewrite both front end and back end you basically rewrite the entire compiler. Also, all the old sources would not work any more, and would need a massive rewriting.

For operating systems, Windows or Linux can be compared to high level languages like GCC, FreePascal or FreeBasic, while DOS can be compared to ASM: a change in the underlying architecture, for Windows or Linux, would not be a big issue, since the system API would remain the same, while for DOS it would basically require a totally different OS.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeDOS and UEFI

Post by marcov »

angros47 wrote:DOS is a low level OS
I rather say minimalistic than lowlevel. And working through a firmware (BIOS), rather than managing the chips themselves is also not exactly lowlevel. The other OS in the same category (abstraction is done more by firmware than OS) are the older versions of Classic MacOS (say before 6/7 after which them became PM), but that has evolved into a larger abstraction over the years.

Basically it only abstracts disk, and tiny, minimalistic, portions of kbd and video. Logically, since it is an Disk Operating System.

But that Disk abstraction also never evolved (to e.g. busmaster out of the box), because the bootloaders (the actual target of bioses) didn't need that.
It can be a good thing in terms of speed and memory usage, but it also makes porting more troublesome.
Well, if you can use it all in the first place. Many dos extenders have memory limits, and second core is extreme experimental at best.
A programming language like GCC, FreePascal, or FreeBasic can be ported to a different platform: one would only need to rewrite the backend, keeping the front end unchanged, and then most programs written in these languages could be compiled on the new platform.
I wouldn't be surprised if a major GCC backend is actually more lines than dos io.sys
On the other end, an Assembler (NASM, for example) can't be easily ported to a different platform: the instruction set would be different, so to deal with it the front end would need to be changed, too, and if you rewrite both front end and back end you basically rewrite the entire compiler. Also, all the old sources would not work any more, and would need a massive rewriting.

For operating systems, Windows or Linux can be compared to high level languages like GCC, FreePascal or FreeBasic, while DOS can be compared to ASM: a change in the underlying architecture, for Windows or Linux, would not be a big issue, since the system API would remain the same, while for DOS it would basically require a totally different OS.
I don't see the HLL<->assembler to Dos->other OS analogy. It seems to too far fetched. Moreover HLL programs are not necessarily portable. go32v2 programs can use a lot of dos features, just like the asm does. Free Pascal has a nearly complete assembler internally (AT&T AND Intel style), and gcc also has internal assembler support (though afaik more limited due to different purpose).

But yes, changing API will break some programs, and there will be porting required. And the problem is that the dos community should have splitted long ago into a retro/demo orientd group (like e.g. C=64 and Amiga and other old target), and a more modernly oriented group around e.g. DJGPP+FreeDOS trying to make the most of the target, and e.g. working with a large shared library to create more API and commonality between dos apps. Nothing is wrong with either group, but IMHO they simply don't belong together anymore.

Or at least say 10-13 years ago, I hoped that would happen eventually, but FreeDOS progress (and people flocking to FreeDOS) has been less that I had hoped. So my guess is the retro group will be the survivors. The rest will move on to other OSes to get work done, and occasionally boot a VM in spare time out of nostalgia.
angros47
Posts: 2321
Joined: Jun 21, 2005 19:04

Re: FreeDOS and UEFI

Post by angros47 »

marcov wrote: I rather say minimalistic than lowlevel. And working through a firmware (BIOS), rather than managing the chips themselves is also not exactly lowlevel. The other OS in the same category (abstraction is done more by firmware than OS) are the older versions of Classic MacOS (say before 6/7 after which them became PM), but that has evolved into a larger abstraction over the years.

Basically it only abstracts disk, and tiny, minimalistic, portions of kbd and video. Logically, since it is an Disk Operating System.
Actually, BIOS in origin wasn't even supposed to be a firmware. Before DOS, BIOS was used on the CP/M operating system, and it was stored on disk, just like the rest of the system. At the time, a lot of microcomputers used the same processor (for example, Apple, Commodore 64 and BBC used the 6502, while MSX, Spectrum, and Amstrad CPC used Z80): but it was not possible to run the same program on different brands, even if they used the same processor, because memory mapping was different (so, even if the processor could run the code, video memory was in a different location, for example, and so nooutput could be produced). To fix that, an operating system that was able to run in the same way on all those different hardware was needed, and that OS was CP/M: it consisted in three part, the CCP that processed console commands, the BDOS that managed file i/o and the BIOS that executed the hardware interfacing commands: CCP and BDOS were provided by Digital Research, and were identical for all computers using that version of CP/M, while BIOS was produced by the hardware manufacturer and changed for different models.

When IBM developed the PC, they planned to use CP/M 86 (a version made for 16 bit processors), but they failed to find an agreement for the license, so they commissioned a clone for CPM from Microsoft, that bought a quick and dirty clone (QDOS, literally Quick Dirty OS) from Seattle Computer Products, made some small changes and called it MS-DOS.

They also made an 8 bit version of dos for MSX, called MSX DOS, that, just like CP-M, had the BIOS on disk.



Or at least say 10-13 years ago, I hoped that would happen eventually, but FreeDOS progress (and people flocking to FreeDOS) has been less that I had hoped. So my guess is the retro group will be the survivors. The rest will move on to other OSes to get work done, and occasionally boot a VM in spare time out of nostalgia.
I agree. Personally I would have hoped to see something like DesqView, but free and open source, for DOS. Or some more development for GEM
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeDOS and UEFI

Post by marcov »

Note that bios INT emulation alone won't cut it. Too many programs use port60-something ($66/$67?) for lowlevel kbd, and many programs do Direct Screen Writes (DSW). And then there is COM and LPT via ports for those who need it.

IOW you'd need to get such peripherals (kbd,mouse,com,lpt) in the suitable compatible modes too, when legacybios is gone. As long as you can write an UEFI loader to plugin UEFI abstractions to do so that is maybe doable. But in practice such options work at the beginning, but the ability atrophies over time.

Most motherboards already startup in graphics mode (a vesa LFB alike mode) to show logos and for their UEFI interface (*). Console only *nix often also works in LFB mode.

Is textmode actually mandatory for UEFI? Because if VGA can't be inited in something appropriate anymore, that is probably the end of the line.

(*) which I dislike btw, I think the old spartan bioses were much quicker navigable, since it was doable to do kbd only.
Post Reply