SvarDOS community forum

I understand that the FreeDOS Kernel has its own/special version of SHARE. However, which version is supposed to be used with the EDR Kernel? Am I correct using still the version coming with OpenDOS 7.01 (SHARE.EXE, 4.907 Bytes, from May 1997)? Frank

Frank, have you tried the SHARE package provided by SvarDOS itself? While originally coming from FreeDOS, I see no FreeDOS kernel specific code in it. So it should work. I cannot say however, if the SvarDOS share package lacks some features comparing to the DR/Novell/Caldera one. https://gitlab.com/FreeDOS/base/share/-/blob/master/SOURCE/SHARE/SHARE.C?ref_type=heads

To partially answer myself: the SvarDOS share package lacks indeed some significant functionality. The EDR kernel contains a table with stub functions for share: https://github.com/SvarDOS/edrdos/blob/eed01423e61329f684e86cb3c71b20d327339779/drdos/header.asm#L783 The stub functions are called at different places, for example when INT21,5D02 etc. is called. https://fd.lod.bz/rbil/interrup/dos_kernel/215d02.html I assume that this table is filled by the NW share utility. The SvarDOS (FreeDOS) Share does not fill the table, and the FreeDOS kernel does not seem to support INT21,5D02 et. al. To be investigated further...

Disassembling the relevant part of NW SHARE.EXE reveals that it indeed writes into the EDR kernel share stub table. INT21.4458 gets a pointer into the private data area, which at offset 0x28 contains a near ptr to its share stub table. The stub table entries are then overwritten with far addresses into the resident part of the share executable. (Note: disassembly is for SHARE 2.05 shipped with DR DOS 7.03, but should be similar for 7.01). 0000:02db push es 0000:02dc mov ax, 0x4458 ; 'XD' 0000:02df int 0x21 0000:02e1 mov di, word es:[bx + 0x28] ; arg3 0000:02e5 mov si, 0xf8b7 0000:02e8 mov cx, 0xc 0000:02eb cli 0000:02ec lodsw ax, word [si] 0000:02ed add ax, word [0xfcbd] 0000:02f1 stosw word es:[di], ax 0000:02f2 mov ax, word [0xfcbf] 0000:02f5 stosw word es:[di], ax 0000:02f6 loop 0x2ec 0000:02f8 pop es 0000:02f9 ret

Thanks for investigating. In meantime I did some tests (newest EDR Kernel, SVARCOM 2025.0): The above mentioned (old) SHARE from OpenDOS 7.01 works and can be loaded high. Share from FreeDOS seems to work, at least with a short test with LOTLAN (where the server needs share). However, share from FreeDOS cannot be loaded high (LH SHARE.COM: "abnormal program termination").

To make a long story short: While a loaded FreeDOS share might make other software detect a installed share, it seems to be mostly useless when loaded under the EDR kernel. So NW SHARE might be the software to use at the moment for a functional share implementation.

From long long time ago I vaguely remember that the share from DR-DOS 7.03 shouldn't be used with OpenDOS 7.01 (and/or vice versa), but I dunno where I learned this...

> So NW SHARE might be the software to use at the moment

Thanks for clarifying!

> From long long time ago I vaguely remember that the share from DR-DOS 7.03 shouldn't be used with OpenDOS 7.01 (and/or vice versa), but I dunno where I learned this...

Indeed! The SHARE 2.05 shipped with 7.03 version throws an error if the kernel is not at least from 7.02. Albeit the general dispatch table mechanism seems to be similar. I will take the SHARE from 7.01 when I do a more detailed analysis...

Do not use FreeDOS's sharer on any other kernel, it's at best useless. The FreeDOS interface is completely original except for re-using the MultSHARE (10h) major function number for its int 2Fh interface. (The name MultSHARE is from lMS-DOS sources: https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/INC/mult.mac#l68 ) I wrote some about the sharer jump tables present in our DR-DOS: http://svardos.org/?p=forum&thread=1734989703 The table that you found (which I didn't know yet how to locate at run time) is the one actually used. The one at DOSDATA:0090h is a placeholder for the data segment layout and appears to be unused. The DR-DOS/OpenDOS Enhancement Project used to recommend using the DR-DOS v7.01 sharer: http://web.archive.org/web/20110608064802/http://www.drdosprojects.de/index.cgi/download.htm

> Also, if you do not already have it, you might need to download the version of the Share http://web.archive.org/web/20110608065518/http://www.drdosprojects.de/cgi-bin/download.cgi/share.zip command that comes with DR-DOS 7.01 to make TaskManager work.

This is certainly a better choice than FreeDOS's sharer. However, as mentioned I am uncertain whether the sharer will cope with the FAT32 extensions to the SFTs in all cases. I do not have evidence either way, but I suspect it may not be compatible. Because we have only the core kernel's sources we unfortunately can review the sharer only by reverse-engineering the binaries. In general, only choose the sharer that most closely matches the kernel you're using. The sharer should be considered a part of the kernel by all means. (At one point there was some support in MS-DOS for indeed building the sharer as a built-in part of the kernel rather than "Installed". This unfortunately seems to share a build option ("Installed") with a built-in network redirector.) That is why I also ported lMS-DOS's sharer to NASM sources. The MS-DOS v6 sharer may work with MS-DOS v7.00, but certainly fails to work reliably on MS-DOS v7.10 because that kernel version re-uses some SFT fields for FAT32 cluster field extensions plus the same problem that EDR-DOS may have where the sharer doesn't know about FAT32 extensions.

> Do not use FreeDOS's sharer on any other kernel, it's at best useless.

Sounds like we need two SHARE packages: FDSHARE and EDRSHARE. Is the EDR SHARE available in sources somewhere? Is its license the same as the EDR kernel? Mateusz

I'm not sure why you're asking about the DR-DOS sharer's sources. "Because we have only the core kernel's sources we unfortunately can review the sharer only by reverse-engineering the binaries." That is, no, we do not have sources for the/any (E)DR-DOS sharer. As to the license I would consider the new CP/M and derivatives license agreement to cover other parts of the DR-DOS system like sharer and debugger as well. That means we may share, copy, and modify the binaries that are out there.

> I'm not sure why you're asking about the DR-DOS sharer's sources. "Because we have only the core kernel's sources we unfortunately can review the sharer only by reverse-engineering the binaries."

Ooops, did not read it the first time, sorry. All clear now. So we have a GPL FreeDOS SHARE that is practically useful only with the FreeDOS kernel, and we have a DR SHARE blob that is compatible with the EDR Kernel but probably not in all FAT-32 scenarios and hardly maintainable since no sources are available. Not ideal, but at least we know where we stand. :-) I have added an EDRSHARE package to the repo (pkgnet pull edrshare). Mateusz

I used to think referencing the uses of the EDR-DOS sharer jump table with those of lMS-DOS may prove fruitful because these tables could be similar in their semantics. However, I found that there is no simple correspondence between the two systems. https://hg.pushbx.org/ecm/edrdos/file/4cda0b9af813/drdos/fdos.mac#l163 lists 12 entrypoints actually used, albeit there's 15 defined in the table. https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/DOS/msconst.nas#l167 lists 14 used and 1 unused (first one, at index 0). They are named as follows: PUBLIC JShare EVEN JShare LABEL DWORD DW OFFSET badcallentry, BIOCODE DW OFFSET okcallentry, BIOCODE ; 1 MFT_enter DW OFFSET okcallentry, BIOCODE ; 2 MFTClose DW OFFSET badcallentry, BIOCODE ; 3 MFTclU DW OFFSET badcallentry, BIOCODE ; 4 MFTCloseP DW OFFSET badcallentry, BIOCODE ; 5 MFTCloN DW OFFSET badcallentry, BIOCODE ; 6 set_block DW OFFSET badcallentry, BIOCODE ; 7 clr_block DW OFFSET okcallentry, BIOCODE ; 8 chk_block DW OFFSET badcallentry, BIOCODE ; 9 MFT_get DW OFFSET badcallentry, BIOCODE ; 10 ShSave DW OFFSET badcallentry, BIOCODE ; 11 ShChk DW OFFSET okcallentry , BIOCODE ; 12 ShCol DW OFFSET badcallentry, BIOCODE ; 13 ShCloseFile DW OFFSET badcallentry, BIOCODE ; 14 ShSU Expanding the cryptic names: DW OFFSET okcallentry, BIOCODE ; 1 MFT_enter Enter a file (SFT just opened) into the Master File Table (MFT), either creating a new MFT entry or linking an existing one to this SFT. It also "checks for a file sharing conflict", and will return an error if the open must be rejected. https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l180 DW OFFSET okcallentry, BIOCODE ; 2 MFTClose Close an SFT, unlink it from its MFT and free the MFT if this was the last user. https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l279 DW OFFSET badcallentry, BIOCODE ; 3 MFTclU Close all files for a given user id https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l367 This uses BCS "Bulk Close SFTs". BCS uses CPS "Close Process SFTs" which contains the PSP walker https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare2.nas#l903 Aka 21.5D03 https://fd.lod.bz/rbil/interrup/dos_kernel/215d03.html The "user id" is the machine number at https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/INC/const2.nas#l146 called "network machine number for sharing/network (0000h = us)" in the interrupt list https://fd.lod.bz/rbil/interrup/dos_kernel/215d06.html#3063 (MSW apparently uses this for a VM id.) DW OFFSET badcallentry, BIOCODE ; 4 MFTCloseP Close all files for a given user id and process id combination https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l407 Also uses Bulk Close SFTs. Aka 21.5D04 https://fd.lod.bz/rbil/interrup/dos_kernel/215d04.html DW OFFSET badcallentry, BIOCODE ; 5 MFTCloN Close file by name. https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l450 This uses CPS (Close Process SFTs). Aka 21.5D02 https://fd.lod.bz/rbil/interrup/dos_kernel/215d02.html DW OFFSET badcallentry, BIOCODE ; 6 set_block Probably "lock file region" https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l536 DW OFFSET badcallentry, BIOCODE ; 7 clr_block Probably "unlock file region" https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l790 DW OFFSET okcallentry, BIOCODE ; 8 chk_block Check for lock during file access https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l1584 The lock related functions contain lots of commented code. And apparently the sharer doesn't distinguish read locks from read/write locks in this version. I seem to recall that MS-DOS v5 does do that according to the interrupt list. This is confusing to me because 21.5C doesn't accept a lock type according to the interrupt list: https://fd.lod.bz/rbil/interrup/dos_kernel/215c.html But the 21.52 tables list an MS-DOS v5 lock type: https://fd.lod.bz/rbil/interrup/dos_kernel/2152.html#table-01638 DW OFFSET badcallentry, BIOCODE ; 9 MFT_get Query MFT for an opened SFT from indices https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare.nas#l1756 aka 21.5D05 https://fd.lod.bz/rbil/interrup/dos_kernel/215d05.html DW OFFSET badcallentry, BIOCODE ; 10 ShSave "save information from SFT into an FCB" https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare2.nas#l1111 DW OFFSET badcallentry, BIOCODE ; 11 ShChk "check a fcb for share related information" https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare2.nas#l1071 DW OFFSET okcallentry , BIOCODE ; 12 ShCol "collapse identical handle SFTs in mode 70 only" https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare2.nas#l1147 DW OFFSET badcallentry, BIOCODE ; 13 ShCloseFile Close file from name if opened in compat mode, before REN or DEL https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare2.nas#l1267 This one interestingly doesn't return a status in any useful way. The sole caller at https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/DOS/delete.nas#l412 will construct a deny all SFT on the stack after calling ShCloseFile and try to open it with the sharer to make sure the deletion operation may proceed. DW OFFSET badcallentry, BIOCODE ; 14 ShSU SFT Update, broadcast a change in an SFT to other SFTs linked to the same file. This is the one most involved in cluster values and hence suspect for FAT32 extensions https://hg.pushbx.org/ecm/msdos4/file/59ed725f4b3d/src/CMD/SHARE/gshare2.nas#l1374

Reviewing the DR-DOS calls, without looking at all the callers (speculation): https://hg.pushbx.org/ecm/edrdos/file/4cda0b9af813/drdos/fdos.mac#l163 S_LOCKS equ 4*0 ; share lock/unlock region Probably to lock or unlock. S_UPDATE equ 4*1 ; update DHNDL from share Unclear when to call this. S_RECORD equ 4*2 ; update share from DHNDL Call after changing relevant fields, eg allocating a new cluster. Like ShSU. S_FDOSRW equ 4*3 ; validate proposed operation Check locks on file I/O S_DISCARD equ 4*4 ; discard all files on drive Seems to be for disk changes to invalidate remaining files. S_OPEN equ 4*5 ; files is opening, remember it S_CLOSE equ 4*6 ; files is closing, forget it S_OM_COMPAT equ 4*7 ; check open mode compatible Might be S_OPEN unconditionally succeeds and this must be called before to check? S_CLOSE_IF_OPEN equ 4*8 ; close if compat open, else deny Corresponds to ShCloseFile? S_DENY_IF_OPEN equ 4*9 ; deny if open shared/by others Similar use case as the temporary open in lMS-DOS delete.nas? S_GET_LIST_ENTRY equ 4*10 ; get open file list entry 21.5D05 ? S_CLOSE_FILES equ 4*11 ; close all files for given PSP/UID 21.5D03 / 21.5D04 ? 21.5D02 is reported by the interrupt list as not supported by DR-DOS v7.00 and doesn't seem to have an equivalent in this jump table either.