>> 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 s
> 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.
>>
mov ah,cl ; get the call # from cl to ah
-jmp reloc_call_int21_handler ; do the system call
-cpm_error: mov al,0
-iret
+
+; The following code is from RxDOS version 7.20N.
+; (C) Copyright 2008 Christian Masloch. Licensed under th
>> - Christian: entry.asm revamp to fix the CP/M call (review!)
>> http://sf.net/tracker/?func=3Ddetail&aid=3D2421577&group_id=3D5109&atid=
> =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 t
> 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.
Hi,
I just looked at the recent SVN commits to fix that CALL 5 stuff. The new
commentary about it contains some errors. I'm appending the things I would
improve about it. It's not meant to annoy you, although I imagine it
could. (Does it?)
Regards,
Christian
---
This comment was put into t
>>> 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
>> 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.
>
> Sorry but it IS
>> Which app crashes from running on a FAT+ kernel? (Presuming you don't
>> even
>> have that large files, or that the app doesn't access these files.)
>> Excluding low-level disk utilities such as defragmenting or disk
>> checking
>> programs of course, because EVERY new or extended filesystem
> 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 clu
Hi Alain,
> I think that you are not being polite.
Yes. Yes, I reflected on this and I think you're right. Sorry. I just
don't like how people reply sometimes. I'll try to calm down there.
> You are new here
I've been in contact with Eric and some other people since more than a
year. I woul
>> 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.
>
> Whether you call it stra
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 re
> 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 c
> 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 reentran
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
>> Has anyone investigated the changes affecting Christian's patch?
>
> It helps with escape/break:
> http://au.geocities.com/short_stop_pacific/freesoft/system.htm#escbrk
> So if you press F12 in the primary command.com it won't hang.
It also helps with DEBUG (and probably other programs) that ca
> 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
>> 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
>> - 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 In
- 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
>> specifie
> 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 do
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
> 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
> 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
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
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 d
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 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
> 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.
RxDOS isn't finished
Am 21.10.2009, 03:47 Uhr, schrieb dos386 :
>> 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
> 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
> fo
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
> ;
> 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,
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
This cross-posted from Freedos-user.
> [...] The kernel does not correctly
> allocate MCBs for its configuration and initialization program code. The
> code that an application loaded by INSTALL= returns to via termination
> (pointed to by Int22) is in free memory.
>
> [...]
>
> The interrupt 22h
Hi,
this to the kernel developers. Affected is at least dos_open when creating
files (and possibly directories?). dir_write_update is used, which will
flush all buffers for the affected file system (after creating and
modifying a buffer for the affected directory entry) but not check whether
> 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
> however generating AGAIN an unstable kernel 2041 is a real bad idea.
>
> and tagging current state (after the questionable 1705) '2041' without
> further discussion is shit.
Note that the 1702 changes were effectively reversed by 1704.
The 1705 changes are unrelated.
--
40 matches
Mail list logo
