Re: windows defender issues? & other AV issues

[Richard Gaskin via use-livecode]

Matthias Rebbe wrote:

>> Am 17.01.2019 um 17:08 schrieb Richard Gaskin:
>>
>> R.H. wrote:
>> > I just feel that we should know what the problem is that corrupts
>> > the stack when saving and the original stack filename is appended
>> > with the tilde character?
>>
>> Agreed.  If the engine has a problem writing stack files, that would
> prevent us from using LiveCode.
>>
>> The trick now is to pin down the cause of the issue you've
> experienced.
>
> Maybe it would be good at first to know how big in size the stack is
> that cannot be saved correctly.
> Maybe it is really the size that cause this.

I believe the logical limit is 4GB, so I don't think size alone is the 
cause.


Complexity might be related, such as number of cards, but even then I 
have doubts.


I used to maintain an alternative LC Dictionary in which every language 
token was its own card - more than 3,000 at the time.  While saves would 
take several seconds, it didn't matter for that stack since that only 
happened once at build time; from then on it was used only for reads. 
Worked like a champ, successfully built on more than a hundred different 
system an aggregate of many thousands of times.


So far we have a few people (3?) who've reported issues with saves, in 
which all of the save issues, IIRC, were intermittent.


Meanwhile, the one thing all subscribers of this list have in common is 
that we use LiveCode, implying that we're able to use LiveCode because 
we can save our work.


So it seems there is something specific to a combination of factors, 
some possibly related to the engine, others possibly related to disk 
media and/or file system structures, and some possibly related to the OS 
or other processes.


Without a recipe for reliably reproducing the issue, this will be a 
tough nut to crack.


Hopefully as we gather more details a recipe will emerge.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Matthias Rebbe via use-livecode]

> Am 17.01.2019 um 17:08 schrieb Richard Gaskin via use-livecode 
> :
> 
> R.H. wrote:
> 
> > I just feel that we should know what the problem is that corrupts the
> > stack when saving and the original stack filename is appended with the
> > tilde character?
> 
> Agreed.  If the engine has a problem writing stack files, that would prevent 
> us from using LiveCode.
> 
> The trick now is to pin down the cause of the issue you've experienced.
> 

Maybe it would be good at first to know how big in size the stack is that 
cannot be saved correctly.
Maybe it is really the size that cause this. 


> 



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Richard Gaskin via use-livecode]

R.H. wrote:

> I just feel that we should know what the problem is that corrupts the
> stack when saving and the original stack filename is appended with the
> tilde character?

Agreed.  If the engine has a problem writing stack files, that would 
prevent us from using LiveCode.


The trick now is to pin down the cause of the issue you've experienced.

Since we don't see many reports here of errant stack saves, it seems 
this will require some sleuthing to pin down the specific combination of 
factors at play.



> Is there any way to detect and catch an error when saving?

All I/O, whether socket or disk, whether stack files or any other 
format, is ideally accompanied by error-checking, e.g.:


  save stack tStackFilePath
  if the result is not empty then
 answer "Couldn't save document ("& sysError() &")"
 exit to top
  end if

The sysError function is especially useful there, delivering the error 
number the OS provides to describe the specific reason the file could 
not be written.



> Saving either from the IDE or saving the compiled in any case (with or
> without corruption) takes way too long time. My tests disabling
> Windows Defender did not change this...

How much is "too long time", and what's in the file?

The number of cards may be particularly relevant for save time, perhaps 
number of substacks if there are many.  File size when written 
successfully would be good know too.



> And I can not ask clients to disable Windows Defender or change the
> Defender settings anyway. I have no control over such machines and
> it is a big company with some users using my app. They are mostly
> illiterate even to open Windows Defender or they are not permitted
> to change any settings.

I'm with you, very disinclined to encourage users to turn off built-in 
security features.


I haven't done more research on this in weeks, but back when I did the 
many other apps affected by this were of such a broad variety no clear 
pattern was self-evident to me which would explain how LC could be among 
them.


As time permits I may do some more reading around the web to see how 
other vendors are coping with this.



> But generally said, I would also prefer to go with a proper
> installation tool, read from and write to files in the AppData or
> Documents directory

More than OS-recommended practice, often essential.  All user data 
should be in user space.



> A stack is just not a good database solution if data is well
> structured and there is a lot of data.

Agreed.  If you need a DB you should use a DB, which will have its own 
binary file format(s).  (But of course then the question is which type 
of DB: relational, document store, graph, or something else?)


There are almost as many file formats as their are document-producing 
applications. No singe file format can accommodate all possible types of 
apps, so we use the format best suited for the type of app we're making.



The bad thing about file formats is that there is no one-size-fits-all 
solution, so we have to make choices about what's best for the task at hand.


The great thing about file formats is that there is no one-size-fits-all 
solution, so we get to make choices about what's best for the task at hand.


:)

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Bob Sneidar via use-livecode]

Right. The splash stack actually becomes an executable when saved as a 
standalone. Executables by nature cannot be modified. This is one of the 
reasons a splash stack approach makes a lot of sense, because now all your 
attacked stacks/substacks CAN be modified (given they are in a location the OS 
allows it and the end user has write permissions to that location.) 

Bob S


> On Jan 16, 2019, at 11:50 , R.H. via use-livecode 
>  wrote:
> 
> Windows: Regarding the many replies to the question of allowing saving a
> stack file I would like to thank everybody for the answers by Matthias,
> Bob, Alex, Jacqueline, JJS ...
> 
> The problem was that a stack file used by a compiled splash stack does not
> save on some client's computers with Windows systems >= 7 and can only be
> run once leaving an unsaved file that is renamed with a tilde character.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Richard Gaskin via use-livecode]

Lagi Pittas wrote:

> A POS system that I wrote saved a few arrays and text on exit. It
> worked beautifully in  99.9% % of the time but every so often the
> user would start up and the file was corrupted some how - I  saw
> the tilde file (exactly as word does (used to do it?), when view
> extensions for known file type was enabled in windows.

Yes, that's one of the things I've enjoyed about using stack files for 
storage, the engine's automatic safe-write procedure that makes a backup 
of the old file before writing the new one.


Of course we could script our own routines to do that, but I don't mind 
a little convenience now and then.


Imagine how much worse those users would be without that safe-write.

> In the end I just created another table in the sqlite database and
> saved the encoded  arrays in there - never a problem since.

Did you ever find out why the engine was having difficulty writing those 
files?


What did "the result" show?

Beyond the implications for end-users is for all of us: if there's a bug 
that prevents writing stack files under certain circumstances, it will 
prevent us from using LiveCode under those circumstances.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Mark Waddingham via use-livecode]

On 2019-01-17 16:15, R.H. via use-livecode wrote:

Is there any way to detect and catch an error when saving?


When the engine saves a stackfile when it has previously been saved to 
the same place...


It first moves the existing file at  to ~. If this 
step fails (e.g. because it can't move the file) then the save command 
stops and returns an error indicating that in 'the result'.


Next it attempts to save the stackfile to .

If there is an error whilst writing the stackfile then the save command 
stops, deletes the partially written stackfile at , moves the 
~ back to  and returns an appropriate error in 'the 
result'.


If the engine crashes during saving, you will be left with a partially 
written  and a copy of the stackfile as it was successfully 
last saved at ~. Obviously in this case the engine has 
crashed, so there is no 'the result' to check.


If saving successfully completes, then the engine deletes ~ 
and returns empty in 'the result'.


So - assuming the engine isn't crashing (although the long save time 
sounds odd - if you can submit a report/send a stackfile which takes 
ages to re-save we can take a look!), then you should be able to find 
out why the save is failing, or not happening as expected by checking 
'the result' after the save command which is initiating the save.


Hope this helps!

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[R.H. via use-livecode]

Well, thanks for all the comments regarding failing to save the data stack
distributed with a compiled splash stack. Each case is different. In this
case, I have to actually go by my promise to not install anything on the
target machine that is not visible inside my app folder. The user can just
remove the folder and that's it - by agreement. So, that actually disallows
even storing anything else in any writable directory in this particular
case.

The data stack uses data separated from UI and data is read-only. The user
saves data to a text file. That all works well. The saving of the "data"
stack that includes the separate UI has mainly one purpose: to allow the
user starting from where he/she stopped working with the application. But
this is not crucial and I will simply not save anything. The stack will be
as is.

I just feel that we should know what the problem is that corrupts the stack
when saving and the original stack filename is appended with the tilde
character? Well, corruption is a big word here since the stack itself is
not corrupted or does not appear to be, but something is not right. It is
more a principle question now. As Curry mentioned, it happens elsewhere.

Is there any way to detect and catch an error when saving?

We are deviating a bit from the subject here which is "Windows Definer and
AV software". Still, there could be an issue related.

Saving either from the IDE or saving the compiled in any case (with or
without corruption) takes way too long time. My tests disabling Windows
Defender did not change this but I still do not rule out that there could
be something related to AV. It needs further testing, maybe also on other
machines.

And I can not ask clients to disable Windows Defender or change the
Defender settings anyway. I have no control over such machines and it is a
big company with some users using my app. They are mostly illiterate even
to open Windows Defender or they are not permitted to change any settings.

But generally said, I would also prefer to go with a proper installation
tool, read from and write to files in the AppData or Documents directory
and keep data separate from the stack -- even though if this is possible in
principle, it should not create problems also using stacks for data
storage. In many cases, it is a very simple straight-forward solution as
everything is easily accessible. A stack is just not a good database
solution if data is well structured and there is a lot of data.

Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Lagi Pittas via use-livecode]

A POS system that I wrote saved a few arrays and text on exit. It worked
beautifully in  99.9% % of the time but every so often the user would start
up and the file was corrupted some how - I  saw the tilde file (exactly as
word does (used to do it?), when view extensions for known file type was
enabled in windows.

The thing I couldn't figure was that people using it for over 2 years never
had a problem, another shop that had three of my  POS systems NEVER had a
problem there were basically at most 5-7 sites that had the problem -
rarely (once or twice a year  - then never again) but two machines were
corrupting every month or so it seemed). I checked to see if they switched
off without exiting - but I know that in 99.99% of cases you could do that
without corrupting.

All the machines run windows 7 embedded and of course I switched off
updates (if it works today it will work tomorrow - I threatened them with
death if they installed anything or used the internet on it). There was  no
rhyme or reason to the corruption, as one of the shops had 2 machines
bought at the same time and the one was corrupting consistently and the
other wasn't. In the end I just created another table in the sqlite
database and saved the encoded  arrays in there - never a problem since.
Lesson learned (by me at least) it's not worth the aggro, the coding is not
that much more involved so why bother unless it's for my  own use as I have
full control? Although I have teamviewer on each machine - talking somebody
through connecting the device to the internet after they have changed ISP
or other reasons meant too much wasted time explaining what and where a
status bar was/is

"Every time I make my program fool proof the universe comes up with a
better fool"

Lagi

On Thu, 17 Jan 2019 at 01:11, Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Curry Kenworthy wrote:
>
>  > Although it's quite possible to save data in stack file(s) if you do
>  > it properly, people who follow that route often have trouble, so I
>  > discourage it.
>
> Depends what's in the stack file.
>
> The traditional factoring of code, UI, and data became a best practice
> for good reason.
>
> But stack files can be very versatile storage containers, offering many
> of the benefits of LSON (LC encoded arrays) but with the addition of
> being able to contain LC objects as well.
>
> LSON's generally my go-to unless I have a specific need for something
> else, but once in a while stack files have been a good solution for
> storage.
>
> There are many storage formats to choose from, and stack files have a
> place among them.  For keeping with the tradition of separating code,
> UI, and data, it's not the format but how it's used.
>
> --
>   Richard Gaskin
>   Fourth World Systems
>   Software Design and Development for the Desktop, Mobile, and the Web
>   
>   ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Curry Kenworthy via use-livecode]

Thanks Richard and Jacque for the enthusiastic support of my opening 
observation:


"it's quite possible to save data in stack file(s) if you do it
properly"

Yes, that holds true. :)

But as a responsible advisor to people in the community at large, I must 
discourage stack files as first choice to save data from installed apps. 
People who follow that route often have trouble.


Not talking about any particular dry academic "best practices" that 
someone wrote, someone else read, a third parroted. Nor tradition. 
Simply real LC cases right here in our community - I find a good 
correlation between people with problems and people who save to stacks. 
Few do it properly. It's a problem here.


When people have bad habits, I actually get more business. So maybe I 
should be encouraging people to use stacks first and foremost for data 
storage, among other things! Ha ha. But there's no way I'd ever do that; 
I care about people and I want them to have fewer problems in their code.


Using stacks to save data, "It's very tempting to try and save data to 
the distribution folder, or to mix data and user interface together!" 
The medium does have some effect on the transaction and the people 
involved, also depending on what experience people are coming from.


Since stacks normally hold UI and LC code, it's a very small step to mix 
data and UI together. And that's exactly what people tend to do. From 
there, they tend to save directly to the app folder, another tiny step 
that often involves just one word of code. Not to mention a few other 
gotchas of stacks compared to other files if used wrongly. It's a quick 
route to trouble, and I've been called to rescue many a ship that was 
following that siren call


I provided a quick fix for those in that situation. And it's also 
possible to use stack files the "right" way for saving data. For that 
matter stacks can hold almost any type of data, and almost any type of 
data file can hold stacks and UI. Anything is possible.


But most people will be better served keeping these things separated for 
easy understanding and building solid habits. Stacks (or properly 
designated flat files) for UI and code, another type of file or a 
database for data. App in Program Files or Applications, data in the 
proper place per OS and purpose. A standard installer, or else even more 
care (not less) in app awareness and data handling. Sign your app if 
needed, or provide some installation FAQ for users, and be cautious 
about accessing files to minimize AV issues and system issues.


These tend to steer people in the right direction, and mixing things 
together often leads people astray. I'm sorry that's the case, it 
doesn't have to be, but often it is. Real people, real stacks; reality 
talking. Of course, stack-data aficionados that know their stuff can do 
their thing; I'm probably not reaching a ghostly hand out of your email 
Inbox to stop you. (Just make sure that it works as well as you think! 
I've seen some notable exceptions.)


So that's my PSA on data files. It's pretty much win-win-win because 
either the tip helps people and they avoid problems, or if they take 
another road and have trouble I'll likely have the chance to help them 
out later, while those who really know the ropes can feel even more 
empowered using stacks for data and piling on greater support for my 
opening observation. Take care and good night! :D


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[J. Landman Gay via use-livecode]

As you say, the file format isn't an issue. I frequently use stack files 
for storage of all kinds of things. Never had any problem with it. The 
different types of data storage provided in stack format can be very useful.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 16, 2019 7:12:58 PM Richard Gaskin via use-livecode 
 wrote:


There are many storage formats to choose from, and stack files have a
place among them.  For keeping with the tradition of separating code,
UI, and data, it's not the format but how it's used.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> Although it's quite possible to save data in stack file(s) if you do
> it properly, people who follow that route often have trouble, so I
> discourage it.

Depends what's in the stack file.

The traditional factoring of code, UI, and data became a best practice 
for good reason.


But stack files can be very versatile storage containers, offering many 
of the benefits of LSON (LC encoded arrays) but with the addition of 
being able to contain LC objects as well.


LSON's generally my go-to unless I have a specific need for something 
else, but once in a while stack files have been a good solution for storage.


There are many storage formats to choose from, and stack files have a 
place among them.  For keeping with the tradition of separating code, 
UI, and data, it's not the format but how it's used.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Curry Kenworthy via use-livecode]

Although it's quite possible to save data in stack file(s) if you do it 
properly, people who follow that route often have trouble, so I 
discourage it. It's very tempting to try and save data to the 
distribution folder, or to mix data and user interface together! Quite 
the sticky, messy mixture. :)


A nice plan to avoid trouble is:

1. Keep data to save separate from UI
2. Save to Documents if the user should see it, otherwise App Data
3. Use a very standard Windows installer

(That's the easy road. And others have already mentioned some of those 
points in whole or in part.)


Distributing a zip also has a long heritage, there some outstanding apps 
distributed that way that I use myself, but when you have no control 
over the destination nor the integrity of the app folder, all the more 
reason to very strictly save ONLY to the most appropriate locations. 
Then you can skip the installer - but you can't skip both.


That would be your best short-term option now, having already taken 
another road and wanting a quick fix. Save the stack to App Data! Read 
it only once from the distro. Long-term, think hard about moving over to 
the "easy road" for data storage.


The days of distributing data however-the-heck-you-want are pretty much 
over. If you want some freedom in one area such as saving to your distro 
folder, you must gain greater control over other factors such as the 
install location or privileges. Obviously that's the more difficult and 
less certain path


In fact I have seen the tilde-named stack before, similar to what you 
describe. LC is unable to complete the save. I've also heard of lengthy 
delays when saving. I don't recall the specific trigger, but usually 
applying the above guidelines clears up these symptoms along with 
various other headaches. Where to save is very important, and doing it 
properly works wonders. "Just do it!" ;)


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[R.H. via use-livecode]

Windows: Regarding the many replies to the question of allowing saving a
stack file I would like to thank everybody for the answers by Matthias,
Bob, Alex, Jacqueline, JJS ...

The problem was that a stack file used by a compiled splash stack does not
save on some client's computers with Windows systems >= 7 and can only be
run once leaving an unsaved file that is renamed with a tilde character.

===

I am distributing the executing splash stack (compiled stack) in a folder
together with subfolders offering for download as a zip file. Users move
the zip to the desktop, unzips and uses. There is nothing stored in
inaccessible "system" or whatever non-user directories. It is a very simple
setup.

In one subfolder of the executable, the actual data stack is residing.

Yes, I am aware that I could save data outside of the stack and not save
the stack itself, but I agree with Richard that it must be possible to
store data in the stack itself in principle. For now, it would require a
new version if I stored data outside. But it is a good hint and I might
consider for later.

Another solution put forward by Alex was to rename the stack file from the
splash stack that failed to save and remove the tilde from the filename. In
fact, it could be a workaround and I have to test it, but it is ugly and it
would not allow saving after all. I will test it though as a quick solution.

Another question was whether user rights on client's computers might
disallow them to save the stack. But then, I checked and they usually use
Admin rights, then also the executable splash stack would not run. The data
stack is just a file to the system, nothing more. And why would it be
permitted on some machines and other not? (I checked that nobody is using
forbidden directories.)

The problem may be a bit deeper. I am also considering that if the stack
file is too big and the process of saving takes so long as in this case
(always > 15 secs, often 30 secs and more, even though no data was changed
at all) and Windows Defender might detect such activity and stop it because
of a time out. Just wild speculations...

Another speculation is that the stack file is somehow corrupted (not
detectable by me) and maybe the LiveCode team can check it's integrity. Or
is there a way to check this as well? I have started a ticket to look at
the problem.

I will report when I found a solution. I see that other users here might
not have encountered such problem on Windows machines and this in itself is
also valuable information.

Thanks to all
Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Bob Sneidar via use-livecode]

When I first distributed my Forms Generator to Windows users, I had it put into 
the Program Files folder. They immediately reported CTD almost as soon as they 
launched the app and after signing in. I traced it to the fact that I routinely 
save my stacks by script in development so I do not lose any changes. I had to 
completely refactor to not do that anymore, and to keep any persistent changes 
I needed to save in a prefs file. 

Bottom line, when distributing standalone, IMHO, don't save anything with the 
stack, or else install the standalone in a place where the user has write 
access by default. 

Bob S


> On Jan 15, 2019, at 08:38 , Matthias Rebbe via use-livecode 
>  wrote:
> 
> There should be no problem to copy/write/save a stack to the folder AppData . 
> This is the recommended place if your app needs to write data to disk. It can 
> be access using specialfolderpath("Support") or specialfolderpath(26).
> 
> Or has this really changed in Windows 10?
> 
> Matthias Rebbe


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[JJS via use-livecode]

yes "documents" on mobile is also ok

Op 15-1-2019 om 20:19 schreef J. Landman Gay via use-livecode:
The best folder to write to on mobile is "documents". Both iOS and 
Android are sandboxed and disallow writing to either "engine" or 
"resources".


On 1/15/19 12:04 PM, JJS via use-livecode wrote:
You could also use "home" as it works on 3 desktop platforms and iOs. 
Linux does not have a "support". and Android uses "Engine"



Op 15-1-2019 om 17:38 schreef Matthias Rebbe via use-livecode:
There should be no problem to copy/write/save a stack to the folder 
AppData . This is the recommended place if your app needs to write 
data to disk. It can be access using specialfolderpath("Support") or 
specialfolderpath(26).


Or has this really changed in Windows 10?

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 



Am 15.01.2019 um 16:54 schrieb Bob Sneidar via use-livecode 
>:


Yes, with Windows 10, there is a feature called Sandboxing, where 
even if your logged in user has write permissions to where the 
stack is saving, you will still  not be able to write there. 
Program Files is a great example. The solution is not to save 
stacks. Stacks should not be the place you save information. Think 
of them as more like web forms.


I learned this the hard way. Instead you should save settings and 
such in a "safe" location, either in a database or else in some 
kind of settings file. I have a whole system for this. I 
arrayEncode an array I use runtime for my settings and save it to 
disk each time a setting changes.


Bob S


On Jan 15, 2019, at 01:59 , R.H. via use-livecode 
> wrote:


Failed saving onWindows 10 (all latest versions of LiveCode)

I am talking about a compiled business related stack (small compiled
splash, main stack not compiled in a resource folder and various 
resources)

that goes to clients.

Some of my clients experience that the main stack is not saving 
and will
leave two files in a state that does not allow to reopen them 
again. One of
the files is renamed with a tilde character "~" at the end of the 
filename.
This is the file "in progress" to be saved from file A to B and 
when the

saving was successful, the old file is removed.


___
use-livecode mailing list
use-livecode@lists.runrev.com 
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode






___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[J. Landman Gay via use-livecode]

The best folder to write to on mobile is "documents". Both iOS and 
Android are sandboxed and disallow writing to either "engine" or 
"resources".


On 1/15/19 12:04 PM, JJS via use-livecode wrote:
You could also use "home" as it works on 3 desktop platforms and iOs. 
Linux does not have a "support". and Android uses "Engine"



Op 15-1-2019 om 17:38 schreef Matthias Rebbe via use-livecode:
There should be no problem to copy/write/save a stack to the folder 
AppData . This is the recommended place if your app needs to write 
data to disk. It can be access using specialfolderpath("Support") or 
specialfolderpath(26).


Or has this really changed in Windows 10?

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 

Am 15.01.2019 um 16:54 schrieb Bob Sneidar via use-livecode 
mailto:use-livecode@lists.runrev.com>>:


Yes, with Windows 10, there is a feature called Sandboxing, where 
even if your logged in user has write permissions to where the stack 
is saving, you will still  not be able to write there. Program Files 
is a great example. The solution is not to save stacks. Stacks should 
not be the place you save information. Think of them as more like web 
forms.


I learned this the hard way. Instead you should save settings and 
such in a "safe" location, either in a database or else in some kind 
of settings file. I have a whole system for this. I arrayEncode an 
array I use runtime for my settings and save it to disk each time a 
setting changes.


Bob S


On Jan 15, 2019, at 01:59 , R.H. via use-livecode 
> wrote:


Failed saving onWindows 10 (all latest versions of LiveCode)

I am talking about a compiled business related stack (small compiled
splash, main stack not compiled in a resource folder and various 
resources)

that goes to clients.

Some of my clients experience that the main stack is not saving and 
will
leave two files in a state that does not allow to reopen them again. 
One of
the files is renamed with a tilde character "~" at the end of the 
filename.
This is the file "in progress" to be saved from file A to B and when 
the

saving was successful, the old file is removed.


___
use-livecode mailing list
use-livecode@lists.runrev.com 
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Yes, with Windows 10, there is a feature called Sandboxing, where even
> if your logged in user has write permissions to where the stack is
> saving, you will still  not be able to write there. Program Files is a
> great example. The solution is not to save stacks. Stacks should not
> be the place you save information.

LiveCode stack files are a format; the file path is the location.

While it's often useful to separate UI from code, sometimes stack files 
make a really good storage format.


Windows does not care about the internal format of a file, only where 
it's saved.


Wherever you can store any binary file, you should be able to store 
stack files.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Alex Tweedly via use-livecode]

I would consider putting a check in the splash stack for the existence 
of the 'tilde' file, and removing/renaming it before opening the mainstack.


An ugly workaround until a proper fix happens - but maybe worth thinking 
about ?


Alex.

On 15/01/2019 09:59, R.H. via use-livecode wrote:

Failed saving onWindows 10 (all latest versions of LiveCode)

I am talking about a compiled business related stack (small compiled
splash, main stack not compiled in a resource folder and various resources)
that goes to clients.

Some of my clients experience that the main stack is not saving and will
leave two files in a state that does not allow to reopen them again. One of
the files is renamed with a tilde character "~" at the end of the filename.
This is the file "in progress" to be saved from file A to B and when the
saving was successful, the old file is removed.

The saving process takes very long (from 15 seconds and more). Sometimes
over 30 seconds -- with or without this problem.

If I ask the client to remove the tilde "~" then the stack can be reopened.
Otherwise not. Of course, I can not ask clients to do this in a production
environment or ask him to delete the installation and always install again.

Somewhere during the saving process, something happens that stops the
process and ends with a failure.

There are no error messages. I can not replicate the behaviour on my own
computer. But I can see it on client's machines (not just one).

I am wondering if this could also be something that occurs because of
interference of Windows Defender or some AV? Did anybody ever experience
something similar on Windows?

Kind regards and thanks for replies
Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[JJS via use-livecode]

You could also use "home" as it works on 3 desktop platforms and iOs. 
Linux does not have a "support". and Android uses "Engine"



Op 15-1-2019 om 17:38 schreef Matthias Rebbe via use-livecode:

There should be no problem to copy/write/save a stack to the folder AppData . This is the 
recommended place if your app needs to write data to disk. It can be access using 
specialfolderpath("Support") or specialfolderpath(26).

Or has this really changed in Windows 10?

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 


Am 15.01.2019 um 16:54 schrieb Bob Sneidar via use-livecode 
mailto:use-livecode@lists.runrev.com>>:

Yes, with Windows 10, there is a feature called Sandboxing, where even if your 
logged in user has write permissions to where the stack is saving, you will 
still  not be able to write there. Program Files is a great example. The 
solution is not to save stacks. Stacks should not be the place you save 
information. Think of them as more like web forms.

I learned this the hard way. Instead you should save settings and such in a 
"safe" location, either in a database or else in some kind of settings file. I 
have a whole system for this. I arrayEncode an array I use runtime for my settings and 
save it to disk each time a setting changes.

Bob S



On Jan 15, 2019, at 01:59 , R.H. via use-livecode mailto:use-livecode@lists.runrev.com>> wrote:

Failed saving onWindows 10 (all latest versions of LiveCode)

I am talking about a compiled business related stack (small compiled
splash, main stack not compiled in a resource folder and various resources)
that goes to clients.

Some of my clients experience that the main stack is not saving and will
leave two files in a state that does not allow to reopen them again. One of
the files is renamed with a tilde character "~" at the end of the filename.
This is the file "in progress" to be saved from file A to B and when the
saving was successful, the old file is removed.


___
use-livecode mailing list
use-livecode@lists.runrev.com 
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Matthias Rebbe via use-livecode]

There should be no problem to copy/write/save a stack to the folder AppData . 
This is the recommended place if your app needs to write data to disk. It can 
be access using specialfolderpath("Support") or specialfolderpath(26).

Or has this really changed in Windows 10?

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 

> Am 15.01.2019 um 16:54 schrieb Bob Sneidar via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Yes, with Windows 10, there is a feature called Sandboxing, where even if 
> your logged in user has write permissions to where the stack is saving, you 
> will still  not be able to write there. Program Files is a great example. The 
> solution is not to save stacks. Stacks should not be the place you save 
> information. Think of them as more like web forms. 
> 
> I learned this the hard way. Instead you should save settings and such in a 
> "safe" location, either in a database or else in some kind of settings file. 
> I have a whole system for this. I arrayEncode an array I use runtime for my 
> settings and save it to disk each time a setting changes. 
> 
> Bob S
> 
> 
>> On Jan 15, 2019, at 01:59 , R.H. via use-livecode 
>> mailto:use-livecode@lists.runrev.com>> wrote:
>> 
>> Failed saving onWindows 10 (all latest versions of LiveCode)
>> 
>> I am talking about a compiled business related stack (small compiled
>> splash, main stack not compiled in a resource folder and various resources)
>> that goes to clients.
>> 
>> Some of my clients experience that the main stack is not saving and will
>> leave two files in a state that does not allow to reopen them again. One of
>> the files is renamed with a tilde character "~" at the end of the filename.
>> This is the file "in progress" to be saved from file A to B and when the
>> saving was successful, the old file is removed.
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Bob Sneidar via use-livecode]

Yes, with Windows 10, there is a feature called Sandboxing, where even if your 
logged in user has write permissions to where the stack is saving, you will 
still  not be able to write there. Program Files is a great example. The 
solution is not to save stacks. Stacks should not be the place you save 
information. Think of them as more like web forms. 

I learned this the hard way. Instead you should save settings and such in a 
"safe" location, either in a database or else in some kind of settings file. I 
have a whole system for this. I arrayEncode an array I use runtime for my 
settings and save it to disk each time a setting changes. 

Bob S


> On Jan 15, 2019, at 01:59 , R.H. via use-livecode 
>  wrote:
> 
> Failed saving onWindows 10 (all latest versions of LiveCode)
> 
> I am talking about a compiled business related stack (small compiled
> splash, main stack not compiled in a resource folder and various resources)
> that goes to clients.
> 
> Some of my clients experience that the main stack is not saving and will
> leave two files in a state that does not allow to reopen them again. One of
> the files is renamed with a tilde character "~" at the end of the filename.
> This is the file "in progress" to be saved from file A to B and when the
> saving was successful, the old file is removed.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[Matthias Rebbe via use-livecode]

I cannot see this behaviour here and on our clients computers.
Our standalones with substacks are running on several Win10 machines. All 
theses standalones use
 preferences stacks, which are saved from within the standalones. The 
standalones were created with LC 9.0.1 Business.

We are delivering those standalones without an installer, so they are not 
placed in the Program Files folder. They are either placed in the documents, 
sometimes in a dropbox folder and some customers have placed them on drive 
D,E,F, but not on the system drive.

Are your standalones delivered with a installer and do they reside in Program 
Files folder? If so, did you take care, that it is not allowed to write into 
the Program Files folder?

To check, if your AV software is the culprit, i would try, if possible, to 
exclude your standalone and its other files from AV realtime scanning. Maybe 
one of your clients is willing to try.

Our clients all use F-Secure Client Security as AV/Firewall on Windows and we 
never run into any problem with our apps.


Matthias


Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 
> Am 15.01.2019 um 10:59 schrieb R.H. via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> Failed saving onWindows 10 (all latest versions of LiveCode)
> 
> I am talking about a compiled business related stack (small compiled
> splash, main stack not compiled in a resource folder and various resources)
> that goes to clients.
> 
> Some of my clients experience that the main stack is not saving and will
> leave two files in a state that does not allow to reopen them again. One of
> the files is renamed with a tilde character "~" at the end of the filename.
> This is the file "in progress" to be saved from file A to B and when the
> saving was successful, the old file is removed.
> 
> The saving process takes very long (from 15 seconds and more). Sometimes
> over 30 seconds -- with or without this problem.
> 
> If I ask the client to remove the tilde "~" then the stack can be reopened.
> Otherwise not. Of course, I can not ask clients to do this in a production
> environment or ask him to delete the installation and always install again.
> 
> Somewhere during the saving process, something happens that stops the
> process and ends with a failure.
> 
> There are no error messages. I can not replicate the behaviour on my own
> computer. But I can see it on client's machines (not just one).
> 
> I am wondering if this could also be something that occurs because of
> interference of Windows Defender or some AV? Did anybody ever experience
> something similar on Windows?
> 
> Kind regards and thanks for replies
> Roland
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com 
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues

[R.H. via use-livecode]

Failed saving onWindows 10 (all latest versions of LiveCode)

I am talking about a compiled business related stack (small compiled
splash, main stack not compiled in a resource folder and various resources)
that goes to clients.

Some of my clients experience that the main stack is not saving and will
leave two files in a state that does not allow to reopen them again. One of
the files is renamed with a tilde character "~" at the end of the filename.
This is the file "in progress" to be saved from file A to B and when the
saving was successful, the old file is removed.

The saving process takes very long (from 15 seconds and more). Sometimes
over 30 seconds -- with or without this problem.

If I ask the client to remove the tilde "~" then the stack can be reopened.
Otherwise not. Of course, I can not ask clients to do this in a production
environment or ask him to delete the installation and always install again.

Somewhere during the saving process, something happens that stops the
process and ends with a failure.

There are no error messages. I can not replicate the behaviour on my own
computer. But I can see it on client's machines (not just one).

I am wondering if this could also be something that occurs because of
interference of Windows Defender or some AV? Did anybody ever experience
something similar on Windows?

Kind regards and thanks for replies
Roland
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Matthias Rebbe via use-livecode]

I meant 

I have just tested it here with LC9.0.2

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de 
https://winsignhelper.dermattes.de 

> Am 09.01.2019 um 10:33 schrieb Matthias Rebbe via use-livecode 
> mailto:use-livecode@lists.runrev.com>>:
> 
> The whole discussion made me remembering that on my Mac i noticed a really 
> significant performance loss in SE when outputting large data in message box.
> When this is happening i can hear my fans boosting and the cpu temperature is 
> increasing.
> 
> As soon as i close the message box or empty it the SE is responsive again,the 
> temperature is lowering and the fans go into normal mode.
> 
> This script for example
> repeat 2
> put "12asdfadsfasdfasdfasfasdf3453"  after tOut
> end repeat
> put tout
> 
> is able to force this behaviour on an iMac 4Ghz i7 with 32GB ram.
> 
> Just test with LC9.0.2
> 
> Matthias Rebbe
> 
> free tools for Livecoders:
> https://instamaker.dermattes.de 
> https://winsignhelper.dermattes.de
> 
>> Am 09.01.2019 um 07:17 schrieb Richard Gaskin via use-livecode 
>> :
>> 
>> AndyP wrote:
>> 
>>> This 'thrashing about' of messages may also explain why the situation
>>> (speed) is impacted when the project browser and message  box are
>>> open?
>> 
>> Components that need frequent updates to reflect current state can indeed be 
>> tricky. You may find this report interesting, esp. Comment #3:
>> https://quality.livecode.com/show_bug.cgi?id=13585
>> 
>> -- 
>> Richard Gaskin
>> Fourth World Systems
>> Software Design and Development for the Desktop, Mobile, and the Web
>> 
>> ambassa...@fourthworld.comhttp://www.FourthWorld.com
>> 
>> ___
>> use-livecode mailing list
>> use-livecode@lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription 
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Matthias Rebbe via use-livecode]

The whole discussion made me remembering that on my Mac i noticed a really 
significant performance loss in SE when outputting large data in message box.
When this is happening i can hear my fans boosting and the cpu temperature is 
increasing.

As soon as i close the message box or empty it the SE is responsive again,the 
temperature is lowering and the fans go into normal mode.

This script for example
repeat 2
put "12asdfadsfasdfasdfasfasdf3453"  after tOut
end repeat
put tout

is able to force this behaviour on an iMac 4Ghz i7 with 32GB ram.

Just test with LC9.0.2

Matthias Rebbe

free tools for Livecoders:
https://instamaker.dermattes.de
https://winsignhelper.dermattes.de

> Am 09.01.2019 um 07:17 schrieb Richard Gaskin via use-livecode 
> :
> 
> AndyP wrote:
> 
> > This 'thrashing about' of messages may also explain why the situation
> > (speed) is impacted when the project browser and message  box are
> > open?
> 
> Components that need frequent updates to reflect current state can indeed be 
> tricky. You may find this report interesting, esp. Comment #3:
> https://quality.livecode.com/show_bug.cgi?id=13585
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

AndyP wrote:

> This 'thrashing about' of messages may also explain why the situation
> (speed) is impacted when the project browser and message  box are
> open?

Components that need frequent updates to reflect current state can 
indeed be tricky. You may find this report interesting, esp. Comment #3:

https://quality.livecode.com/show_bug.cgi?id=13585

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[AndyP via use-livecode]

This 'thrashing about' of messages may also explain why the situation (speed)
is impacted when the project browser and message  box are open?



-
Andy Piddock 


My software never has bugs. It just develops random features. 

TinyIDE  a Free alternative minimalist IDE Plugin for LiveCode 


Script editor Themer for LC http://2108.co.uk  

PointandSee is a FREE simple but full featured under cursor colour picker / 
finder.
http://www.pointandsee.co.uk  - made with LiveCode
--
Sent from: 
http://runtime-revolution.278305.n4.nabble.com/Revolution-User-f278306.html

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Mark Wieder via use-livecode]

On 1/8/19 3:36 PM, Monte Goulding via use-livecode wrote:




On 9 Jan 2019, at 6:56 am, Richard Gaskin via use-livecode 
 wrote:


Even more interesting IMO is all the attempts to access
revapplicationoverview.mc


Thanks - I've added a note on that detail in my report:

https://quality.livecode.com/show_bug.cgi?id=21782 


This would be the engine trying lots of paths when trying to resolve 
revApplicationOverview. See `MCDispatch::findstackname`. Clearly it is being 
referenced somewhere and it is not in the stackFiles of home as it should be. 
Whether this is the cause or not of the issues being discussed I’m not sure. It 
could be that windows defender gets stressed when it sees an application 
stabbing around in the dark trying to find a file.


Still begs the question as to why the engine is doing this. Now that 
I've sheepishly done a non-case-sensitive search for it, I see 
revApplicationOverview referenced a lot in the main backscript and I see 
that findstackname will take a stack short name as an argument and then 
try to find the stack file.


So is all that thrashing just the result of "is there is a stack..."? Or 
possibly "if the mode of stack..."? That could seriously be impacting 
the speed of lots of system messages.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Monte Goulding via use-livecode]

> On 9 Jan 2019, at 6:56 am, Richard Gaskin via use-livecode 
>  wrote:
> 
> > Even more interesting IMO is all the attempts to access
> > revapplicationoverview.mc
> 
> Thanks - I've added a note on that detail in my report:
> 
> https://quality.livecode.com/show_bug.cgi?id=21782 
> 
This would be the engine trying lots of paths when trying to resolve 
revApplicationOverview. See `MCDispatch::findstackname`. Clearly it is being 
referenced somewhere and it is not in the stackFiles of home as it should be. 
Whether this is the cause or not of the issues being discussed I’m not sure. It 
could be that windows defender gets stressed when it sees an application 
stabbing around in the dark trying to find a file.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Mark Wieder wrote:
> On 1/7/19 9:38 PM, Richard Gaskin via use-livecode wrote:
>> ...an interesting thing about file access is a lot of lstat and
>> open calls apparently looking for, and not finding, the App
>> Overview stack file:
>>
>> 
lstat("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev", 


>> 0x7ffc8d185800) = -1 ENOENT (No such file or directory)
>> 
open("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev", 


>> O_RDONLY) = -1 ENOENT (No such file or directory)
...
> Even more interesting IMO is all the attempts to access
> revapplicationoverview.mc

Thanks - I've added a note on that detail in my report:

https://quality.livecode.com/show_bug.cgi?id=21782

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Mark Wieder via use-livecode]

On 1/7/19 9:38 PM, Richard Gaskin via use-livecode wrote:
At a quick skim I see evidence of a lot of timers (which we would expect 
given the SE's features), but an interesting thing about file access is 
a lot of lstat and open calls apparently looking for, and not finding, 
the App Overview stack file:


lstat("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev", 
0x7ffc8d185800) = -1 ENOENT (No such file or directory)
open("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev", 
O_RDONLY) = -1 ENOENT (No such file or directory)


That much seems a bug, and I'll add notes to about that to the bug 
report. Since it isn't finding the file it can't write to it, and 
without writes I doubt it's the thing people are seeing when they turn 
RTP on and off.  But worth looking into for the sake of tidiness.


Even more interesting IMO is all the attempts to access 
revapplicationoverview.mc


Not only can I not think of a valid reason for that, I can't grep a 
reference to revapplicationoverview anywhere in the source except for a 
couple of custom properties in field list of stack revPluginEditor.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[JJS via use-livecode]

Correct.

Op 8-1-2019 om 00:09 schreef Richard Gaskin via use-livecode:

JJS wrote:
> I added .rev .livescript and livecode.exe to Windows Defender and have
> not had an slow issue since and keeping fingers crossed.

That's very valuable, thanks. So just to confirm, you did not need to 
turn off Real Time Protection, just exclude two file types and one EXE?




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Mark Wieder via use-livecode]

On 1/7/19 9:38 PM, Richard Gaskin via use-livecode wrote:

It's super-annoying to try to scroll though, and no, I haven't read 
every line (I'll leave that for more diligent souls like Mark Wieder, 
who will probably run that when he reads this ).


 OMW

--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Bob Sneidar via use-livecode]

It's kind of always been this way. I remember getting brand new Dells, 
installing all the software they need, joining domain etc. Last step was 
installing AV. The reason I put that last because the performance hit if I did 
it first would have doubled my deployment time. 

Bob S


> On Jan 8, 2019, at 08:08 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Bob Sneidar wrote:
> 
> >> On Jan 7, 2019, at 17:59 , Richard Gaskin wrote:
> >>
> >> Maybe this is one more reason to move everything to the cloud,
> >> to end the tyrrany of overzealously monitored local disk I/O. :)
> >>
> >> I honestly don't have the quick-fix answer that will keep our
> >> customers happy with disk-intensive apps.
> >>
> >> Sugggestions?
> >
> > SSD?
> 
> Alas, my tests were done on an SSD.  I haven't used platters for anything but 
> backups in half a decade.
> 
> In a few years we may reach a point where the speed difference between disk 
> and RAM will be so minor that it'll render half of the things they teach in 
> CS101 obsolete.
> 
> But for now, the order-of-magnitude difference on writes introduced by 
> Defender's RTP will likely remain a problem until Windows brings their AV 
> monitoring methods in line with more advanced packages.
> 
> -- 
> Richard Gaskin


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

>> On Jan 7, 2019, at 17:59 , Richard Gaskin wrote:
>>
>> Maybe this is one more reason to move everything to the cloud,
>> to end the tyrrany of overzealously monitored local disk I/O. :)
>>
>> I honestly don't have the quick-fix answer that will keep our
>> customers happy with disk-intensive apps.
>>
>> Sugggestions?
>
> SSD?

Alas, my tests were done on an SSD.  I haven't used platters for 
anything but backups in half a decade.


In a few years we may reach a point where the speed difference between 
disk and RAM will be so minor that it'll render half of the things they 
teach in CS101 obsolete.


But for now, the order-of-magnitude difference on writes introduced by 
Defender's RTP will likely remain a problem until Windows brings their 
AV monitoring methods in line with more advanced packages.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Bob Sneidar via use-livecode]

SSD?

Bob S


> On Jan 7, 2019, at 17:59 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Maybe this is one more reason to move everything to the cloud, to end the 
> tyrrany of overzealously monitored local disk I/O. :)
> 
> I honestly don't have the quick-fix answer that will keep our customers happy 
> with disk-intensive apps.
> 
> Sugggestions?
> 
> -- 
> Richard Gaskin


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Brian Milby via use-livecode]

It is mostly on change but also when SE windows get suspended.  Also when a SE 
window is closed if it has been >20s it does get saved as a precaution.  I’d 
need to dig in some more to see how frequently it is being saved while using 
the SE and trace code if warranted.

I found this much just by reviewing the code.  Next is watching the file while 
using the SE to see how often it gets updated.

Thanks,
Brian
On Jan 8, 2019, 1:25 AM -0600, Richard Gaskin via use-livecode 
, wrote:
> Brian Milby wrote:
> > I've looked into the pref save code and it isn't as bad as I thought.
> > The file is saved regularly, but not at the interval that I thought.
> > It does have a half second delay which should prevent too many file
> > writes (the actual save is debounced 500ms in the future, so if
> > another save request comes in then the write is delayed). I was
> > thinking that it was saving much more often.
>
> Were you able to determine why it's saved at regular intervals as
> opposed to when it changes?
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.com http://www.FourthWorld.com
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Brian:

> The file is saved regularly, but not at the interval that I thought.

One more hint - during symptoms, after making a new text selection with 
the mouse (as opposed to just typing on a line) there was an especially 
big delay before the field would be responsive again. To be successful 
with copy/paste I had to select, keep waiting for a second or two before 
copying, then select, wait until blinking insertion returned, then 
paste. Selecting and copying right away would fail.


Since that bug report, I've noticed that sometimes the line numbers in 
the SE will get out of sync with scrolling text and stick at a certain 
point (on Mac too, not requiring any symptoms of this bug and perhaps 
unrelated). In that condition, making a selection is what triggers the 
line numbers to refresh - maybe a significant trigger for some actions.


But during symptoms, it wasn't only slow selections - sometimes 
keystrokes were easy to mess up, but memory is growing dim. Now that we 
know the Defender fix, if the final fix still proves illusive I may need 
to unfix my computer when I get some time, maybe video it, to test 
symptoms again and make a more precise record of the editing delays and 
what triggers them.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Richard:

> Personally, I feel no driving need to try to take Mark
> Waddingham to school.

I have the utmost respect for Mark and his tremendous knowledge. And for 
everyone else high or low for that matter. I don't play favorites or 
tiptoe, I treat people the same. As the old saying goes, it rains on 
everyone. The laws and natural results of habits and actions good or bad 
apply to all.


Including me first and foremost; as I've indicated, matters of 
self-discipline involve the self, you can't actually force habits on 
others. But I do share and teach, to help others get better results. It 
works but it requires some discipline. Everyone can improve - you were 
asking, and I was answering, mostly about regular users. My clients 
teach me important lessons too. Learning is never a one-way street.


I seriously doubt this issue is Mark's fault (In fact, I don't think I 
mentioned any names) and in fact I'm still not 100% certain we've nailed 
it until it's verified, although it seems logical that we're close. 
Still some assumptions though, and therefore still possible to be wrong.


A little Mark would probably go a long way here! :D Then again this bug 
being in the IDE, I can understand if he is answering a higher calling.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> And I have the same respect for all, PHD or GED, but neither gets a
> free buddy pass from the laws of our universe (or from myself, since
> I also notice those laws) on what works best.

Uh, all right then.

Personally, I feel no driving need to try to take Mark Waddingham to 
school. Knock yourself out. I'm just trying to help diagnose a bug.



>  > when we do what should be considered the "right" thing
>  > and still find performance impaired.
>
> It usually WON'T be impaired in that case...

"Usually" being the operative word there.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Brian Milby wrote:
> I've looked into the pref save code and it isn't as bad as I thought.
> The file is saved regularly, but not at the interval that I thought.
> It does have a half second delay which should prevent too many file
> writes (the actual save is debounced 500ms in the future, so if
> another save request comes in then the write is delayed).  I was
> thinking that it was saving much more often.

Were you able to determine why it's saved at regular intervals as 
opposed to when it changes?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Brian:

> I've looked into the pref save code and it isn't as bad as I thought.

That's good...maybe something a bit closer to the auto formatting and 
replace features, and whatever organizes them?


Who knows, it could be something outside the SE that just happens to 
interfere, I don't like to speculate on exact causes or locations - but 
the SE itself is a bit suspect because if I remember, the issues got 
serious around the same time the SE and related parts of LC got some 
major new features. Definitely got bad in 9 (with Defender) whereas 
perfectly usable on 8 with Defender.


Seeing the files accessed within a short time period while typing would 
be useful...but if unlucky, it might involve conflicts or special 
conditions and require having symptoms showing. Hopefully not. If very 
lucky this could be debugged on any platform, not just Windows.


Assuming the "AV door" is indeed file access.

Hope it's not super hard to track down after all. :)

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Richard:

> Everyone on the LC dev team is either a CS or advanced
> mathematics graduate.
> I'm more interested in those of us who do not hold a doctorate in CS

That's why I mentioned both - the same rules apply to everyone. Not just 
in the LC world either. Math, physics, gravity, good or bad coding 
habits, rain - apply to all.


And I have the same respect for all, PHD or GED, but neither gets a free 
buddy pass from the laws of our universe (or from myself, since I also 
notice those laws) on what works best.


> when we do what should be considered the "right" thing
> and still find performance impaired.

It usually WON'T be impaired in that case - consistently applying solid 
philosophy, plus not assuming that all other code has been done well, 
tends to avoid the problems; that's the point. Key: solid philosophy, 
disciplined habits.


> I'm less interested in casting judgment on code I haven't read
> written by other people than just making the code I'm responsible
> for writing perform well.

It's not casting an emotional moral judgment (although come to think of 
it, scribbling horns on pics of offenders would be pretty fun). :D


But what I actually do is train and encourage people to strive for good 
coding habits.


To me it's simply - what else would anyone expect?

You get the cake you bake. The recipe you follow. If you put in 50 eggs 
or drop a cigarette into the batter, you get that too. Your actions 
dictate the result.


That may seem extreme examples, but so is constant disk access or other 
things that use resources too frequently or at a bad tim3. It's not 
cool. Nor something that we should just wait until it pops up, like 
whack-a-mole. That why our brains have pattern matching and 
philosophical features built in. Develop good habits. Anticipate 
possible issues. It's one of the many things people should have in mind 
to watch out for from the START, at least in their own code that they 
write themselves.


DB, flat file, web; doesn't matter. Nor only with this particular issue 
of disk access. Either way, people shouldn't just code things however 
the mood (or the sprint) takes them. Code carefully, organize well, try 
to anticipate what could go wrong as you type, think ahead, and learn 
from every mistake you make, take it to heart. The more problems that 
can be avoided mentally BEFORE they are written, the fewer to spend 
limited resources fixing. We can't eliminate bugs, but we can reduce a 
certain % with very little overhead on coding mental load, so it's a 
huge win.


If people don't code carefully with good habits, you'll get exactly the 
result that you created, sometimes you lucky anyway, and sometimes not. 
I like to help people start developing those good habits and turn around 
any bad ones.


I can often "smell" or calculate a very rough likely/not assessment that 
problems exist in other code by symptoms and logic; it's not by chance 
that I'm very often correct when i show up and start harping on 
something that triggers people. Ha ha. :)


> And with modern conventions trending toward auto-saving vs the
> older explicit user-driven saves, some of the most well-written
> apps write to disk more frequently than ever before.

There are also a lot of badly-written apps, even from big companies. 
Lousy code and sloppy work is fairly epidemic, tons of bad examples to 
potentially mislead the unwary CS student or PT hobbyist. I'm especially 
SMH when major websites or apps mess up their CORE features (up to and 
including financial ones) while undergoing mobile redesigns. Losing 
sight of the most important things. This is not an era of exemplary code 
in the world.


Auto saves not being triggered by the user puts us more in control, 
right? That's a good thing too. We have all the opportunity, and also 
responsibility to do it well. Not 10 times per second of course, to 
exaggerate again (although you never know) but when something needs to 
happen, there are plenty of things we can do to make it smooth and time 
it smart so the user doesn't get slapped in the face. If the user must 
be interrupted, give it a visual indicator. Actually quite simple to 
make apps very responsive, at least until the OS gets in the way and 
decides now it's time for something completely different.


Believe me, this is not very difficult to get right as far as its in 
your hands, and the rest, from OS and other apps, will usually not take 
things down too much further. People at all levels can understand being 
careful not to interrupt what the user is doing, and not calling 
expensive features too often.


> a lot of lstat and open calls apparently looking for, and not
> finding, the App Overview stack file

Very interesting. Glad you found that. More examples of things 
that...never mind! :D Hope you keep poking around.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

Re: windows defender issues? & other AV issues?

[Brian Milby via use-livecode]

I've looked into the pref save code and it isn't as bad as I thought.  The
file is saved regularly, but not at the interval that I thought.  It does
have a half second delay which should prevent too many file writes (the
actual save is debounced 500ms in the future, so if another save request
comes in then the write is delayed).  I was thinking that it was saving
much more often.

Interesting on revApplicationOverview.rev since that path isn't where the
stack lives (it is missing "Plugins").  I see 44 references to the stack
name in various places (most in revbackscriptlibrary - 33), but most come
in groups of 3 (if there is a stack... if the mode is not 0... the do
something).


On Mon, Jan 7, 2019 at 11:37 PM Richard Gaskin via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Curry Kenworthy wrote:
>
>  > Richard:
> ...
>  >> How many devs among us are shipping apps which rely on
>  >> frequent disk saves?
>  >
>  > Not the devs that heed my usual advice and KISS philosophy. :)
>  >
>  > But any system-intensive action performed too often or at the wrong
>  > time during typing, animation, or other activities where lag is
>  > obvious can be an issue on any platform - Mac, Windows, mobile, even
>  > web, even using any language - not just LC.
>  >
>  > Bad coding habits or insufficient caution is just bad, fullstop,
>  > regardless of the context. Good habits and caution are critical, no
>  > matter whether someone is a post-HC hobbyist or a degreed comp sci
>  > engineer. That's why I'm always harping like a broken record about
>  > good habits. :D
>
> Everyone on the LC dev team is either a CS or advanced mathematics
> graduate.  I'm not losing sleep over the prospect that they haven't at
> least thumbed though Knuth.
>
> The Script Editor is in competent hands, and with community involvement
> it only get better.
>
> I'm more interested in those of us who do not hold a doctorate in CS, or
> even when we do what should be considered the "right" thing and still
> find performance impaired.
>
> I haven't finished reading the specs at sqlite.org, but I skimmed enough
> this evening to get the impression that there's a fair bit of
> housekeeping needed to satisfy what we consider read-only operations
> like queries. Some of that housekeeping needs persistence, particularly
> with materializations for pre-evaluation of subqueries, among others.
>
> So using the world's most popular No-One-Ever-Got-Fired-For-Choosing-It
> local storage solution may still not make one immune to the effects of
> this unusual performance hit from Windows Defender.
>
> I haven't benchmarked that specifically, though it would be a good test
> if someone here has time.
>
> But even with flat files, we write data when we need persistence. I
> doubt many stay up late adding routines that write to disk
> unnecessarily. Sometimes it's to flush cache.  Sometimes it's state data
> useful for session restoration.  Sometimes it's the user's document.
>
> And with modern conventions trending toward auto-saving vs the older
> explicit user-driven saves, some of the most well-written apps write to
> disk more frequently than ever before.
>
> I'm less interested in casting judgment on code I haven't read written
> by other people than just making the code I'm responsible for writing
> perform well.
>
> To summarize what we've learned so far:
>
> - Apps write to disk for many legitimate reasons
>
> - Defender's RTP impairs performance of writes
>
> - Even "read" operations on the world's most common local
>storage format, SQLite, and others, may be affected.
>
> The latter merits testing. And given what we know of the SE, seriously so.
>
> It may be that Prefs plays a key role in timed tasks, but I can't
> imagine if it does that it was the result of an LC team member out of
> things to do.  We write when we need persistence, so I suspect they
> would do no less.
>
> But here's an interesting thing - boot your Linux box and run this:
>
>   strace ./livecodeindy.x86_64 &> strace-log.txt
>
> It's super-annoying to try to scroll though, and no, I haven't read
> every line (I'll leave that for more diligent souls like Mark Wieder,
> who will probably run that when he reads this ).
>
> At a quick skim I see evidence of a lot of timers (which we would expect
> given the SE's features), but an interesting thing about file access is
> a lot of lstat and open calls apparently looking for, and not finding,
> the App Overview stack file:
>
> lstat("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev",
>
> 0x7ffc8d185800) = -1 ENOENT (No such file or directory)
> open("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev",
>
> O_RDONLY) = -1 ENOENT (No such file or directory)
>
> That much seems a bug, and I'll add notes to about that to the bug
> report. Since it isn't finding the file it can't write to it, and
> without writes I doubt it's the thing people are seeing when they turn
> 

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> Richard:
...
>> How many devs among us are shipping apps which rely on
>> frequent disk saves?
>
> Not the devs that heed my usual advice and KISS philosophy. :)
>
> But any system-intensive action performed too often or at the wrong
> time during typing, animation, or other activities where lag is
> obvious can be an issue on any platform - Mac, Windows, mobile, even
> web, even using any language - not just LC.
>
> Bad coding habits or insufficient caution is just bad, fullstop,
> regardless of the context. Good habits and caution are critical, no
> matter whether someone is a post-HC hobbyist or a degreed comp sci
> engineer. That's why I'm always harping like a broken record about
> good habits. :D

Everyone on the LC dev team is either a CS or advanced mathematics 
graduate.  I'm not losing sleep over the prospect that they haven't at 
least thumbed though Knuth.


The Script Editor is in competent hands, and with community involvement 
it only get better.


I'm more interested in those of us who do not hold a doctorate in CS, or 
even when we do what should be considered the "right" thing and still 
find performance impaired.


I haven't finished reading the specs at sqlite.org, but I skimmed enough 
this evening to get the impression that there's a fair bit of 
housekeeping needed to satisfy what we consider read-only operations 
like queries. Some of that housekeeping needs persistence, particularly 
with materializations for pre-evaluation of subqueries, among others.


So using the world's most popular No-One-Ever-Got-Fired-For-Choosing-It 
local storage solution may still not make one immune to the effects of 
this unusual performance hit from Windows Defender.


I haven't benchmarked that specifically, though it would be a good test 
if someone here has time.


But even with flat files, we write data when we need persistence. I 
doubt many stay up late adding routines that write to disk 
unnecessarily. Sometimes it's to flush cache.  Sometimes it's state data 
useful for session restoration.  Sometimes it's the user's document.


And with modern conventions trending toward auto-saving vs the older 
explicit user-driven saves, some of the most well-written apps write to 
disk more frequently than ever before.


I'm less interested in casting judgment on code I haven't read written 
by other people than just making the code I'm responsible for writing 
perform well.


To summarize what we've learned so far:

- Apps write to disk for many legitimate reasons

- Defender's RTP impairs performance of writes

- Even "read" operations on the world's most common local
  storage format, SQLite, and others, may be affected.

The latter merits testing. And given what we know of the SE, seriously so.

It may be that Prefs plays a key role in timed tasks, but I can't 
imagine if it does that it was the result of an LC team member out of 
things to do.  We write when we need persistence, so I suspect they 
would do no less.


But here's an interesting thing - boot your Linux box and run this:

 strace ./livecodeindy.x86_64 &> strace-log.txt

It's super-annoying to try to scroll though, and no, I haven't read 
every line (I'll leave that for more diligent souls like Mark Wieder, 
who will probably run that when he reads this ).


At a quick skim I see evidence of a lot of timers (which we would expect 
given the SE's features), but an interesting thing about file access is 
a lot of lstat and open calls apparently looking for, and not finding, 
the App Overview stack file:


lstat("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev", 
0x7ffc8d185800) = -1 ENOENT (No such file or directory)
open("/home/rg/.runrev/components/livecodeindy-9.0.2.x86_64/revapplicationoverview.rev", 
O_RDONLY) = -1 ENOENT (No such file or directory)


That much seems a bug, and I'll add notes to about that to the bug 
report. Since it isn't finding the file it can't write to it, and 
without writes I doubt it's the thing people are seeing when they turn 
RTP on and off.  But worth looking into for the sake of tidiness.



Oddly, in my quick skim of the log file I haven't yet seen calls to the 
various SQLite files the IDE uses or the Prefs file, and alas I'm out of 
time on this for tonight...



> Thanks for your test, very nice. My regards.

Happy to one of the many people in this process.

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Richard:


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



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.


Thanks Richard. Yes - I also do frequent training, so any IDE issues 
tend to show up during tutoring and co-dev, besides annoying me a bit 
during my own work.



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


Not the devs that heed my usual advice and KISS philosophy. :)

But any system-intensive action performed too often or at the wrong time 
during typing, animation, or other activities where lag is obvious can 
be an issue on any platform - Mac, Windows, mobile, even web, even using 
any language - not just LC.


Bad coding habits or insufficient caution is just bad, fullstop, 
regardless of the context. Good habits and caution are critical, no 
matter whether someone is a post-HC hobbyist or a degreed comp sci 
engineer. That's why I'm always harping like a broken record about good 
habits. :D


Thanks for your test, very nice. My regards.

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

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.)

https://quality.livecode.com/show_bug.cgi?id=21604

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
http://livecodeconsulting.com/


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Brian:

> I think I know the issue then... look at how often the pref file
> is written.  Throttle/turn that off and see what happens.

> I was thinking that earlier today but those test results make me
> want to investigate that further.

Thanks Brian, fixing things up as usual!

Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

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.)

https://quality.livecode.com/show_bug.cgi?id=21604

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
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Brian Milby via use-livecode]

I think I know the issue then... look at how often the pref file is written.  
Throttle/turn that off and see what happens.

I was thinking that earlier today but those test results make me want to 
investigate that further.

Thanks,
Brian
On Jan 7, 2019, 8:40 PM -0600, Richard Gaskin via use-livecode 
, wrote:
> J. Landman Gay wrote:
> > I'm willing to bet that any slowdown in the SE not related to AV
> > intervention is probably the new auto-complete features. I've
> > turned most of them off and I see no speed decrease.
>
> Same here. But since the LC IDE is written in LCS, anything it does to
> trigger this widely-documented issue with Win Defender will sooner or
> later show itself in at least some of our apps.
>
> They key question is: which language features are most affected?
>
>
> A Test
> ---
> Given the nature of AV, it seemed file I/O would be a likely candidate,
> but to pin that down for sure I dug up a test script that touches a wide
> range of LCS features, running it with both Defender's Real-Time
> Protection (RTP) on, and then off.
>
> The script was the last of a series of general performance assessment
> scripts started by Malte back in 2014, during the early v8 series. Many
> of the elements identified through the various contributions in that
> forum thread helped point the way to dramatic increases in
> frequently-used operations like lineoffset, file I/O, and others. There
> are many good test suites out there, including some from Mark Talluto,
> Curry, and others. Many may have similar breadth; I chose this one
> because I'm familiar with the specifics of its scope:
> https://forums.livecode.com/viewtopic.php?f=67=22072=135950#p135752
>
> I modified the script only slightly so that it runs in the GUI LC rather
> than LiveCode Server, and with both RTP on and off.
>
>
> Findings
> 
> Here are the results:
>
> RTP ON
> System Version: Win32 NT 10.0
> --
> Test_BuildList: 187 ms
> Test_LineOffset: 3741 ms
> Test_LineAccessByNumber: 642 ms
> Test_LineAccessForEach: 36 ms
> Test_ArraySplit: 95 ms
> Test_EncodeArray: 90 ms
> Test_DecodeArray: 114 ms
> Test_ArrayAccess: 60 ms
> Test_Merge: 1409 ms
> Test_BuildFilePath: 505 ms
> Test_FileTextWrite: 6869 ms
> Test_FileTextRead: 192 ms
> Test_FileBinWrite: 9017 ms
> Test_FileBinRead: 74 ms
>
>
> RTP OFF
> System Version: Win32 NT 10.0
> --
> Test_BuildList: 192 ms
> Test_LineOffset: 4012 ms
> Test_LineAccessByNumber: 719 ms
> Test_LineAccessForEach: 39 ms
> Test_ArraySplit: 99 ms
> Test_EncodeArray: 113 ms
> Test_DecodeArray: 143 ms
> Test_ArrayAccess: 76 ms
> Test_Merge: 1609 ms
> Test_BuildFilePath: 579 ms
> Test_FileTextWrite: 515 ms
> Test_FileTextRead: 186 ms
> Test_FileBinWrite: 376 ms
> Test_FileBinRead: 74 ms
>
>
> Most tests are close enough that any differences can be accounted for
> with expectable fluctuations in general system performance due to the
> effects of background tasks.
>
> But writing files - damn! Now I understand what the reporters in the
> forums have been talking about.
>
> The magnitude of the speed hit makes me wonder exactly what RTP is doing
> - detailed analysis of the file I/O buffer?
>
> Whatever it is, it's worth thinking about in terms of how it will affect
> our own apps.
>
>
> Implications for Our Own Apps
> -
> The LC executable is signed, so while that may mitigate other AV issues,
> apparently that has no effect with the impact of file I/O ops on RTP.
>
> The auto-complete feature you mentioned here seems very relevant for all
> of us, because IIRC they use SQLite for that, where the driver's need to
> jump around the b-tree structure can trigger a fair bit of disk I/O.
>
> Even with those off, I would imagine that if you have the Dictionary tab
> open in the SE you'd see a similar impact, since Dict lookups are made
> as the selection changes.
>
> If there's any good news here, it's that there doesn't appear to be
> anything the team can do in the engine to avoid triggering RTP's impact.
>
> But the bad news may impact many of us: With apparently all disk writes
> affected, any use of a persistent local store will take a hit.
>
> This includes not only flat files, but databases like SQLite.
>
> Reading appears to have minimal impact, but while that won't affect flat
> files, some DBs may modify bits of some DB files when performing even
> read operations, so we can't completely rule out impact on what we think
> of as read-only DB operations.
>
>
> Dealing With RTP
> 
> As a paranoid security freak, I can't in good conscience recommend to
> end-users to turn of any feature of their security kit.
>
> But on balance, it's worth noting that other AV packages do not seem to
> impact storage performance this horribly, if at all. And many of the
> more popular alternatives are generally considered better than Windows
> Defender.
>
> So while it seems a bit heavy-handed to tell customers which AV package
> to use, Microsoft's unusually aggressive 

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:
> I'm willing to bet that any slowdown in the SE not related to AV
> intervention is probably the new auto-complete features. I've
> turned most of them off and I see no speed decrease.

Same here.  But since the LC IDE is written in LCS, anything it does to 
trigger this widely-documented issue with Win Defender will sooner or 
later show itself in at least some of our apps.


They key question is: which language features are most affected?


A Test
---
Given the nature of AV, it seemed file I/O would be a likely candidate, 
but to pin that down for sure I dug up a test script that touches a wide 
range of LCS features, running it with both Defender's Real-Time 
Protection (RTP) on, and then off.


The script was the last of a series of general performance assessment 
scripts started by Malte back in 2014, during the early v8 series.  Many 
of the elements identified through the various contributions in that 
forum thread helped point the way to dramatic increases in 
frequently-used operations like lineoffset, file I/O, and others.  There 
are many good test suites out there, including some from Mark Talluto, 
Curry, and others.  Many may have similar breadth; I chose this one 
because I'm familiar with the specifics of its scope:

https://forums.livecode.com/viewtopic.php?f=67=22072=135950#p135752

I modified the script only slightly so that it runs in the GUI LC rather 
than LiveCode Server, and with both RTP on and off.



Findings

Here are the results:

RTP ON
System Version: Win32 NT 10.0
--
Test_BuildList: 187 ms
Test_LineOffset: 3741 ms
Test_LineAccessByNumber: 642 ms
Test_LineAccessForEach: 36 ms
Test_ArraySplit: 95 ms
Test_EncodeArray: 90 ms
Test_DecodeArray: 114 ms
Test_ArrayAccess: 60 ms
Test_Merge: 1409 ms
Test_BuildFilePath: 505 ms
Test_FileTextWrite: 6869 ms
Test_FileTextRead: 192 ms
Test_FileBinWrite: 9017 ms
Test_FileBinRead: 74 ms


RTP OFF
System Version: Win32 NT 10.0
--
Test_BuildList: 192 ms
Test_LineOffset: 4012 ms
Test_LineAccessByNumber: 719 ms
Test_LineAccessForEach: 39 ms
Test_ArraySplit: 99 ms
Test_EncodeArray: 113 ms
Test_DecodeArray: 143 ms
Test_ArrayAccess: 76 ms
Test_Merge: 1609 ms
Test_BuildFilePath: 579 ms
Test_FileTextWrite: 515 ms
Test_FileTextRead: 186 ms
Test_FileBinWrite: 376 ms
Test_FileBinRead: 74 ms


Most tests are close enough that any differences can be accounted for 
with expectable fluctuations in general system performance due to the 
effects of background tasks.


But writing files - damn! Now I understand what the reporters in the 
forums have been talking about.


The magnitude of the speed hit makes me wonder exactly what RTP is doing 
- detailed analysis of the file I/O buffer?


Whatever it is, it's worth thinking about in terms of how it will affect 
our own apps.



Implications for Our Own Apps
-
The LC executable is signed, so while that may mitigate other AV issues, 
apparently that has no effect with the impact of file I/O ops on RTP.


The auto-complete feature you mentioned here seems very relevant for all 
of us, because IIRC they use SQLite for that, where the driver's need to 
jump around the b-tree structure can trigger a fair bit of disk I/O.


Even with those off, I would imagine that if you have the Dictionary tab 
open in the SE you'd see a similar impact, since Dict lookups are made 
as the selection changes.


If there's any good news here, it's that there doesn't appear to be 
anything the team can do in the engine to avoid triggering RTP's impact.


But the bad news may impact many of us:  With apparently all disk writes 
affected, any use of a persistent local store will take a hit.


This includes not only flat files, but databases like SQLite.

Reading appears to have minimal impact, but while that won't affect flat 
files, some DBs may modify bits of some DB files when performing even 
read operations, so we can't completely rule out impact on what we think 
of as read-only DB operations.



Dealing With RTP

As a paranoid security freak, I can't in good conscience recommend to 
end-users to turn of any feature of their security kit.


But on balance, it's worth noting that other AV packages do not seem to 
impact storage performance this horribly, if at all.  And many of the 
more popular alternatives are generally considered better than Windows 
Defender.


So while it seems a bit heavy-handed to tell customers which AV package 
to use, Microsoft's unusually aggressive approach to monitoring writes 
is impactful, and from the many stories with other apps we can find 
around the web, sometimes seriously.


Maybe this is one more reason to move everything to the cloud, to end 
the tyrrany of overzealously monitored local disk I/O. :)


I honestly don't have the quick-fix answer that will keep our customers 
happy with disk-intensive apps.


Sugggestions?

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, 

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Jacqueline:

> I'm willing to bet that any slowdown in the SE not related to
> AV intervention is probably the new auto-complete features.
> I've turned most of them off and I see no speed decrease.

Thanks Jacqueline, very true - that's yet another separate SE 
performance issue! Very good for people to know if they aren't on the 
most powerful machines.


(And who knows, depending on the timing of the symptoms appearing in the 
wild, might even relate to whatever allowed AV to get involved. The SE 
jerkiness/slowdowns related to Defender never gave me any big problems 
prior to LC 9. But that's a different issue and should be considered 
100% separate.)


In the case of Bug 21604, I had purposefully turned off most auto 
features in testing, as documented in the bug report.


Yes, me too - with Defender tweaked and auto off, I'm steaming along 
just fine on Windows. My only concern now is a permanent fix if 
possible, and why the same symptoms sometimes show up on Mac. ;)


Thanks to all involved for responding to my initial request last month 
and participating in pinning down the problem so far; it was pesky! :)


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[J. Landman Gay via use-livecode]

I'm willing to bet that any slowdown in the SE not related to AV 
intervention is probably the new auto-complete features. I've turned most 
of them off and I see no speed decrease.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 7, 2019 6:15:13 PM Curry Kenworthy via use-livecode 
 wrote:


And on that date I mentioned my suspicion/prediction (since others
reported similar symptoms on Mac, plus typing in a window shouldn't be a
biggie) that there was more to this than Defender/AV, potentially the
code design of SE and/or IDE.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

JJS:

> Speed, what are we talking about? milliseconds?
> Overall i find it working great with enough speed.
> Microsoft will probably not be interested that LC
> will run slow due to their product.

It looks like your reply MIGHT be referencing more general LC 9 ENGINE 
performance, an unrelated topic that Richard introduced to this thread. 
If so, important to correct before it becomes a snowball incorrect meme 
of a thousand posts. See my previous.


Depending on what turns out to be the final fix, snappier performance 
may be an extra benefit. I'm not going to explain why in detail; the 
savvy may understand, but that's a SECONDARY bonus that Richard 
amplified via conflation with another issue, and no time as I've had to 
correct some needless misrepresentations.


But such a performance perk would be of the nature that Richard 
described today himself as "Inexplicable slowdowns are the big mystery." 
And he has pointed out that Defender affects other apps with slowdowns.


So, depending on the fix, if something can be tweaked in SE/IDE to avoid 
Defender issues, that may have the side effect of better SE performance 
- depending on what actions (if any) in SE/IDE allow Defender/AV to get 
involved when the user is merely typing. Typically something we would 
not expect.


(Not talking about general engine ms speed, to type 500 wpm.) :)

PS: And of course to Richard's little trap perhaps, an example of the 
wifebeater question for those who follow fallacies and the like in 
dishonest/manipulative techniques of conversation, I'll amend my 
statement in previous post; I never made any suggestion that the Script
Editor was the cause of Microsoft's issues with Defender as it relates 
to any other apps. Nice one, Richard, but I caught it right after.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

Richard:

> And now the issue has become doubly conflated.
> To review, there are two issues in this thread:

Yes, I happened to mention that initial conflation today BEFORE you did, 
with some slight differences. Your post shadowed mine.


> With your addition, we now have a third concern introduced
> unrelated to AV handling:
> c) The performance optimization efforts demonstrably
> under way with LC's v9 series are not yet complete.

Richard, it seems you're shooting just a little off the mark lately. 
It's quite unusual for you to be inaccurate, and I've known you for a 
long time. If you have any personal issue with me, accept my apologies 
and best regards, but whatever it may be, don't let any feelings throw 
off your reading and writing accuracy and honesty. Facts, statements, 
and chronology are all public for reference. Sticking a little closer to 
them would be appreciated.


So now we may be triple-conflated. different general LC 9 ENGINE 
performance optimization issues is a completely different topic that 
doesn't belong in this thread and has ONLY been introduced here courtesy 
of yourself, Mr. Richard Gaskin. Nothing to do with me.


> While it is apparently of great interest to discuss more
> general performance issues in any thread where the topic
> may be plausibly inserted

That (not of this thread, again cross-threaded by yourself, Richard) was 
something I've promoted publicly since Jan 2017, and discussed with LC 
prior. And (I explain here ONLY because you force me, to avoid needless 
confusion to others, since you've now accused me of injecting it 
globally) in Sep 2018 I filed Bug 21561 "Slow LC 9 LCS Performance in 
Multiple Areas and Real Applications" to demo irrefutable effects in 
multiple areas of engine code BECAUSE at the time discussions of the 
optimization effort underway were focusing mainly on arrays. I mentioned 
it again in another thread BECAUSE in discussing 6/9 factoring OTHERS 
had already mentioned performance. These are all published, and we can 
quote and link if you wish, but not on this thread, please. Your recent 
comments about that bug report were off too, but I don't want to follow 
you on this cross-thread stuff.


I can't see any possible need to bring that topic here into this thread, 
and I'm not sure why you saw fit to do so, but again, that was you, 
RICHARD GASKIN, injecting it here, and not myself. Here in this thread I 
briefly mentioned (quote) "plus improved performance as a bonus" i.e. a 
possible (not guaranteed) extra INCENTIVE for fixing one of these AV 
problems, what you call the "Defender issue."


That "Defender issue" - in other words, my other Bug 21604 "Script 
Editor for LC 901 Unusable on Windows i3/i5" - and the other AV flagging 
issue (whether by Defender or any other AV) are both what OTHERS 
introduced to this thread when discussing AV, including yourself. Which 
is fine by me (both AV) but let's keep the chronology and facts 
straight: note that ANY and all conflation (or not) on this thread 
happened before my post today. Except this conflation of yours, of 
course! :)


> there is a key factor with the subject at hand which you
> may not have noticed in the comments in your bug report:
> Those who have disabled Windows Defender's Real Time Protection
> find the issue immediately resolved.

Again, you are straying from PUBLISHED details and chronology. In fact, 
in the very source you mentioned. On Nov 16, the Defender fix was noted. 
On Dec 12, I acknowledged that it was the case for me too, and thanked 
them for it. I don't think you can accuse me of not noticing something 
that I explicitly acknowledged, can you? And what I've emphasized today 
is a great quick fix for the symptoms? To overlook multiple statements 
of mine and suggest the opposite is going off the rails a little.


On Dec 12, I also warned about telling people to turn off Defender per 
se rather than just the affected part, which Panos then identified.


And on that date I mentioned my suspicion/prediction (since others 
reported similar symptoms on Mac, plus typing in a window shouldn't be a 
biggie) that there was more to this than Defender/AV, potentially the 
code design of SE and/or IDE.


> Back on topic in this thread, I agree with your assessment here,
> that if there is an opportunity to alter LC so that it no longer
> triggers this well known Microsoft bug,

Yes, that's where we've agreed, to that extent - that there may be a way 
to fix it/avoid it on the LC side. On Dec 12 I suggested it along my 
lines, and later the same day you suggested it along slightly different 
lines based on MS reports. I don't know whose theory will prove to be 
correct, but both possible and involving a shared component: changing 
something in LC to avoid this issue permanently.


> If the performance issues you're seeing on your Mac
> Any Mac-specific issues merit their own bug report as well

That's only true if your assumption or theory is correct. It hasn't 

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

JJS wrote:
> I added .rev .livescript and livecode.exe to Windows Defender and have
> not had an slow issue since and keeping fingers crossed.

That's very valuable, thanks. So just to confirm, you did not need to 
turn off Real Time Protection, just exclude two file types and one EXE?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Bob Sneidar via use-livecode]

Yes whitelisting is an option, but not for distributing apps. Well, not much of 
an option. Anytime you make users do something to their OS or AV to get your 
app to work, people get real nervous. 

Bob S


> On Jan 7, 2019, at 14:06 , JJS via use-livecode 
>  wrote:
> 
> Speed, what are we talking about? milliseconds?
> 
> It depends on where you need speed for.
> 
> Overall i find it working great with enough speed.
> 
> I work with a very known American company, and the software they use is about 
> to cry. screen flickers, it's as slow as hell and everybody has to work with 
> it, period. It was introduced about 3 years ago.
> 
> It's probably written in C. Waiting for screen updates can take up to 10 to 
> 20 seconds. And they use it worldwide, the mainservers are in the US.
> 
> And they don't give a sh*t that everyone hates it and complain, because they 
> paid for it. And managers above managers...someone introduced it, holy grail, 
> you know.
> 
> 
> I added .rev .livescript and livecode.exe to Windows Defender and have not 
> had an slow issue since and keeping fingers crossed.
> 
> Microsoft will probably not be interested that LC will run slow due to their 
> product.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[JJS via use-livecode]

Speed, what are we talking about? milliseconds?

It depends on where you need speed for.

Overall i find it working great with enough speed.

I work with a very known American company, and the software they use is 
about to cry. screen flickers, it's as slow as hell and everybody has to 
work with it, period. It was introduced about 3 years ago.


It's probably written in C. Waiting for screen updates can take up to 10 
to 20 seconds. And they use it worldwide, the mainservers are in the US.


And they don't give a sh*t that everyone hates it and complain, because 
they paid for it. And managers above managers...someone introduced it, 
holy grail, you know.



I added .rev .livescript and livecode.exe to Windows Defender and have 
not had an slow issue since and keeping fingers crossed.


Microsoft will probably not be interested that LC will run slow due to 
their product.



Op 7-1-2019 om 21:45 schreef Richard Gaskin via use-livecode:

Curry Kenworthy wrote:

Since Windows Defender is fairly unlikely to be the oh-so-sneaky 
culprit when similar issues show up running the LC 9 Script Editor on

the Mac platform...


And now the issue has become doubly conflated.

To review, there are two issues in this thread:

a) Windows Defenders "Real Time Protection" is widely documented
   across the Internet to have caused unusual slowdowns in a great
   many applications. LiveCode is one of those applications.

   My interest here is in seeking details on the cause of that
   Microsoft issue so we may determine if there's an opportunity
   to modify something in LC to move it from the category of
   known affected apps to those that are unaffected.


b) Some third-party AV packages will from time to time flag LC apps
   with false positives, easily remedied by working with those vendors.


With your addition, we now have a third concern introduced unrelated 
to AV handling:


c) The performance optimization efforts demonstrably under way with
   LC's v9 series are not yet complete.


If the performance issues you're seeing on your Mac are equal or greater
than those seen by bug reporters on the issue which is the topic of this
thread, that is notable of course but the subject of a separate
discussion.  Any Mac-specific issues merit their own bug report as 
well, just like the one we're discussing here which you had flagged as 
a Windows issue (#21604), and which led to the discovery of the 
contributory effect of Windows Defender.


While it is apparently of great interest to discuss more general
performance issues in any thread where the topic may be plausibly
inserted, there is a key factor with the subject at hand which you may 
not have noticed in the comments in your bug report:


Those who have disabled Windows Defender's Real Time Protection find the
issue immediately resolved.

Yes, as discussed at length in so many other threads, other
opportunities exist to further optimize LiveCode beyond the significant
gains made in the v8 and v9 series thus far.  So we would expect
evidence of remaining issues to show themselves on other platforms than
the one we're discussing here.  You may consider starting new threads 
on new subjects of interest to you.


Back on topic in this thread, I agree with your assessment here, that 
if there is an opportunity to alter LC so that it no longer triggers 
this well known Microsoft bug, it probably isn't in the script editor:


As I've also predicted previously in that bug report, it's a 
better-than-average bet that the LC 9 Script Editor is not using the 
best practices in some areas, because merely typing usually does not 
cause problems in most other apps on a fully Windows-Defended

system, not to mention Macs. 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. 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.


I would not be so quick to cast such sweeping judgment on the quality 
of the work the LiveCode team produces, but the suggestion that the 
Script Editor is not the cause of Microsoft's issue with Defender does 
indeed seem reasonable.


I mentioned the Script Editor as a recipe because its requirements 
tend to expose issues affecting performance, whether we're discussing 
those specific to Windows Defender as in this thread, or other 
specific opportunities for improvement cataloged elsewhere.


Hopefully this thread may leverage the collective experience of the 
community to find insight into the underlying triggers for the 
Defender issue we're discussing here.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

Since Windows Defender is fairly unlikely to be the oh-so-sneaky 
culprit when similar issues show up running the LC 9 Script Editor on

the Mac platform...


And now the issue has become doubly conflated.

To review, there are two issues in this thread:

a) Windows Defenders "Real Time Protection" is widely documented
   across the Internet to have caused unusual slowdowns in a great
   many applications. LiveCode is one of those applications.

   My interest here is in seeking details on the cause of that
   Microsoft issue so we may determine if there's an opportunity
   to modify something in LC to move it from the category of
   known affected apps to those that are unaffected.


b) Some third-party AV packages will from time to time flag LC apps
   with false positives, easily remedied by working with those vendors.


With your addition, we now have a third concern introduced unrelated to 
AV handling:


c) The performance optimization efforts demonstrably under way with
   LC's v9 series are not yet complete.


If the performance issues you're seeing on your Mac are equal or greater
than those seen by bug reporters on the issue which is the topic of this
thread, that is notable of course but the subject of a separate
discussion.  Any Mac-specific issues merit their own bug report as well, 
just like the one we're discussing here which you had flagged as a 
Windows issue (#21604), and which led to the discovery of the 
contributory effect of Windows Defender.


While it is apparently of great interest to discuss more general
performance issues in any thread where the topic may be plausibly
inserted, there is a key factor with the subject at hand which you may 
not have noticed in the comments in your bug report:


Those who have disabled Windows Defender's Real Time Protection find the
issue immediately resolved.

Yes, as discussed at length in so many other threads, other
opportunities exist to further optimize LiveCode beyond the significant
gains made in the v8 and v9 series thus far.  So we would expect
evidence of remaining issues to show themselves on other platforms than
the one we're discussing here.  You may consider starting new threads on 
new subjects of interest to you.


Back on topic in this thread, I agree with your assessment here, that if 
there is an opportunity to alter LC so that it no longer triggers this 
well known Microsoft bug, it probably isn't in the script editor:


As I've also predicted previously in that bug report, it's a 
better-than-average bet that the LC 9 Script Editor is not using the 
best practices in some areas, because merely typing usually does not 
cause problems in most other apps on a fully Windows-Defended

system, not to mention Macs. 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. 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.


I would not be so quick to cast such sweeping judgment on the quality of 
the work the LiveCode team produces, but the suggestion that the Script 
Editor is not the cause of Microsoft's issue with Defender does indeed 
seem reasonable.


I mentioned the Script Editor as a recipe because its requirements tend 
to expose issues affecting performance, whether we're discussing those 
specific to Windows Defender as in this thread, or other specific 
opportunities for improvement cataloged elsewhere.


Hopefully this thread may leverage the collective experience of the 
community to find insight into the underlying triggers for the Defender 
issue we're discussing here.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Richard wrote:
>> > Do you know what Defender is doing that other more full-featured
>> packages aren't in terms of application performance impairment?
>
> No, but I can guess that it is much as has been posted prior to this.
> Virtually all malware deterrent products use subscription based
> services, and many of them get their malware signature data from the
> same sources. False positives are not unheard of...

This conversation has spawned two different issues, conflated here.

The issue with false positives was raised by Tom Glod, and I've seen 
that once in a while too.


But the issue with Windows Defender is very different.  Defender isn't 
preventing LC from running at all, or (at least as far as anyone has 
reported to date) even flagging it as a false positive.  Instead, it 
merely slows down execution.  And if we search around on the web see a 
great many apps affected similarly.


False positives I can understand.  Inexplicable slowdowns are the big 
mystery.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Curry Kenworthy via use-livecode]

As I've (seriously) joked previously in my bug 21604 report that has 
been referenced already in this thread:


Since Windows Defender is fairly unlikely to be the oh-so-sneaky culprit 
when similar issues show up running the LC 9 Script Editor on the Mac 
platform, :D therefore it's highly doubtful that this is strictly an AV 
industry issue. Viewing it as such could even delay a permanent cure.


Fortunately, disabling Windows Defender's real-time virus options is a 
great fix for the symptoms. And like a good cold medicine, that is a 
huge relief! Currently I'm using a third-party AV (with some of its 
options tweaks as well) so in Windows Defender Security Center, "Virus & 
threat protection" is overridden by the other product. But "Firewall & 
network protection" and "App and browser control" and "Device security" 
are still fully enabled. It's NOT a good idea to disable the whole 
shebang, especially firewall. Be sure to have some form of AV installed. 
(I also had bad results with McAfee, which is what came pre-installed 
with my computer.)


As I've also predicted previously in that bug report, it's a 
better-than-average bet that the LC 9 Script Editor is not using the 
best practices in some areas, because merely typing usually does not 
cause problems in most other apps on a fully Windows-Defended system, 
not to mention Macs. 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. 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.


Thus, easing the symptoms (quick relief!) may be different than a 
permanent cure (no more of this trouble, plus improved performance as a 
bonus). The cure would probably make the SE snappier for all users, even 
those who never had problems. It would also head off any possible future 
issues in case other Operating Systems decide to imitate some of the 
Defender type features. It wouldn't be the first time one OS followed 
the lead of another.


It's important not to conflate two very different problems that have 
been discussed relating to Windows Defender. One is getting the 
"jitters" and having trouble typing, copy/pasting, etc in the LC 9 
Script Editor. The IDE itself is affected, and presumably may be the 
cause. This is the problem that I predict is fairly likely to be more of 
a code design issue than an AV issue.


The other problem is apps and their files being flagged or completely 
blocked by AV, which is a different and more common problem in the 
software world, and very much an AV and file trust issue.


Best wishes,

Curry Kenworthy

Custom Software Development
"Better Methods, Better Results"
LiveCode Training and Consulting
http://livecodeconsulting.com/

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Bob Sneidar via use-livecode]

No, but I can guess that it is much as has been posted prior to this. Virtually 
all malware deterrent products use subscription based services, and many of 
them get their malware signature data from the same sources. False positives 
are not unheard of, although I suspect they are fairly rare. 

We had an app that was generating a false positive in the AV module in our 
gateway/routers. Not only could I not copy the installer from the server to the 
local workstation I was trying to install on, but just opening a folder on the 
server from a remote location would cause the WAN connection to reset! I didn't 
connect the dots and couldn't figure out why my folders kept delisting their 
contents from remote sites until some time later! Informing the developer AND 
the subscriptions service eventually resolved the issue. 

If we had a list of all LC apps that were failing, along with a list of the 
libraries they used, we might be able to do a little detective work and figure 
out what library is causing an issue. Otherwise, it may simply be a matter of 
setting a dummy apps libraries to not automatically detect, and add one library 
at a time, rebuilding each time, in order to isolate the errant library. As I 
understand the problem, not all apps are suffering from this? 

Bob S


> On Jan 7, 2019, at 08:47 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Bob Sneidar wrote:
> 
> > We disable Windows Defender via group policy. A lot of IT
> > administrators do. It's not that it's a bad product, it's that
> > there are alternatives in the marketplace that provide a great
> > many more features, like central management and distribution
> > of policies, which can universally whitelist folders on all
> > domain controlled workstations.
> >
> > For the non-domain systems in a small office with a limited budget,
> > Defender is a great solution as an endpoint malware product. However,
> > these are the issues they will encounter, not just with LC apps but
> > with others.
> 
> Do you know what Defender is doing that other more full-featured packages 
> aren't in terms of application performance impairment?
> 
> In my searches I've found many explanations of the impact of the problem, but 
> nothing about its cause, not even whether Microsoft intends to repair 
> Defender to work more efficiently.
> 
> I'm hoping we can pin down the difference between apps affected by Defender 
> and those that run unimpaired, so we might consider whatever changes may be 
> needed to LC to put it into the latter category.
> 
> -- 
> Richard Gaskin


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> We disable Windows Defender via group policy. A lot of IT
> administrators do. It's not that it's a bad product, it's that
> there are alternatives in the marketplace that provide a great
> many more features, like central management and distribution
> of policies, which can universally whitelist folders on all
> domain controlled workstations.
>
> For the non-domain systems in a small office with a limited budget,
> Defender is a great solution as an endpoint malware product. However,
> these are the issues they will encounter, not just with LC apps but
> with others.

Do you know what Defender is doing that other more full-featured 
packages aren't in terms of application performance impairment?


In my searches I've found many explanations of the impact of the 
problem, but nothing about its cause, not even whether Microsoft intends 
to repair Defender to work more efficiently.


I'm hoping we can pin down the difference between apps affected by 
Defender and those that run unimpaired, so we might consider whatever 
changes may be needed to LC to put it into the latter category.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Bob Sneidar via use-livecode]

We disable Windows Defender via group policy. A lot of IT administrators do. 
It's not that it's a bad product, it's that there are alternatives in the 
marketplace that provide a great many more features, like central management 
and distribution of policies, which can universally whitelist folders on all 
domain controlled workstations. 

For the non-domain systems in a small office with a limited budget, Defender is 
a great solution as an endpoint malware product. However, these are the issues 
they will encounter, not just with LC apps but with others. 

Bob S


> On Jan 6, 2019, at 09:46 , Richard Gaskin via use-livecode 
>  wrote:
> 
> Tom Glod wrote:
> 
> > Hi folks, I'd like to know if there is any chance that the issues with
> > windows defender interfering in the normal operation of the LiveCode
> > engine is something that can and will be looked at?
> >
> > Is there any communication between Microsoft and Livecode inc?
> >
> > Is there any hope that we won't have to put an * beside on our
> > application requirements?
> >
> > Its just not an acceptable workaround to ask customers to disable
> > windows defender.
> 
> Panos has found that the issue is specific to Windows Defender's "Real Time 
> Protection":
> https://quality.livecode.com/show_bug.cgi?id=21604
> 
> It would be great if LC were the only app affected by this, so the LC team 
> could fix it.  But looking 'round the web I find that this is tragically 
> pervasive:
> https://duckduckgo.com/?q=windows+defender+slowing+apps
> 
> That said, it does not appear to be completely universal; that is, some apps 
> manage to avoid the wrath of Real Time Protection.
> 
> My comment #10 in that bug report asks what LC may be able to do to avoid the 
> impact of this Microsoft bug.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Matthias Rebbe wrote:

>> Am 06.01.2019 um 20:31 schrieb Richard Gaskin:
>> I don't believe certificates have been confirmed as the
>> differentiator for apps immune to this Microsoft bug, but
>> if anyone can confirm that please add it to the notes in
>> the report:
>> https://quality.livecode.com/show_bug.cgi?id=21604
>
> Is there a sample stack, maybe a benchmark stack,  i could test under
> Win10 which shows the behaviour with defender and does it not with
> defender inactive?
> I then could test the created standalone with and wihtout signing.

So far most reports center around using LC's Script Editor, which is 
sensible enough as it's one of the most computationally intensive 
activities we do regularly with LC.


The key, however, seems to be not just Windows Defender itself, but 
specific to its "Real Time Protection" option, per Comment 8 in that report.


So a good first diagnostic step would be to check that setting on your 
system.  If it's already on and you've noticed no lag when editing large 
scripts, it may be a red herring.  But if you only see lag after turning 
it on, that would seem reasonable confirmation, consistent with what at 
least half a dozen or so other users have reported so far.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Matthias Rebbe via use-livecode]

Is there a sample stack, maybe a benchmark stack,  i could test under Win10 
which shows the behaviour with defender and does it not with defender inactive?
I then could test the created standalone with and wihtout signing.

Matthias

Matthias Rebbe



> Am 06.01.2019 um 20:31 schrieb Richard Gaskin via use-livecode 
> :
> 
> Matthias Rebbe wrote:
> 
> >> The responsibility would probably be on you, the app developer, to
> >> get an exclusion for your particular app. I don't know much about
> >> how Defender works, but getting a signing certificate from MS may
> >> be one way to legitimize the app.
> >
> > So that´s maybe the reason, why no one of my customers who use Windows
> > 10 ever reported a problem.
> > I am using a Code Signing Certificate from Comodo to sign my Windows
> > apps.
> 
> I don't believe certificates have been confirmed as the differentiator for 
> apps immune to this Microsoft bug, but if anyone can confirm that please add 
> it to the notes in the report:
> 
> https://quality.livecode.com/show_bug.cgi?id=21604
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Matthias Rebbe wrote:

>> The responsibility would probably be on you, the app developer, to
>> get an exclusion for your particular app. I don't know much about
>> how Defender works, but getting a signing certificate from MS may
>> be one way to legitimize the app.
>
> So that´s maybe the reason, why no one of my customers who use Windows
> 10 ever reported a problem.
> I am using a Code Signing Certificate from Comodo to sign my Windows
> apps.

I don't believe certificates have been confirmed as the differentiator 
for apps immune to this Microsoft bug, but if anyone can confirm that 
please add it to the notes in the report:


https://quality.livecode.com/show_bug.cgi?id=21604

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Matthias Rebbe via use-livecode]

> 
> The responsibility would probably be on you, the app developer, to get an 
> exclusion for your particular app. I don't know much about how Defender 
> works, but getting a signing certificate from MS may be one way to legitimize 
> the app.
So that´s maybe the reason, why no one of my customers who use Windows 10 ever 
reported a problem.
I am using a Code Signing Certificate from Comodo to sign my Windows apps.

Matthias


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[Richard Gaskin via use-livecode]

Tom Glod wrote:

> Hi folks, I'd like to know if there is any chance that the issues with
> windows defender interfering in the normal operation of the LiveCode
> engine is something that can and will be looked at?
>
> Is there any communication between Microsoft and Livecode inc?
>
> Is there any hope that we won't have to put an * beside on our
> application requirements?
>
> Its just not an acceptable workaround to ask customers to disable
> windows defender.

Panos has found that the issue is specific to Windows Defender's "Real 
Time Protection":

https://quality.livecode.com/show_bug.cgi?id=21604

It would be great if LC were the only app affected by this, so the LC 
team could fix it.  But looking 'round the web I find that this is 
tragically pervasive:

https://duckduckgo.com/?q=windows+defender+slowing+apps

That said, it does not appear to be completely universal; that is, some 
apps manage to avoid the wrath of Real Time Protection.


My comment #10 in that bug report asks what LC may be able to do to 
avoid the impact of this Microsoft bug.



> The day Kevin was here last year for the develop yourself videos I
> demoed my stack to Chris, but not before the anti-virus (some lesser
> known security software) totally attacked my standalone stack.

"attacked"? What exactly happened?


> Are there any other experiences you've had with AV software attacking
> LC stacks?

I have not previously seen performance impairment from AV software, but 
from time to time I run across AV packages reporting LC-based apps with 
false positives.


The first time it happened I was alarmed, but since then I've learned 
that it seems many AV packages rely on Bloom filters, similar to what 
Google Chrome uses to identify malware sites, and Bloom filters by 
nature are prone to false positives.


So now when I encounter a false positive flagged from an AV package I 
drop a note to their Support department and pretty much all of them have 
been quick to whitelist my app.  In some cases, where the pattern that 
triggered the false positive was in the engine, one whitelist request 
winds up fixing the issue for all LC devs.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: windows defender issues? & other AV issues?

[J. Landman Gay via use-livecode]

Most software I've seen does ask users to whitelist their app in any 
anti-virus software the user has.


I don't think LC could ask for exclusions for any app it builds, it's a 
development platform. Anyone could take the free version, write some 
malware, and distribute it. That would be like asking AV software to 
exclude any app written in Java.


The responsibility would probably be on you, the app developer, to get an 
exclusion for your particular app. I don't know much about how Defender 
works, but getting a signing certificate from MS may be one way to 
legitimize the app.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On January 6, 2019 10:58:18 AM Tom Glod via use-livecode 
 wrote:



Hi folks, I'd like to know if there is any chance that the issues with
windows defender interfering in the normal operation of the LiveCode engine
is something that can and will be looked at?

Is there any communication between Microsoft and Livecode inc?

Is there any hope that we won't have to put an * beside on our application
requirements?

Its just not an acceptable workaround to ask customers to disable windows
defender.

The day Kevin was here last year for the develop yourself videos I demoed
my stack to Chris, but not before the anti-virus (some lesser known
security software) totally attacked my standalone stack.

Are there any other experiences you've had with AV software attacking LC
stacks?

Thanks,

Tom
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your 
subscription preferences:

http://lists.runrev.com/mailman/listinfo/use-livecode





___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

windows defender issues? & other AV issues?

[Tom Glod via use-livecode]

Hi folks, I'd like to know if there is any chance that the issues with
windows defender interfering in the normal operation of the LiveCode engine
is something that can and will be looked at?

Is there any communication between Microsoft and Livecode inc?

Is there any hope that we won't have to put an * beside on our application
requirements?

Its just not an acceptable workaround to ask customers to disable windows
defender.

The day Kevin was here last year for the develop yourself videos I demoed
my stack to Chris, but not before the anti-virus (some lesser known
security software) totally attacked my standalone stack.

Are there any other experiences you've had with AV software attacking LC
stacks?

Thanks,

Tom
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode