Hello tom ehlert,
On at 2022-08-01 15:11 +0200, tom ehlert wrote:
> Hallo Herr C. Masloch,
> am Sonntag, 31. Juli 2022 um 22:25 schrieben Sie:
I would appreciate if you did not refer to me wrongly.
>> On at 2022-07-31 15:49 +0800, TK Chia wrote:
>>> Hello Jerome,
>>>
> Generally, I would no
On at 2022-07-31 22:44 +0200, Eric Auer wrote:
Hi!
(I started looking into it to support loading lDebug in device-driver
mode using DEVLOAD, which requires an allocation to the device that's
larger than 64 KiB. I uploaded my experimental patch [1] ...
However, I believe that DEVLOAD will no
> at least after
> test.bat
>devload ansitest.com
>CTTY NUL
>CTTY CON
> ansitest reports
>ANSI detected
> of course DEVLOAD could borrow the code from CTTY.
> but: how can DEVLOAD detect that STDIN is indeed CON, and not COM1
in addition: after exiting from DEVLOAD, the next
Hallo Herr C. Masloch,
am Sonntag, 31. Juli 2022 um 22:25 schrieben Sie:
> On at 2022-07-31 15:49 +0800, TK Chia wrote:
>> Hello Jerome,
>>
Generally, I would not include an attachment. However, this is a
tiny zip and includes the test source, build scripts and the compiled
versi
Hi!
(I started looking into it to support loading lDebug in device-driver
mode using DEVLOAD, which requires an allocation to the device that's
larger than 64 KiB. I uploaded my experimental patch [1] ...
However, I believe that DEVLOAD will not re-open the file handles held
by existing pr
On at 2022-07-31 15:49 +0800, TK Chia wrote:
Hello Jerome,
Generally, I would not include an attachment. However, this is a
tiny zip and includes the test source, build scripts and the compiled
version.
Well... I found that your ansitest.com still works with the FreeDOS 1.3
kernel + nansi.sy
Hi,
> On Jul 31, 2022, at 5:46 AM, tom ehlert wrote:
>
>
>> interesting find. did you try any of the alternatives DRVLOAD, DEVLOD,
>> DDL ...
>
> a compilation of devload, drvload, loadsys
> http://toogam.com/software/archive/drivers/dosstart/dosstart.zip
>
> Tom
Ok, this is interesting….
I
Hi,
> On Jul 31, 2022, at 3:49 AM, TK Chia wrote:
>
> Hello Jerome,
>
>>> Generally, I would not include an attachment. However, this is a
>>> tiny zip and includes the test source, build scripts and the compiled
>>> version.
>
> Well... I found that your ansitest.com still works with the Fre
> interesting find. did you try any of the alternatives DRVLOAD, DEVLOD,
> DDL ...
a compilation of devload, drvload, loadsys
http://toogam.com/software/archive/drivers/dosstart/dosstart.zip
Tom
___
Freedos-devel mailing list
Freedos-devel@lists.so
Hello TK Chia,
> Are you using devload.com to load the nansi.sys driver? If so, this
> might explain the failure. I found that if I use devload.com --- rather
> than load the driver through fdconfig.sys --- then for some reason
> nansi.sys's input handling routines are not triggered, and there
Hello Jerome,
Generally, I would not include an attachment. However, this is a
tiny zip and includes the test source, build scripts and the compiled version.
Well... I found that your ansitest.com still works with the FreeDOS 1.3
kernel + nansi.sys 4.0d. (I.e. there was no regression between
> Well to simplify matters, I ported the test to a simple NASM
> program. It displays Supported or Not and returns errorlevel 1 if not found.
> I did a quick check on the PentiumPro under MS-DOS 6.22 + ANSI.SYS, it says
> supported.
> Rebooted the PentiumPro under FreeDOS 1.3 + NANSI.SYS, it s
Hi again,
> On Jul 30, 2022, at 4:51 PM, Jerome Shidel wrote:
>
> Hi,
>
>> On Jul 30, 2022, at 3:03 PM, TK Chia wrote:
I just created a boot floppy with 1.3’s Kernel, Command, NANSI and the Test
program.
Loaded Command and NANSI to low memory with nothing else in the CONFIG.SYS and
nothin
Hi,
> On Jul 30, 2022, at 3:03 PM, TK Chia wrote:
>
> Hello Jerome,
>
>> The test works correctly under at least the most recent versions of MS-DOS
>> (6.x), PC-DOS and DR-DOS.
>
> Thanks. Well, I could not reproduce whatever failure you were getting
> with your routine under FreeDOS. Witho
Hello Jerome,
The test works correctly under at least the most recent versions of MS-DOS
(6.x), PC-DOS and DR-DOS.
Thanks. Well, I could not reproduce whatever failure you were getting
with your routine under FreeDOS. Without more information, it seems
there is no good way to tell what exac
HI,
> On Jul 30, 2022, at 2:15 AM, TK Chia wrote:
>
> Hello Ralf Quint,
>
>> Well, not having comments to understand what you are doing is pretty
>> tough when you don't have the time to analyze the code line by line. But
>> IIRC, the common way to check for the presence of an ANSI device drive
Hello Ralf Quint,
Well, not having comments to understand what you are doing is pretty
tough when you don't have the time to analyze the code line by line. But
IIRC, the common way to check for the presence of an ANSI device driver
was to check via an INT 2Fh (multiplexer) call (don't recall the
On 7/29/2022 11:44 AM, Steve Nickolas wrote:
On Fri, 29 Jul 2022, Ralf Quint wrote:
Well, not having comments to understand what you are doing is pretty
tough when you don't have the time to analyze the code line by line.
But IIRC, the common way to check for the presence of an ANSI device
dr
>> But IIRC, the common way to check for the presence of an ANSI
>> device driver was to check via an INT 2Fh (multiplexer) call (don't
>> recall the exact call value (AX/AH)).
...
> I remember when Eric Auer added it to NANSI, so it should support
> it:
>
> * https://docs.huihoo.com/help-pc/int-
Hi,
On Fri, Jul 29, 2022 at 1:45 PM Steve Nickolas wrote:
>
> On Fri, 29 Jul 2022, Ralf Quint wrote:
>
> > But IIRC, the common way to check for the presence of an ANSI device driver
>> was to check via an INT 2Fh (multiplexer) call (don't recall the exact call
>> value
> > (AX/AH)).
>
> That wo
On Fri, 29 Jul 2022, Ralf Quint wrote:
Well, not having comments to understand what you are doing is pretty tough
when you don't have the time to analyze the code line by line. But IIRC, the
common way to check for the presence of an ANSI device driver was to check
via an INT 2Fh (multiplexer)
FWIW, here's the code I use to test whether or not ANSI.SYS is loaded.
;---
;Strings need to test for ANSI.SYS
;---
TestMsg:
DB CR ;String to test A
> It seems to me that your checking code currently relies on certain very
> specific assumptions about how the ansi.sys driver behaves (e.g. that
> the driver immediately spits out an ESC [ y ; x R sequence with no delay
> whatsoever).
this very specific assumption is fair to make about ansi.sys
Well, not having comments to understand what you are doing is pretty
tough when you don't have the time to analyze the code line by line. But
IIRC, the common way to check for the presence of an ANSI device driver
was to check via an INT 2Fh (multiplexer) call (don't recall the exact
call value
Hello Jerome,
Basically, one of the versions of my ancient (written back in the early 90’s)
Turbo Pascal directory listing programs used ANSI escape sequences to provide
color. Instead of blindly assuming ANSI support is present, it first probes DOS
to verify the functionality. It performs th
Hi All,
While recently performing a re-install of everything (System Commander Multiple
DOS, Windows, Linux booting) on my Pentium Pro, I discovered a minor
compatibility issue regarding ANSI.SYS support. Without digging into it more, I
cannot say if the issue is NANSI.SYS or elsewhere in Free
26 matches
Mail list logo
