>> Besides, I'm too egoistic to write or re-write major parts
>> of something when this new version isn't accepted because it
>> isn't tested enough. That was the case with the "unstable"
>> DOS-C version 2037

> this entire bullshit.
> 2037 has been tested, and the results say 'unstable'


> 2037 had some very welcome enhancements (country.sys support
> comes to my mind, but there may be more).

Good question - what else should be ported to stable first?

> unfortunately 2037 has also a zillion of Arkady's 'optimizations'.
> at least one of them made the kernel unstable.

I started making a big "technical" list of what changed in
which SVN revision and did indeed find a very broad mix of
patch types: The country.sys support, if possible to combine
with the 2036 hardcodes number/date/time format defaults for
those who have no space for country.sys files, would be one
of the most useful things to port back into the stable kernel.

On the other hand, some other "unstable" kernel patches are
clearly very experimental. Some throw in lots of debugging,
others are "let me try X in a completely different way", yet
others are indeed Arkady style peephole optimizations which
can sacrifice readability (and maybe stability) for a few more
bytes of reduced kernel size. However, most patches are not
officially by Arkady but by Jeremy, who had support from Lucho.

One problem is that Jeremy commited in waves where much code
changed in short time and no other kernel developers had the
time / wanted to review so heavy changes in such short time.

I think I should post my half-done (60 of 120 commits :-))
"list of commits between 2035 stable and 2037 unstable" to
one (but which?) of the mailing lists so we can discuss it:

Find those patches that are easy and worth to port to 2038,
those that are hard to port but very useful, those which seem
to be debugging or experimental and might be worth reverting
to make 2037 more stable/readable/useable/maintainable and
those which scare the XYZ out of the reader and should be
reviewed or reverted to get back some confidence for 2037.

In addition, discussing on the list might motivate some of
the readers to contribute the 2nd half of the list :-)).

> not unstable as in 'linux kernel with an odd number', but
> unstable as in 'do not use for production. will sometimes
> surprise you'

Not good.

> in that case, Jeremy is to blame, as he merged Arkadys
> optimizations, but never took the time to backtrace
> them to a to be tested, but stable 2037.

Interesting. That would also explain why the commit log
sometimes has very short / vague explanations of what
exactly changed in which SVN update...

> feel free to re-add country.sys support to 2038

See above :-)

>> (which had many features version 2036 and the upcoming
>> 2038 don't have).

> yes, sadly.

When excluding backports from 2038 to 2037, I remember
only a few... Country sys support and experimental but
sometimes working WfW311 / Win3.1 386enh compatibility,
something with Ctrl-Z, nicer initdisk partition display
and some alternative ways to handle absence of floppy
drives and disk changes in general.

Also related: SHARE tuning, new SYS features (make boot
sectors for OTHER operating systems... strange idea ;-))

I probably missed several goodies because as said my
list-of-changes only covers half of the SVN writes yet.

Commits where "too much" changed in one big blob are:
1147 Win3 related, 1023 nlsfunc country sys related,
1009 various tuning, 998 the big "initial unstable
branch from Lucho and Arkady" (7/2004) which throws
large amounts of changes into more than 20 files :-!

I probably missed several of the too big ones, too ;-)


Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
Freedos-user mailing list

Reply via email to