OpenEuphoria

2. Re: Vista users: machine level exception when calling external functions

• Posted by CChris Jul 30, 2008
• 1011 views

There was a contribution about enabling DEP in the archive, http://www.rapideuphoria.com/dep.zip

I would certainly try it out, as your problem has been reported before, and reported to be cured by this I don't have Vista myself, and disabled DEP under XP as much I could.

CChris

4. Re: Vista users: machine level exception when calling external functions

• Posted by jacquesd Jul 30, 2008
• 937 views

With Shawn Pringle code integrated in your application, the application itself
will unlock DEP so the end user won't have to disable DEP.
The only problem is that you must recompile exw.exe with the modified machine.c
I think this should be added to 4.0.

Jacques d.

6. Re: Vista users: machine level exception when calling external functions

• Posted by CChris Jul 30, 2008
• 967 views

It boils down to executing code in a memory area Windows didn't assume oto hold executable code. This is supposed to defend against various virii. The memory allocate() returns a pointter to is not marked as executable, and this is why call() may fail with a machine level exception.

DEP can be restricted to only affect Windows base services, not user pps. That way, Euphoria apps with machine code an run. I am les sure why a call to c_func() would fail, but the reason is very likely close, if not identical.

I second the motion to inclue the fix in Eu 4.0. I'd do it if not for the lasting lack of svn access.

CChris

8. Re: Vista users: machine level exception when calling external functions

• Posted by CChris Jul 30, 2008
• 933 views

DEP is activated only in Vista and XP SP2 and later. People with older versions/service packs are not affected. Some older processors may not support it either.

How DEP is configured depends on various things. To check how your settings are, go to Configuration Panel -> System -> Advanced. Then, two courses are available:

1. Check which programs DEP applies to: Go to Performances -> Data Execution Prevention and see which radios are checked, and whether there is an exclusion list.
2. (what I did) instead, go to Boot and Recovery options, click Modify to access the boot options, go to the line that says
   /noexecute=<various possibilities>.
   Change it to
   /noexecute=AlwaysOff .

Then save and OK out. Change effective on next reboot, call() no longer crashes.

I remember that Rob wrote something in the foum a while ago, but you can probably find the post, even if we still cannot.

M$ says it is part of a defensve strategy. Since DEP relies on simple mechanisms that have existed since the 80386 CPUs were released, I think the defense is more against competition than against hackers. Just my opiniion. Virii makers have known for a long time that they had to mark their hot memory pages as executable and tweak the paging system, so they don't care about DEP anyway, they tunnel beneath it.

CChris

10. Re: Vista users: machine level exception when calling external functions

• Posted by CChris Jul 30, 2008
• 942 views

[quote jeremy]

No, it's rather something you have to do something to disable rather...

demo/callmach.ex is said to be a good test to see if there is a problem with DEP wrt call(). I didn't reenable DEP to test this. Your setting should - crossing fingers - be enough to avoid the annoyance.

When you use call_back(), you get an address from a routine id. A routine id may come either from define_c_proc() or routine_id().

• In the latter case, the routine is in executable memory area, and DEP does not interfere.
• Inn the former case, it all depends on how the dll was compiled. And if you used the "" special dll entry point in order to get a routine id from machine code in RAM, Intel knows what state the code page it is in has. If the page doesn't have the PAGE_EXECUTE flag, DEP may terminate the offending process thru a page fault exception.

Also remember you can get an external routine address using define_c_var(). Same here: who knows how cleanly the thing was compiled? Older code didn't need to deal with DEP, as it was not enabled by the OS.

I'd suggest any reader with failing c_func() calls or similar that can be traced without a doubt to DEP interference to email Jeremy so as to provide him with some test code. Again, if demo/callmach.ex passes, there may <cough> be no problem at all.

CChris