[Freedos-kernel] Share, HX, and pipes
Hello all, It is true that no DOS provides pipes. HX makes up for this by creating a new file and opening 2 instances (1 read only)--per the HX docs that I looked at on Sunday. If SHARE is not loaded, this ostensibly "may not work as expected." Christian: Is your file sharer ready yet (able to load & reliably share files)? Does it work under FreeDOS, or RxDOS only? It seems to me that use of assembly is better than C _under certain conditions_: If the active developers prefer to write assembly If C is unclear/unportable If an assembly program is ready If a C version is deemed stable and unlikely to change, a translation is fit But I personally will take any working file sharer (if it's OW only, I would like a smaller download). Thank you, Ibidem -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Web site ISP problems
Over the weekend, the ISP that handles our DNS did an upgrade and unfortunately it didn't happen smoothly, so they are effectively down right now. Based on what we know, this may take some time before they can correct it. Until this is fixed, www.freedos.org will not be resolvable in DNS, so it will appear as though the FreeDOS site is down. Instead, developers and users can visit the FreeDOS web site at its alternate address: http://freedos.sourceforge.net/ . Sorry for any inconvenience this may cause. Special thanks to Jim Hall for all the work he's done with respect to this issue. Pat -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
> 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: h 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
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Am 06.07.2009, 10:00 Uhr, schrieb Eric Auer : > > Hi Christian, > I know about the OEM ID and the DOS-C release string which can be retrieved by Int21.33FF. I don't see how SHARE could use that... > >> I suppose there's no way to get the kernel's build number for SHARE >> then? > > The revision number (eg 38 for 2038) is returned in BL > if you call int 21.30, which also returns OEM ID 0xfd > for FreeDOS :-). Okay, but I won't depend on that. Some SETVER TSRs completely take over Int21.30 (and Int21.3306), or only pass some of the values from the DOS kernel. >>> - is currently tied to Borland Turbo C compilers - options are to [1] >>> update to be more compiler neutral C, [2] convert to OW compatible >>> only, [3] merge into kernel so not a standalone app any more, [4] >>> rewrite in assembler, or [5] something I missed. > > I am not sure how big 3. would be The code usage would be smaller. Think how both the kernel and file sharing code could omit the interfacing and function number/dispatching code. Also, all code part of the main kernel code would be relocated to UMA or HMA too. > but the main RAM usage is > in data tables... It might be interesting to put those into > HMA when SHARE would become a part of the kernel. What exactly prevents a modular (i.e. not part of the kernel) SHARE from putting data elsewhere? > I also do > think that 4. might be a nice idea :-). I presume you don't want to use the (free) NASM source of my RxDOS file sharer ;-P Regards, Christian -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
> Given the number of hooks, some of which are not even documented, > I would say that the current implementation of SHARE is smoother. I agree. > This "format of share exe hooks" table about MS SHARE lists: > > - a routine of unknown purpose, probably not called Since SHARE of MS-DOS 3.3+ is documented to set this pointer to an invalid value, calling it would crash the system. Conclusion: Yes, it's not called. > - something called on open and something called on close > > - routines called by DOS when int 21.5d02/03/04 are requested > (so share implements those close-all-matching things for dos) > > - routines to lock/unlock regions and check for locking > > - a get open file list access thing This is for Int21.5D05. (BTW, if you want to use another notation than Interrupt dot function, you don't have to use mine.) > - something possibly about updating FCB from SFT and knowing clusters Which shows that MS-DOS SHARE.EXE, at least minimally, knows about such low-level stuff as clusters. Bad. You forgot the function about checking an opened SFT against FCB. > - a routine to "close file if duplicate for process" Important to note that the file must have sharing mode 7 (111 binary): this is the special "Net FCB" mode only enabled during server calls. Since this mode is apparently only described (in RBIL) at Int21.3D (Open) and for this hook, I presume MS-DOS handles it like local FCBs when applying sharing rules (so the mode is matched like mode 0, COMPAT), and collapses multiple net FCBs opened for the same file from the same (net) process. Need to test what mode MS-DOS passes to the redirector when opening remote files with FCBs itself. > - something to close the most recently opened files? What is "the most recently opened file"? Possibly it means SHARE.EXE uses the SFT pointer in the SDA, which is called "pointer to current SFT" in RBIL (table at Int21.5D0B). > - a routine to update directory info from SFT entries (size, time) > > Most of those MS SHARE hooks use DOS SS and DS and manipulate > kernel data structures instead of having normal call parameters. What we are used to with the redirector calls. > Certainly not a nice API either, compared to FreeDOS SHARE > which uses custom extensions to the int 2f SHARE API for > open, close, check, lock and unlock. Note that I do think > it might be nice to support int 21.5d02/03/04, but you can > also put that bit into the kernel instead of into SHARE. Or you could add some more functions to the Int2F API. >> share exe as part of the kernel is of course a trade-off: it's natural >> for an OS, but for DOS you'd like the base kernel small and only >> include things that most people use (and most people don't need >> SHARE). > > Good question - what apart from Windows uses SHARE? Maybe MSCLIENT? Any software opening files at the same time, in theory. COMMAND.COM opens temporary files for pipes and I/O redirections that are left open for the child process(es), file sharing is useful to prevent the child(s) from deleting/writing these files (with other handles than that inherited from COMMAND.COM). MSCLIENT really requires it only when used as server. Any other DOS file server probably requires it as well, at least those allowing reading and writing of files. > I also wonder how big, roughly, a kernel built-in SHARE would be. See the other mail for that. Regards, Christian -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Hi Christian, Please explain in what way Win 3 uses virtual(?) machine numbers and why supporting them is needed to get a Win compatible SHARE. I also wonder what enumerates machines and how in a real network. MS probable does not use anything fancy like checksum of IP/name? Regarding the new API thing: More like MS is not the same as exactly like MS, 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 forgot to complain about one thing of FreeDOS SHARE in my > list: Unless the kernel does it itself (even without SHARE), > multiple open SFTs aren't updated when file information (such > as file size and first cluster) is changed by one process > accessing the file. I think I noticed such code in the kernel already :-) Not sure. Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Hi Christian, >>> I know about the OEM ID and the DOS-C release string which can be >>> retrieved by Int21.33FF. I don't see how SHARE could use that... > I suppose there's no way to get the kernel's build number for SHARE then? The revision number (eg 38 for 2038) is returned in BL if you call int 21.30, which also returns OEM ID 0xfd for FreeDOS :-). > The functions in question (Int21.5D subfunctions 02h..05h) interestingly > aren't supported by Novell/DR-DOS too. The functions are: Close file by > name, Close all files for given machine number [probably used by > networking?), Close all files for given machine number & PSP, Get open > file list entry (provides ASCIZ filename of a specified SFT to > applications, might be useful). This is an old missing feature - while I know no software that uses it, I agree that it would be potentially useful, both the get open file list entry and the close-some ones. >> - is currently tied to Borland Turbo C compilers - options are to [1] >> update to be more compiler neutral C, [2] convert to OW compatible >> only, [3] merge into kernel so not a standalone app any more, [4] >> rewrite in assembler, or [5] something I missed. I am not sure how big 3. would be but the main RAM usage is in data tables... It might be interesting to put those into HMA when SHARE would become a part of the kernel. I also do think that 4. might be a nice idea :-). > As mentioned in the SHARE source code (at the Int2F handler code), the > inline assembler hack used for interrupt processing should be replaced by > an external object module if the code stays C (thus options [1] and [2]). True... Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
Hi Bart, > Yes, that has been in the kernel since the initial implementation by > Ron Cemer. It used to work on fnodes but now updates the SFTs. > These routines (mainly merge_file_changes() in fatfs.c) could be moved > to share.c if the hooks from RBIL table 01636 were implemented. Given the number of hooks, some of which are not even documented, I would say that the current implementation of SHARE is smoother. This "format of share exe hooks" table about MS SHARE lists: - a routine of unknown purpose, probably not called - something called on open and something called on close - routines called by DOS when int 21.5d02/03/04 are requested (so share implements those close-all-matching things for dos) - routines to lock/unlock regions and check for locking - a get open file list access thing - something possibly about updating FCB from SFT and knowing clusters - a routine to "close file if duplicate for process" - something to close the most recently opened files? - a routine to update directory info from SFT entries (size, time) Most of those MS SHARE hooks use DOS SS and DS and manipulate kernel data structures instead of having normal call parameters. Certainly not a nice API either, compared to FreeDOS SHARE which uses custom extensions to the int 2f SHARE API for open, close, check, lock and unlock. Note that I do think it might be nice to support int 21.5d02/03/04, but you can also put that bit into the kernel instead of into SHARE. > share exe as part of the kernel is of course a trade-off: it's natural > for an OS, but for DOS you'd like the base kernel small and only > include things that most people use (and most people don't need > SHARE). Good question - what apart from Windows uses SHARE? Maybe MSCLIENT? I also wonder how big, roughly, a kernel built-in SHARE would be. Eric -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
