Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
On Thu, 25 Mar 2004, Gregory Pietsch wrote: > i (insert mode) - implemented. I made the get-out-of-insert-mode > character a period on an otherwise blank line instead of control-Z > because the one thing I hated about MS edlin was the use of control > characters in the syntax. (The period can be escaped if you really > wanted just a period on a line.) isn't it possible to accept ^Z too? I've had a report of somebody fighting with edlin because he didn't know it was "." instead of ^Z... And then the only way to escape is to try all keys or to reboot... Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi! 26-Мар-2004 11:21 [EMAIL PROTECTED] (tom ehlert) wrote to Aitor Santamarэa Merino <[EMAIL PROTECTED]>: >>>emm386 RAM=m-n range for UMBs + EMS >>>emm386 ROM=m-n range of RAM to be used to shadow ROM >>> as soon as someone finds out what that's supposed to do _exactly_ ASM>> My guesses: te> e.g. Eric implemented it as 'RAM' = 'I=', and 'ROM=' = 'X=', and te> wondered why I didn't accept it (because it's wrong) te> As I said: as soon as someone finds out what that's supposed to do te> _EXACTLY_, ... Excerpt fom "HELP EMM386.EXE" from MS-DOS 6.22: __O\_/_\_/O__ Syntax DEVICE=[drive:][path]EMM386.EXE [ON|OFF|AUTO] [memory] [MIN=size] [W=ON|W=OFF] [Mx|FRAME=address|/P] [Pn=address] [X=-] [I=-] [B=address] [L=minXMS] [A=altregs] [H=handles] [D=nnn] [RAM=-] [NOEMS] [NOVCPI] [HIGHSCAN] [VERBOSE] [WIN=-] [NOHI] [ROM=-] [NOMOVEXBDA] [ALTBOOT] Parameters memory Specifies the maximum amount of extended memory (in kilobytes) that you want EMM386 to provide as expanded/Virtual Control Program Interface (EMS/VCPI) memory. This amount is in addition to the memory used for UMBs and EMM386 itself. Values for memory are in the range 64 through the lesser of either 32768 or the amount of extended memory available when EMM386 is loaded. The default value is the amount of free extended memory. If you specify the NOEMS switch, the default value is 0. EMM386 rounds the value down to the nearest multiple of 16. Switches X=- Prevents EMM386 from using a particular range of segment addresses for an EMS page or for UMBs. Valid values for and are in the range A000h through h and are rounded down to the nearest 4-kilobyte boundary. The X switch takes precedence over the I switch if the two ranges overlap. I=- Specifies a range of segment addresses to be used (included) for an EMS page or for UMBs. Valid values for and are in the range A000h through h and are rounded down to the nearest 4-kilobyte boundary. The X switch takes precedence over the I switch if the two ranges overlap. RAM=- Specifies a range of segment addresses to be used for UMBs and also enables EMS support. If you do not specify a range, EMM386 uses all available adapter space to create UMBs and a page frame for EMS. NOEMS Provides access to the upper memory area but prevents access to expanded memory. NOVCPI Disables support for VCPI applications. This switch must be used with the NOEMS switch. If you specify the NOVCPI switch without specifying the NOEMS switch, EMM386 does not disable VCPI support. If you specify both switches, EMM386 disregards the MEMORY parameter and the MIN switch. Disabling support for VCPI applications reduces the amount of extended memory allocated. [ROM=-] Specifies a range of segment addresses that EMM386 uses for shadow RAM──random-access memory used for read-only memory (ROM). Valid values for and are in the range A000h through h and are rounded down to the nearest 4-kilobyte boundary. Specifying this switch may speed up your system if it does not already have shadow RAM. _ O/~\ /~\O So, difference between RAM= and I= not very clear, but, probably, as sayed by Aitor, I= does unconditional memory inclusion. Also, RAM= enables support for EMS. X=, contrary to I=, excludes memory range from handling. ROM= makes shadow copy of specified memory region (this should speedup access to given region, if there resides some slow ROM). __O\_/_\_/O__ Sharing XMS and EMS memory EMM386 provides EMS/VCPI memory for programs that require it by converting XMS memory to EMS/VCPI memory. When it is loaded, EMM386 reserves the amount of memory specified by the MIN switch for use as EMS/VCPI memory (the default value is 256K). Once this amount of XMS memory is reserved, it is always available as EMS/VCPI memory and no longer available as XMS memory. EMM386 may be able to convert additional amounts of XMS memory to EMS/VCPI memory, up to the amount specified by the MEMORY parameter. EMM386 returns the additional amount back to XMS memory when it is no longer needed as EMS/VCPI memory. If you specify MIN=0, EMM386 does not reserve any XMS memory for use as EMS/VCPI memory. Instead, it converts XMS memory to EMS/VCPI memory only when a program requests it. This frees XMS memory when EMS/VCPI memory is not needed. However, EMM386 will not be able to supply the requested amount of EMS/VCPI memory if programs have allocated all the XMS memory at the time of the request. [...] Using EMM386 to provide access to the upper memory area [...] device drivers.
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, tom ehlert escribió: emm386 RAM=m-n range for UMBs + EMS emm386 ROM=m-n range of RAM to be used to shadow ROM as soon as someone finds out what that's supposed to do _exactly_ ASM> My guesses: ASM> RAM wrong guess why? I mean, you don't know how to implement this... (see below) ASM> My suspicion is ... ASM> ROM, my guessing is (only a guessing), ... e.g. Eric implemented it as 'RAM' = 'I=', and 'ROM=' = 'X=', and wondered why I didn't accept it (because it's wrong) As I said: as soon as someone finds out what that's supposed to do _EXACTLY_, ... Ok, EXACTLY: === ROM=mmm-nnn So it seems I was right after all: not that it says much, but it's exactly what I described: http://support.microsoft.com/default.aspx?scid=kb;en-us;98508 No bigdeal. Would have surprised me if it ran QBASIC NIBBLES and won't let you continue until you win the game. ;-) === RAM EMM386.EXE NOEMS => UMBs EMM386.EXE RAM => UMBs + PageFrame default: RAM ALMOST EXACTLY: === RAM=mmm-nnn Explained here (not fully): http://support.microsoft.com/default.aspx?scid=kb;en-us;74212 There's a range of memory that is searched with the search algorythm proposed there. The range is fixed C000-DFFF, unless overriden (presumably) with the RAM= parameter. You can also directly INCLUDE other areas with the I= forces to include these areas (with no need to be checked by the algorythm). The I= switch on EMM386.EXE has a higher order of precedence than the search algorithm. And above that all, areas under the X= flag are unconditionally EXCLUDED. some others like Win 3.11 compat should probably be fixed before we call it FreeDOS 1.0 ... There is probably a patent to prevent us of it anyway :( ASM> I don't think so... Did it prevent DR-DOS from doing that anyway? I ASM> think it's just a question of misscompatibilities here or there... There's a technote about Win 3.1 compatibility, and why this probably will never happen, so I don't repeat it here. then let me rephrase because I didn't explain myself well. What I meant is: there are TECHNICAL (not LEGAL) problems by which we don't have it. And by technical I mean noone set to do it (of course, there are older threads and technotes and that all). Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
>>emm386 RAM=m-n range for UMBs + EMS >>emm386 ROM=m-n range of RAM to be used to shadow ROM >> >> as soon as someone finds out what that's supposed to do _exactly_ >> ASM> My guesses: ASM> RAM wrong guess ASM> My suspicion is ... ASM> ROM, my guessing is (only a guessing), ... e.g. Eric implemented it as 'RAM' = 'I=', and 'ROM=' = 'X=', and wondered why I didn't accept it (because it's wrong) As I said: as soon as someone finds out what that's supposed to do _EXACTLY_, ... tom --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Aitor Santamaría Merino wrote:
Hi,
Gregory Pietsch escribió:
I don't see anything about edlin or code in there, so I guess they
are okay, or am I just not getting any feedback?
Oops, sorry!
When the list was first posted, EDLIN didn't exist, so I'll add it (to
MISC utilities, ok?). Could you report on the commands already
implemented? Is there any MS-EDLIN command still to be implemented?
Here are the differences between FreeDOS edlin and MS edlin, AFAIK:
# (edit a single line) - implemented. Does not work the same as MS's
because I wanted the implementation to be easy. The only difference is
that the user has to type in the entire line instead of just using the
-> key.
a (append) - MS edlin used this for a "paged file" where part of the
file is in memory and part hadn't been read in. My implementation can
handle larger files (making the paged file thing obsolete), so I changed
this to append to the end of the buffer, which seems more natural.
c (copy range of lines) - implemented.
d (delete a block of lines) - implemented.
e (save and quit) - implemented.
i (insert mode) - implemented. I made the get-out-of-insert-mode
character a period on an otherwise blank line instead of control-Z
because the one thing I hated about MS edlin was the use of control
characters in the syntax. (The period can be escaped if you really
wanted just a period on a line.)
l (list lines) - implemented.
m (move block) - implemented.
p (page) - implemented.
q (quit) - implemented.
r (replace) - implemented. I added to the string syntax.
s (search and replace) - implemented. MS edlin had a control-Z between
the two strings; I have a comma, which results in a cleaner syntax, IMNSHO.
t ("transfer" file) - implemented. It slurps in a whole file instead of
going the "paging" route.
w (write file) - implemented. I added the optional filename because the
one thing that isn't there that MS edlin has is automatic file backups.
Having the filename there makes it easy to backup the file manually.
I believe that's all of them.
It will be a bit harder for me to recover one of those old MS-DOS
versions to compare...
Aside from the control-characters-on-the-command-line issue (which I got
around by improving the syntax), the only thing I can see that MS edlin
does that mine doesn't is make automatic backups of the file you're
editing. I got around it by adding the optional filename to the "w"
command, so that the user can make a backup if he/she/it wants.)
I don't know much about CODE, but doesn't sound as one of the "core"
MS-DOS utilities, and hence does not go into this list, sorry...
Aitor
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
___
Freedos-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Luchezar Georgiev escribio': Here is a quote from the spec (http://fd-doc.sourceforge.net/spec/spec.html): The MS-DOS 3.3 compatibility extends only to the FreeDOS kernel. FreeDOS programs should be compatible with MS-DOS 6.22, because those are the features that users will be most familiar with. MS-DOS 6.22 did contain SCANDISK, although FAT32 wasn't there yet. Very convincing ;-) SCANDISK remains there, then... and on the other hand, it points out that FAT32 needs not be requested for 1.0, right? Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, Gregory Pietsch escribió: I don't see anything about edlin or code in there, so I guess they are okay, or am I just not getting any feedback? Oops, sorry! When the list was first posted, EDLIN didn't exist, so I'll add it (to MISC utilities, ok?). Could you report on the commands already implemented? Is there any MS-EDLIN command still to be implemented? It will be a bit harder for me to recover one of those old MS-DOS versions to compare... I don't know much about CODE, but doesn't sound as one of the "core" MS-DOS utilities, and hence does not go into this list, sorry... Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, Luchezar Georgiev escribiÃ: Thanks, Aitor! 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm As far as I know, APPEND is considered dangerous and incompatible. It had better stay missing. Well, it is not aware of task switchers, it may have problems with executing nested SHELLs, true. Many reasons why MS does NOT support it. Anyway I am giving a try, as it was VERY useful to me: it allowed me to run WordStar Express on my PC/XT having two DD drives: 3 1/2 and 5 1/4... I am being delayed because I've learnt to avoid using HLLs (C) when hooking int21h, and I am rewriting that in NASM. Anyway maybe I should move it to post-1.0, I'll do that unless someone complains... I think that SCANDISK is the most important missing program. Whether to borrow code for it from CHKDSK, DOSFSCK, both or none, is a disputable issue which ultimately its developer will solve. I share your concern. Anyway Bart's argument is still valid. One more opinion for the untie? (about wether to move scandisk for post-1.0?). Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, BTW, TO EVERYBODY (I forgot to say): changes will not be commited IMMEDIATELY, ok? tom ehlert escribió: emm386 RAM=m-n range for UMBs + EMS emm386 ROM=m-n range of RAM to be used to shadow ROM as soon as someone finds out what that's supposed to do _exactly_ My guesses: RAM (you can specify it without parameters, in that case it is trivial: use both UMBs and EMS, and thus incompatible to NOEMS) In any case, RAM should always be incompatible to NOEMS. It's long ago since I last watched EMM386 code, but I seem to recall that there's some upper memory scanner to determine the memory that cann be used as UMBs, I guess that with this paramenter you skip the testing, as the user will tell you which gap of the memory may be used for UMBs and for the page frame. My suspicion is that you can specify more than one of these parameters. ROM, my guessing is (only a guessing), it copies the memory of that range into several pages, and maps that phisical memory into those pages. himem /INT15H=xxx himem /HMAMIN=m prehistoric crap might be moved to Post 3.0 Ok, for the moment we'll leave it for post-1.0, quite more generic ;-) I have never used int15h to allocate embs, which would be the impact of this for application compatibility? I guess not much, as I haven't heard complains about this yet... backup / restore Missing - Addressed (Ralf Quint) might be changed to 'missing' ( if someone ever missed that) I'll leave it as it is, I know Ralf is working on it (although all of us have different amount of timeslice to work on FreeDOS I guess ;-)) setver (CALLVER, VERSION= in CONFIG.SYS) Ready should be changed to missing - it's simply not the same thing Well, it may do the same functionality, that's why (1) I said NOT MS compatible (2) in post-1.0, specified that a compatible one is REQUIRED, what about the rest? one more opinion on this and I'll change it (if you also think it is confusing as it is). Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Many thanks, Bart. Alain, that is what I tried to explain but with nicest words (probably of an English native speaker! ;-)). Aitor Bart Oldeman escribió: I think that SCANDISK is the most important missing program. it may be important, but I respectfully disagree it being a showstopper. The FreeDOS spec still states that we should be compatible with MSDOS 3.3. [etcetc] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Nice that you pointed about FAT32. I'll explain what I tried to reflect in the list (because FAT32 was not popular time ago). My point has been: FAT32 support is left as post-1.0. The fact that KERNEL, FDISK and other components already support FAT32 is an extra plus, but maybe we don't need to mark "FAT32" as one of the milestones for FD1.0 precisely because NOT ALL the utilities already support FAT32. Of course, this all is changeable: we can set that support for FAT32 be requested for ALL the components (including ALL disk utilities, UNDELETE, etc). How does people feel about it? Respect to the reference to DOSFSCK, I don't know well how to do it, so do you people prefer that (a) DOSFSCK be added to the list as a base utility? In my understanding, this decission corresponds to Jim Hall. Notice that there is no tool in MS-DOS called DOSFSCK (b) simply make a reference as with HIMEM/FDXMS286? (although FAT32 support is not "required" for 1.0 in the present situation, this may be technically a bit rare to be noticed there) I'll opt for (b), unless the contrary is decided. Notice that this does not solve the problem for other utilities (UNDELETE, DEFRAG?,...) that may not support this. Aitor Alain escribió: Hi, I found this: chkdsk Ready2003-10-6 I don't agree. If we have a fat32 kernel, and chkdsk is only fat16 we cannot use it :( There could be a reference to dosfsck, stating not compatible or something. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
A little more about memory testing: A good teste program must be very long, for one thing that nowdays memory are prone to random errors, not only repeatable ones. What I believe is usefull is something else: just check if it is there at all, if there are no holes (like the one at 16Mb inserted by some mis-configured bios), and other gross errors. That is more or less what the Bios "should" do. I agree more with Eric than with Tom (see bellow). Alain Eric Auer escreveu: > HIMEM /TESTMEM:... is indeed not that useful. An exist-check might be > useful, but a check like "write own address to all 0x?000 form > addresses" (to check if there is really RAM there and it is not > multiple copies of the first 16 MB or something) will probably be > useful to detect broken BIOS-hooking memory allocation schemes > without wasting much CPU time. tom ehlert escreveu: himem /TESTMEM:ON|OFF really want a (bad) memory test in 1.0 ? A> As bad as is MS's is, it did save me many times. Consider it not a A> _test_for_100%_ok_ but as a _test_if_exists_ and I disagree. If you want a memorytest (I don't question that), you can easily start one in autoexec; even HIMEM /TEST might be useful it's NOT intended to be a real memtest, but if you want one ... A> you can understand how good it is. if you understand how good it is (or _any_ other memtest) you have more information then I (and a VERY technical understanding of it) In fact I did have some information in memory tests, but that was a long time ago and probably a little outdated. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Yes, Bart, "the show must go on!" ;-) The FreeDOS spec still states that we should be compatible with MSDOS 3.3. Here is a quote from the spec (http://fd-doc.sourceforge.net/spec/spec.html): The MS-DOS 3.3 compatibility extends only to the FreeDOS kernel. FreeDOS programs should be compatible with MS-DOS 6.22, because those are the features that users will be most familiar with. MS-DOS 6.22 did contain SCANDISK, although FAT32 wasn't there yet. If SCANDISK development isn't that easy as Aitor anticipates, DOSFSCK replaces it functionally. We Bulgarians have a proverb - "Petima Petka ne chakat" (5 men don't wait for Pete). So if SCANDISK is ready - fine, if not - DOSFSCK will replace it for the "show" ;-) Lucho --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hello Alain, A> tom ehlert escreveu: >> himem /TESTMEM:ON|OFF >> really want a (bad) memory test in 1.0 ? A> As bad as is MS's is, it did save me many times. Consider it not a A> _test_for_100%_ok_ but as a _test_if_exists_ and I disagree. If you want a memorytest (I don't question that), you can easily start one in autoexec; even HIMEM /TEST might be useful it's NOT intended to be a real memtest, but if you want one ... A> you can understand how good it is. if you understand how good it is (or _any_ other memtest) you have more information then I (and a VERY technical understanding of it) tom --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
On Thu, 25 Mar 2004, Luchezar Georgiev wrote: > Thanks, Aitor! > > 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm > As far as I know, APPEND is considered dangerous and incompatible. It had > better stay missing. > I think that SCANDISK is the most important missing program. it may be important, but I respectfully disagree it being a showstopper. The FreeDOS spec still states that we should be compatible with MSDOS 3.3. Scandisk is beyond 3.3 FAT32 support is beyond 3.3 even support for hard drives > 32 MB is beyond 3.3 -- it's cool that we have the last two features but they're not required by our self-imposed plans. so, if anything FAT32 related is going to stop 1.0 then either the spec should be changed or 1.0 will be released a lot later. Bart --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
If we have a fat32 kernel, and chkdsk is only fat16 we cannot use it :( We can, but only on FAT12 and FAT16 volumes. But SCANDISK must support FAT32. That's why it had better use the DOSFSCK, not CHKDSK engine. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
tom ehlert escreveu: himem /TESTMEM:ON|OFF really want a (bad) memory test in 1.0 ? As bad as is MS's is, it did save me many times. Consider it not a _test_for_100%_ok_ but as a _test_if_exists_ and you can understand how good it is. IMHO if implemented, it should be implemented with that functionality in mind. Alain --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi, I found this: chkdsk Ready 2003-10-6 I don't agree. If we have a fat32 kernel, and chkdsk is only fat16 we cannot use it :( There could be a reference to dosfsck, stating not compatible or something. Alain Aitor Santamaría Merino escreveu: I have committed most of the pending changes to the TODO list. While Jim and I acknowledge on the way of reintegrating it on the site, Bernd has kindly posted a preview of the list in the links below: 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm post-1.0: http://fdos.org/ripcord/fdos_1_0/official/post.htm --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Thanks, Aitor! 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm As far as I know, APPEND is considered dangerous and incompatible. It had better stay missing. I think that SCANDISK is the most important missing program. Whether to borrow code for it from CHKDSK, DOSFSCK, both or none, is a disputable issue which ultimately its developer will solve. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
emm386 RAM=m-n range for UMBs + EMS emm386 ROM=m-n range of RAM to be used to shadow ROM as soon as someone finds out what that's supposed to do _exactly_ himem /INT15H=xxx himem /HMAMIN=m prehistoric crap might be moved to Post 3.0 himem /TESTMEM:ON|OFF really want a (bad) memory test in 1.0 ? backup / restore Missing - Addressed (Ralf Quint) might be changed to 'missing' ( if someone ever missed that) setver (CALLVER, VERSION= in CONFIG.SYS) Ready should be changed to missing - it's simply not the same thing --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Aitor Santamaría Merino wrote: Hi all, I have committed most of the pending changes to the TODO list. While Jim and I acknowledge on the way of reintegrating it on the site, Bernd has kindly posted a preview of the list in the links below: 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm post-1.0: http://fdos.org/ripcord/fdos_1_0/official/post.htm When the todo list is back ready in its place I'll make an official announcement, but for the moment, it is open for discussion wether you think that the items in the 1.0 list are to be created/edited/removed/moved, etc (I'd prefer not to talk into post-1.0 list yet, I just send it here so that you have a reference of what it's there, and in case you think that something of what is there should be for 1.0 and not for later). So all of you that have soemthing to say about this, please speak. Public and private (aitorsm _AT_ inicia.es) mails are admitted, although perhaps it's better to make them public, so that other people can give their opinion. Please note that the list is supposed to be a list of items, that is, CONCISE, and NOT verbose. Also I suppose it's better if the messages posted here are also CONCISE, that would be helpful because my time is limitted. Note that there's also the list of DOS exitcodes kindly collected and contributed by Matthias Paul. For compatibility, please check that your utilities comply with these exitcodes as much as possible. Finally, if someone has an opinion on some item to be modified, but noone else says nothing, after certain time I'll understand that everybody agrees, and I commit the change (or at least, I'll annotate the change for the next big update). Regards, Aitor I don't see anything about edlin or code in there, so I guess they are okay, or am I just not getting any feedback? Gregory Pietsch --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] FreeDOS 1.0 TODO list ready (but not yet posted)
Hi all, I have committed most of the pending changes to the TODO list. While Jim and I acknowledge on the way of reintegrating it on the site, Bernd has kindly posted a preview of the list in the links below: 1.0 todo's: http://fdos.org/ripcord/fdos_1_0/official/todos.htm post-1.0: http://fdos.org/ripcord/fdos_1_0/official/post.htm When the todo list is back ready in its place I'll make an official announcement, but for the moment, it is open for discussion wether you think that the items in the 1.0 list are to be created/edited/removed/moved, etc (I'd prefer not to talk into post-1.0 list yet, I just send it here so that you have a reference of what it's there, and in case you think that something of what is there should be for 1.0 and not for later). So all of you that have soemthing to say about this, please speak. Public and private (aitorsm _AT_ inicia.es) mails are admitted, although perhaps it's better to make them public, so that other people can give their opinion. Please note that the list is supposed to be a list of items, that is, CONCISE, and NOT verbose. Also I suppose it's better if the messages posted here are also CONCISE, that would be helpful because my time is limitted. Note that there's also the list of DOS exitcodes kindly collected and contributed by Matthias Paul. For compatibility, please check that your utilities comply with these exitcodes as much as possible. Finally, if someone has an opinion on some item to be modified, but noone else says nothing, after certain time I'll understand that everybody agrees, and I commit the change (or at least, I'll annotate the change for the next big update). Regards, Aitor --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click ___ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
