On Thu, 25 Mar 2004 20:20:22 -0600, you wrote:
Hi Uso,
>3.31 actually (which first did >32 MB partitions) :P
I remember crystal clear, this version was release by Compaq.
I help my schoolmate to partition his 200MB Connor with this,
otherwise drive letter will reach "I", horrible.
Rgds,
John
Hi,
I've written a guide "Setup MS Client 3.0 under FreeDOS with 3COM
3C905B-TX".
Since this is a step-by-step guide, it's not conflict with Mike's
network howto (it's far more detail and complete).
Anyone have time can you please help me to check the integrity? Or
add your experience, comment.
At 04:13 PM 3/24/2004 -0600, Michael Devore wrote:
>The first release candidate version of EMM386 with VCPI support is available at
>ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMM386SR.ZIP, as
>executable and ASM+C source. Note well: the uncompressed executable name is no
At 04:13 PM 3/24/2004 -0600, you wrote:
>The first release candidate version of EMM386 with VCPI support is available at
>ftp://ftp.devoresoftware.com/downloads in the files EMM386.ZIP and EMM386SR.ZIP, as
>executable and ASM+C source. Note well: the uncompressed executable name is now
>EMM386.
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 yo
Aitor Santamaría Merino wrote:
Hi,
Alain has introduced in this mail something interesting that was
introduced in other posts too: the spec mentions a kernel compatible to
MS-DOS 3.30,
3.31 actually (which first did >32 MB partitions) :P
Alain escribió:
some others like Win 3.11 compat
should
Eric Auer escribió:
Hi, some comments on your comments...
HIMEM /INT15H=... should not be extremely hard to do, so I vote for it.
That's another argument that I like: low cost to implement it. A third
opinion (or more) for the untie?
Eric, you say DOS5 we have it more or less, I just watch the
Hi,
Alain has introduced in this mail something interesting that was
introduced in other posts too: the spec mentions a kernel compatible to
MS-DOS 3.30, but actually I think that our current FreeDOS kernel is
closer to 5.0 and sucessors than 3.30. Also 3.30 and 5.0 have many
differences in da
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 wi
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
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 SH
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 spe
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.
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
about fat32 testing: I believe a working DOSFSCK 2.10 just what is
needed (not what is whished for).
A ScanDisc-alike program would be nice, but IMHO what is really _needed_
is just some way of testing and fixing a fat32 disk, nothing fancy fust
functional. This would give time to ScanDisk be i
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
Hi!
25-Мар-2004 21:05 [EMAIL PROTECTED] (Eric Auer) wrote to
[EMAIL PROTECTED]:
EA> HIMEM /HMAMIN=m is indeed not very useful. Being able to allocate PARTS
EA> of the HMA would be nice but was not introduced before MS DOS 7 or so,
EA> and before that time, HMAMIN protected the system from giv
Hi, some comments on your comments...
HIMEM /INT15H=... should not be extremely hard to do, so I vote for it.
HIMEM /HMAMIN=m is indeed not very useful. Being able to allocate PARTS
of the HMA would be nice but was not introduced before MS DOS 7 or so,
and before that time, HMAMIN protected t
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
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
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
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
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 f
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 ch
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 n
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
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/t
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.
Eric Auer wrote:
...
URLs:
http://www.infradead.org/devload/
http://www.infradead.org/devload/source/devload.asm
http://www.coli.uni-sb.de/~eric/stuff/soft/by-others/ devload-3.12.zip
If this turns out to work: Bernd, you said devload is open but no longer
maintained. License is GPL but the distro
29 matches
Mail list logo
