Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FreeDOS has an error with it's DEVICE= line in CONFIG.SYS
463 views
Skip to first unread message
Rod Pemberton
Dec 15, 2012, 11:26:19 PM12/15/12
to
I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
FreeDOS' CONFIG.SYS (v1.1):
DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
It flagged the '=' sign with an error via a caret '^' on the next
line. What does that mean exactly? What could be wrong with the
'=' sign? Nothing. It happens there is no correlation between
the indicated error and the problem ... There is a bug in
FreeDOS.
So, next, I reduced the FreeDOS DEVICE= line to:
DEVICE=HIMEMX.EXE
It still flagged the '=' sign as an error.
After spending a half-hour trying every combination of upper- and
lower-case "DEVICE=", "HIMEMX.EXE", and the path, I found that
FreeDOS needs a space between HIMEMX.EXE and it's parameters.
Unfortunately, the need for a space is required whether the
DEVICE= line has parameters or not ... I.e., the line above
without parameters needs a space at the end!!! Most DOS editors
trim the final spaces from the end-of-line. I'd think that anyone
familiar with DOS would know that or should.
If you're reading and are familiar with someone on the FreeDOS
team, could you pass along this error report?
Rod Pemberton
Sjouke Burry
Dec 16, 2012, 3:36:38 AM12/16/12
to
"Rod Pemberton" <do_no...@notemailnotz.cnm> wrote in news:kaji80$5lg$1
@speranza.aioe.org:
Between a program and the parameters you ALWAYS need a space,
otherwise dos does not know where the program name ends.
For the last twenty years I have followed that rule.
@speranza.aioe.org:
otherwise dos does not know where the program name ends.
For the last twenty years I have followed that rule.
Bill Leary
Dec 16, 2012, 5:35:01 AM12/16/12
to
"Sjouke Burry" wrote in message
news:XnsA12B61C144Fsjo...@213.75.12.10...
?). For example, "DIR/W" displays a wide directory, just as it should. I
just tried it on both my MSDOS 3.3 machine and in the command prompt of
Windows 7. And "DIR *.EXE" works, but "DIR*.EXE" doesn't because * is a
wildcard for alphanumeric.
However, that's not relevant here since he's talking about CONFIG.SYS.
Again, on my MSDOS 3.3 machine my CONFIG.SYS "DEVICE" lines all have the "="
immediately after the "DEVICE". In fact, there are no spaces at all in the
CONFIG.SYS file on this machine.
If he's seeing what he thinks he's seeing (I don't have FreeDOS on any of my
machines to try), then it's a bug. Or, at least, an "incompatibility."
Their parser appears to be testing incorrectly for the terminator.
- Bill
news:XnsA12B61C144Fsjo...@213.75.12.10...
> "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:
>> I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
>> FreeDOS' CONFIG.SYS (v1.1):
>>
>> DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
>>
>> It flagged the '=' sign with an error via a caret '^' on the next
>> line. What does that mean exactly? What could be wrong with the
>> '=' sign? Nothing. It happens there is no correlation between
>> the indicated error and the problem ... There is a bug in
>> FreeDOS.
>>
>> So, next, I reduced the FreeDOS DEVICE= line to:
>>
>> DEVICE=HIMEMX.EXE
>>
>> It still flagged the '=' sign as an error.
>>
>> After spending a half-hour trying every combination of upper- and
>> lower-case "DEVICE=", "HIMEMX.EXE", and the path, I found that
>> FreeDOS needs a space between HIMEMX.EXE and it's parameters.
>>
>> Unfortunately, the need for a space is required whether the
>> DEVICE= line has parameters or not ... I.e., the line above
>> without parameters needs a space at the end!!! Most DOS editors
>> trim the final spaces from the end-of-line. I'd think that anyone
>> familiar with DOS would know that or should.
>>
>> If you're reading and are familiar with someone on the FreeDOS
>> team, could you pass along this error report?
>
>> I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
>> FreeDOS' CONFIG.SYS (v1.1):
>>
>> DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
>>
>> It flagged the '=' sign with an error via a caret '^' on the next
>> line. What does that mean exactly? What could be wrong with the
>> '=' sign? Nothing. It happens there is no correlation between
>> the indicated error and the problem ... There is a bug in
>> FreeDOS.
>>
>> So, next, I reduced the FreeDOS DEVICE= line to:
>>
>> DEVICE=HIMEMX.EXE
>>
>> It still flagged the '=' sign as an error.
>>
>> After spending a half-hour trying every combination of upper- and
>> lower-case "DEVICE=", "HIMEMX.EXE", and the path, I found that
>> FreeDOS needs a space between HIMEMX.EXE and it's parameters.
>>
>> Unfortunately, the need for a space is required whether the
>> DEVICE= line has parameters or not ... I.e., the line above
>> without parameters needs a space at the end!!! Most DOS editors
>> trim the final spaces from the end-of-line. I'd think that anyone
>> familiar with DOS would know that or should.
>>
>> If you're reading and are familiar with someone on the FreeDOS
>> team, could you pass along this error report?
>
> Between a program and the parameters you ALWAYS need a space,
> otherwise dos does not know where the program name ends.
> For the last twenty years I have followed that rule.
Only if what follows is alphanumeric (or an alphanumeric stand-in, like * or
> otherwise dos does not know where the program name ends.
> For the last twenty years I have followed that rule.
?). For example, "DIR/W" displays a wide directory, just as it should. I
just tried it on both my MSDOS 3.3 machine and in the command prompt of
Windows 7. And "DIR *.EXE" works, but "DIR*.EXE" doesn't because * is a
wildcard for alphanumeric.
However, that's not relevant here since he's talking about CONFIG.SYS.
Again, on my MSDOS 3.3 machine my CONFIG.SYS "DEVICE" lines all have the "="
immediately after the "DEVICE". In fact, there are no spaces at all in the
CONFIG.SYS file on this machine.
If he's seeing what he thinks he's seeing (I don't have FreeDOS on any of my
machines to try), then it's a bug. Or, at least, an "incompatibility."
Their parser appears to be testing incorrectly for the terminator.
- Bill
Sjouke Burry
Dec 16, 2012, 12:03:22 PM12/16/12
to
"Bill Leary" <Bill_...@msn.com> wrote in
news:JP-dnUvMTM5KPlDN...@giganews.com:
Internal commands behave differently from physical programs.
Both your examples are internal.
news:JP-dnUvMTM5KPlDN...@giganews.com:
Both your examples are internal.
R.Wieser
Dec 16, 2012, 1:04:48 PM12/16/12
to
Hello Rod,
> Unfortunately, the need for a space is required whether the
> DEVICE= line has parameters or not ...
If that is caused by the config.sys parser I would definitily call it buggy.
But have you already thought of the posibility that the HIMEMX program
itself is at fault here ? That it does not understand the way it gets
executed from within the booting OS (as opposed from the command-line) ?
Regards,
Rudy Wieser
-- Origional mesage:
Rod Pemberton <do_no...@notemailnotz.cnm> schreef in berichtnieuws
kaji80$5lg$1...@speranza.aioe.org...
> Unfortunately, the need for a space is required whether the
> DEVICE= line has parameters or not ...
But have you already thought of the posibility that the HIMEMX program
itself is at fault here ? That it does not understand the way it gets
executed from within the booting OS (as opposed from the command-line) ?
Regards,
Rudy Wieser
-- Origional mesage:
Rod Pemberton <do_no...@notemailnotz.cnm> schreef in berichtnieuws
kaji80$5lg$1...@speranza.aioe.org...
Auric__
Dec 16, 2012, 3:50:12 PM12/16/12
to
Is HIMEMX.EXE in the root directory? (It should be in C:\FDOS\BIN, not C:\.)
If it's not, then you should pass the full path, e.g.:
DEVICE=C:\FDOS\BIN\HIMEMX.EXE /switches
In VMware, with the full path and *no* switches, I get no error. With it
entered exactly as you have it, I get the same error, with or without the
full path specified. With the full path specified and the switches spaced out
as mentioned by Sjouke Burry:
DEVICE=C:\FDOS\BIN\HIMEMX.EXE /MAX=2097152 /NUMHANDLES=128 /METHOD:PORT92
...it works fine.
--
You wanted to!
Auric__
Dec 16, 2012, 3:50:54 PM12/16/12
to
Sjouke Burry wrote:
> Internal commands behave differently from physical programs.
Not when it comes to switches at the prompt. Pick any program you like, and
> Internal commands behave differently from physical programs.
type 'appname/any_switch', e.g.:
edit/b/h
DOS has never cared about spaces between switches, or a lack of them, as long
as the switch character is '/'. (Of course, if the switch requires a space,
e.g. '/o filename', that's different.)
--
It is sad that we should meet only thus at the ending.
JJ
Dec 16, 2012, 4:17:19 PM12/16/12
to
"Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:
> I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
> FreeDOS' CONFIG.SYS (v1.1):
>
> DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
>
> It flagged the '=' sign with an error via a caret '^' on the next
> line. What does that mean exactly? What could be wrong with the
> '=' sign? Nothing. It happens there is no correlation between
> the indicated error and the problem ... There is a bug in
> FreeDOS.
>
> So, next, I reduced the FreeDOS DEVICE= line to:
>
> DEVICE=HIMEMX.EXE
>
> It still flagged the '=' sign as an error.
>
> After spending a half-hour trying every combination of upper- and
> lower-case "DEVICE=", "HIMEMX.EXE", and the path, I found that
> FreeDOS needs a space between HIMEMX.EXE and it's parameters.
>
> Unfortunately, the need for a space is required whether the
> DEVICE= line has parameters or not ... I.e., the line above
> without parameters needs a space at the end!!! Most DOS editors
> trim the final spaces from the end-of-line. I'd think that anyone
> familiar with DOS would know that or should.
I've encountered this confusing problem before (I'm still using kernel
> I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
> FreeDOS' CONFIG.SYS (v1.1):
>
> DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
>
> It flagged the '=' sign with an error via a caret '^' on the next
> line. What does that mean exactly? What could be wrong with the
> '=' sign? Nothing. It happens there is no correlation between
> the indicated error and the problem ... There is a bug in
> FreeDOS.
>
> So, next, I reduced the FreeDOS DEVICE= line to:
>
> DEVICE=HIMEMX.EXE
>
> It still flagged the '=' sign as an error.
>
> After spending a half-hour trying every combination of upper- and
> lower-case "DEVICE=", "HIMEMX.EXE", and the path, I found that
> FreeDOS needs a space between HIMEMX.EXE and it's parameters.
>
> Unfortunately, the need for a space is required whether the
> DEVICE= line has parameters or not ... I.e., the line above
> without parameters needs a space at the end!!! Most DOS editors
> trim the final spaces from the end-of-line. I'd think that anyone
> familiar with DOS would know that or should.
build 2036). It seems that KERNEL.SYS not just poorly parse the line, but
also incorrectly report the line which causes the error.
> If you're reading and are familiar with someone on the FreeDOS
> team, could you pass along this error report?
>
>
> Rod Pemberton
build was on 2012-02-07. If you have older build (see your KERNEL's
HISTORY.TXT), try the latest build (the ke2041_386f32.zip file) from:
http://sourceforge.net/projects/freedos/files/Kernel/2041/
http://tinyurl.com/bt5bwcv
or...
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2041/
http://tinyurl.com/ce2t5u7
Rod Pemberton
Dec 16, 2012, 4:32:25 PM12/16/12
to
"R.Wieser" <add...@not.available> wrote in message
news:50ce0ccf$0$6855$e4fe...@news2.news.xs4all.nl...
> > "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:...
...
However, the DEVICE= line works correctly for MS-DOS (v7.10). To
me, that implies that FreeDOS is doing something different. It
could be that difference is triggering a bug in HIMEMX too, e.g.,
perhaps they have an off-by-one error passing command line, or etc
speculation ... Even if HIMEMX has a bug, I'd probably declare
that difference in FreeDOS to be a bug also. If there was no
difference or bug in FreeDOS versus MS-DOS, then I'd think that a
bug in HIMEMX couldn't be triggered. True?
Rod Pemberton
news:50ce0ccf$0$6855$e4fe...@news2.news.xs4all.nl...
> > "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:...
...
> > Unfortunately, the need for a space is required whether the
> > DEVICE= line has parameters or not ...
>
> If that is caused by the config.sys parser I would definitily
> call it buggy.
>
> But have you already thought of the posibility that the HIMEMX
> program itself is at fault here ? That it does not understand
> the way it gets executed from within the booting OS (as
> opposed from the command-line) ?
>
It could be.
> > DEVICE= line has parameters or not ...
>
> If that is caused by the config.sys parser I would definitily
> call it buggy.
>
> But have you already thought of the posibility that the HIMEMX
> program itself is at fault here ? That it does not understand
> the way it gets executed from within the booting OS (as
> opposed from the command-line) ?
>
However, the DEVICE= line works correctly for MS-DOS (v7.10). To
me, that implies that FreeDOS is doing something different. It
could be that difference is triggering a bug in HIMEMX too, e.g.,
perhaps they have an off-by-one error passing command line, or etc
speculation ... Even if HIMEMX has a bug, I'd probably declare
that difference in FreeDOS to be a bug also. If there was no
difference or bug in FreeDOS versus MS-DOS, then I'd think that a
bug in HIMEMX couldn't be triggered. True?
Rod Pemberton
Rod Pemberton
Dec 16, 2012, 4:33:04 PM12/16/12
to
"Auric__" <not.m...@email.address> wrote in message
news:XnsA12B8CCB2F340au...@88.198.244.100...
are no directories.
I recently re-installed an old IDE HD (Hard Drive) as my primary
master. My system normally boots from a secondary master via BIOS
settings which is a SATA SDD (Solid State Drive). I
re-partitioned and re-formatted the old IDE. Then, I sys'd it and
copied files to it. Next, I used the modern BBS menu (Bios Boot
Spec.) to select the primary master, the old IDE, to boot. I did
this in order to test the configuration of files, CONFIG.SYS, and
AUTOEXEC.BAT, etc using the FreeDOS command.com and kernal, before
making a bootable floppy image. Normally, I just create an boot
floppy using MS-DOS files, but I decided to see if there was
enough system files and utilities from FreeDOS and other sources
to make a boot disk with my set of preferred files. Once I like
it, I'll format, sys, and copy the files to an actual floppy.
Finally, I'll use John Fine's partcopy to create a floppy image.
It's much easier to use than rawread/rawrite or Linux 'dd'
command. Floppy disk drives are becoming more scarce. At some
point, I should probably create a bootable DOS CD or learn how to
use a ramdisk or virtual disk for creating floppy boot images...
> DEVICE=C:\FDOS\BIN\HIMEMX.EXE /switches
>
> In VMware, with the full path and *no* switches, I get no error.
Odd. Ok.
> With it entered exactly as you have it, I get the same error,
> with or without the full path specified.
Good.
> With the full path specified and the switches spaced out
> as mentioned by Sjouke Burry:
>
> DEVICE=C:\FDOS\BIN\HIMEMX.EXE /MAX=2097152
> /NUMHANDLES=128 /METHOD:PORT92
>
> ...it works fine.
Yes.
However, I just needed one space at the end of HIMEMX.EXE.
Rod Pemberton
news:XnsA12B8CCB2F340au...@88.198.244.100...
> Rod Pemberton wrote:
>
> > I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
> > FreeDOS' CONFIG.SYS (v1.1):
> >
> > DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
> >
> > [snip]
>
> > I pasted this DEVICE= line from my MS-DOS CONFIG.SYS into
> > FreeDOS' CONFIG.SYS (v1.1):
> >
> > DEVICE=HIMEMX.EXE/MAX=2097152/NUMHANDLES=128/METHOD:PORT92
> >
> >
> > It still flagged the '=' sign as an error.
> >
> > After spending a half-hour trying every combination of upper-
> > and lower-case "DEVICE=", "HIMEMX.EXE", and the path, I
> > found that FreeDOS needs a space between HIMEMX.EXE
> > and it's parameters.
> >
> > [snip]
> > It still flagged the '=' sign as an error.
> >
> > After spending a half-hour trying every combination of upper-
> > and lower-case "DEVICE=", "HIMEMX.EXE", and the path, I
> > found that FreeDOS needs a space between HIMEMX.EXE
> > and it's parameters.
> >
>
> Bearing in mind that I have roughly zero experience with
> FreeDOS...
>
> Is HIMEMX.EXE in the root directory? (It should be in
> C:\FDOS\BIN, not C:\.)
> If it's not, then you should pass the full path, e.g.:
>
Yes. The drive is blank, except for a handful of files. There
> Bearing in mind that I have roughly zero experience with
> FreeDOS...
>
> Is HIMEMX.EXE in the root directory? (It should be in
> C:\FDOS\BIN, not C:\.)
> If it's not, then you should pass the full path, e.g.:
>
are no directories.
I recently re-installed an old IDE HD (Hard Drive) as my primary
master. My system normally boots from a secondary master via BIOS
settings which is a SATA SDD (Solid State Drive). I
re-partitioned and re-formatted the old IDE. Then, I sys'd it and
copied files to it. Next, I used the modern BBS menu (Bios Boot
Spec.) to select the primary master, the old IDE, to boot. I did
this in order to test the configuration of files, CONFIG.SYS, and
AUTOEXEC.BAT, etc using the FreeDOS command.com and kernal, before
making a bootable floppy image. Normally, I just create an boot
floppy using MS-DOS files, but I decided to see if there was
enough system files and utilities from FreeDOS and other sources
to make a boot disk with my set of preferred files. Once I like
it, I'll format, sys, and copy the files to an actual floppy.
Finally, I'll use John Fine's partcopy to create a floppy image.
It's much easier to use than rawread/rawrite or Linux 'dd'
command. Floppy disk drives are becoming more scarce. At some
point, I should probably create a bootable DOS CD or learn how to
use a ramdisk or virtual disk for creating floppy boot images...
> DEVICE=C:\FDOS\BIN\HIMEMX.EXE /switches
>
> In VMware, with the full path and *no* switches, I get no error.
> With it entered exactly as you have it, I get the same error,
> with or without the full path specified.
> With the full path specified and the switches spaced out
> as mentioned by Sjouke Burry:
>
> DEVICE=C:\FDOS\BIN\HIMEMX.EXE /MAX=2097152
> /NUMHANDLES=128 /METHOD:PORT92
>
> ...it works fine.
However, I just needed one space at the end of HIMEMX.EXE.
Rod Pemberton
Rod Pemberton
Dec 16, 2012, 4:33:51 PM12/16/12
to
"Bill Leary" <Bill_...@msn.com> wrote in message
news:JP-dnUvMTM5KPlDN...@giganews.com...
> > > [snip]
> > [snip]
only for a space. I'd think they'd also test for EOL (CR LF), but
I didn't see that with my testing. Auric__ said he saw that with
his testing using VMWare.
RP
news:JP-dnUvMTM5KPlDN...@giganews.com...
> "Sjouke Burry" wrote in message
> news:XnsA12B61C144Fsjo...@213.75.12.10...
> > "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:
...
> news:XnsA12B61C144Fsjo...@213.75.12.10...
> > "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:
> > > [snip]
> > [snip]
>
> If he's seeing what he thinks he's seeing (I don't have FreeDOS
> on any of my machines to try), then it's a bug. Or, at least,
> an "incompatibility." Their parser appears to be testing
> incorrectly for the terminator.
>
That's what I took the issue to be. I'm assuming they're testing
> If he's seeing what he thinks he's seeing (I don't have FreeDOS
> on any of my machines to try), then it's a bug. Or, at least,
> an "incompatibility." Their parser appears to be testing
> incorrectly for the terminator.
>
only for a space. I'd think they'd also test for EOL (CR LF), but
I didn't see that with my testing. Auric__ said he saw that with
his testing using VMWare.
RP
R.Wieser
Dec 16, 2012, 6:00:04 PM12/16/12
to
Hello Rod,
> If there was no difference or bug in FreeDOS versus MS-DOS,
> then I'd think that a bug in HIMEMX couldn't be triggered. True?
Absolutily true, and also a very wrong stance at the same time. :-\
If FreeDos sticks to the (not too exactly defined) rules about executing
programs it retrieved from the config.sys, and the executed program only
regards a subset of those rules (as used by another OS) than who's to blame
? Mind you, there are several possibilities I can think of to how such a
program could fail to sucessfully parse its own arguments.
I would suggest to check if more alike programs fail to successfully run,
and postpone your findings about who is to blame to when you have those
results. Also a disassembly of the affected program might be in order, to
determine how-and-why it exactly fails.
Regards,
Rudy Wieser
-- Origional message:
> If there was no difference or bug in FreeDOS versus MS-DOS,
> then I'd think that a bug in HIMEMX couldn't be triggered. True?
If FreeDos sticks to the (not too exactly defined) rules about executing
programs it retrieved from the config.sys, and the executed program only
regards a subset of those rules (as used by another OS) than who's to blame
? Mind you, there are several possibilities I can think of to how such a
program could fail to sucessfully parse its own arguments.
I would suggest to check if more alike programs fail to successfully run,
and postpone your findings about who is to blame to when you have those
results. Also a disassembly of the affected program might be in order, to
determine how-and-why it exactly fails.
Regards,
Rudy Wieser
-- Origional message:
Rod Pemberton <do_no...@notemailnotz.cnm> schreef in berichtnieuws
kalebq$u56$1...@speranza.aioe.org...
Bill Leary
Dec 16, 2012, 8:42:38 PM12/16/12
to
"Sjouke Burry" wrote in message
news:XnsA12BBA9152C6Csj...@213.75.12.10...
> "Bill Leary" <Bill_...@msn.com> wrote in
>> Only if what follows is alphanumeric (or an alphanumeric stand-in,
>> like * or ?). For example, "DIR/W" displays a wide directory, just as
>> it should. I just tried it on both my MSDOS 3.3 machine and in the
>> command prompt of Windows 7. And "DIR *.EXE" works, but "DIR*.EXE"
>> doesn't because * is a wildcard for alphanumeric.
>>
>> However, that's not relevant here since he's talking about CONFIG.SYS.
>> Again, on my MSDOS 3.3 machine my CONFIG.SYS "DEVICE" lines all have
>> the "=" immediately after the "DEVICE". In fact, there are no spaces
>> at all in the CONFIG.SYS file on this machine.
>>
>> If he's seeing what he thinks he's seeing (I don't have FreeDOS on any
>> of my machines to try), then it's a bug. Or, at least, an
>> "incompatibility." Their parser appears to be testing incorrectly for
>> the terminator.
>
>> like * or ?). For example, "DIR/W" displays a wide directory, just as
>> it should. I just tried it on both my MSDOS 3.3 machine and in the
>> command prompt of Windows 7. And "DIR *.EXE" works, but "DIR*.EXE"
>> doesn't because * is a wildcard for alphanumeric.
>>
>> However, that's not relevant here since he's talking about CONFIG.SYS.
>> Again, on my MSDOS 3.3 machine my CONFIG.SYS "DEVICE" lines all have
>> the "=" immediately after the "DEVICE". In fact, there are no spaces
>> at all in the CONFIG.SYS file on this machine.
>>
>> If he's seeing what he thinks he's seeing (I don't have FreeDOS on any
>> of my machines to try), then it's a bug. Or, at least, an
>> "incompatibility." Their parser appears to be testing incorrectly for
>> the terminator.
>
> Internal commands behave differently from physical programs.
> Both your examples are internal.
Have you actually tried this?
> Both your examples are internal.
I *GAVE* examples that were easy to demonstrate. I *TRIED* both.
For example, "CHKDSK/F" works exactly the the same way "CHKDSK /F" does.
And it's *STILL* irrelevant because he's talking about CONFIG.SYS, and he's
correct* that FreeDOS does not work as MS-DOS does.
- Bill
- - - -
* Assuming his examples are correct. Again, I don't have FreeDOS and am
unable to replicate his experience.
Richard Bonner
Dec 18, 2012, 10:30:56 AM12/18/12
to
Rod Pemberton (do_no...@notemailnotz.cnm) wrote:
> "R.Wieser" <add...@not.available> wrote in message
> news:50ce0ccf$0$6855$e4fe...@news2.news.xs4all.nl...
> > > "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:...
> ...
> > > Unfortunately, the need for a space is required whether the
> > > DEVICE= line has parameters or not ...
> >
> > If that is caused by the config.sys parser I would definitily
> > call it buggy.
> >
> > But have you already thought of the posibility that the HIMEMX
> > program itself is at fault here ? That it does not understand
> > the way it gets executed from within the booting OS (as
> > opposed from the command-line) ?
> >
> It could be.
> However, the DEVICE= line works correctly for MS-DOS (v7.10). To
> me, that implies that FreeDOS is doing something different.
>
> Rod Pemberton
> "R.Wieser" <add...@not.available> wrote in message
> news:50ce0ccf$0$6855$e4fe...@news2.news.xs4all.nl...
> > > "Rod Pemberton" <do_no...@notemailnotz.cnm> wrote:...
> ...
> > > Unfortunately, the need for a space is required whether the
> > > DEVICE= line has parameters or not ...
> >
> > If that is caused by the config.sys parser I would definitily
> > call it buggy.
> >
> > But have you already thought of the posibility that the HIMEMX
> > program itself is at fault here ? That it does not understand
> > the way it gets executed from within the booting OS (as
> > opposed from the command-line) ?
> >
> It could be.
> However, the DEVICE= line works correctly for MS-DOS (v7.10). To
> me, that implies that FreeDOS is doing something different.
>
*** My experience with FreeDOS is that it does do things
differently.
What about other DEVICE lines? Will FreeDOS load other drivers in the
configuration:
DEVICE=path\driver.exe
In all my experience with MS and DR DOS CONFIG.sys versions, DEVICE
lines never required spaces except for switch parameters.
--
Richard Bonner
http://www.chebucto.ca/~ak621/DOS/
Richard Bonner
Dec 18, 2012, 10:35:28 AM12/18/12
to
Rod Pemberton (do_no...@notemailnotz.cnm) wrote:
> Most DOS editorstrim the final spaces from the end-of-line. I'd think
*** I use MS-DOS EDIT (Version 2.0.026) for my configuration files and
it leaves a space at the end of a line if I include one.
> Most DOS editorstrim the final spaces from the end-of-line. I'd think
> that anyone familiar with DOS would know that or should.
>
> Rod Pemberton
>
*** I use MS-DOS EDIT (Version 2.0.026) for my configuration files and
it leaves a space at the end of a line if I include one.
0 new messages