> Please explain in what way Win 3 uses virtual(?) machine numbers > and why supporting them is needed to get a Win compatible SHARE.
MS-DOS usually sets the net machine number (offset 1Eh of SDA, table at Int21.5D0B) to zero (indicating "local") inside its Int21 dispatcher, unless the server call (Int21.5D00) is used with another value but zero in the DPL's machine field. The machine number is used when opening files to put it into the SFT machine field. It's also checked against the SFT field when accessing an opened SFT (error 0006h, "Invalid handle" is returned if they don't match). Windows jumps in by enabling it's virtual machine number handling per DOS patches (there's also a bit for that in the "Patch DOS" request from DOSMGR, Int2F.1607 with bx 0015h). The machine number in the SDA is set to the virtual machine number (probably same as returned by Int2F.1683) by Windows itself, and MS-DOS doesn't modify the value when Windows is present. This means it doesn't (A) clear the value to zero inside the Int21 dispatcher and (B) doesn't use the machine field of the DPL passed to Int21.5D00. I don't know how exactly the latter affects DOS servers. Despite forcing the machine number to the VM ID, the patch also disables checking whether the machine number of the SFTs match. A wild guess: This is to enable local handles left open from before Windows started (value zero as machine) being accessed by the owning programs from inside VMs (non-zero machine number). > I also wonder what enumerates machines and how in a real network. > MS probable does not use anything fancy like checksum of IP/name? With the DOS file server support, this is determined by the server/network software. (MS-)DOS only uses the word value provided inside the server call's (Int21.5D00) DPL. > Regarding the new API thing: More like MS is not the same as > exactly like MS, I aim to leave the main differences in the internal API. The external API (and file sharing behaviour) should be the same. > and as you already said, if MS designed some > weird thing then it is not necessarily good to clone that. As > the MS style hooks manipulate kernel internal data, they do not > make adding 64 bit support any smoother than our current API. I DID NOT copy the MS-DOS hooks. My (single) file sharing hook doesn't depend on SS or DS pointing to DOSDATA and uses call parameters instead. All passed pointers are far, so they can point the file sharer into DOSDATA or anywhere else. Here's a draft of the API's short description (not anything coded yet): === RxDOS file sharing hook functions: 0000h RxDOS file sharer installation check [currently not called by the kernel] 0001h Open file (es:di-> SFT, ds:si-> filename) 0002h Change access mode (es:di-> SFT, bx = new mode) 0003h Close file (es:di-> SFT) [kernel assumes this always succeeds] 0004h Read from file (es:di-> SFT, ds:si-> region structure, dx = PSP) 0005h Write to file (es:di-> SFT, ds:si-> region structure, dx = PSP) [size of zero indicates to truncate file] 0006h Lock file (es:di-> SFT, ds:si-> region structure, dx = PSP) 0007h Unlock file (es:di-> SFT, ds:si-> region structure, dx = PSP) 0008h Create new file or directory (ds:si-> filename, dx = PSP, cx = machine) [always allowed by current file sharer, still calls function 0001h to open] 0009h Delete file or directory (ds:si-> filename, dx = PSP, cx = machine) [directory must be empty. allowed by file sharer unless file open] 000Ah Update file's metadata with filename (ds:si-> filename, dx = PSP, cx = machine, bx = flags which metadata is updated, es:di-> metadata update callback structure) [renaming of directories containing opened files disallowed by file sharer, since the path would change] 000Bh Update file's metadata with SFT (es:di-> SFT, dx = PSP, cx = machine, bx = flags which metadata is updated, ds:si-> metadata update callback structure) 1000h Int2F.1000 hook (ss:bp-> stack frame with bp, ip, cs, flags) 10xxh Int2F.10 hook (ss:bp-> stack frame with bp, ip, cs, flags) 5Dxxh Int21.5D hook (ds:si-> stack frame (ax..flags), es:di-> DPL) [kernel only calls this for appropriate subfunctions] === Adding 64-bit file size support here is as easy as declaring that the file region structure contains 64-bit values (always, even if FAT+ and 64-bit file size support isn't compiled into the kernel). If it was defined otherwise initially, the "compatible version" (version number checked for API compatibility) of the kernel would be increased so older file sharer versions would refuse to run on the new kernel. Regards, Christian ------------------------------------------------------------------------------ _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
