DOS ain't dead - I made my own DOS implementation

samwdpckr

07.12.2023, 05:07

I made my own DOS implementation (Announce)

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

CandyMan

07.12.2023, 22:17

@ samwdpckr

I made my own DOS implementation

Post reply

> 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 :-(

Zyzzle

07.12.2023, 23:58

@ CandyMan

I made my own DOS implementation

Post reply

>
> 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.

samwdpckr

08.12.2023, 02:43

@ Zyzzle

I made my own DOS implementation

Post reply

> >
> > 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.

tom

Germany (West),
08.12.2023, 15:52

@ samwdpckr

I made my own DOS implementation

Post reply

> > >
> > > 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.

samwdpckr

08.12.2023, 22:11

@ tom

I made my own DOS implementation

Post reply

> 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.

tom

Germany (West),
09.12.2023, 01:46

@ samwdpckr

I made my own DOS implementation

Post reply

> > 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.

marcov

09.12.2023, 11:29

@ samwdpckr

I made my own DOS implementation

Post reply

> 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)

nico7550 16.12.2023, 14:17 @ marcov	I made my own DOS implementation Post reply
	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)

samwdpckr

27.12.2023, 17:59

@ nico7550

I made my own DOS implementation

Post reply

> 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.

nico7550

28.12.2023, 08:31

@ samwdpckr

I made my own DOS implementation

Post reply

> > 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

0ffer

30.12.2023, 09:35
(edited by 0ffer, 30.12.2023, 09:48)

@ samwdpckr

I made my own DOS implementation

Post reply

> 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

Zyzzle

08.12.2023, 15:56

@ samwdpckr

I made my own DOS implementation

Post reply

> > 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.

SuperIlu

Berlin, Germany,
07.12.2023, 23:24

@ samwdpckr

I made my own DOS implementation

Post reply

> 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 :-D

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

0ffer

25.12.2023, 20:31

@ samwdpckr

I made my own DOS implementation

Post reply

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

RayeR

CZ,
31.01.2024, 17:13

@ samwdpckr

I made my own DOS implementation

Post reply

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.

tom

Germany (West),
31.01.2024, 22:02

@ RayeR

I made my own DOS implementation

Post reply

> 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.

Japheth

Germany (South),
01.02.2024, 08:32

@ tom

I made my own DOS implementation

Post reply

> > 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!

samwdpckr

01.02.2024, 15:36

@ RayeR

I made my own DOS implementation

Post reply

> 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.

RayeR

CZ,
01.02.2024, 19:01

@ samwdpckr

I made my own DOS implementation

Post reply

> 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.

samwdpckr

01.02.2024, 19:09
(edited by samwdpckr, 01.02.2024, 19:27)

@ RayeR

I made my own DOS implementation

Post reply

> 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.

RayeR

CZ,
02.02.2024, 05:22

@ samwdpckr

I made my own DOS implementation

Post reply

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.

KormaX

02.02.2024, 11:11

@ RayeR

I made my own DOS implementation

Post reply

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.

samwdpckr

02.02.2024, 20:20

@ KormaX

I made my own DOS implementation

Post reply

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.

RayeR

CZ,
11.02.2024, 15:52

@ samwdpckr

I made my own DOS implementation

Post reply

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.

samwdpckr 12.03.2024, 22:56 (edited by samwdpckr, 12.03.2024, 23:35) @ samwdpckr	I made my own DOS implementation Post reply
	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.

fritz.mueller

Munich, Germany,
15.03.2024, 14:49

@ samwdpckr

I made my own DOS implementation

Post reply

> 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

samwdpckr 15.03.2024, 20:46 @ fritz.mueller	I made my own DOS implementation Post reply
	You are using it wrong.

fritz.mueller

Munich, Germany,
16.03.2024, 20:01

@ samwdpckr

I made my own DOS implementation

Post reply

> 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

samwdpckr

16.03.2024, 23:11

@ fritz.mueller

I made my own DOS implementation

Post reply

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.

samwdpckr 18.03.2024, 01:52 @ samwdpckr	I made my own DOS implementation Post reply
	I added an RSS stream to the webpage. Also implemented DOS syscall 0x26 to the kernel.

fritz.mueller

Munich, Germany,
18.03.2024, 13:25

@ samwdpckr

I made my own DOS implementation

Post reply

Hi,
first of all I wanted to inform you that my posts were not meant to critizise you. This was simply a first test. I like testing new programs. There are often problems if I test a program / OS for the first time.
I just ran a second test with your latest version now. As I may have overlooked your email address on your website, I uploaded 35 zipped pictures on my website:

www.bootablecd.de/ST-DOS.7z

I hope you can see that ST-DOS sometimes behaves a little strange, e.g. it names the HD with 2 GB size "A" under special circumstances. The setup program says that it is possible to run format before installation. There is even a question if it was already formatted or not.
The most less helpful thing for me was the "GUI" (sorry for Win3).
I used in about the same background colour with the FreeDOS fish for my version 1.1.0 of the english online help and got a VERY LOUD cry: "With this colour the text is unreadable." I still cannot reproduce it on my website, but, sorry for that, with your GUI it is reproducable. For test purposes it would be very helpful to change the background from your "blue" (maybe you call it another colour) to white or something else. The marker for the actual "mouse position" (Meaning: which symbol is marked at the moment?) is invisible for me around most symbols, see pictures.
"vi": Maybe I used the wrong program.
At one picture I added the text Alt-c etc. Sorry, this was wrong.

Hope the pictures help you to understand what I talk about.

Fritz

samwdpckr

18.03.2024, 22:22

@ fritz.mueller

I made my own DOS implementation

Post reply

Thank you for your efforts in documenting the problems so thoroughly.

The installer of the graphical user interface cannot find the files, because you ran it from the root directory. That's why the "Getting started" instructions also say to run it from the LEETOS\ directory.

The TEXTEDIT program may be hard to use. I recommend using the NOTEPAD application in the graphical user interface.

On the last two pictures the operating system did not think that it was booted from a diskette. As I wrote earlier, it always starts counting drive letters from A:, so if you remove all diskette drives, the first hard drive becomes the A: drive. It works just as intended.

The colors of the graphical system can be changed by running the CONFIG.COM program from the LEETOS\ directory. You can also rename the SETUP.INI file so that it does not find it, which causes it to use CGA high-res display mode with only black-and-white colors. I understand that most modern LCD displays have terrible contrast ratios. On my display your screenshots look just fine.

You can get the mouse working by installing a mouse driver. Cutemouse works. Also you can try the KEYMOUSE.COM keyboard mouse emulator.

You don't have to press ALT when using the shortcut keys. Just press the underlined letter key.

fritz.mueller

Munich, Germany,
20.03.2024, 15:56

@ samwdpckr

I made my own DOS implementation

Post reply

Sorry, its me again.
Thank you for your new OS, but I think I will stop with tests now and maybe continue in a few months.
At the moment I think it is too early that users test it.

>On the last two pictures the operating system did not think that it was booted from a diskette. As I
>wrote earlier, it always starts counting drive letters from A:, so if you remove all diskette drives,
>the first hard drive becomes the A: drive. It works just as intended.

This makes it more complex. I have an old laptop where I need an external USB diskette drive.
And in virtual machines removing the whole diskette controller is not unusual.
In this case the autoexec.bat (maybe others too) has several "C:\" inside that have to be modified via notepad.
For reasons that I do not know notepad.app (started from GUI - filemanager - directory: \leetos\ - filenames: notepad.app) starts the notepad window and exits at once (maybe working directory or something else is wrong).

> You can get the mouse working by installing a mouse driver. Cutemouse works. Also you can try the
> KEYMOUSE.COM keyboard mouse emulator.

Cutemouse worked. But I was unable to add it in autoexec.bat because notepad.app did not work for me (see above).

> You don't have to press ALT when using the shortcut keys. Just press the underlined letter key.

Several message boxes do not have an underlined letter key, e.g. OK, help, YES/NO etc. which makes it harder to
work without mouse.

A doskey would be helpful to repeat the last commands (e.g. to fix a typo).
I tried german keyboards (mkeyb gr and keyb gr,850,C:\dos\keyboard.sys - file was there) - both did
not work, mkeyb seems to freeze)
One more strange behaviour: As I do not know the finnish keyboard, I typed through my keyboard layout
(asdfghjklöä etc.) and after in about 25 keys there is a strange behaviour that I have not seen on other
OSes till now: Especially after ' the "go back <--" button doesnt work and sometimes it is no longer possible
to add other characters too. I am sure you can tell me a reason for this.
Several tools got a freeze, I do not remember them all. One of them was mkeyb.
A "?" in command line (C:\?) that shows the commands built in command.com would be helpful too, see:
https://www.bootablecd.de/FreeDOS-Internet-version/help110-no-fish/en/hhstndrd/command/question.htm
Setting an alias in autoexec.bat seems not to be possible (I tried "alias install=a:\leetos\install.com" to avoid not working installations of leetos)

I tried to create a new shortcut for notepad - looks simple, but I did not get it with the shortcut editor. Could you add the correct syntax in the window where you have to enter the values (e.g. notepad or notepad.app, working directory: C:\leetos or whatever, icon file: xy.ico with path or no path, can an icon that is already in use be used a second time, how can I create a new icon etc). This are typical standard user questions.

Sorry, but I hope you can understand me now. Maybe this helps you to add some positions at the FAQs,
e.g. why does format not work although setup asks for it, why do I use a non standard system on the OS (even X-Ways Forensics does not recognize it, but IMDISK can mount it), why does the HD use A: when diskette drive is removed etc.

Thanks.

Fritz

samwdpckr

21.03.2024, 18:06

@ fritz.mueller

I made my own DOS implementation

Post reply

> This makes it more complex. I have an old laptop where I need an external
> USB diskette drive.
> And in virtual machines removing the whole diskette controller is not
> unusual.
> In this case the autoexec.bat (maybe others too) has several "C:\" inside
> that have to be modified via notepad.
I modified the command prompt. Now it creates an environment variable %COMDRV% when it starts. That environment variable is the drive letter of the command prompt. It can be used to make batch files that are independent from the drive letter of the current boot drive.

> For reasons that I do not know notepad.app (started from GUI - filemanager
> - directory: \leetos\ - filenames: notepad.app) starts the notepad window
> and exits at once (maybe working directory or something else is wrong).
Notepad needs a file to open. Otherwise it just exits. The file manager automatically opens files to Notepad when you click the "View" button.

> Several message boxes do not have an underlined letter key, e.g. OK, help,
> YES/NO etc. which makes it harder to
> work without mouse.
OK/Yes works by pressing Enter. No/Cancel works by pressing Escape. It is mentioned in the documentation.

> I tried german keyboards (mkeyb gr and keyb gr,850,C:\dos\keyboard.sys -
> file was there) - both did
> not work, mkeyb seems to freeze)
Most KEYB implementations that come with FreeDOS are dependent of some undocumented features of MS-DOS, and they will not work. ST-DOS's KEYB implementation is just a simple TSR program that replaces the default BIOS keyboard interrupt handler.

> One more strange behaviour: As I do not know the finnish keyboard, I typed
> through my keyboard layout
> (asdfghjklöä etc.) and after in about 25 keys there is a strange
> behaviour that I have not seen on other
> OSes till now: Especially after ' the "go back <--" button doesnt work and
> sometimes it is no longer possible
> to add other characters too. I am sure you can tell me a reason for this.
They are called "dead keys". I think the German keyboard layout does not have them.

The KEYMAPS.TXT file in the root of the install disk contains instructions how to create your own keyboard layouts.

> A "?" in command line (C:\?) that shows the commands built in command.com
> would be helpful too, see:
> https://www.bootablecd.de/FreeDOS-Internet-version/help110-no-fish/en/hhstndrd/command/question.htm
I will write a documentation for the command prompt. Currently it changes so much that I will not do it yet.

Now the SETUP program has a better support for installing from a USB storage stick. The target drive can also be changed, but the drive that it detects by default should usually be correct.

tom

Germany (West),
21.03.2024, 19:32

@ samwdpckr

I made my own DOS implementation

Post reply

> > I tried german keyboards (mkeyb gr and keyb gr,850,C:\dos\keyboard.sys -
> > file was there) - both did
> > not work, mkeyb seems to freeze)
> Most KEYB implementations that come with FreeDOS are dependent of some
> undocumented features of MS-DOS, and they will not work. ST-DOS's KEYB
> implementation is just a simple TSR program that replaces the default BIOS
> keyboard interrupt handler.

I'm not certain about *most* KEYB implementations, but I am certain that MKEYB does not rely on any MS-DOS feature, but interacts entirely with the BIOS.
and I think KEYB behaves (in this respect) identical.

samwdpckr 21.03.2024, 19:56 @ tom	I made my own DOS implementation Post reply
	> I'm not certain about most KEYB implementations, but I am certain that > MKEYB does not rely on any MS-DOS feature, but interacts entirely with the > BIOS. > and I think KEYB behaves (in this respect) identical. Then I need to investigate why it crashes.

fritz.mueller Munich, Germany, 21.03.2024, 22:14 @ samwdpckr	I made my own DOS implementation Post reply
	> Then I need to investigate why it crashes.

samwdpckr

21.03.2024, 22:21

@ tom

I made my own DOS implementation

Post reply

> I'm not certain about *most* KEYB implementations, but I am certain that
> MKEYB does not rely on any MS-DOS feature, but interacts entirely with the
> BIOS.
> and I think KEYB behaves (in this respect) identical.

MKEYB.C, line 76.

It changes DOS's internal undocumented memory allocation struct. That is why it crashes. It assumes that the underlying operating system is MS-DOS.

Whoever wrote that should go fix their program. Those memory allocation structs are not identical between different DOS implementations.

ecm

Düsseldorf, Germany,
22.03.2024, 00:21

@ samwdpckr

I made my own DOS implementation

Post reply

> > I'm not certain about *most* KEYB implementations, but I am certain that
> > MKEYB does not rely on any MS-DOS feature, but interacts entirely with
> the
> > BIOS.
> > and I think KEYB behaves (in this respect) identical.
>
> MKEYB.C, line 76.

That's https://github.com/davidebreso/mkeyb/blob/518d24d578dcb094b7f74800cd982bb4e4b7178b/mkeyb.c#L76

> It changes DOS's internal undocumented memory allocation struct. That is
> why it crashes. It assumes that the underlying operating system is MS-DOS.
>
> Whoever wrote that should go fix their program. Those memory allocation
> structs are not identical between different DOS implementations.

Actually they are identical among compatible DOS systems. The system call services with ax = 5800h to 5803h on int 21h are not "internal" to DOS.

---
l

samwdpckr

22.03.2024, 02:06

@ ecm

I made my own DOS implementation

Post reply

> Actually they are identical among compatible DOS systems. The system call
> services with ax = 5800h to 5803h on int 21h are not "internal" to DOS.
No, they are not identical.

In that Github page (which does not even work on Seamonkey, the page is just missing elements and the console contains no errors) the error is on line 92. It seems to be a different version of the program, but it also modifies the internal memory allocation structure of DOS.

ecm

Düsseldorf, Germany,
22.03.2024, 07:31

@ samwdpckr

I made my own DOS implementation

Post reply

> > Actually they are identical among compatible DOS systems. The system
> call
> > services with ax = 5800h to 5803h on int 21h are not "internal" to DOS.
> No, they are not identical.
>
> In that Github page (which does not even work on Seamonkey, the page is
> just missing elements and the console contains no errors) the error is on
> line 92. It seems to be a different version of the program, but it also
> modifies the internal memory allocation structure of DOS.

Okay well whatever revision of the file you have, in the repo that's https://github.com/davidebreso/mkeyb/blob/518d24d578dcb094b7f74800cd982bb4e4b7178b/mkeyb.c#L92

And yes, this does modify a DOS internal structure - it assumes the MCB format and how to make an MCB self-owned. This is not the same for all DOS systems but MS-DOS compatibles like (E)DR-DOS and FreeDOS do often use the same structures. My TSRs also assume that the MCB structure is compatible.

---
l

tom

Germany (West),
22.03.2024, 10:58

@ samwdpckr

I made my own DOS implementation

Post reply

> the error is on line 92.
*(short far*)MK_FP(allocSeg-1, 1) = allocSeg; /* makes it selfreferencing */ _fmemcpy(MK_FP(allocSeg-1, 8), MY_MEMORY_SIGNATURE, 8); /* mark our name */

> It seems to be a different version of the program, but it also
> modifies the internal memory allocation structure of DOS.

the MCB structure (while never documented by MS) has been documented since MSDOS 2.0. And been implemented this way by any selfrespecting DOS clone.

this is indeed problematic if you decide to run your own structure

struct mcb { unsigned next_mcb_seg; unsigned prev_mcb_seg; unsigned paragraph_count; unsigned owner_psp; // 0: normal memory block // 1: dta struct // 2: disk cache // 3: filesystem // 4: handle // 5: system unsigned char type; unsigned char __far *usercache_freedptr; };

also, all MEM like memory diagnostic tools will fail on your "operating system that is mostly compatible with the documented DOS API."

Time to move on...

tom Germany (West), 22.03.2024, 11:22 @ samwdpckr	I made my own DOS implementation Post reply
	as a sidenote: There is an undocumented undocumented feature of MSDOS that MSNET uses to make some MCB selfreferening. `oldPSP = getCurrentPSP(); setCurrentPSP(mcb); dosrealloc(mcb, mcb.currentsize); // this sets the owner of this mcb to PSP setCurrentPSP(oldPSP);` unfortunately, this doesn't work with ST-DOS either

samwdpckr 22.03.2024, 13:14 (edited by samwdpckr, 22.03.2024, 13:34) @ tom	I made my own DOS implementation Post reply
	Is there any good reason for the user program to modify that struct? Why would it want to make it "self-referencing"? Those memory control blocks are not even identical between different versions of MS-DOS. If you modify them, unpredictable things will happen.

tom

Germany (West),
22.03.2024, 14:12
(edited by tom, 23.03.2024, 07:32)

@ samwdpckr

I made my own DOS implementation

Post reply

> Is there any good reason for the user program to modify that struct? Why
> would it want to make it "self-referencing"?

Yes, absolutely.
It allows to allocate some memory (and copy resident code to it) which will
remain resident when the program calls exit().
There are other ways to stay TSR; but this has a couple of advantages.

> Those memory control blocks are not even identical between different
> versions of MS-DOS.
if you allow that later versions added a char name[8]; field, they are 100% identical. since 31 41 years. Since MSDOS 2.0. Across all DOS clones.

> If you modify them, unpredictable things will happen.
Nope. MKEYB demonstrates that it works very predictable.

samwdpckr

22.03.2024, 16:21
(edited by samwdpckr, 22.03.2024, 16:53)

@ tom

I made my own DOS implementation

Post reply

> Yes, absolutely.
> It allows to allocate some memory (and copy resident code to it) which will
>
> remain resident when the program calls exit().
> There are other ways to stay TSR; but this has a couple of advantages.

That does not require modifying the struct manually.

It is also not documented that the owner of a memory block changes when its size is changed. But I can easily change the behaviour of the kernel so that it works like that. Currently it does not change the owner.

The way the memory allocation structs are done in MS-DOS is inefficient and makes it slow to traverse the memory allocations backwards, especially when there is a large number of allocated memory blocks.

tom

Germany (West),
22.03.2024, 17:32
(edited by tom, 23.03.2024, 07:28)

@ samwdpckr

I made my own DOS implementation

Post reply

> > Yes, absolutely.
> > It allows to allocate some memory (and copy resident code to it) which
> will
> >
> > remain resident when the program calls exit().
> > There are other ways to stay TSR; but this has a couple of advantages.
>
> That does not require modifying the struct manually.
What other way would you propose?
>
> It is also not documented that the owner of a memory block changes when its
> size is changed.
I know. But MSDOS does exactly this.

> But I can easily change the behaviour of the kernel so
> that it works like that. Currently it does not change the owner.
>
> The way the memory allocation structs are done in MS-DOS is inefficient and
> makes it slow to traverse the memory allocations backwards, especially when
> there is a large number of allocated memory blocks.
Sure.

OTOH, you could place Type ('M' or 'Z'); owner and size in The proper location to solve the *this* problem.

samwdpckr

23.03.2024, 08:10

@ tom

I made my own DOS implementation

Post reply

I prefer keeping the struct members word-aligned.

Modifying a memory allocation now also changes its owner in the new version.

> What other way would you propose?
Probably the best way would be to change the memory allocation strategy _before_ the TSR program is loaded from the disk, or alternatively make sure that the TSR program is loaded to the lower addresses, before other programs like the command prompt are loaded. That way the memory is not fragmented. This shows how well it works:

[image]

The program can change the memory allocation strategy and then load another instance of itself to the memory using normal DOS syscalls.

If that is not possible, there are other ways to stay resident in memory so that the part of the program that stays resident is not the memory block with the original PSP, but they are all either relatively difficult to do or need modifying the internal structures of the kernel.

For example, the program could free its environment segment and file handles, allocate memory for the resident part, copy its own PSP to the resident part (with memcpy to make sure that the parent PSP does not change), change the current PSP to the new PSP, jump to the new PSP, free the old PSP and then exit via int21,ah=31.

ecm

Düsseldorf, Germany,
23.03.2024, 09:58

@ samwdpckr

I made my own DOS implementation

Post reply

> If that is not possible, there are other ways to stay resident in memory so
> that the part of the program that stays resident is not the memory block
> with the original PSP, but they are all either relatively difficult to do
> or need modifying the internal structures of the kernel.
>
> For example, the program could free its environment segment and file
> handles, allocate memory for the resident part, copy its own PSP to the
> resident part (with memcpy to make sure that the parent PSP does not
> change), change the current PSP to the new PSP, jump to the new PSP, free
> the old PSP and then exit via int21,ah=31.

Service 31h does have the problem that you need to keep a part of a/the PSP resident, at least 40h bytes though I'd go with 60h bytes. And as you mentioned a program using service 31h should free its process file handles unless it specifically wants to keep them around for later use. (Most programs using service 31h get this wrong.)

As also described in the link, my TSRs will relocate their initial process to the top of the LMA. This is done unconditionally, but the reason is to avoid fragmentation when installing without a suitable UMB being available. The process relocation can be disabled using a /J+P switch for insufficiently compatible systems. The final resident allocation is also made by allocating a new data block (with appropriate strategy and UMB link) and hacking its MCB, just like mkeyb.

---
l

tom

Germany (West),
23.03.2024, 12:20

@ samwdpckr

I made my own DOS implementation

Post reply

>
> The program can change the memory allocation strategy and then load another
> instance of itself to the memory using normal DOS syscalls.
That's pretty much nonsense.

> For example, the program could free its environment segment and file
> handles, allocate memory for the resident part, copy its own PSP to the
> resident part (with memcpy to make sure that the parent PSP does not
> change), change the current PSP to the new PSP, jump to the new PSP, free
> the old PSP and then exit via int21,ah=31.
I prefer my method.

samwdpckr

23.03.2024, 20:32

@ tom

I made my own DOS implementation

Post reply

Anyway, now the owner of the MCB changes when the realloc syscall is made, so modifying the internal structs is not necessary. I don't know if that works in FreeDOS, but because FreeDOS aims to be a 100% MS-DOS compatible operating system, it SHOULD work - if it doesn't, then it is a bug.

ST-DOS is not meant to be a clone of MS-DOS. Instead it is meant to be (mostly) compatible with the documented programming interface, so that it satisfies most already existing DOS programs and makes it easy to write new programs in such way that it works on both ST-DOS and FreeDOS. Many old CP/M syscalls are not supported, but I'll probably write a "compatibility TSR" that implements some syscalls that are currently not implemented in the kernel.

The main purpose of ST-DOS is to be as efficient 16-bit disk operating system as possible, and a software layer that provides basic I/O syscalls for accessing file systems and storage devices in Unix-like manner. If you need an MS-DOS clone, then you should just use FreeDOS.

samwdpckr

26.03.2024, 04:36

@ samwdpckr

I made my own DOS implementation

Post reply

New version. No new features this time, and no significant bugfixes either. In the filesystem mounter there was a bug that affected only builds with 64-bit LBA support when the BIOS supported LBA48 or higher. The program left the most significant doubleword of the "starting sector" of a filesystem uninitialized and it caused read errors. The default build of the kernel uses only 32-bit sector indexes anyway.

I did numerous small fixes to make the kernel support 64-bit sector indexing properly, so now it should work with larger than 2 TB hard drives. I cannot test it though.

I did also many micro-optimizations and reordered the arguments of many functions.

I wrote routines that calculate the sector indexes using MMX instructions. I thought that it would make the math with 64-bit integers a lot faster than adding, subtracting and comparing the numbers 16 bits at time in the 8086-compatible general purpose registers. In the end the MMX version turned out to be significantly slower, at least on a 3 GHz Pentium 4. This again shows that using new fancy instruction set extensions does not always make the program run faster, but it can very efficiently ruin compatibility with older hardware. The kernel can be compiled with "-dUSE_MMX" to create a build that uses MMX instructions.

The kernel can also be compiled for different targets than just 8086. I noticed that when it is compiled for i386 or newer CPUs, some programs just stop working. One of those programs is Doom's installer. I don't know why that happens.

The "VER" command of the command prompt now also shows the build target of the kernel.

samwdpckr

27.03.2024, 23:29

@ samwdpckr

I made my own DOS implementation

Post reply

My previous message did not make much sense. It turns out that MMX does only 32-bit math and many sources from the internet are wrong about this. I replaced the MMX routines with code that uses the 32-bit i386 registers. The new code is also much faster.

I also tried SSE2 instructions, but interestingly they were not much faster than MMX either.

Trying to replace 64-bit comparisons with hand-written routines seems to result in slow code. The reason is probably that the hand-written routines have to always have their return value in a general-purpose register, whereas the comparisons that the compiler generates natively have their "return value" in the flags register. So although comparing two 64-bit numbers in 16-bit registers means having to do four conditional jumps, it is still faster than a hand-written routine. AFAIK the Watcom compiler does not support having a return value of an actual function in the flags register. But replacing 64-bit additions and substractions with hand-written inline routines did speed things up a lot.

Symlinks can now point to device files. Previously they could only point to actual files.

The cache lookup table was previously a far object, but I moved it to the same segment with the kernel, which resulted in a small performance improvement.

Rugxulo

Usono,
28.03.2024, 01:29

@ samwdpckr

I made my own DOS implementation

Post reply

> My previous message did not make much sense. It turns out that MMX does
> only 32-bit math and many sources from the internet are wrong about this. I
> replaced the MMX routines with code that uses the 32-bit i386 registers.
> The new code is also much faster.

Keep in mind that MMX is still using the FPU behind the scenes.

> I also tried SSE2 instructions, but interestingly they were not much faster
> than MMX either.

You're using a 3 Ghz Pentium 4? Very quirky machines. SSE2 was first introduced with the Pentium 4, and is probably preferred for that machine (and default for AMD64). If it's not "faster" on that one machine, keep in mind that Pentium 4 had long pipelines and had no barrel shifter (i.e. shifts are slow) and other quirky things (use add 1 instead of inc). Even SSE2's bandwidth would greatly increase in later cpus, so it's definitely faster nowadays. GCC always had surprisingly good tuning for Pentium 4. Feel free to compare its output. Oh, and FXSAVE/FXRSTOR is faster than the old FPU way of saving things.

samwdpckr

28.03.2024, 04:15

@ Rugxulo

I made my own DOS implementation

Post reply

Nowadays many developers want to drop support of CPUs that don't have SSE2 instructions, and they are basically using those new instruction set extensions as a tool to bully people who have an "old" computer that still has more than enough computing power for their use. They are reasoning it by saying that the new instruction set extensions make the program run faster, when the reality is that every new version of the program is always more bloated than the previous one. This culture is especially visible amongst the Rust gang and the developers of many graphical desktop libraries in the FOSS world.

They are purposely writing code that breaks when sizeof(long) is not 64, and are writing makefiles that override the CFLAGS that the user has set, resulting in a binary that has a different CPU target than was intended by the user. This type of behaviour is unacceptable. When the program has zero lines of assembly, there is absolutely no reason to artificially limit its portability by preventing building it to certain CPU targets.

And my example shows that using those new instruction set extensions like MMX and SSE2 does not always even make the code faster. SSE2 can do 64-bit math natively, so there is less code involved in adding 64-bit numbers, and it should be faster in theory, but not always in practice. The user must always have the option to build and optimize the code for their own computer, even when the computer is "old" or something else than intended by the original developer of the software.

fritz.mueller

Munich, Germany,
28.03.2024, 21:19

@ samwdpckr

I made my own DOS implementation

Post reply

Only a few bug reports:
a) After installation of latest version including leetos I removed the diskette (controller still inside), rebooted and got a freeze.
Reason: HD changed to A: leetos still looks for "cd c:\leetos" instead of "%COMDRV%\leetos" and freezes.
b) It also freezes when I enter Z:\test (not existing drive)
c) edit: I tried to open A:\fdauto.bat (which does not exist), chose A:\autoexec.bat and get the error message: Syscall 44: Unknown function 09.
d) I entered mkeyb041 gr (german keyboard layout) and got a freeze.
e) I entered mkeyb050 gr /e 101keys keyboard and got a freeze.
e) I played 2kTetris (can be found at: https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/games/tetris/
It worked, but when game was over, I entered "n" (for no more game) and got a:
"KERNEL>_(blinking cursor)"
So much for today.

samwdpckr

29.03.2024, 18:00

@ fritz.mueller

I made my own DOS implementation

Post reply

I noticed that the symbolic links were completely broken. Now it seems to handle all corner cases correctly.

> Only a few bug reports:
> a) After installation of latest version including leetos I removed the
> diskette (controller still inside), rebooted and got a freeze.
> Reason: HD changed to A: leetos still looks for "cd c:\leetos" instead of
> "%COMDRV%\leetos" and freezes.
> b) It also freezes when I enter Z:\test (not existing drive)
Thanks. I fixed that.

> c) edit: I tried to open A:\fdauto.bat (which does not exist), chose
> A:\autoexec.bat and get the error message: Syscall 44: Unknown function
> 09.
I don't understand what you mean. But syscall 44 function 09 does not have to exist when MS-DOS compatible networking functions are not loaded, so that's not necessarily a bug in ST-DOS. Other DOS kernels just don't show that error message, and I intend to hide it in future versions.

> d) I entered mkeyb041 gr (german keyboard layout) and got a freeze.
> e) I entered mkeyb050 gr /e 101keys keyboard and got a freeze.
Memory control blocks in ST-DOS are different than they are in ST-DOS.

> e) I played 2kTetris (can be found at:
> https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/games/tetris/
> It worked, but when game was over, I entered "n" (for no more game) and got
> a:
> "KERNEL>_(blinking cursor)"
The game may have corrupted something in the memory. Not necessarily a bug in ST-DOS.

> Having said that, with all the malware / ransomware in the world, I think a
> lot of concerns for older hardware and software are related to security.

Instruction set extensions have nothing to do with security. If anything, unconditionally requiring these new instruction set extensions worsen the security, because that prevents some people from updating the software to the latest versions.

Rugxulo

Usono,
29.03.2024, 22:01

@ samwdpckr

I made my own DOS implementation

Post reply

> > Having said that, with all the malware / ransomware in the world, I think
> > a lot of concerns for older hardware and software are related to security.
>
> Instruction set extensions have nothing to do with security. If anything,
> unconditionally requiring these new instruction set extensions worsen the
> security, because that prevents some people from updating the software to
> the latest versions.

I think I meant older cpus are quietly deprecated due to such bugs (overeager speculative execution or whatever). There are many workarounds in the Linux kernel for such flaws, but the "oldest" Linux kernel still actively maintained (on kernel.org) is 4.19 from Oct. 2018. I'm sure distributions can still patch other kernels if needed.

But overall it's sometimes hard to find sympathy for old or weak tech. If it isn't actively sold, maintained, or doesn't receive security fixes (or microcode updates), some people refuse to care.

In a perfect world, any tech that could work should be potentially good enough (and not worthy of scorn).

I saw someone on Twitch stream Quest for Glory (EGA) via DOSBox. As you know, VGA was vastly more popular and easier to program. Still, EGA works on more machines and 320x200x16 colors is still "good enough" for some things. My point is we don't always forcibly have to use the "latest greatest", even if everyone else seems to be doing it. (We may both be preaching to the choir here.)

samwdpckr

29.03.2024, 22:31

@ Rugxulo

I made my own DOS implementation

Post reply

> I think I meant older cpus are quietly deprecated due to such bugs
> (overeager speculative execution or whatever).
Actually that's more of a problem with newer CPUs. Old pre-SSE2 CPUs don't do such things.

I just find it weird when a software developer, who doesn't even write assembly, suddenly says that someone else's computer is "too old" or "too slow" and must not be "supported" anymore. If we consider that that "someone else's computer" is a turing-complete machine that has enough memory to run the program in question, and has enough computing power that its owner does not consider it "too slow", the software developer should not have the right to say that it is.

The job of the software developer is to just maintain the program, and generally when we are speaking of relatively high-level userspace programs or their libraries, they compile to older x86 hardware just fine, unless something is actively preventing it from happening. Breaking compatibility with 32-bit x86 CPUs and/or pre-SSE2 CPUs will most likely also break compatibility with many non-x86 targets.

If the software developer only does their job and maintains the program so that it works efficiently, it also saves the environment because the users don't need to buy new computers to be able to continue using the program. In that case the program also consumes less electricity on newer machines.

Rugxulo

Usono,
08.04.2024, 03:19

@ samwdpckr

I made my own DOS implementation

Post reply

> I just find it weird when a software developer, who doesn't even write
> assembly, suddenly says that someone else's computer is "too old" or "too
> slow" and must not be "supported" anymore. If we consider that that
> "someone else's computer" is a turing-complete machine that has enough
> memory to run the program in question, and has enough computing power that
> its owner does not consider it "too slow", the software developer should
> not have the right to say that it is.

The CDC 6600 mainframe from 1964 was a 60-bit processor at 10 Mhz up to 982 kb of memory (almost a meg??) running 2 MIPS. It cost $2.4 million (equivalent to $23 million today).

Wikipedia says:

"Many minicomputer performance claims were based on the Fortran version of the Whetstone benchmark, giving Millions of Whetstone Instructions Per Second (MWIPS). The VAX 11/780 with FPA (1977) runs at 1.02 MWIPS. Results on a 2.4 GHz Intel Core 2 Duo (1 CPU 2007) vary from 9.7 MWIPS using BASIC Interpreter to 2,403 MWIPS using a modern C/C++ compiler."

In fairness, you shouldn't have to be a systems engineer with a PhD just to use or program a computer. Having said that, choice of OS, compiler, and algorithm make a big difference (depending on the requirements). It's NOT true that everyone born before 1990 was a rube who knew nothing, nor that their machines were incapable of "real work".

> The job of the software developer is to just maintain the program, and
> generally when we are speaking of relatively high-level userspace programs
> or their libraries, they compile to older x86 hardware just fine, unless
> something is actively preventing it from happening.

C is much better than assembly for portability, but it's still VERY flawed. A skilled developer can work around most of that, but most people don't care. It is NOT "strictly conformant by default". No amount of "standards" or warnings or lints or libraries can hide all of that for you. You just have to "test test test!" and work around any problems you find (whether preprocessor macros, patches, separate modules, libraries, external tools, etc).

So-called "UNIX" or "UNIX-like" or "POSIX" or sticking to GNU tools or Ubuntu LTS does not save you from portability problems. There used to be a saying: "all the world's a VAX!" (see the Jargon File). VMS and Windows NT were both from Dave Cutler and somewhat considered anti-UNIX in philosophy. In other words, OS-specific code is nothing new. (And yet Cutler insisted that Windows NT be portable from the beginning. Too bad most other cpu makers like MIPS, Alpha, PowerPC couldn't compete with Intel.)

EDIT: You may prefer to hang around more sympathetic people (e.g. NetBSD or OpenBSD) rather than Linux.

fritz.mueller

Munich, Germany,
17.05.2024, 12:49

@ Rugxulo

I made my own DOS implementation

Post reply

Hi,
I ran one more test of ST-DOS with version 2024-05-16 in virtualbox.

I added some DOS programs to see what works and what not.

a) mkeyb gr lead to a blinking cursor, nothing else (I think I already
reported this). It would be great to have at least some other keyboards than US and finnish.
b) fdshell 0.10 (dosshell) lead to a freeze after the first basic information.
dosshell /? showed the help and exited.
c) fd edit worked but froze at "save as - filename" After a regular exit without saving I got an unknown system call 38Child exited with return code 0
d) doszip (dz) lead to a blinking cursor after start.
e) ctmouse seems to work
f) editor Blocek lead to a blinking cursor.
g) game blkdrop showed some code and exited with: Child exited wirth return code 243
h) game flpybird lead to a message: Child exit
i) game sayswho seemed to work - not absolutely sure - but after exit (ESC) the whole sourcecode ran through on screen and I got a message Child exited with return code 0
j) game senet seemed to work.
k) NewDOS browser seems to work but after exit the whole sourcecode ran through.
l) NewDOS calculator seems to work, after exit sourcecode ran through.
m) NewDOS scandrv -> same
n) NewDOS cleandsk -> same
o) NewDOS scanfix: Syscall44: Unknown function09
p) NewDOS setdate: changed Date but after exit sourcecode ran through.
q) It would be nice if "dir" would support "dir /w".

Rugxulo

Usono,
29.03.2024, 02:53

@ samwdpckr

I made my own DOS implementation

Post reply

Rugxulo

Usono,
30.03.2024, 10:16

@ samwdpckr

I made my own DOS implementation

Post reply

> Nowadays many developers want to drop support of CPUs that don't have SSE2
> instructions, and they are basically using those new instruction set
> extensions as a tool to bully people who have an "old" computer that still
> has more than enough computing power for their use.

Those kinds of people upgrade every few years, maybe because of their workplace forcing them. They probably don't have the same import taxes or high shipping costs as you.

Also, when a compiler (or library) drops support for a certain OS or cpu family, someone else has to take up that burden or leave it abandoned. If one piece is missing, it's easy for the whole thing to crumble. "Tier 1" is almost always AMD64 (v2?) and maybe ARM64.

> They are reasoning it
> by saying that the new instruction set extensions make the program run
> faster, when the reality is that every new version of the program is always
> more bloated than the previous one. This culture is especially visible
> amongst the Rust gang and the developers of many graphical desktop
> libraries in the FOSS world.

CLMUL (circa 2010) claims to be faster. Have I ever used it? No.

I did, years ago, find 2x speedups in PAQ8 with his SSE2 patches. Actually, at that time, MMX or SSE2 was roughly the same speed. SSE2 improved more later. But my fork wasn't locking anyone in to specific OSes or cpus. (His default build was MinGW G++ 3.4 targeting MMX using MVSCRT.DLL that had a stupid tmpfile() bug on non-Admin Vista, so I rebuilt with newer DJGPP using CPUID. And I wanted CWSDPMI support so that it could swap to disk if needed. OpenWatcom/Causeway also worked but much less efficiently [worse malloc, slower swapping].).

Oscar Wilde said, "A cynic is someone who knows the cost of everything and the value of nothing."

> They are purposely writing code that breaks when sizeof(long) is not 64,
> and are writing makefiles that override the CFLAGS that the user has set,
> resulting in a binary that has a different CPU target than was intended by
> the user. This type of behaviour is unacceptable. When the program has zero
> lines of assembly, there is absolutely no reason to artificially limit its
> portability by preventing building it to certain CPU targets.

While I 100% agree, strict ISO C has never been meant to be portable. They explicitly allow non-portable things. (Heck, PAQ8 was pre-C++11 and didn't compile on AMD64 due to such bugs. It was also single core only and very slow but still very good.)

Actually, even ISO C only mandated that "long double" equal double, which is what MSVCRT does (or did, in the old days), same with OpenWatcom (unlike GCC). And I don't think AMD64 supports beyond "double" directly anyways. So FPC's Extended type is unsupported on AMD64. (AVX probably fixes that, but that's yet another can of worms.)

I believe the Linux kernel is roughly C11 (without VLAs) with GCC extensions of course.

> And my example shows that using those new instruction set extensions like
> MMX and SSE2 does not always even make the code faster. SSE2 can do 64-bit
> math natively, so there is less code involved in adding 64-bit numbers, and
> it should be faster in theory, but not always in practice. The user must
> always have the option to build and optimize the code for their own
> computer, even when the computer is "old" or something else than intended
> by the original developer of the software.

Old also means a lot of things. I remember my P4. It was single core only (mainly noticeable during antivirus scans, ugh). It had some USB 1.1 (slower) and some USB 2 ports. It was using a traditional hard drive (non-SSD). The 512 MB of RAM was probably DDR2. You can compare cpus from 2004 to 2020 to see a difference.

> I just find it weird when a software developer, who doesn't even write
> assembly, suddenly says that someone else's computer is "too old" or "too
> slow" and must not be "supported" anymore. If we consider that that "someone > else's computer" is a turing-complete machine that has enough memory to run
> the program in question, and has enough computing power that its owner does
> not consider it "too slow", the software developer should not have the right > to say that it is.

IIRC, the PlayStation 5 and XBox Series X are both Ryzen 2 with 16 GB of RAM. Compare that to 2013-era PS4 and XBoxOne. My point is that nothing is ever good enough for some people. (But they do try to do a lot more with HD/UHD/4k/whatever.)

> The job of the software developer is to just maintain the program, and
> generally when we are speaking of relatively high-level userspace programs or > their libraries, they compile to older x86 hardware just fine, unless
> something is actively preventing it from happening. Breaking compatibility
> with 32-bit x86 CPUs and/or pre-SSE2 CPUs will most likely also break
> compatibility with many non-x86 targets.

For many years the world has already tried to deprecate and kill IA-32. Ubuntu doesn't support it anymore (since 2019?). Like I said, people are arguing over whether x64 v3 should be the new baseline or not.

They don't really sympathize with people who don't upgrade every few years. (I would say every five years would be nice, but it's usually shorter than that.) A lot of software won't work on Win7 or 8 anymore. Heck, for laughs, I sent my mother an email about Cygwin. They used to support Win9x. Then it was XP (for Unicode). Then they dropped IA-32. Then they dropped older OSes (like Win7/8).

Linux is all about choice. But often that choice is "not invented here!" or "UNIX only!" or "we don't care about anything before 2017!". Roll your own, develop your own ... easier said than done. Face it, "portability" is not a priority for most people.

To some people, RAM unused is wasted. You know, ulimit says their stack is "unlimited", and virtual memory and AMD64's 48-bit addresses just encourage wasteful practice. (Granted, trying to do everything in 64 kb is unrealistic. But a home user REALLY shouldn't need 64 GB of RAM for anything!) I'm not saying we should all target 286s or use 486s to identify our algorithms' bottlenecks. But meh, the modern world is not optimal. ("We don't have time! It costs money! We don't have a test setup!")

You know what's slow? Recompiling headers over and over again. (But C++20 fixed that. "Just throw more cores at it!") Garbage collection. Bytecode. Quadratic algorithms. Cpu cache thrashing. AutoTools/Configure under Cygwin. Slow software emulation (because xyz isn't supported anymore). Bugs. Limits.

The whole point of "computer science", I thought, was to not be tied to any specific technology. In other words, don't rely too heavily on any cpu or OS or compiler or language dialect. They don't last. You have to do everything yourself. (Well, sometimes other people help.)

But yes, talk is cheap, and "upgrade!" is never useful advice.

samwdpckr

30.03.2024, 20:09
(edited by samwdpckr, 30.03.2024, 20:32)

@ Rugxulo

I made my own DOS implementation

Post reply

> For many years the world has already tried to deprecate and kill IA-32.
> Ubuntu doesn't support it anymore (since 2019?). Like I said, people are
> arguing over whether x64 v3 should be the new baseline or not.

I remember when Ubuntu used it as a "marketing advantage" against Windows that Ubuntu works on older computers. Nowadays Ubuntu is a complete opposite of what it once was. It is so bloated that even new cheap laptops cannot run it anymore.

And 32-bit x86 Linux desktop is already completely broken because of those idiots who insist that everything must be compiled for at least SSE2 targets. Literally nothing works and everything just throws invalid opcode errors. When the compiler is asked to generate i686, i586 or even i486 code, there is still SSE2 instructions everywhere, because the CFLAGS are overridden in multiple lines of the build scripts. It is a lot of work to make them actually work and then the next software update breaks it again.

At least command line tools still work on a Pentium II, which also has easily more than enough computing power for them. Everything happens instantly and the difference to new computers is almost unnoticeable.

The situation is already so crazy that I'm scared of installing software updates on a computer that is only ten years old and has an i7-based Xeon CPU, because I fear that the new version of some important package has instructions that my CPU does not support.

You cannot trust the archname in the name of the software package anymore. "i686" does not actually mean i686 and x64 may be basically anything.

> To some people, RAM unused is wasted.

I thought that the one of the basic ideas of multitasking is that one program cannot consume all memory of the computer. Aren't se supposed to have multitasking computers in 2024?

Oso2k

31.03.2024, 21:22

@ samwdpckr

I made my own DOS implementation

Post reply

> And 32-bit x86 Linux desktop is already completely broken because of those
> idiots who insist that everything must be compiled for at least SSE2
> targets. Literally nothing works and everything just throws invalid opcode
> errors. When the compiler is asked to generate i686, i586 or even i486
> code, there is still SSE2 instructions everywhere, because the CFLAGS are
> overridden in multiple lines of the build scripts. It is a lot of work to
> make them actually work and then the next software update breaks it again.

I think you’re making an assumption here. At least with gcc, binutils, and djlsr (djgpp’s bsd derived libc), you tell exactly build-djgpp builds and injects ISA support. Rich Felker’s cross compiler scripts do something very similar for musl libc and Linux.

https://github.com/andrewwutw/build-djgpp/issues/45
https://github.com/richfelker/musl-cross-make

Rugxulo

Usono,
31.03.2024, 22:59

@ Oso2k

I made my own DOS implementation

Post reply

> At least with gcc, binutils, and djlsr (djgpp’s bsd derived libc),
> you tell exactly build-djgpp builds and injects ISA support.
>
> https://github.com/andrewwutw/build-djgpp/issues/45

Just FYI ....

GNU sed (and FreeBSD sed) support a non-standard -i switch to edit "in place", thus no need for a temporary output file and mv afterwards. (If you use -i~, it will create a backup file first.)

samwdpckr 01.04.2024, 16:31 @ samwdpckr	I made my own DOS implementation Post reply
	I wrote the basic utilities TREE, DELTREE, ATTRIB, XCOPY and DIRFIND (called when DIR /S command is given to the command prompt). DELTREE and XCOPY were important, because the graphical interface calls them when copying entire directories. I also added a non-standard syscall that changes the timestamp of a directory entry.

samwdpckr

08.09.2024, 01:32
(edited by samwdpckr, 08.09.2024, 01:59)

@ samwdpckr

I made my own DOS implementation

Post reply

I noticed mbbrutman's NetDrive and got some inspiration from it. I created NETDISK. Now ST-DOS has the power of cloud too.

Download page:
http://sininenankka.dy.fi/leetos/netdisk.php

Because ST-DOS has a different device driver API than MS-DOS and its 100% clones, NETDISK only works on ST-DOS. The way it works is pretty similar to mTCP NetDrive - the server computer has disk images and they are shared to the client computers. There are some differences though. Although NETDISK and mTCP NetDrive are products that serve different purposes and are not competing against each other, some comparisons between them can still be made:

NETDISK's pros, compared to mTCP NetDrive:
+ Works with all filesystem types (because ST-DOS has a filesystem driver API)
+ Has dynamic caching, which probably makes NETDISK faster
+ The server works on both DOS and POSIX-compatible operating systems like Linux (compiling it to DOS needs the socket.h header from ST-DOS's TCP/IP stack and its sockhdr.obj object file)
+ Works with almost indefinitely large drives (ST-DOS uses 64-bit offsets for device files)

Cons:
- Only works with ST-DOS
- No advanced features like sessions and "undo" - the server program is currently very simple and doesn't have a lot of code
- The device driver does not currently support unloading, a reboot is needed

I had to make some fixes to the kernel and the TCP/IP stack to get NETDISK working, so it only works with the newest versions of them.

samwdpckr 31.10.2024, 22:29 @ samwdpckr	I made my own DOS implementation Post reply
	I made a video of installing ST-DOS and NETDISK. https://www.youtube.com/watch?v=iW4KVJcfmz8