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
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
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
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
;
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
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
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
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
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
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
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
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
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?
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
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
- 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
- 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?
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
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
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
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
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
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
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
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
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
- 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
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
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
29 matches
Mail list logo
