Re: [Freedos-devel] FreeDOS need clean up!

[Eric A. <er...@co...>]

Hi Johnson,

> >Our kernel is only ca 40 kilobytes on disk, which is quite small.
> I don't believe it's already optimized to zero excess code

I know, some people would say "hey we can make it 39 kilobyte and
gain 1 kilobyte of free HMA space". But only very few apps use the
HMA, so I generally assume that the HMA is only useful for kernel,
BUFFERS and UIDE anyway :-).



> should be some way to improve, the previous slow accessing problem
> still not yet solved, I don't know if any specific memory problem or
> others, but keep the code clean always correct.

True. We should add an array of "next free cluster on drive X:"
integers, that would make creation (and growing) of files and
directories a lot faster, in particular on FAT32 drives and on
drives where many clusters are already in use. Such an array
would make searching for a free cluster a lot faster. Each entry
would be set to 0 after you boot and when you free a cluster
(for simplicitly, at least in an initial version) and would be
set to the location where the search stopped AFTER each time
when you call "allocate a cluster". Then the search can start
at that point when you call "allocate a cluster" again :-).



>>Compatibility issues seem to be limited to Windows 32 bit mode
>>I miss other popular apps? :-)

> When come to DOS extender or some DOS extender program, FreeDOS
> usually not work (e.g. Han Chinese System)

Are you sure that this is a DOS extender problem? Sounds more
like missing double byte character support (DBCS). Can the Han
software be downloaded somewhere?


> This is for developers only, and how to judge what is "stable"?

Which number should we use for the unstable / devel kernel? As
Tom said, it is sort of un-useable because it contains many
complicated changes and almost nobody did proof-reading for
them :-(. The stable kernel "is stable because it is based on
the previous stable kernel", and because it only contains such
changes which are small / simple / well tested and preferrably
fix bugs instead of adding new features.

> When a new kernel will release?

I think we should release 2038 soon, see my other mail yesterday.
Maybe we can even add the cluster allocation speed fix there?

> To the users, "2037a" or "2037 beta" is confusing enough, please
> keep to 1.0, 1.1,  minor fix should be 1.1a ... etc.

I agree that using letters or words can be confusing. But using
numbers like 2038 is okay. The internal number is just 38, by
the way :-).



> >Well if you REALLY want the scene to wake up, then I think it is
> >VERY important to have a new release of the whole distro. In other
> New release of 1.0 is disaster, maybe I'm a bit exaggerated...
> Didn't you see how FreeDOS 1.0 react? Many people complain the ISO
> have problem, or the installed DOS not working properly.

I meant 1.1, not a new variant of 1.0... Can you check our Wiki at

http://fd-doc.sourceforge.net/wiki/index.php?n=FdDocEn.FdInstall

to see if all known errors are already listed in the Wiki and in
Bugzilla? The latter is at

http://www.freedos.org/bugzilla/cgi-bin/query.cgi



> The FreeDOS 1.0 ISO is not small bug, people did have bad image about
> the whole project, saw a few people asking questions here several
> months ago, and no one can help them to solve, they're so helpless

Can you give examples of those problems? Is 1.0 worse than beta9
in your opinion?

> I'm want but not able to help, coding not my talent.

This is no problem - we also need a lot of help with non-coding:
Testing bugs in bugzilla (to find out if they still affect the
version that will be used for 1.1), putting packages in zips for
the 1.1 distro, and reading the SVN changelog to make a short
summary which can be put in our kernel changelog text file:

freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/kernel/?view=log

Everybody who wants to help with any of the mentioned non-coding
things is welcome, thanks :-).



> I've tried but seems you guys not very impressed about the
> "simplicity", also you have to solve duplicate software,
> make a clean "whatsnew.txt".

Please explain. Which duplicate software?

> I saw Tom's comment about the percentage thing, my advise:
> Marketing is important, no matter how good your product is

True! I am trying to convince somebody in HK to include 1.0
or the Rugxulo 1.1-ish distro instead of beta9. Because if
he includes beta9 (with his product) then that will be bad
for our "marketing". His customers will see an outdated DOS
and will get a bad impression of FreeDOS.

> Good but not simple enough, don't underestimate the human stupidity
> > wiki.fdos.org/Main/Todo_1_0
> Not simple enough, Tom was right about the stupid percentage,
> but people love these kind of presentation

I see. We need a marketing guy who can suggest "understandable
for dummies" descriptions of FreeDOS :-). As we are talking
about the percentage idea, which categories do you have in
mind and which percentage do you think we already reached?



> >wiki.fdos.org/Main/Post_1_0_Todo
> 1) DBLSPACE, FASTOPEN, MEMMAKER outdated, should be removed

Not really. In theory, it always makes sense to have MEMMAKER,
even though many drivers for DOS (like UIDE) already use very
little memory anyway, so it is hard to accidentally have a
bad UMB configuration today :-). Using compressed filesystems
can be useful for embedded systems with flash disk. I think
you can use the SHSU ramdisk which can load compressed disk
images - but only if you have enough RAM and if you do not
need to write to the disk. Otherwise, you need something which
is a bit more similar to DBLSPACE. Last but not least...:

FASTOPEN - Microsoft stopped to use FASTOPEN because they do
believe that you do not need it if you have a disk cache.
But remember that the "FreeDOS has slow cluster allocation"
problem described above cannot be solved with a disk cache.
Basically FASTOPEN remembers the on-disk location of a few
recent directory entries so it can find them again faster.

> 2) Include the standard memory manager, and provide information
> for others available

Please explain. De-facto standard is JEMM386 / HIMEMX now.

> 3) MSAV is Anti-virus, too bad ClamAV have no DOS port, and
> F-PROT for DOS have no more update

Actually a DOS port of ClamAV ClamScan does exist. But nobody
had time to update it in the last year...



> > freedos.svn.sourceforge.net/viewvc/freedos/kernel/trunk/docs/intfns.txt?view=markup
> Once a project got too big, it should have duplicate code or some
> quick and dirty code written, but not cleaning these up just can't
> keep development going on.

Please explain. The intfns.txt list describes which functions
are required for MS DOS compatibility. I agree that it is dirty
and bloated in some aspects, but we cannot make it simpler.

> I found that FreeDOS is "quite good" in some situation, that's
> why I don't want to see it slowdown and stopped completely.

Thanks :-)

Eric