Re: [Freedos-user] after

2017-05-06 Thread BLAMETROI
From: BlameTroi Eric, >> C:\ELVIS\DOC>find /i "env" e*.htm >> file list ... >> Error reading from drive A: DOS area: general failure > > Does the same bug happen with find /i "env" C:e*.htm > and with find /i "env" C:\elvis\doc\e*.htm by the way? Yes it does. I've

Re: [Freedos-user] after

2017-05-06 Thread ERIC AUER
From: Eric Auer Hi Troi, > C:\ELVIS\DOC>find /i "env" e*.htm > file list ... > Error reading from drive A: DOS area: general failure You mean it FIRST checks all files in the current directory on C: but THEN tries to jump to the A: drive? That sounds like a bug in the

[Freedos-user] after find

2017-05-06 Thread BLAMETROI
From: BlameTroi I'm curious as to why FreeDOS is trying to read a:. I've built a VM in VirtualBox and most things work well, but while digging around looking for information, I got this after a FIND command. C:\ELVIS\DOC>find /i "env" e*.htm . file list ... Error

Re: [Freedos-user] after

2017-05-06 Thread TOM EHLERT
From: Tom Ehlert I could reproduce this. it happens in/after findnext() this error is related to the compiler. if the source is compiled using TurboC 2.01 the error occures. compiling the exact same source with TCPP the error is gone. try

Re: [Freedos-user] after

2017-05-06 Thread BLAMETROI
From: BlameTroi Eric, In the three cases (mine and your two suggestions) if DOSLFN is loaded and enabled, there is no sign of a problem. If DOSLFN is not loaded, I get the error. If DOSLFN has been loaded, but I disable it (DOSLFN /D), the error returns. So, DOSLFN seems

Re: [Freedos-user] after

2017-05-06 Thread ERIC AUER
From: Eric Auer Hi Rugxulo and Troi, >> It could be a rare kernel bug, but my guess is some buffer overflow in the >> IO95 lib. I think this problem is hidden by enabling DOSLFN. > > Yes indeed that did either mask or "fix" the problem. Thanks. In that case please tell in

Re: [Freedos-user] after

2017-01-18 Thread Tom Ehlert
Originally to: ALL I could reproduce this. it happens in/after findnext() this error is related to the compiler. if the source is compiled using TurboC 2.01 the error occures. compiling the exact same source with TCPP the error is gone. try www.drivesnapshot.de/freedos/findtcpp.com and

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-17 Thread Tom Ehlert
I could reproduce this. it happens in/after findnext() this error is related to the compiler. if the source is compiled using TurboC 2.01 the error occures. compiling the exact same source with TCPP the error is gone. try www.drivesnapshot.de/freedos/findtcpp.com and

Re: [Freedos-user] after

2017-01-17 Thread Eric Auer
Originally to: ALL Hi Troi, > C:\ELVIS\DOC>find /i "env" e*.htm > file list ... > Error reading from drive A: DOS area: general failure You mean it FIRST checks all files in the current directory on C: but THEN tries to jump to the A: drive? That sounds like a bug in the kernel, either

[Freedos-user] after find

2017-01-17 Thread BlameTroi
Originally to: ALL I'm curious as to why FreeDOS is trying to read a:. I've built a VM in VirtualBox and most things work well, but while digging around looking for information, I got this after a FIND command. C:\ELVIS\DOC>find /i "env" e*.htm file list ... Error reading from drive A: DOS

Re: [Freedos-user] after

2017-01-17 Thread BlameTroi
Originally to: ALL Eric, >> C:\ELVIS\DOC>find /i "env" e*.htm >> file list ... >> Error reading from drive A: DOS area: general failure > > Does the same bug happen with find /i "env" C:e*.htm > and with find /i "env" C:\elvis\doc\e*.htm by the way? Yes it does. I've seen a few posts and

Re: [Freedos-user] after

2017-01-17 Thread BlameTroi
Originally to: ALL Eric, In the three cases (mine and your two suggestions) if DOSLFN is loaded and enabled, there is no sign of a problem. If DOSLFN is not loaded, I get the error. If DOSLFN has been loaded, but I disable it (DOSLFN /D), the error returns. So, DOSLFN seems to "fix" the

Re: [Freedos-user] after

2017-01-17 Thread Eric Auer
Originally to: ALL Hi Rugxulo and Troi, >> It could be a rare kernel bug, but my guess is some buffer overflow in the >> IO95 lib. I think this problem is hidden by enabling DOSLFN. > > Yes indeed that did either mask or "fix" the problem. Thanks. In that case please tell in which situations

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread BlameTroi
Eric, In the three cases (mine and your two suggestions) if DOSLFN is loaded and enabled, there is no sign of a problem. If DOSLFN is not loaded, I get the error. If DOSLFN has been loaded, but I disable it (DOSLFN /D), the error returns. So, DOSLFN seems to "fix" the problem, at least from a

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread Eric Auer
Hi Rugxulo and Troi, >> It could be a rare kernel bug, but my guess is some buffer overflow in the >> IO95 lib. I think this problem is hidden by enabling DOSLFN. > > Yes indeed that did either mask or "fix" the problem. Thanks. In that case please tell in which situations the bug does happen

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread BlameTroi
> It could be a rare kernel bug, but my guess is some buffer overflow in the > IO95 lib. I think this problem is hidden by enabling DOSLFN. Yes indeed that did either mask or "fix" the problem. Thanks. > But I personally just avoid Find and use Xgrep instead. I probably will too as I learn what

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread BlameTroi
Eric, >> C:\ELVIS\DOC>find /i "env" e*.htm >> file list ... >> Error reading from drive A: DOS area: general failure > > Does the same bug happen with find /i "env" C:e*.htm > and with find /i "env" C:\elvis\doc\e*.htm by the way? Yes it does. I've seen a few posts and such that sound

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread Rugxulo
Hi, On Jan 16, 2017 11:24 AM, "Eric Auer" wrote: > > > C:\ELVIS\DOC>find /i "env" e*.htm > > file list ... > > Error reading from drive A: DOS area: general failure > > You mean it FIRST checks all files in the current > directory on C: but THEN tries to jump to the A: >

Re: [Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread Eric Auer
Hi Troi, > C:\ELVIS\DOC>find /i "env" e*.htm > file list ... > Error reading from drive A: DOS area: general failure You mean it FIRST checks all files in the current directory on C: but THEN tries to jump to the A: drive? That sounds like a bug in the kernel, either in the drive status

[Freedos-user] after find, Error reading from drive A: DOS area: general failure.

2017-01-16 Thread BlameTroi
I'm curious as to why FreeDOS is trying to read a:. I've built a VM in VirtualBox and most things work well, but while digging around looking for information, I got this after a FIND command. C:\ELVIS\DOC>find /i "env" e*.htm file list ... Error reading from drive A: DOS area: general

Re: [Freedos-user] after fdos boot : Kick!

2004-09-21 Thread BWMarcotte
Hi Markus, no, since i get kick! like i turn the pc on and get kick! doesn't even try to access the fdd or the hdd i think this kick! is stored somewhere now in a battery buffered area, like even if i remove the power plug and then turn it on again, it goes STRAIGT to kick doesn't show me

Re: [Freedos-user] after fdos boot : Kick!

2004-09-21 Thread markus
Hi doesn't work to. see above :) I have run into a problem similar to this problem on my Thinkpad - the system was refusing to reboot and the power button was putting the system into suspend mode. My fix was to remove the battery from the laptop for 60 seconds then put the battery back

Re: [Freedos-user] after fdos boot : Kick!

2004-09-20 Thread markus
hi this is Eric Auer's MetaKern bootloader that is being used. Option 1 is 386-specific, Option 2 is to boot the FreeDOS which is on the diskette. yup, something like this :) There it prints KICK! and then expects to find KERNEL.SYS are you sure KERNEL.SYS file is present on that