SvarDOS community forum

Thanks to Mateusz' efforts we now have a shiny new and working stable release. Please try it and give some feedback: http://www.svardos.org/

Just a summary of essential changes: CORE files are stored in C:\SVARDOS instead of C:\SVARDOS\BIN https://github.com/SvarDOS/bugz/issues/47 LNG files are stored along the executables instead of being placed in %DOSDIR%\NLS https://github.com/SvarDOS/bugz/issues/58 PKG no longer generates PACKAGES\*.LST files - all metadata is now stored within the LSM https://github.com/SvarDOS/bugz/issues/54 Improvements of the HELP command https://github.com/SvarDOS/bugz/issues/50 https://github.com/SvarDOS/bugz/issues/51 SvarCOM is compatible with the EDR-DOS kernel https://github.com/SvarDOS/bugz/issues/38 EN-only builds are being systematically generated (SvarDOS fits now on a single 1.44M floppy) https://github.com/SvarDOS/bugz/issues/42 Installer improvements https://github.com/SvarDOS/bugz/issues/44 https://github.com/SvarDOS/bugz/issues/46 https://github.com/SvarDOS/bugz/issues/55 Mateusz

BTW - an open question. Does it make sense to change the build versionning of SvarDOS releases? Currently it is simply the day at which the build has been generated (YYYYMMDD). It's not a bad system, but somewhat long, and unnecessarily granular because we do not need the capacity of making daily (public) releases. Maybe we could use a shorter versioning scheme instead? I was thinking something weekly, like one of these: date +%GW%V --> 2024W05 date +%G%V --> 202405 date +%g%V --> 2405 *my preferred so far! Mateusz

> Does it make sense to change the build versionning of SvarDOS releases?

I don't care too much about this. If you want to change it, just do it. Yes, YYYYMMDD is long, but you don't need an explanation to understand it. You could also just apply the versioning system from SvarCOM, SvarDOS More, or SVED: 2024.6

> we do not need the capacity of making daily (public) releases

Last days showed up different, right? ;-)

> Just a summary of essential changes:

[snip] Thanks for this list! :-) I was too lazy yesterday and wanted to wait until a visitor probably complains about the missing list.

> Last days showed up different, right? ;-)

True, but I think it was a pathological situation :-P A side effect of a weekly versioning would be actually enforcing some waiting time before going public. That's probably a good side effect. I will think about it, no need to rush it. Mateusz

> A side effect of a weekly versioning would be actually enforcing some waiting time before going public. That's probably a good side effect.

If we use this time for testing "internally", yes. :-)

> I will think about it, no need to rush it.

+1

By the way: LibreOffice switched to the "year.month" scheme.

> The next major release after LibreOffice 7.6 will be LibreOffice 24.2 (February), which will be followed by LibreOffice 24.8 (August)

Source: https://lists.freedesktop.org/archives/libreoffice/2023-May/090403.html

is it known not working on 8088? https://i.imgur.com/YNDV9g1.png

I'm pretty sure it still does work on 8088-class machines because I do regular tests on 86box. Maybe is your floppy image corrupted? Or maybe your (virtual) machine does not support 1.44M drives? In my experience most 8088 bioses are limited to 720K. Mateusz

> In my experience most 8088 bioses are limited to 720K.

but Xi8088's BIOS supports 1.44MB floppies. https://github.com/skiselev/8088_bios ... hmm, it turns out with newer BIOS it seems to work now.

> ... hmm, it turns out with newer BIOS it seems to work now.

I reproduced this issue by using 86Box and the 86box romset version 3.11, selecting the emulated machine to be "xi8088" and first floppy drive set to 1.44M. The boot failure is not specific to SvarDOS, though - a vanilla FreeDOS boot floppy was also unable to boot. Then I upgraded the xi8088 BIOS which was version 0.9.4 from 2017 and I replaced it with the version 1.0.0 ("bios-micro8088-noide.rom") from there: https://github.com/skiselev/8088_bios/releases/tag/v1.0.0 With this new BIOS the machine was able to boot from the 1.44M floppy without any issues. So I think it's safe to assume this was caused by a BIOS glitch. Mateusz

I've tested the xi8088 BIOS v0.9.4 again. In fact, the boot fails only the 1st time. It is enough to restart the VM (either with ctrl+alt+del or through a hard reset) and then the floppy boots alright. Weird. Anyway, unrelated to SvarDOS in any case. Mateusz

xi8088 BIOS v0.9.4 is broken in the sense that an INT13,41 call to query the extended INT13 capabilities has a memory corruption bug. This also made FDISK crash reproducably. This (closed) FDISK issue for this is https://github.com/FDOS/fdisk/issues/80