DOS ain't dead

Why don't you just run the SETUP program as instructed in the documentation?

Of course it stops booting, if you mess up the boot sector with FreeDOS's FDISK. Don't do that.

It is a documented thing that ST-DOS (or rather its bootloader) does not currently support booting from a partitioned disk. The SETUP program creates a filesystem that starts from the first sector of the disk. FreeDOS on the other hand is hardcoded to assume that a hard disk always has MS-DOS-compatible partition table.

The SETUP program is hardcoded to always use C: as the target drive, which makes it impossible to install ST-DOS on computers that don't have a floppy drive. ST-DOS always starts counting drive letters from A:, and when it is booted from an USB storage stick on a computer that does not have floppy drives, the USB storage stick usually becomes drive A: and the first hard disk becomes B:. This problem does not affect VirtualBox users, because VirtualBox does not support booting from USB anyway.

I have purposely made the SETUP program in such way that it has as few options as possible, because for some reason people just cannot choose the right options even when it should be obvious what to choose. Seems that everything still has too much options.

There is no "Win3" UI and the TEXTEDIT program does not have vi mode. Almost nothing in your messages make any sense.

On DOS the TEXTEDIT program sometimes corrupts the files for some reason, when the caret position is on the second column and backspace is pressed. I haven't found the cause of that bug yet. The POSIX port of it works correctly, which makes it difficult to debug. Because the graphical interface has the NOTEPAD program, it is not a big issue.

For some reason FreeDOS's CHKDSK shows errors in the floppy disk image, but the directory entry for COMMAND.LNK in the \LEETOS\DESKTOP\ directory has its size just right and it is not 0 bytes. CHKDSK nor SCANDISK from MS-DOS 6.22 don't show any errors. I need to write my own CHKDSK program in the near future.

I fixed two memory bugs from the kernel. There were two pointers that were supposed to be far pointers to far pointers, but they were instead near pointers to far pointers. That caused the kernel to save the pointers to int23h and int24h interrupt handlers to its own stack instead of the PSP of the currently running program.

ST-DOS can add and remove filesystem during runtime, but it has to be done via syscalls. The SETUP program does the necessary syscalls to mount the beginning of the first hard disk to the C drive. Then it detects the geometry of the hard drive and calls FORMAT with the correct arguments.

> You are using it wrong.

OK, I use levy16032024 now.
Lets start from beginning:
I boot up from A: and execute directly "format c:" or "format drv:c"
format shows that there is no HD, no cylinders, sectors, etc.
It seems that the HD is not found although it is inside. What has to be done
to get an fdisk/format access to it? If I remember right, it has NOT to be mounted when running such a basic thing?
When I execute "setup" it suddenly offers the HD informations and runs format.
But: After rebooting I get a boot message: ......ERR that runs through.

After booting from diskette I entered "sys c:" and get an error message.
Only the example for "sys" explained the reason: "sys drv:c" has to be entered
.
After this I rebooted from HD and I get a boot message: ......ERR that runs through again.
As "drv:c" is unusual for me, would it be possible to add it at all commands where it is needed? Thx.
So much for now.

Fritz

You are using it wrong.

> I have made a lot of bug fixes. Also the install programs are now easier to
> use than before, and CD-ROM drivers and keyboard layouts are installed
> automatically. I wrote some instructions:
>
> http://sininenankka.dy.fi/leetos/start.php
>
> Also I made the TCP/IP stack bug compatible with Intel's newer packet
> drivers, which seem to have even the most basic functions completely
> broken.

Hi,
I am only a small user, but I have installed several DOS versions x times.
I admire your plan to create a DOS with a Win3 clone, but I think it will be too much work
for a single person, companies with a lot of people created something like this over years.
So I also fear that you will give up some day and leave an unfinished work
I ran several tests with ST-DOS and only one time I was able to install ST-DOS and lEET/OS
via the ST-DOS install command on a 500 MB HD in virtual box. All other trials
did not find a C: drive and tried to install to a:. No idea why.

Where shall I start with my problems? Hm, hard to say:

If you run the diskette first time you notice that there is no fdisk but only a format command.
So I booted up from FDT2403 (freedos trial CD) and executed fdisk on a virtual 500 MB HD
(FAT16) from there. It worked, but booting from levy diskette and executing format then
started and showed absolutely strange values (63222 Bytes per Sector, sectors per cluster
246, reserved sectors 63222, FATS: 246, sectors per track 63222, heads 63222 etc.

After one successfull installation via levy diskette I started latest FD fdisk and got
THREE NON DOS partitions as a result.
I also tested the levy diskette via FDT2403 and checkdsk a: /f and got the following result:
The file system string does not indicate FAT12.
This is generally not an error, but some low level disk utilities may not handle
this correctly.
\LEETOS\DESKTOP\command.lnk has an invalid size, the size should be about 512, but the entry
says it's 0 (I assume this comes from an installation trial to C:\leetos).

After this the diskette did no longer boot. I mounted the levy diskette image with IMDISK in
Windows and removed the folder DESKTOP - unmounted it and it still does not boot.
My forensic tool does not recognize the diskette and only two unpartitioned spaces at the working image too.
And this tools knows all these partitions on modern systems.

There are several other problems that I had, one (little) missing feature is a missing CP850/858
keyboard support, textedit works a little in vi style (please no discussion about this), which
makes it harder to modify config / autoexec, problems with mouse moving via keyboard, the symbols
on the "Win3" UI are almost invisible and you can almost not see which symbol is marked by mouse.

In case that you are interested in more tests, please send a mail to my name on the left side @mail.com.

Fritz

I have made a lot of bug fixes. Also the install programs are now easier to use than before, and CD-ROM drivers and keyboard layouts are installed automatically. I wrote some instructions:

http://sininenankka.dy.fi/leetos/start.php

Also I made the TCP/IP stack bug compatible with Intel's newer packet drivers, which seem to have even the most basic functions completely broken.

OK, so I understand that UEFI boot env. doesn't allow direct HW and memory access otherwise UEFI stuff would break. So then only way would be write a regular UEFI application that implement some hypervisor or port DOSBOX-X but it will lost the advantage of native DOS run and could be achieved simply by running some tiny Linux with DOSBOX-X on top - we already have such DOSBOX-X version...
BTW had you look at Tkchia UEFI code if there's something interesting?
https://codeberg.org/tkchia/muefircate

---
DOS gives me freedom to unlimited HW access.

If the "operating system" uses UEFI boot services, it is not an operating system - it is just a UEFI program. In that case the operating system is the UEFI.

UEFI has its own dynamic memory management. UEFI programs cannot just write to arbitrary memory addresses like operating system kernels do. The program has to do every memory allocation via UEFI boot services. That causes a serious problem, because some peripherals (such as graphics cards) have memory and/or registers that are mapped to some known physical address range in the CPU's memory address space.

Also some peripherals may not be usable without exitting from UEFI boot services. It may be unsafe and/or cause undefined side effects if the UEFI program tries to control those peripherals directly. Many peripherals are stateful from the programmer's perspective and the driver program needs to constantly know their state.

The UEFI specification has a large and constantly growing number of those so-called boot services and many of them aren't implemented in most UEFI implementations. In many cases the implementations are buggy and unusable. The only thing that is actually tested by the manufacturers is that it boots Windows.

UEFI boot services are not the same thing as BIOS runtime services. They are not meant to do the same things.

> I don't know any DOS program that uses VT-x

That does not mean that they don't exist, or will not exist in the near future. One of the basic principles of DOS is that the currently running program is in full control of the computer, so DOS programs can do basically anything.

I disagree. I mean, I agree with samwdpckr in that writing an entire UEFI-aware DOS is not a meaningful solution, neither is anything that requires us to come up with a cr*pton of drivers whenever a new motherboard is introduced, but it's not mandatory to leave boot services. And UEFI provides boot services to just about every part of the computer. He mentioned v86 as a way to avoid memory conflicts, that wouldn't work for the exact reasons he's said, but I don't know why everybody forgets VT-x when talking about these topics. I don't know any DOS program that uses VT-x, so if we have a BIOS, that can be loaded as an UEFI application and that initializes a VT-x session right away without ExitBootServices(), it would work.

We have a bunch of open source BIOS surfaces already. We just need someone with the skills, free time and enthusiasm of somebody like Crazii to replace tha back end of literally any of those (ranging from the one in DOSBox to SeaBIOS) with a UEFI translation layer. Or less skills but more free time. Or even less skills and even more free time.

Not only that it would work but also it might be even more effective than most of the things we already have, I mean, it would be a great opportunity to integrate many functions into one single program from a packet interface for UEFI network services through memory management to sound card support and fixing video output. And philosophically it would still be just as native as doing all these things separately with various v86 hacks.

---
DOS isn't about why. It's about why not.

Sorry I mixed it with boot services, they has much rich capabilities and allows run various UEFI apps like UEFI shell and fancy graphics bootloaders...
https://uefi.org/specs/UEFI/2.9_A/12_Protocols_Console_Support.html
But I understant that it would has memory conflicts with RM - DOS. It might be solved by writting a hypervisor but it's too complex and makes not much sense when can boot some standard OS with some VM...

---
DOS gives me freedom to unlimited HW access.

> UEFI doesn't mean that you have to handle all the HW by yourself. UEFI
> offers runtime services and drivers for accessing storage (HDD, USB),
> keyboard and framebuffer.
> https://wiki.osdev.org/Using_UEFI_Runtime_Services_in_your_Kernel

Those UEFI runtime services are listed in the OSDev article:


        Efi_Get_Time                    GetTime;
        Efi_Set_Time                    SetTime;
        Efi_Get_Wakeup_Time             GetWakeupTime;
        Efi_Set_Wakeup_Time             SetWakeupTime;
        Efi_Set_Virtual_Address_Map     SetVirtualAddressMap;
        Efi_Convert_Pointer             ConvertPointer;
        Efi_Get_Variable                GetVariable;
        Efi_Get_Next_Variable_Name      GetNextVariableName;
        Efi_Set_Variable                SetVariable;
        Efi_Get_Next_High_Mono_Count    GetNextHighMonotonicCount;
        Efi_Reset_System                ResetSystem;
        Efi_Update_Capsule              UpdateCapsule;
        Efi_Query_Capsule_Capabilities  QueryCapsuleCapabilities;
        Efi_Query_Variable_Info         QueryVariableInfo;


I don't see anything related to disk or console I/O.

> But problem is that UEFI starts in 64-bit long mode (old 32-bit UEFI are
> probably no longer developed and supported) that makes it problematic to
> cooperate with realmode DOS (not sure if possible do some 16-64b mode
> switches safely without destrying UEFI structures).

UEFI does not have a standardized memory map like BIOS does. UEFI has only a limited set of functions that do not alter the memory map - the only boot services that are guaranteed to NOT alter the memory map are ExitBootServices() and GetMemoryMap() (if I remember their names correctly). BIOS-based operating systems, on the other hand, assume that everything starting from memory address ~60:0 to the kilobyte count in address 40:13 is safe to be used by the kernel. If there happens to be UEFI code or UEFI structures in that memory area, it will create problems.

UEFI has been designed (probably on purpose) in such way that it is NOT possible to create a universal "BIOS shim" that would work with every operating system that uses BIOS. Of course it would be possible to create something that uses the virtual-86 mode of x86 processors and run the DOS operating system inside that, but it would then be extremely hard to implement an environment that could also run DOS extenders and other 32-bit DOS applications. Most likely it would also have problems with accessing many I/O ports and handling interrupts. And also that "shim" would need to support every piece of hardware separately.

On top of that, UEFI cannot boot anything if the boot disk does not have a GPT partitioning table. The bootable binary (usually the bootloader of the operating system) must be a PE-formatted file in a FAT32 filesystem - also known as the "EFI partition". Most operating systems aren't even compatible with GPT partitioning, which isn't even a good partitioning scheme to begin with.

> That's not technically possible. IBM PC-compatible BIOS has runtime
> services, and simple operating systems (including various DOS
> implementations) use them to access the hardware.

Yes I know. Currenly almost every DOS compatible OS rely on BIOS services. But some time ago user Tkchia presented some attempts that could lead to run something like DOS on UEFI-only machine. But he relied on legacy VGA BIOS module that is disappearing too, at least on my working-NTB so I couldn't try it out.

UEFI doesn't mean that you have to handle all the HW by yourself. UEFI offers runtime services and drivers for accessing storage (HDD, USB), keyboard and framebuffer. https://wiki.osdev.org/Using_UEFI_Runtime_Services_in_your_Kernel

But problem is that UEFI starts in 64-bit long mode (old 32-bit UEFI are probably no longer developed and supported) that makes it problematic to cooperate with realmode DOS (not sure if possible do some 16-64b mode switches safely without destrying UEFI structures). Tkchia would definitely tell you more details and how he did it. I just see he has some updates on his repo, so to have a look https://codeberg.org/tkchia/muefircate
He's quite brief here but giving some idea what is possible: https://codeberg.org/tkchia/muefircate/src/branch/main/doc/NOTES.asciidoc

---
DOS gives me freedom to unlimited HW access.

> As one key feature I would
> see the ability to boot on new UEFI CSM-less systems as they are spreading
> out.

That's not technically possible. IBM PC-compatible BIOS has runtime services, and simple operating systems (including various DOS implementations) use them to access the hardware.

It's thanks to those runtime services that DOS always worked on everything, from the original IBM PC and XT machines with SCSI drives and MDA/CGA monitors to the "new" computers with IDE or SATA drives and graphic adapters that may not be even fully compatible with VGA.

BIOS made it possible to develop operating systems without having to write individual drivers for each piece of hardware. The operating system did not need to access the hardware directly - instead it could just call the standardized universal BIOS services to do basic things like disk I/O and write text on the screen or capture keystrokes.

With UEFI that is no longer the case. Now every operating system has to have driver code for every possible hardware combination out there. It should not come as a surprise that writing drivers for every piece of hardware is just not possible for small operating system developers who write operating systems as a hobby.

UEFI is Microsoft's plan to stop people from making their own indie operating systems. They want a future where everyone will use either Windows or a Microsoft-signed version of Linux.

It also seems that many new computers have firmware bugs that completely prevent them from booting any other operating systems than Windows and maybe Linux. I have some new laptops that cannot even boot Linux. In most UEFI machines the so-called CSM module is so buggy and badly implemented that it cannot really do anything, and even the basic BIOS int 13h services are broken.

> > to be implemented in long years stagnating FreeDOS or EDRDOS?
> stagnating because most bugs are fixed?

No. However, I vaguely remember a discussion on the FD mailing list some years ago about releasing FreeDOS v2.0 - the new "features" for this version, as it was suggested, would have been to remove some "unused" packages.

If that isn't a strong sign for stagnation, then what?

---
MS-DOS forever!

> Nice, we have more YADs (Yet Another DOS).
not exactly. operating system that is mostly compatible with the documented DOS API is not yet another DOS. a LOT of DOS compatibility is about the undocumented API.

> Wouldn't we rather see such
> modern features
what modern features? windows 2.0 in 2024?


> to be implemented in long years stagnating FreeDOS or
> EDRDOS?
stagnating because most bugs are fixed?


> OK, I don't want to beat down the enthusiasm. Sometimes it's better to
> start from a scratch than fight with some old sub-optimal decisions and
> compromises that made someone else in the past. As one key feature I would
> see the ability to boot on new UEFI CSM-less systems as they are spreading
> out. There was some attempts but... Adopting GPT and exFAT would be a good
> step.
This just tells me that you have not the faintest clue about *any* OS kernel programming.
"sub-optimal decisions and compromises" and "GPT and exFAT" are entirely unrelated.

Nice, we have more YADs (Yet Another DOS). Wouldn't we rather see such modern features to be implemented in long years stagnating FreeDOS or EDRDOS? I understand it's exciting to write own DOS. On the other hand it usually ends with a bunch of incomplete abandoned projects that cannot fully replace old good MS-DOS that I still keeps as a reference for compatability.

OK, I don't want to beat down the enthusiasm. Sometimes it's better to start from a scratch than fight with some old sub-optimal decisions and compromises that made someone else in the past. As one key feature I would see the ability to boot on new UEFI CSM-less systems as they are spreading out. There was some attempts but... Adopting GPT and exFAT would be a good step. Good luck with the project.

---
DOS gives me freedom to unlimited HW access.

> The bootloader has to support the operating system that is going to be loaded.

https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/boot/metakern/metakern-11oct2003.zip

metakern.bin by Eric Auer - FreeDOS MetaKern boot menu, classical version

copy /b metakern.bin + bootsect.1 metakern.sys

bootsect.1=bootsector ST-DOS

The boot process will FIRST load metakern.sys which will THEN offer to
load either the "other OS"

See doc:
Allows to install several DOS / Windows kernels
Allow up to 4 boot sectors, 4 partitions, 3 drives

My Triple boot floppy image

http://www.multiboot.ru/temp/metakern.ima

Boot from old Ranish parition manager bootsector in MS-DOS 8.0 by hold "Ctrl" button or direct to FreeDOS MetaKern boot menu:
1. ST-DOS
2. Free DOS
command.com is common for all DOS
type Ver for see version

> > Specfic to my project, using 86Box, I also have major crash (86box
> killed)
> > when using The CandyMan MULTBOOT loader (fixed bootloader that call a
> > multboot.sys file than incorporate the ST-DOS boot file and load it into
> > memory)
>
> You cannot just load an operating system with any bootloader. The
> bootloader has to support the operating system that is going to be loaded.

Thanks, but of course, I extract and use the correct floppy boot sector before testing. Here is my test bootdisk with the special CandyMan bootsector and the CandyMan tool 'Multboot.sys' with ST-DOS bootsector inside:
https://megawrzuta.pl/download/ce4787bfe6f8a2dd4b3c345a2d3a3a9a.html

> Hi, sadly it didn't support multi configuration in config.sys.
>
> Specfic to my project, using 86Box, I also have major crash (86box killed)
> when using The CandyMan MULTBOOT loader (fixed bootloader that call a
> multboot.sys file than incorporate the ST-DOS boot file and load it into
> memory)

The supported CONFIG.SYS directives are currently not very well documented. Basically SHELL means the user interface to be loaded (same as in MS-DOS), SHARGS means the args for the shell and DRIVER is for loading and running some programs (for example TSR drivers) for initializing the system before running the shell.

You cannot just load an operating system with any bootloader. The bootloader has to support the operating system that is going to be loaded.

Something about ST-DOS...
ST-DOS floppy images with a Free DOS boot sector work correctly with the ST-DOS kernel.
Great idea kernel prompt:
kernel >

In my opinion:
If there is no Config.sys file or there is no shell=... entry in the Config.sys file, the shell should load command.com by default
Loading shell - kernel.sys message not needed

Kernel.sys from ST-DOS properly work with Tiny DOS shell v0.01a - (c)2009 Richard L. James https://rayer.g6.cz/romos/rjdos.zip
SHELL=rjdos.exe in config.sys

Hi, sadly it didn't support multi configuration in config.sys.

Specfic to my project, using 86Box, I also have major crash (86box killed) when using The CandyMan MULTBOOT loader (fixed bootloader that call a multboot.sys file than incorporate the ST-DOS boot file and load it into memory)

> Some medias, for example optical disks, use larger sectors that cannot be
> emulated as smaller 512 byte sectors. Optical disks usually use sector size
> of 2 kB. Also floppies can have different sector sizes, and everything from
> 128 bytes to 1 kilobyte is commonly used. Floppies are always soft sectored
> and BIOS cannot do logical block addressing with them.

(totally irrelevant hardware detail:
Some of those media (like many SCSI early magnetoc-opticals and cdrom drives) could be jumpered to report 512 byte sector size for booting purposes)

> > adding GPT support should be easy. actually GPT partitioning is easier
> then
> > MBR due to the (slightly complicated) extended partitions.
> > GPT has only primary partitions.
> I know, but GPT is also very limited.
in what way is GPT limited, or even "very limited" and how would your partitioning scheme be better? what features would it add?


> > > I have designed my own partitioning scheme
> > > that supports unlimited number of partitions, but haven't implemented
> it
> > > yet.
> > Don't do that. use GPT.
> Why not?
creating a new partitionng scheme means you are not able to coexist with Windows/Linux/whatever on the same disk.
usually not so smart an idea.

> if you search the FreeDOS kernel for #ifdef FAT32 you should get an idea
> what to change for FAT32 support. it's surprisingly little differenz.
FAT32 is very similar to FAT12/16, but I would implement it as a dynamic filesystem driver. The static filesystem driver in the kernel binary supports only FAT12/16.

> "4k native": drives that present the internal 4k sector size - which is
> normal in modern disks - as 4K to the external world. Most disks emulate a
> 512 byte sectorsize, even modern ones.
The kernel should support different sector sizes, but it is hard to test.

> adding GPT support should be easy. actually GPT partitioning is easier then
> MBR due to the (slightly complicated) extended partitions.
> GPT has only primary partitions.
I know, but GPT is also very limited.

> > I have designed my own partitioning scheme
> > that supports unlimited number of partitions, but haven't implemented it
> > yet.
> Don't do that. use GPT.
Why not?

> AFAIK BIOS int13h extensions are implemented as 48-bit indexing in
> the year 2023.
Of course, but the API uses 64-bit numbers. Only the physical implementation has only 48 bits.

> Good luck on your project, and thanks for sharing with the community.
Thanks.


> Thanks for the explanation and, as your kernel seems to be using RAW
> sector-offsets, sector size shouldn't matter as to whether it's 512-byte
> native, 512-byte "emulated", or 4k-byte native.
Some medias, for example optical disks, use larger sectors that cannot be emulated as smaller 512 byte sectors. Optical disks usually use sector size of 2 kB. Also floppies can have different sector sizes, and everything from 128 bytes to 1 kilobyte is commonly used. Floppies are always soft sectored and BIOS cannot do logical block addressing with them.

> Never mind, of course there is not 2 TB limit when using UEFI int 13
> extensions. I was confusing the old DOS/BIOS 2TB limit and direct 64-bit
> index calls to int 13h.

This has nothing to do with UEFI.

> > Perhaps 4kn support,
> What is that?
Sorry, it is 4k-native sector support. As in, most hard drives are now made with 4096-byte sectors, as opposed to the old standard of 512 bytes/sector.

>
> > GPT and /
> The kernel itself does not support any partitioning tables at all. It has
> syscalls that are used to mount the filesystems from specific offsets on
> the disk. An external program is used to tell the kernel the correct
> beginning sector of every filesystem. Currently the mounter supports only
> MS-DOS-compatible partitioning. I have designed my own partitioning scheme
> that supports unlimited number of partitions, but haven't implemented it
> yet.
Thanks for the explanation and, as your kernel seems to be using RAW sector-offsets, sector size shouldn't matter as to whether it's 512-byte native, 512-byte "emulated", or 4k-byte native.

> I don't understand the question. BIOS int13h extensions use 64-bit indexing
> for sectors. There is no 2 TB limitation.
Never mind, of course there is not 2 TB limit when using UEFI int 13 extensions. I was confusing the old DOS/BIOS 2TB limit and direct 64-bit index calls to int 13h.

> > >
> > > Unfortunately it does not support FAT32
> > FAT32 support is critical, should be added.
> The kernel has a filesystem driver API that is currently read-only. A
> dynamic FAT32 driver would be good for testing the write side of things.
> Ext4 would also be cool.
>
> The kernel has a static driver for FAT12/16 filesystem, and I tried to
> write it so that the static driver can easily be replaced with something
> else.

if you search the FreeDOS kernel for #ifdef FAT32 you should get an idea what to change for FAT32 support. it's surprisingly little differenz.

>
> > Perhaps 4kn support,
> What is that?
"4k native": drives that present the internal 4k sector size - which is normal in modern disks - as 4K to the external world. Most disks emulate a 512 byte sectorsize, even modern ones.


> > GPT and /
> The kernel itself does not support any partitioning tables at all. It has
> syscalls that are used to mount the filesystems from specific offsets on
> the disk. An external program is used to tell the kernel the correct
> beginning sector of every filesystem. Currently the mounter supports only
> MS-DOS-compatible partitioning.
adding GPT support should be easy. actually GPT partitioning is easier then MBR due to the (slightly complicated) extended partitions.
GPT has only primary partitions.

> I have designed my own partitioning scheme
> that supports unlimited number of partitions, but haven't implemented it
> yet.
Don't do that. use GPT.

>
> The bootloader tells the kernel the offset of the system partition.
>
> > or exFAT support as well
> Writing your own drivers is a good way to contribute to the project.


>
> >, for > 2 TiB drives. Does this feature mean
> > internal support for your OS goes beyond the LBA48 2 TiB BIOS / LBA
> > limitation:
> I don't understand the question. BIOS int13h extensions use 64-bit indexing
> for sectors. There is no 2 TB limitation.
AFAIK BIOS int13h extensions are implemented as 48-bit indexing in the year 2023.
48 bit are sufficient for 256 TB. Still far away, but remarkably close compared
to the time when it was presented. at that time, 48 bit and Infinity was almost the same.


Good luck on your project, and thanks for sharing with the community.

> >
> > Unfortunately it does not support FAT32
> FAT32 support is critical, should be added.
The kernel has a filesystem driver API that is currently read-only. A dynamic FAT32 driver would be good for testing the write side of things. Ext4 would also be cool.

The kernel has a static driver for FAT12/16 filesystem, and I tried to write it so that the static driver can easily be replaced with something else.

> Perhaps 4kn support,
What is that?

> GPT and /
The kernel itself does not support any partitioning tables at all. It has syscalls that are used to mount the filesystems from specific offsets on the disk. An external program is used to tell the kernel the correct beginning sector of every filesystem. Currently the mounter supports only MS-DOS-compatible partitioning. I have designed my own partitioning scheme that supports unlimited number of partitions, but haven't implemented it yet.

The bootloader tells the kernel the offset of the system partition.

> or exFAT support as well
Writing your own drivers is a good way to contribute to the project.

>, for > 2 TiB drives. Does this feature mean
> internal support for your OS goes beyond the LBA48 2 TiB BIOS / LBA
> limitation:
I don't understand the question. BIOS int13h extensions use 64-bit indexing for sectors. There is no 2 TB limitation.

> Good luck on your project, and thanks for sharing with the community.
Thanks.

>
> Unfortunately it does not support FAT32
FAT32 support is critical, should be added. Perhaps 4kn support, GPT and / or exFAT support as well, for > 2 TiB drives. Does this feature mean internal support for your OS goes beyond the LBA48 2 TiB BIOS / LBA limitation:

8. 7. 2023: The kernel now supports BIOS int 13h enhanced disk drive extensions and hard drives that have a size of 2^64 sectors (which is 8589934592 terabytes when the sector size is 512 bytes). The standard build of the kernel also now works with the original IBM PC and XT.

Good luck on your project, and thanks for sharing with the community.

> Hello. I wrote my own operating system that is mostly compatible with the
> documented DOS API. It does many things differently than MS-DOS and FreeDOS
> - for example, it has dynamically growing caches and file buffers, which
> make disk I/O faster. It has driver APIs for device and filesystem drivers.
> Currently it has drivers for serial port, parallel port and CD-ROM drive
> and ISO9660 filesystem.

This is really impressive. I guess Finnish winters really are long, dark and boring

---
Javascript on MS-DOS? Try DOjS https://github.com/SuperIlu/DOjS
Fediverse: @dec_hl@mastodon.social

> Hello. I wrote my own operating system that is mostly compatible with the
> documented DOS API. It does many things differently than MS-DOS and FreeDOS
> - for example, it has dynamically growing caches and file buffers, which
> make disk I/O faster. It has driver APIs for device and filesystem drivers.
> Currently it has drivers for serial port, parallel port and CD-ROM drive
> and ISO9660 filesystem.
>
> Download page:
> http://sininenankka.dy.fi/~sami/fdshell/doskernel.php

Thanks!

Unfortunately it does not support FAT32