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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
