On Sat, 17 Jul 2004, Arkady V.Belousov wrote:
Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty
enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks
like Steffen fixes (at least, one) bug, related to environment, but up to
now I don't know where to
Hi!
19--2004 01:23 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
Hi, I think it is now clear that Turbo C 2 cannot optimize for 386.
HOWEVER, the NASM parts can still be optimized for 386.
... but then save a few byte by using a different longDIVMODMUL
implementation doesn't
Hi!
19--2004 01:23 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
[...]
EA The DosGetFree function (remember my bug report...) calls
EA flush_buffers if called from FatGetDrvData (int 21.1c?), maybe this is
EA where it crashed? Otherwise it also is int 21.36 ...
EA Plus, how do we
Hi!
19--2004 08:29 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to [EMAIL PROTECTED]
[EMAIL PROTECTED]:
Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty
enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks
On Mon, 19 Jul 2004, Arkady V.Belousov wrote:
Hello,
Unfortunately, FreeCOM (included into 2035 package) wrongly handles empty
enviornment (easy to reproduce in MS-DOS, as I report this in group). Looks
^^
like Steffen fixes (at
steffen)
put MSDOS + current distributed FreeCOM on floppy.
boot, and say F5 (skip everything)
and you'll have a load complaining FreeCOM,
although it definitively gets it's startup path.
Arkady)
it's a plain dull idiotic mathematicians braindead idea
to 'improve' freedos kernel, but break
Hi Eric,
please be aware that some structs (such as fnodes) are free-style, but
most are dictated by RBIL. It's best to use CLUSTER in internal parameters
and fields etc. because this is either 16 or 32 bits. Just like those
freedos specific open flags they are completely kernel-internal and
On Tue, 20 Jul 2004, Bart Oldeman wrote:
I'm still not sure if and when I really return, the archives aren't really
encouraging... In any case, I appreciate that a bug was found in
ludivmul.inc; the same bug was in fact present in the 64 bit version I
adapted it from! Well I notified the
Eric,
please please, if you discover that you made a mistake in a post then
please edit the post while you still can. IMHO It's very annoying to read:
Hmmm this must be the case.
Oh no, sorry, what I said above was wrong, it is like this.
This makes your already long post even longer
Bart Oldeman schreef:
I'm sorry but I simply don't have the time to go through all the other
patches. If they were reduced to just bug fixes I'll promise that I'll
have another look though -- I still monitor the mailing list every now and
then. Guys *any* project that wants to be close to a 1.0
Hi Bart,
In any case, I appreciate that a bug was found in ludivmul.inc
so do I
What I don't like is that the fix from Arkady (for the 1000th time...)
does 3 things at the same time -- formatting, fixing, and optimizing.
neither do I like that.
This makes it impossible to see where things
At 12:55 AM 7/20/2004 +1200, Bart Oldeman wrote:
I'm sorry but I simply don't have the time to go through all the other
patches. If they were reduced to just bug fixes I'll promise that I'll
have another look though -- I still monitor the mailing list every now and
then. Guys *any* project that
There recently has been discussion of the kernel,
of the upcoming FreeDOS 1.0 release, and of changes
which should or should not be accepted.
As acting kernel maintainer, this is how I am trying
to ensure stability while making progress and trying
not to 'upset the talent' as it were.
As I said in
Hi!
20--2004 01:09 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
Glad to hear you, Bart. Have some questions to you.
BO please be aware that some structs (such as fnodes) are free-style, but
BO most are dictated by RBIL.
You develop the fnode structures, so should know
Hi!
19--2004 21:56 Arkady V.Belousov wrote to
[EMAIL PROTECTED]:
SK the PATH=. variable?
AVB MS-DOS (neither kernel, nor MS-command.com) NEVER INCLUDES SUCH
AVB VARIABLE INTO ENVIRONMENT (empty or not). If in config.sys not present menu
AVB or some SETs, then for INSTALL= MS-DOS passes
Arkady V.Belousov wrote:
Hello,
19--2004 13:59 [EMAIL PROTECTED] (Steffen Kaiser) wrote
to [EMAIL PROTECTED]
[EMAIL PROTECTED]:
You mean Arkady called MS-DOS-style empty environment broken? Yes, I
call this. But this is MS-DOS and all its bugs become standard and called
SK So, you've fixed the
Arkady V.Belousov schreef:
Hi!
19--2004 16:08 [EMAIL PROTECTED] (Bernd Blaauw) wrote to
[EMAIL PROTECTED]:
BB to work out his changes. At a given moment, he should probably issue a
BB code-freeze and then make stuff more readable/review-able
May you point, what in my code isn't readable (or,
Hi!
19--2004 21:14 [EMAIL PROTECTED] (FreeCOM) wrote to
[EMAIL PROTECTED]:
SK What does the kernel do now, when the originally correct empty
SK environment layout arrives there?
Originally correct - with one empty ASCIIZ string? Currently prepared
MS-DOS-style empty environment. (DO WE
My dear Mr. Belousov,
_I_ _report_ bug in FreeCOM. If now FreeDOS is closer to MS-DOS and
FreeCOM now incorrectly works in both under MS-DOS and FreeDOS (with empty
environment), who wrong?
do you really think a new kernel that breaks all installed FreeCOM's
in the wild is an improvement
Hi!
19--2004 22:11 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov
[EMAIL PROTECTED]:
te do you really think a new kernel that breaks all installed FreeCOM's
te in the wild is an improvement ?
Workaround for current bug in FreeCOM is easy, this is question of two
lines in main.c
Hi all, Arkady:
PLEASE do make FreeDOS 2035a behave as wrong as 2035, because
people will want to compare 2035a to 2035, and if things happen like
- you cannot format unformatted drives (disk access flag broken)
- stable version of FreeCOM (0.82pl3, as opposed to 0.82pl3xyz testing)
crashes
Hi!
19--2004 10:31 [EMAIL PROTECTED] (Michael Devore) wrote to
[EMAIL PROTECTED]:
MD I am glad someone said this that nicely. I have been stunned that the vast
MD number of relative last-minute pre-1.0 kernel changes
I begun to (more deeply) work on kernel only when Bart quits his
BB replace readable by understandable for inexperienced C programmers
Unimportant.
here I have to agree - kernel programming is nothing for inexperienced
programmers, and will never be.
Note: this is myth.
well - my private email archives show that 'arkadifying code' is used as
Hello Eric,
I am sure 2035a fixes several bugs of 2035
found the ret_ah bug. if that has real world implications is unknown.
found the Ulong 32%32 bug - impressive, but 100% irrelevant to the
kernel as all real world use will work 100% ok.
claims to have found a bug in umb_link code for a001:
Hi!
19--2004 22:42 [EMAIL PROTECTED] (tom ehlert) wrote to Arkady V.Belousov
[EMAIL PROTECTED]:
BB replace readable by understandable for inexperienced C programmers
Unimportant.
te here I have to agree - kernel programming is nothing for inexperienced
te programmers, and will never be.
25 matches
Mail list logo
