Main page I Packages I Help I Forum

SvarDOS community forum

a place to talk about SvarDOS and other DOS-related things

jump to end reply list of threads

SvarDOS build 20240201 available

aa23a6c4b2c12ce9 5293d7dd5c2e3994 352c1076588a3d54 b0a123df50cd5aa0 a83fa45a6763865f 7ee5b98b3a9b6080 a94232d4849d48c6 b025711ecd4619bf
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/
078ac416e4811d4f ac7134fc6c34222e e676a6b143232a57 f638c349b414e0e6 b25cc1129ce8293c bc9a49b88c1ea9f5 a8d5c26e0797bc6f 2eba886e5c7e366b
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
078ac416e4811d4f ac7134fc6c34222e e676a6b143232a57 f638c349b414e0e6 b25cc1129ce8293c bc9a49b88c1ea9f5 a8d5c26e0797bc6f 2eba886e5c7e366b
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
aa23a6c4b2c12ce9 5293d7dd5c2e3994 352c1076588a3d54 b0a123df50cd5aa0 a83fa45a6763865f 7ee5b98b3a9b6080 a94232d4849d48c6 b025711ecd4619bf
> 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? ;-)
aa23a6c4b2c12ce9 5293d7dd5c2e3994 352c1076588a3d54 b0a123df50cd5aa0 a83fa45a6763865f 7ee5b98b3a9b6080 a94232d4849d48c6 b025711ecd4619bf
> 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.
078ac416e4811d4f ac7134fc6c34222e e676a6b143232a57 f638c349b414e0e6 b25cc1129ce8293c bc9a49b88c1ea9f5 a8d5c26e0797bc6f 2eba886e5c7e366b
> 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
aa23a6c4b2c12ce9 5293d7dd5c2e3994 352c1076588a3d54 b0a123df50cd5aa0 a83fa45a6763865f 7ee5b98b3a9b6080 a94232d4849d48c6 b025711ecd4619bf
> 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
aa23a6c4b2c12ce9 5293d7dd5c2e3994 352c1076588a3d54 b0a123df50cd5aa0 a83fa45a6763865f 7ee5b98b3a9b6080 a94232d4849d48c6 b025711ecd4619bf
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
078ac416e4811d4f ac7134fc6c34222e e676a6b143232a57 f638c349b414e0e6 b25cc1129ce8293c bc9a49b88c1ea9f5 a8d5c26e0797bc6f 2eba886e5c7e366b
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.
078ac416e4811d4f ac7134fc6c34222e e676a6b143232a57 f638c349b414e0e6 b25cc1129ce8293c bc9a49b88c1ea9f5 a8d5c26e0797bc6f 2eba886e5c7e366b
> ... 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
078ac416e4811d4f ac7134fc6c34222e e676a6b143232a57 f638c349b414e0e6 b25cc1129ce8293c bc9a49b88c1ea9f5 a8d5c26e0797bc6f 2eba886e5c7e366b
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

your name or nick

password (optional)


check the FIRST and LAST boxes: