windows defender issues? & other AV issues?

Richard Gaskin ambassador at
Mon Jan 7 22:55:38 EST 2019

Curry, I haven't questioned your findings in the report.  On the 
contrary, I confirmed them.

We don't disagree on observable data.

We merely differ on focus:

Few of my customers use the LC Script Editor, so they don't care about 
it. But they do use the software that we ship to them.

And since we can find many stories about this in apps other than LC, 
like those I found with the DuckDuckGo search I did the other day, the 
element from the many forum posts on this that caught my attention was 
that every one of them who replied back said that turning off RTP was a 
satisfying result.

That got me focused on the AV aspect of this, when Tom started this 
thread looking at AV issues.

As for the SE, I share the interest but not the concern.  Milby's 
looking at the prefs angle, Mark Waddingham is already working on 
arrays, so both on-disk and in-memory optimizations are under way; that 
much is in the can.  #21604 is indeed a good report, helpful on both 
sides. It'll be closed soon, so now I'm free to consider the part of his 
discovery that impacts what we ourselves ship:

How many devs among us are shipping apps which rely on frequent disk saves?

Are you seeing a difference with the impact of RTP on vs off?

This will definitely prompt me to spend more time testing on Windows...

  Richard Gaskin
  Fourth World Systems

> Richard:
>  > But writing files - damn! Now I understand what the reporters
>  > in the forums have been talking about.
> LOL, great test to verify the impact, but it incredibly closely follows 
> my documented prediction on Dec 12:
>  > A relevant question on our side of the equation is whether LC
>  > is constantly accessing file(s) while we type or make selections
>  > in script editor and if so, the wisdom of and necessity for such
>  > an approach. I wouldn't recommend it because it's unnecessary
>  > and prone to trouble. (If it turns out LC is not doing that,
>  > sorry - my assumption, based on antivirus getting into the picture.)
> And supporting all my remarks today regarding my theory that the cause 
> of the issue was actions taken by SE/IDE to open up merely typing to AV, 
> something we would not expect ideally, AND also the performance perk 
> that might be a side effect for all cases, if that theory was correct.
> Richard:
>  > I honestly don't have the quick-fix answer that will keep
>  > our customers happy with disk-intensive apps.
>  > Sugggestions?
> Hmmm...since this all based on my seemingly correct predictions (?) 
> without crediting them and while simultaneously having made inaccurate 
> accusations against me (weird) how about what I suggested today:
>  > Per common sense and best coding practices, the actions taken
>  > by the IDE while we are merely typing and selecting text
>  > ideally should not open the doors to get AntiVirus products
>  > involved continually.
> Just as I suggested before in the bug report. There is no need for ANY 
> typing window to CONSTANTLY access an outside file. The most 
> time-crucial parts should either be moved to memory or be done with care 
> and timed appopriately. If that turns out to be the issue, I was right 
> all along despite the your late hysterics.
> Naturally what goes for the IDE can also be used just as well for any 
> app, to continue quoting myself today.
>  > Actions that may get vetted by AV, or that may use
>  > greater system resources, need to be considered carefully
>  > in terms of approach, timing, and responsiveness.
> Pretty obvious - I've known for 20 years not to constantly access files 
> while typing, and to space out disk reads and writes appropriately. And 
> I've seen and helped repair similar issues for users. Always minimize 
> file usage, time it appropriately, not per second or N times per second 
> when someone is typing, or during animation for that matter, since we're 
> talking about apps made with LC. Pretty basic coding technique indeed.
> How about those "Good Coding Habits 101" suggestions from myself? :D
> Like my motto: Good methods, good habits, good results! Now potentially 
> applicable to the IDE itself, something I've taken a lot of heat for 
> suggesting.
> Best wishes,
> Curry Kenworthy
> Custom Software Development
> "Better Methods, Better Results"
> LiveCode Training and Consulting

More information about the Use-livecode mailing list