Re: [Freedos-kernel] Intent to tag 2040 release
Bart's later fixes based on I think dos386's feedback (could be Christian Masloch, can't recall right now who reported). For the record: If you're talking about the FAT crosslinking issues, I didn't report anything regarding that. Here's a report again not regarding FAT crosslinking issues: In revision 1634 which adds CONFIG.SYS options via MEMDISK command line support, in _query_memdisk the passed drive is ignored (and 0 = first floppy is always used) because this sequence of instructions is wrong: mov dl, al ; drive number (...) mov eax,454d0800h ; magic1 + AH=8 (...) mov ecx,444dh ; magic2 mov edx,5349h ; magic3 + mov ebx,3f4bh ; magic4 It should be: mov edx,5349h ; magic3 + mov dl, al ; drive number (...) mov eax,454d0800h ; magic1 + AH=8 (...) mov ecx,444dh ; magic2 mov ebx,3f4bh ; magic4 For something different, regarding the comment why this MEMDISK support is currently only provided in 386 builds, wouldn't it suffice to use the byte in the list of lists that shows whether a 386 is available? Ah, I see that the kernel doesn't actually set that byte in 8086-compatible builds ever. The 8086-compatible kernel should check whether a 386 is in use, and set the byte if so. Fix that and you can use the byte as argument to _query_memdisk or check it from within the function yourself or whatever. Regards, Christian -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Process termination uses flags on stack
Hi, I found that running with the FreeDOS kernel (tested on build 2038 from 2008-03-08 as available on Rugxulo's site) my program sometimes mysteriously enabled the Trace Flag when returning from a child process. This does not happen in MS-DOS. MS-DOS (tested 6.22 and 7.10) apparently does not use the flags on the parent's stack frame when returning, it instead sets some default flags. These default flags ignore the Carry Flag and Trace Flag as stored on the parent's stack frame, both are always cleared. The stored Interrupt Flag is ignored too, it's always set. During execution of my program's child process, my program fails to properly preserve its own stack for DOS to use. To be clear, the stack contents are lost - the stack itself is free and usable at the time the child process terminates. This is not a problem in MS-DOS, because cs:ip and the flags are properly set (with the Trace Flag always off) and my program does not depend on any of the registers to be preserved. The appropriate place for a patch would be in the function return_user() in task.c, near the end, where cs:ip on the parent's stack is reset to the stored Int22 handler. Adding this line might be sufficient: irp-FLAGS = 0x200; /* clear the Trace Flag and Carry Flag. set the Interrupt Flag */ (There's no definition FLG_INTERRUPT in pcb.h so I used the immediate value.) Regards, Christian -- Nokia and ATT present the 2010 Calling All Innovators-North America contest Create new apps games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Boot sector LBA detection error
of course you are right. but maybe you are missing the point ... why the original author (m2) wrote it exactly as it is: to save precious 2 bytes in the boot sector code This is a problem for the FAT12 OEM boot sector only, all other boot sectors can be assembled with this patch without problems. To allow the FAT12 OEM boot sector to use this patch, I'd suggest to move the LBA disk access packet into the sector (where the first jump currently jumps to) but only declare and initialize the first word (LBA_SIZE) there. The initial jump would be adjusted to pass control to the code following after this (2 bytes higher than now). This would save us the 6-byte instruction mov LBA_SIZE, 10h (really mov word [bp+0200h], 0010h) below read_next i.e. it would save 4 bytes overall. The packet would, once used, overwrite 14 bytes of following code but this initial part is safe to overwrite then. (NASM preprocessor conditionals could be used to check that only the initial part is overwritten.) Regards, Christian -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Boot sector LBA detection error
Hi, the LBA detection of the FAT12/FAT16 boot sectors (both for the FreeDOS and OEM kernels) could misdetect that a BIOS does support LBA if it doesn't really. This is the used code (after calling Int13.41 for the boot unit): shr cx, 1 ; CX must have 1 bit set sbb bx, 0aa55h - 1 ; tests for carry (from shr) too! jne read_normal_BIOS This test succeeds if (cx1) (bx==AA55h) as intended but also succeeds if (!(cx1)) (bx==AA54h). This is a highly unlikely case but nonetheless an error which should be corrected. Example: sub bx, 0AA55h jne read_normal_BIOS shr cx, 1 jnc read_normal_BIOS Note that the code after this expects bx to be zero, so sub must be used here instead of cmp. I exchanged the order of the test for cx bit 0 (disk access support) and the correct signature in bx since it's easier to understand the code this way. (It would work the other way around as well.) Regards, Christian -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] suggestion - put kernel svn revision version number in sys config data
Alain mentioned that it is hard to keep an overview which kernel file is which version, for example if you want to report a problem or want to compare kernels. For that it would be a great help to put for example the SVN release number in there. SYS CONFIG can then be used to show it for any kernel file without having to boot with the file. Any chance there will be a (21.33FF style) call to retrieve that number from the running kernel too? You can't be sure that the kernel file on C: or A: or wherever is the one actually running. (Assuming a standard system, the file still could have been updated to another kernel revision.) Such a 21.33Fx call could also return the build number for convenience, possibly with a special value such as 0 or -1 if it's no official build. The config would still be less than 16 bytes with version number in it. I think it would be a valuable small extra. Putting the SVN release number will only add a 16 bit int. A 16-bit interrupt? Okay, I know what you mean and the kernel is developed mostly in C anyway and sorry for that :/ Why is it important to fit the CONFIG area into 16 byte? Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Freedos boot floppy and claimed bugs
Am 21.10.2009, 03:47 Uhr, schrieb dos386 dos...@gmail.com: The kernel may need to work around the Linux VFAT patent avoidance HACK in Linux kernel 2.6.30+, which writes 100% illegal names to the SFN entry when LFNs are used. Christian was going to include a workaround in Rx-DOS (NASM GPL code); it may help to see that. COOL. Now really nobody can whine about the evil FAT+ hack violating the saint FAT spec by MacroSoft saying that no file may have more than 4GB ... That doesn't make sense. VFAT isn't associated with file sizes at all. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-devel] newer motherboards and [U]EFI, large-sectored drives
Hi Eric, not new... Floppy supported 128 to 1024 bytes, for example... Yes, FreeDOS only supports 512 bytes at the moment. For unknown reason, this became even more hardcoded than it was before short ago. As far as I remember, the biggest that MS DOS supported was 4096 for WORM, but only with driver.sys? Another source mentions 2048 bytes used for MO drives... And wasn't there some far-east floppy format with 1024 byte sectors, too? Technically, MS-DOS should support 8192 too. Bret mentioned this in some notes. It would also fit the byte count used as directory entry index into a single sector (256 * 32 = 8192). Note that supporting bigger sectors will need bigger buffers at some point Yes, any buffer needs to have a (f.e.) 8192 byte data field then. Even for drives which have a smaller sector size. With the MS-DOS compatible buffers that FreeDOS currently uses (?) the useless space at the end of these large buffers can't be re-used when buffering drives with smaller sector size. and some way of detecting actual sector size. On DOS's side, simply call the Get BPB device function (and insure the BPB is valid, i.e. no crucial values zero or -1). The bytes per sector field must be set correctly then. The default block device has to obtain the sector's size from the BIOS. There doesn't seem to be a standard Int13 call for that. LBA BIOSes may provide Int13.48 (Get drive parameters), the returned table always contains a bytes per sector field. [I tested this on a 2002 standard PC BIOS, and it supports this call and returns valid data.] Otherwise, we either have to assume 512 bytes per sector, or read a single sector into an initialized 8192-byte buffer and determine how many bytes the read actually changed. I do not know whether MS DOS ever could BOOT from drives with big sectors. I don't know either, but with the single-file boot architecture used by FreeDOS (which I'll adapt too) this depends solely on the boot loader in the boot sector. Note that we should also check whether kernel, FORMAT, FDISK, DOSFSCK and maybe other tools have sign overflow problems for 512 byte per sector drives above 1024 GB. Suggestion: Just _never_ use signed data types for anything were a negative value doesn't make sense, such as file sizes and sector numbers ;-) Of course as long as FDISK is happy (or you simply use Linux FDISK) you can limit your self to drive letters of at most 1024 GB each, avoiding any problems. Of course as long as you are happy with it you could restrict yourself to 8 GiB drives which can be addressed by CHS. With this reasoning we can avoid any more effort for developers! Talking about GPT and UEFI: Tom often mentioned that we should add GPT handling to our partition table parser (initdisk.c). Note that this might make the parser significantly more complex - not sure. I'm pretty sure the GPT stuff allows partitioning with 64-bit sector addressing. This raises the question how this can be supported by us. Do EFI compatibility BIOSes support LBA with actual 64-bit addressing? (The LBA packet's sector number field is a 64-bit word, but actual implementations [that I've seen] used only 28 or 48 bit of these; known as LBA28 and LBA48. On the other hand, 48-bit addressing already enables very large drives.) DOS file systems currently use 32-bit addressing for sectors. This can't be worked around by the OS, a new file system is required for that. However, such a 32-bit file system could reside at positions on the (GPT) disk were it needs to be addressed by LBA48 or LBA64. This means: the DOS file system driver doesn't need to know about 64-bit sector addressing; the block device installed for DOS when booting does have to. On the other hand, not THAT many places would have to be changed to make FreeDOS aware of other sector sizes, at least if only block devices loaded AFTER boot would have to support other sizes. How to access installed hard disks with larger sector sizes then? (Or anything which looks like a hard disk or floppy disk, i.e. can be accessed by DOS when booting.) Bret mentions in some places that a few USB pen drives do have larger sector sizes, such as 2048 bytes. DOS couldn't boot from these then, too. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Int21.7304.sf03 should actually copy/move FATs
Hi, the kernel is supposed to support all Int21.7304 (Set DPB/BPB fields for formatting) subfunctions but doesn't provide subfunction 03h completely. The current code simply gets (and sets as requested) the flags from the BPB, but doesn't move the FAT accordingly. MS-DOS apparently contains code to do so. This isn't documented in RBIL, but can be tested by setting the active FAT (of a FAT32 drive) to a single one, then resetting the flags to include all FATs later. The second call overwrites the previously inactive FAT(s) with a copy of the active one. (Depending on the size of the file system, this results in a short delay. If this isn't the case, files/directories can be created (changing FAT entries) while only the active FAT is used and dosfsck can be used to insure both FATs have the same content later when the flags were reset.) Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] new kernel release pending
Hi, Which aspects of SFT changed and how? Are there potential performance issues because we no longer can cache certain data in extra fields of fnodes? It seems to me that the fnode (as defined in fnode.h) doesn't save any information that isn't contained in the SFT, except the new file dates and times (in the directory entry) which are accessed with a filename instead of a SFT; so they're not required in the SFT. Note that the directory entry's cluster and index into cluster (as found in the fnode) can be computed with some shifting from the entry's sector and index into sector (as found in the SFT) when the sector size, cluster size and the sector of the first cluster is available (all found in a valid DPB or EDPB). * Fixed Int21/AX=4409 for drives from device drivers. What was wrong? I'm interested too. Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] DDT layout differences
Hi, the DDT defined in device.h differs from that used by MS-DOS for FAT32. (Applicable to MS-DOS 7.10+ only.) MS-DOS includes the 12 reserved FAT32 BPB bytes in the BPBs contained within the DDT. MS-DOS also removes the 6 reserved bytes behind the second BPB in the DDT. The ddt_flags field is set to 20h by MS-DOS for FAT32 partitions, but I think that's less important than the layout and size difference. Here's a correction: ... bpb ddt_bpb; /* BIOS Parameter Block */ #ifdef WITHFAT32 UBYTE ddt_bpbreserved[12];/* part of FAT32 BPB above */ #endif UBYTE ddt_flags; /* bit 5: 32-bit FAT bit 6: 16-bit FAT (else 12-bit FAT) bit 7: unsupportable disk (all accesses will return Not Ready) */ UWORD ddt_FileOC; /* Count of Open files on Drv */ UBYTE ddt_type; /* device type */ UWORD ddt_descflags; /* bit flags describing drive */ UWORD ddt_ncyl; /* number of cylinders (for partition only, if hard disk) */ bpb ddt_defbpb; /* BPB for default (highest) capacity supported */ #ifdef WITHFAT32 UBYTE ddt_defbpbreserved[12]; /* part of FAT32 BPB above */ #else UBYTE ddt_reserved[6];/* (part of BPB above) */ #endif ... Regards, Christian -- 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/Challenge ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [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. This is very similar to what COMMAND.COM (/FreeCOM/4DOS/RxCMD) does for I/O redirection and pipes between commands ( |, , on the command line). If SHARE is not loaded, this ostensibly may not work as expected. Yes, because the file might be written by other processes than the one that got to write the pipe, or it might be deleted by a process. The former causes unexpected input for the reading process, the latter might cause filesystem corruption and/or data loss. Christian: Is your file sharer ready yet (able to load reliably share files)? No. Most code of the actual hook handling is done, but it doesn't load yet and some of the code to call it from DOS is not yet integrated in the kernel. The former will be fixed by migrating the TSR installation/command line parsing/configuration from another TSR I wrote some time ago. Does it work under FreeDOS, or RxDOS only? Currently I'm only working on RxDOS, so it doesn't work on DOS-C (FreeDOS kernel). Since the hook method uses a far call with a number of parameters in registers, some complicated interfacing will be required if it's to be used with DOS-C's C source code. Another problem is that the file sharer installation code currently requires RxDOS. It checks whether the running DOS is RxDOS (7.30+, so my new version only) by issuing Int21.335E - a newly defined call that returns a special value in ax to tell that a DOS version supporting this call is present. RxDOS returns Rx, along with some version information in the other registers (dx, cx, bx, si, di). If that check succeeds, the new RxDOS internal list of pointers is retrieved using Int21.335F. The version number at the beginning is checked, the pointer to the list of hooks is retrieved and the version number at the beginning of the hook list is checked as well. Also, to set the file sharing installed flag in the SDA, the file sharer calls the original Int21 entry (found in the list of pointers too) to get the address of the SDA. DOS-C needs at least a reliable installation check with build number, and a new function to return the address of the file sharing hook if it was to support the RxDOS file sharer. Instead of changing DOS-C to use my file sharer, the current FreeDOS SHARE could be adapted to handle things correctly. The API would at least require an update, however. If Jeremy is looking into SHARE right now, you won't have to use my code. 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 If the code is to stay in memory If developers tend to care more about source compatibility to different compilers than actual source content ;-) If the assembler is more free :-P (recent NASM versions are 2-clause BSD) Regards, Christian -- 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
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
Am 06.07.2009, 10:00 Uhr, schrieb Eric Auer e.a...@jpberlin.de: 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
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
I guess SHARE might be something to test w/ HX. Japheth's documentation claims that SHARE is needed for pipes, Cygwin requires pipes, and FD SHARE is too crippled to work. If Japheth knows about a bug, he should explain what EXACTLY is wrong so somebody has a chance to fix it... I don't know what Japheth has to complain about it, but I know that DOS-C's SHARE: - is a C program that stays in memory without usage of any assembler code. Increases memory usage much. - uses an interface on Int2F which probably isn't as good as an internal hook. (MS-DOS uses a number of hooks partly documented in RBIL, I use one hook which dispatches to different functions using the function number in ax. The latter will of course be described within the release's documentation.) - can't be removed once installed. I think this limitation isn't just in SHARE but also in the kernel. - doesn't provide a dedicated installation check. The original MS-DOS SHARE.EXE installation check Int2F.1000 is most unreliable. For example, Win3.x reports that SHARE.EXE is installed disregarding whether it actually is, as do a number of TSRs designed to fake file sharing support. - doesn't use the (under Win3.x virtual, else network) machine number at all. Since SHARE also works without access to SFTs, the sharing records require a new field to support the machine number. - was written by people that probably understood first sharing mode and first access mode wrong. There is no single first mode. The first mode fields in the sharing record are unnecessary. The allowed mode table must be applied between the mode of EACH existing open and that of the new open for the same file. I think the problem doesn't just ignore subsequent more restrictive opens of a file (allowing too much for new opens), but could also carry on restrictions of one open after it was already closed (disallowing too much for new opens). - uses a complicated allowed mode (and exception) table that can be simplified, since entries that create critical errors (value 2 in the table) are simply all entries disallowing the new open (otherwise value 1 in the table) where the new open is in compatibility mode. - allows opening the same file two times in compatibility mode always, but it should only be allowed if the (virtual/network) machine number of the opening process matches. (This isn't documented in RBIL, the tests were apparently done without usage of Win3.x or the Server Call Int21.5D00.) Since SHARE doesn't know about machine numbers anyway, this can't be done. - (according to the commentary) returns sharing record numbers of 0..32767 (positive 16-bit values) to indicate success on opening the file. The kernel should increase such a returned value before using it as sharing record number in the SFT. Value 0 indicates the file isn't handled by file sharing in MS-DOS. - doesn't check whether it runs on the correct DOS version. It doesn't even check whether it runs on its kernel at all. Even if it would, since the kernel provides no way to get its version number, it couldn't check for that anyway. I initially considered to use DOS-C's SHARE but dropped that idea after my examination. 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
- uses an interface on Int2F which probably isn't as good as an internal hook. (MS-DOS uses a number of hooks partly documented in RBIL, I use one You mean table 01636, format of share exe hooks? It doesn't matter, but probably yes. (I don't know the number, but it's inside the Int21.52 Get List of Lists description.) Note that our SHARE does not implement int 21.5d02/03/04/05 yet. I wonder which apps actually use those functions, though. I don't know. I'll support these, however. (Still didn't write them, but planned.) - can't be removed once installed. I think this limitation isn't just in SHARE but also in the kernel. It is also in every other version of SHARE that I know. Shrug... Yes, great. Since Microsoft made it bad, let's make it bad too, especially when doing it another way but still as bad (without compatibility reasons). If I had to re-invent SHARE anyway, I would actually make it a PART of the kernel, lowering memory footprint. That's what Udo said too. I prefer a TSR-type solution (without hooking interrupts) however, since some obscure things might better work with file sharing disabled. If you want the option to disable it, why not free the memory used by the code then? Of course you cannot unload it then either. You could still have some way to resize the data structures used, on the fly, after booting... Not as difficult when using a dynamic heap structure for all data ;-) - doesn't provide a dedicated installation check. The original MS-DOS SHARE.EXE installation check Int2F.1000 is most unreliable. For example, Win3.x reports that SHARE.EXE is installed disregarding whether it actually is, as do a number of TSRs designed to fake file sharing support. The int 2f.1000 install check works fine, thank you. Apps which respond to the check usually do so because they already support what SHARE does. I think Windows 3 implements the share stuff itself for DOS apps started from Windows? It does not. Of course you can and probably will invent a new API, the yes the only good SHARE, the one from Christian, is loaded, but what will call it? ;-) You didn't forget yet that I'm working on a kernel? So my yes the only good kernel the one from Christian as you say ;-) will call it. I designed my only-good API so that it would be usable easily by both the one calling it (the kernel) as well as the one providing it (the file sharer, or a dummy handler which always returns error 0001h - invalid function). - doesn't use the (under Win3.x virtual, else network) machine number at all. Since SHARE also works without access to SFTs, the sharing records require a new field to support the machine number. I do not get the point you are trying to make here. But maybe this means that our SHARE is not workgroups compatible yet? Yes. SHARE is neither DOS network compatible (if the FreeDOS machine acts as server) nor Win3.x DOS box compatible (disregarding whether there's any network). I am not familiar enough with the intricate details of SHARE to comment on that. Suggest a patch if you want to... ;-) [...] Sounds like [...] [...] As said above - I do not know enough about details to comment on this. Anyone there familiar enough with it? Any kernel developer to work on file access? And please don't say you know the kernel part of file access but not SHARE. Aren't they developed together? Basically you say SHARE misbehaves if you use network drives and apps on different computers open the same file after you already said that SHARE does not yet support network node addresses anyway. Yes, that's what I said. - doesn't check whether it runs on the correct DOS version. It doesn't even check whether it runs on its kernel at all. Even if it would, since the kernel provides no way to get its version number, it couldn't check for that anyway. If by the kernel you mean the FreeDOS kernel I thought that's implied by the list :-) there are enough ways to get the version number. Most basic would be getting the normal DOS version number, Most unreliable since SETVER and similar programs as VERSION=, ANYDOS, CALLVER. possibly checking for OEM is 0xfd and version is at least 3.something. You can also check for true number and even get FreeDOS specific version information if you want to be very picky. 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 to differentiate kernel releases. Does the string have a fixed format specified anywhere? Is there any other call to get specific information? I initially considered to use DOS-C's SHARE but dropped that idea after my examination. And now you probably wrote something completely new, with a completely new API, which does what you think a SHARE should do instead of enabling DOS to do what other DOSes do when they have SHARE loaded ;-). Or maybe you will write something more
Re: [Freedos-kernel] Past bugs and CONFIG dot SYS
- doesn't check whether it runs on the correct DOS version. It doesn't .. 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 to differentiate kernel releases. Does the string have a fixed format specified anywhere? Is there any other call to get specific information? No; the string has no fixed format ... I suppose there's no way to get the kernel's build number for SHARE then? ... I don't see where not complaining about FreeDOS SHARE makes it better either, so I decided to complain. ... complaining never accomplishes anything except perhaps making one feel better - however, information about deficiencies in current implementations is encouraged, and perhaps the only way they will ever improve. So let's say I provide some information now. ... If you're interested in more information about my development (as opposed to FreeDOS SHARE complaints), tell me. We could proceed here if another DOS kernel's software isn't too much off-topic on the Freedos-kernel list ;-) or move to private e-mails. as long as the discussion is relevant to kernel compatibility, discussing on this list is fine (it is a pretty low volume list and I think those here either are watching out to ensure the FD kernel doesn't diverge into an incompatible mess or find the inner workings of DOS/OSes interesting). Thanks for clarifying this. If the discussion does become too off-topic, I would appreciate being CC'd in any off list emails. No Denglisch (German + English terms) technical mails between me and Eric anymore ;-) To summarize discussions (and add a few points) about FreeDOS share: ... - does not fully implement the API as implemented by MS share (no specific applications known to require them mentioned / useful for testing?) - need to research further 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). - 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. 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]). Regarding the updating of SFTs opened for the same file (previous mail), is that already in the kernel? If not, I want to add that point to your list for SHARE. Regards, Christian -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Debug mode patch for TC
Additionally, I used copy con: to record some messages. One interesting thing it says is Truename CON: C:/CON or some such thing. Is this a bug, or standard behavior? No bug, it's compatible to MS-DOS. If the input is a character device's name without any directory information (but a drive letter is okay), the return is a drive specification followed by forward slash followed by the device's name. This is documented in Ralf Brown's Interrupt List (Interrupt 21h, Function 60h - Truename). Regards, Christian -- ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
[Freedos-kernel] Self-owning PSP termination bug not yet fixed
The subject says it all. I reported the bug almost three months ago, is it going to be fixed? I'm quoting the relevant part of my first mail on the subject below. The short version of it is that the only things not done if the PSP is its own parent is the memory deallocation and closing of all opened SFTs. All other termination operations have to be done. DOS-C however does none of these other operations. To fix this, the detection for self-owning PSPs in inthndlr.c has to move to return_user() in task.c. So change this line: if (!tsr) to include the self-owner check: if (!tsr !(p-ps_parent == cu_psp) ) And remove the following lines from inthndlr.c: (below case 0x4c:) if (((psp FAR *)MK_FP(cu_psp, 0))-ps_parent == cu_psp) break; Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Still no reason to add experimental things to stable now :-) The solution is easy: Add it to the UNSTABLE fork No. Because first, I don't develope DOS-C, and second, forking is bad and makes merging changes back in harder. Since your opinion seems to be that filesystem extensions can never be added to the stable or official release, this is of course what you want to happen to them: Implement it into unstable and it will never find it's way to stable. The problem here isn't just that you don't want to release new features in official builds, it's that you support forking another single build (which, by now, is already years behind in improvements of stable - see below why) instead of adding the feature to (unofficial) builds directly derived from the latest stable. Of course that's just my opinion and I'm not even a FreeDOS developer, so feel free to ignore it. At least I didn't yet see anything changed in stable which was derived from unstable Actually not much apart from COUNTRY SYS support in unstable has very favorable risk/complexity versus gain in features ratio at the moment, unfortunately... So why write a risky feature at first, if there's apparently no chance it will be merged to stable? Additionally, this raises the problem that people that want to write new features into unstable first will have to cope with a kernel already full of other unstable features. So I won't recommend re-using the outdated unstable anymore. , and improvements of stable aren't added to unstable either. This is because more or less the only developers were Jeremy, Lucho and Arkady - the latter is kind of missing and Jeremy just returned a few weeks ago from being so busy with the real world real life that he simply had no time to continue working on the unstable branch. Lucho now has other big things as 4DOS. I'm of course not blaming these people. However, as I mentioned previously, if all developers of stable had merged their changes (as applicable) to unstable as well, this would make life easier for people that want to test new features for stable on unstable. (And please don't argue that the developers of stable would have to know unstable then, too, because they of course should do if it's more than a fork.) If they were IFDEFed then you would have no chance understanding either ;-). I doubt I would have a problem with it if the source was divided that way. What do you mean by either? The stable / unstable diff is maybe 1000s of lines. Could it be smaller if the changes in stable were added to unstable? [...] because I prefer to write such programs in Assembler. In a way, I want to change everything compared to DOS-C (The FreeDOS Kernel) which is written in a high-level language, and that's the reason I choose not to develop it. Tastes differ. One of the original goals with DOS-C was using more C :-) I know. and that's the reason I choose not to develop it. If you repeat answering that DOS-C tries to use C as much as possible I can repeat to write my answer again ;-) Still you are welcome to point out tech details of bugs if you find them, as we often have only vague it somehow does not work type bug reports and no time or hardware/software to reproduce/debug them. Of course ;-) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Indeed JAM only works on non-FAT32 kernels because of different data structures... Any other different structures besides the SFT? JAM apparently needs the start cluster of the compressed disk file so it can use lowlevel (int 25/26...?) calls to access that file without causing reentrancy while the kernel accesses files on the compressed disk :-). Ignoring the fact that it apparently broke SHARE.EXE, too Our version of share? Does it work less well on FAT32 aware kernels? Nope, here I talked about the MS-DOS SHARE.EXE only problems of MS-DOS 7.10+ only. That'll make jmount incompatible with MSDOS4, DRDOS 56, but compatible with newer versions, because the word at 35h is the last accessed cluster, and after reading one sector (as Eric showed) that will still be the starting cluster. patching JMOUNT [...] is not elegant, but that is a typical problem with closed source software :-p Anyone tried to contact the JAM developers before patching the binaries? Does JAM read anything from the archive file (I presume it wants the first cluster of that file) before looking into the SFT? It does the following: Drive reset, network flush buffers, check if drive is remote, check for DJ mechanism state, for dblspace, for JAM drive properties, truename, more JAM drive properties. Then it checks the DPB of the drive with the JAM compressed disk file on it, OPENs that. Then dosdebug/dosemu logged that a first disk sector read happens, not sure why. Next JMOUNT seeks to: current +0, end +0, start +0. Now JMOUNT reads the first sector of the compressed disk file. Then it checks the JFT and SFT to, indeed, get the start cluster of the compressed disk file :-). Does it parse the JFT and SFT chain directly or does it use DOS services such as 2F.1220 and 2F.1216 ? I am not sure whether DOS would already read the next cluster when you read the first (size of cluster) bytes of a file, I would guess it will not... It *could* read the value of the next cluster from the FAT (value inside the FAT entry of just-read cluster) but that could also result in an EOF marker so I guess you're right. FreeDOS already does exactly that - as soon as any int 21 call is done, the SFT is updated with information from the fnodes where necessary. Only if an outside software would WRITE to the SFT you could cause problems because this might get the SFT out of sync with the fnodes: FreeDOS might have information stored in the fnodes which the outside software which manipulated the SFT will fail to update if it does not know about fnodes. But is the fnode re-used for the next DOS call, or is it populated from all values found in the SFT again? Because, if the former is true, then the cluster reference would be lost as soon as another call used the fnode for another file. And if the fnode was repopulated from the SFT on each DOS call, then if whatever program changed the cluster references in the SFT would also change the fnode indirectly (if it accessed the SFT when the InDOS and CritErr word was zero). Maybe extremely lowlevel software such as task swappers or such unimaginable things as online defragmenting software ;-) could cause problems here, but JMOUNT should be safe :-). Ack. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Actually MSDOS 7.10 already uses the SFT in a different way, but undocumented by RBIL, for both FAT16 and FAT32: 0BhWORDcontains the high word of the relative cluster number at offset 19h 2BhDWORD contains the starting cluster number 35hDWORD contains the current cluster number Interesting. How this interacts with SHARE.EXE: I have no idea Probably the main reason it doesn't work with MS-DOS 7.10. This was just obtained by writing a program that dumps the SFT after opening a large file and reading 7*4k into it on a FAT32 partition with 4k clusters. Good work! I verified RBIL's statement that the word at 0Bh was not used by checking it for files located on a FAT12 and FAT32 drives. It contained a seemingly random value which lead me to the wrong assumption MS-DOS just didn't properly initialize it. However I don't think I'll copy this strange behaviour (at least not by default). As reported by Eric, it breaks programs like JAM (the point is, even on FAT12 and FAT16 disks) which look into the SFT to get the first cluster of a (FAT12 or FAT16) file. Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
Hi Eric, Pat: It won't help FreeDOS of course because it still uses fnodes for these things instead of SFTs. Those are ancient relics that should be done away with. There is no need for them anymore. I'd like to put that high on the priority list for kernel development. Just to remind you that your conclusion about Fnodes turns out to be wrong ;-) Eric (german): Andererseits hatte FreeDOS vermutlich Gründe, F-Nodes statt erweiterte-SFT zu implementieren. Und zwar nicht nur, weil DOS-C F-Nodes hatte, bevor es SFTs hatte ;-) (translation): OTOH FreeDOS probably had reasons to implement F-Nodes instead of extended-SFT. And not just because DOS-C used F-Nodes before it used SFTs ;-) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
It's all undocumented, of course :) You're distinguishing undocumented undocumented from documented undocumented... Nah, here I rather distinguished undocumented changes from MS-DOS 6 to 7 and the documented ones, which were like the config.txt user documentation describing some of the changes and giving away hints as to what changed technically ;-) (So, yes, you're probably right.) It just happens that nobody has updated RBIL. I'm not sure about unexpected because the 3.3x-4.0 change is similar, i.e. they could have left the 16bit sector counter for disks 32MB. About SHARE: http://support.microsoft.com/kb/161619 Microsoft here says: In order to support the FAT32 file system, Share.exe support has been disabled in the real-mode MS-DOS kernel regardless of whether or not you have any drives using the FAT32 file system. But what it actually means: We had to re-use some fields of an internal structure for FAT32 whose size we couldn't change, and breaking real-mode file sharing seemed like something we could get away with. It doesn't even work if you aren't using any FAT32 drive! nevertheless FreeDOS has its own share which doesn't use these SFT fields. Yes. Of course it needs further testing, but I tested that reading a whole cluster only sets the last accessed cluster to that cluster, not the one following it. You must actually read one byte more to get that field updated. Thanks. This is interesting information. Doesn't it update the SFT relative and absolute current cluster values, too? As far as I've understood it, fnodes should be invalidated when leaving DOS, so if these cluster references were saved in the fnode only, it wouldn't help a lot. It should update those but doesn't at the moment. If the fnode really goes away soon, the code could be easily changed to use the fields in the SFT instead I guess. (Or not required, see other mail from Eric!) Regards, Christian -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Hello again
The main bug/feature that I plan to work on is FAT+ support, the working with 4GB files goes along with this since it adds support for 4+GB files. Please keep this out of production kernels. I agree - modifying FAT to support files 4 GB is asking for trouble. Of course you can add it to the unstable branch so people can try it there nevertheless... Uhm, now that seemingly some people are working on the kernel again, it's good to proceed the forking? I agree that FAT+ support is controversial, but it doesn't have to be build into unstable only. This would just differentiate unstable more from stable again. I plan on implementing FAT+ as optional feature not included in the default kernel. Even a kernel compiled with FAT+ support could be configured (via *CONFIG.SYS or online configuration utility) to deactivate the ability for any or specific drives. EDR-DOS users might patch/hack/... their FAT32+ drives to contain a filesystem version of 0.1 if they want the DOS-C kernel with FAT+ support to recognize the drive immediately. Support for files between 2 and 4 GB size, on the other hand, is very well-defined, compatible and safe to add, I already have some notes about which knobs need fiddling for that :-). On the other hand, you've a point here. Why tie 4 GiB file size support to FAT+? You (all kernel developers, not necessarily Eric) could write that first, and then someone might proceed to add FAT+ support. this involves the risk of breaking stuff inside the kernel, and is not (and never will be) supported of any other operating system. If you ask me, it would be even better to have a MINIMAL (eg only readonly, only root directory) ISO9660 / EXT2 / NTFS / whatever driver in the kernel and load a separate full driver for that file system later. Well, that's almost what DOS-C currently does. The minimal driver here is the boot sector which loads the kernel file. The kernel then continues to access the same filesystem with its own FAT drivers, but it doesn't necessarily have to access the same drive/filesystem as the boot sector because the FreeDOS boot sector fortunately loads the full kernel file. EDR already supports this. who cares ? My personal opinion that some recent filesystem tweaks in EDR DOS are a big pain for lowlevel tools... For example EDR DOS might try to play nice for FAT16 apps and as a side effect lure FORMAT into making 8 GB almost-FAT16 filesystems when it tries to hide FAT32. Err, what? Please explain that better. Even if EDR FORMAT does create FAT16 filesystem with long (128 sector) or long long ;) (256 sector) clusters by default, where is the problem? Low-level tools should make sure that the sectors per cluster field of the BPB/DPB is valid. If they don't support large clusters they would detect values 128 and 0 as invalid then. If they don't check the field, that's not EDR-DOS's fault. Another example are EDR-specific extensions of the FAT32 BPB that make it necessary to modify DEVLOAD to work with EDR DOS etc ;-). First, there are no EDR-specific extensions to the BPB, you're talking about the DPB here. (The difference is important!) Second, 4 of 6 additional bytes are required for better FAT16 MS-DOS compatibility, and the EDR-DOS DPB will be fixed so that the LAYOUT will match that of FAT32 MS-DOS. Getting the correct DPB size is not as difficult, really, and should *not* be limited to hack for EDR-DOS only because other DOS versions might use larger DPBs too. (Should I add a few bytes beyond the normal DPB just for the argument? Nah.. Notice however that previous RxDOS versions additionally stored the volume ID in the DPB for good reason.) And since you mention only EDR-DOS's tweaks requiring a better DEVLOAD, shouldn't I add that DEVLOAD already contains handling for some DR-DOS oddities and therefore contains proper DR-DOS detection code anyway? (This code however isn't used to detect EDR-DOS in DEVLOAD, *that* code completely relies on unreliable (via CONFIG.SYS settable) MS-DOS version values.) I'll answer to the initial reply and to Eric's other mail here, too: I THINK you could make some components compile time omitable but I also think that support only OW is a risky idea as you will still need drivers and drivers typically are what forces you to include and keep all sorts of compatible cruft. Well, if he meant only the kernel then that's probably no problem. At least I didn't see any driver plug-ins delivered as source for DOS-C recently. Anyway, my future work on the dev branch is now done as a separate project (I call it the DOS-C kernel as opposed to the kernel discussed on this list, the FreeDOS kernel). Uhm, don't you want to search a new name? ;-) I still* like calling the kernel DOS-C, since FreeDOS kernel sounds like it was designed to be just this. And calling it the kernel sounds like there are no other DOS kernels (commercial or
Re: [Freedos-kernel] Kernel build 2038rc1 testing
PS: Attempting to use SUBST to create a drive letter backed by a directory in a dosemu magic drive creates a drive which does not contain any files. I did not check why. I assume DOSEMU's magic drives use the Int2F redirector interface to provide their filesystem to the emulated DOS. SUBST usually doesn't work with redirectors, but our SWSUBST probably doesn't check this condition so you get strange results. Regards, Christian -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] PATCH: sys fix
- Christian: entry.asm revamp to fix the CP/M call (review!) http://sf.net/tracker/?func=3Ddetailaid=3D2421577group_id=3D5109atid= =3D105109 anyone know of any CP/M like programs or applications to test these with? There's some C library based on the CALL 5 but I never used it. My test case was setting up the correct registers (function in cl instead of ah, only functions 00h..24h valid) then using a call 5 in DEBUG. (Be sure to use FreeDOS's DEBUG because MS-DOS's apparently corrupts the CALL 5 handler inside the PSP.) Here's an example DEBUG script: === CUT HERE === a mov ax, sp mov cl, 2 mov dl, 21 call 5 int 3 nop g q === CUT HERE === If the handler works, it will display an exclamation mark (Int21.02, display character) in front of the first line of DEBUG's register output. DEBUG should show the disassembled NOP or (depending on the version, maybe) the INT 03 on the next line. Make sure the displayed ax register equals sp, which it should do if the handler returns the stack correctly. If the handler doesn't work it might crash the system or do something random. Regards, Christian -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
Examples: - handling of floppy before disk is inserted / unformatted partitions - initdisk CHS geometry fix and BSS init fix from RayeR - int 21.1c non-FAT / non-existing drive handling fix from Tom If anyone wants to contribute to discussions about this patches he can do now. seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. Uhm you do not exactly motivate me I'm currently trying to. The mentioned patches are: None of those patches is necessary for the 2038 kernel Yes, if you want to add some Known bugs sections to the documentation instead. but on the other hand some of them are definitely useful, yes :-). - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't work. There's a patch for this in inthndlr.c but it's wrong and leads to crashes. The patch in inthndlr.c (below case 0x4c of the main Int21 handler) has to be removed, and the condition of a self-owning PSP has to be handled like a TSR termination in the return_user function in task.c. 2037 is affected by this, too. Afair, self-owning PSPs happen in shells and in DEBUG etc, but I do not remember having problems with leaving DEBUG. DEBUG (at least FD DEBUG and derived versions) avoids accidental termination by any means. The only real possibility is that somehow a critical error occured when DEBUG's PSP was active, and the default answer of Fail returned by DEBUG was turned into Abort because Fail wasn't allowed on this particular error code. This is very unlikely, in fact I don't even know any error code that doesn't allow the Fail response. So, DEBUG's patched PSP is mostly just a backup if something goes wrong but will usually never be used. Leaving the main SHELL is not a good idea anyway. But works well in other DOS versions. Plus the origins of your inthndlr.c / task.c patch are a bit fishy copyright-wise. Just like UDOS and the documentation of DOS-internal data in RBIL are. You know, you might just ignore my patch and add that as a known bug. - CALL 5 interface is broken, and probably crashes the system. Note that only CP/M programs use this, software from the seventies. Yes, and DOS is mainly software from the eighties and nineties ;-) The Assembly code in entry.asm that handles such calls is screwed up. I can provide working replacement code or patch it to work how it's supposed to. 2037 is affected by this, too. The patch was long ago and I remember the discussion about it was aborted too early. It should have been on the list, too. I believe it was a do what I say or forget it request ;-). Might have been too rude there, or haven't explained it enough. As mentioned in my previous mail, I could patch the existing code instead. - The seek position (and various other fields) of the SFT isn't declared as unsigned. Eric reported that the seek function reports errors using negative return values. This has to be changed so that it can work with files up to 4 GiB. Depending on when the seek function is called (whether it's already determined that the handle references a valid SFT, and that the origin in al is valid) you might just remove any error reporting of it, since the actual seek operation never returns errors in MS-DOS (as mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, at least the case 0x42 in inthndlr.c should work with larger seek positions. I agree that supporting files above 2 GB size is high on the wishlist and reasonably easy to implement. Will work on it :-) Thanks! I've CCed the Freedos-kernel list, too. Okay, so I guess I have to CC both lists, too :-) Since we're getting more into the tech stuff now, I think I can reasonably mail this reply to the kernel list only. Regards, Christian -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] [Freedos-user] was: Windows 3.1 - Pending kernel patches 2037/2038
Simple: If you only use WIN /S then you can use the stable 2036 or stable 2038 kernel. The latter is on http://rugxulo.googlepages.com/ as binary snapshot. There are a few pending improvements before 2038 can be put on sourceforge file releases... The sources already are on sourceforge in our svn, of course :-) If there's a stable 2038, then that should get put on ibiblio for general release as soon as possible. If it's on rugxulo's pages, then very few people will know about it (heck, *I* didn't know about it - see my other email.) If you're waiting for further improvements to 2038 before you release 2038, then you're doing this wrong. [...] I'd strongly recommend making 2038 available, and putting the few pending improvements in 2039. The problem is that Eric holds back at least three necessary patches, of which two are already provided in source form. He doesn't exactly have to wait for these, we've completely described them. (The first one on the list, others in the FreeDOS bugtracker or old private e-mails.) Since it seems Eric doesn't exactly want to be the kernel maintainer, you need someone else for that. The mentioned patches are: - Terminating self-owning PSPs (parent PSP field set to the PSP) doesn't work. There's a patch for this in inthndlr.c but it's wrong and leads to crashes. The patch in inthndlr.c (below case 0x4c of the main Int21 handler) has to be removed, and the condition of a self-owning PSP has to be handled like a TSR termination in the return_user function in task.c. 2037 is affected by this, too. - CALL 5 interface is broken, and probably crashes the system. The Assembly code in entry.asm that handles such calls is screwed up. I can provide working replacement code or patch it to work how it's supposed to. 2037 is affected by this, too. - The seek position (and various other fields) of the SFT isn't declared as unsigned. Eric reported that the seek function reports errors using negative return values. This has to be changed so that it can work with files up to 4 GiB. Depending on when the seek function is called (whether it's already determined that the handle references a valid SFT, and that the origin in al is valid) you might just remove any error reporting of it, since the actual seek operation never returns errors in MS-DOS (as mentioned in RBIL and UDOS too). 2037 seems not to be affected by this, at least the case 0x42 in inthndlr.c should work with larger seek positions. I've CCed the Freedos-kernel list, too. Regards, Christian -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
