PureBasic Forum

How odd, since it works fine here on 23 different Windows 7 x86 machines when i tested it out. You are putting them in the 'Excluded Processes' and not the file and folder exclusions right?

Do you have full permissions to the purebasic install folder?

DOH!

Of course I am! And it suddenly started working, too! How convenient.

Does this problem occur with other development environments???

MSE isn't identifying PB or it's generated executables as a virus/malware but maybe Fred should submit this form anyways?
http://www.microsoft.com/security/porta ... itive.aspx

After IDE restart?

Glad it worked out for you

Its not a false positive or anything else. Its normal activity from a correctly implemented real time protection, so MSE is working as intended and PureBasic is working as intended - MSE just needs the addition of the exclusions in MSE which is why there is a place to put the exclusions - to exclude those things from the real time protection scan. There is nothing to submit, and even if it was submitted MS is just going to come back and say that its working as intended and to add the exclusions so Fred would be wasting his time trying to submit for something thats working as intended, we went over this in the beta for other things as well so its just not PB.

Just noticed the following:
I removed all PureBasic_CompilationXXX.exe from the exclude list, so i exclude just the .exe from PureBasic.

Everything compiles very fast, but everything that requires TEMP is starting slow (starting unsaved sources
and all other saved sources without the compiler option "Create temporary executable in the source directory")

All sources with enabled "Create temporary executable in the source directory" start instantly.
Maybe MSE scans the whole TEMP folder every time or runs more checks for TEMP.

I enabled "Create temporary executable in the source directory" as default compiler option now,
so all new created files startup fast after saving the source.

Excluding the whole TEMP folder is too risky in my opinion.

You are correct, it is very risky to exclude the whole temp folder, never do that.

Yes, unless the compilation .exe in the temp folder is excluded then its going to start slow because the temp folder is a major use vector for viruses/trojans/malware so its by default included as a whole in the real time protection scan and monitored, and the temp compilation .exe, unless excluded, the real time protection sees it as "suspect activity" until proven otherwise because of the uniqueness of the temp folder in the user path as a system folder and that is exactly what real time protection for a monitored location is supposed to do. So because it sees it as "suspect activity" (because things are not expected to "initiate" in the temp folder suddenly that never existed before in that location like the compilation .exe does) it has to scan the whole compilation as its compiled and run and thus the time it takes. (OK, "suspect activity" is a little strongly worded, we know its not real suspect activity for the compilation)

In a weird way, the compilation .exe does mimic some malware activity in that each run its a new compilation .exe and that new compilation never existed before as it was at the moment of compilation even if the same file name is being used. Some malware does this also, suddenly create or change something in the temp and then execute it from there.

I think I said this right.

No, after I moved it from "files and locations" to processes... I had tried this before reading about it, and thought I had it in the right place but typos or something. I just missed the part about processes.

never hurts to check, which is why I mentioned it.

I appreciate the persistence with helping!

I was hoping the "DOH" and embarrassed smiley would have made the sarcasm clear that I had it in the wrong place until that post. Sometimes the keyboard just isn't very clear at communicating, so I have to clean it with windex. After that, my coding always goes faster, too.