The FreeDOS Project

g0rheb <a href="http://txnmovhkhazy.com/">txnmovhkhazy</a>,
[url=http://mipxpnkgozix.com/]mipxpnkgozix[/url],
[link=http://bfdhljxkrmud.com/]bfdhljxkrmud[/link],
http://eslhsebqzzmc.com/

Hi

> aware of the excessive blinking of the mouse when in EDIT,
> and I don't like it either.

Seems to be related to the cursor colorization/hiding and causes the
almost complete vanish is some cases (i have 2 "evil" PC's now ...).

> progress to add the DFlat+ 1.1 features in subsequent (less
> stable) versions of Edit (from 0.9c till 1.0), and this of
> the blinking will be one of those. Keep please tuned to the
> freedos-devel list to find out exactly in which version
> whe excessive blinking will be reworked.

Thanks. Please continue ... I'll report ASA I notice an effect or fix.

Hello,

The changes made to video.c or the like do NOT affect the behaviour, but
rather where in source the call is made. So anything strange that may be
found there should be in previous versions (unless I did something wrong).
For this edition I didn't review the "semantics" of the code, but rather
the placement of the lines.

I am aware of the excessive blinking of the mouse when in EDIT, and I
don't like it either. It is one of the (many) features planned for the
DFlat+ version 1.1, but it is priorized as it should be, and of course
under bug-fixing.

There will be (shortly) a DFlat+ 1.0.1 version (and thus Edit 0.9b) fixing
some bugs, but this "feature" of excessive blinking will not be one of
those. I will progress to add the DFlat+ 1.1 features in subsequent (less
stable) versions of Edit (from 0.9c till 1.0), and this of the blinking
will be one of those. Keep please tuned to the freedos-devel list to find
out exactly in which version whe excessive blinking will be reworked.

Finally, there is not a misinterest in real machines/hardware. It's simply
that most of the work is being done under NTVDM or virtualizators simply
because it is simply easier to debug and recover from a crash. Tests in
real machines are also done.

Regards,
Aitor

I wrote:

> > Waits for the beginning of a vertical ("big") retrace, to avoid
flicker.
> Cause problems ?

Bad guess, heh :-( Disabled, no effect :-( Trying to disable
"hide_mousecursor();" but seems to compile to something strange ....

Feel free to reclose and be be assured that I won't re-open or re-report
this anymore, considering the eclatant overall lack of interest
(devel/test/document) on DOS and even more lack of existence of DOS running
__NOT__ inside of DOGBOX/DOGEMU/NTVDM and similar faked stuff.

aitorsm wrote:

> Happy Edit'ing, and bug reporting!

Tried to ...

> In the discussion at bttr-software, it is shown to be a BIOS-specific
bug.

It isn't shown. It is suspected at best, and no details about what BIOS
might do wrong.

> Unreproducable

FYI, found one more PC exposing it, and what's worse, even the "good" PC's
where the cursor is visible have minor problems of this type: cursor
blinking too much, and completely vanishing in a small area of the screen
(horizontal line cca 20 chars).

> and do not have news from someone else to suffer from the same bug.

Nor from anyone about using FD EDIT 0.9 successfully (on DOS ???) ...

> Therefore, closed as NOT-A-BUG.

COOL.

> I do much FreeDOS programming on NTVDM

I see ...

> so I was trying to guess how much the impact on me will be.
> my interest on DOSBOX and such programs increases

Not much impact anymore: Use with real hardware at own risk ...

BTW, the bug isn't in MOUSE.C, since this remained in fact
unchanged, but VIDEO.C is a good candidate:

> hide_mousecursor();
> show_mousecursor();

Bad usage ?

> Waits for the beginning of a vertical ("big") retrace, to avoid flicker.


Cause problems ?

> if (SysConfig.VideoSnowyFlag)
> waitforretrace();

Wait only if snowed ??? Maybe the bug was already available in 0.7D but
disabled together with the snow ?

In the discussion at bttr-software, it is shown to be a BIOS-specific bug.
Unreproducable, and do not have news from someone else to suffer from the
same bug.

Therefore, closed as NOT-A-BUG.

In the discussion at bttr-software, it is shown to be a BIOS-specific bug.
Unreproducable, and do not have news from someone else to suffer from the
same bug.

Therefore, closed as NOT-A-BUG.