edrdos
edrdos copied to clipboard
SvarDOS
change dual-file names back to IBMBIO.COM and IBMDOS.COM
At least Digital Research DR DOS 6 and Caldera DR-DOS 7.03 kernel files are named IBMBIO.COM and IBMDOS.COM. As the dual-file builds purpose is mainly being a drop-in replacement for this systems, I suggest that the names are changed. Currently they are called DRBIO.SYS and DRDOS.SYS.
As the zero-compressed DRBIO.SYS is smaller than 29K it can be booted at least from a DR-DOS 7.03 bootsector perfectly fine (tested), if renamed to IBMBIO.COM.
MS-DOS (IO.SYS / MSDOS.SYS) and IBM PC-DOS (IBMBIO.COM / IBMDOS.COM) boot sector loaders may not work as expected because they may fail to initialise bp to 7C00h, so current SvarDOS flavour EDR-DOS would not find the hidden sectors where expected.
Further, with a kernel file close to the 29 KiB limit the load may fail if you run on a file system with larger cluster sizes such as 2 KiB, all the way up to 32 KiB, 64 KiB, or 128 KiB.
I tend to make the single-file kernel the default build, and the dual-file one especially for compatibility with older DR-DOS systems, as I see no benefit in having the dual-file version when not using it with an existing DR DOS. New systems can use the single-file version, like SvarDOS does.
My point of view is that the compatibility outweights the problems with MS-DOS loaders etc. But this is a discussion, so lets see what other opinions show up :)
The DR-DOS provided IBMBIO.COM is 24.810 bytes in size, the EDR one is currently 25.286 bytes. So the EDR kernel should work with the DR-DOS provided loaders where the original kernel does, I guess.
Mmm... as a discussion , i say the dr-dos kernel originally had DRBIO.SYS A DRBDOS.SYS as a filenames , but for compatibility with IBM boot sectors and another things the oem name for the boot sector has changed from DRI(or whatever it was) to IBM 6.0 and the filenames were IBMBIO.COM IBMDOS.COM. That was for compatibility but back ago. In one file instead of using KERNEL.SYS is better to reanme to DRKERNEL.SYS instead , to NOT confuse with FreeDOS Kernel(because they are WAY different). And the other discussion on the EDRDOS topic , is maybe , maybe, to make Reverse Engineer of the utilities some differ very much from the DOS counter parts for example FDISK which not only creates partitions , but FORMAT that partitions(like cp/m does).
The KERNEL.SYS is called KERNEL.SYS to be bootable by the "ordinary" VBR IPL installed by the FreeDOS SYS command. In fact I first named the combined kernel DRKERNEL.SYS, but changed it upon request after the EDR kernel gained the capability of booting like the FreeDOS kernel. SvarDOS for example simply replaces the kernel binary when switching between FreeDOS and EDR kernels.
However, you may also rename your EDR KERNEL.SYS to DRKERNEL.SYS if that is more approriate to you. You then have to specify a custom kernel name when invoking the SYS command via the /SKFN parameter.
Regarding the reverse engineering of some DR tools, SHARE would be the most "urgent" one, as the Free FDISK / FORMAT combination should do everything DR FDISK does (and more). FreeDOS SHARE on the other hand only works with the FreeDOS kernel, so one has to resort to the OpenDOS 7.01 SHARE command.
The other reason to keep all kernels named "KERNEL.SYS" is that it naturally prevents one to have both kernel packages installed, which I think would be confusing to the user, who would not have any obvious way to know which kernel is to be booted.
Quoting from boeckmann: Regarding the reverse engineering of some DR tools, SHARE would be the most "urgent" one, as the Free FDISK / FORMAT combination should do everything DR FDISK does (and more). FreeDOS SHARE on the other hand only works with the FreeDOS kernel, so one has to resort to the OpenDOS 7.01 SHARE command.
There is not only differences in fdisk and or format for example /X switch to format hard drives. But also there are another utilities like delpurge.exe delwatch.exe and some things that does not work like the freedos (msdos compatible way) There is also in freedos chkdsk a missing support for FAT32 and a missing diskopt.exe Some utilities can be used some others can't like for example HIMEM.EXE EMM386.EXE which behaviour is not the same and does not act as a single memory manager driver in all of circumstances.
There is not only differences in fdisk and or format for example /X switch to format hard drives. But also there are another utilities like delpurge.exe delwatch.exe and some things that does not work like the freedos (msdos compatible way) There is also in freedos chkdsk a missing support for FAT32
Also let's not forget that FD FORMAT is broken.
There is not only differences in fdisk and or format for example /X switch to format hard drives. But also there are another utilities like delpurge.exe delwatch.exe and some things that does not work like the freedos (msdos compatible way) There is also in freedos chkdsk a missing support for FAT32 and a missing diskopt.exe Some utilities can be used some others can't like for example HIMEM.EXE EMM386.EXE which behaviour is not the same and does not act as a single memory manager driver in all of circumstances.
TASKMGR would also be very nice to have :) But for the people wanting to use Windows etc. I still consider SHARE the most important one.
Also let's not forget that https://github.com/SvarDOS/bugz/issues/121.
Yes, already forgot that. I think if we want it to be fixed we have to do this ourself. Not sure if anyone from the FreeDOS community is interested in dealing with this.
I'm currently working on fd share, version in git compiles with Open Watcom but leaves too much code resident. I have split the code up and working to ensure c runtime from startup portion doesn't stay resident. once that is working I'm going to work so fd share and hopefully kernel is compatible with ms dos 4 share as much as possible (should help improve win 3 compatibility, with goal for kernel to be vshare compatible). I can look to see how reasonable it will be to support DR kernel, but will be a while until I get to it.
I can look to see how reasonable it will be to support DR kernel, but will be a while until I get to it.
That would be awesome! However, as @ecm-pushbx pointed out at http://svardos.org/?p=forum&thread=1737555410, the implementations seem to be sufficiently different between the MS and EDR kernels that it will be some effort to support both kernels with a single program.
I can look to see how reasonable it will be to support DR kernel, but will be a while until I get to it.
That would be awesome! However, as @ecm-pushbx pointed out at http://svardos.org/?p=forum&thread=1737555410, the implementations seem to be sufficienly different between the MS and EDR kernels that it will be some effort to support both kernels with a single program.
See also http://svardos.org/?p=forum&thread=1734989703 where I listed why MS-DOS v4.00 share won't be compatible with FAT32, even if you extend the SFT layout like EDR-DOS (unlike MS-DOS v7.10 and FreeDOS) so the prefix of the SFT entry is compatible to v4.00's SFT layout. I assume vshare may also fail to work with FAT32 in the same way.
I expect it to be more of a fork or at least separate build for EDR than single program.
Mmm... as a discussion , i say the dr-dos kernel originally had DRBIO.SYS A DRBDOS.SYS as a filenames , but for compatibility with IBM boot sectors and another things the oem name for the boot sector has changed from DRI(or whatever it was) to IBM 6.0 and the filenames were IBMBIO.COM IBMDOS.COM. That was for compatibility but back ago. In one file instead of using KERNEL.SYS is better to reanme to DRKERNEL.SYS instead , to NOT confuse with FreeDOS Kernel(because they are WAY different). And the other discussion on the EDRDOS topic , is maybe , maybe, to make Reverse Engineer of the utilities some differ very much from the DOS counter parts for example FDISK which not only creates partitions , but FORMAT that partitions(like cp/m does).
I am quite me the IBM 6.0 label was in novell versions on DRI they were IBM 3.3 reflecting that from drdos 3.3 to 6.0 the dos versión was always 3.30 and the fdisk utility was completely Broken formatting 1 gb or > hard disk drivers tested on both msdos and drdos back them (at least chkdsk from msdos 6 gaves Lost clústers) but It was nice to have a Dos 3.3 with a Dos 6.x features without changing Dos versions .😁