Hello,
2009/6/14 Eric Auer e.a...@jpberlin.de:
Hi Aitor,
I support this idea, but that means that odd numbers (2039) would go
unstable.
Actually Bart already ported country sys support from unstable,
combining it with built-in country support. He is also working
on f-node free
Hi Aitor,
I support this idea, but that means that odd numbers (2039) would go unstable.
Actually Bart already ported country sys support from unstable,
combining it with built-in country support. He is also working
on f-node free operations in stable. This means that version
2039 will be the
I support this idea, but that means that odd numbers (2039) would go unstable.
I guess that on view on this FD 1.1 should have 2038 ( or 2040 if
there's such thing by the release time).
Aitor
2009/5/18 Bernd Blaauw bbla...@home.nl:
Eric Auer schreef:
Still no reason to add experimental things
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 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
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
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
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
2009/5/17 Bart Oldeman bartolde...@users.sourceforge.net:
0Bh WORD contains the high word of the relative cluster number
at offset 19h
2Bh DWORD contains the current cluster number
35h DWORD contains the starting cluster number
sorry, the last two are the other way around:
2Bh
2009/5/17 Christian Masloch c...@bttr-software.de:
Just in case you're talking about the extended SFT: I'll use a
FAT32-extended SFT (probably compatible to EDR-DOS's extensions for FAT32)
even without FAT+. Somewhere *at least the beginning cluster* of the file
has to be stored, and the
Eric Auer schreef:
Maybe we should have DVD playing software and a DVD-
compatible version of DOSCDROAST first... :-p. And
I repeat my earlier argument: Just split the bluray
image into a few files, very easy :-).
What's DOSCDROAST exactly?
So far I'm quite happy with Blair's port of
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
OK, let me chime in on this. Jim and I had several conversations on
topics like this before I took over. I want to share the current
thinking.
We, as a group, have made a significant impact on the open source
community and computing in general. This is something we need to keep
in mind as we
Hi Christian,
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
Hi Jeremy,
You misunderstand me :-) Of course we should support files of 2-4 GB
size in the STABLE kernel very soon! Just do not support ABOVE 4 GB
There are no longer multiple active branches, there is only trunk.
Trunk is stable, but there also is devel / unstable:
Nope, I'm not doing anything other than trying to gather enough
information with respect to project status to try to come up with a
road map and possibly plan release 1.1.
I have made *NO* decisions.
Pat
On Thu, May 14, 2009 at 4:26 PM, Eric Auer e.a...@jpberlin.de wrote:
Hi Jeremy,
***
Hi Tom, Jeremy,
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
29 matches
Mail list logo
