Hi Jeremy,
Kernel 2038 tagged and available at http://www.fdos.org/kernel/latest/
Someone with access, please upload to ibiblio and release on SF.
Please update history.txt - it represents the state of 13 months ago...
While you are at it, could you update my email to mceric at
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 Christian,
I think that you are not being polite.
You are new here and you start by wanting to change everything. Why
don't you start by fixing a few bugs?
Alain
Christian Masloch escreveu:
Which app crashes from running on a FAT+ kernel? (Presuming you don't
even
have that large
Hi all,
I use regularly FreeDOS in users instalations with brand new, superfast
motherboards. The aplication is heavy Database usage and FreeDOS is
prerforming better then MS-DOS...
There is a systematic problem only with ASUS motherboards (in the last 3
years aprox.) System crashes, files
Alain M. schreef:
I use regularly FreeDOS in users instalations with brand new, superfast
motherboards. The aplication is heavy Database usage and FreeDOS is
prerforming better then MS-DOS...
Great. Is switching kernel the only thing that's relevant or did you
switch any other components
2009/5/18 Christian Masloch c...@bttr-software.de:
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
Hello all,
1. I have checked out the latest build (kernel 2038-32). It works fine
with GEM/XM. (So did the 2nd RC.)
2. Congratulations on a great kernel/OS
3. PLEASE stop the flame wars--the last few digests have looked rather (?!)
4. I would rather see more of the features from 2037 in stable
Eric Auer wrote:
Once 2038 is released I plan to continue reviewing any outstanding
patches and apply as appropriate. My top priority is bug fixes -
repeatable bugs will probably be fixed first :-) In no particular
True. One bug: MSCLIENT, but only in BASIC (without REDIR loaded)
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.
in theory you are right. in
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
2009/5/18 Tom Ehlert t...@drivesnapshot.de:
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
Hi Bart,
[fnodes] 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.
in theory you are right. in praxis fnodes are everywhere throughout
the file system (as you probably know), and
On Mon, May 18, 2009 at 3:49 PM, Tom Ehlert t...@drivesnapshot.de wrote:
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
2009/5/18 Christian Masloch c...@bttr-software.de:
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
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
Hi Christian,
I don't want to change everything. The only extension I asked
for was to support FAT+, of course in the stable (or trunk) kernel
branch because unstable isn't developed by anyone currently and
developing it would proceed the forking of these branches.
Still no reason to
Eric Auer schreef:
Still no reason to add experimental things to stable now :-)
The solution is easy: Add it to the UNSTABLE fork and, while
doing so, show that there are people who are interested in
new experiments with DOS! This will also draw more attention
to this branch and make it more
If half as much effort went into the code that has gone into this
thread, we'd have rewritten the kernel several times over.
Since I'm wrong about the kernel(?), let me put it to you this way. I
want to put out a new release, FreeDOS v1.1 and get a plan in place.
In 50 words or less, who is
Hi Pat,
I would say 2038 as default, 2037 (including winkrnl) as option--unless
2039 shows up first (doesn't look likely). If 2039 gets something
worthwhile, 1.11 is an option.
Thank you,
ibidem
--
Crystal Reports -
On Mon, May 18, 2009 at 6:32 PM, Pat Villani p...@monmouth.com wrote:
If half as much effort went into the code that has gone into this
thread, we'd have rewritten the kernel several times over.
Since I'm wrong about the kernel(?), let me put it to you this way. I
wrong?
want to put out a
This sounds liuke a good strategy.
Pat
On Mon, May 18, 2009 at 8:07 PM, ibid...@lavabit.com wrote:
Hi Pat,
I would say 2038 as default, 2037 (including winkrnl) as option--unless
2039 shows up first (doesn't look likely). If 2039 gets something
worthwhile, 1.11 is an option.
Thank you,
21 matches
Mail list logo
