Hi all... great, I like TODO list changes :-). > http://fdos.org/ripcord/fdos_1_0/official/todos.htm
EMM386 RAM= is well enough implemented if you make it an alias to X= if you ask me. ROM= on the other hand would be not too hard to do (Michael already shadows ROM to trap ffff:0 reboots). But ROM= does not help much, because all newer computers (even an 1990 NeAT 386 mainboard) have a BIOS setup option to shadow ROM into RAM. So no need to let EMM386 do that. So ROM= can be post 1.0 if you ask me. HIMEM HMAMIN / INT15 / A20CONTROL are probably not too hard to do, so why not. HIMEM TESTMEM should only do a quick and simple check, e.g. write the address of the dword itself to every 256th dword (1 dword / kbyte) and read it back. Only to check if memory actually exists at that place and is not just a mis- detection due to BIOS memory size misreport or something. > http://fdos.org/ripcord/fdos_1_0/official/post.htm LBACACHE /L "load to low memory" is pointless - LBACACHE has no self-loadhi anyway. Either you load it low (prompt / DEVICE) or high (loadhi / devicehigh). No command line option for that. LBACACHE /E "element size selection" will only happen if it makes sense! To test, please compare cache hit percentage of 22oct2003 LBAcache to 1?apr2004 LBAcache (4k <-> 8k element size). If 8k performs actually worse (in particular with small caches) then there would be a reason to allow the user to select less than 8k element size at all (smaller elements mean more DOS RAM used!). LBACACHE /B "read ahead size": Read-ahead is done with TICKLE hidden HD / LB options, but I need feedback / testers to tune them. LBACACHE CD-ROM caching is already there in CDRCACHE. If you mean CD-ROM caching which is actually part of LBACACHE and shares the same XMS handle, please mention that explicitly. Missing tools: FASTOPEN / DRIVER / DRIVPARM: I vote that those should be kernel functionality eventually, not separate programs. DOSSHELL: Because we need yet one more GUI or because it offers limited task switching / multitasking? INTERLNK/INTERSRV: Tyler (freedos123) found some serial-port-drive-letter tool a while ago, but nobody told whether it worked in FreeDOS...? Of course an open source serial port drive letter would be even better. DBLSPACE: I would be interested in a readonly compressed filesystem where every cluster is compressed separately and where you have a table of byte offsets stored somewhere in order to access clusters fast. CVT: Conversion to FAT32 would be nice, but for now we still even have troubles to FORMAT to FAT32 well enough (not clear why, but Win9x accesses the root dir at the wrong place after FORMAT...). MEMMAKER/CHKSTATE: Well, yes, why not. If UMBs are fragmented... MSAV: Joergen Ibsen ported ClamAV.net CLAMSCAN to DOS :-) VSAFE: I would be interested in such a project, yes. SELECT: Our installer scripts are even more complex than that already. By the way - pre 1.0 - as far as I understand Aitor, Euro compliancy is already okay. I think only a few disk tools still TRASH LFNs, but which? Test results? SHSUCDX-read-ahead (with buffers option) would be interesting, I think! PRINT/PRINTQ might need a new impulse. SCANDISK needs helpers to come into live. BACKUP / RESTORE can be post-1.0 if you ask me. DEFRAG needs daring testers. ATAPICDD needs DMA help (Jeremy has very little free time). Todo list should mention who plans to do what (e.g. Aitor: GRAFTABL, APPEND) or is already working on it, to avoid 2 people working at the same thing without knowing about each other. Are FreeCOM REN wildcards actually still missing? When will DIR be able to show > 2 GB free? ... Eric ------------------------------------------------------- This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek For a limited time only, get FREE Ground shipping on all orders of $35 or more. Hurry up and shop folks, this offer expires April 30th! http://www.thinkgeek.com/freeshipping/?cpg=12297 _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
