single-file kernel name

[boeckmann]

I am still struggling to decide whether the single-file kernel should be named KERNEL.SYS or DRKERNEL.SYS by default. DRKERNEL.SYS would be better to differentiate it from the FreeDOS kernel, but SYS would have to be adjusted to find it by default (no big thing though). Naming it KERNEL.SYS, the user could think it is the FreeDOS kernel. I tend to name it DRKERNEL.SYS.

[mateuszviste]

The positive side would be that it becomes then possible for pkg to install the kernel right in the root directory because there is no risk of overwriting a freedos kernel. Without weird subdirectories in the svardos folder. The less fun part is obviously the necessity of shipping an exotic sys.. and the fact that sysing is mandatory to activate the kernel (and what if the two kernels are present?). Sounds like a potentially annoying (error prone) complication for the user. With a single kernel.sys at least there is no doubt about what is being booted.

[boeckmann]

Well, I would try to get the changes into upstream SYS, so that would not be the problem...

[mateuszviste]

I think an interesting exercice is to consider the user's PoV. What needs to be done to switch from kernel X to kernel Y?

KERNEL.SYS:

COPY %DOSDIR%\KERNLEDR\KERNEL.SYS C:\ 
REBOOT

DRKERNEL.SYS:

COPY %DOSDIR%\KERNLEDR\DRKERNEL.SYS C:\ 
DEL C:\KERNEL.SYS  (optional?)
SYS /ACTIVATE:DRKERNEL.SYS C:
REBOOT

In the second case we also have to keep fingers crossed that the user has first upgraded SYS to the new "hacked" version.

Both options have their pros and cons, but I think the first one is saner, as it annoys the user the least (and limits the risk of user breaking his system to the minimum). Plus, it keeps the potential of automated (pkg) kernel upgrades alive, should such option be ever revisited in the future.

[mateuszviste]

Also, when I see DRKERNEL I immedately hear "dr kernel" (followed for some reason by "dr oetker"). Granted, it's a psychiatric condition of mine, but still annoying :-P

[boeckmann]

Also, if it stays at kernel.sys, I do not have to change all the makefiles again :D

[mateuszviste]

So assumming it stays as KERNEL.SYS, we would have:

In the svp package: KERNELS\KERNLEDR\KERNEL.SYS

Installed to (by pkg): C:\SVARDOS\KERNLEDR\KERNEL.SYS

Activated (by user) through a simple copy operation to: C:\KERNEL.SYS

That looks quite clean & easy to me.

Same goes for the FreeDOS kernel of course, which would be available in the repo as an alternative. The only difference is it would be in KERNLFD instead of KERNLEDR.

[boeckmann]

Yes, of course the users could also issue a SYS command from within the kernel directories. Would be the more general solution in case more kernels arrive in SvarDOS.

[mateuszviste]

The one thing I am unsure about is the COUNTRY.SYS matter. Should we expect the user to modify his config.sys when switching to a different kernel? Not very friendly... It might be better/easier to replace the country.sys file present in C:\SVARDOS...

This way no need to edit the config.sys file. But if we do that, then it means two kernel packages cannot be installed at the same time. Which might be fine (user has to pkg delete kernlfd before pkg install kernledr). But if we follow this, then it makes no sense not to install kernel.sys directly to C:\ at pkg install time. Which basically brings us back to square one.

[boeckmann]

There would also be the possibility for a separate dconfig.sys. But that would mean two different configs for two different kernels. country.sys should be part of kernedr package, and also probably a dconfig.sys example. We should instruct the user to use the sys command to install the kernel into the root (it is one command in the easy case), and put a README into every kernel directory with remarks about the kernels specifics.

[boeckmann]

We can then for example also make a kernel package for ms-dos 4, with the same structure.

[boeckmann]

But this pkg install thing also has its nice parts, with putting everything into C:\ from the start on. Perhaps we start with that, as long as there are "only" two kernels :) But we should output a message after installation, that the user should have a look at the kernel specific readme, before rebooting the machine.

[mateuszviste]

But this pkg install thing also has its nice parts, with putting everything into C:\ from the start on. Perhaps we start with that, as long as there are "only" two kernels :) But we should output a message after installation, that the user should have a look at the kernel specific readme, before rebooting the machine.

Like you, I am unsure what solution is the best one from a cosmological point of view, but I also have a slight personal preference towards the "all in C:\" way, because of its simplicity and because it is the most "legacy looking". I agree that a clear message about kernel specifics is mandatory. So let's start with that. I will prepare some preliminary packages, hopefully today, so we can see what kind of limitations we hit in practice. I will also look this week into building a working bleeding edge release with EDR instead of FreeDOS.

[boeckmann]

Nice, and I will try to update the JWasm package in the next days. Then we can test if we are able self-host and compile the EDR kernel under SvarDOS + EDR kernel.

[mateuszviste]

I've added two packages to the repo: kernlfd.svp and kernledr.svp.

I can pkg install one or another and switch between the two without any issue so far (only glitch is that DOSEMU2 crashes with the EDR kernel, but that's probably not the kernel's fault).

Anyway -- very promising so far.

Note that the kernledr package contains outdated documentation. This is because I reused the documentation from your old edrdos.svp file. It would be really cool if the kernledr.svp package could be autogenerated through this neat github build thingy you have set up.

[mateuszviste]

I replaced the FreeDOS kernel by EDR in the firmware build. The "bleeding edge" version of SvarDOS is now EDR-based, and... surprisingly, it worked right away. I was able to install the EDR-based bleeding edge release of SvarDOS in VirtualBox without any issues. I'm sure there is a ton of corner cases that will go bad, but so far it is really awesome.

During my VBox installation I felt that the keyboard inputs are slower than with FreeDOS. Not sure why, will have to do some more tests.

[boeckmann]

I replaced the FreeDOS kernel by EDR in the firmware build. The "bleeding edge" version of SvarDOS is now EDR-based, and... surprisingly, it worked right away. I was able to install the EDR-based bleeding edge release of SvarDOS in VirtualBox without any issues. I'm sure there is a ton of corner cases that will go bad, but so far it is really awesome.

Great! I will add automatic .SVP builds for the Github action.

During my VBox installation I felt that the keyboard inputs are slower than with FreeDOS. Not sure why, will have to do some more tests.

If you do further tests, please try with disabled FDAPM.

[mateuszviste]

If you do further tests, please try with disabled FDAPM.

FDAPM was indeed the culprit. With "FDAPM APMDOS" under EDR and VirtualBox, the system is sluggish, even typing on the command line is painful. With no FDAPM, or "FDAPM APMOFF" or "FDAPM APMBIOS" the system is nice and responsive - but in all these cases the VirtualBox process runs at 100% of CPU on my laptop, while with "APMDOS" it stays at 1-2% when idle.

[boeckmann]

Yes, this is also was I experienced in 86box. Good to have another data point. However: running FDAPM ADV:MIN or ADV:REG seems to run fine.

FDAPM mentiones something about performance problems under Novell DOS if INT28 is hooked:

https://github.com/FDOS/fdapm/blob/61bf59098c24f77cb3284be6e0ee770e82c14daa/fdapm.txt#L42-L46

[boeckmann]

So may be you can also test it with FDAPM ADV:REG? And if this works we make it the default setting?

[boeckmann]

[mateuszviste]

When using Robert's EIDL instead of FDAPM, the VirtualBox process idles at around 5%, so less power saving than with "FDAPM APMDOS", but the system stays very responsive. EIDL has a nice license (MIT) and the binary is only 80 bytes (288 bytes memory footprint, mostly because of its PSP), but it has two issues:

1. running EIDL.COM multiple times leads to multiple instances being installed in memory, ie. EIDL does not check for its presence before TSRing. After the 3rd or 4th instance the system becomes hardly usable.
2. it does not try to detect when the system is actually idle, just executes a single sti+hlt combo at every int 28h. this means it always slows down the PC, even when CPU time is needed elsewhere. On modern (Pentium+) systems it probably does not matter, but might be bothering on older CPUs. So probably not a good "generic" solution.

Another option is DOSIDLE from Marton Balog (1998). It is a much more complex piece of software. "DOSIDLE -APM" leads to VirtualBox idling at under 2%, so comparable with FDAPM, but the systems is still very reactive. Using "DOSIDLE -HLT" has the same effect: under 2% CPU usage, no noticeable slowdown. No sources, though.

I also tried "FDAPM ADV:REG" and this one does not seem to cause any slowdown with VirtualBox, and it decreases the CPU utilization at idle time to under 2%, just like DOSIDLE.

I am somewhat tempted to kick out FDAPM and include EIDL on the floppies as a third party driver... It's not the best, but it yields acceptable results and it so simple that barely anything can go wrong there. The package is also tiny, and that's nice for floppy distribution. Plus, it would be another GPLism less in SvarDOS. :)

[boeckmann]

Well, at least we have a few options now that seem to work :) My preference still would be FDAPM, because it s more "generic".

[mateuszviste]

Well, at least we have a few options now that seem to work :) My preference still would be FDAPM, because it s more "generic".

done in build 20240730. I'd still like to get rid of FDAPM eventually, for a tinier/simpler solution, but let's not get ahead too much, there's plenty of more essential things to focus on for the time being..

[boeckmann]

Good! I try to finalize to svardos pkg generation. I try to also include the specific git commit the kernel was built from at the kernel boot message. That seems more trivial than it is, at least if you want it to work on all build platforms :/

[andrewbird]

Did you try git describe --tags?

$ git describe --tags
v20231212-alpha-283-g55d8dde

[boeckmann]

Right now I use git rev-parse --short HEAD, but this is tricky to "implant" into the build system in a platform independant way. At least so that it works with every DOS shell I want to support. Right now I think I have to live with the fact that the kernel only outputs its git revision if built under Linux / Mac. At least it is a start... The SvarDOS packages will anyway be built via the Github action.

[boeckmann]

It would be really cool if the kernledr.svp package could be autogenerated through this neat github build thingy you have set up.

This is now implemented. I removed all the docs and left only the license. The whole documentation needs some overhaul. The version of the .svp package is of the form YYYYMMDD and is automatically set by querying the current date on build.

Kernel now has a version (like above) a revision (git commit), and a build date displayed on boot. Version is set to "?" if it is not build as SvarDOS package. But version may be specified when building via WMAKE VERSION="20240730" for example. If building under DOS / Windows, also the git revision is currently set to "?".

[boeckmann]

Not sure we have to show the copyright disclaimer. This is normally shown when DR-DOS command.com is started. I put this into the kernel, because we do not spawn DR-DOS command.com. Makes everything a little verbose, but I think it is safer.

[mateuszviste]

Maybe could it be shortened to one line "copyright xyz ; see EDRCOPR.TXT for details" ?

[mateuszviste]

This is now implemented. I removed all the docs and left only the license. The whole documentation needs some overhaul. The version of the .svp package is of the form YYYYMMDD and is automatically set by querying the current date on build.

That is very good, thank you! Would it be a huge problem to make it so the svp filename inside the zip is KERNLEDR-YYYYMMDD.SVP instead of KERNLEDR.SVP ? It's just a petty detail, but it would allow me to periodically import the package right into the SvarDOS repository without having to rename it manually.

Kernel now has a version (like above) a revision (git commit), and a build date displayed on boot.

Is there a way to query the version at runtime? Maybe I could add this information into VER output.

[boeckmann]

That is very good, thank you! Would it be a huge problem to make it so the svp filename inside the zip is KERNLEDR-YYYYMMDD.SVP instead of KERNLEDR.SVP ? It's just a petty detail, but it would allow me to periodically import the package right into the SvarDOS repository without having to rename it manually.

I should be able to implement that. Maybe this requires the package to be put into an extra folder for artifact upload.

Is there a way to query the version at runtime? Maybe I could add this information into VER output.

Not right now, as it currently identifies itself as DOS 6 via INT21,30 and DOS 7.1 via INT21,3306 (true version) and 7210 as returned by INT21,4452. As both theSvarDOS version and git revision are 8 bytes it is also not wise to put them in some extra register returned by the above functions. But it could be included in the DOS version string returned by INT21,33FF.

[mateuszviste]

could be included in the DOS version string returned by INT21,33FF.

Neither RBIL nor TechHelp! know about INT 21h,33FF. I suppose this is some undocumented internal DR-DOS API. Could you please share some more information about it?

[ecm-pushbx]

could be included in the DOS version string returned by INT21,33FF.

Neither RBIL nor TechHelp! know about INT 21h,33FF. I suppose this is some undocumented internal DR-DOS API. Could you please share some more information about it?

It's actually a function that originated with the FreeDOS kernel. It is found there in inthndlr.c under the heading "the remaining are FreeDOS extensions", marked "Get DOS-C release string pointer".

Best practice for calling it is implemented in my fork of callver, which sets dx to zero before the call and assumes it is supported if the call sets a nonzero segment return value in dx. This is assumed to be needed for a valid return of the far pointer in dx:ax.

Prior versions of callver required 21.3000 to return bh = 0FDh to call 21.33FF at all, but I think it's better to test support specifically and not assume anything based on the OEM ID. DOG also requires the OEM ID to be 0FDh as yet.

We added support for the function to RxDOS (current), EDR-DOS (current), and the lDOS fork of MS-DOS v4.

[mateuszviste]

It's actually a function that originated with the FreeDOS kernel.

Hi ECM, thank you for the pointers, it works indeed. :-)

commit

@boeckmann perhaps could we close this issue? The kernel filename being kernel.sys seems to work fine so far.

[ecm-pushbx]

DOS versions should be displayed with two digits for the minor version, ie 6.00 and 7.01 (which EDR-DOS reports).

[boeckmann]

Yes can be closed. We can create a more specific issue on demand.

[mateuszviste]

DOS versions should be displayed with two digits for the minor version, ie 6.00 and 7.01 (which EDR-DOS reports).

Good catch, thanks! Fixed now.

[ecm-pushbx]

Your last picture shows DR-DOS version 7210 but according to the BDOS loader sources it should be 1072. Your earlier picture got that right so it seems you got confused since.

[ecm-pushbx]

Error in http://svn.svardos.org/comp.php?repname=SvarDOS&compare[]=%2F@1843&compare[]=%2F@1844

[ecm-pushbx]

(This version number is NOT related to 86-DOS / MS-DOS kernel version numbers at all.)

[mateuszviste]

Your last picture shows DR-DOS version 7210 but according to the BDOS loader sources it should be 1072. Your earlier picture got that right so it seems you got confused since.

I changed it later indeed. RBIL says that AL indicates the actual version, while AH is the "single / multiuser" flavor. In a word - AX should not be treated as a single value, but AH and AL should be considered two different values.

Hence I figured that it is more logical (and less confusing to users) to put the version in front, so displayed versions retain a human order (7210 and 7214 being the same version but different flavor, and an upgrade would lead to the version being either 7310 or 7314). I even hesitated at displaying it as "72.10". Another option that I pondered was to display it as "version 72 single-user" / "version 72 multi-user", but then it would involve extra translation work, so I dropped the idea.

Am I being too creative?

[boeckmann]

I would just leave this info out. We are not multi-user, as we are not Concurrent DOS :) And this version, for compatibility reasons, will likely never change.

[boeckmann]

The displayed string returned via 33,FF should be sufficient enough for the user to distinguish which exact kernel revision is running.

[mateuszviste]

The 33FF string is very good, but it only came up with EDR-DOS. If someone runs SvarCOM under an earlier DR-DOS system, the only DR-specific version available would be from 4452h (there really are people out there doing such retro-necromancy). Besides, isn't it a good way to tell the user "you are running a DR-DOS kernel"?

[boeckmann]

there really are people out there doing such retro-necromancy

Well, if they want it, they shall get it. Does not hurt if it is displayed :)