(Arkady, I know that you also posted to this thread, but the shit of programs that I used to remove spam trashed your message, could you please re-send to me that in private? I like keeping those messages as mails than acceeding them from web; anyone kind out there can also resend, thanks)
Eric Auer escribió:
EMM386 RAM= is well enough implemented if you make it an alias to X= ifWRONG. Please, recheck old posts by Arkady and myself.
you ask me.
ROM= on the other hand would be not too hard to do (MichaelGood. It will be moved, as said to 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.So are you suggesting to keep them as pre- or post-?
<snip explanations, this is about if to keep them or not, not about explanations>
So I'll rename this feature to "Add self-loadhi". ?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 CD-ROM caching is already there in CDRCACHE. If you mean CD-ROMI'll add a note.
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 beDRIVPARM is a CONFIG.SYS option, not a utility. Anyway funcionality not discussed, I guess you are meant to leave them as post-, so left there. :)
kernel functionality eventually, not separate programs.
DOSSHELL: [...]I leave that discussion for later maybe. I think for the moment we should focus wether they should be pre-/post
By the way - pre 1.0 - as far as I understand Aitor, Euro compliancyI guess those dealing with directory entries, that is, kernel, UNDELETE and the disk tools (possibly others). My aim is to leave them there as reference, not that I know of a tool that has problems with that.
is already okay. I think only a few disk tools still TRASH LFNs, but
which? Test results?
But if we found a utility trashing LFNs, we should care about that (or that's the purpose, unless people considers that post-1.0).
BACKUP / RESTORE can be post-1.0 if you ask me.Annotated...
Todo list should mention who plans to do what (e.g. Aitor: GRAFTABL, APPEND)As I said already, I have to update the APPEND entry, and it will specify that I am into that. But adding people's names for other entries than those that are missing and are being started is hard: so when kernel is ready except for "fix bugs", shall we list everybody there working to patch bugs?
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 ableCould you please test and add bugzilla entries as appropriate, or suggest Steffen for his table?
to show > 2 GB free? ...
Aitor
------------------------------------------------------- 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
