DOS ain't dead

> Not sure if anyone has implemented
> Posix on the 8086.
>

There were quite a few of 8086 based implementations of UNIX that conformed to POSIX. More or less. Xenix and Venix are one example.

There were also clones like Coherent and Minix. They have some POSIX conformance. Not sure on what level, though.

If you mean POSIX on top of DOS, there were several projects I'm aware. Quite a few of them being educational. If I remember right, Vsta had a version that ran on top of DOS.

P.S. Sorry for butting in late in the discussion. :)

[del]

---
Make DOS great again!
Make Russia small again!

> Yes, in VM with a small disk with single partition probably everything
> works fine, I belive.. But out in the wild you can expect more oddities. I
> guess it may be similar problem like with FreeFdisk discused some months
> ago here - partitions starting at misaligned CHS values, as today on SSD
> many partition tools don't align to CHS but LBA, e.g. start 1st partition
> at 1MB... Just try your system on some real large partitioned HDD...

I want to stick with USB sticks until I can get
that working to my satisfaction. PDOS doesn't
yet have the necessary support tools to be a
standalone system. It still relies on fdisk and
format from Freedos, but I realized that I should
be able to write tools to manipulate a VHD image
instead.

I assume that CHS and LBA are mutually exclusive?
Or can you write code, including a boot sector, that
gracefully detects whether you are on an LBA-capable
system and switch to LBA?

I really need these exact switching rules to be
encapsulated in public domain source code that is
part of PDOS.

BFN. Paul.

> I assume that CHS and LBA are mutually exclusive?

Not at all. You simply use the LBA detection int 13 call and if that is positive, you are allowed to use LBA style disk access. You can always stick to CHS, but of course CHS has the added complexity that the same LBA sector can have different CHS locations depending on how your current geometry is arranged, for example based on your BIOS CMOS settings. But of course there also is an int 13 call to query the current CHS geometry

> Or can you write code, including a boot sector, that
> gracefully detects whether you are on an LBA-capable
> system and switch to LBA?

Of course, yes. The detection is simple, just write your own public domain code to use it. From RBIL:

INT 13 - IBM/MS INT 13 Extensions - INSTALLATION CHECK
AH = 41h
BX = 55AAh
DL = drive (80h-FFh)
Return: CF set on error (extensions not supported)
AH = 01h (invalid function)
CF clear if successful
BX = AA55h if installed
AH = major version of extensions
01h = 1.x
20h = 2.0 / EDD-1.0
21h = 2.1 / EDD-1.1
30h = EDD-3.0
AL = internal use
CX = API subset support bitmap (see #00271)
DH = extension version

Bitfields for IBM/MS INT 13 Extensions API support bitmap:
Bit(s) Description (Table 00271)
0 extended disk access functions (AH=42h-44h,47h,48h) supported
1 removable drive controller functions (AH=45h,46h,48h,49h,INT 15/AH=52h)
supported
2 enhanced disk drive (EDD) functions (AH=48h,AH=4Eh) supported
extended drive parameter table is valid (see #00273,#00278)
3-15 reserved (0)

One of the reserved bits later got used to indicate support for linear pointers to RAM, I think even supporting 64-bit pointers for buffers beyond your first 4 GB of RAM, for int 13 LBA calls. Read the updated EDD specs for details if you want to use that feature.

See int 13 functions 08 and 48 for details about checking the current CHS geometry. To access sector contents, use functions 2 and 3 for CHS or 42 and 43 for LBA style.

---
FreeDOS / DOSEMU2 / ...

> > I assume that CHS and LBA are mutually exclusive?
>
> Not at all. You simply use the LBA detection int 13 call and if that is
> positive, you are allowed to use LBA style disk access. You can always
> stick to CHS, but of course CHS has the added complexity that the same LBA
> sector can have different CHS locations depending on how your current
> geometry is arranged, for example based on your BIOS CMOS settings. But of
> course there also is an int 13 call to query the current CHS geometry

Thanks for your message full of information.

I think this knowledge needs to be encoded in
C90 code.

Note that PDOS/386 is now able to run the gccwin
C compiler, so it is now a mini Windows development
environment. Self-contained download is now available
from http://pdos.org

That is basically proof of concept done.

And that has now been extended to comms too. You
can see how I drive COM1 to access a news server
using pure C90 code, here:

https://groups.google.com/g/comp.lang.c/c/bYF6sl6z-MI

I think a sensible goal at this stage would be for
PDOS/386 to boot on every, or at least, most,
80386-based computers. Sort of with the goal that
the right geek will be sitting in front of an
obscure computer, boot PDOS as more-or-less the
only OS that actually works, and then proceed to
fix an important bug in PDOS.

What was theoretically possible with an 80386
processor? It could have been married to what
BIOS and hard disk? (ie I am looking for very
old configurations)

So starting from the MBR, and working within the
512-byte limitation (including FAT-32 restrictions),
what should have been done, with the benefit of
hindsight?

Thanks. Paul.