You're right, but I meant writing to the .exe disk file while running.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bhkusi$22oa$1@digitaldaemon.com...
> It's not impossible.  Just allocate some memory, mark its page callable,
and
> write some instructions there and call it!  You may have to copy your code (hope it's internally using relative addressing!)
>
> You may find that you can modify the program code memory to be writable, allowing old-school SMC.
>
> Personally I wish x86 would go the way of the dinosaur and make room for
the
> new chip designs.  Trinary ops, anyone?  x86 code requires lots of superfluous mov's and register management.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:bhkqkp$1va8$1@digitaldaemon.com...
> > I've always had a soft spot for self-modifying code. One example I
thought
> > was the cat's meow was when I figured out how the original ADVENT
FORTRAN
> > program initialized itself, and then rewrote its own executable.
> >
> > I then used a similar technique to avoid configuration files in my own programs. They'd just patch the executable. That came to a halt when
virus
> > checking programs became common, as self-modifying exe files were
> supposedly
> > a sure sign of virus activity. Then Microsoft killed it altogether by
> making
> > it impossible for an exe to write to itself while running. Oh well.
> >
> > I still enjoy writing x86 assembler.
>
>

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bhktil$21kb$1@digitaldaemon.com...
> We all know Walter busts his ass on this language.  But what has this to
do
> with him, really?  He's probably laughing his ass off, or ignoring the
whole
> thread.  ;)

I'm reading it. The thing is, the goto debate was raging in the 1970's. I've got the scars and the t-shirt to prove it. The issue was never resolved (and cannot be), it just settled into a truce where those who liked goto's used them and those who didn't didn't. Language designers who wished to appeal to both groups put in a goto.

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhl7fi$29vq$1@digitaldaemon.com...
> > It's no different than people using C as a back end to their language Z,
> and
> > many many people (including myself) have wanted to make C as the output
of
> > D. Supporting goto isn't hard, why close the door on such uses?
> >
> C is just used because there are no easily availiable tools for
> ast->optimised code
> why not open the door on the D back end ...

Because that's far, far more work than just adding a goto statement!

"Walter" <walter@digitalmars.com> wrote in message news:bhlqec$2qvg$1@digitaldaemon.com...
> You're right, but I meant writing to the .exe disk file while running.
>
patching you own exe so you can save "state", or both self modifying code and state saveing.

not too sure about the effect of self modifying code on x86 cpus with separate I and D caches, but do know that there are very heavy penalties on StrongArm. and there are some hoops you have to jump through on some CPU's to just get the data flushed from D cache into memory and reload the I cache, for example when dynamic compiling.

it might be a fun interlectual challenge to see if I can memmap a file, write some self modifying code into it, mark pages as executable and then start running it ...

I don't believe that on a modern cpu there are many reasons to want to
execute code from stack, or data space, or be able to write to code segment.
infact the only reason I think valid is dynamic compilation. and accept that
page level granularity (allowing a page to be written, then changed to
execute, readonly or execute only) may not be fine enough and there are
times when you want to be able to write to a page that is also being
excuted, but don't think you should be writing into areas that are actually
running especially on a multi proccessor env your going to run a huge risk
of shooting yourself, not to mention having the data potentially cached in 4
or more places (2+ cpus with separate I and D caches) and many be even in
more than 2 pipelines too.
as I only belive writeing code for execution is valid if doing dynamic
compilation, there are cpu friendlier ways that only require D-cache flush
of a page and I cache invalidation of a page.

Mike Wynn wrote:
> C is just used because there are no easily availiable tools for
> ast->optimised code
> why not open the door on the D back end ...

I have seen a number of good efforts, which so far have had little support, and thus results are mediocre.

* C-- "portable assembly language" - a language to be output by compilers as intermediate. Lower-level than C, solves a number of its shortcomings as intermediate. Current compiler is experimental, LCC-based, non-optimised. If someone would make a GCC-based compiler for the language, this could be a worthy target.
	http://www.cminusminus.org/

* TenDRA C++ compiler generates bytecode as intermediate language, called "Architectural Neutral Distribution Format" (ANDF). Which, in turn, is compiled ahead of time on the target machine to generate an executable. There are a number of back-ends for this one, both commercial and free. I believe the free x86 back-end is very new, and is  non-optimised yet. The project seemed almost dead for a while, but now it's back to activity. I believe this may become a very worthy target.
	http://www.tendra.org/
	http://www.tendra.org/news/interest.html

There must also be others, i just can't remember. So far all free, cross-platform compiler back-ends i've seen except for GCC have most of their targets in "experimental" state, not very optimised. No wonder, since it takes so many years dedicated work for each!

-eye

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhls47$2snk$1@digitaldaemon.com...
> I don't believe that on a modern cpu there are many reasons to want to execute code from stack, or data space, or be able to write to code
segment.

I keep thinking that most buffer overrun exploits would become inoperable if the stack was set to be read/write, but not execute.

"Walter" <walter@digitalmars.com> wrote in message news:bhlr17$2rhj$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bhktil$21kb$1@digitaldaemon.com...
> > We all know Walter busts his ass on this language.  But what has this to
> do
> > with him, really?  He's probably laughing his ass off, or ignoring the
> whole
> > thread.  ;)
>
> I'm reading it. The thing is, the goto debate was raging in the 1970's.
I've
> got the scars and the t-shirt to prove it. The issue was never resolved
(and
> cannot be), it just settled into a truce where those who liked goto's used them and those who didn't didn't. Language designers who wished to appeal
to
> both groups put in a goto.
>
I agree it never will be resolved, however believe as more languages add
features that replace most of the uses of goto and less implement it, the
users (and uses) of goto will slowly fade into obscurity.
D offers more that many langs for removing goto without seriour effect to
code
(multi level break/continue, exception and nested functions)
so far I've only heard one good reason for having goto in D (back end
support)
which I accept does make life easier those who are going to use D as a
backend lang.
I'm curious if there are any others that can not be resolved easily
(multi level redo is the only other thing that comes to mind, something I
have wanted to do on the odd occasion)

"Walter" <walter@digitalmars.com> wrote in message news:bhkbde$1cgb$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhjruo$kd9$1@digitaldaemon.com...
> > but like pointers there are other constructs that are more robust and
> > perform the same task
> > (bounded array and reference (unmovable pointer))
> > even at a very low level, you only _need_ those two (well bounded array
is
> > enough as a length of one is a ref, but we all like a little syntactic
> > sugar).
> > movable pointer is just an efficient way to do both in one go. (well
> > unbounded array)
>
> You can always refactor the code to eliminate the need for a goto. That doesn't mean it's cost effective, especially when it results in a lot of diff's from one version to the next that makes it hard to verify just how the algorithm changed.
>
therefore a language without a goto can be used as a backend language,
meaning that the D compiler writer has an easier task, and the user of D as
a backend has a more complex task.
as I said, I would prefer to see D as a front end using a backend that was
designed for the task of being a backend.
I'm sure it would horrify you that I would also like to see the system taken
to what to me seem a logical conclusion of having
D+ (superset of D syntax with goto and other "unsafe features")
D  (the core D with a few "unsafe" ops but not too many)
D# (sub set of D syntax allowing only safe operations, no pointers or
sliceing stack alloced arrays, or passing inner functions as delegates (or
has safe ways to allow this (stack frame promoted to heap etc)))

all using the same backend, which may also support functional, and dynamic langs allowing the D langs to interoperate even better than it can now. (potential to link to C++ or other OO langs directly [rather than using C as an intermediate convention])

"Walter" <walter@digitalmars.com> wrote in message news:bhm0j3$9l$1@digitaldaemon.com...
>
> "Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:bhls47$2snk$1@digitaldaemon.com...
> > I don't believe that on a modern cpu there are many reasons to want to execute code from stack, or data space, or be able to write to code
> segment.
>
> I keep thinking that most buffer overrun exploits would become inoperable
if
> the stack was set to be read/write, but not execute.
>
should do, only leaves you the ability to change the local in current and
parent frames and return addresss of parent frames (you might be in a leaf
function on a risc arch so current return address may be in link reg)
to remove more you have to go further and hide (either change segment reg or
mark pages unreadable) the parent frames and return address (separated
stacks)
still potentially allows you to change locals or scribble into the heap.
guess that's the reason ppl rely on software solutions.

You mean long-term SMC.  I gotcha.  You could still do that, but in a roundabout way, by providing a "loader" program that patches the real program then executes it.  Antivirus software would still complain even if Windows doesn't.  And there'd still be issues with running multiple copies of the program simultaneously.

What I would use it for is having a program make special case functions by splicing together function fragments at runtime.  Or just customizing a function with special constants before calling it.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:bhlqec$2qvg$1@digitaldaemon.com...
> You're right, but I meant writing to the .exe disk file while running.
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:bhkusi$22oa$1@digitaldaemon.com...
> > It's not impossible.  Just allocate some memory, mark its page callable,
> and
> > write some instructions there and call it!  You may have to copy your
code
> > (hope it's internally using relative addressing!)