Michael Devore wrote:
> At 02:50 PM 8/21/2006 -0600, Eddie wrote:
>
>>I was really hoping that this problem had been silently fixed by
>>all of the other work that has been done recently.
>
> Doesn't look VDS-related, the executable only uses a couple of common calls
> there. Not much mor
At 02:50 PM 8/21/2006 -0600, Eddie wrote:
>I was really hoping that this problem had been silently fixed by
>all of the other work that has been done recently.
Doesn't look VDS-related, the executable only uses a couple of common calls
there. Not much more I can tell you. Maybe the origina
At 02:50 PM 8/21/2006 -0600, Eddie wrote:
> I was really hoping that this problem had been silently fixed by
>all of the other work that has been done recently. I was disappointed
>when the same problem cropped up again - because that means more work.
>
>So far I haven't done the work to iso
Aitor Santamar?a wrote:
>2006/8/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>> This problem occurs when using SMARTDRV.EXE (with write caching
>> enabled) from MSDOS 6.22 with FreeDOS. Replacing either avoids the
>> problem.
>
>Well, thanks indeed for the reports, perhaps you could tell us too if
At 05:15 AM 8/21/2006 -0600, [EMAIL PROTECTED] wrote:
>This problem occurs when using SMARTDRV.EXE (with write caching
>enabled) from MSDOS 6.22 with FreeDOS. Replacing either avoids the
>problem.
SMARTDRV is pretty particular on some machines. I just pulled the
following from the Microsof
Hi Eddie,
2006/8/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> This problem occurs when using SMARTDRV.EXE (with write caching
> enabled) from MSDOS 6.22 with FreeDOS. Replacing either avoids the
> problem.
Well, thanks indeed for the reports, perhaps you could tell us too if
you're using EMM38
This problem occurs when using SMARTDRV.EXE (with write caching
enabled) from MSDOS 6.22 with FreeDOS. Replacing either avoids the
problem.
I haven't pinned it down yet but the problem seems to occur with
more than just one pgm. I've seen it when installing UKA17X2 (i.e.
UKA_PPP), A189GPL