DOS ain't dead - lDOS iniload + fdkernpl used in warez (+ FreeDOS kernel)

ecm

Düsseldorf, Germany,
04.01.2025, 21:54

lDOS iniload + fdkernpl used in warez (+ FreeDOS kernel) (Announce)

The retrocomputing stackexchange user pts asked today what loader was being used in a DOS warez image. Turns out it is a 2022 or 2023 revision of lDOS's iniload and fdkernpl stages.

It was easy for me to recognise both due to being named io.sys and containing a FreeDOS kernel and of course the very distinct error messages pts quoted from the initial loader.

---
l

DosWorld

05.01.2025, 02:25
(edited by DosWorld, 05.01.2025, 13:46)

@ ecm

lDOS iniload + fdkernpl used in warez (+ FreeDOS kernel)

Post reply

> I've found it on http://www.mul[cut]ot.ru/[cut/

Will be good stop deliver Russian translations with freedos. Definitely, may be somebody live one day more. (dos is wide used in factories on outdated machines)

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

mceric

Germany,
05.01.2025, 13:40

@ DosWorld

lDOS iniload + fdkernpl used in warez (+ FreeDOS kernel)

Post reply

> Will be good stop deliver Russian translations with freedos. Definitely,
> may be somebody live one day more. (dos is wide used in factories on
> outdated machines)

As with many other countries, the problem are the politics there, not the people there. There are hard-working Russian experts in the DOSEMU2 team, for example.

Still, I have a bit of a problem with this thread because it indirectly advertises that Warez download. While it is interesting for the author that iniload is used for that, it is not necessarily interesting for BTTR ;-)

---
FreeDOS / DOSEMU2 / ...

DosWorld

05.01.2025, 13:52
(edited by DosWorld, 05.01.2025, 15:05)

@ mceric

lDOS iniload + fdkernpl used in warez (+ FreeDOS kernel)

Post reply

1. I’ll refer to Linus opinion. https://www.phoronix.com/news/Linus-Torvalds-Russian-Devs

> I'm Finnish. Did you think I'd be *supporting* Russian aggression?
> Apparently it's not just lack of real news, it's lack of history knowledge too.

Here is many people from CR, IMHO, they also have own point of view.

Also, this is not problem of politics or space science - I am soldier of Ukrainian army. This is real world every day problem.
You can say “I am out of politic”, - yes I am hear this opinion many times… from Russians (99% cases). Could not recommend do in this way (if you have no second citizenship for backup “we broke own country, so need escape outside”).

2. Link to wares has been fixed. Sorry.

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

roytam

29.08.2025, 05:31

@ ecm

lDOS iniload + fdkernpl used in warez (+ FreeDOS kernel)

Post reply

> The
> retrocomputing
> stackexchange user pts asked today
> what
> loader was being used in a DOS warez image. Turns out it is a
> 2022 or
> 2023
> revision of lDOS's
> iniload
> and
> fdkernpl
> stages.
>
> It was easy for me to recognise both due to being named io.sys
> and containing a FreeDOS kernel and of course the very distinct error
> messages pts quoted from the initial loader.

Sorry for asking something irrelevant here.
I wonder if lDOSboot can be booted from non-standard disk size? for example, booting from DMF disk or disk formatted with 2M?

ecm

Düsseldorf, Germany,
29.08.2025, 16:04

@ roytam

Booting lDOS from non-standard disk size

Post reply

> Sorry for asking something irrelevant here.
> I wonder if lDOSboot can be booted from non-standard disk size? for
> example, booting from DMF disk or disk formatted with 2M?

As for the boot sector loader, you can force some things using the instsect tool. With /Q NONE the geometry is read from the boot sector instead of querying the ROM-BIOS with int 13h function 08h, which may be needed for unusual disk sizes. /G SECTORS=x and /G HEADS=x allow to change the geometry values written to the boot sector. /L NONE forces the use of CHS access, which may be needed if the int 13h interface has bugs.

The lDOS boot iniload loader has the query patch site to allow modifying its behaviour. It has one byte for HDD boot (unit >= 80h) and another for diskette boot (unit < 80h). This allows forcing LBA, forcing CHS, and trusting the geometry passed from the prior loader (instead of querying it using int 13h function 08h, again). There is a special flag, 80h, to pass the query patch settings to the kernel. This is observed by lDebug (modifying its BOOTUNITFLxx variable that corresponds to the load unit). It isn't observed by the lDOS kernel yet.

Boot time access is purely a function of the boot sector loader and iniload. After boot time, the kernel sets up UPBs and DPBs for each recognised drive and accesses them in the usual way. That means if an unusual format is supported at all post-boot time then the ability to boot off this file system is a question about ldosboot (the boot sector loader and iniload).

If ldosboot is not able to load from a file system, it may be possible to get lDebug to boot from it, using either ldosboot (but then that may fail too) or a different boot loader. (lDOS/lDebug iniload kernels can run as io.sys, ibmbio.com, etc.) The loader in lDebug may then be able to chainload a kernel where ldosboot would have failed. The commands to run would be at least boot protocol ldos followed by q, plus whatever may be needed in addition to make the load succeed.

If you can provide me with a VM setup that reproduces a boot failure using the current ldosboot + kernel I may be able to modify things so there is a way for them to work.

---
l